it-swarm.com.de

Härten / Reduzieren der Angriffsfläche für einen Docker-Container

Ich möchte eine gehärtete Docker-Instanz einrichten, hauptsächlich zum Ausführen von Mikrodiensten wie statisch kompilierten Golang-Anwendungen. Was ich suche, ist, das Host-Betriebssystem vor einem betrügerischen Container und Container voreinander zu schützen. Ich habe versucht, die Situation mit dem folgenden Szenario zusammenzufassen.

Szenario :

Wir haben einen Server mit einem minimalen Betriebssystem wie Alpine Linux (Busybox-basiertes Betriebssystem), auf dem SElinux und grsec installiert, aktiviert und korrekt konfiguriert sind.

Auf diesem Server wird eine Docker-Instanz mit 2 laufenden Containern A und B und einem Volume V ausgeführt.

Der Container A enthält eine statisch kompilierte Anwendung ohne Abhängigkeiten, die mit dem öffentlichen Internet (Web-App oder öffentliche API) vernetzt ist. Diese Anwendung enthält einen RIESIGEN Fehler wie die Ausführung von willkürlichem Code/Upload/Full Reverse Shell, je schlimmer Sie sich vorstellen können. Dieser Container ist auch mit dem Volume V als Upload-Ziel, Datenbank usw. vernetzt.

Das Host-Betriebssystem enthält ein Flag, das nur gelesen werden kann, wenn root (von SElinux erzwungen).

Der Container B enthält auch ein Flag und eine Anwendung, aber keine Verbindung zur Außenwelt.

Angreifer :

  • Mensch, kennt den großen Fehler in der Anwendung.
  • Er will die Fahnen bekommen. Die Daten in V sind nicht wichtig.
  • Er ist keine Spionageagentur, aber dennoch ein hochrangiger Sicherheitsspezialist.
  • Möglicherweise haben Sie Zugriff auf einige Zero-Days, die uns nicht bekannt sind.

Annahmen :

  • Der Linux-Kernel hat Fehler, aber grsec reicht aus, um dies zu beheben. Kann kein Angriffsvektor sein, wenn grsec nicht deaktiviert ist
  • Grsec und SElinux haben keine Fehler und sind nicht falsch konfiguriert.
  • Ein Benutzer root im Container ist root außerhalb des Containers (vielleicht wird dies eines Tages nicht mehr wahr sein ...)
  • Docker ist ein realer Docker. Keine bekannten Fehler, wurde aber in der Vergangenheit von Fehlern betroffen und es könnte wieder vorkommen.
  • Ein Protokollsystem für zukünftige Untersuchungen ist bereits ordnungsgemäß eingerichtet.

Ziel :

  • Schützen Sie die Flaggen. Wahrscheinlich nicht möglich, da wir davon ausgehen, dass Docker Fehler aufweist.
  • Angriffsfläche reduzieren.
  • Machen Sie dem Angreifer das Leben schwer.
  • Stellen Sie einen Alarm ein, der ausgelöst wird, wenn der Angreifer versucht, die Flags zu erhalten. Am liebsten lange bevor er es geschafft hat sie zu bekommen.

Fragen :

  • Wie realistisch sind meine Annahmen?
  • Wie würden Sie diese Ziele erreichen?
  • Wie sind meine folgenden Vorschläge?
  • Irgendwelche allgemeinen Sicherheitshinweise für Docker?

Meine Vorschläge :

  • Konfigurieren Sie SElinux so, dass kein Benutzer auf A schreiben kann und kein Benutzer Dateien auf V ausführen kann.
  • Verwenden Sie ein extrem minimales Docker-Image ohne Benutzerland. Etwas wie:

    FROM scratch
    COPY app /
    ENTRYPOINT ["/app"]
    
  • Deeskalieren Sie die Berechtigungen, bevor Sie die App ausführen. (Ich bin mir nicht sicher, wie ich das richtig machen soll ...)

  • Ein gefälschtes Busybox-User-Land? Etwas, das einen Alarm auslösen würde, wenn wir versuchen, /bin/sh, /bin/ls oder so ähnlich.
14
Matthieu

Ich verweise Sie auf die CIS-Benchmarks für Härtungsrichtlinien. Den aktuellen CIS-Benchmark für Docker finden Sie hier . Dies ist ein anerkannter Industriestandard für das Grundhärten. Sie bieten auch Richtlinien für Linux et al., Webserver, DBs usw.

8
HashHazard