macOS pf drošības slēdzis OpenVPN: noteikumi, kas aizveras

Operētājsistēmā macOS drošības slēdzis ir tik labs, cik laba ir aiz tā esošā pakešu filtra politika, un pf ir tā daļa, kas šo politiku izpilda. Politikai vienlaikus jādara divas pretējas lietas: jāļauj klientam sasniegt savu serveri, lai tunelis varētu pastāvēt, un jāaptur viss pārējais no tiešas iziešanas. Lielākā daļa publicēto noteikumu kopu tiek galā ar otro un aizmirst pirmo, tāpēc iekārta zaudē savienojumu, nevis iegūst aizsardzību. Versija, kas strādā, nosauc galapunktu, atrisinātāju un tuneli, un neko vairāk.

Ko pakešu filtrs var izlemt un ko ne

pf skatās uz saskarnēm, adresēm, protokolu numuriem un portiem, un tur tas apstājas. Tas nekad neuzzina, kurš process atvēra ligzdu, tāpēc vienai programmai rakstīta atļauja kļūst par atļauju katrai programmai, kas var sasniegt to pašu portu. Tā dāsna UDP izņēmuma dēļ drošības slēdzis atkal pārvēršas parastā tīklā. Programmapziņas bloķēšana pieder klientam vai sistēmas paplašinājumam, nevis šim failam.

Filtrs arī neveido maršrutus. Kad klients nokrīt, noklusējuma maršruts joprojām var norādīt uz mirušu tuneli, un pf to pārvērš bloķētās paketēs, nevis klusā atgriešanās pie Wi-Fi. Bloķēšana ir paredzētais rezultāts, nevis kļūme, ko vajadzētu apiet.

Rezultātu biežāk izšķir secība, nevis noteikuma teksts. Bez quick pf turpina vērtēt pēc atbilstības un uzvar pēdējais atbilstošais noteikums, tāpēc plaša pāreja apakšā atceļ rūpīgos izņēmumus virs tās. Pāreju atzīmēšana ar quick padara pirmo atbilstību galīgu, un to parasti domā politikas autors.

Vispirms izlasiet saskarnes un galapunkta faktus

Bezvadu saskarnes ne katrā Mac tiek numurētas vienādi, un tuneļa ierīce iegūst numuru, kas starp palaišanām var mainīties. Noteikums, kas nosauc neesošu ierīci, neizdodas parsēšanas laikā, un tas ir skaļi un viegli noķerams, savukārt noteikums, kas nosauc nepareizo esošo ierīci, tiek parsēts tīri un ļauj satiksmei, kuru gribējāt apturēt.

Vāciet faktus, kamēr klients ir savienots, jo tuneļa ierīce pastāv tikai tad. Jums vajag saskarni, kas tur noklusējuma maršrutu, klienta izveidoto ierīci, un tā servera adresi un portu, uz kuru tas zvana. Tieši šo pēdējo vērtību lielākā daļa noteikumu kopu izlaiž, un tās izlaišana ir iemesls, kāpēc nokopēta kopa bloķē savu pašas tuneli.

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

Pirmā komanda nosauc saskarni, kas pašlaik uzvar, otrā uzskaita katru kodolam zināmo ierīci, un trešā parāda VPN konfigurācijas, ko sistēma var palaist. Pierakstiet šīs atbildes, pēc tam nolasiet servera adresi un portu no paša klienta konfigurācijas.

Rakstiet noteikumu kopu ap tuneļa ceļu

Tālāk esošais fails pēc noklusējuma aizliedz un atkal ielaiž piecas lietas: loopback, tuneļa ierīci, klienta ceļu uz tā serveri, atrisinātāju, kas tiek izmantots pirms tuneļa pastāvēšanas, un divas apmaiņas, kas uztur bezvadu savienojumu lietojamu. Saskarņu nosaukumi un servera adrese nāk no jūsu iekārtas, tāpēc aizstājiet apstiprinātās vērtības. Arī tuneļa numurs nesakritīs ar jūsējo.

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

