Обмеження доступу до мережі контейнера Docker

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

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

Я хочу не допустити доступу до цього контейнера з Інтернету зсередини, за винятком того, що він має бути SFTP-сервером.

Щоб зрозуміти: я знаю, як не допустити доступу до мого контейнера зовнішнього світу - я можу налаштувати вхідні iptablesправила, і я можу виставити лише порт 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-м правилами.

Це насправді не конкретна проблема для докера. Є кілька способів вирішити це.

1. Використовуйте загальнодоступні iptablesправила, щоб дозволити вхідні зв’язки та пов'язаний / встановлений трафік, а потім заблокувати все інше.

2. Використовуйте лише службу sftp, наприклад ProFTPD, яка не може запускати оболонку.

Загалом, якщо ви не дозволяєте своїм користувачам отримувати оболонку і не дозволяєте їм запускати програми з контейнера, вам не потрібно про це турбуватися.

Це просто швидкий мозковий штурм, і я його ще не перевіряв. Ви захочете перевірити його в лабораторії, перш ніж взяти його на виробництво.

Щоб запобігти вихідному трафіку на не-SSH (SFTP) та веб-порти, ви можете застосувати політику через IPTABLES або інший брандмауер Layer4 до DROP або ОТМЕНИТИ трафік, отриманий з сегмента, використовуваного контейнерами докера, призначеними до 0,0.0,0/0, за винятком випадків, коли призначення Порт - TCP22.

Щоб вирішити проблему переходу до неприйняття місць в Інтернеті, ви можете спробувати встановити екземпляр проксі-фільтра фільтрування / кешування, наприклад, кальмара або синього пальто, який прослуховується на інтерфейсі docker0 і який використовується маршрутом дефалт господаря, щоб вийти в Інтернет. Звідти ви можете застосувати політику, засновану на багатьох критеріях, а також зберегти використання мережі шляхом кешування статичного вмісту. Можливо, ви хочете використовувати NAT (я думаю, що IPTABLES і Masquerade надають це в Linux) на хост-машині, щоб забезпечити використання проксі-сервера прозоро (я описав це у своїй відповіді на те, що я хочу прокси лише HTTP, але я не впевнений, що робити робити з трафіком HTTPS ). Це означає, що є причина перейти в Інтернет в першу чергу, що відповідає політиці вашої компанії.

Через природу SSH (на якій базується SFTP), ви не зможете забезпечити заборону трафіку для переміщення файлів, якщо не реалізуєте політику, згідно з якою контейнери можуть використовувати лише надані вами пари ключів. Це добре для вас, оскільки воно дає вам певну " Я не мав видимості та контролю над переданими файлами"захист, якщо хтось із ваших клієнтів передає щось незаконне (наприклад, порушення прав інтелектуальної власності) або використовує вашу послугу для уточнення інформації, що містить етикетку класифікації, або вони торгують CP), якщо вас притягують до суду за те, що роблять ваші клієнти (вважайте аналогічним загальний статус оператора для телефонів) Це погано для вас, оскільки ви не можете часто кешувати повторно передані, незмінені файли, а тому, що будь-яка політика, яку ви вписуєте в контракт зі своїми клієнтами, буде, по суті, невиконаною через технічні засоби.