Apriboti OpenVPN tinklų vartus vienu LAN naudojant UFW taisykles

Leiskite tunelio klientams pasiekti vieną potinklį ir nieko daugiau. Apsaugos grandinės prieš ankstyvuosius UFW priėmimus, maršruto leidimas ir testai, įrodantys ribą.

Nuspręskite leidimą prieš atidarydami ugniasienės failą: autentifikuoti klientai gali atidaryti ryšius į vieną konkretų potinklį, o vartai turi atmesti kiekvieną kitą tranzito kelią, net kai klientas įdiegia papildomus maršrutus. Tas sakinys yra projektas, ir kiekviena taisyklė žemiau egzistuoja jam įgyvendinti. Kažkas platesnio, pavyzdžiui, visa privati adresų erdvė, išėjimas į internetą per tunelį arba lygiaverčių mazgų srautas, yra kitas projektas, kuriam reikia atskiro sprendimo. Taisyklės taip pat tyčia nuobodžios, nes protinga ugniasienė yra ta, kurios vėliau niekas negali audituoti.

Pirmiausia užrašykite topologiją ir leidimą

Pavyzdyje naudojamas Community OpenVPN serveris su naudotojo erdvės TUN įrenginiu, vadinamu tun0, klientų telkiniu 10.77.0.0/24, ir vienu prijungtu potinkliu 192.168.60.0/24 sąsajoje lan0. IPv4 persiuntimas jau veikia, o LAN jau turi grįžimo maršrutą į telkinį, todėl niekas čia nepriklauso nuo vertimo tarp jų.

Šio kompiuterio ugniasienė priklauso UFW, ir joks konteinerio taisyklių rinkinys ar atskira nftables lentelė negali įdiegti ankstesnio priėmimo kelio. Srauto iškėlimo apėjimas, praleidžiantis filtrą, apsaugos grandines paverstų dekoracija, todėl patvirtinkite, kad nė viena nėra aktyvi. Palikite paties OpenVPN client-to-client persiuntimą išjungtą, nes lygiaverčių mazgų srautas, kuris niekada nekerta operacinės sistemos filtro, negali būti juo apribotas. Išorinis klausytojas ir administravimo taisyklės lieka kaip yra, nes šis pakeitimas valdo iššifruotą tunelio srautą, o ne pakeičia ugniasienę.

Pastatykite apsaugas prieš ankstyvuosius UFW priėmimus

Maršruto leidimo ir po jo einančio atmetimo nepakanka griežtai ribai. Standartinės before taisyklės priima nusistovėjusį srautą ir kai kuriuos ICMP dar prieš atsižvelgiant į bet kurią naudotojo taisyklę, todėl praėjusią savaitę leistas srautas gali likti už naujojo paskirties apribojimo vien dėl to, kad jis dar turi būseną. Padarykite UFW failų atsarginę kopiją ir prieš redaguodami laikykite atvirą juostos išorės konsolę.

Failo *filter skirsnyje /etc/ufw/before.rules paskelbkite dvi grandines prie esamų deklaracijų ir prieš bet kurią taisyklės eilutę.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Iš karto po deklaracijų ir prieš įėjimo bei persiuntimo leidimus įšokkite į jas ir apibrėžkite, ką jos įsileidžia.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Išsaugokite likusią skirsnio dalį ir jo COMMIT eilutę. Antros filtro lentelės įklijavimas ar nesusijusių taisyklių trynimas yra kelias, kuriuo ugniasienės pakeitimas virsta sutrikimu, o failas yra per vieną perkrovimą nuo to, kad taptų vienintele svarbia kopija.

Perskaitykite, ką kiekviena apsauga įsileidžia ir atmeta

Pirmoji grandinė tęsia apdorojimą tik kai šaltinis yra telkinyje, paskirtis yra tas vienas potinklis, išėjimo sąsaja yra LAN, o paketas juda pradine savo srauto kryptimi. Viskas kita, kas ateina iš tunelio, išmetama, įskaitant šaltinį už telkinio ir bet kurią paskirtį už leidžiamo potinklio.

Lygiaverčių mazgų paketas įeina ir išeina per tun0, todėl jis nepraeina LAN sąsajos testo dar nepasiekus paskirties patikros. Nauji ryšiai iš LAN klientų link taip pat nepraeina atsakymo krypties testo, o tai pagal nutylėjimą uždaro atvirkštinį atgalinio iškvietimo kelią.

Tikslas RETURN palieka įprastą UFW politiką galioti. Šios grandinės filtruoja, o toliau pridedamas maršruto leidimas vis dar nusprendžia, ar išlikęs paketas bus priimtas. Būtent šis atskyrimas leidžia vėliau vienoje vietoje pakeisti leidžiamą potinklį. Jei apsaugos priimtų paketus tiesiogiai, kiekvieną būsimą taisyklę reikėtų pridėti du kartus.

Leiskite potinklį ir uždarykite šoninius duris

Pirmiausia peržiūrėkite maršruto leidimą, tada nuimkite peržiūros vėliavėlę, kad jį pritaikytumėte: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Po to peržiūrėkite naudotojo taisyklių tvarką, nes ankstesnis atmetimas vis dar nugali vėlesnį leidimą. Leidimas visam potinkliui taip pat yra netinkama forma, kai turi būti pasiekiamas tik vieno kompiuterio HTTPS prievadas.

Atkreipkite dėmesį, ką daro įėjimo išmetimas: tunelio klientai negali pasiekti jokios paslaugos pačiuose vartuose, įskaitant DNS klausytoją, susietą su jų LAN adresu. DNS talpinimas ten reikalauja sąmoningos išimties prieš išmetimą ir peržiūrėtos leidimo sutarties. Jei UFW valdo IPv6, pridėkite atitinkamus išmetimus tun0 atžvilgiu faile before6.rules taip pat, nes IPv4 paskirčių sąrašas nieko nesako apie IPv6 paketus.

Tikrinkite įkeltą politiką, o ne peržiūrą

Peržiūrėkite perkrovimą, pritaikykite jį techninės priežiūros lange ir perskaitykite veikiančią taisyklių rinkinį.

sudo ufw --dry-run reload
sudo ufw show raw

Patvirtinkite, kad tunelio apsaugos atsiranda prieš numatytuosius būsenos ir ICMP leidimus. Paprastas ufw status nerodo ranka redaguotų before taisyklių, todėl operatoriai daro išvadą, kad taisyklės trūksta, nors ji iš tikrųjų įkelta. Skaitykite neapdorotą sąrašą iš viršaus į apačią, o ne ieškokite fragmento. Jei apsaugos atsiranda po būsenos leidimo, riba nedaro to, ką siūlo failas.

Tada testuokite elgseną, o ne tekstą. Atidarykite naują ryšį su leidžiamu kompiuteriu ir stebėkite atsakymą, nukreipkite nekenksmingą užklausą į paskirtį už potinklio ir patvirtinkite, kad ji miršta, išbandykite lygiaverčių mazgų ryšį, išbandykite vartuose esančią vietinę paslaugą ir išbandykite neprašytą LAN į klientą ryšį. Įtraukite vieną už apimties ribų esantį srautą, kuris egzistavo prieš pakeitimą, ir išvalykite tik tą srautą, o ne ištuštinkite visą įrenginio sekimo lentelę.

Užrašykite apribojimus šalia taisyklių: tai riboja tranzitą ir nieko daugiau. Tai netrukdo klientui naudotis savo interneto ryšiu, netrukdo leidžiamam LAN kompiuteriui persiųsti srautą toliau ir nepakeičia autentifikacijos leidžiamų paslaugų viduje.

Susiję straipsniai