Inoltre, l'access point stesso può essere configurato come un server DHCP dal lato wireless, e quindi una stazione mobile può autoconfigurarsi. Notiamo però che l'AP non è equipaggiato con un NAT, e quindi occorrerà impostare degli IP pubblici, oppure appoggiarsi ad un NAT esterno.

---

Associazione di una stazione mobile

Una macchina Linux dispone di alcuni comandi (Wireless tools) per la gestione dei collegamenti wireless, corredati da un prezioso sforzo di documentazione. I comandi che useremo però, sono solo due:

• iwlist: rapporta a riguardo degli access point nei paraggi, dei loro parametri di configurazione, nonché dei parametri ammessi dalla propria scheda wireless;
• iwconfig: permette di configurare i parametri associati ad una scheda di rete wireless, in modo da permetterne il funzionameno con gli AP circostanti

Questi comandi sono stati inseriti in un apposito file di script, che li esegue nella corretta sequenza, e permette un minimo di configurazione manuale. Eccone un esempio:

#!/bin/bash
# questo file ha nome wlan.ipw2200

BOARD=ipw2200                # il nome di convenienza della scheda
WIFACE=eth1                  # il nome dell'interfaccia di rete
ADDR=192.168.120.40          # l'indirizzo IP che intendiamo assegnargli
GW=192.168.120.1             # il default Gateway relativo
ESSID=USR5450                # l'identificativo dell'access point

up () {

 echo attivazione di $BOARD su $WIFACE
 modprobe -r ipw2200
 echo "per sicurezza ho prima rimosso il modulo ipw2200"
 sleep 2
 modprobe ipw2200
 echo "ora l'ho rimesso"

 iwconfig                           # verifica che interfaccia sia riconosciuta e funzionante
 iwlist $WIFACE scanning            # verifica di ricevere AP 
 iwconfig $WIFACE mode Managed      # configura il driver per il tipo di rete
 iwconfig $WIFACE essid $ESSID      # ed il suo identificativo
 ip addr add $ADDR/24 dev $WIFACE   # assegna indirizzo IP e Netmask
 ip link set $WIFACE up             # abilita l'interfaccia
 ip addr                            # vediamo se tutto e' andato bene
 ip route del default               # reimposta la default route
 ip route add default via $GW
 ip route                           # tutto bene ?
 return
}

down () {
 echo disattivazione di $BOARD su $WIFACE

 ip link set dev $WIFACE down
 ip link

 return
}

echo "Scheda $BOARD su interfaccia $WIFACE,"
echo "con IP $ADDR e default gateway $GW, verso"
echo "l'accesspoint USR con essid $ESSID, senza WEP."

case "$1" in
  up)
    up
    ;;
  down)
    down
    ;;
  *)
    echo "usage $0 up | down"
    exit 1
esac

exit

Questo script, una volta reso eseguibile con il comando chmod 755 wlan.ipw2200 e lanciato da root, accetta le opzioni up o down, e dopo aver rimosso e reinserito il modulo del chipset wireless (in modo da resettarlo completamente) provvede a far associare l'interfaccia al nostro  access point. Allo scopo di monitorare ciò che succede dietro le quinte, possimo configurare una seconda interaccia di rete wireless in  modalità monitor.

---

Stato delle connessioni

Sempre in Linux, esiste un filesystem virtuale, /proc, i cui contenuti sono generati al volo dal kernel, e che costituisce un pratico mezzo per raccogliere informazioni sul sistema. Nel caso del wireless, le informazioni sono mostrate visualizzando /proc/net/wireless, che mostra ad esempio:

root@alef-laptop:~# cat /proc/net/wireless
Inter-| sta-|   Quality        |   Discarded packets               | Missed | WE
 face | tus | link level noise |  nwid  crypt   frag  retry   misc | beacon | 20
  eth1: 0000   88.  -41.  -86.       0      0      0      0      4        0
  eth2: 021f   82.  -55.  -100.      6      0      0      0  13752        9
 wifi0: 021f   82.  -55.  -100.      6      0      0      0  13752        9

