Việc chấp nhận LIÊN QUAN, THÀNH LẬP cho tất cả các nguồn trong iptables được coi là quá mở?


9

Tôi thường thấy quy tắc -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTđược áp dụng. Trong khi tôi không phải là một chuyên gia, dòng đặc biệt đó liên quan đến tôi. Rõ ràng là quy tắc cho phép tất cả lưu lượng truy cập với ngoại lệ duy nhất là kết nối phải được thiết lập hoặc liên quan đến kết nối đã thiết lập.

Kịch bản

  • Tôi sẽ cho phép kết nối với cổng SSH mặc định 22từ mạng LAN máy chủ trong mạng con 192.168.0.0/16hoặc bất cứ điều gì.
  • SuperInsecureApp®phơi bày một cái gì đó trên cổng 1337, mà tôi thêm vào INPUTchuỗi của tôi .
  • Tôi đã thêm conntrackquy tắc để chấp nhận ESTABLISHEDRELATEDtừ tất cả các nguồn
  • Chính sách chuỗi là DROP

Về cơ bản, cấu hình đó chỉ cho phép kết nối SSH từ mạng LAN, đồng thời cho phép lưu lượng truy cập vào cổng 1337 từ thế giới.

Đây là nơi sự nhầm lẫn của tôi nở hoa. Sẽ conntrackbằng mọi cách vạch trần một lỗ hổng bảo mật mà sẽ cho phép một để có được một kết nối thành lập vào năm 1337 (kể từ khi nó mở thế giới), và sau đó sử dụng kết nối để tiếp cận được với cổng SSH (hoặc bất kỳ cổng khác cho rằng vấn đề)?

Câu trả lời:


8

Tôi sẽ không xem lưu lượng truy cập THÀNH LẬP và LIÊN QUAN quá mở. Bạn có thể bỏ qua LIÊN QUAN, nhưng chắc chắn nên cho phép THÀNH LẬP. Cả hai loại lưu lượng này đều sử dụng trạng thái conntrack.

Các kết nối được thành lập đã được xác nhận bởi một quy tắc khác. Điều này làm cho nó đơn giản hơn nhiều để thực hiện các quy tắc đơn hướng. Điều này chỉ cho phép bạn tiếp tục giao dịch trên cùng một cổng.

Kết nối liên quan cũng được xác nhận bởi một quy tắc khác. Chúng không áp dụng cho rất nhiều giao thức. Một lần nữa họ làm cho nó đơn giản hơn nhiều để cấu hình các quy tắc. Họ cũng đảm bảo trình tự phù hợp của các kết nối nơi họ áp dụng. Điều này thực sự làm cho quy tắc của bạn an toàn hơn. Mặc dù điều này có thể giúp kết nối trên một cổng khác, nhưng cổng đó chỉ là một phần của quy trình liên quan như kết nối dữ liệu FTP. Những cổng nào được cho phép được điều khiển bởi các mô đun conntrack giao thức cụ thể.

Bằng cách cho phép các kết nối THÀNH LẬP và LIÊN QUAN, bạn có thể tập trung vào những kết nối mới mà bạn muốn tường lửa chấp nhận. Nó cũng tránh các quy tắc bị hỏng có nghĩa là cho phép lưu lượng truy cập trở lại, nhưng cho phép các kết nối mới.

Do bạn đã phân loại chương trình trên cổng 1337 là không an toàn, nên bắt đầu sử dụng id người dùng không phải root chuyên dụng. Điều này sẽ hạn chế thiệt hại mà ai đó có thể gây ra nếu họ quản lý để bẻ khóa ứng dụng của anh ta và có được quyền truy cập nâng cao.

Rất khó có thể sử dụng kết nối trên cổng 1337 để truy cập cổng 22 từ xa, nhưng có thể kết nối với cổng 1337 có thể được sử dụng để ủy quyền kết nối với cổng 22.

Bạn có thể muốn đảm bảo SSH được bảo mật chuyên sâu:

  • Sử dụng hosts.allow để giới hạn quyền truy cập bên cạnh các hạn chế tường lửa.
  • Ngăn chặn quyền truy cập gốc hoặc ít nhất yêu cầu sử dụng các khóa và giới hạn quyền truy cập của chúng trong tệp ủy quyền.
  • Kiểm toán đăng nhập thất bại. Một máy quét nhật ký có thể gửi cho bạn các báo cáo định kỳ về hoạt động bất thường.
  • Cân nhắc sử dụng một công cụ như fail2ban để tự động chặn truy cập trên các lỗi truy cập lặp lại.

