Ingen tun0? Match dekryptert IPsec i nftables med meta ipsec

Du forventer et tunnelgrensesnitt, leter etter det, og det er ingenting å matche i brannmuren. Det er normalt for en policybasert gateway: den krypterte utvekslingen ankommer på det fysiske grensesnittet, og den dekrypterte indre pakken som deretter videresendes, observeres også som ankommende på samme grensesnitt. Det finnes ingen tun0 fordi ingenting opprettet en.

Den indre forespørselen er fortsatt en egen pakke med sin egen kilde, destinasjon og tjeneste, og kjernen vet hvilken sikkerhetsassosiasjon den kom ut av. Det er denne kunnskapen en brannmurregel kan matche.

To pakker, ett grensesnitt

Se for deg den inngående retningen. En ESP- eller UDP-innkapslet pakke ankommer, kjernen finner den samsvarende policyen, dekrypterer den og gir den klare pakken videre til videresendingsstien. En regel som bare ser på grensesnittnavnet, kan ikke skille den pakken fra annen trafikk som ankommer på samme ledning.

Det som skiller den, er konteksten for den inngående sikkerhetsstien som er knyttet til pakken. nftables eksponerer den som meta ipsec exists, som er sann når pakken ankom gjennom en IPsec-sikkerhetssti. Kombiner den med klientpoolen, destinasjonen og tjenesten, og regelen blir spesifikk nok til å være trygg.

Å utelate konteksten er den vanlige feilen, og det er en sikkerhetsfeil snarere enn en kosmetisk. En regel som godtar alt som kommer fra klientpoolen, godtar like gjerne en forfalsket pakke fra det lokale nettet, fordi kildeadressen ikke er bevis for noe i seg selv. Konteksten for sikkerhetsstien er den billigste måten å gjøre kilden meningsfull. Skriv regelen med den fra starten i stedet for å legge den til etter en revisjon.

Skriv videresendingsregelen

Anta en autentisert IPv4-fjerntilgangstjeneste med klienter i 10.90.0.0/24 og én godkjent destinasjon på 203.0.113.40. Et regelfragment for den flyten ser slik ut.

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

Adressene og grensesnittet er eksempler som skal erstattes. Plasser det gjennomgåtte ekvivalenten i videresendingspolicyen før regelen som ellers ville avvise flyten, og ikke tøm et eksisterende regelsett for å installere det; en gateway er ikke et rent-rom-eksperiment.

Uttrykket oifname er verdt å beholde. Det dokumenterer utgangsbeslutningen og hindrer regelen i å matche i en retning du ikke hadde tenkt, noe som betyr noe på en gateway med flere veier til internett. På en testboks med én oppstrømskobling virker uttrykket overflødig, og det er nettopp derfor det fjernes før boksen får en andre kobling.

Tillatelsene for den ytre utvekslingen er separate. Gatewayens inngangssti trenger de IKE- og ESP- eller UDP-innkapslingsportene den faktisk bruker, og disse tillatelsene autoriserer ingenting om den dekrypterte pakken inni. Å blande de to er måten en fungerende tunnel ender opp med en brannmur som videresender alt.

Inngående kontekst er ikke utgående kontekst

Den samme familien av uttrykk dekker den andre retningen med rt ipsec, som beskriver sikkerhetsassosiasjonen for utgående trafikk som en pakke vil bruke. Det svarer på et annet spørsmål: ikke hvor denne pakken kom fra, men om den vil være beskyttet på sin neste etappe.

Denne forskjellen betyr noe på en gateway som både avslutter én tunnel og videresender inn i en annen. En pakke kan ankomme dekryptert og likevel måtte gå ut kryptert, og en godkjenning skrevet bare for den inngående konteksten sier ingenting om kravet for utgående trafikk. Hvis policyen krever den beskyttelsen, bør regelsettet uttrykke det i stedet for å anta at rutingen ordner det.

Hold de to spørsmålene i separate regler slik at leseren ser hvilket som håndheves. Én smart regel som sjekker begge er vanskeligere å gjennomgå og mye vanskeligere å feilsøke når den ene halvdelen slutter å matche. To regler med tellere forteller deg også hvilket krav som feiler, noe én kombinert regel aldri vil gjøre.

NAT er ikke en brannmurbeslutning

Trafikk mot internett fra en privat klientpool trenger vanligvis kildeoversettelse slik at svaret finner veien tilbake. Men trafikk som er valgt for en annen utgående IPsec-policy, må beholde den påkrevde unntakelsen, og å maskere hver private kilde uten å tenke på neste beskyttelsesbeslutning bryter det.

En godkjenning inne i en NAT-kjede er heller ikke en generell tillatelse. NAT og filtrering har forskjellige oppgaver, og en NAT-kjede undersøker ikke hver senere pakke i en etablert flyt, og det er nettopp derfor det å regne med den for sikkerhet gir regler som ser ut til å virke i test og feiler under belastning.

Det motsatte er også sant og overrasker folk: en godkjenning et sted i én grunnleggende filterkjede veier ingenting mot en senere avvisning i en annen gjeldende kjede. Rekkefølge og kjedens omfang avgjør resultatet, ikke tilstedeværelsen av en godkjenning i filen.

Bekreft den nøyaktige indre tjenesten

Test den spesifikke destinasjonen og porten du godkjente, fra en ekte klient, og bekreft at svaret kommer tilbake. Test deretter noe du ikke godkjente, og kontroller at det ikke går gjennom, fordi en for bred regel består den første testen like godt som en korrekt. En forespørsel som aldri forlater klienten, er heller ikke et brannmurresultat, så les tellerne for å se om pakken i det hele tatt ble vurdert. To tester og én telleravlesning forteller deg mer enn en hel ettermiddag med å lese regelsettet.

nftables-referansen dokumenterer meta ipsec, rt ipsec og de retningsspesifikke uttrykkene, og det er stedet for å kontrollere syntaksen mot din installerte versjon. Og hold omfanget eksplisitt: dette er et IPv4-eksempel, det sier ingenting om IPv6, og det gjør ikke vilkårlig offentlig portvideresending til en del av VPN-tjenesten.