Hạn chế quyền truy cập mạng của container Docker

Tôi đang trong quá trình tạo một bộ chứa Docker chỉ SFTP , một bộ chứa sẽ được nhiều người sử dụng cho mục đích duy nhất là tải lên và quản lý các tệp trong chrootMôi trường ed của riêng họ .

Trên giấy tờ, nó khá an toàn: Tôi sẽ vô hiệu hóa mọi hình thức bashđăng nhập và tôi sẽ không chạy bất kỳ quy trình nào khác trong đó. Tuy nhiên tôi muốn làm cứng nó thêm một chút nữa:

Tôi muốn ngăn container này truy cập Internet từ bên trong, ngoại trừ mục đích trở thành máy chủ SFTP.

Để làm cho mọi thứ rõ ràng: Tôi biết cách ngăn thế giới bên ngoài truy cập vào container của mình - Tôi có thể thiết lập các iptablesquy tắc đến và tôi chỉ có thể hiển thị cổng SFTP trong lệnh chạy docker của mình.

Tuy nhiên, tôi muốn thực hiện lệnh sau (ví dụ) không thành công, khi chạy bên trong container:

curl google.com

Ý định của tôi là giảm bớt thiệt hại mà một container bị hack có thể gây ra (không thể sử dụng để gửi email spam, v.v.).

Sẽ vẫn hợp lý khi đặt một số quy tắc xâm nhập vào trong ví dụ docker của bạn để giúp tránh các cuộc tấn công, nhưng bạn sẽ phải hạn chế truy cập ra ngoài (Internet) từ bất kỳ bộ định tuyến ngược nào mà hình ảnh docker kết nối với. Lý do cho điều này là, nếu bạn cố gắng chặn truy cập ra bên ngoài với các quy tắc tường lửa bên trong cá thể của bạn, thì nếu cá thể đó bị xâm phạm, những quy tắc đó có thể bị kẻ tấn công loại bỏ. Bằng cách chặn đi ra qua bộ định tuyến của cá thể, bạn chặn truy cập ra ngoài ngay cả trong trường hợp thỏa hiệp - kẻ tấn công cũng sẽ phải thỏa hiệp với bộ định tuyến.

Ok, vì vậy sau khi nhận được một số bình luận giải thích rằng bộ lọc được dành cho máy chủ chứa, rõ ràng hơn một chút những gì đang cố gắng thực hiện. Trong trường hợp đó, trên máy chủ, bạn sẽ thêm một số quy tắc tương tự như sau:

iptables -A FORWARD -s lo.cal.sub.net -d con.tai.ner.ip -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d lo.cal.sub.net -j ACCEPT
iptables -A FORWARD -s ! lo.cal.sub.net -d con.tai.ner.ip -p tcp --dport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d ! lo.cal.sub.net -p tcp --sport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -m state --state related,established -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -j DROP

Hai quy tắc đầu tiên là để truy cập giữa máy chủ và container. Quy tắc thứ ba nói (đại khái) rằng bất cứ điều gì không phải là mạng con của máy chủ lưu trữ cho SFTP đều ổn đối với chúng tôi; thứ tư là quy tắc hướng ngoại về cơ bản là sinh đôi với thứ ba; quy tắc thứ năm là bắt tất cả (trong trường hợp có các cổng liên quan khác được sử dụng), mặc dù không cần thiết, bạn có thể loại bỏ nó; quy tắc cuối cùng là phép thuật ngăn chặn truy cập vào bất cứ thứ gì ngoài mạng con máy chủ. Vì quyền truy cập được đưa ra trong một vài quy tắc đầu tiên, nên nó sẽ không bao giờ kích hoạt trừ khi không áp dụng quy tắc nào trước đó, trong trường hợp chúng tôi đang nói "chúng tôi không quan tâm bạn muốn gì, bạn không khớp với bất cứ điều gì bạn chấp nhận, vì vậy bạn không thể đến đó từ đây ". Lưu lượng truy cập từ bên ngoài sẽ được thỏa mãn theo quy tắc thứ 3 và thứ 4.

Đây không thực sự là một vấn đề cụ thể của docker. Có một vài cách bạn có thể giải quyết điều này.

1. Sử dụng các iptablesquy tắc trạng thái để cho phép kết nối lưu lượng truy cập trong nước và liên quan / thành lập sau đó chặn mọi thứ khác.

2. Sử dụng dịch vụ chỉ sftp như ProFTPD không có khả năng chạy shell.

Nói chung, nếu bạn không cho phép người dùng của mình lấy vỏ và không cho phép họ chạy các chương trình từ trong container, bạn không cần phải lo lắng về điều đó.

Đây chỉ là một động não nhanh chóng và tôi chưa thử nghiệm nó. Bạn sẽ muốn kiểm tra nó trong phòng thí nghiệm trước khi đưa nó vào sản xuất.

Để ngăn chặn lưu lượng truy cập đi ra ngoài trên các cổng không phải SSH (SFTP) và Web, bạn có thể muốn áp dụng chính sách qua IPTABLES hoặc tường lửa lớp 4 khác cho lưu lượng truy cập DROP hoặc RE DỰA từ phân đoạn được sử dụng bởi các bộ chứa docker được chuyển đến 0,0.0.0 / 0 trừ khi Đích đến Cổng là TCP22.

Để giải quyết vấn đề sắp xảy ra trên web, bạn có thể muốn thử thiết lập một thể hiện của proxy lọc / bộ nhớ đệm, chẳng hạn như mực hoặc bluecoat, đang nghe trên giao diện docker0 và đang sử dụng tuyến đường của chủ nhà để truy cập internet. Từ đó, bạn có thể áp dụng chính sách dựa trên nhiều tiêu chí, cũng như tiết kiệm việc sử dụng mạng bằng cách lưu trữ nội dung tĩnh. Bạn có thể muốn sử dụng NAT (Tôi nghĩ IPTABLES và masage cung cấp điều này trong Linux) trên máy chủ để thực thi việc sử dụng proxy một cách minh bạch (Tôi đã mô tả điều này trong phản hồi của mình với tôi chỉ muốn proxy nhưng tôi không biết phải làm gì làm với lưu lượng HTTPS ). Điều này ngụ ý có một lý do để truy cập web ở nơi đầu tiên tuân thủ chính sách của công ty bạn.

Do bản chất của SSH (dựa trên SFTP), bạn sẽ không thể cung cấp lưu lượng truy cập cho việc di chuyển tệp trừ khi bạn thực hiện chính sách trong đó các container chỉ có thể sử dụng các cặp khóa do bạn cung cấp. Điều này tốt cho bạn, vì nó mang đến cho bạn một số " Tôi không có khả năng hiển thị hoặc kiểm soát các tệp được chuyển"bảo vệ nếu một trong những khách hàng của bạn chuyển một thứ gì đó bất hợp pháp (chẳng hạn như vi phạm IP hoặc sử dụng dịch vụ của bạn để làm lộ thông tin mang nhãn phân loại hoặc họ giao dịch bằng CP), nếu bạn bị đưa ra tòa vì những điều khách hàng của bạn làm (nghĩ là không phù hợp với Tình trạng nhà cung cấp chung cho công ty viễn thông) Điều này không tốt cho bạn vì bạn không thể lưu lại bộ đệm thường xuyên, các tệp không thay đổi và bởi vì bất kỳ chính sách nào bạn ghi trong hợp đồng với khách hàng về cơ bản sẽ không thể thực hiện được thông qua các phương tiện kỹ thuật.