Comutator de siguranță pf în macOS pentru OpenVPN: reguli care se închid

În macOS, un comutator de siguranță este doar atât de bun cât politica filtrului de pachete din spatele lui, iar pf este partea care aplică acea politică. Politica trebuie să facă două lucruri opuse simultan: să lase clientul să ajungă la serverul său ca să poată exista un tunel, și să oprească tot restul din a ieși direct. Majoritatea seturilor de reguli publicate reușesc la al doilea și uită de primul, așa că mașina pierde conectivitatea în loc să câștige protecție. Versiunea care funcționează numește punctul final, resolverul și tunelul, și nimic mai mult.

Ce poate decide un filtru de pachete și ce nu

pf se uită la interfețe, adrese, numere de protocol și porturi și se oprește acolo. Nu află niciodată ce proces a deschis un socket, așa că o permisiune scrisă pentru un program devine o permisiune pentru fiecare program care poate ajunge la același port. Așa transformă o excepție UDP generoasă un comutator de siguranță înapoi într-o rețea obișnuită. Blocarea conștientă de aplicație aparține clientului sau unei extensii de sistem, nu acestui fișier.

Filtrul nu creează nici rute. Când clientul cade, ruta implicită poate încă indica un tunel mort, iar pf transformă asta în pachete blocate în loc de o revenire silențioasă la Wi-Fi. Blocarea este rezultatul dorit, nu o defecțiune de ocolit.

Ordinea decide rezultatul mai des decât textul regulii. Fără quick, pf continuă evaluarea după o potrivire și câștigă ultima regulă potrivită, așa că o trecere largă spre final anulează excepțiile atente de deasupra. Marcarea trecerilor cu quick face prima potrivire definitivă, ceea ce un autor de politici de obicei intenționează.

Citiți mai întâi faptele despre interfață și punctul final

Interfețele wireless nu sunt numerotate la fel pe fiecare Mac, iar dispozitivul tunelului primește un număr care se poate schimba între porniri. O regulă care numește un dispozitiv inexistent eșuează la parsare, ceea ce este zgomotos și ușor de prins, în timp ce o regulă care numește dispozitivul existent greșit se parsează curat și permite traficul pe care voiai să-l oprești.

Colectați faptele cât timp clientul este conectat, pentru că dispozitivul tunelului există doar atunci. Aveți nevoie de interfața care ține ruta implicită, de dispozitivul creat de client și de adresa și portul serverului pe care îl apelează. Exact acea ultimă valoare este cea pe care majoritatea seturilor de reguli o omit, iar omiterea ei este motivul pentru care un set copiat își blochează propriul tunel.

route -n get default
ifconfig -l
scutil --nc list

Prima comandă numește interfața care câștigă acum, a doua listează fiecare dispozitiv pe care îl cunoaște nucleul, iar a treia arată configurațiile VPN pe care sistemul le poate porni. Notați acele răspunsuri, apoi citiți adresa și portul serverului din configurația proprie a clientului.

Scrieți setul de reguli în jurul căii tunelului

Fișierul de mai jos refuză implicit și readmite cinci lucruri: loopback, dispozitivul tunelului, calea clientului către serverul său, resolverul folosit înainte să existe tunelul, și cele două schimburi care țin o legătură wireless utilizabilă. Numele interfețelor și adresa serverului vin de pe mașina dumneavoastră, așa că înlocuiți valorile confirmate. Nici numărul tunelului nu va coincide cu al dumneavoastră.

set skip on lo0
block all
pass out quick on utun0
# maintain this line when the server address changes
pass out quick on en1 inet proto udp to 203.0.113.10 port 1194
# only the resolver the client uses before the tunnel exists
pass out quick on en1 inet proto udp to 192.0.2.53 port 53
pass out quick on en1 inet proto udp from any port 68 to any port 67
pass out quick on en1 inet proto udp to 224.0.0.251 port 5353

