Datahorses

Offene Datenbankports: MySQL, PostgreSQL, MongoDB, Redis und Elasticsearch

Von · · 4 Min. Lesezeit

Ein Datenbankport ist offen, wenn jeder im Internet eine Verbindung zu ihm aufbauen kann. Ihre Anwendung muss die Datenbank erreichen, ein beliebiger Rechner in einem anderen Land nicht. Trotzdem können eine einzige Firewall-Regel, eine geänderte Konfigurationszeile oder eine Cloud-Voreinstellung dazu führen, dass MySQL, PostgreSQL, MongoDB, Redis oder Elasticsearch dem ganzen Internet antworten.

Ein offener Port ist nicht automatisch ein Datenleck. Ist die Authentifizierung stark und die Software aktuell, muss der Angreifer diese Hürde noch überwinden. Ein offener Port macht Ihre Datenbank aber zu etwas, das jeder abtasten, mit Passwortversuchen bombardieren und auf bekannte Schwachstellen testen kann. Wer ihn schließt, beseitigt die gesamte Risikokategorie.

Dieser Artikel nennt die Standardports, zeigt, wie Sie von außen prüfen, und erklärt, wie Sie die Ports richtig schließen.

Die wichtigsten Standardports

Das sind die Standardports laut Dokumentation der jeweiligen Hersteller:

  • MySQL: 3306 für das klassische Protokoll, 33060 für das X Protocol.
  • PostgreSQL: 5432.
  • MongoDB: 27017 für mongod und mongos.
  • Redis: 6379, wie in der Standard-redis.conf festgelegt.
  • Elasticsearch: HTTP-API auf dem ersten freien Port im Bereich 9200 bis 9300, meist 9200, und die Transportschicht auf 9300 bis 9400.

Dienste können auch auf anderen Ports laufen. Betrachten Sie diese Liste also als Ausgangspunkt, nicht als vollständigen Scan.

Wie Datenbanken ins Internet geraten

Die meisten dieser Produkte sind heute in der Grundeinstellung sicherer als früher:

Offene Ports entstehen deshalb meist durch eine bewusste Änderung, die nur vorübergehend sein sollte:

  • jemand hat bind-address = 0.0.0.0, listen_addresses = '*' oder bindIpAll gesetzt, damit sich ein Entwickler von zu Hause verbinden kann,
  • der Protected Mode oder die Sicherheitsfunktionen wurden abgeschaltet, „damit es läuft“,
  • eine Cloud Security Group oder Firewall-Regel erlaubt den Port aus 0.0.0.0/0,
  • ein Docker-Aufruf mit -p 6379:6379 veröffentlicht den Port auf allen Schnittstellen des Hosts,
  • ein alter Test- oder Staging-Server mit eigener Datenbank wurde nie abgeschaltet.

Die Redis-Dokumentation benennt das Risiko klar: Redis ist für vertrauenswürdige Clients in vertrauenswürdigen Umgebungen gedacht, und eine offen erreichbare Instanz kann mit einem einzigen FLUSHALL-Befehl ihren gesamten Datenbestand verlieren.

So prüfen Sie von außen

Die Prüfung muss außerhalb Ihres Netzwerks laufen, sonst testen Sie nur den internen Weg. Nutzen Sie einen Rechner mit einer anderen Verbindung (eine Cloud-VM, einen Handy-Hotspot) und testen Sie ausschließlich IP-Adressen, die Ihnen gehören:

for port in 3306 5432 27017 6379 9200 9300; do
  nc -z -w 3 203.0.113.10 $port && echo "$port open" || echo "$port closed"
done

Auf dem Server selbst sehen Sie, auf welchen Adressen jeder Dienst lauscht:

sudo ss -tlnp | grep -E ':(3306|5432|27017|6379|9200|9300)\b'

127.0.0.1:5432 oder eine private Adresse ist das, was Sie sehen wollen. 0.0.0.0:5432 oder [::]:5432 bedeutet, dass der Dienst auf allen Schnittstellen lauscht und nur eine Firewall zwischen ihm und dem Internet steht.

Internet-Scanner indexieren außerdem offene Ports für jede öffentliche IP-Adresse. Für einen schnellen Blick darauf, was sie zu einer Ihrer Adressen erfasst haben, bietet Shodan eine einfache Abfrage unter https://internetdb.shodan.io/<your-ip>.

So schließen Sie den Port richtig

Arbeiten Sie mit 2 Ebenen, damit ein einzelner Fehler die Datenbank nicht erneut freilegt:

  1. Nur an private Schnittstellen binden. bind-address = 127.0.0.1 (MySQL), listen_addresses = 'localhost' oder eine private IP (PostgreSQL), net.bindIp (MongoDB), bind 127.0.0.1 mit protected-mode yes (Redis), network.host auf einer privaten Adresse (Elasticsearch).
  2. Auf Netzwerkebene einschränken. Die Firewall oder Cloud Security Group sollte den Datenbankport nur von Ihren Anwendungsservern erlauben.
  3. Fernzugriff über einen Tunnel. Entwickler verbinden sich über SSH-Tunnel oder VPN, nie über einen offenen Port.
  4. Überall Authentifizierung verlangen, auch in internen Netzen: Benutzer mit minimalen Rechten, lange Passwörter und TLS für Verbindungen, die einen einzelnen Host verlassen.
  5. Die Software aktuell halten, damit ein versehentlich offener Port nicht zusätzlich eine Version mit bekannten Schwachstellen bereitstellt.

War eine Datenbank mit schwacher oder ganz ohne Authentifizierung erreichbar, behandeln Sie ihre Daten als möglicherweise kopiert: Zugangsdaten wechseln, Logs prüfen und Ihre Meldepflichten bedenken.

Eine kurze Checkliste

  • Erfassen Sie jede öffentliche IP-Adresse, die Ihr Unternehmen nutzt, auch alte Server.
  • Testen Sie die gängigen Datenbankports von außen.
  • Stellen Sie sicher, dass jede Datenbank nur auf localhost oder einer privaten Adresse lauscht.
  • Erlauben Sie Datenbankports in der Firewall nur von Anwendungsservern.
  • Prüfen Sie nach jeder Migration, jedem neuen Server und jeder Docker-Änderung erneut.

Offene Dienste kommen selten allein. Sie laufen oft auf denselben vergessenen Staging-Servern, auf denen auch .env- und Backup-Dateien abrufbar sind.

Wie Datahorses hilft

Datahorses beobachtet Ihr Unternehmen jeden Tag von außen und zeigt, welche Dienste ein Angreifer auf Ihren öffentlichen Adressen sehen kann, darunter Datenbankports und Fernzugänge wie RDP oder SSH, zusammen mit bekannten Schwachstellen der Versionen, die diese Dienste preisgeben. Wir dringen nicht in Ihre Systeme ein und benötigen keine Zugänge. Jeder Fund kommt mit genauen Schritten für Ihren Entwickler, wie unter was passiert, wenn wir etwas finden beschrieben. Das Beispiel-Dashboard zeigt, wie ein solcher Bericht aussieht.

Weitere Artikel

Alle Artikel