Acties:
  • +3 Henk 'm!

  • dion_b
  • Registratie: September 2000
  • Laatst online: 16:58

dion_b

Moderator Harde Waren

say Baah

Topicstarter
Een van de technieken waarmee je in de WiFi-wereld meer kan achterhalen dan "hij doet het niet!!!!" te roepen is packet capture. Professionals gebruiken het constant, met mooie hard- en softwaretools om het uit te voeren. Enterprise-grade AP's kunnen het vrijwel allemaal op afstand, en er zijn dongles als airpcap voor laptops beschikbaar die het ook waar geen high-end AP hangt makkelijk te maken. Daar horen softwarepakketten bij als Omnipeek. Als je dagelijks professioneel met WiFi bezig bent kan ik het van harte aanraden.

Helaas hoort er ook een professioneel prijskaartje bij deze oplossingen, je bent zo EUR 1800 kwijt aan de dongle en de meest eenvoudige versie van de software. Voor thuisgebruik is dat veel te duur.

Om het goedkoper te doen kun je twee kanten op:
1) een MacBook gebruiken (liefst de 2014 MacBook Pro) - download Wireshark en je kunt meer doen dan met EUR 1800 aan airpcap/Omnipeek
2) geen MacBook? Of wil je iets dat je ergens achter kunt laten en op afstand kunt beheren? Dan kun je het op een router of AP doen.

Daar zit ik de laatste dagen mee te stoeien en bij wijze van documentatie voor mezelf heb ik een volledige howto geschreven dat mogelijk - na wat fine-tuning door jullie - hier in de FAQ zou kunnen :P

Dus - ter lering ende vermaeck - pak een oude (of als je het over hebt: nieuwe) router erbij en ga klussen :)


Ik ga in de loop van de week trouwens meer uitleg geven over wat je exact kunt zien en hoe specifieke dingen te troubleshooten met packet capture. Work in progress!

Oslik blyat! Oslik!


Acties:
  • +1 Henk 'm!

  • dion_b
  • Registratie: September 2000
  • Laatst online: 16:58

dion_b

Moderator Harde Waren

say Baah

Topicstarter
Howto packet capture via router/AP met LEDE

Om WiFi-problemen fatsoenlijk te troubleshooten op layer 2 moet je packet capture kunnen doen. De WiFi packet headers kunnen je veel vertellen over een specifieke verbinding en over de algemene situatie in de buurt. Maar die te pakken krijgen is een crime. Onder Windows is het alleen met specifieke (dure) hardware (Airpcap) te realiseren, en dan nog heb je een beperkte (max 2x2 MiMo) kijk op de lucht. Onder Linux kan zoals gebruikelijk alles, maar je bent sterk afhankelijk van de mogelijkheden van de drivers van je netwerkadapter, zul je een sloot aan configuratie moeten doen en ook hier zul je dan doorgaans beperkt zijn tot 2x2 MiMo. Alleen met een Mac kun je eenvoudig WiFi packet capture doen, gewoon Wireshark installeren, monitor mode op de WiFi-adapter selecteren en gaan. Bovendien hebben veel MacBook Pro's 3x3 MiMo. Maar als je tot de 95% van mensen behoort die geen recente MacBook Pro heeft en geen budget/zin hebt zo'n ding te kopen is er gelukkig een alternatief: ga capturen op een router of AP die LEDE draait.

Dat heeft drie voordelen:
[list]• je kunt volledig los van je eigen WiFi-verbinding capturen op een dedicated apparaat (wat scheelt, want je kunt niet tegelijk in monitor mode capturen en dezelfde interface gebruiken voor je internetverbinding)
• een losse AP kan 3x3 of zelfs 4x4 MiMo capturen
• de configuratie is een stuk simpeler dan alles muv een Mac

De keuze voor LEDE en niet bijv OpenWRT komt met name door de betere overzichtelijkheid van LEDE, en betere support voor nieuwe apparaten. Alles wat hier staat is ook onder OpenWRT mogelijk, en voor veel practische zaken zijn ze uitwisselbaar. Mocht je een apparaat hebben dat geen LEDE support heeft maar wel OpenWRT dan kun je daar ook prima mee aan de slag gaan.

Ik heb dit op een Netgear R7800 uitgevoerd met LEDE 17.01.4, dus kan zijn dat een aantal zaken
licht verschillen, maar in beginsel zou het niet veel moeten afwijken. Ik heb het vanaf een Windows 7 computer ingericht, maar zowel OS als versie maken voor onderstaand verhaal weinig uit.

Benodigdheden zijn simpel:
[list]• een geschikte router/AP
• een USB-stick (voor opslag captures)
• een bedrade internetverbinding
• een computer die bedraad aangesloten kan worden op de router/AP, voorzien van terminal emulator met SSH support (bijv PuTTY), en van Wireshark


1) Selecteer geschikte hardware.

Om packet capture te doen op LEDE moet het apparaat voldoen aan een aantal eisen:
[list]• het moet een WiFi-interface hebben (duh) met support voor de band, de WiFi-standaard en het aantal gegevensstromen (MiMo) die je wilt capturen.
• het apparaat moet door LEDE ondersteund worden.
vgezien beperkte opslag op vrijwel alle routers heb je een USB-poort nodig om de captures op te slaan.
• de WiFi-chip ervan moet onder Linux monitor mode toestaan.

