# Nätverksport ## Vad det är En nätverksport är ett 16-bitars tal i huvudet på varje TCP- och UDP-segment, och talet säger åt den mottagande maskinen vilket av dess program datan ska till. Adressen tar paketet till rätt värddator; porten tar det till rätt process när det väl är framme. I vardagligt tal heter det bara port, portnummer när man vill vara exakt, och i plural, portar, menas oftast de som en server lyssnar på. Ordet har ingenting med den fysiska porten på en switch att göra, och inte heller med att porta programvara till en annan plattform. Fältet är 16 bitar brett, så det rymmer 65 536 värden, från 0 till 65535, och TCP och UDP har var sin uppsättning: TCP-port 53 och UDP-port 53 är två skilda saker som DNS råkar använda båda två. TCP-specifikationen, RFC 9293, definierar en socket som en internetadress sammanfogad med en port, och en anslutning som ett par socketar. Det ger fyra värden: klientens adress, klientens port, serverns adress och serverns port. Det förklarar också hur en enda serverport kan bära tusentals samtal samtidigt. Varje samtal skiljer sig i minst ett av de tre andra värdena, oftast i klientporten. RFC 6335 delar intervallet i tre. Portarna 0–1023 är systemportar (System Ports), 1024–49151 är användarportar (User Ports) och 49152–65535 är dynamiska portar (Dynamic Ports), som IANA aldrig tilldelar någon. IANA för registret som kopplar ett tjänstenamn till ett nummer: 22 för SSH, 53 för DNS, 443 för HTTPS och 5432 för PostgreSQL. En registrering är en konvention som klienter förlitar sig på. Vilket program som helst kan lyssna på vilket ledigt nummer som helst, och det är så SSH hamnar på en port som ingen skulle gissa. Klientsidan av en anslutning får för det mesta en port som den aldrig har valt. När ett program ansluter utåt plockar operativsystemet en ur sitt intervall av tillfälliga portar (ephemeral ports), och Linux använder som standard 32768–60999 i stället för IANA:s dynamiska intervall. Att be om att binda port 0 betyder samma sak: ge mig vilken ledig port som helst. ## Varför det spelar roll Bakom varje port ligger ett beslut om exponering: vilka program som svarar utifrån, och på vilken adress. En port utan lyssnare ger ett avvisat anslutningsförsök. En port med en lyssnare är ett stycke mjukvara som vem som helst som når adressen kan prata med, buggar inräknade. Den billigaste tjänsten att säkra är den som lyssnar på 127.0.0.1, eftersom paket från andra maskiner aldrig når loopback-adressen, vad brandväggen än säger. Den första frågan för varje tjänst är alltså om den över huvud taget behöver nås utifrån. En databas som bara applikationen på samma maskin pratar med hör hemma på loopback. Ett verktyg som bara administratörer använder kan också stanna på loopback och nås via en hoppserver eller ett VPN. Det som blir kvar, typiskt 80 och 443 för en webbplats och en port för SSH, är den publika ytan. Att hålla den kort är lika mycket ett kostnadsbeslut som ett säkerhetsbeslut, eftersom varje publik lyssnare ska patchas, loggas och ha en brandväggsregel som matchar den. Den andra frågan är numret. Standardportar kostar ingenting i konfiguration: webbläsare, klienter och restriktiva nätverk räknar med 443 och släpper igenom den. Att flytta SSH från 22 minskar bruset från skannrar som bara provar standardporten, och loggarna blir lättare att läsa. Men en skanning av hela intervallet hittar den ändå, och varje verktyg som hänvisar till porten måste lära sig det nya numret. Det är den sista delen som team glömmer. Den tredje gäller privilegier och delning. På Linux behöver en process root eller förmågan (capability) CAP_NET_BIND_SERVICE för att binda en port under 1024, om inte ip_unprivileged_port_start har sänkts från sitt standardvärde 1024. Normalt äger dessutom ett enda program en viss kombination av adress och port, så två tjänster som båda vill ha 443 behöver något framför sig som delar upp trafiken. Oftast är det en omvänd proxy (reverse proxy) som läser vilket värdnamn klienten bad om. ## Så ser det ut i praktiken Tre delar av företagets infrastrukturarbete hänger på portnummer: en handlar om var en lyssnare sitter, en om en port som flyttade och en om att ta reda på vilka portar som faktiskt är öppna. När företaget satte upp sin egen git-forge i juli 2026 [lades forgens SSH-lyssnare på loopback-gränssnittet, port 23231](/sv/portfolio/deployed-the-companys-own-git-forge-121/), och den som sitter utanför når den via en hoppserver. Antalet publika portar stod därmed still. En multiplexer som skulle servera HTTPS och git över SSH från en och samma publika port, genom att titta på de första byten i varje anslutning, är skriven och avslagen. En lyssnare som ingen använder skulle ändå behöva försvaras. I augusti 2026 fann en härdningsgranskning att SSH hade flyttats till port 1986 under värdens första härdning, medan jailen som spärrar intrångsförsök fortsatte att bevaka 22. [Varje spärr som jailen skrev gällde en port där ingenting lyssnade](/sv/portfolio/found-three-ssh-brute-force-protections-that-never-worked-110/), så skyddet hade aldrig en enda gång slagit till. Åtgärden var liten. Det som blev kvar var en regel: varje säkerhetsskydd paras ihop med en kontroll som faktiskt prövar det. Värden har 464 MB minne och ingen dashboard, så frågorna om den besvaras av [sju skrivskyddade rapportroller som återger den levande maskinen som Markdown](/sv/portfolio/built-seven-read-only-host-reporting-roles-120/). Faktarapporten listar de lyssnande socketarna, alltså portarna så som de finns i en körande systemkärna och inte så som konfigurationen beskriver dem. Bland de verkliga saker som rapporterna har hittat fanns en lyssnande port som ingen deklaration nämnde. ## Var det går fel **En tjänst som var tänkt för maskinen själv svarar hela internet.** Många program lyssnar som standard på alla adresser, vilket syns som `0.0.0.0`, `[::]` eller `*` i socketlistan, och en databas eller adminpanel som skulle vara lokal är då ett enda brandväggsmisstag från att exponeras. Sätt bindningsadressen uttryckligen till `127.0.0.1` eller `::1` och bekräfta den i kolumnen för lokal adress: ```sh ss -tlnp ss -ulnp ``` **Ett skydd fortsätter att bevaka en port som tjänsten har lämnat.** Tjänsten flyttade till ett nytt nummer, och brandväggsregeln, jailen, sonden för övervakning eller en klientkonfiguration nämner fortfarande det gamla. Vart och ett av verktygen fortsätter att fungera korrekt mot en port där ingen daemon lyssnar. Håll numret i en enda variabel som alla som använder det läser, och lägg till en kontroll som jämför den lyssnande socketen med det som varje skydd bevakar. **Utgående anslutningar börjar fallera under last med ”Cannot assign requested address”.** Varje utgående anslutning tar en lokal port ur det tillfälliga intervallet, och en stängd anslutning håller sina fyra värden reserverade i TIME_WAIT en stund efteråt. Med standardintervallet i Linux, 32768–60999, kan en klientadress hålla 28 232 anslutningar mot samma serveradress och port, öppna eller nyss stängda. En proxy eller arbetsprocess som öppnar en ny anslutning per begäran mot en och samma backend gör slut på dem. Återanvänd anslutningar med keep-alive eller en pool först; att bredda intervallet eller lägga till källadresser köper bara marginal. **En tjänst som startas som vanlig användare stannar med ”Permission denied” på port 80.** Att binda under 1024 kräver privilegier. Ge tjänsten förmågan CAP_NET_BIND_SERVICE i dess unit-fil för systemd, lägg den på en hög port bakom en omvänd proxy eller, på en värd där varje lokal användare är betrodd, sänk ip_unprivileged_port_start. Att köra hela tjänsten som root för att komma åt en enda port är den sämsta av avvägningarna. **Starten stannar med ”Address already in use”.** En annan process håller porten, ofta en gammal kopia av samma tjänst som fortfarande håller på att stänga ned, eller en andra tjänst med samma standardvärde (8080 är ett populärt). `ss -tlnp` visar vem som äger den. Bestäm vilken tjänst som äger numret och ge var och en en uttrycklig port i sin konfiguration, i stället för att förlita dig på standardvärden. ## Läs mer - [RFC 9293, section 4: Glossary](https://www.rfc-editor.org/rfc/rfc9293#section-4) — TCP-specifikationens egna definitioner av port, socket och anslutning. - [RFC 6335: IANA Procedures for the Management of the Service Name and Transport Protocol Port Number Registry](https://www.rfc-editor.org/rfc/rfc6335) — de tre portintervallen och hur nummer inom dem tilldelas. - [Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) — IANA:s lista över vilken tjänst som är registrerad på vilket nummer. - [RFC 768: User Datagram Protocol](https://www.rfc-editor.org/rfc/rfc768) — UDP-specifikationen på tre sidor, käll- och destinationsportar inräknade. - [RFC 6056: Recommendations for Transport-Protocol Port Randomization](https://www.rfc-editor.org/rfc/rfc6056) — hur en klient bör välja sina tillfälliga portar så att de blir svåra att gissa. - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) — inställningar i Linux-kärnan, bl.a. ip_local_port_range och ip_unprivileged_port_start.