Ndërprerësi i sigurisë pf në macOS për OpenVPN: rregulla që mbyllen

Në macOS, një ndërprerës sigurie është vetëm aq i mirë sa politika e filtrit të paketave pas tij, dhe pf është pjesa që zbaton atë politikë. Politika duhet të bëjë dy gjëra të kundërta njëkohësisht: të lejojë klientin të arrijë serverin e tij që të mund të ekzistojë një tunel, dhe të ndalojë çdo gjë tjetër të dalë drejtpërdrejt. Shumica e grupeve të publikuara të rregullave ia dalin me të dytën dhe harrojnë të parën, kështu që makina humbet lidhjen në vend që të fitojë mbrojtje. Versioni që funksionon emërton pikën fundore, zgjidhësin dhe tunelin, dhe asgjë më shumë.

Çfarë mund të vendosë një filtër paketash dhe çfarë jo

pf shikon ndërfaqet, adresat, numrat e protokollit dhe portat, dhe ndalon aty. Nuk mëson kurrë se cili proces hapi një socket, prandaj një leje e shkruar për një program bëhet leje për çdo program që mund të arrijë të njëjtën portë. Kështu një përjashtim bujar UDP e kthen një ndërprerës sigurie përsëri në një rrjet të zakonshëm. Bllokimi i vetëdijshëm për aplikacionin i takon klientit ose një shtese të sistemit, jo këtij skedari.

Filtri as nuk krijon rrugë. Kur klienti bie, rruga e parazgjedhur mund të vazhdojë të tregojë një tunel të vdekur, dhe pf e shndërron atë në paketa të bllokuara në vend të një kthimi të heshtur në Wi-Fi. Bllokimi është rezultati i synuar, jo një defekt që duhet anashkaluar.

Rendi vendos rezultatin më shpesh sesa teksti i rregullit. Pa quick, pf vazhdon vlerësimin pas një përputhjeje dhe fiton rregulli i fundit që përputhet, prandaj një kalim i gjerë në fund anulon përjashtimet e kujdesshme sipër. Shënimi i kalimeve me quick e bën përputhjen e parë përfundimtare, dhe kjo është ajo që autori i politikës zakonisht synon.

Së pari lexoni faktet e ndërfaqes dhe pikës fundore

Ndërfaqet me valë nuk numërohen njësoj në çdo Mac, dhe pajisja e tunelit merr një numër që mund të ndryshojë midis nisjeve. Një rregull që emërton një pajisje që nuk ekziston dështon në analizë, gjë që është e zhurmshme dhe e lehtë për t'u kapur, ndërsa një rregull që emërton pajisjen e gabuar ekzistuese analizohet pastër dhe lejon trafikun që doje të ndaloje.

Mblidhni faktet ndërsa klienti është i lidhur, sepse pajisja e tunelit ekziston vetëm atëherë. Ju nevojitet ndërfaqja që mban rrugën e parazgjedhur, pajisja që krijoi klienti, dhe adresa e porta e serverit që ai thërret. Pikërisht kjo vlerë e fundit është ajo që shumica e grupeve të rregullave e lënë jashtë, dhe lënia jashtë e saj është arsyeja pse një grup i kopjuar bllokon tunelin e vet.

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

Komanda e parë emërton ndërfaqen që fiton tani, e dyta liston çdo pajisje që njeh kerneli, dhe e treta tregon konfigurimet VPN që sistemi mund të nisë. Shkruani ato përgjigje, pastaj lexoni adresën dhe portën e serverit nga konfigurimi i vetë klientit.

Shkruani grupin e rregullave rreth rrugës së tunelit

Skedari më poshtë refuzon si parazgjedhje dhe ripranon pesë gjëra: loopback, pajisjen e tunelit, rrugën e klientit drejt serverit të tij, zgjidhësin që përdoret përpara se të ekzistojë tuneli, dhe dy shkëmbimet që e mbajnë një lidhje me valë të përdorshme. Emrat e ndërfaqeve dhe adresa e serverit vijnë nga makina juaj, prandaj zëvendësoni vlerat që keni konfirmuar. As numri i tunelit nuk do të përputhet me tuajin.

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

