Можно ли ограничить подключение к базе данных в контейнере 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
Работает ли [это] (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 вмешивался в правила брандмауэра.
Я создал файл /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, это исправление не работает.