Nėra tun0? Sulyginkite iššifruotą IPsec nftables su meta ipsec

Jūs tikitės tunelio sąsajos, ieškote jos, o ugniasienėje nėra ką sulyginti. Tai normalu politikomis pagrįstam šliuzui: užšifruotas mainai atvyksta per fizinę sąsają, o iššifruotas vidinis paketas, kuris vėliau persiunčiamas, taip pat stebimas atvykstantis per tą pačią sąsają. tun0 nėra, nes niekas jo nesukūrė.

Vidinė užklausa vis dar yra atskiras paketas su savo šaltiniu, paskirties vieta ir paslauga, o branduolys žino, iš kurios saugos asociacijos jis išėjo. Būtent šias žinias ugniasienės taisyklė gali sulyginti.

Du paketai, viena sąsaja

Įsivaizduokite įeinančią kryptį. Atvyksta ESP arba UDP įkapsuliuotas paketas, branduolys randa atitinkančią politiką, jį iššifruoja ir atiduoda atvirą paketą persiuntimo keliui. Taisyklė, kuri žiūri tik į sąsajos pavadinimą, negali atskirti to paketo nuo jokio kito srauto, atvykstančio tuo pačiu laidu.

Jį išskiria prie paketo pridedamas įeinančios saugos kelio kontekstas. nftables jį parodo kaip meta ipsec exists, o tai teisinga, kai paketas atvyko per IPsec saugos kelią. Sudėkite jį su klientų telkiniu, paskirties vieta ir paslauga, ir taisyklė taps pakankamai konkreti, kad būtų saugi.

Konteksto praleidimas yra įprasta klaida, ir tai saugos, o ne kosmetinė klaida. Taisyklė, kuri priima viską, kas ateina iš klientų telkinio, taip pat mielai priims suklastotą paketą iš vietinio tinklo, nes šaltinio adresas pats savaime nieko neįrodo. Saugos kelio kontekstas yra pigiausias būdas padaryti šaltinį prasmingą. Rašykite taisyklę su juo nuo pat pradžių, o ne pridėkite po audito.

Parašykite persiuntimo taisyklę

Tarkime, yra autentifikuota IPv4 nuotolinės prieigos paslauga su klientais 10.90.0.0/24 tinkle ir viena patvirtinta paskirties vieta 203.0.113.40 adresu. To srauto taisyklės fragmentas atrodo taip.

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

Adresai ir sąsaja yra pavyzdžiai, kuriuos reikia pakeisti. Įdėkite peržiūrėtą atitikmenį į persiuntimo politiką prieš taisyklę, kuri kitaip atmestų srautą, ir neišvalykite esamo taisyklių rinkinio, kad jį įdiegtumėte; šliuzas nėra švarios patalpos eksperimentas.

Terminą oifname verta palikti. Jis dokumentuoja išėjimo sprendimą ir neleidžia taisyklei sulyginti kryptimi, kurios neketinote, o tai svarbu šliuzui su keliais keliais į internetą. Vieno išėjimo kanalo bandymo dėžėje terminas atrodo perteklinis, ir būtent todėl jis pašalinamas prieš dėžei gaunant antrą kanalą.

Išorinio mainų leidimai yra atskiri. Šliuzo įėjimo keliui reikia tų IKE ir ESP arba UDP įkapsuliavimo prievadų, kuriuos jis iš tikrųjų naudoja, ir tie leidimai nieko neleidžia dėl viduje esančio iššifruoto paketo. Abiejų sumaišymas yra kelias, kuriuo veikiantis tunelis atsiduria su ugniasiene, kuri persiunčia viską.

Įeinantis kontekstas nėra išeinantis kontekstas

Ta pati išraiškų šeima apima kitą kryptį su rt ipsec, kuris aprašo išeinančią saugos asociaciją, kurią paketas naudos. Jis atsako į kitą klausimą: ne iš kur šis paketas atėjo, o ar jis bus apsaugotas kitame ruože.

Šis skirtumas svarbus šliuzui, kuris kartu užbaigia vieną tunelį ir persiunčia į kitą. Paketas gali atvykti iššifruotas ir vis tiek turi išvykti užšifruotas, o priėmimas, parašytas tik įeinančiam kontekstui, nieko nesako apie išeinančio reikalavimą. Jei politika reikalauja tos apsaugos, taisyklių rinkinys turėtų ją išreikšti, o ne manyti, kad maršrutizavimas tuo pasirūpins.

Laikykite du klausimus atskirose taisyklėse, kad skaitytojas matytų, kuris vykdomas. Viena gudri taisyklė, tikrinanti abu, sunkiau peržiūrima ir daug sunkiau derinama, kai viena jos pusė nustoja sutapti. Dvi taisyklės su skaitikliais taip pat pasako, kuris reikalavimas nepavyksta, ko viena sujungta taisyklė niekada nepadarys.

NAT nėra ugniasienės sprendimas

Srautas į internetą iš privataus klientų telkinio paprastai reikalauja šaltinio vertimo, kad atsakymas rastų kelią atgal. Tačiau srautas, pasirinktas kitai išeinančiai IPsec politikai, turi išsaugoti reikiamą išimtį, o kiekvieno privataus šaltinio maskavimas negalvojant apie kitą apsaugos sprendimą tai sugriauna.

Priėmimas NAT grandinėje taip pat nėra bendras leidimas. NAT ir filtravimas turi skirtingus darbus, o NAT grandinė netikrina kiekvieno vėlesnio nustatyto srauto paketo, ir būtent todėl pasikliovimas ja saugumo srityje sukuria taisykles, kurios atrodo veikiančios teste ir žlunga esant apkrovai.

Priešingai taip pat tiesa ir nustebina žmones: priėmimas kažkur vienoje filtravimo bazinėje grandinėje neturi jokio svorio prieš vėlesnį atmetimą kitoje taikomoje grandinėje. Rezultatą lemia tvarka ir grandinės apimtis, o ne priėmimo buvimas faile.

Patikrinkite tikslią vidinę paslaugą

Išbandykite konkrečią paskirties vietą ir prievadą, kuriuos leidote, iš realaus kliento, ir patvirtinkite, kad atsakymas grįžta. Tada išbandykite tai, ko neleidote, ir patikrinkite, kad tai nepraeina, nes per plati taisyklė pirmą bandymą praeina taip pat gerai kaip teisinga. Užklausa, kuri niekada neišeina iš kliento, taip pat nėra ugniasienės rezultatas, todėl skaitykite skaitiklius, kad sužinotumėte, ar paketas apskritai buvo įvertintas. Du bandymai ir vienas skaitiklio parodymas pasakys daugiau nei visa popietė, praleista skaitant taisyklių rinkinį.

nftables žinynas dokumentuoja meta ipsec, rt ipsec ir krypčiai būdingas išraiškas, ir būtent ten reikia tikrinti sintaksę pagal įdiegtą versiją. Ir laikykite apimtį aiškią: tai yra IPv4 pavyzdys, jis nieko nesako apie IPv6 ir nepaverčia savavališko viešų prievadų persiuntimo VPN paslaugos dalimi.