Geschikte WiFi-specs.
Wat je nodig hebt hangt af van wat je wilt bereiken. Als je alleen maar beacons en andere management/control frames wilt bekijken voldoet een 1x1 gevalletje. Wil je daarentegen alle verkeer bekijken (m.i. zou dit altijd insteek moeten zijn), dan moet je minimaal dat verkeer kunnen vangen. Daarom zou ik aanraden om als het enigszins kan een 3x3 MiMo model te nemen maar in ieder geval 2x2. Als je alleen 2.4GHz nodig hebt is WiFi-n voldoende, wil je ook 5GHz, dan is WiFi-ac een must.

LEDE support
LEDE is een fork van OpenWRT (een beetje zoals Ubuntu een fork is van Debian), voor onze toepassingen kun je ze als gelijkwaardig beschouwen. Beide zijn Linux-based distro's met builds voor embedded devices zoals routers en AP's. In het algemeen is LEDE iets overzichtelijker.
https://lede-project.org/toh/start
Zoek hier je potentiele devices op. Let allereerst op evt revisies. Het komt voor dat apparaten onder de motorkap totaal andere chips en dus ook compatibility hebben bij opeenvolgende revisies! Let ook op dat deze lijst hooguit aangeeft dat LEDE draait, niet dat alles incl WiFi werkt. Klik daarvoor geheel rechts op "View/Edit data". Controleer daar of er niet "LEDE Unsupported: WiFi" staat, al dan niet met een van de frequentiebanden erbij. Zolang dat er niet staat zit je in beginsel goed.

USB poort
Kijk op het apparaat. Zie je een USB poort? Mooi. Als je het apparaat niet voor je hebt, kijk bij de LEDE data, daar staat o.a. het aantal USB ports bij.

WiFi-chip met monitor mode support onder Linux
Dit is een iets ingewikkeldere. Je moet eerst achterhalen welke WiFi-chipset(s) in je apparaat zitten, dan bepalen welke Linux driver daarvoor gebruikt wordt en tenslotte of dat montior mode ondersteunt. Lang verhaal kort maken:
[list]
• Noteer bij de data voor je device bij WLAN Hardware welke chipset(s) erin zit(ten).
• Ga naar Wikipedia: Comparison of open-source wireless drivers en zoek dmv Ctrl-F op de getallen van je chipset (dus bijv "88W8366" voor Marvell TOPDOG 88W8366). Vind je iets, dan zie je geheel links de drivernaam. Vind je niets op getal, zoek dan op vendor ("Qualcomm Atheros"). Vaak zie je dan iets als "Qualcomm Atheros chips with IEEE 802.11ac support". Als je zo'n chip hebt, gaat het om deze driver.
• Lager op dezelfde pagina (Wikipedia: Comparison of open-source wireless drivers zie je per driver de features staan. Staat bij Monitor mode "Yes", dan zit je goed :)

In het algemeen zijn apparaten met Qualcomm Atheros chipsets het best ondersteund. Veel mid-range TP-Link en Netgear devices hebben zo'n chipset. Een paar suggesties voor goed ondersteunde opties:
  • 2.4GHz only 3x3 MiMo: TP-Link TL-WR1043ND (v2 of hoger)
  • WiFi-ac 3x3 MiMo: TP Link Archer C7
  • WiFI-ac 4x4 (MU-)MiMo: TP Link Archer 2600 (max 80MHz kanaalbreedte) of Netgear R7800 (max 160MHz kanaalbreedte)
2) Installeer de alternatieve firmware.

Geschikte apparaat gekozen en klaar om aan de slag te gaan? Sluit om te beginnen de router via de WAN aan op je reguliere (modem)router, en je PC aan de LAN ervan. Steek de USB-stick in een USB poort op het apparaat en zet het aan.

Zie vervolgens de LEDE pagina voor het apparaat of kijk als daar geen installatie-instructies staan naar de OpenWRT device page waar vanaf de LEDE table of hardware waar ze wel altijd staan. Het kan zo simpel zijn als een firmware image downloaden en vanuit de GUI van het apparaat upgrade kiezen en die image selecteren. Dat is het in ieder geval bij bovengenoemde suggesties. Let hier wederom op de juiste revisie. Als je firmware voor een andere revisie probeert te installeren kan het resulteren in een gebrickte en dus niet meer werkend apparaat :o


3) IP configuratie

Als de firmware upgrade geslaagd is heb je LEDE op je device en is het tijd om de basics in te richten. Allereerst wil je het niet als router en/of DHCP server gebruiken in je netwerk.
[list]• Log met je browser in op http://192.168.1.1 met gebruikersnaam root en lege wachtwoordveld. Kies een handige nieuwe wachtwoord en geef die op.
• Ga naar het tab Network en kies daar Interfaces.
• Klik in de Inderface Overview bij LAN op Edit.
• Kies bij Protocol voor DHCP client.
• Zet bij DHCP Server een vinkje bij Ignore interface.
• Klik op Save & Apply
Je zult nu verbinding verliezen met je apparaat. Haal de netwerkkabel naar je router uit de WAN-poort van je apparaat en sluit het op een LAN-poort aan. Ververs daarna het IP-adres van je computer. Voor je kunt verbinden met je apparaat moet je het IP ervan vinden. Kijk in de DHCP-leases van je router, of gebruik nmap om een scan van je LAN te doen. Zodra je het gevonden heb kun je verder.


4) USB configuratie

Voor het gemak wil je dat je USB stick automatisch gemount wordt en dat het daarbij niet steeds een ander naam/locatie krijgt. LEDE werkt net iets anders dan reguliere Linux op dit vlak.

Ga met PuTTY via SSH naar het IP van je apparaat. Log in met username root en het wachtwoord dat je eerder in de GUI gekozen hebt.

