Offenlegung des Container-Netzwerks

Was ist Offenlegung des Container-Netzwerks?

Das Veröffentlichen eines Container-Ports bindet ihn standardmäßig an jede Schnittstelle, sodass ein für die lokale Entwicklung gedachtes Mapping eine Datenbank ins öffentliche Internet stellen kann, ohne dass sich scheinbar eine Firewall-Regel ändert. Im Standard-Bridge-Netzwerk kann außerdem jeder Container jeden anderen erreichen. Diese Übung behandelt eine durch ein Port-Mapping offengelegte Datenbank: Beobachten Sie, wie ein Angreifer sich direkt verbindet, ohne dass eine Anwendung beteiligt ist, und beheben Sie es anschließend, indem Sie an localhost binden und die Dienste in ein benutzerdefiniertes Netzwerk verschieben.

Was Sie lernen in Offenlegung des Container-Netzwerks

• An jede Schnittstelle des Hosts, einschließlich öffentlicher, weshalb eine Entwicklungs-Annehmlichkeit eine Datenbank dem Internet aussetzen kann.
• Das Mapping wird von der Container-Runtime auf dem Host erzeugt, sodass sich an der Cloud-Security-Group-Konfiguration nichts ändert, um es widerzuspiegeln.
• Jeder Container darin kann jeden anderen erreichen, sodass die Kompromittierung eines einzelnen Containers Netzwerkzugriff auf alle gibt.
• Rotieren Sie die Credentials, die erreichbar waren, denn das Schließen des Ports macht nichts ungültig, was ein Angreifer bereits gesammelt hat.

Offenlegung des Container-Netzwerks — Trainingsschritte

1. Eine Datenbank im offenen Internet

   Bob befindet sich in nichts. Vor Wochen hat er einen Dump gekauft, der ein Read-only-Datenbank-Credential für Halvexis enthielt, aber ein Credential ist nutzlos, wenn man die Datenbank nicht erreichen kann. Also scannt er die Data-Store-Hosts des Unternehmens, um zu sehen, ob einer von ihnen von außen antwortet.

2. Direkt hinein, ohne Anwendung

   Es gibt keine Login-Seite, keine API, kein Rate Limit. Ein veröffentlichter Datenbank-Port spricht das rohe Postgres-Protokoll mit jedem, der ihn erreichen kann. Bob richtet einen Datenbank-Client direkt darauf und authentifiziert sich mit dem Credential, das er bereits hatte.

3. Die Tabelle „residents“ lesen

   Das Credential ist read-only, mehr braucht Bob nicht. Er fragt die Tabelle ab, die die Mieter der Plattform und ihre Daten enthält, direkt aus der Produktion.

4. Was sich geändert hat

   Bob hat genau dieses Credential seit Monaten und hat es nie benutzt.

5. Monitoring markiert den Traffic

   Halvexis betreibt Cloud-Monitoring auf seinen Produktions-Hosts. Es weiß nicht, wofür die Datenbank da ist; es meldet, was es gesehen hat.

6. Den offenen Port finden

   Wenn sich die Security-Groups nicht geändert haben, wurde die Offenlegung auf dem Host selbst erzeugt, dadurch, wie ein Container seinen Port veröffentlicht hat. Alice listet den Datenbank-Container auf und liest die eine Spalte, die angibt, an welche Schnittstellen der Port gebunden ist.

7. Wo der Port veröffentlicht wird

   Das Port-Mapping stammt aus der Compose-Datei, die den Stack definiert. Alice öffnet sie, um die Zeile zu sehen, die 5432 veröffentlicht hat.

8. Die Zeile, die es verursacht hat

   Ein einziges Mapping, so geschrieben, wie ein Entwickler es auf seinem Laptop schreibt, hat die Datenbank ins Internet gestellt, als dieser Stack in die Produktion ausgeliefert wurde.

9. An localhost binden

   Die API erreicht die Datenbank über das Compose-Netzwerk anhand ihres Servicenamens, nicht über einen veröffentlichten Host-Port. Das Host-Mapping muss also überhaupt nicht öffentlich sein. Alice bindet es an die Loopback-Schnittstelle, sodass nur der Host selbst und die Container in seinem Netzwerk darauf zugreifen können.

10. Die korrigierte Bindung lesen

    Die Änderung ist ein einziges Schnittstellen-Präfix, aber sie ist die gesamte Korrektur. Alice geht das gebundene Mapping vor dem erneuten Deployment Schritt für Schritt durch, um genau zu sehen, was jetzt von wo aus erreichbar ist.