Ограничение доступа к сети контейнера Docker

Я нахожусь в процессе создания контейнера Docker только для SFTP , который будет использоваться несколькими людьми с единственной целью загрузки и управления файлами в их собственной chrootсреде.

На бумаге это довольно безопасно: я отключу любую форму bashвхода в систему и не буду запускать в ней другие процессы. Однако я хотел бы укрепить это немного больше:

Я хочу запретить этому контейнеру доступ к Интернету изнутри, за исключением того, что он является сервером SFTP.

Чтобы прояснить ситуацию: я знаю, как запретить доступ внешнего контейнера к моему контейнеру - я могу настроить входящие iptablesправила и выставить только порт SFTP в моей команде запуска docker.

Однако я хотел бы, чтобы следующая команда (в качестве примера) не выполнялась при запуске внутри контейнера:

curl google.com

Мое намерение состоит в том, чтобы уменьшить количество повреждений, которые может нанести взломанный контейнер (невозможность использовать его для рассылки спама и т. Д.).

Все еще имеет смысл поместить некоторые входные правила в ваш экземпляр докера, чтобы помочь предотвратить атаки, но вам придется ограничить исходящий (Интернет) доступ с любого вышестоящего маршрутизатора, с которым связывается образ докера. Причина этого в том, что если вы попытаетесь заблокировать исходящий доступ с помощью правил брандмауэра внутри вашего экземпляра, то, если экземпляр скомпрометирован, эти правила могут быть удалены злоумышленником. Блокируя выход через маршрутизатор экземпляра, вы блокируете исходящий доступ даже в случае компрометации - злоумышленнику также придется взломать маршрутизатор.

Итак, после получения некоторого комментария, объясняющего, что фильтрация была предназначена для хоста контейнера, становится немного яснее, что пытается быть выполнено. В этом случае на хосте вы бы добавили некоторые правила, подобные этому:

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

Первые два правила предназначены для доступа между хостом и контейнером. Третье правило гласит (грубо), что все, что не является подсетью хоста, направленной на SFTP, просто в порядке; четвертое - исходящее правило, которое в основном является близнецом к третьему; пятое правило - универсальное (в случае, если используются другие связанные порты), хотя это не нужно, вы можете удалить его; последнее правило заключается в том, что он предотвращает доступ ко всему, кроме подсети хоста. Поскольку доступ предоставляется в первых нескольких правилах, он никогда не сработает, если не применяется ни одно из предыдущих правил, и в этом случае мы говорим: «нам все равно, что вы хотите, вы не соответствуете тому, на что вы одобрены», так что ты не сможешь добраться отсюда ". Входящий трафик извне будет удовлетворяться 3-м и 4-м правилами.

На самом деле это не проблема докера. Есть несколько способов решить эту проблему.

1. Используйте iptablesправила с отслеживанием состояния, чтобы разрешить соединения входящим и связанным / установленным трафиком, а затем блокировать все остальное.

2. Используйте только службу sftp , такую ​​как ProFTPD, которая не способна запустить оболочку.

В общем, если вы не разрешаете своим пользователям получать оболочку и не позволяете им запускать программы из контейнера, вам не нужно об этом беспокоиться.

Это просто быстрый мозговой штурм, и я еще не проверял его. Вы захотите проверить это в лаборатории, прежде чем приступить к производству.

Чтобы предотвратить исходящий трафик через не-SSH (SFTP) и веб-порты, вы можете применить политику через IPTABLES или другой брандмауэр Layer4 к трафику DROP или REJECT, полученному из сегмента, используемого контейнерами Docker, предназначенными для 0.0.0.0/0, за исключением случаев, когда пункт назначения Порт TCP22.

Чтобы решить проблему с переходом к «неутвержденным местам в сети», вы можете попытаться настроить экземпляр фильтрующего / кэширующего прокси-сервера, такого как squid или bluecoat, который прослушивает интерфейс docker0 и использует маршрут дефолта хозяина, чтобы выйти в интернет. Оттуда вы можете применить политику, основанную на многих критериях, а также сэкономить использование сети за счет кэширования статического содержимого. Возможно, вы захотите использовать NAT (я думаю, IPTABLES и Masquerade предоставляют это в Linux) на хост-машине для прозрачного принудительного использования прокси-сервера (я описал это в своем ответе на запрос на использование прокси-сервера только HTTP, но я не уверен, что делать с трафиком HTTPS ). Это означает, что у вас должна быть причина для выхода в Интернет, в первую очередь, в соответствии с политикой вашей компании.

Из-за характера SSH (на котором основан SFTP) вы не сможете обеспечить запрет трафика для перемещения файлов, если не внедрите политику, согласно которой контейнеры могут использовать только пары ключей, предоставленные вами. Это хорошо для вас, потому что дает вам некоторое «У меня не было видимости или контроля над переданными файлами«Защита, если один из ваших клиентов передает что-то незаконное (например, нарушение прав ИС, или использует ваш сервис для отфильтровывания информации, несущей классификационный ярлык, или они торгуют CP), если вы предстали перед судом за то, что ваши клиенты делают (подумайте, что статус общего оператора для операторов связи). Это плохо для вас, потому что вы не можете кэшировать часто повторно переданные, неизмененные файлы, и потому что любая политика, которую вы пишете в договоре с вашими клиентами, будет по существу неосуществима техническими средствами.