Я создаю только SFTP Докер контейнер, который будет использоваться несколькими людьми с единственной целью - загружать файлы и управлять ими самостоятельно. chroot
ed Environment.
На бумаге это довольно безопасно: я отключу все формы bash
войдите, и я не буду запускать в нем другие процессы. Однако я бы хотел еще немного его усилить:
Я хочу запретить этому контейнеру доступ в Интернет изнутри, за исключением того, что он является сервером SFTP.
Чтобы прояснить ситуацию: я знаю, как предотвратить доступ внешнего мира к моему контейнеру - я могу настроить входящие iptables
rules, и я могу открыть только порт SFTP в моей команде запуска докера.
Однако я хотел бы, чтобы следующая команда (в качестве примера) завершилась ошибкой при запуске внутри контейнер:
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-м правилами.
На самом деле это не проблема докеров. Есть несколько способов решить эту проблему.
Используйте с отслеживанием состояния iptables
правила, чтобы разрешить входящие соединения и связанный / установленный трафик, а затем заблокировать все остальное.
Используйте только службу sftp, например ProFTPD который не может запустить оболочку.
В общем, если вы не разрешаете своим пользователям получать оболочку и не позволяете им запускать программы из контейнера, вам не нужно об этом беспокоиться.
Это просто быстрый мозговой штурм, и я его еще не тестировал. Вам нужно будет проверить его в лаборатории, прежде чем отправлять в производство.
Чтобы предотвратить исходящий трафик на не-SSH (SFTP) и веб-портах, вы можете применить политику через IPTABLES или другой брандмауэр Layer4 для DROP или REJECT трафика, полученного из сегмента, используемого контейнерами докеров, предназначенными для 0.0.0.0/0, за исключением случаев, когда пункт назначения Порт - TCP22.
Чтобы решить проблему с отказом от одобрения мест в сети, вы можете попробовать настроить экземпляр прокси-сервера для фильтрации / кеширования, например squid или bluecoat, который прослушивает интерфейс docker0 и использует маршрут по умолчанию для выхода в Интернет. Оттуда вы можете применять политику на основе многих критериев, а также экономить использование сети за счет кэширования статического содержимого. Возможно, вы захотите использовать NAT (я думаю, что IPTABLES и Masquerade предоставляют это в Linux) на хост-машине, чтобы обеспечить прозрачное использование прокси (я описал это в своем ответе на Я хочу использовать только HTTP-прокси, но не знаю, что делать с HTTPS-трафиком). Это означает, что у вас есть причина для выхода в Интернет, в первую очередь, которая соответствует политике вашей компании.
Из-за характера SSH (на котором основан SFTP) вы не сможете обеспечить запрет трафика для перемещения файлов, если не реализуете политику, согласно которой контейнеры могут использовать только предоставленные вами пары ключей. Это хорошо для вас, потому что дает "Я не мог видеть и контролировать переданные файлы"защита, если один из ваших клиентов передает что-то незаконное (например, нарушение прав интеллектуальной собственности, или использует вашу службу для кражи информации с классификационной меткой, или они торгуют CP), если вас привлекли к суду за то, что ваши клиенты сделали (подумайте аналогично статус общего оператора для телекоммуникационных компаний). Это плохо для вас, потому что вы не можете кэшировать часто повторно передаваемые неизмененные файлы, а также потому, что любая политика, которую вы прописываете в контракте с вашими клиентами, будет практически неосуществимой с помощью технических средств.