Ograničite OpenVPN pristupnik na jednu LAN pravilima UFW-a

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

Prvo zapišite topologiju i dopuštenje

Primjer koristi Community OpenVPN poslužitelj s TUN uređajem u korisničkom prostoru nazvanim 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 LAN već ima povratnu rutu do bazena, pa ništa ovdje ne ovisi o prijevodu između njih.

Vatrozidom na ovom hostu upravlja UFW, i nijedan skup pravila u kontejneru ni zasebna nftables tablica ne smije postaviti raniji put prihvaćanja. Prečac za rasterećenje toka koji preskače filtar učinio bi zaštitne lance ukrasnima, zato potvrdite da nijedan nije aktivan. Ostavite vlastito prosljeđivanje client-to-client OpenVPN-a isključenim, jer se promet između ravnopravnih računala koji nikada ne prelazi filtar operacijskog sustava ne može njime ograničiti. Vanjski slušatelj i administrativna pravila ostaju kakvi jesu, jer ova promjena uređuje dešifrirani promet tunela umjesto da zamjenjuje vatrozid.

Postavite zaštite prije ranih prihvaćanja UFW-a

Dopuštenje rute pa odbijanje nije dovoljno za strogu granicu. Standardna before pravila prihvaćaju uspostavljeni promet i odabrane ICMP prije nego što se pogleda bilo koje korisničko pravilo, pa tok dopušten prošli tjedan 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 dopuštenja 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 ponovno pokretanje udaljena od toga da postane jedina kopija koja je važna.

Pročitajte što 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 LAN 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 dopuštene podmreže.

Paket između ravnopravnih računala ulazi i izlazi kroz tun0, pa pada na testu sučelja LAN-a prije nego što se uopće dođe do provjere odredišta. Nove veze s LAN-a 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 dopuštenje rute koje zatim dodate i dalje odlučuje hoće li preživjeli paket biti prihvaćen. Upravo to razdvajanje omogućuje da kasnije promijenite dopuštenu podmrežu na jednom mjestu. Da su zaštite prihvatile pakete odmah, svako bi se buduće pravilo moralo dodati dvaput.

Dopustite podmrežu i zatvorite bočna vrata

Prvo pregledajte dopuštenje rute, zatim uklonite oznaku pregleda da ga 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 pregledajte redoslijed korisničkih pravila, jer ranije odbijanje i dalje pobjeđuje kasnije dopuštenje. Dopuštenje za cijelu podmrežu također je pogrešan oblik kada samo HTTPS port jednog hosta treba biti dostupan.

Obratite pozornost što radi odbacivanje ulaza: klijenti tunela ne mogu dosegnuti nijednu uslugu na samom pristupniku, uključujući DNS slušatelj vezan za njegovu LAN adresu. Domaćinstvo DNS-a tamo traži namjerno izuzeće prije odbacivanja i revidiran ugovor o dopuštenju. 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 dopuštenja 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 ulomak. Ako se zaštite pojave nakon dopuštenja za stanje, granica ne radi ono što datoteka sugerira.

Zatim testirajte ponašanje, a ne tekst. Otvorite novu vezu prema dopuštenom hostu i promatrajte odgovor, usmjerite bezopasan zahtjev prema odredištu izvan podmreže i potvrdite da umire, isprobajte vezu između ravnopravnih računala, isprobajte uslugu lokalnu za pristupnik i isprobajte neželjenu vezu s LAN-a 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 stroja.

Zapišite ograničenja uz pravila: ovo ograničava tranzit i ništa drugo. Ne sprječava klijenta da koristi vlastitu internetsku vezu, ne sprječava dopušteni LAN host da dalje prosljeđuje promet i ne zamjenjuje autentifikaciju unutar dopuštenih usluga.