Střípky z IT - (10) : Mikrotik : Uhádnete, kde byl problém?

11.7.2024 15:32 | Přečteno: 1404× | linux | poslední úprava: 11.7.2024 20:43

A jdeme do dalšího kola. Tentokrát se podíváme na problém u guest wifi sítě.

Mikrotik a DHCP Leases 00:00:00:00:00:00

Inu, guest wifi ve firmě, která je pro návštěvy a reálně zná heslo každý a běžně má na sobě 140 klientů, začala vykazovat problémy. S notebooky problém nebyl, někdo se občas nemohl připojit a někomu se občas nenačetla stránka v telefonu.

Pro centrální správu wifi se používá CAPsMAN, koukl jsem do nastavení, logů apod. a docházelo k útoku na dhcp server. Během minuty, dvou, se vytvořilo třeba 10 rezervací se statusem declined a u MAC adresy byly vidět jen samé nuly, tj. 00:00:00:00:00:00. Dokonce se začaly objevovat i kolize. Po bližším zkoumání to nedělalo jedno zařízení, ale náhodně různá zařízení (ntb s Win, Android, Apple apod.), žádná pravidelnost. Jak to vypadalo viz:

Ta náhodná zařízení nebyla připojena přes jedno AP, ale chodily z více AP napříč více budovami.

Kde je problém?

Problém je dávno vyřešen, jedná se jen o kvíz. Až to někdo uhádne, přidám k zápisku řešení.

Řešení

Googlil jsem a našel jsem na MK foru tipy, že by to mohlo být Wifi Extenderem. Začal jsem pátrat v logách DHCP serveru, v Leasech apod. a našel jsem tam něco s názvem "TL-WA854RE". Adresa měla odezvu, ale ta samá MAC nebyla u registrovaných wifi klientů, takže to muselo mít pro klientskou část jinou MAC.

Následoval tedy sniff adresy, která byla přiřazena tomu extenderu. Ten sniff pak ukázal, přes jakou wifi a je zařízení připojeno a jakou má reálně MAC adresu klientská část:

Blok byl tedy jednoduchý, ale my jsme chtěli najít i původce, takže Wifi Analyzer v telefonu a šupky dupky do míst, kde by se to mohlo nacházet a našli jsme včetně pachatele.

Zdar Max

Předchozí kvízy
Střípky z IT - (1) : Uhádnete, kde byl problém?
Střípky z IT - (2) : DHCP : Uhádnete, kde byl problém?
Střípky z IT - (3) : NFS : Uhádnete, kde byl problém?
Střípky z IT - (4) : MX-ONE : Uhádnete, kde byl problém?
Střípky z IT - (5) : CentOS7 : Uhádnete, kde byl problém?
Střípky z IT - (6) : ext4 : Uhádnete, kde byl problém?
Střípky z IT - (7) : IP na L3 : Uhádnete, kde byl problém?
Střípky z IT - (8) : Systemd : Uhádnete, kde byl problém?
Střípky z IT - (9) : Nagios : Uhádnete, kde byl problém?
       

Komentáře

[tip]

smycka na l2. neco podobnyho mi na guest wifi udelali sousedi s nejakym tplink repeaterem

[Max]

Je to tak, ten dhcp flood attack dělal wifi extender. Konkrétně TL-WA854RE.
Dohledal jsem ho přes mgmt Mikrotiku, horší bylo indentifikovat v té kopici MAC adres ten extender. Nakonec jsem ho našel sniffem / logováním provozu. Takže jsem věděl zhruba mezi kterými AP skáče, s kolegou jsme pak našli konkrétní polohu pomocí wifi scanneru v telefonu.
Zdar Max

[Max]

Jinak těžko říci, zda by to RSTP zastavilo, možná ano. Každopádně na této konkrétní wifi nasazeno nebylo, bo centrální správa se zakončením interfaců přímo na capsmanu a chtěl jsem ušetřit ms na přepojování klientů mezi AP.
Zdar Max

[MP]

Takze nacerno pripojeny extender?

[Peter Golis]

Ste politicky nekorektný, skúste to preformulovať.

[RealJ]

Propojeni ale slovak?

[Max]

