Quelle est la meilleure pratique de docker + ufw sous Ubuntu

Problème

Ce problème a été autour pendant un long moment.

Désactiver iptables dans le Panneau prendra d'autres problèmes.

Annulation des modifications première

Si vous avez modifié votre serveur en fonction de la solution actuelle que nous trouvons sur internet, veuillez restauration de ces changements, y compris:

• Activer le Panneau de iptables fonctionnalité.
  Supprimer toutes les modifications comme --iptables=false , y compris le fichier de configuration /etc/docker/daemon.json.
• UFW par défaut de la règle d'changements à la valeur par défaut DROP au lieu de ACCEPT.
• Supprimer les règles relatives à la Docker réseau dans le UFW fichier de configuration /etc/ufw/after.rules.
• Si vous avez modifié le Panneau fichiers de configuration, redémarrez Docker en premier. Nous allons modifier le UFW de configuration plus tard, et nous pouvons redémarrer ensuite.

La résolution de UFW et Docker questions

Cette solution a besoin de modifier un seul UFW fichier de configuration, tous les Panneau de configurations et d'options par défaut. N'a pas besoin de désactiver le menu fixe iptables fonction.

Modifier le UFW fichier de configuration /etc/ufw/after.rules et ajouter les règles suivantes à la fin du fichier:

# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

-A DOCKER-USER -j ufw-user-forward

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER

L'aide de la commande sudo systemctl restart ufw redémarrer UFW après la modification du fichier. Maintenant, le réseau public ne peut pas accéder à la publication de docker ports, le conteneur et le réseau privé peuvent se rendre visite régulièrement, et les récipients peuvent également accéder au réseau externe de l'intérieur.

Si vous souhaitez autoriser les réseaux publics d'accéder aux services fournis par le conteneur Docker, par exemple, le port de service d'un conteneur est 80. Exécutez la commande suivante pour permettre au public de réseaux pour accéder à ce service:

ufw route allow proto tcp from any to any port 80

Cette commande permet au réseau public d'accéder à toutes les publications, les ports dont le port à conteneurs est de 80.

Remarque: Si nous publions un port à l'aide de l'option -p 8080:80, nous devrions utiliser le port à conteneurs 80, pas le port de l'hôte 8080.

Si il y a de multiples récipients avec un port de service de 80, mais nous voulons seulement le réseau externe pour accéder à un conteneur particulier. Par exemple, si l'adresse privée du conteneur est 172.17.0.2, utilisez la commande suivante:

ufw route allow proto tcp from any to 172.17.0.2 port 80

Si le protocole de réseau de service est UDP, par exemple, un service de DNS, vous pouvez utiliser la commande suivante pour permettre au réseau externe pour accéder à toutes les publications, les services DNS:

ufw route allow proto udp from any to any port 53

De même, si seulement pour un conteneur spécifique, tels que l'adresse IP 172.17.0.2:

ufw route allow proto udp from any to 172.17.0.2 port 53

Comment ça marche?

Les règles suivantes permettent les réseaux privés pour être en mesure de visiter les uns les autres. Généralement, les réseaux privés sont plus fiables que les réseaux publics.

-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

Les règles suivantes permettent de UFW à gérer si les réseaux publics sont autorisés à visiter les services fournis par le conteneur Docker. De sorte que nous pouvons gérer toutes les règles de pare-feu dans un seul endroit.

-A DOCKER-USER -j ufw-user-forward

Les règles suivantes bloquer les demandes de connexion initiée par tous les réseaux publics, mais de permettre à l'intérieur des réseaux d'accès à des réseaux externes. Pour le protocole TCP, il empêche activement à l'établissement d'une connexion TCP à partir des réseaux publics. Pour le protocole UDP, tous les accès aux ports qui est à moins de 32767 sont bloqués. Pourquoi est-ce port? Depuis le protocole UDP est apatride, il n'est pas possible de bloquer la poignée de main du signal qui déclenche la demande de connexion TCP n'. Pour GNU/Linux, nous pouvons trouver le local de la plage de port dans le fichier /proc/sys/net/ipv4/ip_local_port_range. La plage par défaut est 32768 60999. Lorsque vous accédez à un protocole UDP service de l'exécution d'un conteneur, le port local sera choisi au hasard l'un à partir de la plage de port, et le serveur va renvoyer les données à ce port aléatoire. Par conséquent, nous pouvons supposer que le port d'écoute du protocole UDP à l'intérieur de tous les contenants de moins de 32768. C'est la raison pour laquelle nous ne voulons pas de réseaux publics pour l'accès aux ports UDP moins de 32768.

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN

Plus

https://github.com/chaifeng/ufw-docker

sudo wget -O /usr/local/bin/ufw-docker https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker
chmod +x /usr/local/bin/ufw-docker

D'utilisation

ufw-docker help
ufw-docker install
ufw-docker status
ufw-docker allow webapp
ufw-docker allow webapp 80
ufw-docker allow webapp 53/udp
ufw-docker list webapp
ufw-docker delete allow webapp 80/tcp
ufw-docker delete allow webapp

