mitä EAP-tyyppiä se käyttää?

osana rooliani arvioin olemassa olevia WLAN: ia Puhetukeen. Tutkimuksen aikana haluan itsenäisesti tarkistaa niin paljon tietoja olen saanut kuin mahdollista käyttäen protokollan analyysi.. Yksi asetus, jonka olen aina kamppaillut löytää, oli turvallisuus käytössä, varsinkin kun EAP / Dot1X oli käytössä.

I had most of it fulled out and was able to answer my last few questions when I took the Cwap course recently with Peter Mackenzie (@MackenzieWiFi). Joten tässä on tarkastella bonging turvallisuus käytössä SSID.

yleensä TIEDOT SSID: ssä käytetystä tietoturvasta löytyvät majakoiden ja luotaimen vastausten RSN IE: stä (Informaatioelementti). RSN tulee sanoista Robust Security Network, joka mielestäni otettiin käyttöön 802.11 i. tämä oli muutos, joka teki WI-Fi-Alliansseista WPA2 security suite virallisen osan 802.11-standardia. Et löydä RSN IE SSID: n käynnissä WEP tai WPA (1), koska ne ovat ennen 802.11 i.

tämän havainnollistamiseksi alla oleva kuvakaappaus näyttää luotaimen vastauksen SSID: ltä käyttäen avointa todennusta (vasemmalla) ja SSID: ltä käyttäen WPA2-todennusta (oikealla). RSN IE näkyy alla olevassa WPA2-koettimen vasteessa, mutta ei avoimessa todennuksessa (pre-802.11 i) koettimen vasteessa.

on syytä kerrata tässä, että WPA2 on todennus-ja avainhallintamenetelmä kaikille 802.11 i SSID: ille, käyttävätkö ne Pre Shared Key tai EAP (Extensible Authentication Protocol). Usein ihmiset olettavat WPA2 on vain mitä käytät kotona SSID: n salasanalla ja EAP on jotain muuta. Näin ei ole, WPA2: ta käytetään määrittelemään turvallinen kättelyprosessi sekä PSK: lle että EAP SSID: lle, joten näet Windows-vaihtoehdoissa WPA2-Personal (PSK) ja WPA2-Enterprise (EAP).

niin, olettaen, että työskentelet WPA2 SSID: n kanssa, sinun täytyy tarkastella RSN IE: tä (tietoelementtiä) joko SSID: n majakoissa tai koettimen vasteissa yhdistettävälle asiakkaalle. Mysteeri ei kuitenkaan pääty siihen. Jos on tottunut katsomaan 802: ta.11 kehykset sitten tiedät, että ne ovat periaatteessa eri kieltä! Kun ymmärtää, mitä nämä kaikki kohdat tarkoittavat, saa kenet tahansa sekoamaan. Onneksi sekä Omnipeek että Wireshark tekevät melko hyvää työtä dekoodaamalla (kääntämällä) nämä bitit hyödylliseksi tiedoksi.

alla oleva kuvakaappaus näyttää WPA2-PSK-luotaimen vastauksen RSN IE: n. Ilman Protokollaanalysaattoriohjelmistomme taikaa meidän olisi tiedettävä, että 00-0f-AC-04 tarkoitti CCMP: n olevan käytössä salauksessa ja että 00-0F-AC-02 tarkoitti sitä, että Pre Shared Key (PSK) oli käytössä käyttöoikeustunnuksissa. Sen sijaan Omnipeek tässä tapauksessa laittaa ihanan limanvihreän lapun loppuun kertoen meille tämän (Wireshark tekee myös näin).

mikäli joku on unohtanut, CCMP on WPA2-yhteyksien salaamiseen käytetty AES: n 802.11 i-johdannainen. Kun näet CCMP voit lukea sen AES.

on myös hyödyllistä tietää, että laajennettavissa oleva todennusprotokolla (Extensible Authentication Protocol, EAP) on vain kehys jonkinlaisen todennusmekanismin siirtämiselle, se ei ole itse määritelty mekanismi. Toteutukset, kuten PEAP tai EAP-TLS, ovat erityisiä todennusmekanismeja, jotka perustuvat EAP-kehykseen ja määrittelevät tarkasti, miten todennusvaihdon pitäisi tapahtua.

