TCP- en UDP-poorten

Sommige protocollen op de transportlaag in de IP-stack, met name TCP en UDP, maken gebruik van poortnummers (ook wel logische poorten genoemd) om verschillende diensten tussen verschillende systemen en meerdere diensten op eenzelfde systeem te kunnen aanbieden.

Implementatie in de IP-stack

In de IP-stack bevinden TCP- en UDP-datagrams zich strikt genomen op de zogeheten host-to-host layer, die ruwweg correspondeert met de transport- en sessielagen (layer 4 & 5) van het OSI-model. In de IP-header van een IP-packet wordt met een 8-bits protocol identifier (tussen het TTL en het checksum-veld, 67 bits voorbij het begin van de header) aangegeven of het IP-packet een TCP- of UDP-datagram bevat (of een ander protocol zoals VINES). Het UDP- of TCP-datagram (bij TCP spreekt men ook wel van een TCP-segment, duidend op een deel van een meerdere segmenten die de datastream vormen), beslaat de payload van het IP-packet, en hebben elk op hun beurt ook weer een header. In zowel de UDP-datagram-header als de TCP-segment-header bevatten de eerste 16 bits de source port (bronpoort), en de daaropvolgende 16 bits de destination port (bestemmingspoort). Na deze 32 bits verschillen de headers aanzienlijk van elkaar.

Werking

Eén enkele computer kan meerdere sessies tegelijkertijd onderhouden met verschillende andere computers, en zelfs meerdere sessies naar één andere computer. Elke sessie wordt (boven laag 3 van het OSI-model) gekarakteriseerd door de 'protocol identifier' (UDP of TCP), het poortnummer aan de ene zijde van de sessie én het poortnummer aan de andere zijde van de sessie: de bron- en bestemmingspoorten, waarvan het perspectief afhangt van de richting van het datagram of segment. Al deze sessies worden dan via multiplexing door dezelfde netwerkaansluiting gestuurd. Het is dus ook mogelijk dat er tussen twee computers tussen dezelfde bron- en bestemmingspoorten gelijktijdig zowel een UDP- als een TCP-sessie actief is. Dit laatste is bijvoorbeeld gebruikelijk bij het DNS-protocol: queries en replies geschieden meestal via UDP-datagrams, maar indien de hoeveelheid data van de reply op de query meer dan 512 bytes zou bedragen en niet meer in de typische payload size van één UDP-datagram zou 'passen' (bijvoorbeeld – maar niet uitsluitend – bij zone transfers), stuurt de DNS-server deze data terug over een TCP-stream (de TCP-sessie), die geschikter is voor versturen van (relatief) veel data omdat in de IP-stack de TCP-session layer zich ontfermt over lost packets en packets die out of order (in de verkeerde volgorde) arriveren; dit maakt de implementatie/het programmeren van de DNS-software aanmerkelijk eenvoudiger.

In de TCP- en UDP-headers is een poortnummer een 16 bit-waarde. Er zijn dus in principe 65536 mogelijke TCP- of UDP-poorten. Server of daemon software (of sub-proces daarvan) kan luisteren voor inkomende service requests van een bron (deze bron kan óók dezelfde fysieke of virtuele machine/computer zijn) op een poort die geassocieerd is met de service (netwerkdienst) die door die software geboden wordt, of anderszins bekend is bij de bron om te gebruiken als bestemmingspoort. Dit betekent wachten tot het een aanvraag krijgt op die poort (of anders gezegd, op de socket die aan die poort gebonden is). Vervolgens kan het op deze aanvraag reageren, door het verzenden van een antwoord aan het programma dat de aanvraag heeft gestuurd, via de (socket gebonden aan die) bronpoort die dat programma daarvoor in gebruik heeft op de machine waar de aanvraag vandaan komt. Een webserver werkt op deze manier, met name door te luisteren op TCP-poorten 80 (HTTP) en 443 (HTTPS).

