pf bezpečnostný prepínač v macOS pre OpenVPN: pravidlá, ktoré sa zatvárajú

V macOS je bezpečnostný prepínač len taký dobrý, ako je politika paketového filtra za ním, a pf je časť, ktorá tú politiku presadzuje. Politika musí robiť dve protichodné veci naraz: pustiť klienta k jeho serveru, aby tunel mohol existovať, a zastaviť všetko ostatné od priameho odchodu. Väčšina publikovaných sád pravidiel zvládne druhú a zabudne na prvú, takže stroj stratí pripojenie namiesto toho, aby získal ochranu. Verzia, ktorá funguje, pomenuje koncový bod, resolver a tunel, a nič viac.

Čo môže paketový filter rozhodnúť a čo nie

pf sa pozerá na rozhrania, adresy, čísla protokolov a porty, a tam sa zastaví. Nikdy nezistí, ktorý proces otvoril socket, takže povolenie napísané pre jeden program sa stane povolením pre každý program, ktorý sa dostane na ten istý port. Tak sa zo štedrej výnimky UDP stane z prepínača zase obyčajná sieť. Blokovanie s ohľadom na aplikáciu patrí klientovi alebo systémovému rozšíreniu, nie tomuto súboru.

Filter tiež nevytvára trasy. Keď klient padne, predvolená trasa môže stále ukazovať na mŕtvy tunel, a pf to prevedie na blokované pakety namiesto tichého návratu k Wi-Fi. Blokovanie je zamýšľaný výsledok, nie porucha, ktorú treba obísť.

Poradie rozhoduje o výsledku častejšie než text pravidla. Bez quick pf pokračuje v hodnotení po zhode a vyhráva posledné zodpovedajúce pravidlo, takže široký priechod pri dne prebije starostlivé výnimky nad ním. Označenie priechodov ako quick robí prvú zhodu konečnou, čo autor politiky zvyčajne mieni.

Najprv si prečítajte fakty o rozhraní a koncovom bode

Bezdrôtové rozhrania nie sú na každom Macu číslované rovnako a zariadenie tunela dostane číslo, ktoré sa medzi štartmi môže zmeniť. Pravidlo, ktoré pomenuje neexistujúce zariadenie, zlyhá pri parsovaní, čo je hlasné a ľahko zachytiteľné, zatiaľ čo pravidlo pomenúvajúce nesprávne existujúce zariadenie sa parsuje čisto a povoľuje prenos, ktorý ste chceli zastaviť.

Zbierajte fakty, kým je klient pripojený, pretože zariadenie tunela existuje len vtedy. Potrebujete rozhranie, ktoré drží predvolenú trasu, zariadenie, ktoré klient vytvoril, a adresu a port servera, na ktorý sa vytáča. Práve túto poslednú hodnotu väčšina sád pravidiel vynecháva, a preto skopírovaná sada zablokuje svoj vlastný tunel.

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

Prvý príkaz pomenuje rozhranie, ktoré práve vyhráva, druhý vypíše každé zariadenie, ktoré jadro pozná, a tretí ukáže konfigurácie VPN, ktoré systém dokáže spustiť. Zapíšte si tie odpovede a potom prečítajte adresu a port servera z vlastnej konfigurácie klienta.

Napíšte sadu pravidiel okolo cesty tunela

Súbor nižšie predvolene odmieta a znova púšťa päť vecí: loopback, zariadenie tunela, cestu klienta k jeho serveru, resolver používaný pred vznikom tunela a dve výmeny, ktoré udržujú bezdrôtové spojenie použiteľné. Názvy rozhraní a adresa servera pochádzajú z vášho stroja, preto nahraďte potvrdené hodnoty. Ani číslo tunela nebude zodpovedať tomu vášmu.

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