Je to tak. U free wifi to je celkem neřešitelné, protože prostě extender je jak další klient. U firemní, kde se mi uživatelé ověřují přes EAP, je to v cajku. Jako, ještě by ten extender šel asi detekovat nějakou technikou na detekci Rogue AP, ale Mikrotik toto nemá implementováno, takže asi jedině externí sonda na wifi, resp. více sond, což je dost na nic. Další možnost je napsat nějakou sadu přímo pro Mikrotik, ale tam je problém, že když dělá background scan, tak se mu zhorší kvalita wifi. I když, dlouho jsem to už nezkoušel, možná je to už lepší.
Zdar Max

[🇹🇬]

U free wifi to je celkem neřešitelné, protože prostě extender je jak další klient

co tam udělat nějakej FUP jako třeba omezení rychlosti připojení pro jednotlivý klienty?? :O :O nešlo by rouge AP sice zabránit ale nemohla by se stát ňákou moc velkou zátěží :O :O

[Max]

Tak omezení šířky AP nastaveno je. Ono nejde o to, že by někdo něco mohl vyhulit, ale jde o nějaké ty zákeřnosti jako právě extendery apod.
Každopádně Rogue AP chce člověk řešit třeba i u firemní wifi, protože z Rogue AP lze na síť/klienty útočit z venkovních prostor a může tak činit kdokoli procházející v dostatečné vzdálenosti na to, aby se klient chytnul (a pokusit se chytnout může i klient na AP, které má horší signál, prostě roaming a další věci nejsou 100% u každého zařízení).
Zdar Max

[Vantomas]

Bohužel s PSK se MITM vyhnout nedá. Detekce rogue AP sice někde něco rozbliká a rozsvítí v monitoringu, že se to děje, ale jinak nevyřeší nic. Pokud je to navíc nějaký cílený útok, může si útočník odposlechnout MAC adresu na druhé straně areálu a tuhle pak fejkovat u kanceláří a detekce rogue ap ani nic neodhalí, protože je ta MAC přeci vlastní.

Proti MITM je jedině funkční WPA+Radius, kde se rozšiřuje to, co musí útočník znát a získat k tomu přístup, až do takového stavu, že když to útočník zná, je pak rogue ap na parkovišti ten nejmenší problém.

[Max]

To vím, pro firemní wifi jedu eap, ale člověk chce vědět, zda se někdo o něco nepokouší. Na druhou stranu pravda, že mac i další věci jdou okopírovat a detekce tak může být složitější.
Zdar Max

[🇹🇬]

předpokládám že šlo o nějakýho obyčejnýho parazita kterej se na firemní wifi chtěl zdarma přiživit

skutečnej utočnik by takovou věc asi nenechávál běžet zbytečně dlouho nebo by si vlez na kopec a schoval se za dubem se směrovou anétnou nějakou třeba ale hlavně by se nenechal takle děsně snadno chytit :D

[Vantomas]

Všiml jsem si pozdě, ale jasný repeater, navíc podle vysokého počtu dalších zařízení opepřen o to, že repeatovanou síť vysílá pod stejným SSID.

Wifi 802.11 jako takový neumí nativně bridge a pro každého wifi klienta umí jen jednu MAC adresu. Pokud wifi klient chce dělat bridge, nejde pak o skutečný L2 bridge, ale obchází se to přes různá ARP proxy a jiný divočiny. Na základě toho pak různý AP vendoři začali hlídat zda sedí MAC adresa v DHCP requestu proti MAC z wifi vrstvy a tak výrobci repeaterů museli přitvrdit a začít sahat i do DHCP requestů a pak když se to celé poblázní, tak z toho lezou nesmysly.

V ARP tabulce bys ještě viděl všechny IP adresy za tím repeaterem se stejnou MAC adresou a ta by byla shodná s MAC adresou toho TP-Linku na wifi části. Tenhle konkrétní problém se dá trochu "vyřešit" tím, když se v DHCP serveru zaškrtne "Add ARP for leases", pak se ke každé přidělené IP adrese udělá statický ARP záznam proti MAC adrese z DHCP požadavku a takový pakety se pak přes takový repeater nepodaří doručit.

[Max]

Zajímavý tip s "Add ARP for leases". Díky, popřemýšlím.
Zdar Max

[X]

+1

[🇹🇬]

a našli jsme včetně pachatele.

asi dost koukal :D ;D

[Max]

A nejlepší ty výmluvy: "To byl omyl, nechtěl jsem, asi to byla chyba..." :D
Zdar Max

[🇹🇬]

:D :D