Názory k článku Útok AirSnitch dovoluje překonat izolaci klientů na Wi-Fi a ovlivňovat provoz

Ten článek je velké zklamání. Přečíst zprávičku a udělat si vlastní ai výcuc bylo rychlejší, než číst tohle přitom informační hodnota stejná.

Tak síť pro hosty by vždy měla být separátní VLAN. To řešení, že síť pro hosty je součástí té jediné LAN co zařízení umí vytvořit je prostě hloupé. Nechápu proč to výrobci dělají.

A protože my paranoici máme těžký život, tak u nás je síť pro hosty řešena separátním AP, které se zapne do zásuvky pouze tehdy, je-li potřeba. Odfiltrovat provoz je potom velmi snadné.

odfiltrovat provoz je také velmi snadné, když tu máš v extra vlan. Tvoje řešení vlastně nepřináší nic navíc, jen si tam děláš další potenciální problém, pokud jsi tu síť nepoužil velmi dlouho, AP nemusí být aktualizovaný nebo při změnách na síti na něj zapomeneš.

Spravovat vypnutý aktivní prvek je těžké. Nemám rád, když v sítí se mohou objevovat takovéhle zombie zařízení, které mají přístup do sítě (případně nějaká pernamentní pravidla) a přitom jsou někde fyzicky dostupné, může je někdo modifikovat, odnést či něco s nimi dělat (nebo to máš někde pod zámkem?).

RE: "Tvoje řešení vlastně nepřináší nic navíc".

Mícháte svůj pohled na věc a use case někoho jiného a aniž byste o tom věděl dost, tak vynášíte rozhodné soudy.

Taky mám v jedné učebně takové APčko, které se zapíná na 2 hodiny týdně a provoz běží VLANou ven. Záměrně tam nejsou připojení uživatelé izolováni od sebe. Dokonce tam není ani heslo. A má to svůj smysl a pro daný účel je to nejlepší řešení, které se mi tam podařilo vymyslet.

Reálný život přináší "barvitější" situace, než které jde nacpat do černobílé poučky.

Izolace Wi-Fi klientů mi vždy přišla jako trochu zvláštní funkce. Když ji zapnu na jednom AP, tak to v rámci tohoto konkrétního zařízení funguje. Klienti připojení k danému AP spolu nemohou komunikovat.

V síti s více AP už je to ale složitější. Druhé AP samo o sobě nepozná, jestli provoz přichází od Wi-Fi klienta přes jiné AP, nebo z běžné kabelové části sítě. Na úrovni samotného AP tedy nejde zajistit úplnou izolaci klientů napříč celou infrastrukturou.

Často se jako řešení zmiňuje VLAN. Samostatná VLAN pro hosty ale problém neřeší, protože všichni hosté jsou pořád ve stejné vrstvě 2 a mohou spolu komunikovat. Izolace na úrovni VLAN by fungovala jedině tehdy, pokud by měl každý klient vlastní VLAN. To je technicky možné, ale znamená to dynamické přidělování VLAN podle uživatele a tomu musí odpovídat celá síťová infrastruktura.

Takže jednoduché zapnutí „client isolation“ na jednotlivých AP řeší jen komunikaci klientů připojených ke stejnému AP. Pokud má být izolace skutečně plošná a zároveň má fungovat roaming, musí to být řešeno centrálně na úrovni celé sítě, ne jen lokální funkcí v přístupovém bodu.

"To je technicky možné"

Ani ne, mozna v malinkaty infrastrukture, ale ono tech vlanu neni jaksi zas tak moc (4k) abys je moh pridelovat per klient.

Jako bonus si pri nejakym vetsim poctu vlanu (rekneme stovky) muzes pekne nabehnout i co se tyce vykonu.

Musí být řešeno obojí. Např. HPE Aruba má kromě "client isolation" ještě další nastavení "block intra-VLAN traffic". Z toho pak jde nastavit výjimky na MAC a/nebo IP adresy. Default je povolen provoz pouze na gateway -- a teď je právě otázka jestli jen podle IP nebo MAC.