---

Mise à jour: 2018-09-10

La raison du choix de ufw-user-forward, pas ufw-user-input

à l'aide de ufw-user-input

Pro:

Facile à utiliser et à comprendre, prend en charge les anciennes versions d'Ubuntu.

Par exemple, pour autoriser le public à visiter un port publié dont le port à conteneurs est 8080, utilisez la commande:

ufw allow 8080

Con:

Il n'expose pas seulement les ports de conteneurs, mais expose également les ports de l'hôte.

Par exemple, si un service est en cours d'exécution sur l'hôte et le port est 8080. La commande ufw allow 8080 permet au réseau public de visiter le service et publiés tous les ports dont les conteneurs de port est 8080. Mais nous voulons exposer le service en cours d'exécution sur l'hôte, ou tout simplement le service en cours d'exécution à l'intérieur de conteneurs, pas les deux à la fois.

Pour éviter ce problème, nous avons peut-être besoin d'utiliser une commande semblable à la suivante pour tous les conteneurs:

ufw allow proto tcp from any to 172.16.0.3 port 8080

à l'aide de ufw-user-forward

Pro:

Ne peut exposer des services s'exécutant sur des machines et des conteneurs dans le même temps par la même commande.

Par exemple, si nous voulons publier le port 8080 de conteneurs, utilisez la commande suivante:

ufw route allow 8080

Le réseau public peut accéder à toutes les publications, les ports dont les ports à conteneurs sont 8080.

Mais le port 8080 de l'hôte n'est pas encore accessible par le réseau public. Si nous voulons le faire, exécutez la commande suivante pour permettre au public d'accéder au port de l'hôte séparément:

ufw allow 8080

Con:

Ne prend pas en charge les anciennes versions d'Ubuntu, et la commande est un peu plus compliqué. Mais vous pouvez utiliser mon script https://github.com/chaifeng/ufw-docker.

Conclusion

Si nous sommes en utilisant une ancienne version de Ubuntu, on peut utiliser ufw-user-input de la chaîne. Mais être prudent pour éviter d'exposer des services qui ne devraient pas être exposés.

Si nous utilisons une version plus récente d'Ubuntu qui est un soutien ufw route sous-commande, nous ferions mieux d'utiliser ufw-user-forward de la chaîne, et l'utilisation ufw route de commande pour gérer les règles de pare-feu pour les conteneurs.

---

Mise À Jour: 6 Octobre 2018

Le script ufw-docker prend en charge le Panneau de l'Essaim maintenant. Veuillez consulter la dernière version du code pour plus d', https://github.com/chaifeng/ufw-docker

Installation de Docker Essaim mode

Nous ne pouvons utiliser ce script sur le gestionnaire de noeuds pour gérer les règles de pare-feu lors de l'utilisation dans l'Essaim de mode.

• La modification de tous les after.rules fichiers sur tous les nœuds, y compris les gestionnaires et les travailleurs
• Le déploiement de ce script dans le gestionnaire de nœuds

Cours d'exécution dans le Panneau de l'Essaim de mode, ce script va ajouter un service global ufw-docker-agent. L'image chaifeng/ufw-docker-agent est également construite automatiquement à partir de ce projet.

Pour ce que ça vaut voici un additif à @mkubaczyk réponse pour le cas où il y a plus de pont des réseaux impliqués dans l'ensemble de l'installation. Ceux-ci peuvent être fournis par Docker-composition de projets et voici comment les règles adéquates peuvent être générés, étant donné que ces projets sont contrôlés par systemd.

/etc/systemd/system/[email protected]

[Unit]
Description=Docker-Compose project: %I
After=docker.service
BindsTo=docker.service
AssertPathIsDirectory=/<projects_path>/%I
AssertFileNotEmpty=/<projects_path>/%I/docker-compose.yml

[Service]
Type=simple
Restart=always
WorkingDirectory=/<projects_path>/%I
ExecStartPre=/usr/bin/docker-compose up --no-start --remove-orphans
ExecStartPre=+/usr/local/bin/update-iptables-for-docker-bridges
ExecStart=/usr/bin/docker-compose up
ExecStop=/usr/bin/docker-compose stop --timeout 30
TimeoutStopSec=30
User=<…>
StandardOutput=null

[Install]
WantedBy=multi-user.target

/usr/local/bin/update-iptables-for-docker-bridges

#!/bin/sh

for network in $(docker network ls --filter 'driver=bridge' --quiet); do
  iface=$(docker network inspect --format '{{index .Options "com.docker.network.bridge.name"}}' ${network})
  [ -z $iface ] && iface="br-${network}"
  subnet=$(docker network inspect --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}' ${network})
  rule="! --out-interface ${iface} --source ${subnet} --jump MASQUERADE"
  iptables --table nat --check POSTROUTING ${rule} || iptables --table nat --append POSTROUTING ${rule}
done

Évidemment, cela ne va pas si bien que cela.

Il est également intéressant de noter que la totalité de la base du concept de volonté de dissimuler la source de toute connexion pour les applications s'exécutant dans un conteneur.