Riadok DHCP existuje preto, že Mac žiada o adresu skôr, než ju má, takže požiadavka vychádza z portu 68 smerom k portu 67 bez použiteľnej zdrojovej adresy. Riadok multicast umožňuje systému posúdiť, či sa bezdrôtové spojenie oplatí používať, a jeho odstránenie vytvorí stroj, ktorý v fungujúcej sieti hlási žiadne pripojenie. Riadok koncového bodu je to, čo OpenVPN vôbec umožňuje dosiahnuť jeho server; bez neho block all zahodí vonkajší handshake a tunel nikdy nevstane. Riadok resolvera je užší než všeobecné povolenie DNS, pretože pomenúva jednu adresu a jeden port namiesto každej požiadavky, ktorú stroj vykoná.

Tieto výnimky pre koncový bod a resolver sú dve, ktoré musia existovať; všetko ostatné zostáva blokované. Ak klient vytáča doslovnú adresu, riadok resolvera vynechajte a riadok koncového bodu zachovajte. Ak sa adresa servera zmení, aktualizujte ten riadok pred ďalším pripojením, alebo naplňte tabuľku pf z vlastného háku klienta a namiesto toho porovnávajte tabuľku.

Zhoďte tunel a potom reštartujte

Parsujte pred načítaním, pretože syntaktická chyba je lacná pri skúšobnom behu a drahá vo vzdialenej relácii. Potom súbor načítajte, zapnite filter, ak bol vypnutý, a prečítajte, čo je skutočne v platnosti. Spätné čítanie nie je ceremónia: iná kotva môže pridať pravidlá, ktoré ste nenapísali, takže porovnajte vytlačenú sadu so svojím súborom.

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

S načítanými pravidlami zhoďte tunel a skúste načítať stránku. Bežný prenos by sa mal zastaviť a mal by zostať zastavený aj po uspaní a prebudení stroja, pretože práve pri tomto prechode sa vracia zastaraný stav. Pripojte sa znova a potvrďte, že prenos pokračuje bez zásahu do sady pravidiel. Ak prehliadač so zhodeným tunelom stále funguje, niektoré pravidlo je širšie, než ste mysleli, a spätné čítanie ho zvyčajne pomenuje.

Reštart je časť, ktorú ľudia vynechávajú. macOS číta /etc/pf.conf pri štarte, ale čítanie súboru nie je to isté ako zapnutie filtra, takže sada pravidiel, ktorá teraz funguje, môže byť po reštarte neaktívna. Potom spustite sudo pfctl -s info a potvrďte, že stavový riadok hlási filter ako zapnutý.

Udržujte cestu von a reštart čestné

Sada pravidiel, ktorá blokuje všetko, vás môže tiež zamknúť zo stroja, ktorý spravujete na diaľku. Upravujte z lokálnej relácie, keď môžete, majte predchádzajúci súbor vedľa nového a poznajte návrat skôr, než ho budete potrebovať. Príkazy nižšie vypnú filter a znova načítajú kópiu, ktorú ste si nechali, a to je postup pre konzolu, nie cez tunel, ktorý ste práve prestrihli. Návrat za päť sekúnd porazí chytré pravidlo zakaždým.

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

Trvalosť vyžaduje launch daemon, ktorý spúšťa pfctl -e a pri štarte načítava váš súbor. Berte ho ako každú inú privilegovanú úlohu: absolútne cesty, log, ktorý si potom prečítate, a test na stroji, ku ktorému sa fyzicky dostanete. Daemon, ktorý ticho zlyhá, nechá stroj nechránený a vyzerajúci normálne.

Zdokumentujte medzery, začínajúc druhým klientom VPN, ktorý si vytvára vlastné zariadenie tunela. Vaše pravidlá pomenúvajú jedno tunelové rozhranie, takže druhé zostáva blokované alebo ho zachytí široké pravidlo pridané neskôr. Rozhrania tetheringu a hotspotu sa objavujú len občas a zaslúžia si rovnakú poznámku. Žiadna z tých medzier nie je dôvod obísť politiku; sú to podmienky, za ktorých stále platí.