som en del af min rolle vurderer jeg eksisterende VLANs til stemmestøtte. Under undersøgelsen vil jeg gerne uafhængigt verificere så meget af de oplysninger, jeg har fået som muligt ved hjælp af protokolanalyse.. En indstilling, som jeg altid kæmpede for at finde, var sikkerheden i brug, især når EAP / Dot1h var i brug.
jeg havde det meste af det regnet ud og var i stand til at besvare mine sidste par spørgsmål, da jeg for nylig tog kurset med Peter Macken. Så her er et kig på spotting sikkerheden i brug på en SSID.
normalt kan oplysninger om den sikkerhed, der anvendes på et SSID, findes i RSN IE (informationselement) af Beacons og Probesvar. RSN står for Robust sikkerhedsnetværk, som jeg tror blev introduceret med 802.11 i. dette var ændringen, der gjorde de trådløse alliancer apa2 security suite til en officiel del af 802.11-standarden. Du kan ikke finde en RSN IE i SSID ‘ s kørende arbejdsprogram eller APV (1), da de er pre-802.11 i.
for at illustrere dette punkt viser nedenstående skærmbillede et sonde-svar fra et SSID ved hjælp af åben godkendelse (venstre) og et SSID ved hjælp af apa2-godkendelse (højre). Du kan se RSN IE i apa2 sonde respons nedenfor, men ikke i den åbne godkendelse (pre-802.11 i) sonde respons.
det er værd at opsummere her, at apa2 er godkendelsesmetoden og nøglehåndteringsmetoden for alle 802.11 i SSID ‘ er, uanset om de bruger en pre-delt nøgle eller EAP (udvidelig godkendelsesprotokol). Ofte antager folk, at apa2 kun er det, du bruger hjemme på SSID ‘ er med en adgangskode, og EAP er noget andet. Dette er ikke tilfældet, apa2 bruges til at definere den sikre håndtryksproces for både PSK og EAP SSID ‘ er, derfor vil du se i vinduer muligheder for apa2-Personal (PSK) og apa2-Enterprise (EAP).
så hvis du antager, at du arbejder med en apa2 SSID, skal du se på RSN IE (informationselement) i enten Beacons for SSID eller i Probesvarene til en forbindelsesklient. Mysteriet slutter dog ikke der. Hvis du er vant til at se på 802.11 rammer så ved du, at de dybest set er et andet sprog! At forstå, hvad alle disse Bits betyder, er nok til at få nogen til at gå krydsede øjne. Heldigvis gør både Omnipeek og Trådbark et ret godt stykke arbejde med at afkode (oversætte) disse Bits til nyttige oplysninger.
nedenstående skærmbillede viser RSN IE af en APPA2-PSK Probe respons. Uden magien i Vores Protokolanalysatorprogram skulle vi vide, at 00-0f-AC-04 betød, at CCMP var i brug til kryptering, og at 00-0f-AC-02 betød, at en Pre Shared Key (PSK) var i brug til adgangsoplysninger. I stedet sætter Omnipeek i dette tilfælde en dejlig slim grøn note på enden, der fortæller os dette (Trådbark gør det også).
hvis nogen har glemt det, er CCMP 802.11 i-derivatet af AES, der bruges til at kryptere apa2-forbindelser. Når du ser CCMP, kan du læse det som AES.
det er også nyttigt at vide, at udvidelig godkendelsesprotokol (EAP) kun er en ramme for at overføre en slags autentificerings-og nøglemekanisme, det er ikke en defineret mekanisme i sig selv. Implementeringer som PEAP eller EAP-TLS er specifikke godkendelsesmekanismer, der bygger på EAP-rammen for at specificere nøjagtigt, hvordan en godkendelsesudveksling skal finde sted.
af en eller anden grund er EAP blevet den terminologi, der bruges til RADIUSBASERET legitimationsadgang på 802.11-netværk. Det er dog faktisk EAP indkapslet i IEEE 802.1 standard (eller Dot1h som det er almindeligt kendt), der bruges til at sikre vores “EAP” SSID ‘ er.
Ok. Så er det nok! Mit hoved gør ondt. Så hvad med EAP SSID ‘ s? Hvordan verificerer vi disse indstillinger i vores protokolanalyse? Nå, der er en grund til, at jeg dykker ind i den meget kortfattede og ungraceful (og sandsynligvis lidt forkert) beskrivelse af EAP. Og det er fordi du ikke finder det opført i dine rammer!
skærmbilledet nedenfor viser et Probesvar fra et app2-EAP SSID. Bemærk, hvordan AKMP-pakken er angivet som 802.1, ikke EAP? Frustrerende finder du ikke EAP-typen (PEAP, EAP-TLS osv.), Der er anført i nogen Beacons eller Probesvar. Dette skyldes, at AP vil bruge 802.1 gange mellem klienten og sig selv. De indkapslede EAP-rammer sendes derefter til RADIUS-serveren, der beslutter, hvilken EAP-type der skal bruges. Når du konfigurerer et SSID til EAP, kan du faktisk ikke angive en EAP-type, der skal bruges (…medmindre du også bruger controlleren/adgangspunktet som RADIUS-serveren).
Bemærk: ovenstående Sonderespons viser, at SSID også understøtter 802.11 r eller Fast Transition (FT), som det er kendt i standarden.
så du er i stand til at kontrollere, at SSID ‘ et bruger apa2-EAP, men det er ikke nok, hvis du forsøger at konfigurere din klient korrekt til at oprette forbindelse. Hvordan verificerer vi den specifikke EAP-type i brug? Nå, så vidt jeg ved, er den eneste måde at forsøge at oprette forbindelse til SSID og se EAP-meddelelserne (kendt som EAP Over LAN-eller EAPOL-meddelelser). Nedenstående skærmbillede viser en RADIUS-server, der beder en klient (i dette tilfælde en iPhone) om at bruge EAP-TLS til godkendelse.
men for at understøtte EAP-TLS skal et certifikat indlæses på klienten, hvilket vi ikke gjorde i denne test. Så klienten sender en negativ bekræftelse (N-Ack) til RADIUS-serveren faldende EAP-TLS, som du kan se nedenfor. Disse rammer sker alle i rækkefølge, så du kan fortælle, at NAk er for den tidligere EAP-TLS-anmodning.
heldigvis er RADIUS-serveren konfigureret med flere godkendelsesmekanismer, så den nu anmoder om, at klienten bruger PEAP.
denne gang understøtter klienten PEAP, så den reagerer på at gentage brugen af PEAP, og starter håndtryksprocessen ved at sige “Hej”.
der vil så være meget flere eapol-meddelelser i din protokolanalyse, da klienten og RADIUS-serveren fortsætter udfordringen og nøglen involveret i EAP-typen i brug.
alle disse oplysninger er indeholdt i 802.11-overskrifterne, så de kan ses uden at skulle dekryptere nogen optagelser. Hvis du ønsker at kigge efter dig selv og har en leg omkring kan du hente EAP Association capture bruges til disse screenshots her.
jeg håber, at dette hjælper dig med at forstå lidt mere om protokolanalyse af 802.11 godkendelsesmekanismer og viser sig nyttige, når du har en klient, der kæmper for at oprette forbindelse til et SSID. Som altid, bedes du forlade din feedback nedenfor og forbinde med mig på kvidre på @Mac_fifi.
* * tak til Keith Miller (@packetologist) for den mindre korrektion og Rob lav (@roblove6981) for at bede mig om at uploade capture-filen **