In de CLI wil je als eerste een update uitvoeren. Na de tweede commando kun je een kopje thee/koffie gaan drinken, dat duurt even:
code:
1
2
# opkg update
# opkg upgrade

Belangrijk weetje bij LEDE (en OpenWRT): je package list wordt niet weggeschreven op de opslag, dus na reboot is het weg. Als je dus de boel reboot moet je altijd opkg update uitvoeren als je iets wilt installeren.

Dan is het tijd om te achterhalen of USB support aanwezig is (dat verschilt namelijk van build tot build):
code:
1
# dmesg | grep usb

Als je dan meerdere regels krijgt over usbcore en bovenal usb-storage ziet staan zit dit goed. Zo niet moet je het installeren, zie hier.

Nu moeten we de tools installeren om de drive te mounten:
code:
1
# opkg install kmod-usb-storage kmod-fs-ext4 kmod-fs-vfat block-mount dosfstools nano

Vervolgens het systeem rebooten en opnieuw inloggen. Controleer nu of de USB stick goed herkend is als device:
code:
1
# dmesg | grep 'sd '

Dat levert als het goed is een paar regels met als conclusie: Attached SCSI removable disk. Zo niet? Dan is iets hierboven fout gegaan, waarschijnlijk mbt USB-support.

Wel goed? Noteer de devicenaam (waarschijnlijk sda). Ik ga nu verder met sda, als je een andere hebt, structureel waar ik "sda" schrijf jouw naam invullen. Tijd om te formatteren en dan te mounten:
code:
1
2
3
4
# mkfs.fat /dev/sda
# mkdir /mnt/usb
# mount /dev/sda1 /mnt/usb
# touch /mnt/usb/test

Als alles goed gaat heb je nu de USB stick geformatteerd met FAT32, met daarop een leeg bestandje 'test'. Controleer dat met:
code:
1
# ls /mnt/usb

Je ziet als het goed is test staan.

Tijd om dat permanent te maken:
code:
1
2
# block detect > /etc/config/fstab
# /etc/init.d/fstab enable

Helaas maakt block detect er doorgaans een zooitje van. Tijd om eea aan te passen.
code:
1
# /etc/config/fstab

Hier staan twee categorieen, een deel config 'global' en een deel config 'mount'. Die laatste is van belang en moet aangepast worden naar het volgende:
code:
1
2
3
4
5
config 'mount'
        option  target  '/mnt/usb'
        option  device  '/dev/sda1'
        option  fstype  'auto'
        option  enabled '1'

Sla dat op met Ctrl-O en exit dan met Ctrl-X. Als dat gedaan is, reboot het apparaat, log opnieuw in en kijk of het testbestand zichtbaar is:
code:
1
# ls /mnt/usb



5) Installatie programmatuur en configuratie

Dit gedeelte is Work In Progress, maar voor nu houden we het simpel: met airodump-ng kun je snel en gericht packet capture doen. Ideaal is het niet (veel handmatig werk, geen radiotap headers), maar als bovenstaande allemaal gelukt is, is dit doodsimpel.

Eerst installeren:
code:
1
2
# opkg-update
# opkg install aircrack-ng

Dit installeert een zwik aan CLI tools om te rommelen met WiFi-packets. Insteek is penetration testing (ander verhaal), maar de tools kun je ook voor diagnostiek gebruiken.

Vervolgens moet je de netwerkadapter(s) van je device in monitor mode zetten. Dit is het uur van de waarheid voor je apparaatselectie. Als de volgende commando's goed gaan, ben je er klaar voor. Zo niet kan het zijn dat het niet met dit apparaat gaat lukken... Let hierbij op dat dualband AP's twee interfaces hebben, eentje voor de 2.4GHz en eentje voor de 5GHz. Je kunt ze uit elkaar houden door het kanaalnummer. Is dat <=13, dan is het de 2.4GHz adapter, is het >=36, dan is het de 5GHz adapter. In mijn voorbeeld heet de 5GHz-adapter wlan0 en de 2.4GHz-adapter wlan1. Je toont je adapters met de commando iw dev

Dan zie je waarschijnlijk iets als dit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
root@LEDE:~# iw dev
phy#1
        Interface wlan1
                ifindex 7
                wdev 0x100000002
                addr dc:ef:09:xx:xx:x2
                type AP
                channel 9 (2452 MHz), width: 20 MHz (no HT), center1: 2452 MHz
                txpower 0.00 dBm
phy#0
        Interface wlan0
                ifindex 8
                wdev 0x2
                addr dc:ef:09:xx:xx:x1
                type AP
                channel 140 (5700 MHz), width: 20 MHz (no HT), center1: 5700 MHz
                txpower 0.00 dBm

Let hier op de Interfacenaam, en op de bijbehorende channel. Noteer je eigen interfacenamen en meld daarbij welke 2.4GHz is en welke 5GHz. Ze staan nu nog in AP-modus (zie type AP). Dat moet veranderen. Om te testen gaan we de NICs eerst handmatig in monitor mode zetten door een tijdelijke nieuwe interface aan te maken:
code:
1
2
3
4
# iw phy phy0 interface add mon0 type monitor
# ifconfig mon0 up
# iw phy phy1 interface add mon1 type monitor
# ifconfig mon1 up

