Interruptor de seguretat pf de macOS per a OpenVPN: regles que tanquen

A macOS, un interruptor de seguretat val tant com la política del filtre de paquets que té al darrere, i pf és la peça que aplica aquesta política. La política ha de fer dues coses oposades alhora: deixar que el client arribi al seu servidor perquè pugui existir un túnel, i aturar que tota la resta surti directament. La majoria de conjunts de regles publicats resolen la segona i obliden la primera, així que la màquina perd connectivitat en lloc de guanyar protecció. La versió que funciona anomena el punt final, el resolutor i el túnel, i res més.

Què pot decidir un filtre de paquets i què no

pf mira interfícies, adreces, números de protocol i ports, i s’hi atura. Mai no sap quin procés ha obert un sòcol, així que un permís escrit per a un programa es converteix en un permís per a cada programa que pugui arribar al mateix port. Així és com una excepció UDP generosa torna a convertir un interruptor de seguretat en una xarxa corrent. El bloqueig conscient de l’aplicació pertany al client o a una extensió del sistema, no a aquest fitxer.

El filtre tampoc no crea rutes. Quan el client cau, la ruta per defecte pot continuar apuntant a un túnel mort, i pf ho converteix en paquets bloquejats en lloc d’una tornada silenciosa al Wi-Fi. El bloqueig és el resultat volgut, no un mal funcionament que calgui vorejar.

L’ordre decideix el resultat més sovint que el text de la regla. Sense quick, pf continua avaluant després d’una coincidència i guanya la darrera regla que coincideix, així que un pas ampli a prop del final anul·la les excepcions acurades de més amunt. Marcar els passos amb quick fa que la primera coincidència sigui definitiva, que és el que normalment vol dir un autor de polítiques.

Llegiu primer les dades de la interfície i del punt final

Les interfícies sense fil no es numeren igual a cada Mac, i el dispositiu de túnel rep un número que pot canviar entre arrencades. Una regla que anomena un dispositiu inexistent falla en analitzar-se, cosa sorollosa i fàcil de detectar, mentre que una regla que anomena el dispositiu existent equivocat s’analitza netament i permet trànsit que volíeu aturar.

Recolliu les dades mentre el client està connectat, perquè el dispositiu de túnel només existeix llavors. Necessiteu la interfície que té la ruta per defecte, el dispositiu que ha creat el client, i l’adreça i el port del servidor al qual marca. Aquest darrer valor és el que més conjunts de regles ometen, i ometre’l és per què un conjunt copiat bloqueja el seu propi túnel.

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

La primera ordre anomena la interfície que guanya ara, la segona llista cada dispositiu que el nucli coneix, i la tercera mostra les configuracions VPN que el sistema pot engegar. Apunteu aquestes respostes i després llegiu l’adreça i el port del servidor de la configuració pròpia del client.

Escriviu el conjunt de regles al voltant del camí del túnel

El fitxer de sota denega per defecte i torna a admetre cinc coses: loopback, el dispositiu de túnel, el camí del client cap al seu servidor, el resolutor usat abans que existeixi el túnel, i els dos intercanvis que mantenen utilitzable un enllaç sense fil. Els noms d’interfície i l’adreça del servidor vénen de la vostra màquina, així que substituïu els valors que heu confirmat. El número de túnel tampoc no coincidirà amb el vostre.

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

La línia DHCP existeix perquè un Mac demana una adreça abans de tenir-ne una, així que la petició surt del port 68 cap al port 67 sense cap adreça d’origen utilitzable. La línia de multicast permet al sistema jutjar si val la pena usar l’enllaç sense fil, i treure-la produeix una màquina que informa que no hi ha connexió en una xarxa que funciona. La línia del punt final és el que permet a OpenVPN arribar al seu servidor; sense ella, block all descarta l’apretada de mans exterior i el túnel no s’aixeca mai. La línia del resolutor és més estreta que un permís DNS general, perquè anomena una adreça i un port en lloc de cada consulta que fa la màquina.

Aquestes excepcions del punt final i del resolutor són les dues que hi han de ser; tota la resta continua bloquejada. Si el client marca una adreça literal, traieu la línia del resolutor i manteniu la del punt final. Si l’adreça del servidor canvia, actualitzeu aquella línia abans de la connexió següent, o ompliu una taula de pf des del ganxo propi del client i caseu la taula en lloc d’això.

Baixeu el túnel i després reinicieu

Analitzeu abans de carregar, perquè un error de sintaxi és barat en una prova en sec i car en una sessió remota. Després carregueu el fitxer, activeu el filtre si estava desactivat, i rellegiu què hi ha realment en vigor. La relectura no és cerimònia: un altre ancoratge pot afegir regles que no heu escrit, així que compareu el conjunt imprès amb el vostre fitxer.

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

Amb les regles carregades, baixeu el túnel i proveu de carregar una pàgina. El trànsit corrent s’hauria d’aturar, i hauria de continuar aturat després que la màquina dormi i es desperti, perquè és en aquesta transició on torna l’estat obsolet. Torneu a connectar i confirmeu que el trànsit reprèn sense tocar el conjunt de regles. Si un navegador encara funciona amb el túnel baixat, alguna regla és més ampla del que pensàveu, i la relectura normalment la identifica.

El reinici és la part que la gent s’estalvia. macOS llegeix /etc/pf.conf en arrencar, però llegir el fitxer no és el mateix que activar el filtre, així que un conjunt de regles que ara funciona pot quedar inactiu després d’un reinici. Executeu després sudo pfctl -s info i confirmeu que la línia d’estat informa que el filtre està activat.

Mantingueu honestos la sortida i el camí de reinici

Un conjunt de regles que bloqueja tot també us pot deixar fora d’una màquina que administreu en remot. Editeu des d’una sessió local quan pugueu, tingueu el fitxer anterior al costat del nou, i sapigueu la reversió abans de necessitar-la. Les ordres de sota desactiven el filtre i recarreguen la còpia que heu guardat, i és la seqüència per executar des d’una consola, no pel túnel que acabeu de tallar. Una reversió de cinc segons guanya una regla enginyosa cada vegada.

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

La persistència requereix un dimoni d’inici que executi pfctl -e i carregui el vostre fitxer en arrencar. Tracteu-lo com qualsevol altra feina privilegiada: camins absoluts, un registre que pugueu llegir després, i una prova en una màquina que pugueu tocar físicament. Un dimoni que falla en silenci deixa la màquina desprotegida i amb aspecte normal.

Documenteu les llacunes, començant per un segon client VPN que crea el seu propi dispositiu de túnel. Les vostres regles anomenen una interfície de túnel, així que la segona queda bloquejada o la captura una regla àmplia afegida més tard. Les interfícies de tethering i punt d’accés només apareixen de vegades i mereixen la mateixa nota. Cap d’aquestes llacunes no és motiu per saltar-se la política; són les condicions sota les quals encara es manté.