OpenVPN-átjáró korlátozása egyetlen LAN-ra UFW-szabályokkal

Döntse el az engedélyt, mielőtt megnyitna egy tűzfal-fájlt: a hitelesített kliensek egyetlen meghatározott alhálózat felé nyithatnak kapcsolatot, az átjárónak pedig minden más átmenő útvonalat el kell utasítania, még akkor is, ha egy kliens további útvonalakat telepít. Ez a mondat a terv, és minden alábbi szabály azért létezik, hogy érvényt szerezzen neki. Bármi szélesebb, például a teljes privát címtartomány, az internetre jutás az alagúton át vagy a peer-to-peer forgalom, más terv, amely saját döntést igényel. A szabályok szándékosan unalmasak is, mert az okos tűzfal az, amelyet utólag senki sem tud auditálni.

Először írja le a topológiát és az engedélyt

A példa egy Community OpenVPN kiszolgálót használ felhasználói térben futó, tun0 nevű TUN-eszközzel, egy kliensmedencével: 10.77.0.0/24, és egy csatlakoztatott alhálózattal: 192.168.60.0/24 ezen: lan0. Az IPv4-továbbítás már működik, és a LAN már rendelkezik visszaúttal a medence felé, így itt semmi sem függ a köztük lévő fordításról.

A tűzfalat ezen a gazdagépen az UFW birtokolja, és sem egy tároló-szabálykészlet, sem egy külön nftables-tábla nem telepíthet korábbi elfogadási útvonalat. A szűrőt megkerülő forgalomtehermentesítési rövidítés dísztárgyakká tenné az őrláncokat, ezért erősítse meg, hogy egyik sem aktív. Hagyja az OpenVPN saját client-to-client-továbbítását kikapcsolva, mert az operációs rendszer szűrőjét soha át nem lépő peer-to-peer forgalom ezzel nem korlátozható. A külső figyelő és az adminisztrációs szabályok maradnak, ahogy vannak, mert ez a változás a visszafejtett alagútforgalmat szabályozza, nem a tűzfalat cseréli le.

Helyezze az őröket az UFW korai elfogadásai elé

Az útvonalengedély és az azt követő elutasítás nem elég egy szigorú határhoz. A kész before-szabályok a létrejött forgalmat és néhány ICMP-t még azelőtt elfogadnak, hogy bármely felhasználói szabályt megnéznének, így egy múlt héten engedélyezett folyamat pusztán azért maradhat az új célkorlátozáson kívül, mert még van állapota. Készítsen biztonsági másolatot az UFW-fájlokról, és a szerkesztés előtt tartson nyitva egy sávon kívüli konzolt.

A *filter szakaszban, a /etc/ufw/before.rules fájlban, deklaráljon két láncot a meglévő deklarációk mellett és bármely szabálysor előtt.

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

Közvetlenül a deklarációk után, valamint a bemeneti és továbbítási engedélyek előtt ugorjon beléjük, és határozza meg, mit engednek át.

-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

Tartsa meg a szakasz többi részét és annak COMMIT sorát. Egy második szűrőtábla beillesztése vagy a nem kapcsolódó szabályok törlése az az út, amelyen a tűzfalváltozás kimaradássá válik, és a fájl egyetlen újraindításra van attól, hogy az egyetlen fontos példány legyen.

Olvassa el, mit enged át és mit utasít el minden őr

Az első lánc csak akkor folytatja a feldolgozást, ha a forrás a medencében van, a cél az az egyetlen alhálózat, a kilépő interfész a LAN, és a csomag a folyamata eredeti irányában halad. Minden más, ami az alagútból érkezik, eldobódik, beleértve a medencén kívüli forrást és az engedélyezett alhálózaton túli bármely célt.

Egy peer-to-peer csomag belép a tun0 eszközre és kilép onnan, ezért már a LAN-interfész tesztjén elbukik, mielőtt egyáltalán cél-ellenőrzésre kerülne sor. A LAN felől a kliensek felé induló új kapcsolatok a válaszirány tesztjén is elbuknak, ami alapértelmezés szerint lezárja a fordított visszahívási utat.

A RETURN cél megtartja a szokásos UFW-szabályzatot. Ezek a láncok szűrnek, és a következőként hozzáadott útvonalengedély továbbra is eldönti, hogy a túlélő csomag elfogadásra kerül-e. Ez a szétválasztás teszi lehetővé, hogy később egy helyen módosítsa az engedélyezett alhálózatot. Ha az őrök közvetlenül elfogadták volna a csomagokat, minden jövőbeli szabályt kétszer kellene hozzáadni.

Engedélyezze az alhálózatot és zárja be az oldalajtókat

Először tekintse meg az útvonalengedélyt, majd vegye le az előnézet jelzőt az alkalmazásához: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Utána vizsgálja át a felhasználói szabályok sorrendjét, mert egy korábbi elutasítás még mindig legyőzi a későbbi engedélyt. Az egész alhálózatra szóló engedély szintén rossz forma, amikor csak egyetlen gazdagép HTTPS-portja lehet elérhető.

Figyelje meg, mit tesz a bemenet eldobása: az alagút kliensei semmilyen szolgáltatást nem érnek el magán az átjárón, beleértve a LAN-címéhez kötött DNS-figyelőt. A DNS ott történő hosztolása szándékos kivételt igényel az eldobás előtt és felülvizsgált engedélyezési szerződést. Ha az UFW kezeli az IPv6-ot, adjon hozzá megfelelő eldobásokat a tun0 eszközre a before6.rules fájlban is, mert egy IPv4-célokból álló lista semmit sem mond az IPv6-csomagokról.

A betöltött szabályzatot ellenőrizze, ne az előnézetet

Tekintse meg az újratöltést, alkalmazza egy karbantartási ablakban, és olvassa ki az élő szabálykészletet.

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

Erősítse meg, hogy az alagút őrei az alapértelmezett állapot- és ICMP-engedélyek előtt jelennek meg. Egy egyszerű ufw status nem jeleníti meg a kézzel szerkesztett before-szabályokat, ezért a rendszergazdák arra jutnak, hogy hiányzik egy szabály, miközben az valójában be van töltve. Olvassa a nyers listát fentről lefelé, ahelyett hogy egy töredéket keresne. Ha az őrök egy állapotengedély után jelennek meg, a határ nem azt teszi, amit a fájl sugall.

Utána viselkedést teszteljen, ne szöveget. Nyisson friss kapcsolatot egy engedélyezett gazdagéphez, és figyelje a választ, irányítson ártalmatlan kérést az alhálózaton kívüli célra, és erősítse meg, hogy elhal, próbáljon peer-to-peer kapcsolatot, próbáljon az átjárón helyi szolgáltatást, és próbáljon kéretlen LAN-ról kliensre irányuló kapcsolatot. Vegyen bele egy hatókörön kívüli folyamatot, amely a változás előtt létezett, és csak azt a folyamatot törölje, ahelyett hogy a gép teljes követési tábláját kiürítené.

Jegyezze fel a korlátokat a szabályok mellé: ez az átmenő forgalmat korlátozza, és semmi mást. Nem akadályozza meg a klienst abban, hogy saját internetkapcsolatát használja, nem akadályozza meg egy engedélyezett LAN-gazdagépet a forgalom továbbításában, és nem helyettesíti a hitelesítést az engedélyezett szolgáltatásokon belül.