Ein verbreiteter Irrtum: "geschlossen" heißt sicher

Ein Missverständnis begegnet mir bei Portscans immer wieder: Leute gehen davon aus, ein Port sei entweder "offen" oder eben "sicher zu". Tatsächlich unterscheidet ein Scan drei Zustände, und der Unterschied zwischen den letzten beiden ist für die Sicherheit entscheidend.

Offen: Ein Dienst antwortet, der TCP-Handshake wird mit einem SYN-ACK bestätigt.
Geschlossen: Der Host ist erreichbar und antwortet aktiv mit einem RST-Paket. Kein Dienst lauscht hier, aber der Server selbst ist sichtbar.
Gefiltert: Es kommt gar keine Antwort. Eine Firewall verwirft das Paket kommentarlos. Von außen ist das kaum von einem abgeschalteten Host zu unterscheiden.

Für alle nicht benötigten Ports ist "gefiltert" das eigentlich wünschenswerte Ergebnis, nicht "geschlossen". Ein geschlossener Port verrät einem Angreifer immerhin, dass dort ein Server lauscht, den er weiter untersuchen kann. Eine Firewall, die Pakete stillschweigend verwirft, gibt diese Information gar nicht erst preis.

Was ein Portscan technisch macht

Jeder von außen erreichbare Dienst lauscht auf einem bestimmten TCP- oder UDP-Port. Ein Scan testet systematisch eine Liste von Ports und ordnet jeden einem der drei oben genannten Zustände zu. So lässt sich nachvollziehen, welche Dienste tatsächlich von außen ansprechbar sind, und ob eventuell etwas offen steht, das besser verborgen bliebe: Datenbanken, Admin-Oberflächen, Redis, Elasticsearch.

Wichtige Ports im Überblick

Port	Dienst	Relevanz
22	SSH	Fernwartung, sollte per Key-only-Auth und Fail2Ban abgesichert sein.
25 / 465 / 587	SMTP	E-Mail-Versand, 465 und 587 laufen über TLS.
53	DNS	Nameserver, TCP kommt vor allem bei größeren Antworten zum Einsatz.
80 / 443	HTTP / HTTPS	Webserver, Port 80 leitet meist auf 443 um.
110 / 995	POP3 / POP3S	Mail-Abruf, wird zunehmend von IMAP verdrängt.
143 / 993	IMAP / IMAPS	Mail-Abruf mit serverseitiger Ordnerstruktur.
3306	MySQL / MariaDB	Gehört nicht ins offene Internet.
5432	PostgreSQL	Genauso: privat halten.
6379	Redis	Ohne Authentifizierung und mit öffentlicher IP ein klassischer Einfallspunkt.
8080 / 8443	Alternative HTTP/HTTPS	Häufig Entwicklungs-Instanzen oder vergessene Admin-Oberflächen.

Wofür der Scan in der Praxis taugt

Nach dem ersten Missverständnis kommt meist die Frage, wofür man das Tool konkret braucht. Ein paar Situationen, in denen es sich bewährt hat:

Nach einem Deployment oder einer Firewall-Änderung kurz gegenprüfen, dass nur die gewünschten Dienste erreichbar sind.
Eine gerade angepasste UFW-, iptables- oder Cloud-Firewall-Regel testen, ob sie tatsächlich greift.
Bei einer Webanwendung, die nicht antwortet, herausfinden, ob der Webserver-Prozess das Problem ist oder die Firewall den Zugriff blockiert.
Vor einem DNS-Umzug sicherstellen, dass der neue Server bereits auf allen nötigen Ports erreichbar ist.

Verantwortungsvoller Umgang mit dem Tool

Rechtlicher Rahmen

Scannen Sie ausschließlich Systeme, für die Sie eine ausdrückliche Erlaubnis haben. Das Scannen fremder Server ohne Zustimmung kann in Deutschland als Ausspähen von Daten nach § 202a StGB oder als Vorbereitung einer Straftat nach § 202c StGB gewertet werden. Unser Tool führt nur begrenzte Scans auf einer Auswahl von Standard-Ports aus und loggt die anfragende IP zur Missbrauchsabwehr.

Absicherung in der Praxis

Firewall auf Deny-by-default stellen und nur explizit benötigte Ports freigeben.
SSH auf einen Nicht-Standard-Port legen, das reduziert zumindest den Grundrauschen automatisierter Bot-Scans.
Datenbanken an 127.0.0.1 oder ein internes Netz binden statt an eine öffentliche IP.
Fail2Ban oder CrowdSec gegen Brute-Force-Versuche einsetzen.
Nach Änderungen mit diesem Tool gegenprüfen, ob wirklich nichts durchgerutscht ist.

Datenschutz und Fair Use

Wir führen TCP-Connect-Scans gegen die angegebene IP auf einer Auswahl gängiger Ports durch. Die Abfrage ist ratenbegrenzt, personenbezogene Daten speichern wir nicht. Bitte respektieren Sie die Rechte Dritter.

Online Portscanner: TCP-Ports prüfen