Restreindre l'accès au réseau du conteneur Docker

Je suis en train de créer un conteneur Docker SFTP uniquement , qui sera utilisé par plusieurs personnes dans le seul but de télécharger et de gérer des fichiers dans leur propre chrootenvironnement ed.

Sur le papier, c'est assez sûr: je désactiverai toutes les formes de bashconnexion et je n'y exécuterai aucun autre processus. Cependant, je voudrais le durcir un peu plus:

Je veux empêcher ce conteneur d'accéder à Internet de l'intérieur, sauf dans le but d'être un serveur SFTP.

Pour que les choses soient claires: je sais comment empêcher le monde extérieur d'accéder à mon conteneur - je peux configurer les iptablesrègles entrantes et je ne peux exposer que le port SFTP dans ma commande runer docker.

Cependant, je voudrais faire échouer la commande suivante (à titre d'exemple), lorsqu'elle est exécutée à l' intérieur du conteneur:

curl google.com

Mon intention est de réduire la quantité de dommages qu'un conteneur piraté peut faire (ne pas pouvoir être utilisé pour envoyer des spams, etc.).

Il est toujours judicieux de mettre des règles d'entrée dans votre instance de docker pour aider à repousser les attaques, mais vous devrez limiter l'accès sortant (Internet) à partir du routeur en amont auquel l'image docker se connecte. La raison en est que si vous essayez de bloquer l'accès sortant avec les règles de pare-feu à l'intérieur de votre instance, si l'instance est compromise, ces règles pourraient être supprimées par l'attaquant. En bloquant la sortie via le routeur de l'instance, vous bloquez l'accès sortant même en cas de compromis - l'attaquant devrait également compromettre le routeur.

Ok, donc après avoir reçu des commentaires qui expliquent que le filtrage était destiné à l'hôte du conteneur, c'est un peu plus clair ce qui essaye d'être accompli. Dans ce cas, sur l'hôte, vous ajouteriez des règles similaires à ceci:

iptables -A FORWARD -s lo.cal.sub.net -d con.tai.ner.ip -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d lo.cal.sub.net -j ACCEPT
iptables -A FORWARD -s ! lo.cal.sub.net -d con.tai.ner.ip -p tcp --dport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d ! lo.cal.sub.net -p tcp --sport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -m state --state related,established -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -j DROP

Les deux premières règles concernent l'accès entre l'hôte et le conteneur. La troisième règle dit (grosso modo) que tout ce qui n'est pas le sous-réseau de l'hôte dirigé vers SFTP est tout simplement OK par nous; le quatrième est la règle du trafic sortant qui est essentiellement un jumeau au troisième; la cinquième règle est un fourre-tout (dans le cas où d'autres ports associés sont utilisés), même si cela ne devrait pas être nécessaire, vous pouvez probablement le supprimer; la dernière règle est la magie qui empêche l'accès à autre chose que le sous-réseau hôte. L'accès étant donné dans les premières règles, il ne se déclenchera jamais si aucune des règles précédentes ne s'applique. Dans ce cas, nous disons: "Nous ne nous soucions pas de ce que vous voulez, vous ne correspondez à rien pour lequel vous êtes approuvé, vous ne pouvez donc pas vous y rendre ". Le trafic entrant de l'extérieur sera satisfait par les 3e et 4e règles.

Ce n'est pas vraiment un problème spécifique de docker. Il existe plusieurs façons de résoudre ce problème.

1. Utilisez des iptablesrègles avec état pour autoriser les connexions entrantes et le trafic associé / établi, puis bloquez tout le reste.

2. Utilisez un service sftp uniquement tel que ProFTPD qui est incapable d'exécuter un shell.

En général, si vous n'autorisez pas vos utilisateurs à obtenir un shell et ne leur permettez pas d'exécuter des programmes à partir du conteneur, vous n'avez pas à vous en préoccuper.

Ce n'est qu'un rapide brainstorming, et je ne l'ai pas encore testé. Vous voudrez le vérifier en laboratoire avant de le mettre en production.

Pour empêcher le trafic sortant sur les ports non SSH (SFTP) et Web, vous pouvez appliquer une stratégie via IPTABLES ou un autre pare-feu Layer4 au DROP ou au REJECT provenant du segment utilisé par les conteneurs Docker destinés à 0.0.0.0/0, sauf lorsque la destination Le port est TCP22.

Pour résoudre le problème de non-approbation des lieux sur le Web, vous souhaiterez peut-être essayer de configurer une instance d'un proxy de filtrage / mise en cache, tel que squid ou bluecoat, qui écoute sur l'interface docker0 et qui utilise l'itinéraire par défaut de l'hôte pour accéder à Internet. À partir de là, vous pouvez appliquer une stratégie basée sur de nombreux critères, tout en économisant l'utilisation du réseau en mettant en cache du contenu statique. Vous voudrez peut-être utiliser NAT (je pense que IPTABLES et Masquerade le fournissent sous Linux) sur la machine hôte pour appliquer l'utilisation du proxy de manière transparente (je l'ai décrit dans ma réponse à Je veux proxy uniquement HTTP mais je ne sais pas quoi faire avec le trafic HTTPS ). Cela implique d'avoir une raison d'aller sur le Web en premier lieu, conformément aux politiques de votre entreprise.

En raison de la nature de SSH (sur lequel SFTP est basé), vous ne pourrez pas interdire le trafic pour le déplacement de fichiers, sauf si vous implémentez une stratégie selon laquelle les conteneurs ne peuvent utiliser que les paires de clés fournies par vous. C'est bon pour vous, car cela vous donne " Je n'avais aucune visibilité ni contrôle sur les fichiers transférés"Défense si l'un de vos clients transfère quelque chose d'illégal (comme une atteinte à la propriété intellectuelle, ou utilise votre service pour exfiltrer des informations portant une étiquette de classification, ou s'il échange du CP), si vous êtes traduit en justice pour quelque chose que vos clients font (pensez analogue à ce qui est mauvais pour vous car vous ne pouvez pas mettre en cache des fichiers fréquemment transférés et inchangés, et parce que toute politique que vous écrivez dans le contrat avec vos clients sera essentiellement inapplicable par des moyens techniques.