SSID-põhine tulemüürireegel lõpetas Wi-Fi vahetamise järel filtreerimise
SSID-le toetuv tulemüür avaneb, kui Android tagastab tundmatu võrgu nime. Eraldage identiteet jõustamisest ja andke tundmatule oma poliitika.
Reegel oli lihtne: filtreeri liiklust ainult siis, kui telefon on kontori Wi-Fi-ga ühendatud. See pidas kuude kaupa, ja siis ühel hommikul seisis telefon sama SSID peal sama võtmeikooniga ning filtreerimine oli lakanud. Võrgus polnud midagi muutunud; muutunud oli see, kas rakendus näeb võrgu nime. Androidis on «millises Wi-Fi-s ma olen» ja «blokeeri see liiklus» kaks eraldi tööd ning tulemüür, mis need segi ajab, avaneb täpselt siis, kui nimi pole kättesaadav.
Sümptom: identiteet kaob ja poliitika järgneb
SSID-reegel loeb väärtust ja valib seejärel haru. Kui lugemine ei tagasta midagi kasulikku, peab kood midagi tegema, ja tavaline vaikeväärtus on «pole oodatud võrk, seega ära filtreeri». See vaikeväärtus muudab loaprobleemi liikluslekkeks. Võtmeikoon jääb nähtavaks, sest VPN-teenus töötab endiselt; see lihtsalt jõustab teist haru.
Vaadake sündmuste järjekorda, mitte võrku. Tagasilükatud loaküsimus, süsteemiuuendus, mis viis SSID-le juurdepääsu teise loa taha, väljalülitatud asukohateenused või tööprofiili poliitika muutus võivad kõik anda sama tulemuse, samal ajal kui telefon jääb samasse juurdepääsupunkti.
Miks võib nimi tulla tagasi tundmatuna
WifiInfo.getSSID() tagastab praeguse võrgu teenusekomplekti identifikaatori ja Android dokumenteerib, et juurdepääs asukoha suhtes tundlikele väljadele sõltub loast. Kui juurdepääs pole saadaval, tagastab kutse UNKNOWN_SSID, selle asemel et valjult ebaõnnestuda. Tühi või tundmatu väärtus ei ole seega tõestus, et telefon lahkus Wi-Fi-st; see on tõestus, et rakendus ei suuda võrku liigitada.
Kaks kontrolli eristavad juhtumeid. Kinnitage, et telefon on ühendatud, ja vaadake, mida süsteem teatab, seejärel kinnitage, et rakendusel on tõesti luba, mida ta selles Androidi versioonis vajab:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"Kui olekurida näitab ühendatud võrku, samal ajal kui rakendus näeb tundmatut nime, on teil loa- või API-taseme probleem, mitte Wi-Fi probleem. Parandage see enne tulemüürireeglite puudutamist, sest iga järgnev reegel hinnatakse väärtuse vastu, mida rakendus lugeda ei saa.
Kus filtreerimine tegelikult töötab
Kohalik Androidi tulemüür kasutab tavaliselt VpnService’i mudelit, saatmata liiklust kaugserverisse: see võtab virtuaalse liidese, rakendab oma reegleid ja edastab selle, mida lubab. Platvorm lubab ühte aktiivset VPN-teenust kasutajaprofiili kohta ning teine asendab esimese, selle asemel et selle peale kihistuda. Seega ei moodusta eraldi tulemüürirakendus ja eraldi töö-VPN kaheastmelist ahelat; üks neist võidab.
See on SSID-reegli jaoks oluline, sest jõustamispunkt ja vaatluspunkt on erinevad komponendid. VpnService otsustab, mis seadmest lahkub; Wi-Fi API annab ainult sildi. Rakendus võib jõustada õigesti ja liigitada valesti ning täpselt see on selle artikli rike.
Andke tundmatule oma poliitika
Käsitlege võrgu identiteeti kolme olekuna ja kirjutage igaühe poliitika üles enne reegli väljastamist. Kolmas olek on see, mis ununeb, ja just sellesse paneb teid ründaja või vale konfiguratsioon.
| 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 |
Kinniselt ebaõnnestumine tähendab, et tundmatu olek pärib kõige rangema mõistliku poliitika, mitte kõige mugavama. Kui see muudab telefoni uues võrgus kasutuskõlbmatuks, on õige lahendus tahtlik ja nähtav erand, mitte tühja väärtuse kontrolli peidetud vaikne usaldusotsus.
Tutt SSID on silt, mitte tõestus võrguoperaatorist. Igaüks võib käivitada juurdepääsupunkti kontori nimega, seega ei tohiks nimekattuvus kunagi olla ainus asi tundliku sessiooni ja ebausaldusväärse segmendi vahel.
Testige üleminekuid, mitte püsiolekut
Püsioleku testid läbivad võrgus, kus te reegli ehitasite. Riisted elavad üleminekutes: keeldutud luba, Wi-Fi-lt mobiilivõrku, ühelt SSID-lt teisele, VPN-teenuse taaskäivitamine ja teine VPN-rakendus, mis liidese üle võtab. Igaühe puhul otsustage, kas olemasolevad ühendused vaadatakse uuesti läbi ja kas kaitstud liiklus jääb blokeerituks, kuni olek on tundmatu.
Kirjutage tulemus kolme lausena: täheldatud tingimus, otsust jõustav komponent ja tahtlik varulahendus. Kui üks kolmest puudub, pole reegel veel poliitika; see on oletus, mis kontori võrgus juhuslikult töötab.