Чи можливо обмежити підключення до бази даних в контейнері Docker у конкретному інтерфейсі Ubuntu 16?

У мене на сервері база даних 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

— Роман Черепанов
джерело

Чи має ця робота для вас?

— Кевін

@Kevin, я опублікував би це як відповідь і цитую відповідну інформацію, а також відредагую інформацію, щоб відповідати його сценарію

— асміт

@Kevin Я спробував твою пораду, але порт все ще відкритий. Чи можете ви допомогти мені знайти помилку в моєму правилі чи дати мені поради щодо вирішення моєї проблеми (детальніше див. Оновлення запитань)?

— Роман Черепанов

Відповіді:

Замість використання ufwви можете прив’язати MySQL до одного єдиного інтерфейсу.

У файлі конфігурації mysqld (як правило, в /etc/mysql/my.cnf) є опція, bind-addressщо дозволяє вам встановити єдину IP-адресу (наприклад, 10.0.4.25), щоб змусити MySQL слухати лише цей інтерфейс.

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

— jcbermu
джерело

Це не обов’язково краще. Linux вважає IPv4 адреси власними, а не інтерфейсними, тому прив'язка до адреси не автоматично прив'язується до її інтерфейсу. (Останнє можливо, але потрібен окремий сокопт.) Тому, якщо хтось перебуває на тому ж посиланні, наприклад, інший сервер 146.xxx, він все одно може легко підключитися навіть до служб, пов'язаних з адресою іншого інтерфейсу. Тим часом правило брандмауера завжди буде працювати.

— grawity

@grawity У це дуже важко повірити.

— jcbermu

Чи не буде це перша людина , щоб сказати , що, і все ж я успішно кашель використовував це помилкова особливість в минулому ... Подивіться на «сильну модель господаря» (краще для IPv6) проти «слабкою моделі господаря» (загальний для IPv4) для отримання додаткової інформації. (За замовчуванням Linux навіть відповість на запити ARP в інтерфейсі "неправильно"; ви можете налаштувати це за допомогою arp_filter / arp_ignore, але навіть тоді доданий маршрут вручну або запис ARP все ще дозволяє з'єднання.)

— grawity

@grawity Ви праві. Я про це не знав. це дійсно правда, що ти щодня дізнаєшся щось нове . Я змінив свою відповідь, щоб включити її.

— jcbermu

Проблема полягала в тому, що Докер підробляє правила брандмауера.

Відповідно до цих публікацій ( Про небезпеку 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, це виправлення не працює.

— Роман Черепанов
джерело