Ingen tun0? Match dekrypteret IPsec i nftables med meta ipsec

Du forventer en tunnelgrænseflade, leder efter den, og der er ikke noget at matche i firewallen. Det er normalt for en politikbaseret gateway: den krypterede udveksling ankommer på den fysiske grænseflade, og den dekrypterede indre pakke, der derefter videresendes, ses også som ankommende på samme grænseflade. Der er ingen tun0, fordi intet har oprettet en.

Den indre anmodning er stadig en særskilt pakke med sin egen kilde, destination og tjeneste, og kernen ved, hvilken sikkerhedsassociation den kom ud af. Det er den viden, en firewallregel kan matche.

To pakker, én grænseflade

Forestil dig den indgående retning. En ESP- eller UDP-indkapslet pakke ankommer, kernen finder den matchende politik, dekrypterer den og giver den klare pakke videre til videresendelsesstien. En regel, der kun ser på grænsefladens navn, kan ikke skelne den pakke fra enhver anden trafik, der ankommer på samme ledning.

Det, der kendetegner den, er den indgående sikkerhedsstikontekst, der er knyttet til pakken. nftables viser den som meta ipsec exists, hvilket er sandt, når pakken ankom gennem en IPsec-sikkerhedssti. Kombiner den med klientpuljen, destinationen og tjenesten, og reglen bliver specifik nok til at være sikker.

At udelade konteksten er den almindelige fejl, og det er en sikkerhedsfejl snarere end en kosmetisk. En regel, der accepterer alt fra klientpuljen, accepterer lige så gerne en forfalsket pakke fra det lokale netværk, fordi kildeadressen ikke i sig selv er bevis for noget. Sikkerhedsstikonteksten er den billigste måde at gøre kilden meningsfuld. Skriv reglen med den fra starten i stedet for at tilføje den efter en revision.

Skriv videresendelsesreglen

Antag en autentificeret IPv4-fjerntjeneste med klienter i 10.90.0.0/24 og én godkendt destination på 203.0.113.40. Et regelfragment for det flow ser sådan ud.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Adresserne og grænsefladen er eksempler, der skal erstattes. Anbring det gennemgåede ækvivalent i videresendelsespolitikken før den regel, der ellers ville afvise flowet, og tøm ikke et eksisterende regelsæt for at installere det; en gateway er ikke et rent-rum-eksperiment.

Udtrykket oifname er værd at beholde. Det dokumenterer udgangsbeslutningen og forhindrer reglen i at matche i en retning, du ikke havde tænkt dig, hvilket betyder noget på en gateway med flere veje til internettet. På en testboks med et enkelt uplink ser udtrykket overflødigt ud, og det er netop derfor, det fjernes, før boksen får et andet uplink.

Tilladelser til den ydre udveksling er separate. Gatewayens indgangssti har brug for de IKE- og ESP- eller UDP-indkapslingsporte, den faktisk bruger, og disse tilladelser autoriserer intet om den dekrypterede pakke indeni. At blande de to er måden, hvorpå en fungerende tunnel ender med en firewall, der videresender alt.

Indgående kontekst er ikke udgående kontekst

Den samme familie af udtryk dækker den anden retning med rt ipsec, som beskriver den udgående sikkerhedsassociation, en pakke vil bruge. Det besvarer et andet spørgsmål: ikke hvor denne pakke kom fra, men om den vil være beskyttet på sit næste ben.

Den forskel betyder noget på en gateway, der både afslutter en tunnel og videresender ind i en anden. En pakke kan ankomme dekrypteret og stadig skulle forlade krypteret, og en accept, der kun er skrevet for den indgående kontekst, siger intet om det udgående krav. Hvis politikken kræver den beskyttelse, bør regelsættet udtrykke det i stedet for at antage, at routing klarer det.

Hold de to spørgsmål i adskilte regler, så læseren kan se, hvilket der håndhæves. En enkelt smart regel, der kontrollerer begge, er sværere at gennemgå og meget sværere at fejlfinde, når den ene halvdel holder op med at matche. To regler med tællere fortæller dig også, hvilket krav der fejler, hvilket én kombineret regel aldrig vil.

NAT er ikke en firewallbeslutning

Trafik mod internettet fra en privat klientpulje har normalt brug for kildeoversættelse, så svaret kan finde vej tilbage. Men trafik, der er valgt til en anden udgående IPsec-politik, skal beholde sin påkrævede undtagelse, og at maskere hver privat kilde uden at tænke på den næste beskyttelsesbeslutning ødelægger det.

En accept inde i en NAT-kæde er heller ikke en generel tilladelse. NAT og filtrering har forskellige opgaver, og en NAT-kæde undersøger ikke hver senere pakke i et etableret flow, og det er netop derfor, at det at regne med den til sikkerhed giver regler, der ser ud til at virke i test og fejler under belastning.

Det omvendte er også sandt og overrasker folk: en accept et sted i én grundlæggende filterkæde vejer intet mod en senere afvisning i en anden gældende kæde. Rækkefølge og kædeomfang afgør resultatet, ikke tilstedeværelsen af en accept i filen.

Bekræft den nøjagtige indre tjeneste

Test den specifikke destination og port, du har godkendt, fra en rigtig klient, og bekræft, at svaret kommer tilbage. Test derefter noget, du ikke har godkendt, og kontroller, at det ikke går igennem, fordi en for bred regel består den første test lige så godt som en korrekt. En anmodning, der aldrig forlader klienten, er heller ikke et firewallresultat, så læs tællerne for at se, om pakken overhovedet blev evalueret. To tests og én tællerafslæsning fortæller dig mere end en hel eftermiddag med at læse regelsættet.

nftables-reference dokumenterer meta ipsec, rt ipsec og de retningsspecifikke udtryk, og det er stedet at kontrollere syntaksen mod din installerede version. Og hold omfanget eksplicit: dette er et IPv4-eksempel, det siger intet om IPv6, og det gør ikke vilkårlig offentlig portvideresending til en del af VPN-tjenesten.