Als je nu gaat kijken zie je als het goed is twee nieuwe interfaces erbij komen:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
root@LEDE:~# iw dev
phy#1
        Interface mon1
                ifindex 11
                wdev 0x100000003
                addr dc:ef:09:xx:xx:x2
                type monitor
                channel 9 (2452 MHz), width: 20 MHz (no HT), center1: 2452 MHz
                txpower 0.00 dBm
        Interface wlan1
                ifindex 7
                wdev 0x100000002
                addr dc:ef:09:xx:xx:x2
                type AP
                channel 9 (2452 MHz), width: 20 MHz (no HT), center1: 2452 MHz
                txpower 0.00 dBm
phy#0
        Interface mon0
                ifindex 10
                wdev 0x4
                addr dc:ef:09:xx:xx:x1
                type monitor
                channel 140 (5700 MHz), width: 20 MHz (no HT), center1: 5700 MHz
                txpower 0.00 dBm
        Interface wlan0
                ifindex 8
                wdev 0x2
                addr dc:ef:09:xx:xx:x1
                type AP
                channel 140 (5700 MHz), width: 20 MHz (no HT), center1: 5700 MHz
                txpower 0.00 dBmp.

Mon0 en mon1 zijn identiek aan wlan0 en wlan1, met uitzondering van het 'type' veld. Ze zouden nu klaar moeten zijn om packets op te capturen.

Dat gaan we even testen door airodump-ng kort op elk van de interfaces te draaien. De exacte resultaten doen er hier niet toe, zolang je iets vangt is het goed. airodump-ng roep je aan met de commando airodump-ng. Daar gaam we een aantal opties aan mee moeten geven:
[list]• -w (of --write) geeft aan waar de output gedumpt moet worden. /mnt/usb/test is voor nu prima.
• -o (of --output-format) geeft aan hoe de dump opgeslagen moet worden. We willen het in Wireshark bekijken, dus is pcap het aangewezen formaat.
• --beacons vertelt airodump-ng dat hij ook beacons moet registreren. Doorgaans zijn dat de meest interessante pakketten, dus graag!
• --band vertelt airodump-ng in welk WiFi-band hij moet capturen. "a" is 5GHz, "g" is 2.4GHz. Als je een specifieke kanaal instelt (met --channel) hoef je band niet expliciet op te geven. Zonder specifiek kanaal zal de interface tussen kanalen hoppen om maximaal netwerken te vinden. Let wederom op op welk interface je dit doet, een 2.4GHz NIC vragen om in 5GHz te capturen of omgekeerd levert weinig resultaten.
Tenslotte moet je de juiste interface opgeven, hier dus mon0 (5GHz) of mon1 (2.4GHz)

Airodump-ng blijft als het eenmaal draait doorgaan met capturen tot je stop zegt (of je USB drive vol zit :X ). Hier hoeven we maar kort te capturen. Zodra je netwerken in het scherm ziet verschijnen, op Ctrl-c drukken om te stoppen.

Eerst doen we de 2.4GHz, dan 5GHz, dan controleren we of iets opgeslagen is:
code:
1
2
3
# airodump-ng -w /mnt/usb/test -o pcap --beacons --band g mon1
# airodump-ng -w /mnt/usb/test -o pcap --beacons --band a mon0
# ls /mnt/usb

De eerste twee commando's lieten als het goed is vrij snel resultaten zien, en als het goed is zie je nu het volgende:
code:
1
2
3
root@LEDE:~# ls /mnt/usb
test                          test-01.cap
test-02.cap

Zo ja: gefeliciteerd, je hebt iets uit de lucht gecaptured!

Enige wat nog rest om te doen is om de twee interfaces per default in monitor mode in te stellen, zodat je niet iedere keer dat je boot handmatig die netwerken moet aanpassen. Daarvoor moet je /etc/config/wireless onder handen nemen:
code:
1
nano /etc/config/wireless

Exact wat je daar gaat aantreffen hangt af van je apparaat en z'n chips (en trouwens de defaults van de LEDE build die je installeert), maar je zult een paar dingen op orde moeten brengen voor packet capture:
[list]• De country-option moet aanwezig zijn en goed staan. In de VS (vaak default) zijn andere kanalen in gebruik waardoor je onnodig lege kanalen gaat scannen en andere gebruikte kanalen mist. Dit moet dus NL (of EU) zijn.
mode is ook hier centraal. Dat is waarschijnlijk nu "AP" en moet dus "monitor" worden.
• Let op dat de opties channel, hwmode en htmode consequent zijn ingevuld. Dus bij de 5GHz adapter een channel kiezen in de 5GHz (bijv 36), 11a als hwmode en htmode VHT80 (WiFi-ac) of HT40 (WiFi-n). Bij 2.4GHz moeten dat zijn een kanaal in de 2.4GHz (bijv 11), hwmode 11g en htmode HT20.

Waar je vooral niet aan moet rommelen is path, dat is het fysieke adres van de interface in je systeem. Verander dat en je device kan z'n interface niet meer vinden.

Je moet uiteindelijk iets als dit ervan maken:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option country 'NL'
        option hwmode '11a'
        option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'VHT80'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'monitor'
        option ssid 'LEDE'
        option encryption 'none'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '11'
        option country 'NL'
        option hwmode '11g'
        option path 'soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
        option htmode 'HT20'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'monitor'
        option ssid 'LEDE'
        option encryption 'none'

Wederom opslaan met Ctrl-O en dan exitten met Ctrl-X

Vanaf de eerstvolgende reboot zouden de beide interfaces wlan0 en wlan1 per default in monitor mode moeten staan. Tijd om dat te testen:
code:
1
reboot


Als de AP weer in de lucht is (verschilt per device, vaak minder dan een minuut, maar geduld is een schone zaak), weer inloggen via ssh met PuTTY en weer iw dev uitvoeren.