DHCP rinda pastāv tāpēc, ka Mac pieprasa adresi pirms tam, kad tā tam ir, tāpēc pieprasījums iziet no porta 68 uz portu 67 bez lietojamas avota adreses. Multicast rinda ļauj sistēmai spriest, vai bezvadu savienojumu ir vērts izmantot, un tās noņemšana rada iekārtu, kas strādājošā tīklā ziņo par savienojuma neesamību. Galapunkta rinda ir tā, kas ļauj OpenVPN vispār sasniegt savu serveri; bez tās block all nomet ārējo rokasspiedienu un tunelis nekad nepaceļas. Atrisinātāja rinda ir šaurāka par vispārīgu DNS atļauju, jo nosauc vienu adresi un vienu portu, nevis katru vaicājumu, ko iekārta veic.

Šie galapunkta un atrisinātāja izņēmumi ir divi, kuriem jāpastāv; viss pārējais paliek bloķēts. Ja klients zvana uz burtisku adresi, izņemiet atrisinātāja rindu un paturiet galapunkta rindu. Ja servera adrese mainās, atjauniniet šo rindu pirms nākamā savienojuma, vai aizpildiet pf tabulu no klienta paša āķa un tā vietā saskaņojiet tabulu.

Nolaidiet tuneli, pēc tam pārstartējiet

Parsējiet pirms ielādes, jo sintakses kļūda ir lēta sausā palaidē un dārga attālinātā sesijā. Pēc tam ielādējiet failu, ieslēdziet filtru, ja tas bija izslēgts, un nolasiet, kas patiešām ir spēkā. Nolasīšana nav ceremonija: cits enkurs var pievienot noteikumus, kurus jūs neuzrakstījāt, tāpēc salīdziniet izdrukāto kopu ar savu failu.

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

Ar ielādētiem noteikumiem nolaidiet tuneli un mēģiniet ielādēt lapu. Parastajai satiksmei jāapstājas, un tai jāpaliek apstādinātai arī pēc tam, kad iekārta aizmieg un pamostas, jo tieši šajā pārejā vecais stāvoklis atkal ieslīd. Savienojieties vēlreiz un apstipriniet, ka satiksme atsākas, neaiztiekot noteikumu kopu. Ja pārlūks joprojām darbojas ar nolaistu tuneli, kāds noteikums ir plašāks, nekā domājāt, un nolasīšana parasti to nosauc.

Pārstartēšana ir tā daļa, ko cilvēki izlaiž. macOS palaišanas laikā lasa /etc/pf.conf, bet faila lasīšana nav tas pats, kas filtra ieslēgšana, tāpēc noteikumu kopa, kas tagad strādā, pēc pārstartēšanas var būt neaktīva. Pēc tam palaidiet sudo pfctl -s info un apstipriniet, ka statusa rinda ziņo filtru kā ieslēgtu.

Turiet izeju un pārstartēšanas ceļu godīgus

Noteikumu kopa, kas bloķē visu, var arī izslēgt jūs no iekārtas, kuru administrējat attālināti. Rediģējiet no vietējās sesijas, kad varat, turiet iepriekšējo failu blakus jaunajam un ziniet atgriešanās ceļu, pirms tas jums vajadzīgs. Tālāk esošās komandas izslēdz filtru un no jauna ielādē jūsu saglabāto kopiju, un tā ir secība, kas jāizpilda no konsoles, nevis caur tikko pārgriezto tuneli. Piecu sekunžu atgriešanās katru reizi pārspēj gudru noteikumu.

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

Noturībai vajadzīgs palaišanas dēmons, kas izpilda pfctl -e un palaišanas laikā ielādē jūsu failu. Apieties ar to kā ar jebkuru citu privilēģiju darbu: absolūti ceļi, žurnāls, ko varat izlasīt vēlāk, un pārbaude iekārtā, kurai varat fiziski piekļūt. Dēmons, kas klusi neizdodas, atstāj iekārtu neaizsargātu un izskatās normāli.

Dokumentējiet robus, sākot ar otru VPN klientu, kas izveido savu tuneļa ierīci. Jūsu noteikumi nosauc vienu tuneļa saskarni, tāpēc otrā paliek bloķēta vai to uztver vēlāk pievienots plašs noteikums. Tethering un hotspot saskarnes parādās tikai dažreiz un ir pelnījušas to pašu piezīmi. Neviens no šiem robiem nav iemesls izlaist politiku; tie ir nosacījumi, kuros tā joprojām ir spēkā.