in cui il numero di pacchetti scartati, dà un idea della qualità del collegamento, così come il numero Quality Link, mentre Quality Level, è relativo alla forza del segnale ricevuto. In particolare, notiamo l'esistenza di ben 3 interfacce di rete, di cui solo due reali, eth1 ed eth2, mentre wifi0 è un alias della interfaccia di eth2, configurata in modo da permettere la cattura del traffico.

---

Analisi del traffico

I driver (o moduli, nel gergo Linux) di alcuni chipset wireless, permettono di configurare gli stessi in modalità monitor, in modo tale cioè che non funzionino più come interfacce di rete, ma permettano ad una applicazione di monitorare il traffico radio che viene ricevuto. In tal modo, Ethereal viene messo in grado di sniffare anche i protocolli di strato di collegamento, che normalmente si svolgono tutti tra l'interfaccia e l'AP, senza notificare nulla agli strati superiori.

Il sito di wireshark racconta di come sniffare il traffico radio, presso http://www.wireshark.org/faq.html#q10.1, e fa notare come, in linea generale, il driver debba essere messo in modalità monitor, che provoca la perdita del traffico normale. Presso il wiki viene approfondito molto bene il tema della cattura di pacchetti 802.11, e sono riportate le modalità di cattura per i diversi adattatori di rete. Il setup sperimentale che è stato usato per produrre i file di capture allegati a questa sezione, equipaggia un portatile Linux con due interfacce di rete, che corrispondono a eth1 ed eth2: la prima, è quella integrata nella scheda madre, mentre la seconda, è aggiunta in uno slot pcmcia. A queste due interfacce fisiche, ne vengono affiancate altre due virtuali, rispettivamente rtap0 e wifi0, come illustrato sotto.

interfaccia	indirizzo MAC note Wireshark	modulo kernel	standard	modalità monitor
eth1	00:16:6f:54:3b:a5 Intel/Centrino	ipw2200	802.11b/g	iwconfig eth1 mode monitor
rtap0		aggiungere nel file e quindi eseguire		options ipw2200 rtap_iface=1 /etc/modprobe.d/ipw2200 ip link set dev rtap0 up
eth2	00:11:20:a1:43:10 Cisco/Aironet	airo	802.11b
wifi0		eseguire e quindi		echo "Mode: y" >/proc/driver/aironet/eth2/Config ip link set dev wifi0 up
Access Point	00:c0:49:60:41:9e USRobotics		802.11b/g