Je zou nu een subtiel verschil moeten zien:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
root@LEDE:~# iw dev
phy#1
        Interface wlan1
                ifindex 7
                wdev 0x100000002
                addr dc:ef:09:xx:xx:x2
                type monitor
                channel 9 (2452 MHz), width: 20 MHz (no HT), center1: 2452 MHz
                txpower 0.00 dBm
phy#0
        Interface wlan0
                ifindex 8
                wdev 0x2
                addr dc:ef:09:xx:xx:x1
                type monitor
                channel 140 (5700 MHz), width: 20 MHz (no HT), center1: 5700 MHz
                txpower 0.00 dBm

Zie die type? Monitor mode is actief en je bent klaar om te capturen op wlan0 en wlan1 :)


6) Gebruik

Ook Work In Progress.

Algemene workflow:
[list]• Log in op je device via ssh met PuTTY.
• Voer de gewenste airodump-ng commando's uit.
• Na afronden dumps kun je ofwel de USB stick fysiek overzetten op je PC vergeet niet om na afloop de USB-stick terug in je device te steken, of je kunt bijv via WinSCP via SCP de bestanden over het netwerk overzetten.
• Open Wireshark op je PC. Ga naar File > Open en selecteer je .cap bestand.
• Bekijk de mooie resultaten van je noeste arbeid.

Even commando's voor de twee simpelste use-cases:

1) je wilt weten welke AP's om je heen te vinden zijn in de beide banden.

2.4GHz:
code:
1
airodump-ng -w /mnt/usb/2G_scan -o pcap --beacons --band g wlan1

Laat dit zeker een minuut draaien.

5GHz:
code:
1
airodump-ng -w /mnt/usb/5G_scan -o pcap --beacons --band a wlan0

Deze minstens twee minuten laten draaien.


2) je hebt problemen met een verbinding op een specifiek kanaal en wilt volgen wat daar allemaal gebeurt.

Bepaal allereerst welk kanaal dat is en kies dan de juiste adapter afhankelijk van de band, waarbij je "X" vervangt met kanaal in kwestie.

2.4GHz:
code:
1
airodump-ng -w /mnt/usb/2G_channel_X_dump -o pcap --beacons --channel X wlan1

of

5GHz:
code:
1
airodump-ng -w /mnt/usb/5G_channel_X_dump -o pcap --beacons --channel X wlan0

Doe vervolgens datgene wat problemen geeft terwijl het draait. Dit kan zo lang of zo kort duren als je nodig hebt.

[ Voor 100% gewijzigd door dion_b op 28-11-2017 07:27 . Reden: Typo bij USB ]

Oslik blyat! Oslik!


Acties:
  • 0 Henk 'm!

  • Borromini
  • Registratie: Januari 2003
  • Niet online

Borromini

Mislukt misantroop

Netjes @dion_b en gaat voor heel wat mensen enorm nuttig zijn. Heb het eerder dit jaar ook moeten doen vanop mijn XPS 13 om verbindingsproblemen na te kijken. Dan komt zo'n Intel-chip ook wel van pas (op Linux).

Schoonheidsfoutje: in de aankoppelinstructies staat /mbt/usb ipv /mnt/usb de eerste keer :)

Ik kijk uit naar het vervolg!

Got Leenucks? | Debian Bookworm x86_64 / ARM | OpenWrt: Empower your router | Blogje


Acties:
  • 0 Henk 'm!

  • dion_b
  • Registratie: September 2000
  • Laatst online: 16:58

dion_b

Moderator Harde Waren

say Baah

Topicstarter
Borromini schreef op dinsdag 28 november 2017 @ 01:19:
Netjes @dion_b en gaat voor heel wat mensen enorm nuttig zijn. Heb het eerder dit jaar ook moeten doen vanop mijn XPS 13 om verbindingsproblemen na te kijken. Dan komt zo'n Intel-chip ook wel van pas (op Linux).
Heb om een of andere reden altijd gedoe gehad met m'n AC7260 die maar niet in monitor mode wilde....

Dat gezegd, voornaamste reden om een standalone capture device te maken is dat het zelf geen deel neemt aan het verkeer, dus ook niets verandert aan de situatie die je wilt onderzoeken.
Schoonheidsfoutje: in de aankoppelinstructies staat /mbt/usb ipv /mnt/usb de eerste keer :)
Ugh, typo idd. En nog in het oudste stuk - toen ik zowaar goed wakker en helder had moeten zijn :')

Tnx, aangepast igg.

Oslik blyat! Oslik!


Acties:
  • 0 Henk 'm!

  • donny007
  • Registratie: Januari 2009
  • Laatst online: 29-04 09:59

donny007

Try the Nether!

Geinig om te zien dat dit ook op een router gedaan kan worden.

Zelf gebruikte ik altijd Kismet (op Kali Linux) om wireless packets te capturen. Kismet heeft een text-based GUI met daarin een real-time overzicht van actieve AP's (en bijbehorende clients):

Afbeeldingslocatie: https://i.imgur.com/ko5F5SHh.png

Als output geeft Kismet een .pcap dump en een tekstbestandje met daarin details van alle gevonden netwerken/clients.

Op Kali Linux is een groot deel van de configuratie/driver/dependency meuk al voor je geregeld, met een geschikte wifi adapter kun je meteen aan de slag.

/dev/null


Acties:
  • 0 Henk 'm!

  • dion_b
  • Registratie: September 2000
  • Laatst online: 16:58

dion_b

Moderator Harde Waren

say Baah

