Ports und lauschende Dienste

Modul 5: Das Netzwerk abschirmen · Lesezeit: 10 Minuten

Lernziel: Nach dieser Lektion können Sie sehen, welche Dienste auf Ihrem Server lauschen und auf welcher Adresse, den Unterschied zwischen 0.0.0.0 und 127.0.0.1 erklären und von außen prüfen, was jeder im Internet von Ihrem Server sieht.

Kernbegriffe: Port, TCP und UDP, Lauschen, ss -tulpn, 0.0.0.0 und [::], 127.0.0.1 und [::1], bind-address, offen, geschlossen und gefiltert, Angriffsfläche, Scanner

Eine IP-Adresse mit 65.535 Türen

Ihr Server hat eine IP-Adresse, zum Beispiel 192.0.2.10 und 2001:db8::10. Unter dieser Adresse können mehrere Programme gleichzeitig erreichbar sein, jedes auf einem eigenen Port: einer Nummer von 1 bis 65.535. Ein Programm, das Verbindungen annimmt, lauscht auf einem Port. Einige bekannte Ports:

TCP ist das Protokoll für Verbindungen, die zuverlässig ankommen müssen (Web, SSH, Datenbanken). UDP ist für schnelle, einzelne Pakete gedacht (DNS, VPNs wie WireGuard, HTTP/3). Ein Dienst lauscht auf TCP, UDP oder beidem.

Jeder lauschende Port ist eine Tür zu Ihrem Server. Hinter jeder Tür steckt Software, die Fehler enthalten kann. Die Gesamtheit der Türen, die von außen erreichbar sind, nennt man Ihre Angriffsfläche. Je kleiner, desto besser: Ein Server mit einer Website braucht von außen nur 22, 80 und 443.

Nachsehen, was lauscht: ss

Der Befehl ss (socket statistics) zeigt, was auf Ihrem Server lauscht. Mit den Optionen -t (TCP), -u (UDP), -l (nur lauschende), -p (welches Programm) und -n (Nummern, keine Namen):

anna@web1:~$ sudo ss -tulpn
Netid State  Local Address:Port  Peer Address:Port Process
udp   UNCONN 127.0.0.54:53       0.0.0.0:*         users:(("systemd-resolve",pid=402,fd=16))
tcp   LISTEN 0.0.0.0:22          0.0.0.0:*         users:(("sshd",pid=611,fd=3))
tcp   LISTEN 0.0.0.0:80          0.0.0.0:*         users:(("nginx",pid=902,fd=6))
tcp   LISTEN 0.0.0.0:443         0.0.0.0:*         users:(("nginx",pid=902,fd=7))
tcp   LISTEN 127.0.0.1:3306      0.0.0.0:*         users:(("mariadbd",pid=755,fd=21))
tcp   LISTEN 0.0.0.0:6379        0.0.0.0:*         users:(("redis-server",pid=780,fd=6))
tcp   LISTEN [::]:22             [::]:*            users:(("sshd",pid=611,fd=4))
tcp   LISTEN [::]:80             [::]:*            users:(("nginx",pid=902,fd=8))
tcp   LISTEN [::]:443            [::]:*            users:(("nginx",pid=902,fd=9))

Die wichtigste Spalte ist Local Address: die Adresse, auf der das Programm lauscht.

Im Beispiel oben ist MariaDB in Ordnung: Der Dienst lauscht auf 127.0.0.1, also können nur Programme auf dem Server selbst (Ihre Website) darauf zugreifen. Redis dagegen lauscht auf 0.0.0.0:6379. Ist die Firewall nicht richtig eingestellt, kann das gesamte Internet darauf zugreifen. Genau um diese Art von Fehler geht es in dieser Lektion.

Auf der richtigen Adresse lauschen

Eine Datenbank, ein Cache oder ein Verwaltungspanel sollte fast nie von außen erreichbar sein. Die erste und beste Verteidigung ist, dass der Dienst nur auf Loopback lauscht. Eine Firewall (Lektion 5.2) ist die zweite Schutzschicht; sie kann versehentlich ausgeschaltet sein oder nicht greifen (zum Beispiel bei Docker, Lektion 9.3).

Wo Sie das einstellen, ist je nach Programm unterschiedlich:

Die Pakete von Debian und Ubuntu stellen diese Dienste standardmäßig bereits auf localhost ein. Meist geht es schief, wenn jemand einer Anleitung folgt, die sagt: "Setzen Sie bind-address auf 0.0.0.0, um von außen zu verbinden". Möchten Sie selbst von Ihrem Laptop aus auf die Datenbank zugreifen, verwenden Sie einen SSH-Tunnel (Lektion 2.3): Der Port bleibt geschlossen, und nur wer per SSH hereinkommt, kann darauf zugreifen.

Nach einer Änderung starten Sie den Dienst neu und sehen erneut mit ss -tulpn nach.

Offen, geschlossen und gefiltert

Von außen betrachtet kann ein Port drei Zustände haben:

• Offen (open): Es lauscht etwas, und die Verbindung gelingt.
• Geschlossen (closed): Es lauscht nichts, oder eine Firewall lehnt aktiv ab. Der Server schickt sofort ein "Nein" zurück (bei TCP ein RST-Paket). Eine Verbindung scheitert sofort mit "Connection refused".
• Gefiltert (filtered): Eine Firewall verwirft das Paket stillschweigend. Die Verbindung hängt bis zu einem Timeout.

