Pravidlo firewallu podľa SSID prestalo filtrovať po prepnutí Wi-Fi
Firewall naviazaný na SSID zlyhá otvorene, keď Android vráti neznámy názov siete. Oddeľte identitu od vynucovania a dajte neznámemu stavu vlastnú politiku.
Pravidlo bolo jednoduché: filtrovať prevádzku iba pri pripojení k firemnej Wi-Fi. Vydržalo mesiace, a potom jedného rána telefón sedel na tej istej SSID s tou istou ikonou kľúča a filtrovanie sa zastavilo. Na sieti sa nič nezmenilo; zmenilo sa to, či aplikácia vidí názov siete. V Androide sú „na akej Wi-Fi som“ a „zablokuj túto prevádzku“ dve oddelené úlohy a firewall, ktorý ich zlieva, zlyhá otvorene presne vtedy, keď názov prestane byť dostupný.
Príznak: identita zmizne a politika ju nasleduje
Pravidlo podľa SSID prečíta hodnotu a potom vyberie vetvu. Keď čítanie nevráti nič užitočné, kód musí niečo urobiť, a bežná predvolená voľba je „nie je to očakávaná sieť, tak nefiltrovať“. Táto predvolená voľba mení problém s oprávnením na únik prevádzky. Ikona kľúča zostáva viditeľná, pretože služba VPN stále beží; len vykonáva inú vetvu.
Sledujte poradie udalostí, nie sieť. Odmietnutá žiadosť o povolenie, aktualizácia systému, ktorá posunula prístup k SSID za iné povolenie, vypnuté služby polohy alebo zmena politiky pracovného profilu, to všetko môže dať rovnaký výsledok, kým telefón zostáva na tom istom prístupovom bode.
Prečo môže názov prísť ako neznámy
WifiInfo.getSSID() vracia identifikátor sady služieb aktuálnej siete a Android dokumentuje, že prístup k polohovo citlivým poliam závisí od povolenia. Keď prístup nie je dostupný, volanie vráti UNKNOWN_SSID namiesto hlasného zlyhania. Prázdna alebo neznáma hodnota teda nie je dôkazom, že telefón opustil Wi-Fi; je dôkazom, že aplikácia nedokáže sieť klasifikovať.
Dve kontroly prípady oddeľujú. Overte, že telefón je pripojený, a pozrite sa, čo systém hlási, potom overte, že aplikácia skutočne má povolenie, ktoré v tejto verzii Androidu potrebuje:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Ak stavový riadok ukazuje pripojenú sieť, zatiaľ čo aplikácia vidí neznámy názov, máte problém s povolením alebo na úrovni API, nie problém s Wi-Fi. Opravte to skôr, než sa dotknete pravidiel firewallu, pretože každé ďalšie pravidlo sa vyhodnocuje voči hodnote, ktorú aplikácia nedokáže prečítať.
Kde filtrovanie skutočne beží
Miestny Android firewall zvyčajne používa model VpnService bez odosielania prevádzky na vzdialený server: vezme virtuálne rozhranie, použije vlastné pravidlá a odovzdá to, čo povolí. Platforma dovoľuje jednu aktívnu službu VPN na používateľský profil a druhá nahradí prvú namiesto toho, aby sa na ňu vrstvila. Samostatná aplikácia firewallu a samostatná pracovná VPN preto netvoria dvojstupňovú reťaz; jedna z nich vyhrá.
To je pre pravidlo podľa SSID podstatné, pretože miesto vynucovania a miesto pozorovania sú rôzne komponenty. VpnService rozhoduje, čo opustí zariadenie; Wi-Fi API iba dodáva označenie. Aplikácia môže vynucovať správne a klasifikovať nesprávne, a to je presne porucha v tomto článku.
Dajte neznámemu vlastnú politiku
Berte identitu siete ako tri stavy a zapíšte politiku pre každý z nich pred vydaním pravidla. Tretí stav je ten, na ktorý sa zabúda, a práve doň vás dostane útočník alebo chybná konfigurácia.
| 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 |
Zlyhať zavreté znamená, že neznámy stav zdedí najprísnejšiu rozumnú politiku, nie tú najpohodlnejšiu. Ak to spôsobí, že telefón je v novej sieti nepoužiteľný, správnym riešením je úmyselná a viditeľná výnimka, nie tiché rozhodnutie o dôvere ukryté v kontrole prázdnej hodnoty.
Známa SSID je označenie, nie dôkaz prevádzkovateľa siete. Ktokoľvek môže spustiť prístupový bod s názvom firmy, takže zhoda názvu by nikdy nemala byť jediná vec medzi citlivou reláciou a nedôveryhodným segmentom.
Testujte prechody, nie ustálený stav
Testovanie ustáleného stavu prejde v sieti, kde ste pravidlo postavili. Poruchy žijú v prechodoch: odmietnuté povolenie, Wi-Fi na mobilnú sieť, jedna SSID na druhú, reštartovaná služba VPN a iná aplikácia VPN, ktorá prevezme rozhranie. Pri každom rozhodnite, či sa existujúce spojenia prehodnotia a či chránená prevádzka zostane zablokovaná, kým je stav neznámy.
Výsledok zapíšte v troch vetách: pozorovaná podmienka, komponent, ktorý rozhodnutie vynucuje, a úmyselný záložný postup. Ak niektorá z troch chýba, pravidlo ešte nie je politika; je to odhad, ktorý na firemnej sieti náhodou funguje.