Wanneer een netwerkclient (programma) een service request initieert naar een service (port) op een andere computer of server, wordt op de clientcomputer eerst een source port (bronpoort) gealloceerd uit de daarvoor aangewezen (dynamische) reeks; de client zal – als respons verwacht wordt – op deze poort luisteren voor respons. (Op een SNMP-trap-UDP-datagram bijvoorbeeld volgt geen inherente respons in de zin van transport- of sessielaag). De service daemon die een request ontvangt, zal eventuele respons terugsturen naar het source address, gericht aan de source port zoals die in de UDP- of TCP-header naar de service daemon meegestuurd is. Die combinatie van bron- en bestemming-poortnummers (tezamen met bron- en bestemming-IP-adressen) is uniek voor elke sessie. Meerdere, gelijktijdige sessies van dezelfde client naar dezelfde service (poort) op een bepaalde server of computer zullen vanaf verschillende source ports vanaf de client komen, en kunnen zodoende van elkaar onderscheiden worden zodat de datastromen niet verward kunnen raken en/of bij de verkeerde subprocessen terechtkomen. Bij het laden van een webpagina vanaf een webserver bijvoorbeeld, zal de webclient doorgaans een aantal verschillende sessies nagenoeg tegelijk openen richting de webserver om de afzonderlijke delen van een webpagina (waarin meerdere <... src="..."> referenties kunnen zijn opgenomen, zoals voor HTML-frames en afbeeldingen) zo gelijktijdig mogelijk binnen te halen (in plaats van sequentieel).. Dit is veelal efficiënter, zodat alle content van een webpagina sneller laadt en ook visueel beter lijkt te verschijnen, met alle content zoveel mogelijk ineens op de juiste plaats en in de juiste (bedoelde) afmetingen en verhoudingen. Delen van webpagina's die in achtereenvolgende sessies worden ingeladen (of achtereenvolgens in dezelfde of een enkele sessie) kunnen het effect hebben dat gedurende het verschijnen van de pagina, de opmaak en plaats van gedeelten nog verspringen, veranderen van afmeting of lettertypes of stijl.

Poorttypes

• Systeempoorten (Engels: system ports): Gaande van 0 tot en met 1023, vaak "well known ports" (bekende poorten) of ook wel "privileged ports" genoemd, worden gebruikt voor fundamentele applicaties en worden toegekend door IANA. Softwareprocessen (services) die deze poorten willen gebruiken om op te luisteren dienen over 'root'-, 'administrator'- of systeemprivileges te beschikken vanuit het perspectief van een multi-user besturingssysteem.
• Gebruikerspoorten (Engels: user ports): Gaande van 1024 tot en met 49151, ook wel "registered ports" (geregistreerde poorten) genoemd, worden gebruikt door applicaties en worden volgens goed gebruik eveneens geregistreerd bij IANA.
• Dynamische poorten (Engels: dynamic ports): Gaande van 49152 tot en met 65535, worden dynamisch toegekend voor de duur van een bepaalde sessie en mogen vrij gebruikt worden.

De grenzen van de benoemde poortreeksen zijn formeel door IANA gereserveerd en het gebruik ervan is volgens RFC6335 vooralsnog voorbehouden aan IANA.. In de praktijk wordt lang niet altijd de "Best Current Practice" – zoals die door deze RFC wordt voorgeschreven en aangemoedigd – nageleefd.

Vaak gebruikte poorten

Hieronder volgt een selectie van vaak gebruikte poortnummers en hun service names:

Systeempoorten

poort	protocol	omschrijving
20	TCP	FTP: file transfer protocol
21	TCP	FTP Control
22	TCP	SSH: Secure Shell
23	TCP	Telnet
25	TCP	SMTP: Simple Mail Transfer Protocol, verzending van e-mail (MTA)
53	UDP, TCP	DNS: Domain Name System
67	UDP	DHCP Server
68	UDP	DHCP Client
69	UDP	TFTP: Trivial File Transfer Protocol
80	TCP	HTTP: Hypertext Transfer Protocol
110	TCP	POP3: post office protocol, ontvangen van e-mail
119	TCP	NNTP: Network News Transfer Protocol
123	UDP	NTP: Network Time Protocol
137	UDP	NetBIOS Name Service
138	UDP	NetBIOS Datagram Service
139	TCP	NetBIOS Session Service
143	TCP	IMAP: Internet Message Access Protocol
161	UDP	SNMP: Simple Network Management Protocol
162	UDP	SNMP-trap: Simple Network Management Protocol, getriggerde notificaties
389	TCP	LDAP: Lightweight Directory Access Protocol
443	TCP	HTTPS: HyperText Transfer Protocol over TLS/SSL
445	TCP	Direct Hosting / SMB (Samba) over TCP
465	TCP	SMTP: Simple Mail Transfer Protocol over TLS/SSL
546	UDP	DHCP Client (ipv6)
547	UDP	DHCP Server (ipv6)
569	TCP	MSN: Multiple Subscriber Number
587	TCP	SMTP: Simple Mail Transfer Protocol, verzending van uitgaande e-mail (MSA)
990	TCP	FTPS: FTP over SSL
993	TCP	IMAP: Internet Message Access Protocol over TLS/SSL
995	TCP	POP3: post office protocol, ontvangen van e-mail over TLS/SSL