Co článek zdá se vůbec neřeší, je další úroveň problémů která přijde v kombinaci s IPv6, hlavně SLAAC + Privacy Extensions. V tu chvíli může mít každý klient shora neomezený počet IPv6 adres, které si sám vytváří. Pak jsou některé ty rady z článku trochu k ničemu... Pro IPv4 je obvykle k dispozici nějaká analogie DHCP/IP-source-guard, která svazuje MAC a IP přidělenou z DHCP a řeší tak značnou část v článku popsaných problémů.

Konkrétně u HPE Aruba zrovna ta funkce "block intra-VLAN traffic" rozbíjí IPv6 Router Solicitation (RS), takže je v praxi nepoužitelná.

Pokud AP nemá funkci "block intra-VLAN traffic" nebo je takto rozbítá, lze to řešit použitím PVLAN na switchích mezi jednotlivými AP.

Podpora IPv6 first-hop security je i u enterprise WiFi řešení stále obvykle špatná. Potom je izolace klientů jediná možnost jak např. zajistit, aby klienti nemohli do sítě posílat rogue RA.

Co jsem slyšel, tak to co popisujete s IPv6 je důvod, proč IPv6 nepodporují žádné veřejné WiFi hotspoty například ve vlacích. Udělat captive portál s IPv6 je prý prakticky nemožné.

Zrovna Captive portal technicky až takový problém není. Musí ale fungovat čistě na bázi MAC adres, a tím pádem na prvním routeru nejblíže klientům. Různá řešení původně vyvinutá pouze pro IPv4 to tak mít nemusí. Pro vendory to zjevně není prioritní řešit. Z pohledu zákazníka je v případě výběru technologie problém jak tyto požadavky zformulovat a ověřit - z datasheetů a dokumentace nelze vycházet, nelze se opřít o konkrétní RFC a i při nějaké podpoře není zarušena funkce v kombinaci s jinými funkcemi...

Trochu problém je s různými způsoby randomizace MAC adres na straně WiFi klientů. Pokud to dělají moc agresivně, při každém připojení, je problém udržet identifikaci klienta. Ale to platí i bez IPv6.

IPv6 evangelisté by pro jeho větší rozšíření nejlépe udělali, kdyby vznikly nějaké "true IPv6 support" checklisty, testovací postupy a katalogy ověřených zařízení pro typické use cases. Na což by pak např. mohli odkazovat zadavatelé z řad veřejných institucí. Napsat do požadavků "plná podpora IPv6", a pak se nad konfigurací dodané technologie dohadovat co to znamená, nebo že podpora nějaká je, ale je děravá 10 let známým způsobem... to není dobrá cesta ani pro jednu stranu.

A je opravdu potřeba od sebe izolovat jednotlivé klienty? Důležité je hlavně oddělit nedůvěryhodné návštěvníky od míst, kde by mohli napáchat nějaké škody.
A ve chvíli, kdy se na to člověk podívá takhle, tak je z toho složitější problém. Protože najednou je třeba ty klienty nějak rozdělit a určit co můžou a co už ne.

"hlavně oddělit nedůvěryhodné návštěvníky od míst, kde by mohli napáchat nějaké škody."

To ale samo o sobě nestačí. Zkuste si představit hotel a jeho veřejnou Wi-Fi. To, že se host nedostane do účetnictví, je jedna věc, samozřejmá, doufám. Druhá věc je ale ochrana hostů mezi sebou.

Představte si, co to udělá s vaší pověstí, když tam někdo, klidně i nevědomky, připojí zavirovaný nebo botnetem napadený počítač či mobil a ohrozí ostatní hosty. Nikoho nebude zajímat, že za to hotel technicky nemůže.

Hotel je jen příklad. Totéž platí pro všechny veřejné Wi-Fi sítě.

Resis "problem", kterej neexistuje. Zkus si predstavi ze nekdo pripoji zavirovanej pocitac k internetu ....

Jo aha, takovych jsou miliardy.

Jeste lepsi jsou verejny (pripadne hotelovy) usb porty ...

