Einschränkung des Netzwerkzugriffs auf den Docker-Container

Ich bin dabei, einen Docker- Container nur für SFTP zu erstellen, der von mehreren Personen nur zum Hochladen und Verwalten von Dateien in ihrer eigenen chrootEd-Umgebung verwendet wird.

Auf dem Papier ist es ziemlich sicher: Ich deaktiviere jede Art der bashAnmeldung und führe keinen anderen Prozess darin aus. Ich würde es aber gerne noch etwas härter machen:

Ich möchte verhindern, dass dieser Container von innen auf das Internet zugreift, es sei denn, er dient als SFTP-Server.

Um es klar zu machen: Ich weiß, wie ich verhindern kann, dass die Außenwelt auf meinen Container zugreift. Ich kann eingehende iptablesRegeln einrichten und nur den SFTP-Port in meinem Docker-Ausführungsbefehl verfügbar machen.

Ich möchte jedoch den folgenden Befehl (als Beispiel) fehlschlagen lassen, wenn er im Container ausgeführt wird:

curl google.com

Meine Absicht ist es, den Schaden zu verringern, den ein gehackter Container anrichten kann (der nicht zum Versenden von Spam-E-Mails usw. verwendet werden kann).

Es ist immer noch sinnvoll, einige Eingangsregeln in Ihre Docker-Instanz einzufügen, um Angriffe abzuwehren. Sie müssen jedoch den ausgehenden (Internet-) Zugriff von jedem Upstream-Router einschränken, mit dem das Docker-Image verbunden ist. Wenn Sie versuchen, den ausgehenden Zugriff mit den Firewall-Regeln in Ihrer Instanz zu blockieren, können diese Regeln vom Angreifer entfernt werden, wenn die Instanz gefährdet ist. Indem Sie den Ausgang über den Router der Instanz blockieren, blockieren Sie den ausgehenden Zugriff auch im Falle einer Gefährdung - der Angreifer müsste auch den Router gefährden.

Ok, nachdem wir einen Kommentar erhalten haben, der erklärt, dass die Filterung für den Host des Containers bestimmt war, ist etwas klarer, was erreicht werden soll. In diesem Fall würden Sie auf dem Host einige ähnliche Regeln hinzufügen:

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

Die ersten beiden Regeln gelten für den Zugriff zwischen Host und Container. Die dritte Regel besagt (ungefähr), dass alles, was nicht das Subnetz des Hosts für SFTP ist, von uns nur in Ordnung ist. Die vierte Regel ist die Outbound-Regel, bei der es sich im Grunde um eine Doppelregel gegenüber der dritten handelt. Die fünfte Regel ist ein Sammelbegriff (falls andere verwandte Ports verwendet werden). Obwohl dies nicht erforderlich sein sollte, können Sie es wahrscheinlich entfernen. Die letzte Regel ist die Aktivierung, die den Zugriff auf andere Elemente als das Host-Subnetz verhindert. Da der Zugriff in den ersten paar Regeln angegeben ist, wird er nur ausgelöst, wenn eine der vorhergehenden Regeln zutrifft. In diesem Fall sagen wir: "Es ist uns egal, was Sie möchten, Sie haben nichts gefunden, für das Sie genehmigt wurden." Sie können also von hier aus nicht dorthin gelangen ". Eingehender Datenverkehr von außen wird durch die 3. und 4. Regel erfüllt.

Dies ist kein spezielles Docker-Problem. Es gibt verschiedene Möglichkeiten, wie Sie dieses Problem lösen können.

1. Verwenden Sie Stateful- iptablesRegeln, um eingehende Verbindungen und verwandten / eingerichteten Datenverkehr zuzulassen, und blockieren Sie dann alles andere.

2. Verwenden Sie einen SFTP-Dienst wie ProFTPD , der keine Shell ausführen kann.

Wenn Sie Ihren Benutzern nicht erlauben, eine Shell abzurufen, und ihnen nicht erlauben, Programme innerhalb des Containers auszuführen, müssen Sie sich im Allgemeinen keine Gedanken darüber machen.

Dies ist nur ein kurzes Brainstorming und ich habe es noch nicht getestet. Sie sollten es im Labor untersuchen, bevor Sie es in die Produktion bringen.

Um ausgehenden Datenverkehr auf Nicht-SSH- (SFTP-) und Web-Ports zu verhindern, möchten Sie möglicherweise eine Richtlinie über IPTABLES oder eine andere Layer4-Firewall auf DROP- oder REJECT-Datenverkehr anwenden, der aus dem Segment stammt, das von Docker-Containern verwendet wird, die für 0.0.0.0/0 bestimmt sind, außer für Destination Port ist TCP22.

Um das Problem zu lösen, dass Orte im Web nicht genehmigt werden, sollten Sie versuchen, eine Instanz eines Filter- / Caching-Proxys wie z. B. Squid oder Bluecoat einzurichten, der die Schnittstelle docker0 überwacht und die verwendet Der Weg des Gastgebers, um ins Internet zu gelangen. Von dort aus können Sie Richtlinien anwenden, die auf vielen Kriterien basieren, und die Netzwerkauslastung durch Zwischenspeichern von statischem Inhalt verringern. Vielleicht möchten Sie NAT verwenden (ich glaube , IPTABLES und Maskerade bieten diese in Linux) auf dem Host - Rechner Verwendung des Proxy erzwingen transparent (I beschrieb dies in meiner Antwort auf ich Proxy möchte nur HTTP aber ich bin sicher nicht , was tun mit HTTPS-Verkehr ). Dies impliziert, dass es einen Grund gibt, in erster Linie auf das Internet zuzugreifen, der den Richtlinien Ihres Unternehmens entspricht.

Aufgrund der Art von SSH (auf der SFTP basiert) können Sie das Verschieben von Dateien nur dann unterbinden, wenn Sie eine Richtlinie implementieren, in der Container nur von Ihnen bereitgestellte Schlüsselpaare verwenden. Dies ist gut für Sie, weil es Ihnen einige " Ich hatte keine Sichtbarkeit oder Kontrolle über übertragene Dateien"Verteidigung, wenn einer Ihrer Kunden etwas Illegales überträgt (z. B. IP-Schutzrechtsverletzung oder Ihren Dienst dazu nutzt, Informationen mit einem Klassifizierungsetikett zu filtern, oder wenn er mit CP handelt), wenn Sie für etwas vor Gericht gebracht werden, was Ihre Kunden tun (denken Sie analog dazu) Common-Carrier-Status für Telekommunikationsunternehmen.) Dies ist schlecht für Sie, weil Sie häufig neu übertragene, unveränderte Dateien nicht zwischenspeichern können und weil alle Richtlinien, die Sie in den Vertrag mit Ihren Kunden schreiben, auf technischem Wege im Wesentlichen nicht durchsetzbar sind.