Gebruikerspoorten

poort	protocol	omschrijving
1080	TCP	SOCKS proxy
1194	TCP, UDP	OpenVPN
3306	TCP, UDP	MySQL databasesysteem
3389	TCP	RDP: Remote Desktop Protocol
3689	TCP	DAAP: Digital Audio Access Protocol
5432	TCP, UDP	PostgreSQL databasesysteem
5800	TCP	VNC: Virtual Network Computing
5900	TCP	VNC: Virtual Network Computing
6346	TCP, UDP	Gnutella p2p netwerk
8080	TCP	HTTP alternatief voor onder meer proxyservers en Apache Tomcat

Onder UNIX/POSIX systemen

Onder UNIX, POSIX systemen of daarop gelijkende/daaraan conformerende systemen (zoals Cygwin) zijn doorgaans de poortnummers van officiële (door de IANA geregistreerde) services te vinden in de file /etc/services in het file system. In hoeverre de lijst met de daarin vermelde systeempoorten compleet en/of up to date is, is veelal afhankelijk van hoe recent het betreffende (besturings)systeem is geüpdatet; updates van de meest gangbare gebruikerspoorten in deze lijst kunnen opgenomen zijn in de systeemupdates, maar het kan ook voorkomen dat gebruikerspoorten en de bijbehorende service names pas in de lijst worden bijgeschreven wanneer de applicatie of service software die gebruikmaakt van deze poorten daadwerkelijk wordt geïnstalleerd (bijvoorbeeld door middel van installatie-scripts, package managers of soms zelfs door een handmatige installatie waarbij de file ook handmatig aangepast moet worden). Dit kan per platform, distributie en/of (applicatie)software sterk verschillen, en men kan er zeker niet van uitgaan dat de services-file op zo'n systeem altijd uitputtend/compleet en recent is.

Alle regels met services en poorten waarin bijvoorbeeld het de protocolnaam http voorkomt (inclusief die waar http deel uitmaakt van de protocolnaam, of waar het genoemd is in het commentaardeel) zijn te vinden met de opdracht:

$ grep -i http /etc/services
# Updated from http://www.iana.org/assignments/port-numbers and other
# sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services .
http		80/tcp		www		# WorldWideWeb HTTP
http		80/udp				# HyperText Transfer Protocol
https		443/tcp				# http protocol over TLS/SSL
https		443/udp
http-alt	8080/tcp	webcache	# WWW caching service
http-alt	8080/udp

Zoals bovenstaand voorbeeld laat zien, levert dit ook de comment lines in de file op waar http in genoemd is, die alleen informatief verwijzen naar websites – deze regels hebben echter geen enkele betrekking op poorten of services. Om dit te mijden (bijvoorbeeld voor gebruik in shell scripts), kan een extra regexp filter in de "zoekopdracht" worden opgenomen:

$ grep /etc/services http | grep -v ^#

Dit onderdrukt de output van alle regels die beginnen met het karakter # (de comment lines). Om de zoekopdracht strikt te beperken tot de service names die begínnen met http kan de volgende opdracht gebruikt worden:

$ grep ^http /etc/services

Om te zoeken naar alléén de exacte http service name regels, en die met verwante/gelijkende namen uit te sluiten, biedt de volgende opdracht uitkomst:

$ grep '^http\s' /etc/services
http		80/tcp		www		# WorldWideWeb HTTP

http 80/udp # HyperText Transfer Protocol

De quotes om de regular expression zijn hier noodzakelijk door het gebruik van de backslash, die op de command line anders een 'escape-functie' heeft (voorkomt het interpreteren van het erop volgende karakter door de shell in plaats van door het commando). In plaats van de quotes kan daarom ook een dubbele backslash (^http\\s) worden gebruikt; beide varianten geven de bedoelde regexp door aan het grep commando.

Volledigheidshalve nog een voorbeeld om de (regel met de) service name te vinden bij een specifiek poortnummer, in dit voorbeeld poortnummer 80, dus het omgekeerde van de bovenstaande voorbeelden. In de regels worden de poortnummers altijd voorafgegaan door een whitespace (een 'blank character' zoals een spatie of een tab), en altijd direct gevolgd door een forward slash:

$ grep '\s80/' /etc/services

Om een actueel overzicht te verkrijgen van gealloceerde en/of in gebruik zijnde poorten en hun status kan onder deze systemen gebruik gemaakt worden van de commando's (programma's) netstat en (indien beschikbaar) lsof.

