SSID-brandmuurreël het ná ’n Wi-Fi-oorskakeling opgehou filter

Die reël was eenvoudig: filter verkeer net terwyl die telefoon aan die kantoor se Wi-Fi gekoppel is. Dit het maande lank gehou, en toe, een oggend, het die selfoon op dieselfde SSID met dieselfde sleutelikoon gesit en die filtering het opgehou. Niks aan die netwerk het verander nie; wat verander het, was of die app die netwerk se naam kon sien. Op Android is “aan watter Wi-Fi is ek” en “blokkeer hierdie verkeer” twee afsonderlike take, en ’n brandmuur wat hulle vermeng, faal oop presies wanneer die naam onbeskikbaar word.

Die simptoom: identiteit verdwyn, beleid volg

’n SSID-reël lees ’n waarde en kies dan ’n tak. Wanneer die lesing niks bruikbaars teruggee, moet die kode iets doen, en die algemene verstek is “nie die verwagte netwerk nie, dus filter nie”. Daardie verstek verander ’n toestemmingsprobleem in ’n verkeerslek. Die sleutelikoon bly sigbaar omdat die VPN-diens steeds loop; dit handhaaf net ’n ander tak.

Kyk na die volgorde van gebeure eerder as na die netwerk. ’n Toestemmingsversoek wat afgekeur is, ’n stelselopdatering wat SSID-toegang agter ’n ander toestemming geskuif het, liggingsdienste wat afgeskakel is, of ’n verandering in die werkprofiel se beleid kan almal dieselfde resultaat lewer terwyl die selfoon by dieselfde toegangspunt bly.

Waarom die naam onbekend kan terugkom

WifiInfo.getSSID() gee die diensstel-identifiseerder van die huidige netwerk terug, en Android dokumenteer dat toegang tot ligginggevoelige velde van toestemming afhang. Wanneer toegang onbeskikbaar is, gee die oproep UNKNOWN_SSID terug in plaas daarvan om hard te faal. ’n Leë of onbekende waarde is dus nie bewys dat die selfoon Wi-Fi verlaat het nie; dit is bewys dat die app die netwerk nie kan klassifiseer nie.

Twee kontroles skei die gevalle. Bevestig dat die selfoon geassosieer is en sien wat die stelsel rapporteer, en bevestig dan dat die app werklik die toestemming het wat dit op hierdie Android-weergawe nodig het:

adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"

As die statuslyn ’n gekoppelde netwerk wys terwyl die app ’n onbekende naam sien, het jy ’n toestemmings- of API-vlakprobleem, nie ’n Wi-Fi-probleem nie. Maak dit reg voordat jy aan die brandmuurreëls raak, want elke reël stroomaf word teen ’n waarde geëvalueer wat die app nie kan lees nie.

Waar die filtering werklik loop

’n Plaaslike Android-brandmuur gebruik gewoonlik die VpnService-model sonder om verkeer na ’n afgeleë bediener te stuur: dit neem die virtuele koppelvlak, pas sy eie reëls toe en stuur aan wat dit toelaat. Die platform laat een aktiewe VPN-diens per gebruikersprofiel toe, en ’n tweede een vervang die eerste eerder as om daarby te stapel. ’n Aparte brandmuur-app en ’n aparte werk-VPN vorm dus nie ’n tweestap-ketting nie; een van hulle wen.

Dit maak saak vir ’n SSID-reël omdat die handhawingspunt en die waarnemingspunt verskillende komponente is. Die VpnService besluit wat die toestel verlaat; die Wi-Fi-API lewer net ’n etiket. ’n App kan korrek handhaaf en verkeerd klassifiseer, en dit is presies die faling in hierdie artikel.

Gee aan die onbekende geval sy eie beleid

Behandel die netwerkidentiteit as drie toestande, en skryf die beleid vir elkeen neer voordat jy die reël lewer. Die derde toestand is die een wat vergeet word, en dit is die een waarin ’n aanvaller of ’n foutkonfigurasie jou sal plaas.

Faal toe beteken die onbekende toestand erf die strengste sinvolle beleid eerder as die gerieflikste een. As dit die selfoon onbruikbaar maak op ’n nuwe netwerk, is die regte oplossing ’n doelbewuste, sigbare uitsondering, nie ’n stille vertrouensbesluit wat in ’n nul-kontrole weggesteek is nie.

’n Bekende SSID is ’n etiket, nie bewys van die netwerkoperateur nie. Enigiemand kan ’n toegangspunt met die kantoor se naam bedryf, so ’n naam-ooreenkoms moet nooit die enigste ding wees wat tussen ’n sensitiewe sessie en ’n onvertroude segment staan nie.

Toets die oorgange, nie die bestendige toestand nie

Bestendige-toestand-toetsing slaag op die netwerk waar jy die reël gebou het. Die falings lê in oorgange: toestemming geweier, Wi-Fi na sellulêr, een SSID na ’n ander, die VPN-diens herbegin, en ’n ander VPN-app wat die koppelvlak oorneem. Besluit vir elkeen of bestaande verbindings heroorweeg word en of beskermde verkeer geblokkeer bly terwyl die toestand onbekend is.

Skryf die resultaat as drie sinne: die waargenome toestand, die komponent wat die besluit handhaaf, en die doelbewuste terugval. As enige van die drie ontbreek, is die reël nog nie ’n beleid nie; dit is ’n vermoede wat toevallig op die kantoor se netwerk werk.