Fără tun0? Potriviți IPsec decriptat în nftables cu meta ipsec

Vă așteptați la o interfață de tunel, o căutați și nu există nimic de potrivit în firewall. Acest lucru este normal pentru un gateway bazat pe politici: schimbul criptat sosește pe interfața fizică, iar pachetul intern decriptat care este apoi transmis mai departe este și el observat ca sosit pe aceeași interfață. Nu există tun0 pentru că nimic nu a creat una.

Cererea internă rămâne un pachet distinct cu propria sursă, destinație și serviciu, iar nucleul știe din ce asociere de securitate a ieșit. Exact această cunoaștere o poate potrivi o regulă de firewall.

Două pachete, o interfață

Imaginați-vă direcția de intrare. Sosește un pachet încapsulat în ESP sau UDP, nucleul găsește politica potrivită, îl decriptează și predă pachetul clar căii de transmitere. O regulă care se uită doar la numele interfeței nu poate distinge acel pachet de orice alt trafic care sosește pe același cablu.

Ceea ce îl distinge este contextul căii de securitate de intrare atașat pachetului. nftables îl expune ca meta ipsec exists, care este adevărat când pachetul a sosit printr-o cale de securitate IPsec. Combinați-l cu grupul de clienți, destinația și serviciul, iar regula devine suficient de specifică pentru a fi sigură.

Omiterea contextului este greșeala obișnuită și este o greșeală de securitate, nu una cosmetică. O regulă care acceptă tot ce provine din grupul de clienți acceptă la fel de bucuroasă un pachet falsificat din rețeaua locală, pentru că adresa sursă nu este în sine o dovadă pentru nimic. Contextul căii de securitate este cea mai ieftină modalitate de a face sursa semnificativă. Scrieți regula cu el de la început în loc să îl adăugați după un audit.

Scrieți regula de transmitere

Presupuneți un serviciu de acces la distanță IPv4 autentificat cu clienți în 10.90.0.0/24 și o destinație aprobată la 203.0.113.40. Un fragment de regulă pentru acel flux arată astfel.

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

Adresele și interfața sunt exemple de înlocuit. Plasați echivalentul verificat în politica de transmitere înaintea regulii care altfel ar respinge fluxul, și nu goliți un set de reguli existent pentru a-l instala; un gateway nu este un experiment în cameră curată.

Termenul oifname merită păstrat. Documentează decizia de ieșire și împiedică regula să se potrivească într-o direcție pe care nu ați intenționat-o, ceea ce contează pe un gateway cu mai multe căi către internet. Pe o cutie de test cu o singură legătură ascendentă termenul pare redundant, și exact de aceea este eliminat înainte ca cutia să primească o a doua legătură.

Permisiunile pentru schimbul exterior sunt separate. Calea de intrare a gateway-ului are nevoie de porturile IKE și ESP sau de încapsulare UDP pe care le folosește efectiv, iar aceste permisiuni nu autorizează nimic despre pachetul decriptat din interior. Amestecarea celor două este modul în care un tunel funcțional ajunge cu un firewall care transmite totul.

Contextul de intrare nu este contextul de ieșire

Aceeași familie de expresii acoperă cealaltă direcție cu rt ipsec, care descrie asocierea de securitate de ieșire pe care o va folosi un pachet. Răspunde la o altă întrebare: nu de unde a venit acest pachet, ci dacă va fi protejat pe următorul său tronson.

Acea distincție contează pe un gateway care încheie un tunel și totodată transmite în altul. Un pachet poate sosi decriptat și totuși trebuie să plece criptat, iar o acceptare scrisă doar pentru contextul de intrare nu spune nimic despre cerința de ieșire. Dacă politica cere acea protecție, setul de reguli ar trebui să o exprime în loc să presupună că rutarea se va ocupa de ea.

Țineți cele două întrebări în reguli separate, astfel încât cititorul să vadă care este aplicată. O singură regulă isteață care le verifică pe amândouă este mai greu de revizuit și mult mai greu de depanat când una dintre jumătățile ei nu mai corespunde. Două reguli cu contoare vă spun și care cerință eșuează, ceea ce o regulă combinată nu va face niciodată.

NAT nu este o decizie a firewall-ului

Traficul către internet dintr-un grup de clienți privat are de obicei nevoie de traducerea sursei pentru ca răspunsul să găsească drumul înapoi. Dar traficul selectat pentru o altă politică IPsec de ieșire trebuie să își păstreze excepția necesară, iar mascarea fiecărei surse private fără a gândi la următoarea decizie de protecție strică asta.

O acceptare în interiorul unui lanț NAT nu este nici ea o permisiune generală. NAT și filtrarea au sarcini diferite, iar un lanț NAT nu examinează fiecare pachet ulterior al unui flux stabilit, și exact de aceea bazarea pe el pentru securitate produce reguli care par să funcționeze în test și eșuează sub sarcină.

Și inversul este adevărat și surprinde oamenii: o acceptare undeva într-un lanț de bază de filtrare nu are nicio greutate împotriva unei respingeri ulterioare într-un alt lanț aplicabil. Ordinea și scopul lanțului decid rezultatul, nu prezența unei acceptări în fișier.

Verificați serviciul intern exact

Testați destinația și portul specifice pe care le-ați autorizat, de la un client real, și confirmați că răspunsul se întoarce. Apoi testați ceva ce nu ați autorizat și verificați că nu trece, pentru că o regulă prea largă trece primul test la fel de bine ca una corectă. O cerere care nu părăsește niciodată clientul nu este nici ea un rezultat al firewall-ului, așa că citiți contoarele pentru a vedea dacă pachetul a fost evaluat. Două teste și o citire de contor vă vor spune mai mult decât o după-amiază întreagă citind setul de reguli.

Referința nftables documentează meta ipsec, rt ipsec și expresiile specifice direcției, și acolo este locul unde verificați sintaxa față de versiunea instalată. Și păstrați scopul explicit: acesta este un exemplu IPv4, nu spune nimic despre IPv6 și nu transformă transmiterea arbitrară de porturi publice într-o parte a serviciului VPN.