Можно ли ограничить подключение к базе данных в контейнере Docker на конкретном интерфейсе в Ubuntu 16?

693
Roman Cherepanov

У меня есть база данных MySQL на сервере (я использую Percona в контейнере Docker ) с несколькими сетевыми интерфейсами.

Моя система Ubuntu 16.04.2 LTS .

ifconfig  eth0 Link encap:... inet addr:95.*.*.*  eth1 Link encap:... inet addr:10.*.*.* 

Можно ли ограничить доступ ufwк базе данных на eth0интерфейсе, но разрешить eth1?

Таким образом, он будет иметь доступ к БД с 10.*.*.*:6603и не сможет получить доступ с 95.*.*.*:6603.

Обновление (04.03.2017):

Я использовал эту команду, чтобы добавить правило:

sudo ufw deny in on eth0 to any port 6603 from any proto tcp 

Статус:

$ sudo ufw status Status: active  To Action From -- ------ ---- 6603/tcp on eth0 DENY Anywhere 6603/tcp (v6) on eth0 DENY Anywhere (v6) 

Но я, несмотря на отрицание правила, могу войти в свою БД с MySQLклиентом.

Но 6603порт все еще открыт:

nmap -p 6603 95.85.54.75  Starting Nmap 7.01 ( https://nmap.org ) at 2017-03-04 16:14 UTC Nmap scan report for 95.85.54.75 Host is up (0.0012s latency). PORT STATE SERVICE 6603/tcp open unknown  Nmap done: 1 IP address (1 host up) scanned in 0.65 seconds 
2
Работает ли [это] (http://serverfault.com/questions/270715/ubuntu-ufw-set-a-rule-on-a-per-interface-basis)? Kevin 7 лет назад 3
@Kevin, я бы опубликовал это как ответ и процитировал бы соответствующую информацию, а также отредактировал информацию, чтобы соответствовать его сценарию asmith 7 лет назад 1
@Kevin Я попробовал твой совет, но порт все еще открыт. Можете ли вы помочь мне найти ошибку в моем правиле или дать совет по решению моей проблемы (подробности см. В обновлениях вопросов)? Roman Cherepanov 7 лет назад 0

2 ответа на вопрос

1
jcbermu

Вместо использования ufwвы можете привязать MySQL к одному интерфейсу.

В файле конфигурации mysqld (обычно в /etc/mysql/my.cnf) есть опция, bind-addressкоторая позволяет вам задать один IP-адрес (например, 10.0.4.25), чтобы MySQL прослушивал только этот интерфейс.

Однако это не является пуленепробиваемым решением, поскольку на хостах, использующих модель слабого хоста (например, некоторые дистрибутивы Linux), можно подключаться к сервисам, привязанным к одному интерфейсу из другого.

Это не обязательно лучше. Linux считает, что адреса IPv4 принадлежат хосту, а не интерфейсу, поэтому привязка к адресу _не_ автоматически связывается с его интерфейсом. (Последнее возможно, но требует отдельного sockopt.) Поэтому, если кто-то находится на той же ссылке, например, на другом сервере 146.xxx, он все равно может легко подключаться даже к службам, привязанным к адресу другого интерфейса. Тем временем правило брандмауэра всегда будет работать. grawity 7 лет назад 1
@ Grawity В тебя очень трудно поверить. jcbermu 7 лет назад 0
Не будет первым, кто скажет это, и все же я успешно * кашлял * использовал эту ошибку в прошлом ... Взгляните на "модель сильного хоста" (предпочтительнее для IPv6) против "модели слабого хоста" ( общий для IPv4) для получения дополнительной информации. (По умолчанию Linux даже отвечает на запросы ARP на «неправильном» интерфейсе; вы можете настроить это с помощью arp_filter / arp_ignore, но даже тогда добавленный вручную маршрут или запись ARP по-прежнему разрешает соединения.) grawity 7 лет назад 1
@ grawity Вы правы. Я не знал об этом. Это правда, что * Вы узнаете что-то новое каждый день *. Я изменил свой ответ, чтобы включить это. jcbermu 7 лет назад 0
1
Roman Cherepanov

Проблема заключалась в том, что Docker вмешивался в правила брандмауэра.

Согласно этим постам ( Опасность UFW + Docker, Как настроить Docker 1.12+, чтобы НЕ мешать IPTABLES / FirewallD ):

  • Я создал файл /etc/docker/daemon.jsonс содержанием:

    { "iptables": false } 
  • Я добавил правило в UFW:

    sudo ufw allow in on eth1 to any port 6603 

    разрешить соединения только от UFW.

  • перезагрузить демон докера

    sudo service docker stop sudo service docker start 

Примечание: это исправление работает только для контейнеров, созданных с помощью docker run.... Для контейнеров, созданных с помощью Docker Swarm, это исправление не работает.