Topicstarter
donny007 schreef op dinsdag 28 november 2017 @ 11:12:
Geinig om te zien dat dit ook op een router gedaan kan worden.

Zelf gebruikte ik altijd Kismet (op Kali Linux) om wireless packets te capturen. Kismet heeft een text-based GUI met daarin een real-time overzicht van actieve AP's (en bijbehorende clients):

[afbeelding]

Als output geeft Kismet een .pcap dump en een tekstbestandje met daarin details van alle gevonden netwerken/clients.
Mijn eerste insteek was inderdaad ook om Kismet te gebruiken, vooral omdat Kismet de mogelijkheid heeft om een 'drone' op een domme device als zo'n router te draaien die output stuurt naar een server op je client PC. Helaas belandde ik daarbij in een moeras van niet compatibele versies tussen OpenWRT/LEDE enerzijds en regulier Linux/MacOS/Windows anderzijds.

Als je toch volledig op de router/AP moet werken is de meerwaarde van Kismet klein/afwezig, terwijl het meer resources vreet en lastigere configuratie heeft dan airodump-ng (dat feitelijk zelf nihil qua configuratie nodig heeft zolang je environment klopt). Daarom dat ik daarvoor gekozen heb.
Op Kali Linux is een groot deel van de configuratie/driver/dependency meuk al voor je geregeld, met een geschikte wifi adapter kun je meteen aan de slag.
Valt mij met m'n AC7260 steeds weer tegen. Enige moderne adapters waar het in mijn ervaring echt out-of-the-box goed mee gaat zijn die van Qualcomm Atheros, en dan nog zit je vast aan 2x2 of max 3x3 MiMo.

Oslik blyat! Oslik!


Acties:
  • 0 Henk 'm!

  • Thralas
  • Registratie: December 2002
  • Laatst online: 09:48
dion_b schreef op dinsdag 28 november 2017 @ 01:03:
Enterprise-grade AP's kunnen het vrijwel allemaal op afstand
MikroTik ook overigens. En dat is alleraardigst geprijsd.

Wel wat beperkt in de zin dat je of één channel, of álle channels captured, een lijst opgeven lijkt niet mogelijk.

Verder heeft het nog wat handige tools aan boord, je kunt met Winbox bijvoorbeeld ook snel channel en frequency utilsation (beperkt) uitlezen.

Afbeeldingslocatie: https://wiki.mikrotik.com/images/8/83/Snoop2.png
2) geen MacBook? Of wil je iets dat je ergens achter kunt laten en op afstand kunt beheren? Dan kun je het op een router of AP doen.
Mijn eerste gedachte was eigenlijk net als @donny007 dat Kali nogi een stukje toegankelijker is. Tenzij je een router hebt liggen waar je zo OpenWRT/LEDE op kunt zetten is dat in de meeste gevallen waarschijnlijk een stuk praktischer en wat meer portable (heikele punt blijft hardware, maar dat is bij OpenWRT hetzelfde).

