Ograničite OpenVPN prolaz na jednu lokalnu mrežu pravilima UFW-a

Odlučite dozvolu prije nego što otvorite datoteku vatrozida: autentificirani klijenti smiju otvarati veze prema jednoj određenoj podmreži, a prolaz mora odbiti svaki drugi tranzitni put čak i kada klijent instalira dodatne rute. Ta rečenica jeste nacrt, i svako pravilo ispod postoji da je provede. Nešto šire, poput cjelokupnog privatnog adresnog prostora, izlaska na internet kroz tunel ili mreže ravnopravnih računara, drugi je nacrt koji traži vlastitu odluku. Pravila su i namjerno dosadna, jer pametan vatrozid je onaj koji nitko ne može kasnije revidirati.

Prvo zapišite topologiju i dozvolu

Primjer koristi Community OpenVPN server s TUN uređajem u korisničkom prostoru pod nazivom tun0, bazen klijenata 10.77.0.0/24, i jednu priključenu podmrežu 192.168.60.0/24 na lan0. IPv4 prosljeđivanje već radi i lokalna mreža već ima povratnu rutu do bazena, pa ništa ovdje ne zavisi od prevođenja između njih.

Vatrozidom na ovom hostu upravlja UFW, i nijedan skup pravila u kontejneru ni zasebna nftables tablica ne smije postaviti raniji put prihvatanja. Prečica za rasterećenje toka koja preskače filtar učinila bi zaštitne lance ukrasnima, zato potvrdite da nijedna nije aktivna. Ostavite vlastito prosljeđivanje client-to-client OpenVPN-a isključenim, jer mreža ravnopravnih računara koja nikada ne prelazi filtar operativnog sistema ne može se njime ograničiti. Vanjski slušalac i administrativna pravila ostaju kakvi jesu, jer ova promjena uređuje dešifriran promet tunela umjesto da zamjenjuje vatrozid.

Postavite zaštite prije ranih prihvatanja UFW-a

Dozvola rute praćena odbijanjem nije dovoljna za strogu granicu. Standardna before pravila prihvataju uspostavljeni promet i odabrane ICMP prije nego što se pogleda bilo koje korisničko pravilo, pa tok dozvoljen prošle sedmice može ostati izvan novog ograničenja odredišta samo zato što još ima stanje. Napravite sigurnosnu kopiju UFW datoteka i držite izvanmrežnu konzolu otvorenom prije uređivanja.

U odjeljku *filter datoteke /etc/ufw/before.rules, deklarirajte dva lanca uz postojeće deklaracije i prije bilo koje linije pravila.

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

Odmah nakon deklaracija, i prije dozvola za ulaz i prosljeđivanje, skočite u njih i odredite što propuštaju.

-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

Zadržite ostatak odjeljka i njegovu liniju COMMIT. Lijepljenje druge tablice filtra ili brisanje nepovezanih pravila način je na koji promjena vatrozida postaje ispad, a datoteka je jedno restartovanje udaljena od toga da postane jedina kopija koja je važna.

Pročitajte šta svaka zaštita propušta i odbija

Prvi lanac nastavlja obradu samo kada je izvor u bazenu, odredište je ta jedna podmreža, izlazno sučelje je lokalna mreža i paket putuje u izvornom smjeru svog toka. Sve ostalo što dolazi iz tunela odbacuje se, uključujući izvor izvan bazena i svako odredište izvan dozvoljene podmreže.

Paket ravnopravnih računara ulazi i izlazi kroz tun0, pa pada na testu sučelja lokalne mreže prije nego što se uopće dođe do provjere odredišta. Nove veze s lokalne mreže prema klijentima također padaju na testu smjera odgovora, što po zadanom zatvara obrnuti put povratnog poziva.

Meta RETURN zadržava uobičajenu UFW politiku na snazi. Ovi lanci filtriraju, a dozvola rute koju zatim dodate i dalje odlučuje hoće li preživjeli paket biti prihvaćen. Upravo to razdvajanje omogućuje da kasnije promijenite dozvoljenu podmrežu na jednom mjestu. Da su zaštite prihvatile pakete odmah, svako buduće pravilo moralo bi se dodati dvaput.

Dozvolite podmrežu i zatvorite bočna vrata

Prvo pregledajte dozvolu rute, zatim uklonite oznaku pregleda da je primijenite: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Poslije toga pregledajte redoslijed korisničkih pravila, jer ranije odbijanje i dalje pobjeđuje kasniju dozvolu. Dozvola za cijelu podmrežu također je pogrešan oblik kada samo HTTPS port jednog hosta treba biti dostupan.

Obratite pažnju šta radi odbacivanje ulaza: klijenti tunela ne mogu dosegnuti nijednu uslugu na samom prolazu, uključujući DNS slušalac vezan za njegovu adresu u lokalnoj mreži. Domaćinstvo DNS-a tamo traži namjerno izuzeće prije odbacivanja i revidiran ugovor o dozvoli. Ako UFW upravlja IPv6, dodajte odgovarajuća odbacivanja za tun0 u before6.rules također, jer popis odredišta IPv4 ne govori ništa o paketima IPv6.

Provjerite učitanu politiku, ne pregled

Pregledajte ponovno učitavanje, primijenite ga u prozoru za održavanje i pročitajte živi skup pravila.

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

Potvrdite da se zaštite tunela pojavljuju prije zadanih dozvola za stanje i ICMP. Obični ufw status ne prikazuje ručno uređena before pravila, zato operateri zaključe da pravilo nedostaje kada je ono zapravo učitano. Čitajte sirovi popis odozgo prema dolje umjesto da tražite fragment. Ako se zaštite pojave nakon dozvole za stanje, granica ne radi ono što datoteka sugerira.

Zatim testirajte ponašanje, a ne tekst. Otvorite novu vezu prema dozvoljenom hostu i gledajte odgovor, usmjerite bezopasan zahtjev prema odredištu izvan podmreže i potvrdite da umire, isprobajte vezu ravnopravnih računara, isprobajte uslugu lokalnu za prolaz i isprobajte neželjenu vezu s lokalne mreže prema klijentu. Uključite jedan tok izvan opsega koji je postojao prije promjene i obrišite samo taj tok umjesto da ispraznite cijelu tablicu praćenja mašine.

Zapišite ograničenja uz pravila: ovo ograničava tranzit i ništa drugo. Ne sprječava klijenta da koristi vlastitu internet vezu, ne sprječava dozvoljeni host u lokalnoj mreži da dalje prosljeđuje promet i ne zamjenjuje autentifikaciju unutar dozvoljenih usluga.