Pokud poskytuju verejnou wifi, nezapinam na ni ani zadny sifrovani, proc jako? Je to proste public prostor, a ty se bud pripojis nebo nepripojis, to je ciste tvoje vec, stejne jako reseni zabezpeceni tvyho auta. Taky ti nikdo na parkovisti nestavi extra plot kolem tvyho milaska.

> Resis "problem", kterej neexistuje.
To, ze to ty tak vidis, neznamena, ze je to pravda.

> Zkus si predstavi ze nekdo pripoji zavirovanej pocitac k internetu .... Jo aha, takovych jsou miliardy.
Preto velka vacsina nie je pripojena napriamo, ale cez firewally, proxy atd.

> Jeste lepsi jsou verejny (pripadne hotelovy) usb porty ...
Ano. Ak potrebujem USB port tak pouzijem len hlupy nabijaci kabel, alebo pohladam zasuvku a do nej dam vlastny USB zdroj.

> Pokud poskytuju verejnou wifi, nezapinam na ni ani zadny sifrovani, proc jako? Je to proste public prostor, a ty se bud pripojis nebo nepripojis,...
Nechapes situaciu; ak hotel poskytuje wifi, tak ju poskytuje pre hosti ktorym ponuka pripojenie VON, nie pripojenie medzi sebou navzajom. A v pripade spominaneho hacku je to minimalne reputacne riziko pre hotel, bez ohladu na to ako by si sa ty zariadil. Tak ako v hoteli nemas zamky dveri za volitelny priplatok ale standard, takisto mas mat standardne zabezpecenie.

> to je ciste tvoje vec, stejne jako reseni zabezpeceni tvyho auta. Taky ti nikdo na parkovisti nestavi extra plot kolem tvyho milaska.
Ale ty si predsa tiez vyberas, kde parkujes - ci na zabezpecenom osvetlenom parkovisku alebo niekde medzi 20 vrakmi.

V podstatě tedy budeme čekat na definování a zavedení standardu, které se přes noc nestihne. V mezidobí různými způsoby „lepit a přelepovat“ a doufat. Tam, kde to bude jen trochu možné, přijde ke slovu striktní omezení, vyhrazená AP, … a veřejná místa (hotely, nemocnice, …) to zkrátka budou muset nějak „doklepat“.

Ať na tím přemýšlím jak chci, žádné definitivní univerzální a elegantní řešení mne nepadá, vždy najdu „co když“.

Co může být řešení části problémů, a článek se tím vůbec nezabývá, je tunelování provozu od všech klientů na centrální controller, kde se uplatňují security policy. Enterprise WiFi systémy lze obvykle v tomto režimu provozovat.

Pokud je tohle dobře implementované, tak z popsaných problémů zbývá správné zacházení s GTK. Což jsme se z článku nedozvěděli v čem přesně spočívá, a jestli a v jakých případech to jde na straně AP nějak řešit.

To bylo to první, co mě napadlo, přičemž hned jsem začal přemýšlet nad zátěží, výkonu a dimenzování HW (rezervou) a vůbec každou komplikací, která mi prolétla hlavou ("co když"). U Omnie strach nemám, obávám spíš o Zyxel (Nebula).

Pravda, napsal jsem to s hodně velkou nadsázkou, protože z článku jsem toho moc nedozvěděl a hledat podrobné informace k pochopení problému chce čas.

Rozumím tomu dobře, že pokud mám router a guest WiFi nemá sice svoji vlan, ale má svůj interface a na fw je oddělená od zbytku sítě, tak hrozí jen “hacknuti” client isolation a případně problémy budou jen mezi klienty guest wifi? Nebo klienti z guest WiFi můžou ohrozit i klienty v lan?

Predevsim izolace klientu nikdy nebyla o jakymkoli zabezpeceni, je to ciste o redukci typicky zcela zbytecnyho provozu. Oni totiz ty stanice dokazou tu wifinu i v relativne malym mnoztvi celkem zahltit vsemoznejma broadcastama a automatickym hledanim vseho moznyho i nemoznyho (zravim soudruhy v MS).

Hmm v článku čtu jako jedno z řešení "odpojení klientů, jejichž MAC adresa se objevuje na více BSSID" - nebude to mít dost veliký DoS potenciál?