Pole tun0? Sobitage nftablesis dekrüpteeritud IPsec väljendiga meta ipsec

Ootate tunneliliidest, otsite seda ja tulemüüris pole midagi sobitada. See on poliitikapõhise lüüsi puhul tavaline: krüpteeritud vahetus saabub füüsilisele liidesele ja dekrüpteeritud sisemine pakett, mis seejärel edasi suunatakse, täheldatakse samuti saabuvat samale liidesele. tun0 puudub, sest miski ei loonud seda.

Sisemine päring on endiselt eraldi pakett oma lähte, sihtkoha ja teenusega ning kernel teab, millisest turvaassotsiatsioonist see väljus. Just seda teadmist saab tulemüürireegel sobitada.

Kaks paketti, üks liides

Kujutage ette sissetulevat suunda. Saabub ESP või UDP-sse kapseldatud pakett, kernel leiab sobiva poliitika, dekrüpteerib selle ja annab selge paketi edastusteele. Reegel, mis vaatab ainult liidese nime, ei suuda seda paketti eristada ühestki teisest samal juhtmel saabuvast liiklusest.

Seda eristab paketiga seotud sissetuleva turbetee kontekst. nftables esitab selle kujul meta ipsec exists, mis on tõene, kui pakett saabus IPsec-turbetee kaudu. Kombineerige see kliendipooliga, sihtkoha ja teenusega ning reeglist saab piisavalt täpne, et olla turvaline.

Konteksti väljajätmine on tavaline viga ja see on turvaviga, mitte kosmeetiline. Reegel, mis võtab vastu kõik kliendipoolilt tuleva, võtab sama hea meelega vastu võltsitud paketi kohalikust võrgust, sest lähteaadress iseenesest ei ole millegi tõestuseks. Turbetee kontekst on odavaim viis muuta lähe tähenduslikuks. Kirjutage reegel sellega algusest peale, selle asemel et seda pärast auditit lisada.

Kirjutage edastusreegel

Oletame autenditud IPv4-kaugjuurdepääsuteenust, mille kliendid on 10.90.0.0/24 sees, ja üht heakskiidetud sihtkohta aadressil 203.0.113.40. Selle voo reeglifragment näeb välja selline.

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

Aadressid ja liides on asendatavad näited. Asetage üle vaadatud vaste edastuspoliitikasse enne reeglit, mis muidu voo tagasi lükkaks, ja ärge tühjendage olemasolevat reeglistikku selle paigaldamiseks; lüüs ei ole puhta ruumi eksperiment.

Terminit oifname tasub hoida. See dokumenteerib väljundotsuse ja takistab reeglil sobituda suunas, mida te ei kavatsenud, mis loeb lüüsil, millel on mitu teed internetti. Ühe üleslingiga katsemasinal tundub termin üleliigne ja just seetõttu jäetakse see välja enne, kui masin saab teise üleslingi.

Välise vahetuse load on eraldi. Lüüsi sisendtee vajab neid IKE ja ESP või UDP-kapselduse porte, mida see tegelikult kasutab, ja need load ei luba midagi seoses seesmise dekrüpteeritud paketiga. Kahe asja segamine on viis, kuidas töötav tunnel lõpeb tulemüüriga, mis edastab kõike.

Sissetulev kontekst ei ole väljuv kontekst

Sama väljendite pere katab teise suuna väljendiga rt ipsec, mis kirjeldab väljuvat turvaassotsiatsiooni, mida pakett kasutama hakkab. See vastab teisele küsimusele: mitte kust see pakett tuli, vaid kas seda kaitstakse selle järgmisel lõigul.

See erinevus loeb lüüsil, mis üheaegselt lõpetab ühe tunneli ja edastab teise. Pakett võib saabuda dekrüpteeritult ja peab siiski lahkuma krüpteeritult, ning ainult sissetuleva konteksti jaoks kirjutatud luba ei ütle väljuva nõude kohta midagi. Kui poliitika seda kaitset nõuab, peaks reeglistik seda väljendama, selle asemel et eeldada, et marsruutimine sellega tegeleb.

Hoidke kaks küsimust eraldi reeglites, et lugeja näeks, millist täidetakse. Üks nutikas reegel, mis kontrollib mõlemat, on raskemini üle vaadatav ja palju raskemini silutav, kui üks selle pool lakkab sobitumast. Kaks loenduritega reeglit ütlevad teile ka, milline nõue ebaõnnestub, mida üks ühendatud reegel ei tee kunagi.

NAT ei ole tulemüüri otsus

Liiklus internetti privaatsest kliendipoolist vajab tavaliselt lähte tõlget, et vastus leiaks tee tagasi. Kuid teise väljuva IPsec-poliitika jaoks valitud liiklus peab säilitama nõutud erandi, ja iga privaatse lähte maskeerimine mõtlemata järgmise kaitseotsuse peale rikub selle.

Luba NAT-i ahela sees ei ole samuti üldine luba. NAT-il ja filtreerimisel on erinevad ülesanded ning NAT-i ahel ei kontrolli loodud voo iga hilisemat paketti, ja just seetõttu annab sellele turvalisuses lootmine reegleid, mis näivad testis töötavat ja koormuse all ebaõnnestuvat.

Vastupidine on samuti tõsi ja üllatab inimesi: luba kuskil ühes filtreerimise põhiahelas ei oma mingit kaalu hilisema tagasilükkamise vastu teises kohaldatavas ahelas. Tulemuse otsustavad järjekord ja ahela ulatus, mitte loa olemasolu failis.

Kontrollige täpset sisemist teenust

Testige konkreetset sihtkohta ja porti, mille te heaks kiitsite, päris kliendist, ja kinnitage, et vastus tuleb tagasi. Seejärel testige midagi, mida te ei heaks kiitnud, ja kontrollige, et see läbi ei lähe, sest liiga lai reegel läbib esimese testi sama hästi kui õige. Päring, mis ei lahku kliendist kunagi, ei ole samuti tulemüüri tulemus, seega lugege loendureid, et näha, kas paketti üldse hinnati. Kaks testi ja üks loenduri näit ütlevad teile rohkem kui terve pärastlõuna reeglistiku lugemist.

nftablesi viide dokumenteerib meta ipsec, rt ipsec ja suunaspetsiifilised väljendid ning just seal tuleks süntaksit oma paigaldatud versiooni vastu kontrollida. Ja hoidke ulatus selgena: see on IPv4 näide, see ei ütle IPv6 kohta midagi ega muuda meelevaldset avalike portide edastust VPN-teenuse osaks.