Die Datenbank gehört nicht ins Netz, auch nicht kurz

Datenbanken ohne Zugriffsschutz sind kein historisches Thema. Sie entstehen bei jeder Neuinstallation neu, durch eine Standardkonfiguration, die auf allen Adressen hört, einen Container mit veröffentlichtem Port oder eine Freigabe, die „nur für den Test“ gesetzt wurde.

Prüfen, in zwei Minuten#

Auf der Maschine:

sudo ss -tulpn | grep -E ':(3306|5432|6379|27017|9200|11211|5984)\b'

Alles, was dort auf 0.0.0.0 oder [::] steht, ist ein Befund, es sei denn, davor liegt eine Firewallregel, die man belegen kann.

Von außen, von einer anderen Maschine:

nmap -Pn -p 3306,5432,6379,9200,11211,27017 203.0.113.10

# Antwortet Redis wirklich?
redis-cli -h 203.0.113.10 ping        # erwartet: Verbindung scheitert
# Elasticsearch?
curl -sS --max-time 5 http://203.0.113.10:9200/_cluster/health

Wenn hier eine Antwort kommt, ist das kein Test mehr, sondern ein Vorfall, dann gilt Die erste Stunde, denn die Frage ist nicht, ob jemand vorbeigeschaut hat, sondern wann.

Die richtige Reihenfolge der Gegenmaßnahmen#

1. Binden statt filtern. Der wirksamste Schritt ist, dass der Dienst gar nicht nach außen hört:

# PostgreSQL: postgresql.conf
listen_addresses = 'localhost'          # oder die interne Overlay-Adresse

# MySQL/MariaDB: /etc/mysql/mariadb.conf.d/50-server.cnf
bind-address = 127.0.0.1

# Redis: /etc/redis/redis.conf
bind 127.0.0.1 ::1
protected-mode yes
requirepass <langes-zufälliges-passwort>

# MongoDB: /etc/mongod.conf
net:
  bindIp: 127.0.0.1
security:
  authorization: enabled

2. Authentifizierung auch intern. „Nur intern erreichbar“ ist eine Annahme über das Netz, die spätestens beim zweiten Container nicht mehr stimmt. Jede Datenbank bekommt ein Passwort und einen eigenen Benutzer je Anwendung, mit den Rechten, die diese Anwendung braucht, nicht mehr.

3. Firewall als zweite Schicht, nicht als erste:

nft add rule inet filter input tcp dport 5432 ip saddr 10.99.0.0/24 accept
nft add rule inet filter input tcp dport 5432 drop

Wenn wirklich von außen zugegriffen werden muss#

Drei Wege, in dieser Reihenfolge:

1. Overlay-Netz, die Datenbank hört auf der Overlay-Adresse, erreichbar nur für Teilnehmer: WireGuard statt offener Ports.
2. SSH-Tunnel für gelegentliche Zugriffe, etwa aus einem Datenbankwerkzeug:

ssh -N -L 5432:127.0.0.1:5432 benutzer@server
# lokal verbindet man sich danach gegen 127.0.0.1:5432

3. TLS mit Zertifikatsprüfung, wenn ein direkter Zugriff unvermeidbar ist und dann mit Quell-IP-Begrenzung. Das ist der schlechteste der drei Wege und braucht eine Begründung.

Und die Sicherungen#

Der zweite Fundort für Datenbankinhalte ist der Dump, der im Webverzeichnis liegt. Ein curl https://example.org/dump.sql gehört in dieselbe Prüfrunde wie der Portscan, die Liste dafür steht in Geheimnisse gehören nicht ins Repo. Wohin Sicherungen stattdessen gehören, steht in Ransomware zielt zuerst auf die Sicherung.

Wie diese Ports überhaupt aufgehen#

Die Fälle wiederholen sich, und keiner davon sieht im Moment der Entstehung nach einem Fehler aus. Ein Datenbankwerkzeug soll vom Laptop aus verbinden, also wird der Port „kurz“ freigegeben. Ein Container wird aus einem Beispiel übernommen, in dem ports: steht, weil das Beispiel den Zugriff von außen zeigen wollte. Eine Anwendung zieht auf einen zweiten Server um, und die Datenbank bekommt eine Freigabe für dessen IP-Adresse, die später wechselt, während die Regel bleibt.

Deshalb ist die wirksamste organisatorische Maßnahme nicht eine Regel, sondern eine Gewohnheit: Nach jeder Änderung an Diensten, Containern oder Firewall einmal von außen scannen. Das dauert eine Minute und findet genau die Freigaben, die als Zwischenlösung gedacht waren.

# Nach jeder Änderung, von einer anderen Maschine
nmap -Pn -p 3306,5432,6379,9200,11211,27017 203.0.113.10 | grep -v closed

Ergänzend gehört der Datenbankport in die vierteljährliche Außenprüfung (Angriffsfläche von außen messen), dort fällt er auch dann auf, wenn niemand mehr weiß, wer ihn geöffnet hat.