jostain syystä EAP: stä on tullut terminologia, jota käytetään RADIUS based credential access-järjestelmässä 802.11-verkoissa. Se on kuitenkin itse asiassa EAP kapseloitu IEEE 802.1 X-Standardiin (tai dot1x sen yleisesti tunnettuna), jota käytetään ”EAP” SSID: n turvaamiseen.

Ok. Riittää! Päätäni särkee. Entä EAP SSID ’ s? Miten varmistamme nämä asetukset protokollan analyysissä? NO, on syy sukelsin että hyvin ytimekäs ja epäkiitollinen (ja luultavasti hieman väärä) kuvaus EAP. Ja se johtuu siitä, että et löydä sitä listattuna kehyksissä!

alla olevassa kuvakaappauksessa näkyy luotaimen vastaus WPA2-EAP SSID: ltä. Huomaatko, miten AKMP Suite on listattu 802.1 X: ksi, ei EAP: ksi? Turhauttavasti et löydä EAP tyyppi (PEAP, EAP-TLS, jne) lueteltu mitään Majakat tai koetin vastauksia. Tämä johtuu siitä, että AP aikoo käyttää 802.1 X: ää asiakkaan ja itsensä välillä. Kapseloidut EAP-kehykset lähetetään RADIUS-palvelimelle, joka päättää, mitä EAP-tyyppiä käytetään. Itse asiassa, kun määrität SSID EAP et itse voi määrittää EAP tyyppi käyttää (…ellet käytät ohjain/tukiasema kuin RADIUS server samoin).

Huomautus: edellä koettimen vastaus osoittaa SSID tukee myös 802.11 r tai Fast Transition (FT) kuten se tunnetaan standardissa.

voit siis varmistaa, että SSID käyttää WPA2-EAP: tä, mutta tämä ei riitä, jos yrität määrittää asiakkaan yhteyden oikein. Miten varmistamme käytössä olevan EAP-tyypin? No, sikäli kuin tiedän, ainoa tapa on yrittää muodostaa SSID ja katsella EAP viestit (tunnetaan EAP yli LAN tai eapol viestit). Alla olevassa kuvakaappauksessa näkyy RADIUS-palvelin, joka pyytää asiakasta (tässä tapauksessa iPhonea) käyttämään EAP-TLS: ää todennukseen.

mutta tukea EAP-TLS todistus on ladattu asiakkaalle, mitä emme tehneet tässä testissä. Joten asiakas lähettää negatiivisen kuittauksen (n-Ack) RADIUS-palvelimelle, joka laskee EAP-TLS: ää, kuten näet alla. Nämä kehykset kaikki tapahtuvat järjestyksessä, joten voit kertoa, että NAk on edellistä EAP-TLS-pyyntöä varten.

onneksi RADIUS-palvelin on setup useita todennusmekanismeja, joten se pyytää nyt asiakas käyttää PEAP.

tällä kertaa asiakas ei tue PEAP niin se vastaa toistaen käytön PEAP, ja aloittaa kättely sanomalla ”Hei”.


tämän jälkeen protokollan analysoinnissa on paljon enemmän eapol-viestejä, kun asiakas-ja RADIUS-palvelin jatkavat käytössä olevan EAP-tyypin haastetta ja näppäilyä.

kaikki tämä tieto sisältyy 802.11-otsakkeeseen, joten se on katseltavissa ilman, että kaappausten salausta tarvitsee purkaa. Jos haluat etsiä itse ja pelata ympäriinsä, voit ladata näihin kuvakaappauksiin käytetyn EAP Association Capturen täältä.

Toivottavasti tämä auttaa ymmärtämään hieman enemmän 802: n protokollan analysointia.11 todennusmekanismit ja osoittautuu hyödylliseksi, kun asiakas kamppailee yhteyden SSID. Kuten aina, jätä palautteesi alle ja ota minuun yhteyttä Twitterissä osoitteessa @Mac_WiFi.

* * Thanks to Keith Miller (@packetologist) for the minor correction and Rob Lowe (@roblowe6981) for instruct me to upload the capture file **

Vastaa

Sähköpostiosoitettasi ei julkaista.