docker iptables

Сегодня рассмотрим как защитить порты докера от доступа из интернета при помощи фаервола. Конечно настройка будет происходить при помощи iptables.

Вводные

Для применения правила в Ubuntu при помощи iptables используется пакет iptables-persistent.

Ну как используется. iptables-persistent нам нужен что бы правила применялись при старте системы.
Ничего нового скорее всего я не расскажу для тех кто уже знает как использовать iptables. Для тех же кто не знает статейка думаю будет полезной.

Итак, вводные. Представим что у нас есть хост, с установленным докером. И мы хотим что бы доступ по ssh, был только с адреса 67.98.32.122, доступ к портам 8080 и 8231 был с адреса 65.72.33.12, порты 80 и 443 были открыты для всех, а так же все порты открыты для адрес 132.75.14.52. Остальное отбрасываем. Все адреса вымышленные.

Табличка:


Адрес Правило
132.75.14.52 доступны все порты
67.98.32.122 только ссш (22 tcp порт)
65.72.33.12 tcp 8080 и 8231
любой tcp 80 и 443

После установки iptables-persistent у нас появляется папочка /etc/iptables, в которой мы можем создать, а может и уже лежит файл rules.v4

Заполняем его следующим образом:

Теперь пару слов о том что мы написали:

  1. Все правила в iptables применяются сверху вниз. При первом совпадении, проверка дальше не идёт.
  2. Докер фильтруется по цепочке DOCKER-USER. Об этом написано в документации.
  3. Мы создали свою цепочку chain-access. Правила в этой цепочке будут применены как к INPUT так и к DOCKER-USER. Я сделал эту цепочку для простоты и удобства.
  4. Правила из /etc/iptables/rules.v4 применяются только при старте и только для IPv4.
  5.  eno1 — имя внешнего сетевого интерфейса (посмотреть имена можно командой ip a )

Дополнение

При работающих сервисах в докере применить правила не получится (перетрёт правила которые создались докером). Поэтому самый простой вариант это перезагрузка. Либо применение правил, а затем перезапуск докера демона.

применение:

докер:

После того как правила будут применены (например после ребута). Мы можем добавлять свои правила в цепочку chain-access без перезагрузки. Например добавим правило разрешающее для адреса 33.89.09.12 диапазон портов с 1000 по 1100.

и дублируем правило в файле /etc/iptables/rules.v4.

Так же не лишним будет запретить IPv6:

Для просмотра действующих правил можем использовать команду iptables-save.

На сегодня это всё, если есть вопросы — пишите в комментариях ниже. Постараюсь ответить.

  • Александр Кузьмин

    У меня история с докером такая все что вы написали работает с 22 портом на закрытие и открытие для определенных нужных мне хостов. Но вот у меня например 444 порт работает phpmyadmin он переадресовывается на 80 так вот не срабатывает по вашей статье то есть никак не контролится 444. Так что то думал думал и вот что придумал дописать вообще до докера все в самом начале. Добавить в /etc/iptables/rules.v4 Следующее:
    *raw
    -A PREROUTING -p tcp —dport 444 -s blblabla1.dyndns.org -j ACCEPT
    -A PREROUTING -p tcp —dport 444 -s blblabla2.dyndns.org -j ACCEPT
    -A PREROUTING -p tcp —dport 444 -j DROP
    COMMIT
    Получилось!!! Да и спасибо за вашу статью все очень элегантно и я это применил!!!

    • http://vk.com/id3942838 Алексей Варич

      Не совсем понял про переадресацию с 444 на 80, возможно в этом проблемка. У меня пока не было случаев что бы эти правила не сработали, хотя nmap’ом мониторю некоторые хосты, что бы чего не случилось.

  • Секреты Стива

    Я конечно понимаю что 17 строчка блокирует всё остальное, но почему политика INPUT (и FORWARD) не DROP?

    • http://vk.com/id3942838 Алексей Варич

      Правила в статье запрещают трафик только на одном интерфейсе, если выставить input drop будет запрещаться трафик на всех интерфейсах (в т.ч. и lo — loopback), что сильно усложняет весь процесс. По forward хорошее замечание, но мне как правило лень, увы.

Комментарии для сайта Cackle