HTTP-poortgids: webverkeer op poort 80

HTTP is het verzoek- en antwoordprotocol dat wordt gebruikt door browsers, API's, webhooks, gezondheidscontroles en veel interne services. Op poort 80 maakt de client verbinding via TCP, verzendt een HTTP-verzoek en ontvangt headers en een antwoordtekst zonder eerst een TLS-handshake.

Omdat het verkeer niet wordt gecodeerd, kan iedereen die het netwerkpad kan observeren, URL's, cookies, headers, formuliergegevens en antwoordinhoud zien, tenzij de toepassing zijn eigen bescherming toevoegt. Voor openbare websites en geauthenticeerde applicaties moet poort 80 normaal gesproken omleiden naar HTTPS in plaats van privé-inhoud rechtstreeks aan te bieden.

Poort 80 is gewoon HTTP. Poort 443 is HTTPS, wat betekent dat HTTP wordt vervoerd binnen een TLS-gecodeerde sessie. De gebruikerservaring ziet er misschien hetzelfde uit in een browser, maar het beveiligingsmodel is anders: HTTPS valideert het servercertificaat en versleutelt verkeer tijdens de overdracht.

De meeste productielocaties gebruiken beide poorten samen. Poort 80 accepteert oude links, certificaatuitdagingen en nieuwe browserverzoeken en stuurt vervolgens een 301- of 308-omleiding naar de HTTPS-URL op 443. Daarna kan HSTS browsers vertellen automatisch de voorkeur te geven aan HTTPS.

Houd poort 80 open als u HTTP-naar-HTTPS-omleidingen nodig hebt, Let's Encrypt HTTP-01-uitdagingen, load balancer-gezondheidscontroles, CDN-oorsprongscontroles, eenvoudige interne statuseindpunten of compatibiliteit met oudere systemen die niet rechtstreeks op HTTPS kunnen starten.

Sluit of beperk poort 80 wanneer de service privé is, wanneer alle clients worden beheerd en HTTPS rechtstreeks kunnen gebruiken, of wanneer gewone HTTP onnodige blootstelling creëert. Als u het open houdt, zorg er dan voor dat het gedrag beperkt en voorspelbaar blijft: omleiding, uitdaging of statuscontrole in plaats van volledige toegang tot de applicatie.

Controleer voordat u TCP 80 opent of de bedoelde webserver, reverse proxy, ingangscontroller, CDN-oorsprong of load balancer op de juiste interface luistert. Bepaal of poort 80 inhoud moet aanbieden, moet doorsturen naar 443, gezondheidscontroles moet beantwoorden of alleen moet reageren op certificaatvalidatiepaden.

Een poortcontrole bevestigt de netwerkbereikbaarheid, maar vertelt u niet of uw omleidingsketen, cacheheaders, virtuele hostrouting of certificaatautomatisering correct zijn. Test zowel het TCP-pad als het HTTP-gedrag met een browser-, curl- en serverlogboeken.

Voer op Windows Server IIS, Nginx, Apache, Caddy of een andere webserver uit, bind de site aan TCP 80 en sta inkomend HTTP-verkeer toe in Windows Defender Firewall. Cloudservers hebben ook bijpassende cloudfirewall- of beveiligingsgroepregels nodig.

Configureer op Linux Nginx, Apache, Caddy, een containerpoortpublicatie of een ingangscontroller om op 80 te luisteren en sta vervolgens TCP 80 toe in ufw, firewalld, nftables, iptables of de firewall van de provider. Containers en Kubernetes-services moeten de poort publiceren of routeren op de host-, load balancer- of ingress-laag.

Op macOS wordt poort 80 meestal gebruikt voor lokale ontwikkelings- of laboratoriumservices. Voor geprivilegieerde poorten zijn mogelijk verhoogde machtigingen vereist, en lokale firewall- of routerregels bepalen nog steeds of andere machines de service kunnen bereiken.

Begin met een externe poortcontrole aan de hand van de openbare hostnaam of het IP-adres en poort 80. Als het resultaat open is, kunnen externe clients een TCP-verbinding tot stand brengen. Voer vervolgens curl -I http://example.com uit om statuscodes, omleidingen, serverheaders en cachegedrag te inspecteren.

Controleer op de server de luisteraars met ss -tlnp, netstat, lsof of PowerShell. Voor reverse proxy's en cloudimplementaties vergelijkt u hostfirewallregels, cloudbeveiligingsgroepen, load balancer-listeners, containerpoorttoewijzingen en applicatielogboeken, omdat elke laag HTTP kan blokkeren of verkeerd routeren.

Als poort 80 gesloten blijkt, is de webserver mogelijk gestopt, luistert hij alleen op localhost, gebruikt hij een andere poort of wordt hij geblokkeerd door de hostfirewall. Als er een time-out optreedt, kunnen pakketten worden verwijderd door een cloudfirewall, NAT-regel van de router, ISP-filter, CDN-instelling of upstream-beveiligingsbeleid.

Als poort 80 open is maar de pagina verkeerd is, inspecteer dan de virtuele hostvolgorde, hostheaderroutering, standaardserverblokken, proxy-upstreams, containertoewijzingen en DNS-records. Als er een omleidingslus optreedt, vergelijk dan virtuele HTTP- en HTTPS-hosts en zorg ervoor dat de proxy het oorspronkelijke schema correct doorgeeft.

Gebruik bewust poort 80. Leid applicatieverkeer om naar HTTPS, vermijd inloggegevens en gevoelige gegevens op gewone HTTP en bewaar alleen de eindpunten die bereikbaar moeten blijven. Voor openbare sites koppelt u de omleiding aan geldige certificaten op 443 en HSTS nadat u heeft bevestigd dat HTTPS stabiel is.

Registreer aanvragen voor poort 80, let op onverwachte paden en verwijder verouderde eindpunten die geen gewone HTTP meer nodig hebben. Als poort 80 alleen voor ACME- of statuscontroles is bedoeld, beperkt u de reacties op die paden, zodat de service gemakkelijker te begrijpen en te controleren is.