È possibile limitare la connessione al database nel contenitore Docker su una particolare interfaccia su Ubuntu 16?

Ho un database MySQL su un server (io uso Percona nel docker contenitore) con diverse interfacce di rete.

Il mio sistema è Ubuntu 16.04.2 LTS .

ifconfig

eth0      Link encap:...
          inet addr:95.*.*.*

eth1      Link encap:...
          inet addr:10.*.*.*

È possibile limitare l'accesso con ufw a un database su eth0 interfaccia ma permetti eth1?

Quindi sarà in grado di accedere a DB con 10.*.*.*:6603 e non sarà in grado di accedere con 95.*.*.*:6603.

Aggiornamento (04.03.2017):

Ho usato questo comando per aggiungere una regola:

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

Stato:

$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
6603/tcp on eth0           DENY        Anywhere
6603/tcp (v6) on eth0      DENY        Anywhere (v6)

Ma nonostante io neghi la regola, posso accedere al mio DB con MySQL cliente.

Ma 6603 la porta è ancora aperta:

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

— Roman Cherepanov
fonte

fa Questo Lavoro per te?

— Kevin

@ Kevin, vorrei postare questo come una risposta e citare le informazioni pertinenti, e anche modificare le informazioni per adattarsi al suo scenario

— asmith

@Kevin ho provato il tuo consiglio ma la porta è ancora aperta. Potete aiutarmi a trovare un errore nella mia regola o darmi consigli per risolvere il mio problema (vedi gli aggiornamenti delle domande per i dettagli)?

— Roman Cherepanov

Risposte:

Invece di usare ufw, puoi collegare MySQL ad una singola interfaccia.

Il file di configurazione mysql (di solito a /etc/mysql/my.cnf ) ha un'opzione chiamata bind-address che ti consente di impostare un singolo indirizzo IP (ad esempio 10.0.4.25) per forzare MySQL ad ascoltare solo su quell'interfaccia.

Tuttavia non è una soluzione a prova di proiettile, perché negli host che usano il modello ospite debole (come alcune distribuzioni di Linux) è possibile connettersi a servizi collegati su un'interfaccia da un'altra.

— jcbermu
fonte

Questo non è necessariamente migliore. Linux considera gli indirizzi IPv4 come di proprietà dell'host, non di proprietà dell'interfaccia, quindi vincolanti per un indirizzo non si collega automaticamente alla sua interfaccia. (Quest'ultimo è possibile ma richiede un sockopt separato). Pertanto, se qualcuno si trova sullo stesso link, ad es. un altro 146.x.x.x. server, quindi possono ancora connettersi facilmente anche a servizi legati ad un altro indirizzo di interfaccia. Nel frattempo, una regola del firewall lo farà sempre lavoro.

— grawity

@grawity È molto difficile crederti.

— jcbermu

Non sarebbe la prima persona a dirlo, eppure ho avuto successo tosse usato quella disfunzione in passato ... Date un'occhiata al "modello di host forte" (preferito per IPv6) vs "modello di host debole" (comune per IPv4) per ulteriori informazioni. (Di default, Linux risponde anche alle query ARP sull'interfaccia 'sbagliata', puoi regolarlo con arp_filter / arp_ignore, ma anche in questo caso una rotta ARP o aggiunta manualmente consente ancora le connessioni.)

— grawity

@grawity Hai ragione. Non lo sapevo. è proprio vero Si impara qualcosa di nuovo ogni giorno . Ho modificato la mia risposta per includerla.

— jcbermu

Il problema era che Docker manomette le regole del firewall.

Secondo questi post ( I pericoli di UFW + Docker , Come impostare Docker 1.12+ per NON interferire con IPTABLES / FirewallD ):

Ho creato il file /etc/docker/daemon.json con contenuto:
```
{
    "iptables": false
}
```
Ho aggiunto la regola per ufw:
```
sudo ufw allow in on eth1 to any port 6603 
```
per consentire le connessioni solo da ufw.

riavviare il daemon docker

sudo service docker stop
sudo service docker start

Nota: questa correzione funziona solo per i contenitori creati con docker run.... Per i contenitori creati con Docker Swarm questa correzione non funziona.

— Roman Cherepanov
fonte