Software

Een firewall is een programma dat aanvragen die over een netwerk (bijvoorbeeld internet) binnenkomen kan filteren. Op transportlaag-niveau kan deze filtering dan gebeuren door aanvragen met bepaalde poortnummers tegen te houden. Die poorten noemt men dan gesloten.

Er bestaan programma's die scannen welke poorten er 'open staan' (op welke poorten er een service daemon actief luistert) op een machine met een bepaald IP-adres of hele IP-reeksen. Dat gebeurt soms met kwade bedoelingen uitsluitend om te zien of de betreffende computer gekraakt kan worden en dan een potentieel doelwit is (voor hackers). Het kan ook een preventieve controle zijn om te beoordelen in hoeverre een computer te kraken is. Enkele programma's om poorten mee te scannen zijn bijvoorbeeld nmap en nessus. Effectieve firewalls kunnen zulke scans detecteren en latere service requests of zelfs alle verdere packets (van de scannerbron) blokkeren en/of negeren ('droppen').

Hardware

Behalve software bestaat er ook hardware die op TCP/UDP-poort-niveau opereert en/of manipuleert. Zo bestaan er bijvoorbeeld hardwarematige (of dedicated) firewalls (onder meer van Nokia, voorzien van Checkpoint-software), maar ook vrijwel elke industriële en consumenten/SOHO-router heeft functionaliteiten die ingrijpen op poort-niveau. Dan bestaan er voorts nog apparaten met als voornaamste functionaliteit het manipuleren van netwerkverkeer op de transport- en sessielaag, de zogeheten layer-4 switches. Deze worden voornamelijk door Internet Service Providers (ISP's) of instellingen en bedrijven met eigen serverparken ingezet om de belasting (load) van (logische) netwerkdiensten – dus op grond van karakteristieken op laag 4, voornamelijk de TCP/UDP-bestemmingspoort – te verdelen over meerde fysieke systemen (of in elk geval, op laag 3 van het OSI-model te verdelen over meerdere IP-adressen, die dan in de praktijk corresponderen met evenzoveel fysieke servers). Ze worden daarom ook wel load balancers genoemd. Dit verdelen gebeurt meestal middels een round-robin-strategie, maar ook andere strategieën bestaan. Deze layer 4-switches zijn doorgaans zodanig geavanceerd dat ze kunnen detecteren wanneer een van de servers niet meer reageert of functioneert (down is), zodat inkomende service requests dan niet meer naar die server worden gestuurd. Layer 4-switches bieden zo behalve de mogelijkheid om de belasting te verdelen over meerdere machines, ook nog eens redundantie. Ze worden toegepast voor netwerkdiensten als e-mail, usenet en webhosting.

Network Address Translation/Port Address Translation

Als een computer, firewall of router Network Address Translation (NAT) toepast, gaat dit vaak hand in hand met Port Address Translation (PAT). NAT wordt vooral toegepast om met meerdere (private) computers (meestal de LAN zijde) of andere apparaten één enkel (public) IP-adres te gebruiken (meestal de WAN zijde). Wanneer twee private clients dezelfde bronpoort(en) gebruiken voor uitgaande UDP- of TCP-packets (vooral wanneer dat naar hetzelfde doeladres en dezelfde service daar), zou dat zonder PAT dataverstrengeling kunnen opleveren: de software of het apparaat dat de NAT verzorgt, kan dan van de responspackets niet terug herleiden welk packet naar welke private client doorgestuurd (geforward) moeten worden. Door het wijzigen van de bronpoort aan de public of WAN-zijde en dit bij te houden, kunnen de juiste terugkomende responspackets worden terugvertaald naar de juiste IP-adressen en poortnummers aan de private of LAN-zijde. Dit geschiedt allemaal door vervangen van de betreffende adressen in de IP-headers en poortnummers in de TCP- en UDP-headers. NAT en PAT zijn ook essentieel voor het functioneren van bovengenoemde layer 4-switches. Bij veel routers is het eenvoudig mogelijk een overzicht op te vragen van alle recente en actieve sessies met de bijbehorende adres- en poortvertalingen.

Port Address Translation hoeft niet alleen een noodzakelijke bijkomstigheid van NAT zijn, het kan ook een doel op zichzelf zijn: bepaalde poorten aan de public/WAN-zijde kunnen voor inkomende service requests worden vertaald en doorgestuurd naar specifieke private clients en zo nodig andere poorten aldaar.

Zie ook

• Client-servermodel
• Remote Procedure Call
• Client-To-Client Protocol

Bronnen, noten en/of referenties