Con i comandi riassunti in tabella, se eth1 è posta in modalità monitor, questa cessa di funzionare come interfaccia di rete, e riesce solo a catturare in modo passivo il traffico radio che vede. Allo stesso tempo però, è in grado di riportare allo strato applicativo il contenuto degli header radiotap, che informano a riguardo di parametri relativi al funzionamento dello strato fisico. In alternativa, eth1 può essere mantenuta operativa come interfaccia di rete (iwconfig eth1 mode managed), e può essere creato (in accordo alle istruzioni nella seconda riga) un suo alias indicato come rtap0, in grado di permettere il capture completo di intestazioni 802.11. Sembrerebbe la migliore delle soluzioni possibili, tranne che... in questa configurazione, non siamo riusciti a catturare il traffico di gestione che passa da eth1 :-(

Si è quindi optato per usare eth1 in una modalità di funzionamento normale, e di usare eth2 per catturare il traffico sviluppato con eth1. A tal fine, si sono immessi i comandi indicati nella terza riga, così come appaiono nel wiki di wireshark, di fatto disabilitando eth2, e creado al contempo una sua interfaccia-alias, wifi0, mediante la quale ci si può porre in ascolto del traffico in aria.

Catturando ora il segnale radio in assenza di attività da parte delle stazioni mobili, possiamo osservare le trame di gestione trasmesse dall'Access Point, inviate in broadcast con il periodo specificato come Beacon Interval:


provando ad aprirne uno, troviamo le seguenti informazioni, che possiamo interpretare ricordando la struttura della sotto-trama MAC:

Tralasciando la discussione sui campi indirizzo, notiamo come la parte dati sia divisa in parametri fissi e tagged (etichettati): il tipo, numero ed ordine dei primi è fisso, ed è legato al tipo/sottotipo della trama di gestione; ognuno dei secondi invece e' suddiviso nei tre campi Numero, Lunghezza e Valore, e possono essere presenti o meno in qualsiasi ordine, permettendo di estendere il protocollo, anche con tecnologie proprietarie.

In questa fase, i parametri importanti sono le velocità supportate, l'uso di crittografia WEP, le opzioni di modulazione, ed il SSID, ossia l'identità dell'Extended Service Set (ESS), che permette di distinguere un Access Point da un altro, ovvero un insieme di AP, gestiti dalla stessa organizzazione. La trasmissione del Beacon può essere disabilitata rendendo più difficile aderire alla rete Wireless, senza conoscerne il SSID.

---

Autenticazione ed associazione

Mantenendo attivo lo sniffing, possiamo osservare cosa accade quando una nuova stazione si attiva. Inseriamo la seconda interfaccia di rete, ed eseguendo lo script wlan.ipw2200, si ottiene:

No. Time        Source                Destination           Protocol Info
387 24.634576   USRoboti_60:41:9e     Broadcast             IEEE 802.11 Beacon frame, SSID: "USR5450"
388 24.698612   3comEuro_aa:07:3d     Broadcast             IEEE 802.11 Probe Request, SSID: "USR5450"
389 24.699260   USRoboti_60:41:9e     3comEuro_aa:07:3d     IEEE 802.11 Probe Response, SSID: "USR5450"
397 25.014964   3comEuro_aa:07:3d     USRoboti_60:41:9e     IEEE 802.11 Authentication
398 25.015747   USRoboti_60:41:9e     3comEuro_aa:07:3d     IEEE 802.11 Authentication
399 25.016822   3comEuro_aa:07:3d     USRoboti_60:41:9e     IEEE 802.11 Association Request, SSID: "USR5450"
400 25.018777   USRoboti_60:41:9e     3comEuro_aa:07:3d     IEEE 802.11 Association Response

In pratica, in corrispondenza al comando iwconfig $WIFACE essid $ESSID, la scheda invia un Probe Request (388) per il SSID impostato, e di cui mostriamo i campi salienti:

    Type/Subtype: Probe Request (4)
        Tag Number: 0 (SSID parameter set)
        Tag length: 7
        Tag interpretation: USR5450
        Tag Number: 1 (Supported Rates)
        Tag length: 4
        Tag interpretation: Supported rates: 1,0 2,0 5,5 11,0 [Mbit/sec]
        Tag Number: 50 (Extended Supported Rates)
        Tag length: 8
        Tag interpretation: Supported rates: 6,0 9,0 12,0 18,0 24,0 36,0 48,0 54,0 [Mbit/sec]

come si vede, essendo la scheda una 802.11g, annuncia anche il supporto di velocità più elevate.
Quindi, dopo un Probe Response (389) che non è molto di diverso dal Beacon, la stazione 3com tenta di effettuare il join (397) verso l'AP, mediante il messaggio di Authentication, di cui sono riportati i tratti salienti:

 Type/Subtype: Authentication (11)
 Type: Management frame (0)
        Subtype: 11
    Fixed parameters (6 bytes)
        Authentication Algorithm: Open System (0)
        Authentication SEQ: 0x0001
        Status code: Successful (0x0000)

Il contenuto della risposta (398) non è molto differente; il termine Open System significa che non è attiva nessuna forma di crittografia, e quindi l'AP accetta tutti. Esaurita questa fase, la stazione procede con una richiesta di associazione (399) verso l'AP, in cui si comunica il valore di Listen Interval, che rappresenta ogni quanti Beacon la stazione si risveglierà dallo stato di Power Save, e consente all'AP di valutare le sue capacità di memorizzazione:

    Type/Subtype: Association Request (0)
    Frame Control: 0x0000 (Normal)
    Fixed parameters (4 bytes)
        Capability Information: 0x0421
        Listen Interval: 0x0001

A questo fa seguito la relativa risposta di Association Response, in cui l'AP comunica le modalità di trasmissione seguenti:

    Type/Subtype: Association Response (1)
    Frame Control: 0x0010 (Normal)
        Version: 0
        Type: Management frame (0)
        Subtype: 1
        Flags: 0x0
    Fixed parameters (6 bytes)
        Capability Information: 0x0001
            .... .... .... ...1 = ESS capabilities: Transmitter is an AP
            .... .... .... ..0. = IBSS status: Transmitter belongs to a BSS
            .... .... .... 00.. = CFP participation capabilities: No point coordinator at AP (0x0000)
            .... .... ...0 .... = Privacy: AP/STA cannot support WEP
            .... .... ..0. .... = Short Preamble: Short preamble not allowed
            .... .... .0.. .... = PBCC: PBCC modulation not allowed
            .... .... 0... .... = Channel Agility: Channel agility not in use
            .... .0.. .... .... = Short Slot Time: Short slot time not in use
            ..0. .... .... .... = DSSS-OFDM: DSSS-OFDM modulation not allowed
        Status code: Successful (0x0000)
        Association ID: 0x0002
    Tagged parameters (14 bytes)
        Tag Number: 1 (Supported Rates)
        Tag length: 4
        Tag interpretation: Supported rates: 1,0(B) 2,0(B) 5,5(B) 11,0(B) [Mbit/sec]
        Tag Number: 221 (Vendor Specific)
        Tag length: 6
        Tag interpretation: Not interpreted

L'esito positivo dell'associazione è codificato nello Status code, che potrebbe essere negativo, se l'AP ha accettato richieste da un numero già elevato di stazioni. Inoltre, mediante l'Association ID (AID), l'AP distingue le stazioni le une dalle altre, ad esempio nell'ambito nella tabella TIM (mentre il DTIM è associato all'AID pari a zero).

Per verificare personalmente ciò che accade, nel file assoc-cent.pcap possiamo trovare il risultato della cattura della associazione tra eth1 ed AP, mentre in assoc-airo.pcap, l'associazione di eth2, completa degli header radiotap.

---

Sicurezza

Oltre a poter omettere la trasmissione dei frame Beacon che pubblicano l'SSID, esiste la possibilità di configurare in modo statico gli indirizzi MAC che possono chiedere l'associazione all'AP.


Il primo caso però depriva l'architettura di alcune sue funzionalità, mentre il secondo è inapplicabile ai siti più frequentati. Nello standard emesso nel 1999, si è introdotto un metodo di cifratura noto come Wired Equivalent Privacy (WEP), che si basa su di una Secret Key di 40 bit (5 byte), nota sia all'AP che a tutte le stazioni, a cui si aggiunge un Initialization Vector (IV) di 24 bit (3 byte), che può cambiare anche per tutte le trame. Il Seed risultante di 64 bit, viene fornito in ingresso ad un algoritmo Pseudo Random Number Generator (PRNG) (che poi è l'RC4 di RSA), e la risultante Key Sequence pseudo-casuale è posta in ex-OR con i dati da trasmettere nella trama, a cui è stato aggiunto  un Integrity Check Value (ICV) che ne attesta appunto l'integrità, calcolato con un algoritmo di checksum CRC-32.

---

Letture ulteriori

• Tom's Hardware guide: recensione USR5450,  Tim Higgins
• Recipe for a Linux 802.11b Home Network, Schuyler Erle
• 802.11 standard , IEEE, 
• Wired Equivalent Privacy, WiKiPedia GNU FDL
• The Unofficial 802.11 Security Web Page, Bernard Aboba, [local]
• Wireless (in)security: (in)sicurezza dell'802.11, Fabio (naif) Pietrosanti - Yvette (vodka) Agostini