Für Ihre Datenbank sind geschlossen und gefiltert beide gut: Niemand kommt heran. Der Unterschied sagt Ihnen nur, warum: Gefiltert bedeutet fast immer, dass Ihre Firewall die Verbindung blockiert.

Von außen nachsehen

ss zeigt, was auf dem Server lauscht, aber nicht, was von außen erreichbar ist. Dazwischen liegt noch eine Firewall, bei Ihrem Anbieter manchmal zusätzlich eine Netzwerk-Firewall. Die einzige echte Prüfung lautet daher: Sehen Sie von außen nach, von einem anderen Computer aus.

Von Ihrem eigenen Computer aus (nicht vom Server selbst, denn dann gehen Sie über Loopback) geht das für einen einzelnen Port mit nc (netcat):

anna@laptop:~$ nc -vz -w 3 192.0.2.10 6379
nc: connect to 192.0.2.10 port 6379 (tcp) failed: Connection refused
anna@laptop:~$ nc -vz -w 3 192.0.2.10 22
Connection to 192.0.2.10 22 port [tcp/ssh] succeeded!

Unter Windows erledigt PowerShell dasselbe mit Test-NetConnection 192.0.2.10 -Port 6379. Ein Portscanner wie nmap kann mehrere Ports gleichzeitig prüfen; setzen Sie einen solchen Scanner nur auf Ihrem eigenen Server ein.

Vergessen Sie IPv6 nicht. Ein häufiger Fehler ist eine Firewall, die nur Regeln für IPv4 hat, während der Dienst auch auf [::] lauscht. Testen Sie also auch die IPv6-Adresse: nc -6 -vz -w 3 2001:db8::10 6379.

Warum das so wichtig ist

Ihr Server wird ab der ersten Minute gescannt. Suchmaschinen für Geräte und Dienste im Internet sowie Bots von Kriminellen probieren ständig alle IPv4-Adressen auf bekannten Ports durch. Ein offenes Redis ohne Passwort, ein Elasticsearch-Cluster oder eine MongoDB ohne Zugriffskontrolle wird innerhalb kurzer Zeit gefunden. Datenpannen durch offene Datenbanken und offene Suchcluster tauchen regelmäßig in den Nachrichten auf, und fast immer geht es um genau diesen Fehler: Ein Dienst, der für den internen Gebrauch gedacht war, lauschte auf allen Adressen.

Auch am SSH-Port wird den ganzen Tag angeklopft. Das ist normal und mit Schlüsseln (Lektion 2.2) und fail2ban (Lektion 5.3) kein Problem.

Die Kursprüfung

In der Aufgabe zu dieser Lektion prüft das Kursprogramm von außen fünf feste Datenbankports Ihres Servers: 3306 (MySQL/MariaDB), 5432 (PostgreSQL), 6379 (Redis), 9200 (Elasticsearch/OpenSearch) und 27017 (MongoDB). Das Programm versucht nur, ob eine Verbindung zustande kommt, sendet keine Daten und meldet sich nirgends an. Es scannt keine anderen Ports. Die Prüfungen kommen von der IP-Adresse, die in der Aufgabe angegeben ist, sodass Sie sie in Ihrem eigenen Log wiedererkennen können. Eine Adresse kann nur ein paar Mal pro Stunde geprüft werden.

Unter AlmaLinux und Rocky Linux

ss funktioniert genauso. Die Dateien der Dienste liegen an anderen Stellen (zum Beispiel /etc/my.cnf.d/ für MariaDB, /var/lib/pgsql/data/postgresql.conf für PostgreSQL). Außerdem kann SELinux einen Dienst blockieren, der auf einem ungewöhnlichen Port lauschen will; das sehen Sie dann in journalctl (Lektion 6.2) und nicht in ss.

Zusammenfassung

• Jeder lauschende Port ist eine Tür; lassen Sie von außen nur offen, was wirklich nötig ist (meist 22, 80 und 443).
• sudo ss -tulpn zeigt, welches Programm auf welcher Adresse und welchem Port lauscht.
• 0.0.0.0 und [::] bedeuten "alle Adressen", 127.0.0.1 und [::1] bedeuten "nur der Server selbst". Datenbanken, Caches und Suchcluster gehören auf Loopback.
• Geschlossen und gefiltert sind für eine Datenbank beide gut; offen ist falsch.
• Prüfen Sie immer von außen, für IPv4 und IPv6, denn ss sieht die Firewall nicht.

Quiz

Aufgabe

Aufgabe Z5.1: Datenbankports von außen geschlossen. Führen Sie sudo ss -tulpn auf Ihrem Server aus und finden Sie heraus, auf welchen Adressen Ihre Dienste lauschen. Lassen Sie danach das Kursprogramm von außen prüfen, dass die Ports 3306, 5432, 6379, 9200 und 27017 Ihres Servers nicht erreichbar sind, für IPv4 und (falls Ihr Server einen AAAA-Record hat) IPv6. Geben Sie außerdem an, welche Dienste bei Ihnen auf 0.0.0.0 oder [::] lauschen. Das Programm baut nur eine Verbindung zu diesen fünf Ports auf und sendet nichts.

Weiterführende Informationen

• Ihren VPS absichern: die ersten fünf Minuten
• Handbuch ss(8): https://manpages.debian.org/trixie/iproute2/ss.8.en.html
• Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/