Žiadne tun0? Porovnajte dešifrovaný IPsec v nftables pomocou meta ipsec

Očakávate rozhranie tunela, hľadáte ho a vo firewalle nie je nič, s čím by sa dalo porovnať. To je pri bráne založenej na politikách normálne: šifrovaná výmena prichádza na fyzické rozhranie a dešifrovaný vnútorný paket, ktorý sa potom preposiela, sa tiež pozoruje ako prichádzajúci na to isté rozhranie. Žiadne tun0 nie je, pretože ho nič nevytvorilo.

Vnútorná požiadavka je stále samostatný paket s vlastným zdrojom, cieľom a službou a jadro vie, z ktorej bezpečnostnej asociácie vyšiel. Práve túto znalosť môže pravidlo firewallu porovnať.

Dva pakety, jedno rozhranie

Predstavte si prichádzajúci smer. Príde paket zapuzdrený v ESP alebo UDP, jadro nájde zodpovedajúcu politiku, dešifruje ho a odovzdá čistý paket preposielacej ceste. Pravidlo, ktoré sa pozerá len na názov rozhrania, nedokáže tento paket odlíšiť od akejkoľvek inej premávky prichádzajúcej po tom istom kábli.

Odlišuje ho kontext prichádzajúcej bezpečnostnej cesty pripojený k paketu. nftables ho vystavuje ako meta ipsec exists, čo platí, keď paket prišiel bezpečnostnou cestou IPsec. Skombinujte ho s bazénom klientov, cieľom a službou a pravidlo bude dosť konkrétne na to, aby bolo bezpečné.

Vynechanie kontextu je častá chyba a je to chyba zabezpečenia, nie kozmetická. Pravidlo, ktoré prijíma všetko z bazéna klientov, rovnako ochotne prijme podvrhnutý paket z miestnej siete, pretože zdrojová adresa sama o sebe nie je dôkazom ničoho. Kontext bezpečnostnej cesty je najlacnejší spôsob, ako dať zdroju význam. Píšte pravidlo s ním od začiatku, namiesto pridávania po audite.

Napíšte pravidlo preposielania

Predpokladajte autentizovanú službu vzdialeného prístupu IPv4 s klientmi v 10.90.0.0/24 a jeden schválený cieľ na 203.0.113.40. Fragment pravidla pre tento tok vyzerá takto.

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

Adresy a rozhranie sú príklady na nahradenie. Umiestnite skontrolovaný ekvivalent do preposielacej politiky pred pravidlo, ktoré by tok inak odmietlo, a nerušte existujúcu sadu pravidiel, aby ste ho nainštalovali; brána nie je experiment v čistej miestnosti.

Výraz oifname stojí za to ponechať. Dokumentuje rozhodnutie o výstupe a bráni tomu, aby pravidlo odpovedalo v smere, ktorý ste nezamýšľali, čo je dôležité na bráne s niekoľkými cestami do internetu. Na testovacom stroji s jedným výstupným spojením vyzerá výraz nadbytočne, a práve preto sa odstráni skôr, než stroj získa druhé spojenie.

Oprávnenia pre vonkajšiu výmenu sú oddelené. Vstupná cesta brány potrebuje porty IKE a ESP alebo UDP zapuzdrenia, ktoré skutočne používa, a tieto oprávnenia nič nepovoľujú ohľadne dešifrovaného paketu vnútri. Miešanie oboch je spôsob, ako funkčný tunel skončí s firewallom, ktorý preposiela všetko.

Prichádzajúci kontext nie je odchádzajúci kontext

Rovnaká rodina výrazov pokrýva druhý smer pomocou rt ipsec, ktorý opisuje odchádzajúcu bezpečnostnú asociáciu, ktorú paket použije. Odpovedá na inú otázku: nie odkiaľ tento paket prišiel, ale či bude na ďalšom úseku chránený.

Tento rozdiel je dôležitý na bráne, ktorá zároveň ukončuje jeden tunel a preposiela do iného. Paket môže prísť dešifrovaný a napriek tomu musí odísť šifrovaný, a prijatie napísané len pre prichádzajúci kontext nehovorí nič o odchádzajúcej požiadavke. Ak politika túto ochranu vyžaduje, sada pravidiel by ju mala vyjadriť, namiesto predpokladu, že to vyrieši smerovanie.

Držte obe otázky v oddelených pravidlách, aby čitateľ videl, ktoré sa presadzuje. Jedno šikovné pravidlo, ktoré kontroluje obe, sa ťažšie kontroluje a oveľa ťažšie ladí, keď jedna jeho polovica prestane odpovedať. Dve pravidlá s čítačmi vám tiež povedia, ktorá požiadavka zlyháva, čo jedno zlúčené pravidlo nikdy neurobí.

NAT nie je rozhodnutie firewallu

Premávka do internetu z privátneho bazéna klientov zvyčajne potrebuje preklad zdroja, aby odpoveď našla cestu späť. Ale premávka vybraná pre inú odchádzajúcu politiku IPsec si musí zachovať požadovanú výnimku, a maskovanie každého privátneho zdroja bez rozmýšľania o ďalšom rozhodnutí o ochrane to rozbíja.

Prijatie vnútri reťazca NAT tiež nie je všeobecné povolenie. NAT a filtrovanie majú rôzne úlohy a reťazec NAT neprehliada každý neskorší paket nadviazaného toku, a práve preto spoliehanie sa naň v otázkach zabezpečenia dáva pravidlá, ktoré vyzerajú funkčne pri teste a zlyhávajú pod záťažou.

Opak je tiež pravdivý a ľudí zaskočí: prijatie niekde v jednom základnom filtračnom reťazci nemá žiadnu váhu voči neskoršiemu odmietnutiu v inom použiteľnom reťazci. Výsledok rozhoduje poradie a rozsah reťazca, nie prítomnosť prijatia v súbore.

Overte presnú vnútornú službu

Otestujte konkrétny cieľ a port, ktoré ste povolili, z reálneho klienta a potvrďte, že odpoveď sa vracia. Potom otestujte niečo, čo ste nepovolili, a overte, že to neprejde, pretože príliš široké pravidlo prejde prvým testom rovnako dobre ako správne. Požiadavka, ktorá nikdy neopustí klienta, tiež nie je výsledkom firewallu, takže čítajte čítače, aby ste videli, či bol paket vôbec vyhodnotený. Dva testy a jedno odčítanie čítača vám povedia viac ako celé popoludnie čítania sady pravidiel.

Referenčná príručka nftables dokumentuje meta ipsec, rt ipsec a výrazy špecifické pre smer a práve tam je miesto, kde overiť syntax voči nainštalovanej verzii. A držte rozsah explicitný: toto je príklad IPv4, nič nehovorí o IPv6 a nepremieňa svojvoľné verejné preposielanie portov na súčasť služby VPN.