Nema tun0? Uskladite dešifrovani IPsec u nftables pomoću meta ipsec

Očekujete interfejs tunela, tražite ga i u firewallu nema ničega s čim bi se moglo uskladiti. To je normalno za gateway vođen politikama: šifrovana razmjena stiže na fizički interfejs, a dešifrovani unutrašnji paket koji se zatim prosljeđuje također se opaža kao da stiže na isti interfejs. Nema tun0 jer ga ništa nije stvorilo.

Unutrašnji zahtjev je i dalje zaseban paket sa svojim izvorom, odredištem i uslugom, a jezgro zna iz koje sigurnosne asocijacije je izašao. Upravo to znanje firewall pravilo može uskladiti.

Dva paketa, jedan interfejs

Zamislite dolazni smjer. Stiže paket enkapsuliran u ESP ili UDP, jezgro pronalazi odgovarajuću politiku, dešifruje ga i predaje čisti paket putanji prosljeđivanja. Pravilo koje gleda samo ime interfejsa ne može razlikovati taj paket od bilo kojeg drugog saobraćaja koji stiže na istu žicu.

Razlikuje ga kontekst dolazne sigurnosne putanje pridružen paketu. nftables ga izlaže kao meta ipsec exists, što je tačno kada je paket stigao kroz IPsec sigurnosnu putanju. Kombinujte to s bazenom klijenata, odredištem i uslugom i pravilo postaje dovoljno precizno da bude sigurno.

Izostavljanje konteksta uobičajena je greška i to je sigurnosna, a ne kozmetička greška. Pravilo koje prihvata sve što dolazi iz bazena klijenata jednako rado prihvata i lažni paket iz lokalne mreže, jer adresa izvora sama po sebi nije dokaz ničega. Kontekst sigurnosne putanje najjeftiniji je način da izvor učinite smislenim. Pišite pravilo s njim od početka, umjesto da ga dodajete nakon revizije.

Napišite pravilo prosljeđivanja

Pretpostavite autentifikovanu IPv4 uslugu daljinskog pristupa s klijentima u 10.90.0.0/24 i jednim odobrenim odredištem na 203.0.113.40. Fragment pravila za taj tok izgleda ovako.

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

Adrese i interfejs su primjeri koje treba zamijeniti. Stavite pregledani ekvivalent u politiku prosljeđivanja prije pravila koje bi inače odbilo tok i ne praznite postojeći skup pravila da biste ga instalirali; gateway nije eksperiment u čistoj sobi.

Termin oifname vrijedi zadržati. On dokumentuje odluku o izlazu i sprječava da se pravilo uskladi u smjeru koji niste namjeravali, što je važno na gatewayu s nekoliko puteva do interneta. Na testnoj kutiji s jednim izlaznim linkom termin izgleda suvišno i upravo se zato uklanja prije nego kutija dobije drugi link.

Dozvole za vanjsku razmjenu su odvojene. Ulazna putanja gatewaya treba IKE i ESP ili UDP portove enkapsulacije koje zaista koristi, a te dozvole ne odobravaju ništa u vezi s dešifrovanim paketom unutra. Miješanje to dvoje put je kojim radni tunel završi s firewallom koji prosljeđuje sve.

Dolazni kontekst nije odlazni kontekst

Ista porodica izraza pokriva drugi smjer pomoću rt ipsec, koji opisuje odlaznu sigurnosnu asocijaciju koju će paket koristiti. On odgovara na drugo pitanje: ne odakle je ovaj paket došao, nego hoće li biti zaštićen na sljedećoj dionici.

Ta razlika važna je na gatewayu koji istovremeno završava jedan tunel i prosljeđuje u drugi. Paket može stići dešifrovan i ipak morati otići šifrovan, a prihvatanje napisano samo za dolazni kontekst ne govori ništa o odlaznom zahtjevu. Ako politika zahtijeva tu zaštitu, skup pravila to treba izraziti umjesto da pretpostavlja da će rutiranje to riješiti.

Držite dva pitanja u odvojenim pravilima da čitalac može vidjeti koje se primjenjuje. Jedno pametno pravilo koje provjerava oboje teže je pregledati i mnogo teže otkloniti grešku kada jedna njegova polovina prestane da se usklađuje. Dva pravila s brojačima također vam kažu koji zahtjev ne prolazi, što jedno objedinjeno pravilo nikada neće.

NAT nije firewall odluka

Saobraćaj prema internetu iz privatnog bazena klijenata obično treba prevođenje izvora da bi odgovor našao put nazad. Ali saobraćaj odabran za drugu odlaznu IPsec politiku mora zadržati svoje potrebno izuzeće, a maskiranje svakog privatnog izvora bez razmišljanja o sljedećoj odluci o zaštiti to kvari.

Prihvatanje unutar NAT lanca također nije opšta dozvola. NAT i filtriranje imaju različite poslove, a NAT lanac ne pregleda svaki kasniji paket uspostavljenog toka, i upravo zato oslanjanje na njega za sigurnost daje pravila koja izgledaju ispravna u testu i padaju pod opterećenjem.

Obrnuto je također tačno i iznenadi ljude: prihvatanje negdje u jednom osnovnom lancu filtriranja nema nikakvu težinu protiv kasnijeg odbacivanja u drugom primjenjivom lancu. Redoslijed i obim lanca odlučuju ishod, a ne prisustvo prihvatanja u datoteci.

Provjerite tačnu unutrašnju uslugu

Testirajte konkretno odredište i port koje ste odobrili, sa stvarnog klijenta, i potvrdite da se odgovor vraća. Zatim testirajte nešto što niste odobrili i provjerite da ne prolazi, jer preširoko pravilo prolazi prvi test jednako dobro kao ispravno. Zahtjev koji nikada ne napusti klijenta također nije firewall rezultat, pa čitajte brojače da vidite je li paket uopšte ocijenjen. Dva testa i jedno čitanje brojača reći će vam više od cijelog popodneva čitanja skupa pravila.

nftables referenca dokumentuje meta ipsec, rt ipsec i izraze specifične za smjer, i to je mjesto gdje treba provjeriti sintaksu prema instaliranoj verziji. I držite obim eksplicitnim: ovo je IPv4 primjer, ne govori ništa o IPv6 i ne pretvara proizvoljno javno prosljeđivanje portova u dio VPN usluge.