Rreshti DHCP ekziston sepse një Mac kërkon një adresë përpara se ta ketë, prandaj kërkesa del nga porta 68 drejt portës 67 pa një adresë burimore të përdorshme. Rreshti multicast lejon sistemin të gjykojë nëse lidhja me valë ia vlen të përdoret, dhe heqja e tij prodhon një makinë që raporton asnjë lidhje në një rrjet që funksionon. Rreshti i pikës fundore është ai që OpenVPN i lejon të arrijë fare serverin e tij; pa të, block all hedh poshtë shtrëngimin e dorës së jashtme dhe tuneli nuk ngrihet kurrë. Rreshti i zgjidhësit është më i ngushtë se një leje e përgjithshme DNS, sepse emërton një adresë dhe një portë në vend të çdo kërkese që bën makina.

Ato përjashtime të pikës fundore dhe të zgjidhësit janë të dyja që duhet të ekzistojnë; çdo gjë tjetër mbetet e bllokuar. Nëse klienti thërret një adresë fjalë për fjalë, hiqni rreshtin e zgjidhësit dhe mbani rreshtin e pikës fundore. Nëse adresa e serverit ndryshon, përditësoni atë rresht përpara lidhjes tjetër, ose plotësoni një tabelë pf nga grepja e vetë klientit dhe përputhni tabelën në vend të kësaj.

Ulni tunelin, pastaj rinisni

Analizoni përpara ngarkimit, sepse një gabim sintakse është i lirë në një provë të thatë dhe i shtrenjtë në një sesion në distancë. Pastaj ngarkoni skedarin, aktivizoni filtrin nëse ishte i fikur, dhe rilexoni çfarë është në të vërtetë në fuqi. Rilexsimi nuk është ceremoni: një spirancë tjetër mund të shtojë rregulla që nuk i shkruat, prandaj krahasoni grupin e shtypur me skedarin tuaj.

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

Me rregullat të ngarkuara, ulni tunelin dhe provoni të ngarkoni një faqe. Trafiku i zakonshëm duhet të ndalet dhe duhet të mbetet i ndalur pasi makina fle dhe zgjohet, sepse pikërisht në atë tranzicion kthehet gjendja e vjetër. Rilidhuni dhe konfirmoni që trafiku rifillon pa prekur grupin e rregullave. Nëse një shfletues vazhdon të funksionojë me tunelin poshtë, ndonjë rregull është më i gjerë sesa menduat, dhe rileximi zakonisht e emërton.

Rinisja është pjesa që njerëzit e kapërcejnë. macOS lexon /etc/pf.conf në nisje, por leximi i skedarit nuk është i njëjtë me aktivizimin e filtrit, prandaj një grup rregullash që funksionon tani mund të jetë joaktiv pas një rinisjeje. Më pas ekzekutoni sudo pfctl -s info dhe konfirmoni që rreshti i statusit e raporton filtrin si të aktivizuar.

Mbajini të ndershme daljen dhe rrugën e rinisjes

Një grup rregullash që bllokon gjithçka mund t'ju mbyllë edhe jashtë një makine që e administroni në distancë. Redaktoni nga një sesion lokal kur mundeni, mbani skedarin e mëparshëm pranë të riut, dhe njihni kthimin përpara se t'ju nevojitet. Komandat më poshtë e çaktivizojnë filtrin dhe ringarkojnë kopjen që ruajtët, dhe ky është sekuenca për t'u ekzekutuar nga një konsolë, jo përmes tunelit që sapo preu. Një kthim në pesë sekonda e mund një rregull të zgjuar çdo herë.

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

Qëndrueshmëria kërkon një daemon nisjeje që ekzekuton pfctl -e dhe ngarkon skedarin tuaj në nisje. Trajtojeni si çdo punë tjetër të privilegjuar: shtigje absolute, një regjistër që mund ta lexoni më pas, dhe një provë në një makinë që mund ta arrini fizikisht. Një daemon që dështon në heshtje e lë makinën të pambrojtur dhe me pamje normale.

Dokumentoni boshllëqet, duke filluar me një klient të dytë VPN që krijon pajisjen e vet të tunelit. Rregullat tuaja emërtojnë një ndërfaqe tuneli, prandaj e dyta mbetet e bllokuar ose kapet nga një rregull i gjerë i shtuar më vonë. Ndërfaqet e tethering dhe hotspot shfaqen vetëm ndonjëherë dhe meritojnë të njëjtin shënim. Asnjë prej atyre boshllëqeve nuk është arsye për të kapërcyer politikën; ato janë kushtet në të cilat ajo ende qëndron.