Rozhodnite o povolení skôr, než otvoríte súbor firewallu: overení klienti môžu otvárať spojenia do jednej konkrétnej podsiete a brána musí odmietnuť každú inú tranzitnú cestu, aj keď si klient nainštaluje ďalšie trasy. Tá veta je návrh a každé pravidlo nižšie existuje preto, aby ho presadilo. Čokoľvek širšie, napríklad celý privátny adresný priestor, odchod do internetu tunelom alebo prevádzka medzi rovnocennými uzlami, je iný návrh, ktorý potrebuje vlastné rozhodnutie. Pravidlá sú tiež zámerne nudné, pretože inteligentný firewall je ten, ktorý potom nikto nedokáže auditovať.

Najprv zapíšte topológiu a povolenie

Príklad používa server Community OpenVPN s používateľským zariadením TUN nazvaným tun0, fond klientov 10.77.0.0/24, a jednu pripojenú podsietu 192.168.60.0/24 na lan0. Preposielanie IPv4 už funguje a LAN už má spiatočnú trasu do fondu, takže nič tu nezávisí od prekladu medzi nimi.

Firewall na tomto hostiteľovi vlastní UFW a žiadna sada pravidiel kontajnera ani samostatná tabuľka nftables nesmie nainštalovať skoršiu cestu prijatia. Skratka hardvérového odľahčenia toku, ktorá obchádza filter, by z ochranných reťazcov urobila dekoráciu, preto potvrďte, že žiadna nie je aktívna. Nechajte vlastné preposielanie client-to-client OpenVPN vypnuté, pretože prevádzku medzi rovnocennými uzlami, ktorá nikdy neprejde filtrom operačného systému, ňou nemožno obmedziť. Externý poslucháč a administratívne pravidlá zostávajú tak, ako sú, keďže táto zmena riadi dešifrovanú prevádzku tunela namiesto nahradenia firewallu.

Umiestnite stráže pred skoré prijatia UFW

Povolenie trasy a po ňom odmietnutie nestačí na striktnú hranicu. Štandardné pravidlá before prijímajú nadviazanú prevádzku a vybrané ICMP skôr, než sa pozrie akékoľvek používateľské pravidlo, takže tok povolený minulý týždeň môže zostať mimo nového obmedzenia cieľa len preto, že má ešte stav. Zálohujte súbory UFW a pred úpravou majte otvorenú konzolu mimo pásma.

V sekcii *filter súboru /etc/ufw/before.rules deklarujte dva reťazce vedľa existujúcich deklarácií a pred ktorýmkoľvek riadkom pravidla.

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

Hneď po deklaráciách a pred povoleniami pre vstup a preposielanie do nich skočte a definujte, čo prepúšťajú.

-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

Zvyšok sekcie a jej riadok COMMIT ponechajte. Vloženie druhej tabuľky filtra alebo vymazanie nesúvisiacich pravidiel je spôsob, akým sa zmena firewallu stane výpadkom, a súbor je jedno reštartovanie od toho, aby bol jedinou kópiou, na ktorej záleží.

Prečítajte si, čo každá stráž prepúšťa a odmieta

Prvý reťazec pokračuje v spracovaní len vtedy, keď je zdroj vo fonde, cieľom je tá jediná podsieť, výstupné rozhranie je LAN a paket putuje v pôvodnom smere svojho toku. Všetko ostatné prichádzajúce z tunela sa zahodí, vrátane zdroja mimo fondu a akéhokoľvek cieľa za povolenou podsietou.

Paket medzi rovnocennými uzlami vstupuje a vystupuje cez tun0, takže zlyhá v teste rozhrania LAN ešte predtým, než sa vôbec dostane ku kontrole cieľa. Nové spojenia z LAN smerom ku klientom tiež zlyhávajú v teste smeru odpovede, čo predvolene zatvára spätnú cestu volania.

Cieľ RETURN udržiava bežnú politiku UFW v hre. Tieto reťazce filtrujú a povolenie trasy, ktoré pridáte potom, stále rozhoduje, či bude prežívajúci paket prijatý. Práve toto oddelenie vám umožní neskôr zmeniť povolenú podsieť na jednom mieste. Keby stráže prijímali pakety priamo, každé budúce pravidlo by sa muselo pridať dvakrát.

Povoľte podsieť a zatvorte bočné dvere

Najprv zobrazte náhľad povolenia trasy, potom zrušte príznak náhľadu, aby ste ho použili: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Potom skontrolujte poradie používateľských pravidiel, pretože skoršie odmietnutie stále poráža neskoršie povolenie. Povolenie pre celú podsieť je tiež nesprávny tvar, keď má byť dostupný len port HTTPS jedného hostiteľa.

Všimnite si, čo robí zahodenie vstupu: klienti tunela nedosiahnu žiadnu službu na samotnej bráne, vrátane poslucháča DNS viazaného na jej adresu v LAN. Hostovanie DNS tam vyžaduje zámernú výnimku pred zahodením a revidovanú zmluvu o povolení. Ak UFW spravuje IPv6, pridajte zodpovedajúce zahodenia pre tun0 v súbore before6.rules tiež, pretože zoznam cieľov IPv4 nehovorí nič o paketoch IPv6.

Overte načítanú politiku, nie náhľad

Zobrazte náhľad opätovného načítania, použite ho v okne údržby a prečítajte živú sadu pravidiel.

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

Potvrďte, že stráže tunela sa objavujú pred predvolenými povoleniami stavu a ICMP. Obyčajný ufw status nezobrazuje ručne upravené pravidlá before, a preto operátori usúdia, že pravidlo chýba, keď je v skutočnosti načítané. Čítajte surový výpis zhora nadol, namiesto aby ste hľadali fragment. Ak sa stráže objavia po povolení stavu, hranica nerobí to, čo súbor naznačuje.

Potom testujte správanie, nie text. Otvorte nové spojenie k povolenému hostiteľovi a sledujte odpoveď, nasmerujte neškodnú požiadavku na cieľ mimo podsiete a potvrďte, že zomrie, vyskúšajte spojenie medzi rovnocennými uzlami, vyskúšajte službu lokálnu pre bránu a vyskúšajte nevyžiadané spojenie z LAN ku klientovi. Zahrňte jeden tok mimo rozsahu, ktorý existoval pred zmenou, a vymažte len ten tok, namiesto aby ste prepláchli celú sledovaciu tabuľku stroja.

Zapíšte obmedzenia vedľa pravidiel: toto obmedzuje tranzit a nič iné. Nezabráni klientovi používať vlastné internetové pripojenie, nezabráni povolenému hostiteľovi v LAN preposielať prevádzku ďalej a nenahrádza overovanie vnútri povolených služieb.

Súvisiace články