NatJack: NAT-tabellattacker förklarade, vem som påverkas och vilka åtgärder som behövs

NatJack är en attackklass mot enheter som använder Network Address Translation (NAT): routrar, brandväggar, hypervisornätverk, containerbryggor och NAT-gateways i molnet. En angripare som befinner sig bakom samma NAT-enhet som sitt offer manipulerar dess NAT-tabell så att svar från internet inte längre når offret utan angriparen. Därmed kan befintliga TCP-anslutningar tas över, DNS-svar fångas upp och förfalskas eller NAT-enheten blockeras för alla andra användare. Forskningen publicerades av Malcolm Stagg (SODIUM-24, LLC) den 6 augusti 2026 på Black Hat USA, samordnad via CERT/CC (VU#268870) med 13 tillverkare. I 23 testade produkter rapporterades 95 enskilda fynd; enligt vitboken var varje testad enhet med NAT sårbar för minst en del av attackerna.

Kort slutsats: För ett hemnät med egna enheter behövs inga åtgärder. Åtgärder krävs där externa eller opålitliga användare och arbetslaster använder samma NAT-enhet som era produktiva system: gäst-wifi vid företagsbrandväggen, Docker- och Kubernetes-värdar med externa images, test-VM:ar i NAT-nätet på en Hyper-V-värd samt hosting- och coworkingmiljöer. Den mest effektiva åtgärden är kryptering (TLS även internt, säkrat DNS), den näst mest effektiva är att separera förtroendezoner på egna NAT-enheter.

Vad en NAT-tabell gör

Bakom en NAT-enhet har enheterna privata adresser enligt RFC 1918, till exempel 10.0.10.21. När en enhet upprättar en anslutning utåt ersätter NAT-enheten avsändaradress och port med sin externa adress och en extern port och sparar kopplingen i NAT-tabellen. När serverns svar kommer tillbaka slår enheten upp i tabellen vilken intern enhet det tillhör. Under Linux hanterar Netfilter detta med sin anslutningsspårning conntrack; de flesta vanliga routrar, OpenWRT, Docker och Kubernetes använder denna kod.

Ursprungligen var NAT en övergångslösning för bristen på IPv4-adresser och ingen säkerhetsgräns. I praktiken har det dock blivit en sådan: På lager 2 separerar VLAN, portisolering, Dynamic ARP Inspection och vSwitch-isolering enheterna ordentligt från varandra, och ARP-spoofing är knappast längre möjligt i välskötta nät. På lager 3/4 sammanförs de separerade näten däremot ofta i samma NAT-enhet igen. Det är just här NatJack angriper.

Så fungerar attacken

Alla NatJack-varianter följer samma mönster: Angriparen får NAT-enheten att ta bort offrets tabellpost och skapar omedelbart en egen post med samma externa parametrar. NAT-enheten vidarebefordrar sedan serverns nästa svar till angriparen. Varken servern eller offret får något felmeddelande.

Det möjliggörs av beteenden som utformades för ett samarbetsvilligt nät och som är meningsfulla där:

• Loose Mode: Netfilter lägger som standard även till TCP-anslutningar i tabellen vars handskakning den inte har sett. Detta ska bevara anslutningar efter en omstart av routern eller ett vägbyte, men tillåter också att poster skapas utan en giltig anslutningsuppbyggnad.
• Generös kontroll av reset-paket: NAT-enheten kontrollerar sekvensnummer mindre strikt än ändpunkterna själva, så att den inte kastar bort giltiga paket. Paket som en ändpunkt skulle ignorera kan NAT-enheten ändå bedöma som ett anslutningsslut.
• Port Preservation och Endpoint-Independent Mapping: Netfilter använder om möjligt den interna porten som extern port och fortsätter att använda en redan tilldelad koppling för alla mål. Beteendet vid portkonflikter gör det möjligt att härleda vilka portar andra enheter använder just nu.
• Begränsad tabell: Om tabellen är full kastar Netfilter slumpmässigt bort ännu ej bekräftade poster, till exempel öppna DNS-förfrågningar. Bekräftade anslutningar ligger kvar i upp till fem dagar.

För de flesta varianter måste angriparen kunna skicka paket med förfalskad avsändaradress. Om angripare och offer finns i samma subnät räcker det med en enhet eller container med råsocket-rättigheter (NET_RAW). Upstream-varianten fungerar även över subnäts- och VLAN-gränser; då behöver angriparen dessutom en egen server på internet som kan skicka paket med förfalskad avsändaradress. Vitboken beskriver paketsekvenserna och proof-of-concept-koden; den aviserade tekniska rapporten med testframework har ännu inte publicerats.

De fem sårbarheterna i korthet

Vitboken beskriver fem sårbarheter. Bedömningarna är typiska värden och kan avvika beroende på produkt.

Alla protokoll utan stark kryptering påverkas: HTTP, DNS via UDP, Telnet-baserade administrationsprotokoll samt e-postprotokoll som SMTP och IMAP när de körs utan TLS. Vid en TLS-anslutning kan angriparen visserligen avbryta anslutningen, men får inga läsbara data och kan inte injicera något. Vitboken påpekar dessutom att attackpaket kan skickas med reducerad TTL så att de når NAT-enheten men inte kommer vidare in i nätet. Det försvårar upptäckt.

Jämfört med ARP-spoofing har NatJack en liknande effekt, men kringgår etablerade skyddsmekanismer på lager 2. Tidigare arbete av Yang et al. (CVE-2023-30305 till CVE-2023-30314) visade TCP-kapning via NAT-tabeller i wifi-routrar med osäkra icke-standardalternativ; NatJack fungerar i standardkonfigurationen.

Vem som påverkas

Enligt vitboken är praktiskt taget alla Linux-baserade routrar sårbara, liksom system med helt annan kodbas. Följande översikt sammanfattar läget i patchmatrisen på natjack.io (senast uppdaterad den 19 augusti 2026).

Behövs åtgärder?

Avgörande är vem som finns bakom samma NAT-enhet; huruvida er routermodell finns med i listan är sekundärt. Varje variant förutsätter att angriparen redan kontrollerar en enhet, VM eller container bakom NAT-enheten. Där det endast rör egna, betrodda enheter skulle en angripare med den åtkomsten ändå ha enklare vägar. Vitboken konstaterar därför att de flesta hemanvändare inte påverkas allvarligt, medan konsekvenserna är betydligt svårare för företag och tjänsteleverantörer.

I schweiziska små och medelstora företag är mellannivån vanligast: Gäst-wifi är separerat med VLAN men går ut på internet via samma brandvägg som företagsnätet. VLAN-separeringen förhindrar ARP-spoofing och direkt åtkomst, men båda näten delar fortfarande NAT-tabellen. För downstream-varianten skulle angriparen behöva befinna sig i samma subnät som sitt offer; upstream-varianten fungerar över VLAN-gränsen, men är mer komplicerad och kräver en extern server. Åtgärder är tydligt nödvändiga där externa personer finns i samma subnät (hotell-, vårdmottagnings- eller skol-wifi utan klientisolering) och på container- och Kubernetes-värdar där arbetslaster med olika förtroendenivåer körs. Ett komprometterat npm- eller PyPI-paket i en container räcker där som utgångspunkt.

För e-posttjänster är det värt att särskilt granska interna anslutningar utan TLS: skannrar, verksamhetsapplikationer och övervakningssystem som levererar okrypterat till ett internt relä via port 25, samt IMAP utan TLS. Artikeln E-postleverans via ett relä: kontrollera TLS och autentisering beskriver hur du kontrollerar TLS och autentisering vid reläet.

Åtgärder

Vitbokens rekommendationer kan ordnas i fem lager. De skiljer sig åt i vilka sårbarheter de hjälper mot.

Kryptering

TLS på alla anslutningar, även mellan interna system, gör kapade TCP-anslutningar värdelösa: Angriparen kan avbryta dem men varken läsa dem eller injicera data. För DNS rekommenderar vitboken DNSSEC mot förfalskade svar samt DNS over HTTPS eller DNS over TLS mot avlyssning. Kryptering hjälper inte mot portavslöjande och Denial of Service.

Separation av förtroendezoner

Driftssätt opålitliga enheter och arbetslaster i egna subnät och VLAN, med L3/L4-ACL:er som förhindrar all åtkomst till betrodda värdar. Mer effektivt är en egen NAT-enhet eller en egen extern adress per förtroendezon, eftersom grunden för alla varianter saknas utan en gemensam NAT-tabell. I molnet innebär det att betrodda och externa arbetslaster inte ska drivas bakom samma NAT Gateway och att dedikerade i stället för delade IP-adresser ska användas för serverless-tjänster. I Kubernetes körs opålitliga poddar på egna noder.

Anti-spoofing

Aktivera IP Source Guard eller en jämförbar funktion på switchen respektive åtkomstpunkten och uRPF (Reverse Path Filtering) på routern, så att klienter endast kan skicka med sin egen adress. I containrar förhindrar borttagning av capabilityn NET_RAW att en komprometterad process kan skapa förfalskade paket. Docker tilldelar denna capability som standard.

docker run --cap-drop=NET_RAW --user 1000:1000 example/app:1.4

Alternativ förklarade

Alternativ	Effekt
run	Startar en ny container från en image
--cap-drop=NET_RAW	Tar bort containerns rätt till råsockets; förfalskade IP-paket kan då inte längre skapas
--user 1000:1000	Kör processen med användar- och grupp-ID 1000 i stället för som root
example/app:1.4	Containerns image och tagg (exempel)

ping behöver i vissa images NET_RAW; på aktuella kärnor fungerar det vanligen även utan via oprivilegierade ICMP-sockets. I Kubernetes hanteras detta av containerns securityContext:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - NET_RAW

Alternativ förklarade

Alternativ	Effekt
runAsNonRoot: true	Kubernetes startar inte containern om den skulle köras som root
allowPrivilegeEscalation: false	Hindrar processen från att få ytterligare rättigheter, till exempel via setuid-program
capabilities.drop: [NET_RAW]	Tar bort råsocket-capabilityn, på samma sätt som --cap-drop=NET_RAW i Docker

Pod Security Standard restricted kräver att containrar avger alla capabilities (drop: [ALL]), och omfattar därmed NET_RAW.

NAT-härdning

Installera tillgängliga uppdateringar: kärna respektive firmware med Netfilter-fixen, Windows-uppdateringarna från juli och augusti 2026 på Hyper-V-värdar med NAT-nät och FreeBSD från 15.0.0. Om kärnan i er distribution innehåller fixen för CVE-2026-63913 framgår av kärnpaketets ändringslogg.

På Linux-routrar och containervärdar kan Loose Mode dessutom stängas av. Därefter tar Netfilter endast upp TCP-anslutningar med fullständig handskakning i tabellen.

sysctl net.netfilter.nf_conntrack_tcp_loose
sudo sysctl -w net.netfilter.nf_conntrack_tcp_loose=0
echo "net.netfilter.nf_conntrack_tcp_loose = 0" | sudo tee /etc/sysctl.d/90-natjack.conf

Alternativ förklarade

Alternativ	Effekt
sysctl <schlüssel>	Visar aktuellt värde; 1 innebär att Loose Mode är aktivt (standard)
-w	Skriver värdet direkt till den körande kärnan, utan omstart
nf_conntrack_tcp_loose=0	Stänger av övertagandet av anslutningar utan observerad handskakning
tee /etc/sysctl.d/90-natjack.conf	Sparar inställningen permanent så att den överlever en omstart

Loose Mode finns av en anledning: Efter en omstart av routern eller en failover i ett kluster med conntrackd avbryts befintliga anslutningar utan det. Kontrollera detta före ändringen, särskilt på högtilgängliga brandväggar. Vitboken påpekar uttryckligen att flera åtgärder måste väga säkerhet, tillgänglighet och protokollkompatibilitet mot varandra.

Ytterligare inställningar, om produkten erbjuder dem:

• Anslutningsgräns per klient: Vitboken rekommenderar en gräns på cirka 10 000 samtidiga anslutningar per klient. I pf-baserade brandväggar som OPNsense och pfSense finns inställningen i de avancerade alternativen för brandväggsregeln (pf: max-src-states).
• Stäng av Port Preservation och Endpoint-Independent Mapping: Försvårar portidentifiering. I pf ersätter en NAT-regel utan static-port källporten slumpmässigt. Observera att vissa VoIP- och peer-to-peer-applikationer bygger på fasta mappningar.
• ISN-randomisering: I pf via modulate state i stället för keep state. Regler med flags any bör undvikas eftersom de tillåter anslutningar utan giltig handskakning.

Övervakning

Vitboken nämner flera tecken på attackförsök: en full eller nästan full NAT-tabell, paketflöden från en klient över ett stort intervall av källportar, samma IP-adress vid två MAC-adresser eller en MAC-adress med flera IP-adresser, flöden av RST-paket med varierande sekvensnummer, sekvensnummer långt utanför TCP-fönstret och paket med påfallande låg TTL. Under Linux visas tabellens fyllnadsgrad genom en jämförelse av två värden:

cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

Alternativ förklarade

Alternativ	Effekt
nf_conntrack_count	Antal poster som för närvarande är upptagna i tabellen
nf_conntrack_max	Tabellens maximala storlek; beror på arbetsminnet (vid 4 GB eller mer 262 144 poster)

Om det första värdet varaktigt ligger nära det andra är det anledning att utreda, oavsett NatJack. Många brandväggar visar samma nyckeltal som “State Table” eller “Sessions” i dashboarden och kan larma vid ett tröskelvärde.

Bedömning

NatJack utnyttjar antaganden som har funnits i NAT-implementationer i årtionden, inte ett enskilt programmeringsfel. Därför finns det heller ingen patch som helt eliminerar attackklassen: Linux och Windows har ökat svårighetsgraden, AWS har förbättrat på serversidan, och många enheter förblir utan uppdatering. De långsiktiga åtgärderna ligger i den egna arkitekturen: krypterade protokoll även i det interna nätet och ingen gemensam NAT-enhet för system som ni litar på i olika hög grad. Den som har genomfört båda kan hantera NatJack enligt normal patchrytm.