Mặc dù đây là một ví dụ tùy ý, điều đầu tiên tôi làm trên các máy chủ mới là luôn vô hiệu hóa quyền truy cập root và xác thực bản rõ trong sshd - đó là một mẹo rất hay. Ngoài ra fail2ban thực sự đã được cài đặt trên thiết lập thực tế mà từ đó ví dụ được truyền cảm hứng. "Các kết nối được thành lập đã được xác nhận bởi một quy tắc khác" là điều chính xác mà tôi không chắc chắn và trả lời hoàn hảo câu hỏi của tôi. Cảm ơn câu trả lời rất rõ ràng của bạn!
Dencker

Câu hỏi bên lề: Từ góc độ hiệu suất, nó có thay đổi gì không nếu conntrackquy tắc nằm ở đầu hoặc cuối chuỗi? Theo cách tôi hiểu iptables, nó sẽ phải xử lý tất cả các quy tắc về các kết nối đã được thiết lập nếu cuối cùng và chỉ có quy tắc duy nhất đó nếu nó được đặt vào đầu?
Dencker

@Dencker Bạn muốn quy tắc THÀNH LẬP, LIÊN QUAN trước tiên. Nó sẽ chấp nhận cho đến nay lưu lượng truy cập nhiều nhất. Ngoài ra, bạn có thể muốn có các quy tắc chấp nhận lưu lượng truy cập nhiều nhất, mặc dù tốt nhất là cân nhắc nhiều để dễ đọc. Quy tắc của tôi được nhóm, độ trễ nhạy cảm, lưu lượng truy cập cao (được nhóm theo loại), các quy tắc khác. Iptables có các bộ đếm cho phép bạn xem lưu lượng truy cập mỗi quy tắc. Tôi sử dụng Shorewall, bổ sung một số giá trị mặc định hữu ích và có tệp quy tắc dễ đọc để xây dựng tường lửa của tôi.
BillThor

2

THÀNH LẬP và LIÊN QUAN là các tính năng của lọc gói "trạng thái", trong đó việc lọc không chỉ phụ thuộc vào bộ quy tắc tĩnh mà còn phụ thuộc vào ngữ cảnh, trong đó các gói được xem xét. Bạn cần THÀNH LẬP để cho phép các kết nối hoạt động và bạn cần LIÊN QUAN cho các tin nhắn ICMP có liên quan. Lọc trạng thái cho phép lọc chính xác hơn so với quy tắc "không trạng thái" tĩnh.

Trước tiên hãy nhìn vào THÀNH LẬP. Chẳng hạn, hãy xem xét TCP trên cổng 22. Bộ khởi tạo (máy khách) gửi SYNđến serverIPaddr:22. Máy chủ trả về SYN+ACKmáy khách. Bây giờ đến lượt khách hàng gửi một ACK. Quy tắc lọc trên máy chủ phải như thế nào, sao cho chỉ "khớp" ACKđược chấp nhận? Một quy tắc không quốc tịch chung sẽ như thế nào

-A INPUT --proto tcp --port 22 -j ACCEPT

đó là tự do hơn so với quy tắc nhà nước. Quy tắc không trạng thái cho phép các phân đoạn TCP tùy ý, ví dụ ACKhoặc FINkhông có thiết lập kết nối trước. Máy quét cổng có thể khai thác loại hành vi này để lấy dấu vân tay của hệ điều hành.

Bây giờ chúng ta hãy nhìn vào LIÊN QUAN. Điều này được sử dụng cho các tin nhắn ICMP, chủ yếu là các thông báo lỗi. Chẳng hạn, nếu một gói từ máy chủ đến máy khách bị hủy, thì một thông báo lỗi sẽ được gửi đến máy chủ. Thông báo lỗi này "liên quan" đến kết nối được thiết lập trước đó. Nếu không có quy tắc LIÊN QUAN, người ta sẽ cần phải cho phép các thông báo lỗi đến nói chung (không có ngữ cảnh) hoặc, tùy chỉnh cho nhiều trang web, bỏ hoàn toàn ICMP và chờ thời gian chờ trên lớp vận chuyển. (Lưu ý rằng đây là một ý tưởng tồi cho IPv6; ICMPv6 đóng vai trò quan trọng hơn đối với IPv6 so với ICMP đối với di sản IP.)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.