Huminto sa pag-filter ang SSID firewall rule matapos magpalit ng Wi-Fi
Ang firewall na nakabatay sa SSID ay nabigo nang bukas kapag nagbabalik ang Android ng hindi kilalang pangalan ng network. Ihiwalay ang pagkakakilanlan sa pagpapatupad at bigyan ng sariling patakaran ang hindi kilala.
Simple ang tuntunin: i-filter ang trapiko habang konektado lang ang telepono sa Wi-Fi ng opisina. Tumagal ito nang mga buwan, at pagkatapos isang umaga ang telepono ay nasa parehong SSID na may parehong icon ng susi at tumigil na ang pag-filter. Wala namang nagbago sa network; ang nagbago ay kung nakikita ng app ang pangalan ng network. Sa Android, ang «sa aling Wi-Fi ako» at «harangin ang trapikong ito» ay dalawang magkaibang gawain, at ang firewall na pinagsasama ang mga ito ay nabigo nang bukas sa mismong sandaling hindi available ang pangalan.
Ang sintomas: nawawala ang pagkakakilanlan at sumusunod ang patakaran
Ang panuntunang SSID ay nagbabasa ng halaga at pagkatapos ay pumipili ng sangay. Kapag walang kapaki-pakinabang na ibinalik ang pagbasa, kailangang may gawin ang code, at ang karaniwang default ay «hindi ito ang inaasahang network, kaya huwag mag-filter». Ginagawa ng default na iyon na tagas ng trapiko ang isang problema sa pahintulot. Nananatiling nakikita ang icon ng susi dahil tumatakbo pa ang serbisyo ng VPN; ibang sangay lang ang ipinapatupad nito.
Tumingin sa pagkakasunod-sunod ng mga pangyayari, hindi sa network. Ang tinanggihang dialog ng pahintulot, update ng sistema na naglipat ng access sa SSID sa likod ng ibang pahintulot, naka-off na serbisyo ng lokasyon, o pagbabago ng patakaran ng work profile ay maaaring magbigay ng parehong resulta habang nananatili ang telepono sa parehong access point.
Bakit maaaring bumalik na hindi kilala ang pangalan
Ang WifiInfo.getSSID() ay nagbabalik ng identifier ng service set ng kasalukuyang network, at dokumentado ng Android na ang access sa mga field na sensitibo sa lokasyon ay nakadepende sa pahintulot. Kapag walang access, nagbabalik ang tawag ng UNKNOWN_SSID sa halip na mabigong malakas. Kaya ang walang laman o hindi kilalang halaga ay hindi patunay na umalis ang telepono sa Wi-Fi; patunay ito na hindi maikaklasipika ng app ang network.
Dalawang pagsusuri ang naghihiwalay sa mga kaso. Tiyakin na konektado ang telepono at tingnan kung ano ang iniuulat ng sistema, pagkatapos ay tiyakin na talagang taglay ng app ang pahintulot na kailangan nito sa bersyong ito ng Android:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Kung ang linya ng status ay nagpapakita ng konektadong network habang ang app ay nakakakita ng hindi kilalang pangalan, may problema ka sa pahintulot o sa antas ng API, hindi problema sa Wi-Fi. Ayusin iyon bago hawakan ang mga tuntunin ng firewall, dahil bawat tuntunin sa ibaba ay sinusuri laban sa halagang hindi mabasa ng app.
Saan talaga tumatakbo ang pag-filter
Ang lokal na firewall ng Android ay karaniwang gumagamit ng modelong VpnService nang hindi nagpapadala ng trapiko sa malayong server: kinukuha nito ang virtual na interface, inilalapat ang sariling mga tuntunin at ipinapasa ang pinapayagan nito. Isang aktibong serbisyo ng VPN lang ang pinapayagan ng platform sa bawat profile ng user, at pinapalitan ng pangalawa ang una sa halip na magpatong dito. Kaya ang hiwalay na app ng firewall at hiwalay na VPN sa trabaho ay hindi bumubuo ng dalawang-yugtong kadena; isa sa kanila ang mananalo.
Mahalaga ito sa tuntuning SSID dahil magkaibang bahagi ang punto ng pagpapatupad at ang punto ng pagmamasid. Ang VpnService ang nagpapasya kung ano ang lumalabas sa device; ang API ng Wi-Fi ay nagbibigay lang ng label. Maaaring magpatupad nang tama ang app at mag-uri nang mali, at iyon mismo ang sira sa artikulong ito.
Bigyan ng sariling patakaran ang hindi kilala
Ituring na tatlong estado ang pagkakakilanlan ng network, at isulat ang patakaran ng bawat isa bago ilabas ang tuntunin. Ang ikatlong estado ang nakakalimutan, at doon ka ilalagay ng attacker o ng maling configuration.
| Observation | Policy to specify |
|---|---|
| Expected SSID is readable | The explicit filtering policy you designed |
| A different SSID is readable | The default policy for untrusted networks |
| Unknown, changing or unreadable | Fail closed until classification is reliable |
Ang mabigong sarado ay nangangahulugang ang hindi kilalang estado ay nagmamana ng pinakamahigpit na makatwirang patakaran sa halip na ang pinakamadali. Kung dahil doon ay hindi na magamit ang telepono sa bagong network, ang tamang solusyon ay sadyang ginawa at nakikitang eksepsyon, hindi isang tahimik na desisyon ng pagtitiwala na nakatago sa pagsusuri ng walang laman na halaga.
Ang pamilyar na SSID ay isang label, hindi patunay ng operator ng network. Kahit sino ay makakapagpatakbo ng access point na may pangalan ng opisina, kaya ang pagtutugma ng pangalan ay hindi dapat maging tanging bagay sa pagitan ng sensitibong session at hindi pinagkakatiwalaang segment.
Subukan ang mga transisyon, hindi ang steady state
Ang pagsusuri sa steady state ay pumapasa sa network kung saan mo itinayo ang tuntunin. Nabubuhay ang mga sira sa mga transisyon: tinanggihang pahintulot, Wi-Fi papuntang cellular, isang SSID papunta sa iba, na-restart ang serbisyo ng VPN, at ibang app ng VPN na kumukuha ng interface. Para sa bawat isa, magpasya kung muling isasaalang-alang ang mga kasalukuyang koneksyon at kung nananatiling harang ang protektadong trapiko habang hindi kilala ang estado.
Isulat ang resulta sa tatlong pangungusap: ang naobserbahang kondisyon, ang bahaging nagpapatupad ng desisyon, at ang sadyang fallback. Kung may kulang sa tatlo, hindi pa patakaran ang tuntunin; ito ay isang hula na nagkataong gumagana sa network ng opisina.