Ni tun0? Ujemite dešifriran IPsec v nftables z meta ipsec

Pričakujete vmesnik tunela, ga iščete, in v požarnem zidu ni ničesar za ujemanje. To je običajno za prehod na osnovi pravil: šifrirana izmenjava prihaja na fizični vmesnik, in dešifriran notranji paket, ki se nato posreduje naprej, se prav tako opazuje kot prihajajoč na istem vmesniku. Ni tun0, ker ga ni ustvarilo nič.

Notranja zahteva je še vedno ločen paket z lastnim virom, ciljem in storitvijo, in jedro ve, iz katere varnostne povezave je prišel. Prav to znanje lahko ujame pravilo požarnega zidu.

Dva paketa, en vmesnik

Predstavljajte si dohodno smer. Prispe paket, zapakiran v ESP ali UDP, jedro najde ustrezno pravilo, ga dešifrira in preda čist paket poti posredovanja. Pravilo, ki gleda le na ime vmesnika, tega paketa ne more ločiti od drugega prometa, ki prihaja po isti žici.

Razlikuje ga kontekst dohodne varnostne poti, pritrjen na paket. nftables ga izpostavi kot meta ipsec exists, kar velja, ko je paket prišel po varnostni poti IPsec. Združite ga s sklopom odjemalcev, ciljem in storitvijo, in pravilo postane dovolj konkretno, da je varno.

Izpustitev konteksta je pogosta napaka in je varnostna, ne kozmetična napaka. Pravilo, ki sprejme vse, kar prihaja iz sklopa odjemalcev, prav tako rade volje sprejme ponarejen paket iz lokalnega omrežja, ker naslov vira sam po sebi ni dokaz za nič. Kontekst varnostne poti je najcenejši način, da vir dobi pomen. Pišite pravilo z njim že od začetka, namesto da ga dodate po reviziji.

Napišite pravilo za posredovanje

Predpostavite overjeno storitev oddaljenega dostopa IPv4 z odjemalci v 10.90.0.0/24 in enim odobrenim ciljem na 203.0.113.40. Odlomek pravila za ta tok je videti takole.

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

Naslovi in vmesnik so primeri za zamenjavo. Pregledani ekvivalent postavite v politiko posredovanja pred pravilo, ki bi tok sicer zavrnilo, in ne izpraznite obstoječega nabora pravil, da bi ga namestili; prehod ni poskus v čisti sobi.

Izraz oifname je vreden ohranitve. Dokumentira odločitev o izhodu in preprečuje, da bi se pravilo ujemalo v smeri, ki je niste nameravali, kar je pomembno na prehodu z več potmi v internet. Na testnem računalniku z enim vzponskim kanalom se izraz zdi odvečen, in prav zato ga odstranijo, preden računalnik dobi drugega.

Dovoljenja za zunanjo izmenjavo so ločena. Vhodna pot prehoda potrebuje vrata IKE in ESP ali zapakiranja UDP, ki jih dejansko uporablja, in ta dovoljenja ne dovoljujejo ničesar glede dešifriranega paketa znotraj. Mešanje obojega je pot, po kateri delujoč tunel konča s požarnim zidom, ki posreduje vse.

Dohodni kontekst ni odhodni kontekst

Ista družina izrazov pokriva drugo smer z rt ipsec, ki opisuje odhodno varnostno povezavo, ki jo bo paket uporabil. Odgovarja na drugo vprašanje: ne od kod je ta paket prišel, ampak ali bo na naslednjem odseku zaščiten.

Ta razlika je pomembna na prehodu, ki hkrati konča en tunel in posreduje v drugega. Paket lahko prispe dešifriran in mora vseeno oditi šifriran, in sprejetje, napisano samo za dohodni kontekst, ne pove ničesar o odhodni zahtevi. Če politika zahteva to zaščito, bi jo moral nabor pravil izraziti, namesto da predpostavlja, da bo usmerjanje poskrbelo zanjo.

Držite obe vprašanji v ločenih pravilih, da bralec vidi, katero se uveljavlja. Eno pametno pravilo, ki preverja oboje, je težje pregledati in veliko težje odpraviti napake, ko se ena njegova polovica preneha ujemati. Dve pravili s števci vam povesta tudi, katera zahteva ne uspe, česar eno združeno pravilo ne bo nikoli storilo.

NAT ni odločitev požarnega zidu

Promet v internet iz zasebnega sklopa odjemalcev običajno potrebuje pretvorbo vira, da odgovor najde pot nazaj. Toda promet, izbran za drugo odhodno politiko IPsec, mora ohraniti zahtevano izjemo, in prikrivanje vsakega zasebnega vira brez razmišljanja o naslednji zaščitni odločitvi to pokvari.

Sprejetje znotraj verige NAT tudi ni splošno dovoljenje. NAT in filtriranje imata različne naloge in veriga NAT ne pregleduje vsakega poznejšega paketa vzpostavljenega toka, in prav zato zanašanje nanjo glede varnosti daje pravila, ki se zdijo delujoča v preskusu in odpovejo pod obremenitvijo.

Tudi obratno drži in ljudi preseneti: sprejetje nekje v eni osnovni filtrirni verigi nima nobene teže proti poznejši zavrnitvi v drugi veljavni verigi. Izid odločita vrstni red in obseg verige, ne pa prisotnost sprejetja v datoteki.

Preverite natančno notranjo storitev

Preizkusite določen cilj in vrata, ki ste jih dovolili, iz pravega odjemalca, in potrdite, da se odgovor vrne. Nato preizkusite nekaj, česar niste dovolili, in preverite, da ne gre skozi, ker preširoko pravilo opravi prvi preskus prav tako dobro kot pravilno. Zahteva, ki nikoli ne zapusti odjemalca, tudi ni izid požarnega zidu, zato berite števce, da vidite, ali je bil paket sploh ocenjen. Dva preskusa in eno branje števca vam bosta povedala več kot celo popoldne branja nabora pravil.

Referenca nftables dokumentira meta ipsec, rt ipsec in izraze, specifične za smer, in tam je mesto za preverjanje skladnje glede na nameščeno različico. In obseg naj bo jasen: to je primer IPv4, ne pove ničesar o IPv6 in ne spremeni poljubnega javnega posredovanja vrat v del storitve VPN.