3. Linux Wireless Tools, Drivers, and Stacks
In questo modulo tratteremo il sottosistema wireless di Linux.
Inizieremo discutendo alcuni degli strumenti che useremo nel corso. Spesso interagiremo con la nostra scheda wireless tramite un'interfaccia utente in un software, ma ci sono circostanze in cui un penetration tester deve comprendere e saper usare gli strumenti che operano "sotto la superficie".
Un esempio di situazione in cui la conoscenza degli strumenti è assolutamente critica è un penetration test wireless remoto. Un amministratore di sistema configurerà una macchina con una scheda wireless sul sito e ci permetterà di interagire da remoto via SSH. In questi casi, potremmo non avere accesso a hardware familiare e ben testato. Le capacità e i limiti della scheda scelta dall'amministratore di sistema sono critici, e dobbiamo essere in grado di gestire i casi in cui i driver si comportano male usando gli strumenti descritti di seguito.
Inoltre, discuteremo i driver Linux e gli stack wireless. Gran parte delle informazioni in questa parte del modulo sarà utile quando si usano schede wireless sconosciute o poco cooperative, per la risoluzione dei problemi e come riferimento futuro.
3.1. Caricamento e scaricamento dei driver wireless
Partiamo dalle basi e configuriamo il nostro dispositivo wireless con strumenti da riga di comando.
Quando un dispositivo viene collegato o acceso, Linux dovrebbe caricare automaticamente il relativo driver. Digiamo il comando airmon-ng nel prompt per determinare il driver del nostro dispositivo. Airmon-ng è un'utility della suite Aircrack-ng per l'audit delle reti Wi-Fi.
kali@kali:~$ sudo airmon-ng
PHY Interface Driver Chipset
phy0 wlan0 ath9k_htc Qualcomm Atheros Communications AR9271 802.11n
Listato 1 - Esecuzione di lsusb per Alfa AWUS036NHA
L'output rivela il driver del dispositivo wireless come ath9k_htc e il chipset come Qualcomm Atheros AR9271.
Successivamente, eseguiamo il comando lsusb. Questo comando elenca i dispositivi USB di un sistema e mostra informazioni dettagliate per ciascun dispositivo:
kali@kali:~# sudo lsusb -vv
Bus 001 Device 002: ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x0cf3 Qualcomm Atheros Communications
idProduct 0x9271 AR9271 802.11n
bcdDevice 1.08
iManufacturer 16 ATHEROS
iProduct 32 USB2.0 WLAN
iSerial 48 12345
bNumConfigurations 1
...
Listato 2 - Esecuzione di lsusb -vv su AWUS036NHA
Questo estratto dell'output indica che il vendor id e il product id sono 0cf3:9271 e che il chipset è un AR9271 di Qualcomm Atheros Communications.
In Windows, ogni singolo componente hardware deve avere il proprio driver installato. Alcuni dispositivi sono molto simili. Possono avere chip identici o chip diversi che si comportano in modo simile. Può anche accadere che due dispositivi dall'aspetto simile pubblicizzino product ID diversi.
Su Linux, un driver può coprire più dispositivi e talvolta più chipset simili. Ad esempio, l'Alfa AWUS036NHA ha lo stesso chipset del TP-Link WN722N v1 e di almeno altri 50 dispositivi, il che significa che un singolo driver li gestisce tutti. Poiché quel driver specifico è fornito con il kernel, non è necessario installare nulla.
Sebbene sia possibile compilare i driver direttamente nel kernel in Linux, la maggior parte dei driver sono solitamente Loadable Kernel Modules (LKM), caricati solo quando necessario per evitare sprechi di memoria. Anche altri sistemi operativi usano moduli del kernel caricabili, ma con nomi diversi per questa funzionalità.
Sebbene sia raramente necessario modificarli, i moduli del kernel hanno spesso parametri per regolare le impostazioni dell'hardware. Queste impostazioni vengono visualizzate con il comando modinfo e il nome del driver. Eseguendo modinfo per il driver ath9k_htc si ottiene il seguente output:
kali@kali:~$ sudo modinfo ath9k_htc
filename: /lib/modules/4.16.0-kali2-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k_htc.ko
firmware: ath9k_htc/htc_9271-1.4.0.fw
firmware: ath9k_htc/htc_7010-1.4.0.fw
description: Atheros driver 802.11n HTC based wireless devices
license: Dual BSD/GPL
author: Atheros Communications
alias: usb:v0CF3p20FFd*dc*dsc*dp*ic*isc*ip*in*
...
alias: usb:v0CF3p1006d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0CF3p9271d*dc*dsc*dp*ic*isc*ip*in*
depends: mac80211,ath9k_hw,ath9k_common,ath,cfg80211,usbcore
retpoline: Y
intree: Y
name: ath9k_htc
vermagic: 4.16.0-kali2-amd64 SMP mod_unload modversions
parm: debug:Debugging mask (uint)
...
parm: blink:Enable LED blink on activity (int)
Listato 3 - Uso di modinfo per elencare i parametri di ath9k_htc
Queste informazioni sono importanti per determinare dipendenze, compatibilità e requisiti di firmware. Il percorso completo del file driver ath9k_htc.ko è mostrato nel campo filename. I driver si trovano in sottodirectory di /lib/modules/
I due campi firmware indicano che sia il firmware ath9k_htc/htc_9271-1.4.0.fw sia ath9k_htc/htc_7010-1.4.0.fw possono essere caricati da questo driver.
Il driver elenca tutti gli alias dei dispositivi supportati nei campi alias. Ad esempio, usb:v0CF3p9271 indica un dispositivo USB, prodotto dal vendor ID 0CF3 (Qualcomm Atheros Communications), con device ID 9271 (AR9271 802.11n). Quando il dispositivo viene installato, si identifica come usb:v0CF3p9271 e, quando il sistema determina che il driver ath9k_htc supporta quell'alias, viene caricato in memoria.
Quando il driver è caricato in memoria, il sistema carica anche i moduli dipendenti elencati nel campo depends. Se anche i moduli elencati hanno dipendenze, vengono caricati anch'essi.
Gli elementi nel campo params sono opzioni per il dispositivo. Di solito non è necessario modificare i parametri predefiniti. Le distribuzioni Linux possono farlo se lo ritengono opportuno.
Nell'esempio seguente, disabilitiamo il lampeggio dell'attività di rete sul driver ath9k_htc, reimpostando il parametro blink al caricamento del driver:
Listato 4 - Caricamento di ath9k_htc e disabilitazione del LED lampeggiante
Se si verifica un errore, verrà visualizzato nella console. Se non ci sono errori, non ci sarà alcun output.
Le distribuzioni Linux consentono agli utenti di impostare e modificare i parametri dei moduli usando /etc/modprobe.d. Questa directory può essere usata anche per inserire moduli in blacklist.
Un buon esempio di quando usare la blacklist è il caso in cui un driver Broadcom open source e i driver proprietari del vendor sono entrambi presenti sul sistema. Se eseguiamo modinfo su entrambi, vedremo che condividono ID simili. Solo un driver alla volta può rivendicare un dispositivo, quindi dobbiamo mettere in blacklist uno dei due. In caso contrario, i due driver competono per la stessa risorsa, causando risultati imprevisti.
lsmod elenca tutti i moduli caricati e le dipendenze di ciascun modulo. Eseguendo il comando con il driver ath9k_htc caricato si ottiene il seguente output:
kali@kali:~$ lsmod
Module Size Used by
ath9k_htc 81920 0
ath9k_common 20480 1 ath9k_htc
ath9k_hw 487424 2 ath9k_htc,ath9k_common
ath 32768 3 ath9k_htc,ath9k_hw,ath9k_common
mac80211 802816 1 ath9k_htc
cfg80211 737280 4 ath9k_htc,mac80211,ath,ath9k_common
rfkill 28672 3 cfg80211
uhci_hcd 49152 0
ehci_pci 16384 0
ehci_hcd 94208 1 ehci_pci
ata_piix 36864 0
mptscsih 36864 1 mptspi
usbcore 290816 5 ath9k_htc,usbhid,ehci_hcd,uhci_hcd,ehci_pci
usb_common 16384 1 usbcore
...
Listato 5 - Elenco dei moduli del kernel caricati
Notiamo che l'output di lsmod relativo al nostro driver wireless corrisponde alle dipendenze di modinfo nel Listato 3. La prima colonna contiene il modulo caricato e la terza colonna mostra il numero e i nomi dei moduli che lo utilizzano.
A volte è necessario scaricare un driver. Occasionalmente dobbiamo ricaricarlo (con o senza parametri diversi) oppure vogliamo usare un driver diverso, poiché solo un driver alla volta può rivendicare un dispositivo.
Prima di scaricare un driver, dobbiamo rimuovere i moduli da cui il dispositivo dipende con il comando rmmod. I moduli dipendenti dal modulo principale devono essere scaricati per primi.
Vediamo cosa succede se proviamo a rimuovere un modulo del nostro driver ath9k_htc che ha ancora dipendenze:
kali@kali:~$ sudo rmmod ath
rmmod: ERROR: Module ath is in use by: ath9k_htc ath9k_hw ath9k_common
Listato 6 - Tentativo di rimozione di un modulo con dipendenze
Il Listato 6 mostra che tentare di rimuovere un modulo con dipendenze restituisce un errore.
Con l'output di lsmod nel Listato 5 come guida, possiamo iniziare a rimuovere i moduli non necessari ad altri driver. Se non siamo sicuri di quale modulo rimuovere successivamente, possiamo eseguire di nuovo lsmod e trovarne uno che non sia usato da altri.
Listato 7 - Rimozione corretta dei moduli
Warning
Se stai sperimentando con i driver, modificandoli o compilandoli, puoi usare insmod per caricare manualmente un modulo da un percorso specifico; modprobe carica un modulo dalla directory dei moduli del kernel. Esempio: insmod rtl8812au.ko.
3.2. Wireless Tools
Esistono due serie di strumenti per impostare, visualizzare o modificare i parametri della scheda wireless. iw, la serie moderna di strumenti, è pensata per il framework mac80211 più recente. Dall'altra parte, iwconfig (e altri, come iwpriv), risalenti ai primi anni 2000, sono stati creati per il framework ieee80211. Sebbene iwconfig possa ancora essere usato per alcune funzionalità di mac80211, sono deprecati e limitati rispetto alle capacità di iw.
Discuteremo il framework mac80211 e il framework ieee80211 più avanti in questo modulo. Per ora, esploriamo le funzionalità e le capacità di entrambi i set di strumenti. Inizieremo con gli strumenti legacy.
3.2.1. iwconfig e altre utility
Prendiamoci un momento per discutere alcune delle utility deprecate disponibili in Linux.
- iwconfig manipola i parametri wireless di base: cambia modalità, imposta canali e chiavi.
- iwlist consente di avviare la scansione, elencare frequenze, bit rate e chiavi di crittografia.
- iwspy fornisce la qualità del collegamento per nodo (non spesso implementata dai driver).
- iwpriv consente di manipolare le Wireless Extensions specifiche di un driver.
Per vedere i numeri dei canali e le frequenze corrispondenti che la nostra interfaccia wireless è in grado di rilevare, possiamo eseguire iwlist con il nome dell'interfaccia seguito dal parametro frequency:
kali@kali:~$ sudo iwlist wlan0 frequency
wlan0 14 channels in total; available frequencies :
Channel 01 : 2.412 GHz
Channel 02 : 2.417 GHz
Channel 03 : 2.422 GHz
Channel 04 : 2.427 GHz
Channel 05 : 2.432 GHz
Channel 06 : 2.437 GHz
Channel 07 : 2.442 GHz
Channel 08 : 2.447 GHz
Channel 09 : 2.452 GHz
Channel 10 : 2.457 GHz
Channel 11 : 2.462 GHz
Channel 12 : 2.467 GHz
Channel 13 : 2.472 GHz
Listato 8 - Uso di iwlist per visualizzare canali/frequenze disponibili
Nota che l'output del comando varierà in base alla geografia.
3.2.2. L'utility iw
Sebbene potremmo ancora usare iwconfig e altri strumenti grazie a un layer di compatibilità, sono deprecati e non dovremmo più usarli. L'utility iw e la sua varietà di opzioni è l'unico comando di cui abbiamo bisogno per configurare un dispositivo Wi-Fi.
Supponendo che i driver siano stati caricati correttamente, eseguire iw list ci fornirà molte informazioni dettagliate sui dispositivi wireless e sulle loro capacità:
kali@kali:~$ sudo iw list
Wiphy phy0
...
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
* outside context of a BSS
Band 1:
Capabilities: 0x116e
HT20/HT40
...
...
HT TX/RX MCS rate indexes supported: 0-7
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
...
Listato 9 - Uso di iw list per visualizzare informazioni dettagliate sull'interfaccia wireless
Il listato sopra mostra che la scheda supporta diverse modalità, tra cui IBSS (ad hoc), monitor mode, managed mode (client) e AP mode. Elenca anche le frequenze consentite. I canali da 1 a 13 sono consentiti a 20 dBm, mentre il 14 è vietato.
Per ottenere un elenco degli access point wireless nel raggio della nostra scheda, useremo iw con l'opzione dev wlan0, che specifica il nostro dispositivo. Aggiungeremo quindi il parametro scan. Infine, invieremo l'output di questo comando a grep SSID per filtrare solo i nomi delle reti wireless:
Listato 10 - Elenco degli SSID disponibili analizzando l'output di iw scan
Il numero del canale su cui trasmette un access point target è un'informazione critica. L'output di iw dev scan può essere ulteriormente raffinato inviando i risultati a egrep usando l'operatore OR logico (|) per mostrare le stringhe che contengono "DS Parameter set" oppure "SSID:":
kali@kali:~$ sudo iw dev wlan0 scan | egrep "DS Parameter set|SSID:"
SSID: wifu
DS Parameter set: channel 3
SSID: 6F36E6
DS Parameter set: channel 11
Listato 11 - Elenco degli SSID e dei canali disponibili analizzando l'output di iw scan
Con alcuni dei comandi di base completati, creeremo una nuova Virtual Interface (VIF) denominata "wlan0mon" in monitor mode. Questi comandi iw possono sembrare complessi, ma una volta scomposti, noteremo che la logica che seguono è piuttosto semplice.
Specifichiamo di nuovo il nostro dispositivo con iw dev wlan0. Poi aggiungiamo un'interfaccia con l'opzione interface e il parametro add seguito dal nome (wlan0mon). Infine, l'opzione type con monitor posiziona la nuova interfaccia in monitor mode:
Listato 12 - Aggiunta di un'interfaccia separata in monitor mode, chiamata wlan0mon collegata a wlan0
Come per molti comandi, quando non viene visualizzato alcun output, sappiamo che il comando è andato a buon fine. Con la nuova interfaccia creata, dobbiamo attivarla con ip (le interfacce appena create sono disattivate per impostazione predefinita):
Listato 13 - Attivazione della wlan0mon appena creata
Usando il comando iw dev info, potremo ispezionare la nostra interfaccia in monitor mode appena creata:
kali@kali:~$ sudo iw dev wlan0mon info
Interface wlan0mon
ifindex 4
wdev 0x1
addr 0c:0c:ac:ab:a9:08
type monitor
wiphy 0
channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
Listato 14 - Ottenimento di informazioni da iw sull'interfaccia in monitor mode
Verifichiamo che la nostra scheda sia in monitor mode avviando uno sniffer, tcpdump, per catturare i frame wireless:
kali@kali:~$ sudo tcpdump -i wlan0mon
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0mon, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 262144 bytes
13:39:17.873700 2964927396us tsft 1.0 Mb/s 2412 MHz 11b -20dB signal antenna 1 [bit 14] Beacon (wifu) [1.0* 2.0* 5.5* 11.0* 9.0 18.0 36.0 54.0 Mbit] ESS CH: 3, PRIVACY[|802.11]
Listato 15 - Test della monitor mode con tcpdump
Eseguendo questo comando nel nostro ambiente di laboratorio verrà visualizzato molto traffico sull'interfaccia wlan0mon. Premendo Ctrl+C si interromperà la cattura.
Nell'esempio sopra, notiamo un beacon sul canale 3 con SSID "wifu".
Una volta terminato con la nostra VAP, vorremo eliminarla con il comando iw e l'opzione del. Fatto ciò, confermiamo che ha funzionato con info:
kali@kali:~$ sudo iw dev wlan0mon interface del
kali@kali:~$ sudo iw dev wlan0mon info
command failed: No such device (-19)
Listato 16 - Eliminazione della VAP in monitor mode
Central Regulatory Domain Agent (CRDA) aiuta le radio a rispettare le normative wireless nel mondo. È usato dal sottosistema wireless cfg80211 per applicare le impostazioni del dominio regolatorio per una determinata località. Le normative dei paesi possono essere piuttosto complesse, e CRDA imposta la radio per operare entro le normative del paese in cui si trova. In particolare, applica i limiti di potenza di trasmissione sulla radio, impedisce alla radio di trasmettere su frequenze ristrette e rispetta altre limitazioni come DFS. Il comando iw reg interagisce con CRDA per interrogare e, in alcuni casi, modificarlo.
I produttori possono anche impostare limitazioni sull'hardware di un dispositivo a seconda di dove viene venduto. Ad esempio, le schede wireless Intel vendute negli Stati Uniti non possono andare oltre il canale 11. Inoltre, Mikrotik impedisce che i modelli internazionali con range di frequenza maggiori vengano venduti negli Stati Uniti.
Per visualizzare il dominio regolatorio corrente, usiamo iw reg get:
kali@kali:~$ sudo iw reg get
global
country 00: DFS-UNSET
(2402 - 2472 @ 40), (6, 20), (N/A)
(2457 - 2482 @ 20), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN
(5170 - 5250 @ 80), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(5250 - 5330 @ 80), (6, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
(5490 - 5730 @ 160), (6, 20), (0 ms), DFS, PASSIVE-SCAN
(5735 - 5835 @ 80), (6, 20), (N/A), PASSIVE-SCAN
(57240 - 63720 @ 2160), (N/A, 0), (N/A)
Listato 17 - Ottenimento delle informazioni sul dominio regolatorio
Per impostazione predefinita, Kali è configurata sul dominio regolatorio globale (00).
Per cambiare o impostare il dominio regolatorio, eseguiamo iw reg set
La modifica non è permanente, poiché l'impostazione è solo in memoria. Per assicurarsi che sia sempre impostata all'avvio, modifichiamo /etc/default/crda con un editor di testo e compiliamo la variabile REGDOMAIN:
Figura 1: sudo nano /etc/default/crda
Dopo il riavvio, confermiamo che il dominio regolatorio è stato impostato eseguendo di nuovo iw reg get:
kali@kali:~$ sudo iw reg get
global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
Listato 18 - Ottenimento delle informazioni sul dominio regolatorio dopo l'impostazione su US
In sintesi, ecco cosa possiamo apprendere dall'output:
- Nella banda 2.4 GHz, la trasmissione è consentita tra 2.402 GHz e 2.472 GHz con larghezza di canale fino a 40 MHz e potenza fino a 30 dBi.
- Nella banda 5 GHz, 5.170–5.250 GHz è consentito con canali fino a 80 MHz a 23 dBi, 5.250–5.330 GHz con canali fino a 80 MHz a 23 dBi con DFS, 5.490–5.730 GHz con canali fino a 160 MHz a 23 dBi e DFS, 5.735–5.835 GHz con canali fino a 80 MHz e fino a 30 dBi.
- Nella banda 60 GHz, 57.240–63.720 GHz è consentito con canali fino a 2.160 GHz a 40 dBi.
Il dominio regolatorio che impostiamo può talvolta essere sovrascritto. L'elaborazione delle regole CRDA è piuttosto complessa, e altri fattori entrano in gioco per garantire l'uso del dominio regolatorio corretto. Ad esempio, verrà sovrascritto quando ci si connette a un AP che pubblicizza un paese. Alcuni AP consentono di impostare un paese e lo pubblicizzano nei loro beacon. Ciò può includere informazioni dettagliate sui canali autorizzati.
Una scheda wireless può talvolta pubblicizzare il proprio dominio regolatorio tramite il driver. Collegando l'Alfa AWUS036NHA, pubblicizza il dominio regolatorio GB:
kali@kali:~$ sudo iw reg get
global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
phy#0
country GB: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
Listato 19 - Ottenimento delle informazioni sul dominio regolatorio dopo il collegamento dell'Alfa AWUS036NHA
Poiché la nostra scheda è solo 2.4 GHz, il dominio regolatorio GB consente 2402–2482 MHz, il che permetterebbe i canali 12 e 13, mentre gli Stati Uniti consentono solo i canali da 1 a 11. Per questo motivo, l'output di iw list mostra i canali 12 e 13 disabilitati, seguendo la normativa più restrittiva del dominio regolatorio US.
kali@kali:~$ sudo iw list
...
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
Listato 20 - Elenco delle frequenze consentite dopo il collegamento dell'Alfa AWUS036NHA
3.2.3. L'utility rfkill
rfkill è uno strumento per abilitare o disabilitare i dispositivi wireless collegati. Possiamo usarlo per il Wi-Fi, ma anche per Bluetooth, banda larga mobile come 4G/LTE, 5G, WiMax, GPS, FM, NFC e qualsiasi altra radio.
Eseguiamo rfkill list per visualizzare tutti i dispositivi Wi-Fi e Bluetooth abilitati sul sistema:
kali@kali:~$ sudo rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
Listato 21 - Elenco dei blocchi RF con l'utility rfkill
"Soft blocked" si riferisce a un blocco da rfkill, eseguito in software. "Hard blocked" si riferisce a un interruttore fisico o a un parametro BIOS del dispositivo. rfkill può modificare solo i soft block.
Una radio può essere disabilitata (soft blocked) usando rfkill block seguito dal numero ID del dispositivo visualizzato nel comando rfkill list. Usando l'output precedente, eseguiremo il comando rfkill per disabilitare il nostro dispositivo Wi-Fi:
Listato 22 - Soft block RF su phy0
Se il comando ha successo, non viene visualizzato nulla.
Eseguiamo rfkill list 1 per elencare specificamente il nostro dispositivo Wi-Fi disabilitato:
Listato 23 - Elenco dei blocchi RF per phy0
Per riabilitare il nostro dispositivo Wi-Fi eseguiremo rfkill con il parametro unblock:
Listato 24 - Rimozione del soft block su phy0
Possiamo disabilitare tutte le radio contemporaneamente con il parametro block all:
Listato 25 - Soft block di tutti i dispositivi wireless
E tutti i dispositivi possono essere riabilitati usando rfkill con il parametro unblock all.
3.3. Wireless Stacks and Drivers
Il sistema operativo Linux supporta due stack wireless. Il sottosistema ieee80211 è stato deprecato a favore del framework mac80211 più recente. Per questo motivo, qualsiasi driver recente nel kernel sarà scritto usando il framework mac80211.
Esamineremo entrambi, poiché sono ancora in uso.
3.3.1. Il sottosistema wireless ieee80211
Quando il Wi-Fi divenne ampiamente disponibile, si partì dal relativamente semplice sottosistema ieee80211. Era sufficiente per Linux per interagire con i vari driver e fornire un'interfaccia comune per gestire le schede Wi-Fi.
Le Wireless Extension (WE), note come wext, sono un'estensione dell'interfaccia di rete Linux per gestire le specificità del Wi-Fi. Furono implementate in tre parti che interagiscono tra loro.
La prima parte era un set di strumenti utente per controllare i driver, con iwconfig, iwlist, iwspy e iwpriv. La seconda parte consisteva nell'implementazione di wext nei driver Wi-Fi per rispondere alle azioni attivate dagli strumenti wireless. Infine, wext richiedeva un intermediario per comunicare le azioni dei diversi strumenti utente ai driver e rispondere, che si trova nel kernel.
Alcuni driver iniziali si affidavano a utility esterne per controllare vari aspetti e capacità della scheda wireless. Ogni chipset aveva la propria utility, ma nessuna era compatibile con le altre. Avevano sintassi diverse, capacità diverse e ciascuna poteva gestire solo il proprio driver.
Il panorama dei driver per schede wireless, delle utility e degli standard era ancora pieno di incoerenze. Ad esempio, la maggior parte dei driver non poteva implementare la master mode, cambiare la potenza di uscita della scheda o supportare Wi-Fi Protected Access (WPA). Persino i nomi delle interfacce non erano standardizzati sotto ieee80211, causando ovvia confusione su quando usare "eth", "wifi", "ath", "wlan", ecc.
Sebbene wext fosse un passo nella direzione giusta, molti driver wireless avevano ancora capacità diverse e ciascuno implementava le wireless extensions in modo diverso.
3.3.2. Il framework wireless mac80211
Con l'evoluzione del Wi-Fi e la sua crescente complessità, fu introdotto il framework mac80211. Mac80211 centralizza molto codice comune ed è stato più flessibile nel gestire le nuove tecnologie wireless e le differenze tra chipset.
Il framework wireless mac80211 è incluso in tutti i kernel Linux moderni. Sotto mac80211, la maggior parte delle funzioni comuni è standardizzata. Ciò significa che i driver wireless non devono reimplementarle.
La standardizzazione delle funzioni ha portato sia nuovi miglioramenti sia nuovi requisiti. Ecco un elenco di alcune di queste modifiche:
- Il supporto per 802.11n, 802.11ac e altre modalità è integrato.
- Il supporto WEP e WPA è fornito tramite wpa_supplicant, lo strumento de facto per connettersi alle reti wireless.
- Il Common Regulatory Domain con Central Regulatory Domain Agent (CRDA) applica le diverse normative sulle comunicazioni wireless nei paesi del mondo (limitazioni di frequenza, potenza di uscita e altro).
- La master mode (nota anche come Access Point mode) richiede Host access point daemon (hostapd).
- Il comando iw è usato per manipolare le impostazioni dell'interfaccia wireless al posto di iwconfig, iwpriv, iwlist e iwspy.
- Il processo di cambio delle modalità wireless è ora standardizzato su tutti i dispositivi/driver.
- Le interfacce wireless hanno una convenzione di denominazione comune di "wlan" seguita da una o due cifre.
- Tutte le funzioni per le diverse modalità (managed, master, monitor, mesh, ecc.) sono disponibili per i driver, ma non tutti i chipset le supportano.
Warning
Nota che i nomi delle interfacce "wlan*" vengono assegnati in base all'ordine di rilevamento. Per questo motivo, il nome di un'interfaccia può variare in base all'ordine in cui viene rilevata. Inoltre, udev può rinominare le interfacce in "wlp*" o "wlx*" nel tentativo di dare alle interfacce un nome prevedibile quando vengono collegate.
Non possiamo elencare tutte le modifiche e le funzionalità di mac80211 né approfondirle qui. Consulta il sito Linux Wireless per maggiori informazioni su questo argomento.
Continuiamo la nostra discussione su mac80211 parlando di alcune delle librerie software con cui interagisce. mac80211 fa parte di un gruppo più ampio di librerie software che include nl80211 e cfg80211.
nl80211 è la libreria NetLink dedicata all'802.11, e aiuta strumenti come wpa_supplicant, hostapd, iw, Wireshark, aircrack-ng e altri strumenti di cattura pacchetti a comunicare e interagire con i driver nel kernel, tramite cfg80211. Discuteremo questi strumenti in seguito.
cfg80211 fa parte del kernel Linux. È l'API di configurazione per l'802.11 e interagisce direttamente con i driver FullMAC e, tramite mac80211, con i driver SoftMAC.
I driver FullMAC sono chipset wireless completamente integrati, come quelli negli smartphone, con molte funzioni wireless integrate nell'hardware stesso. È necessario solo un driver minimale.
I SoftMAC, d'altra parte, sono per radio semplici e richiedono driver più complessi. cfg80211 interagisce anche con il dominio regolatorio, CRDA, che discuteremo in seguito. Infine, mac80211 implementa tutte le funzioni wireless necessarie affinché la radio SoftMAC operi nelle diverse modalità wireless.
Il seguente diagramma mostra come queste librerie interagiscono tra loro.
Figura 2: Collegamenti tra mac80211, cfg80211 e nl80211
La Figura 2 mostra un driver FullMAC, brcmfmac, usato con alcuni chip Broadcom. Dall'altra parte, troviamo iwlwifi, un driver SoftMAC che gestisce i chipset Intel recenti.
Nel wireless, abbiamo il MAC Sublayer Management Entity (MLME), che si occupa delle seguenti operazioni di gestione:
- Authentication
- Deauthentication
- Association
- Disassociation
- Reassociation
- Beaconing
I FullMAC hanno tutte le operazioni MLME (o un sottoinsieme di quelle sopra) eseguite dall'hardware wireless stesso e dal suo firmware. Un vantaggio dei FullMAC è il miglioramento del consumo energetico, critico sui chipset mobili e su altri dispositivi a basso consumo. Offre anche ai vendor un maggiore controllo sulle operazioni eseguibili con il loro hardware. Tuttavia, ha un costo. Le operazioni Wi-Fi sono complesse e lo è anche la loro codebase. Nessuna implementazione è esente da bug.
Per i dispositivi SoftMAC, tutto è implementato nel software del framework del driver. Tutti i driver SoftMAC che usano mac80211 beneficiano di correzioni di sicurezza, miglioramenti e altri bug risolti con il framework. Con le release del kernel Linux o quando una distribuzione Linux rilascia correzioni di sicurezza, tutti i driver SoftMAC vengono aggiornati. I driver FullMAC, d'altra parte, richiedono che i rispettivi vendor rilascino le correzioni.
3.4. Conclusione
In questo modulo abbiamo discusso strumenti wireless, stack e driver. Una comprensione di base di molti dei concetti qui presentati sarà utile nei casi in cui lavoriamo con adattatori sconosciuti o poco cooperativi. Qui abbiamo usato l'Alfa AWUS036AC come esempio e mostrato tutti i diversi modi in cui possiamo trovare il suo chipset e il driver.
Infine, siamo tornati indietro nel tempo ed abbiamo esplorato il sottosistema Linux ieee80211, usato per i driver fino circa all'802.11g/802.11n, e progressivamente sostituito da mac80211. Tutti i nuovi driver del kernel Linux sono sviluppati usando il framework mac80211.
Il framework mac80211 semplifica lo sviluppo dei driver, consentendo correzioni di bug e fornendo nuove funzionalità a tutti i driver contemporaneamente. mac80211 può ora gestire con facilità le tecnologie wireless più recenti e iw ci fornisce un'unica utility per governarle tutte.