Linia DHCP există pentru că un Mac cere o adresă înainte de a o avea, deci cererea pleacă de la portul 68 spre portul 67 fără o adresă sursă utilizabilă. Linia multicast lasă sistemul să judece dacă legătura wireless merită folosită, iar eliminarea ei produce o mașină care raportează nicio conexiune într-o rețea funcțională. Linia punctului final este cea care OpenVPN îi permite să ajungă la serverul său; fără ea, block all aruncă strângerea de mână exterioară și tunelul nu se ridică niciodată. Linia resolverului este mai îngustă decât o permisiune DNS generală, pentru că numește o adresă și un port în locul fiecărei interogări pe care o face mașina.

Acele excepții pentru punctul final și resolver sunt cele două care trebuie să existe; tot restul rămâne blocat. Dacă clientul apelează o adresă literală, eliminați linia resolverului și păstrați linia punctului final. Dacă adresa serverului se schimbă, actualizați acea linie înainte de următoarea conexiune, sau umpleți un tabel pf din cârligul propriu al clientului și potriviți tabelul în schimb.

Coborâți tunelul, apoi reporniți

Parsați înainte de încărcare, pentru că o eroare de sintaxă este ieftină într-o probă uscată și scumpă într-o sesiune la distanță. Apoi încărcați fișierul, activați filtrul dacă era oprit, și recitiți ce este de fapt în vigoare. Recitirea nu este ceremonie: alt ancoraj poate adăuga reguli pe care nu le-ați scris, așa că comparați setul tipărit cu fișierul dumneavoastră.

sudo pfctl -n -v -f /etc/pf.conf
sudo pfctl -f /etc/pf.conf
sudo pfctl -e
sudo pfctl -s rules
sudo pfctl -s Anchors
sudo pfctl -a <anchor> -s rules
sudo pfctl -s info

Cu regulile încărcate, coborâți tunelul și încercați să încărcați o pagină. Traficul obișnuit ar trebui să se oprească și ar trebui să rămână oprit după ce mașina adoarme și se trezește, pentru că exact în acea tranziție starea veche se strecoară înapoi. Reconectați-vă și confirmați că traficul reia fără să atingeți setul de reguli. Dacă un browser încă funcționează cu tunelul coborât, o regulă este mai largă decât credeați, iar recitirea de obicei o numește.

Repornirea este partea pe care oamenii o sar. macOS citește /etc/pf.conf la boot, dar citirea fișierului nu este același lucru cu activarea filtrului, așa că un set de reguli care funcționează acum poate fi inactiv după o repornire. Rulați apoi sudo pfctl -s info și confirmați că linia de stare raportează filtrul ca activat.

Păstrați cinstite ieșirea și calea de repornire

Un set de reguli care blochează tot poate, de asemenea, să vă închidă în afara unei mașini pe care o administrați de la distanță. Editați dintr-o sesiune locală când puteți, păstrați fișierul anterior lângă cel nou și cunoașteți revenirea înainte de a avea nevoie de ea. Comenzile de mai jos dezactivează filtrul și reîncarcă copia pe care ați păstrat-o, iar aceasta este secvența de rulat dintr-o consolă, nu prin tunelul pe care tocmai l-ați tăiat. O revenire în cinci secunde bate o regulă deșteaptă de fiecare dată.

sudo pfctl -d
sudo pfctl -f /etc/pf.conf.previous
sudo pfctl -s rules

Persistența cere un daemon de lansare care rulează pfctl -e și încarcă fișierul dumneavoastră la boot. Tratați-l ca pe orice altă sarcină privilegiată: căi absolute, un jurnal pe care îl puteți citi după aceea și un test pe o mașină la care puteți ajunge fizic. Un daemon care eșuează în tăcere lasă mașina neprotejată și cu aspect normal.

Documentați lacunele, începând cu un al doilea client VPN care își creează propriul dispozitiv de tunel. Regulile dumneavoastră numesc o singură interfață de tunel, așa că a doua rămâne blocată sau este prinsă de o regulă largă adăugată mai târziu. Interfețele de tethering și hotspot apar doar uneori și merită aceeași notă. Niciuna dintre aceste lacune nu este un motiv să săriți politica; ele sunt condițiile în care ea încă se susține.