Nu doe ik verder weinig qua spectrumanalyse, maar ik vraag me wel af wat de meerwaarde van monitor mode in veel gevallen is. Non-WiFi-verkeer zie je er niet mee, en de inhoud is toch versleuteld. Op het moment dat de vraag hoe je zelf je spectrum gebruikt met meerdere APs en een groot aantal clients dan zouden je APs ook fancy genoeg moeten zijn om dat inzichtelijk te maken toch? Misschien is het ook een ander verhaal als je naar een specifieke client wilt kijken (bv. hoe 'ie roamt).

Waar de routers me wel weer extra interssant voor lijken is het feit dat die Atheros chipsets ook rf-energieniveaus kunnen rapporteren, dan kun je dus ook non-802.11-interferentie spotten (in theorie tenminste).

MikroTik heeft dat ook geimplementeerd, maar ik meen me te herinneren dat iemand ook wel eens het eea. voor OpenWRT had gebouwd, misschien ook interessant om naar te kijken.

Afbeeldingslocatie: https://wiki.mikrotik.com/images/3/3b/Spectral-scan-dude.PNG
dion_b schreef op dinsdag 28 november 2017 @ 14:24:
Valt mij met m'n AC7260 steeds weer tegen. Enige moderne adapters waar het in mijn ervaring echt out-of-the-box goed mee gaat zijn die van Qualcomm Atheros, en dan nog zit je vast aan 2x2 of max 3x3 MiMo.
Het is sowieso wel handig om een extra adapter te hebben, anders is het vechten met zaken als NetworkManager en heb je geen internet zolang je monitored...

Acties:
  • +1 Henk 'm!

  • dion_b
  • Registratie: September 2000
  • Laatst online: 16:58

dion_b

Moderator Harde Waren

say Baah

Topicstarter
Thralas schreef op woensdag 29 november 2017 @ 22:36:
[...]


MikroTik ook overigens. En dat is alleraardigst geprijsd.
Niet slecht. Wat ik zo 1-2-3 niet zie: kun je daar de radiotap headers ook mee uitlezen?
Wel wat beperkt in de zin dat je of één channel, of álle channels captured, een lijst opgeven lijkt niet mogelijk.
Een lijst is met airodump-ng wel mogelijk, maar ik zie er niet zo de meerwaarde van in. Ofwel je wilt de hele omgeving observeren (alle channels), danwel wil je een bepaalde verbinding op een bepaald kanaal onderzoeken (enkele dus). "Ik wil alles weten behalve kanaal 6, die boeit me niet" is niet iets dat ik mezelf snel zie zeggen :+
Verder heeft het nog wat handige tools aan boord, je kunt met Winbox bijvoorbeeld ook snel channel en frequency utilsation (beperkt) uitlezen.

[afbeelding]


[...]


Mijn eerste gedachte was eigenlijk net als @donny007 dat Kali nogi een stukje toegankelijker is. Tenzij je een router hebt liggen waar je zo OpenWRT/LEDE op kunt zetten is dat in de meeste gevallen waarschijnlijk een stuk praktischer en wat meer portable (heikele punt blijft hardware, maar dat is bij OpenWRT hetzelfde).
Mijn ervaring met kali op een laptop is dat het nooit zo simpel is. Dat ligt niet aan kali an sich, maar aan lastige WiFi NIC chips/drivers/firmware blobs.

Mbt 'portable' - ja en nee. Laptop is natuurlijk makkelijker om mee te nemen, maar tegelijkertijd is het lastiger om ergens te laten staan. Mijn insteek was bovendien iets te doen wat geen enkele eis stelde aan de laptop (of welke computer dan ook) gebruikt wordt om dit aan te sturen. Dus ook een Windows-gebruiker die geen zin heeft om zich in kali te verdiepen zou het moeten kunnen gebruiken.
Nu doe ik verder weinig qua spectrumanalyse, maar ik vraag me wel af wat de meerwaarde van monitor mode in veel gevallen is. Non-WiFi-verkeer zie je er niet mee, en de inhoud is toch versleuteld. Op het moment dat de vraag hoe je zelf je spectrum gebruikt met meerdere APs en een groot aantal clients dan zouden je APs ook fancy genoeg moeten zijn om dat inzichtelijk te maken toch?
Spectrum analyse = layer 1. Packet analyse = layer 2 (tenzij je de radiotap headers hebt, dan is het alsnog beetje layer 1).

Als je een enorme bult ruis in je spectrum hebt, of een zeer zwak signaal op een locatie waar je wilt verbinden, heeft packet analyse totaal geen meerwaarde. Maar als je goed signaal hebt en toch beroerde performance, wat dan? Of als een apparaat zich niet gedraagt zoals je wilt (kan niet aanmelden, dat soort ongein)? De data in packets zelf is zelden interessant, maar de headers, die (zonder 802.11w) niet versleuteld zijn des te meer. Alles wat je wilt weten over het gedrag van de verbinding kun je uit de headers halen.

Typische dingen die je anders niet ziet:
- stations die RTS/CTS actief hebben, bijvoorbeeld omdat ze wel het AP kunnen detecteren, maar niet andere stations aan de andere kant van AP. Onder die omstandigheden zenden de twee stations door elkaar heen, met collisions toto geval. RTS/CTS lost dat op, maar hierdoor moet elke station eerst tijd aanvragen en wachten op bevesting dat het die ook krijgt, wat funest is voor throughput.
- als een client niet kan aanmelden op een bepaalde AP kan het nuttig zijn om de beacons van het AP te vergelijken met de probe requests van de clients in kwestie. Als daar een mismatch is in de capabilities velden zie je snel genoeg waar het fout gaat.
Waar de routers me wel weer extra interssant voor lijken is het feit dat die Atheros chipsets ook rf-energieniveaus kunnen rapporteren, dan kun je dus ook non-802.11-interferentie spotten (in theorie tenminste).
Meh, dat is waar je een spectrum analyzer voor nodig hebt. Als je die niet hebt kun je inderdaad met die energieniveau's proberen iets te achterhalen, maar het lastige is dat je daar alleen maar een klein deel van potentiele stoorbronnen mee kunt vinden. Een grote bult microgolfoven zie je inderdaad wel, maar pakweg een Marmitek AV-transmitter die FHSS doet mis je volledig (want in elke subcarrier maar zeer kortstondig een signaal, dus weinig energie), en een smalle, hoge piek mis je er ook mee. Plus dat veel van de 'loze' energie eigenlijk komt van regulier WiFi, waar

Ik heb een tijd lang een Fluke Aircheck beoordeeld die op zo'n manier een beeld probeerde te geven van de RF. Ik kan het alleen omschrijven als 'echt waardeloos'. Voor spectrum analyse moet je spectrum analyseren, punt. Die Fluke gaf teveel false positives en leverde eigenlijk geen meerwaarde boven blind handmatig de kanalen afgaan. Nu is zo'n Aircheck ook niet primair bedoeld als spectrum analyzer, dus het is niet eerlijk het daarop af te rekenen, maar aangezien dat wel is wat wij zochten heb ik uiteindelijk geadviseerd om de Metageek Wi-Spy DBx te nemen, wat in totaal niet eens de helft kostte van de Aircheck. Prive vond ik dat alsnog iets te duur (~EUR 500 voor de hw, vergelijkbaar bedrag voor de sw), dus heb ik een RF-Explorer gekocht, wat voor ~EUR 300 hw+sw veruit goedkoopste optie was die ik kon vinden een klein jaartje terug. Maar goed, dat is nog steeds veel meer dan je als 'gewone' WiFi gebruiker zou willen betalen, dus ik begrijp dat je het probeert met de chips die je hebt. Helaas kan ik daar kort in zijn: je schiet er weinig mee op :'(
MikroTik heeft dat ook geimplementeerd, maar ik meen me te herinneren dat iemand ook wel eens het eea. voor OpenWRT had gebouwd, misschien ook interessant om naar te kijken.

[afbeelding]
Als ik ooit een Mikrotik met WiFi in handen heb ga ik er zeker naar kijken, maar dat plaatje lijkt weinig op wat ik in m'n spectrum analyzers zie, dus verwacht er niet teveel van.
[...]

Het is sowieso wel handig om een extra adapter te hebben, anders is het vechten met zaken als NetworkManager en heb je geen internet zolang je monitored...
NetworkManager moet sowieso dood, maar eens, dat is waarom ik een tweede stel WiFi-antennes in m'n laptop gemod heb :+

Oslik blyat! Oslik!


  • Thralas
  • Registratie: December 2002
  • Laatst online: 09:48
dion_b schreef op woensdag 29 november 2017 @ 23:25:
Niet slecht. Wat ik zo 1-2-3 niet zie: kun je daar de radiotap headers ook mee uitlezen?
Ze gebruiken niet radiotap, maar TZSP, maar dat is opzich redelijk vergelijkbaar. Hier een voorbeeld van een beacon (gevolgd door uiteraard de 802.11 headers):

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
TZSP: IEEE 802.11 Good
    Version: 1
    Type: Received packet (0)
    Encapsulation: IEEE 802.11 (18)
    Signal
        Option Tag: Signal (10)
        Option Length: 1
        Signal: -86
    Rate
        Option Tag: Rate (12)
        Option Length: 1
        Rate: 1 Mbit/s (2)
    Frame check sequence
        Option Tag: Frame check sequence (17)
        Option Length: 1
        FCS: Frame is valid
    Channel
        Option Tag: Channel (18)
        Option Length: 1
        Channel: 6 (2.437 GHz) (6)
    Original Length
        Option Tag: Original Length (41)
        Option Length: 2
        Original Length: 260
    End
        Option Tag: End (1)
Ik wil alles weten behalve kanaal 6, die boeit me niet" is niet iets dat ik mezelf snel zie zeggen :+
Goed punt, ik denk dat dat idee voortkomt uit m'n achtergrond qua WiFi capturing: security, niet zo zeer netwerkoptimalisatie.

En de rest overigens ook. Ik geloof dat ik hoewel ik prima weet hoe ik een device in monitor mode krijg, maar je geeft een hoop praktische voorbeelden die ik geheel niet had overwogen d:)b

  • dion_b
  • Registratie: September 2000
  • Laatst online: 16:58

