TCP vs. UDP und Ports verstehen: Was hinter „Port offen“ steckt

IP-Adresse und Port: Hausnummer und Wohnung

Eine IP-Adresse bringt Daten zum richtigen Gerät. Auf diesem Gerät laufen aber meist mehrere Dienste gleichzeitig: ein Webserver, ein SSH-Zugang, vielleicht ein Modbus-Server. Damit ein ankommendes Paket beim richtigen Programm landet, gibt es Portnummern. Ein gängiges Bild: Die IP-Adresse ist die Hausnummer, der Port die Wohnung im Haus.

Portnummern sind 16 Bit lang, es gibt also die Werte 0 bis 65535. TCP und UDP haben dabei jeweils einen eigenen Nummernraum: TCP-Port 53 und UDP-Port 53 sind technisch zwei verschiedene Dinge, auch wenn beide für DNS registriert sind.

TCP: verbindungsorientiert und zuverlässig

Das Transmission Control Protocol ist aktuell in RFC 9293 spezifiziert. Es stellt laut RFC einen zuverlässigen Bytestrom bereit, der in der richtigen Reihenfolge ankommt. Dafür baut TCP vor der eigentlichen Datenübertragung eine Verbindung auf, den sogenannten Drei-Wege-Handshake:

1. Der Client sendet ein Segment mit gesetztem SYN-Flag.
2. Der Server antwortet mit SYN und ACK.
3. Der Client bestätigt mit ACK – die Verbindung steht.

Danach werden Daten nummeriert, bestätigt und bei Verlust erneut gesendet. Das kostet etwas Overhead, ist aber genau das, was du für Webseiten, Dateiübertragungen, Fernzugriff oder das Lesen von Registern einer Steuerung willst. Typische TCP-Dienste laut IANA-Register sind etwa SSH (22), HTTP (80), HTTPS (443), SMB (445, „microsoft-ds“), RDP (3389, „ms-wbt-server“) und Modbus TCP (502).

UDP: schlank und ohne Garantie

Das User Datagram Protocol ist in RFC 768 definiert, einem nur wenige Seiten langen Dokument aus dem Jahr 1980. Es bietet laut RFC ein Verfahren, um Nachrichten mit einem Minimum an Protokollmechanismen zu verschicken. Zustellung und Schutz vor Duplikaten sind ausdrücklich nicht garantiert; wer zuverlässige, geordnete Übertragung braucht, soll laut RFC TCP verwenden.

Es gibt also keinen Handshake und keine Bestätigung. Ein Datagramm wird losgeschickt, und ob es ankommt, muss bei Bedarf die Anwendung selbst prüfen. Das macht UDP schnell und geeignet für kurze Anfragen und Antworten. Bekannte UDP-Dienste sind DNS (53), NTP (123) und SNMP (161).

TCP vs. UDP im direkten Vergleich

• Verbindung: TCP baut vorher eine Verbindung auf, UDP nicht.
• Zuverlässigkeit: TCP bestätigt und wiederholt, UDP verschickt ohne Garantie.
• Reihenfolge: TCP liefert in der richtigen Reihenfolge, bei UDP ist das Sache der Anwendung.
• Overhead: TCP hat mehr Steuerinformationen und Zustände, UDP ist minimal.
• Einsatz: TCP für Daten, die vollständig ankommen müssen; UDP für kurze Abfragen, Zeitsynchronisation oder Multicast.

Wer legt fest, welcher Port wofür ist?

Die Zuordnung von Portnummern zu Diensten verwaltet die IANA (Internet Assigned Numbers Authority) im „Service Name and Transport Protocol Port Number Registry“. RFC 6335 teilt den Nummernraum in drei Bereiche:

• System Ports (0–1023): auch „Well Known Ports“, von der IANA vergeben, zum Beispiel 22, 80 oder 443.
• User Ports (1024–49151): auch „Registered Ports“, ebenfalls von der IANA vergeben, etwa 3389 oder 4840 für OPC UA.
• Dynamic Ports (49152–65535): private oder kurzlebige Ports, die nie vergeben werden. Clients nutzen sie typischerweise als Absenderport ihrer Verbindungen.

