Rilevazione le 802.11 schede e punti di accesso non autorizzati
Il primo obiettivo è rilevazione. Possiamo dire a quando qualcuno alimentazioni su una scheda all'interno di gamma della rete locale? Ciò può essere fatta con i componenti disponibili immediatamente ed il software libero. Il driver del Cisco Aironet incluso con i noccioli più recenti di Linux sostiene "il modo del video di rf", che consente un controllo promiscuo di 802.11 pacchetti - specificamente, controllando le 802.11 strutture grezze per rilevare se ci sono delle strutture rivelarici trasmettono per radio da un punto o da una scheda di accesso del rogue. Conforme alla specifica originale 802.11, ci sono tre codici categoria di 802.11 telai. Con l'obiettivo di rilevazione i punti di accesso del rogue e delle schede senza fili non autorizzate di Ethernet, siamo soprattutto interessati nei telai dei codici categoria 1 e 2. Le strutture del codice categoria 1 sono le uniche strutture permesse dentro dichiarano 1, unauthenticated dichiarano e sono in gran parte strutture dell'amministrazione usate per l'autenticazione, i falò e le richieste della sonda. Il codice categoria 2 che le strutture sono permesse in entrambi dichiara 1 e 2 ed è usato per l'associazione e la riassociazione. Dai punti di accesso, penseremmo vedere tantissime strutture del falò (codice categoria 1). Da unassociated i clienti ad-hoc che esplorano nel modo attivo, noi penserebbe vedere tantissime richieste della sonda (anche codice categoria 1). Verificare questa ipotesi, un metodo di controllo delle tutte e 802.11 le strutture dell'amministrazione è necessario, che la scheda del Cisco ed il driver di Linux sono capaci "nel modo del video di rf." Installi per mettere la scheda nel modo del video di rf, qualsiasi modo di BSS (uso ": r "per il modo normale del video di rf): # modo di eco ": y "> /proc/driver/aironet/eth0/Config # Allora, pacchetti annotanti di inizio con tcpdump, conservante li ad una lima per analisi successiva con etereo: # tcpdump - i eth0 - s 0 - W capturefile # La rete ad-hoc non autorizzata la prima prova doveva confermare la capacità di rilevare una scheda di WLAN che è alimentata sopra. Una scheda di Lucent Orinoco è stata configurata nel modo ad-hoc su un laptop di Win2k e girato sopra verso scopra se ci fossero delle strutture caratteristiche spedite dalla scheda di Orinoco quando è stato messo nel modo ad-hoc. Dopo la scheda inizializzata, il tcpdump è stato interrotto, cominciato etereo e la lima di bloccaggio sono stati aperti. Tantissime richieste della sonda dalla scheda di Orinoco sono state trovate, confermanti che era effettivamente possibile rilevare quando qualcuno all'interno di gamma vicina aveva alimentato su una scheda senza fili di Ethernet nel modo ad-hoc. La struttura dissecata era come segue:
Effettivamente, è possibile da dire a se qualcuno inizia una scheda attivamente d'esplorazione nel modo ad-hoc e le informazioni utili molte possono essere spigolate da una singola struttura. Più relativi sono gli SSID ed il MAC address, poiché possono essere usati per rintracciare giù una scheda e/o una persona particolari. Il punto di accesso non autorizzato la prova seguente doveva confermare la possibilità di rilevazione del punto di accesso del rogue. Una sessione del tcpdump è stata iniziata ed allora un punto di accesso del Cisco Aironet 340 è stato acceso. Dopo che il punto di accesso rifinisca il caricamento del sistema, il deposito è stato esaminato con etereo e tantissime strutture del falò spedite dal punto di accesso sono state trovate. Segue una tale struttura, dissecata di nuovo da etereo:
Il cliente non autorizzato lo stato esaminato finale era clienti non autorizzati. Il primo piano d'azione considerato (il piano d'azione più probabile), è che qualcuno porta una scheda straniera e le alimentazioni esso in su con lo SSID errato. Se la scheda attivamente stesse esplorando, le richieste della sonda sarebbero viste da questa scheda mentre ha tentato di trovare un punto di accesso. Il secondo piano d'azione è che qualcuno porta una scheda straniera e le alimentazioni esso in su con lo SSID corretto. Questo risulta essere poco un più problematico da rilevare, in quanto ci sarà soltanto alcune strutture delle 802.11 amministrazioni per innescare un allarme ed allora più traffico "normale". Ciò è problematica soprattutto a causa del senso il modo di RFMON_ANYBSS che sulla scheda del Cisco funziona - malgrado il relativo nome, la scheda non può ricevere simultaneamente i pacchetti da tutto il BSS nella gamma, particolarmente se quelle frequenze differenti di uso del BSS. La conseguenza è che prende un certo intervento manuale a traffico di annusata da un BSS particolare - veda la sezione qui sotto "sui problemi e sulle complicazioni" per più particolari su questo problema e come funzionare intorno esso. Questo problema è stato ignorato e preferibilmente il fuoco era sulle poche strutture delle 802.11 amministrazioni che rivelano prontamente nella ventosa - entrambi i piani d'azione risultati per produrre le richieste simili della sonda, in modo da entrambi i piani d'azione sono trattare come identici. La richiesta dissecata della sonda spedita da questa scheda:
I problemi e le complicazioni alcuni problemi sono emerso con la scheda ed il driver del Cisco che devono essere accennati. Il primo problema è che la scheda del Cisco, per difetto, anche nei modi di RFMON_ANYBSS e di RFMON, attivamente non esplora sempre per traffico su tutte le scanalature. Il seguenti sono le circostanze in cui pre-esplorerà per BSS:
Tutte queste circostanze vogliono "la scossa" la scheda nella pre-esplorazione. Per sviluppare un dispositivo pratico di rilevazione, la scheda dovrebbe essere data dei calci a gli intervalli normali, forse ogni minuto. Uno scritto semplice per toccare la lima di BSSList ogni minuto farà il trucco. Secondo problema: Non tutto il BSS nella gamma ha rivelato attendibilmente nella lima /proc/driver/aironet/eth0/BSSList. Quando la scheda è messa nel modo di RFMON, trasmettere è disabled, in modo da la scheda non può esplorare attivamente per BSS spedendo le richieste della sonda. Di conseguenza, la scheda deve usare l'esame passivo. Invece di spedizione delle richieste della sonda, la scheda ascolta i falò. Le esplorazioni passive usano un temporizzatore che—la scheda aspetterà di sentire le strutture del falò fino a che il temporizzatore non espiri ed allora che si muove verso un'altra scanalatura. Il problema con la scheda del Cisco è che questo temporizzatore è regolato troppo basso. Il valore di difetto è 40ms, che era insufficiente sulla nostra rete della prova per notare tutto il BSS, senza riguardo alla gamma o alla resistenza relativa del segnale dei punti di accesso. La soluzione doveva aggiungere questa linea alla procedura di inizio della scheda, setup_card, in airo.c: cfg.beaconListenTimeout = 120; Triplicare questo prespegnimento ha fatto attendibilmente il lavoro di rilevazione di BSS. Di conseguenza, tutti i nostri punti di accesso hanno rivelato in BSSList, tutto il tempo. Terzo problema: Malgrado il relativo nome, neppure mettere la scheda nel modo di RFMON_ANYBSS non ha indotto la scheda a ricevere il traffico da tutti i nostri punti di accesso, che erano tutti che usando le frequenze differenti e probabilmente sono stati sincronizzati diversamente. La scheda in se ha scelto un BSS per sincronizzare per basare sulla relativa propria procedura (probabilmente sulla relativa valutazione della resistenza relativa del segnale). Il problema con questo è che desideriamo vedere il traffico da tutto il BSSs nella gamma, non appena quelli che sembrano avere i segnali più forti. Un senso non potrebbe essere trovato per inabilitare questa caratteristica sulla scheda del Cisco, ma ci è un workaround - il driver di Linux fornisce un'interfaccia di /proc per regolare un AP preferito. Una volta la lista di BSSs nella gamma del dispositivo d'esplorazione è trovata (/proc/driver/aironet/eth0/BSSList), sceglie quello per controllare e fornire il MAC address nella lima /proc/driver/aironet/eth0/APList. Ciò forzerà la scheda per sincronizzare con quello BSS e per commutare a quella scanalatura, dopo di che il traffico da quello BSS può essere ricevuto ed usato per le valutazioni di resistenza del segnale o il controllo per l'attività sospettosa. Le conclusioni queste prove semplici confermano che ci sono 802.11 strutture che sono caratteristiche dei punti di accesso tipici del rogue e delle reti ad-hoc non autorizzate e che queste strutture possono essere rilevate ed analizzate usando i componenti disponibili immediatamente ed il software libero. Usando questi concetti con una base di dati dei punti e delle schede di accesso di fiducia e le impronte digitali dei telai sospettosi, eteree ha potuto essere usato come blocchetto di costruzione fondamentale in un sistema completo di rilevazione di 802.11 intrusioni. ciò è un articolo aggiunto da Kim Sulloway
|
|||||
|