dion_b

Moderator Harde Waren

say Baah

Topicstarter
Thralas schreef op donderdag 30 november 2017 @ 21:56:
[...]


Ze gebruiken niet radiotap, maar TZSP, maar dat is opzich redelijk vergelijkbaar. Hier een voorbeeld van een beacon (gevolgd door uiteraard de 802.11 headers):

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
TZSP: IEEE 802.11 Good
    Version: 1
    Type: Received packet (0)
    Encapsulation: IEEE 802.11 (18)
    Signal
        Option Tag: Signal (10)
        Option Length: 1
        Signal: -86
    Rate
        Option Tag: Rate (12)
        Option Length: 1
        Rate: 1 Mbit/s (2)
    Frame check sequence
        Option Tag: Frame check sequence (17)
        Option Length: 1
        FCS: Frame is valid
    Channel
        Option Tag: Channel (18)
        Option Length: 1
        Channel: 6 (2.437 GHz) (6)
    Original Length
        Option Tag: Original Length (41)
        Option Length: 2
        Original Length: 260
    End
        Option Tag: End (1)
Niet slecht, ik mis tov radiotap alleen de SNR. Gelijk wel een van de interessantere velden, maar je kunt met de rest hier al heel veel, niet in de laatste plaats controleren of je devices wel degelijk de instellingen die je instelt uitvoeren. Het komt nogal eens voor dat bij autonome acties van een WiFi chip (denk aan een DFS of OBSS-event in 5GHz, danwel het schakelen van 20 naar 40MHz in 2.4GHz, of in sommige erg brakke gevallen gewoon een dynamic channel select) de WiFi-chip de SoC niet op de hoogte brengt van de nieuwe situatie. Dan krijg je bijv beacons die vrolijk zeggen dat ze in kanaal A zitten maar alsnog op B uitgezonden worden. Flink wat devices zullen daar niet mee verbinden :o

Ben de laatste tijd veel bezig met uitschakelen van de laagste data rates. Daar ga ik ook nog een howto voor schrijven, het is in OpenWRT/LEDE best simpel en kan heel goede resultaten bieden - als de AP daadwerkelijk doet wat je het vraagt. Wat ik nogal eens tegenkom is dat de beacons vrolijk de gewenste supported rates adverteren, maar zelf nog steeds met de laagste data rate (1Mbps in 2.4GHz, 6Mbps in 5GHz) verstuurd worden. Daarmee zondigt zo'n apparaat tegen 802.11-2016, en verlies je grootste deel van de voordelen van het uitschakelen van die lage rates :X Dat zou je hiermee ook kunnen vangen.
[...]

Goed punt, ik denk dat dat idee voortkomt uit m'n achtergrond qua WiFi capturing: security, niet zo zeer netwerkoptimalisatie.]
Flink andere tak van sport inderdaad. Zo'n Fluke Airchek is voor mij bijna nutteloos, maar het is juist ontworpen voor dat soort toepassing :)
En de rest overigens ook. Ik geloof dat ik hoewel ik prima weet hoe ik een device in monitor mode krijg, maar je geeft een hoop praktische voorbeelden die ik geheel niet had overwogen d:)b
Dat is het mooie van ervaringen zo delen :)

Ik gok trouwens dat het voorbeeld van beacons die met instellingen X zenden terwijl ze eigenlijk zelf Y doen evengoed een teken kan zijn van iemand die zit te kloten met een rogue AP.

Oslik blyat! Oslik!

Pagina: 1