Wichtig: Das Register beschreibt, welcher Dienst eine Nummer zugewiesen bekommen hat, nicht, was auf einem bestimmten Gerät tatsächlich läuft. Ein Webserver kann auf Port 8080 lauschen, ein SSH-Dienst auf einem beliebigen anderen Port. Ein Scan-Ergebnis „Port 502 offen“ ist deshalb ein starker Hinweis auf Modbus TCP, aber kein Beweis.

Was „Port offen“ wirklich bedeutet

Ein Port ist kein Bauteil, das offen oder zu sein kann. Die Zustände beschreiben, wie ein Gerät auf eine Anfrage reagiert – und damit auch, was zwischen Scanner und Ziel passiert. Die Dokumentation des verbreiteten Scanners Nmap unterscheidet unter anderem:

• open: Ein Programm nimmt auf diesem Port aktiv TCP-Verbindungen oder UDP-Datagramme an.
• closed: Das Gerät ist erreichbar und antwortet, aber kein Programm lauscht auf dem Port.
• filtered: Ein Paketfilter verhindert, dass die Anfrage ankommt oder eine Antwort zurückkommt. Ob der Port offen ist, bleibt unklar.
• open|filtered: Es kam keine Antwort, und das kann sowohl „offen“ als auch „gefiltert“ bedeuten.

Warum TCP leichter zu prüfen ist als UDP

Bei TCP ist die Sache relativ klar. Antwortet der Server auf ein SYN mit SYN/ACK, ist der Port offen. Ist der Port geschlossen, sendet das Gerät laut RFC 9293 einen Reset (RST) zurück. Kommt gar nichts, filtert vermutlich eine Firewall.

Bei UDP ist es kniffliger. Ein offener UDP-Dienst antwortet oft nur auf eine Anfrage im passenden Protokollformat und schweigt auf ein leeres Paket. Ein geschlossener Port sollte laut RFC 1122 mit einer ICMP-Meldung „Port Unreachable“ antworten. Wenn aber eine Firewall diese ICMP-Meldungen verwirft, sieht ein geschlossener Port aus wie ein offener. Deshalb stehen UDP-Ergebnisse oft als „open|filtered“ im Bericht.

Der Standort des Scans entscheidet mit

Nmap weist ausdrücklich darauf hin: Die Zustände sind keine Eigenschaft des Ports, sondern beschreiben, wie der Scanner ihn sieht. Ein Scan aus demselben Netz kann einen Port als offen zeigen, während derselbe Port von außen gefiltert erscheint. Für deine Bewertung heißt das: Notiere immer, von wo aus du geprüft hast.

Ports verantwortungsvoll prüfen

Portprüfungen sind ein nützliches Werkzeug, um die eigene Umgebung zu verstehen. Ein paar Grundregeln gehören aber dazu:

1. Nur mit Berechtigung: Prüfe ausschließlich Netze und Geräte, für die du zuständig bist oder einen klaren Auftrag hast.
2. Vorsicht in OT-Netzen: Laut NIST SP 800-82 können aktive Scans empfindliche Geräte instabil machen oder deren Prozesszustand stören. Solche Scans sollten möglichst in geplanten Stillstandszeiten stattfinden.
3. Gezielt statt flächig: Lieber wenige, bekannte Ports auf ausgewählten Geräten prüfen als ganze Netze mit allen 65535 Ports.
4. Ergebnis einordnen: Ein offener Port ist nicht automatisch ein Problem. Entscheidend ist, ob der Dienst gebraucht wird und ob er angemessen abgesichert ist.

Genau diese Arbeitsweise unterstützt der OT Port Checker: Prüfungen starten nur, wenn du sie selbst auslöst, und konzentrieren sich auf typische Ports im lokalen Netz. Weitere Netzwerk- und Protokollbegriffe schlägst du im OT Lexikon nach.

Häufige Fragen zu TCP, UDP und Ports

Quellen

• RFC 9293: Transmission Control Protocol (TCP)
• RFC 768: User Datagram Protocol
• RFC 1122: Requirements for Internet Hosts
• RFC 6335: Port Number Registry Procedures
• IANA: Service Name and Transport Protocol Port Number Registry
• Nmap: Port Scanning Basics
• NIST SP 800-82 Rev. 3: Guide to OT Security

Stand: 15. Oktober 2026.