Nincs tun0? Egyeztesse a visszafejtett IPsec-et az nftables-ben a meta ipsec kifejezéssel

Alagút-interfészt vár, keresi, és a tűzfalban nincs semmi, amivel egyeztetni lehetne. Ez szabályalapú átjáró esetén normális: a titkosított csere a fizikai interfészen érkezik, és a továbbított visszafejtett belső csomag is úgy figyelhető meg, hogy ugyanazon az interfészen érkezik. Nincs tun0, mert semmi sem hozta létre.

A belső kérés továbbra is külön csomag saját forrással, céllal és szolgáltatással, és a kernel tudja, melyik biztonsági társulásból lépett ki. Ezt a tudást tudja egy tűzfalszabály egyeztetni.

Két csomag, egy interfész

Képzelje el a bejövő irányt. Egy ESP- vagy UDP-burkolt csomag érkezik, a kernel megtalálja a megfelelő szabályt, visszafejti, és a tiszta csomagot átadja a továbbítási útvonalnak. Egy szabály, amely csak az interfész nevét nézi, nem tudja megkülönböztetni ezt a csomagot az ugyanazon a vezetéken érkező bármely más forgalomtól.

Ami megkülönbözteti, az a csomaghoz kapcsolt bejövő biztonsági útvonal kontextusa. Az nftables ezt meta ipsec exists formában teszi elérhetővé, ami akkor igaz, ha a csomag IPsec biztonsági útvonalon érkezett. Kombinálja a klienspoolal, a céllal és a szolgáltatással, és a szabály elég konkrét lesz ahhoz, hogy biztonságos legyen.

A kontextus elhagyása a gyakori hiba, és ez biztonsági hiba, nem kozmetikai. Az a szabály, amely a klienspoolból érkező bármit elfogad, ugyanolyan szívesen elfogad egy hamisított csomagot a helyi hálózatról, mert a forrás cím önmagában semminek sem bizonyítéka. A biztonsági útvonal kontextusa a legolcsóbb módja annak, hogy a forrás jelentéssel bírjon. Írja a szabályt már az elején vele, ahelyett hogy egy audit után adná hozzá.

Írja meg a továbbítási szabályt

Tételezzünk fel egy hitelesített IPv4 távoli hozzáférésű szolgáltatást, amelynek kliensei a 10.90.0.0/24 tartományban vannak, és egy jóváhagyott célt a 203.0.113.40 címen. Egy szabálytöredék ehhez a folyamhoz így néz ki.

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

A címek és az interfész helyettesítendő példák. Helyezze az átvizsgált megfelelőt a továbbítási szabályba azelőtt a szabály előtt, amely egyébként elutasítaná a folyamot, és ne ürítse ki a meglévő szabálykészletet a telepítéshez; az átjáró nem tisztaszobai kísérlet.

Az oifname kifejezést érdemes megtartani. Dokumentálja a kimenő döntést, és megakadályozza, hogy a szabály olyan irányban egyezzen, amelyet nem szándékozott, ami számít egy több internetes útvonallal rendelkező átjárón. Egyetlen felső kapcsolattal rendelkező tesztgépen a kifejezés feleslegesnek tűnik, és éppen ezért távolítják el, mielőtt a gép második kapcsolatot kap.

A külső cseréhez szükséges engedélyek különállóak. Az átjáró bemeneti útvonalának szüksége van azokra az IKE és ESP vagy UDP-burkólási portokra, amelyeket ténylegesen használ, és ezek az engedélyek semmit sem engedélyeznek a belső visszafejtett csomaggal kapcsolatban. A kettő keverése az az út, amelyen egy működő alagút olyan tűzfalhoz jut, amely mindent továbbít.

A bejövő kontextus nem kimenő kontextus

Ugyanaz a kifejezéscsalád fedi a másik irányt a rt ipsec kifejezéssel, amely leírja azt a kimenő biztonsági társulást, amelyet a csomag használni fog. Más kérdésre válaszol: nem arra, hogy honnan jött ez a csomag, hanem hogy védve lesz-e a következő szakaszán.

Ez a megkülönböztetés számít egy olyan átjárón, amely egyszerre fejez be egy alagutat és továbbít egy másikba. Egy csomag visszafejtve érkezhet, és mégis titkosítva kell távoznia, és a csak a bejövő kontextusra írt elfogadás semmit sem mond a kimenő követelményről. Ha a szabály megköveteli ezt a védelmet, a szabálykészletnek ki kell fejeznie, ahelyett hogy feltételezné, hogy az útválasztás elintézi.

Tartsa a két kérdést külön szabályokban, hogy az olvasó lássa, melyik érvényesül. Egyetlen okos szabály, amely mindkettőt ellenőrzi, nehezebben átvizsgálható, és sokkal nehezebben hibakereshető, amikor az egyik fele megszűnik egyezni. Két számlálós szabály azt is megmondja, melyik követelmény hibázik, amit egyetlen egyesített szabály soha nem fog megtenni.

A NAT nem tűzfaldöntés

A privát klienspoolból az internet felé irányuló forgalomnak általában forrásfordításra van szüksége, hogy a válasz megtalálja a visszautat. De a másik kimenő IPsec-szabályhoz kiválasztott forgalomnak meg kell tartania a szükséges mentességét, és minden privát forrás maszkolása anélkül, hogy a következő védelmi döntésre gondolnánk, ezt megtöri.

A NAT-láncon belüli elfogadás sem általános engedély. A NAT és a szűrés különböző feladatokat lát el, és a NAT-lánc nem vizsgálja meg egy létrejött folyam minden későbbi csomagját, és éppen ezért eredményez a biztonság érdekében rá támaszkodva olyan szabályokat, amelyek a tesztben működni látszanak és terhelés alatt meghiúsulnak.

A fordítottja is igaz, és meglep embereket: egy szűrő alapláncában valahol lévő elfogadás semmilyen súllyal nem bír egy másik alkalmazható lánc későbbi elutasításával szemben. Az eredményt a sorrend és a lánc hatóköre dönti el, nem az elfogadás jelenléte a fájlban.

Ellenőrizze a pontos belső szolgáltatást

Tesztelje a jóváhagyott konkrét célt és portot valódi kliensről, és erősítse meg, hogy a válasz visszaérkezik. Utána teszteljen valamit, amit nem hagyott jóvá, és ellenőrizze, hogy nem megy át, mert egy túl széles szabály ugyanolyan jól átmegy az első teszten, mint egy helyes. Az a kérés, amely soha nem hagyja el a klienst, szintén nem tűzfaleredmény, ezért olvassa le a számlálókat, hogy lássa, egyáltalán kiértékelték-e a csomagot. Két teszt és egy számlálóleolvasás többet mond, mint egy egész délután a szabálykészlet olvasása.

Az nftables-referencia dokumentálja a meta ipsec, a rt ipsec és az irányspecifikus kifejezéseket, és ott érdemes a szintaxist a telepített verzióhoz ellenőrizni. És tartsa a hatókört egyértelműen: ez IPv4-példa, semmit sem mond az IPv6-ról, és nem teszi a tetszőleges nyilvános porttovábbítást a VPN-szolgáltatás részévé.