som en del av min roll bedömer jag befintliga WLAN för röststöd. Under undersökningen vill jag självständigt verifiera så mycket av den information jag har fått som möjligt med hjälp av protokollanalys.. En inställning som jag alltid kämpade för att hitta var säkerheten i bruk, särskilt när EAP / Dot1X användes.
jag hade det mesta räknat ut och kunde svara på mina sista frågor när jag nyligen tog cwap-kursen med Peter Mackenzie (@MackenzieWiFi). Så här är en titt på att upptäcka säkerheten som används på ett SSID.
normalt kan information om säkerheten som används på ett SSID hittas i RSN IE (informationselement) av Beacons och Sondresponser. RSN står för Robust Security Network, som jag tror introducerades med 802.11 i. detta var ändringen som gjorde Wi-Fi Alliances WPA2 security suite en officiell del av 802.11-standarden. Du hittar inte en RSN IE i SSID kör WEP eller WPA (1) eftersom de är pre-802.11 i.
för att illustrera denna punkt visar nedanstående skärmdump ett Sondrespons från ett SSID med öppen autentisering (vänster) och ett SSID med WPA2-autentisering (höger). Du kan se RSN IE i WPA2-Sondresponsen nedan, men inte i Open Authentication (pre-802.11 i) Sondrespons.
det är värt att återkomma här att WPA2 är autentiserings-och nyckelhanteringsmetoden för alla 802.11 i SSID, oavsett om de använder en fördelad nyckel eller EAP (Extensible Authentication Protocol). Ofta antar människor att WPA2 bara är det du använder hemma på SSID med ett lösenord och EAP är något annat. Detta är inte fallet, WPA2 används för att definiera den säkra handskakningsprocessen för både PSK och EAP SSID, så du kommer att se i Windows-alternativ för WPA2-Personal (PSK) och WPA2-Enterprise (EAP).
så, förutsatt att du arbetar med en WPA2 SSID måste du titta på RSN IE (informationselement) i antingen Beacons för SSID eller i Sondresponserna till en anslutande klient. Mysteriet slutar dock inte där. Om du är van att titta på 802.11 ramar då vet du att de i princip är ett annat språk! Att förstå vad alla dessa bitar betyder är tillräckligt för att få någon att bli korsad. Tack och lov gör både Omnipeek och Wireshark ett ganska bra jobb med att avkoda (översätta) dessa bitar till användbar information.
nedanstående skärmdump visar RSN IE av ett WPA2-PSK-Sondsvar. Utan magiken i vår Protokollanalysatorprogramvara skulle vi behöva veta att 00-0f-AC-04 innebar att CCMP användes för kryptering och att 00-0f-AC-02 innebar att en pre Shared Key (PSK) användes för åtkomstuppgifter. Istället, OmniPeek i detta fall, sätter en härlig slem grön anteckning på slutet berättar detta (Wireshark gör detta också).
om någon har glömt är CCMP 802.11 i-derivatet av AES som används för att kryptera WPA2-anslutningar. När du ser CCMP kan du läsa den som AES.
det är också bra att veta att Extensible Authentication Protocol (EAP) bara är ett ramverk för att överföra någon form av autentiserings-och nyckelmekanism, det är inte en definierad mekanism i sig. Implementeringar som PEAP eller EAP-TLS är specifika autentiseringsmekanismer som bygger på EAP-ramverket för att specificera exakt hur ett autentiseringsutbyte ska ske.
av någon anledning har EAP blivit den terminologi som används för RADIEBASERAD referensåtkomst på 802.11-nätverk. Det är emellertid faktiskt EAP inkapslat i IEEE 802.1 x-standarden (eller Dot1X som dess allmänt kända) som används för att säkra våra ”EAP” SSID.
Ok. Det räcker! Mitt huvud gör ont. Så vad sägs om EAP SSID? Hur verifierar vi dessa inställningar i vår protokollanalys? Tja, det finns en anledning till att jag dyker in i den mycket kortfattade och otrevliga (och förmodligen lite fel) beskrivningen av EAP. Och det beror på att du inte hittar det listat i dina ramar!
skärmdumpen nedan visar ett Sondrespons från en WPA2-EAP SSID. Lägg märke till hur AKMP-sviten är listad som 802.1 X, inte EAP? Frustrerande hittar du inte EAP-typen (PEAP, EAP-TLS, etc) som anges i några Beacons eller Sondresponser. Detta beror på att AP kommer att använda 802.1 X mellan klienten och sig själv. De inkapslade EAP-ramarna skickas sedan till RADIUS-servern som bestämmer vilken EAP-typ som ska användas. Faktum är att när du konfigurerar ett SSID för EAP kan du faktiskt inte ange en EAP-typ som ska användas (…om du inte använder styrenheten/åtkomstpunkten som RADIUS-servern också).
Obs: ovanstående Sondrespons visar att SSID också stöder 802.11 r eller snabb övergång (FT) som det är känt i standarden.
så du kan verifiera att SSID använder WPA2-EAP men det räcker inte om du försöker konfigurera din klient korrekt för att ansluta. Hur verifierar vi den specifika EAP-typen som används? Tja, så vitt jag vet är det enda sättet att försöka ansluta till SSID och titta på EAP-meddelandena (känd som EAP över LAN eller EAPOL-meddelanden). Nedanstående skärmdump visar en RADIUS-server som ber en klient (i detta fall en iPhone) att använda EAP-TLS för autentisering.
men för att stödja EAP-TLS behöver ett certifikat laddas på klienten, vilket vi inte gjorde i det här testet. Så klienten skickar en negativ bekräftelse (N-Ack) till RADIUS-servern som minskar EAP-TLS, som du kan se nedan. Dessa ramar händer alla i följd, så du kan berätta att NAk är för den tidigare EAP-TLS-begäran.
tack och lov är RADIUS-servern inställd med flera autentiseringsmekanismer så det begär nu att klienten använder PEAP.
den här gången stöder klienten PEAP så att den svarar på att upprepa användningen av PEAP och startar handskakningsprocessen genom att säga ”hej”.
det kommer då att finnas mycket mer eapol-meddelanden i din protokollanalys, eftersom klienten och RADIUS-servern fortsätter utmaningen och nyckeln som är involverad i EAP-typen som används.
All denna information finns i 802.11 rubriker så är synlig utan att behöva dekryptera några fångar. Om du vill leta efter dig själv och ha en lek runt kan du ladda ner EAP Association capture som används för dessa skärmdumpar här.
jag hoppas att detta hjälper dig att förstå lite mer om protokollanalys av 802.11 autentiseringsmekanismer och visar sig vara användbara när du har en klient som kämpar för att ansluta till ett SSID. Som alltid, lämna din feedback nedan och kontakta mig på Twitter på @Mac_WiFi.
* * tack till Keith Miller (@packetologist) för mindre korrigering och Rob Lowe (@roblowe6981) för att uppmana mig att ladda upp capture-filen * *