Gera¸c˜ao do Arquivo de Registros de Ataques

O arquivo de registros de ataques foi criado baseando-se tanto nas caracter´ısticas que definem cada ataque, quanto nas caracter´ısticas observadas no tr´afego captu- rado na rede wireless.

Na implementa¸c˜ao deste trabalho trˆes ataques de DoS, bastante conhecidos em redes wireless, foram considerados:

• Ataque Virtual Carrier Sense;

• Ataque Association Flood ;

• Ataque De-authentication.

4.5.1

Ataque Virtual Carrier Sense

O mecanismo de virtual carrier sense ´e usado para atenuar colis˜oes com terminais escondidos. Ele pode ser visualizado na Figura 4.10. Nesse mecanismo, cada qua- dro 802.11 carrega um campo de dura¸c˜ao que indica o n´umero de microsegundos que o canal est´a reservado. Esse valor ´e usado para programar o NAV (Network Allocation Vector ) em cada esta¸c˜ao. Somente quando o NAV da esta¸c˜ao alcan¸ca zero, ´e que ela tem permiss˜ao para transmitir novos dados. Esse recurso ´e usado principalmente pelo handshake RTS (Request To Send ) / CTS (Clear To Send ), que serve para sincronizar o acesso ao canal quando um terminal escondido estiver interferindo com a transmiss˜ao. Durante esse handshake, a esta¸c˜ao transmissora

envia um quadro RTS, que inclui uma dura¸c˜ao grande o suficiente para comple- tar toda a seq¨uˆencia RTS/CTS (incluindo o quadro CTS, o quadro de dados e o quadro subseq¨uente de acknowledgment). A esta¸c˜ao de destino responde ao RTS com um CTS, contendo um campo de dura¸c˜ao atualizado em rela¸c˜ao ao tempo j´a decorrido durante a seq¨uˆencia. Ap´os o CTS ser enviado, cada n´o na extens˜ao de r´adio, tanto da esta¸c˜ao transmissora quanto da esta¸c˜ao receptora, vai ter atualizado seu NAV e vai reter todas as suas transmiss˜oes pela dura¸c˜ao da transmiss˜ao que est´a ocorrendo. Embora o recurso RTS/CTS seja raramente usado na pr´atica, respeitar a fun¸c˜ao de virtual carrier sense indicada pelo campo de dura¸c˜ao ´e obrigat´orio em todas as implementa¸c˜oes do padr˜ao 802.11.

Figura 4.10: Mecanismo Virtual Carrier Sense.

Um atacante pode explorar o mecanismo de virtual carrier sense informando um campo de dura¸c˜ao muito grande, prevenindo desse modo as demais esta¸c˜oes de obter acesso ao canal (Bellardo and Savage, 2003 ). Isso pode ser visualizado atrav´es da Figura 4.11. O valor m´aximo para o NAV ´e 32767, ou aproximadamente 32 milisegundos em redes 802.11b. Assim, em princ´ıpio o atacante somente precisa transmitir aproximadamente 30 vezes por segundo, para obstruir todo o acesso ao canal.

Mesmo sendo poss´ıvel usar quase qualquer tipo de frame para controlar o NAV, incluindo o pr´oprio ACK, o uso do RTS apresenta algumas vantagens. Visto que uma esta¸c˜ao com um comportamento correto vai sempre responder a um RTS com um CTS, o atacante pode fazer com as demais esta¸c˜oes propaguem o ataque al´em do que ele poderia propagar sozinho. Disparando esse ataque repetidas

Figura 4.11: Ataque Virtual Carrier Sense.

vezes, o atacante pode causar uma degrada¸c˜ao percept´ıvel na performance da rede, resultando em um ataque de nega¸c˜ao de servi¸co.

Os registros do ataque virtual carrier sense foram montados de acordo com a Tabela 4.2. Nesses registros, os campos determinantes para a ocorrˆencia do ataque s˜ao: RTS (Request To Send ), CTS (Clear To Send ), CTRL (n´umero de frames do tipo Control ), DURAC (dura¸c˜ao acumulada de todos os frames) e STATUS (status do registro).

Tabela 4.2: Forma¸c˜ao dos Registros do Ataque Virtual Carrier Sense.

RTS CTS CTRL DURAC STATUS

De 50 a 70 Igual a RTS RTS + CTS CTRL * 32767 1

Se para obstruir o acesso ao canal, o atacante precisa transmitir aproximada- mente 30 vezes por segundo, em 2 segundos s˜ao necess´arias aproximadamente 60 transmiss˜oes. Acrescentando a esse valor uma tolerˆancia de 10 quadros para mais e para menos, estabeleceu-se que o campo RTS deve variar entre 50 e 70. Para cada quadro RTS transmitido, um quadro CTS deve ser recebido. O n´umero de quadros CTRL deve ser igual `a soma entre o n´umero de quadros RTS e o n´umero de quadros CTS. O campo DURAC deve ser igual ao n´umero de quadros CTRL multiplicado por 32767, que ´e a dura¸c˜ao m´axima permitida em cada quadro. O campo STATUS deve ser igual a 1 para indicar a ocorrˆencia de um ataque.

4.5.2

Ataque Association Flood

Quando uma esta¸c˜ao se associa a um ponto de acesso, este libera um AID (As- sociate Identification) para a esta¸c˜ao na faixa entre 1 e 2007. Esse valor ´e usado para comunicar informa¸c˜oes de gerenciamento de energia para a esta¸c˜ao, quando a mesma estiver em estado “power save”. O ataque association flood ´e execu- tado atrav´es do envio de m´ultiplas requisi¸c˜oes de autentica¸c˜ao e associa¸c˜ao para o ponto de acesso, todas com apenas um endere¸co MAC fonte (Curran and Smyth, 2006 ). O ponto de acesso ´e incapaz de diferenciar as requisi¸c˜oes de autentica¸c˜ao geradas por um atacante, das criadas por clientes leg´ıtimos da rede, desse modo ´e for¸cado a processar cada requisi¸c˜ao. Eventualmente, o ponto de acesso vai esgotar seus AIDs para aloca¸c˜ao e vai ser for¸cado a desassociar esta¸c˜oes, para poder usar AIDs j´a alocados. Na pr´atica, v´arios pontos de acesso v˜ao reiniciar ap´os alguns minutos de inunda¸c˜ao. Entretanto, esse ataque ´e bastante eficaz para derrubar segmentos de rede ou at´e mesmo redes inteiras.

Os registros do ataque association flood foram divididos em duas categorias: registros com grande n´umero de quadros de requisi¸c˜ao de autentica¸c˜ao e registros com grande n´umero de quadros de requisi¸c˜ao de associa¸c˜ao. Em todos os registros, os campos determinantes para a ocorrˆencia do ataque s˜ao: AUTHEN (Authenti- cation), PRORES (Probe Response), ASSREQ (Association Request), MANAGE (n´umero de quadros do tipo Management) e STATUS (status do registro).

Os registros com grande n´umero de quadros de requisi¸c˜ao de autentica¸c˜ao foram montados de acordo com a Tabela 4.3.

Tabela 4.3: Forma¸c˜ao dos Registros do Ataque Association Flood - Tipo A.

AUTHEN PRORES ASSREQ MANAGE STATUS

De 50 a 70 De 29 a 31 De 29 a 31 AUTHEN + PRORES + ASSREQ 1

O campo AUTHEN deve variar entre 50 e 70. Os campos PRORES e ASSREQ devem variar entre 29 e 31, pois se verificou dos dados capturados na rede que, sempre que h´a um grande n´umero de quadros de requisi¸c˜ao de autentica¸c˜ao na rede, h´a tamb´em um n´umero consider´avel de quadros de resposta de probing e de requisi¸c˜ao de associa¸c˜ao. O n´umero de quadros MANAGE deve ser igual `a soma entre o n´umero de quadros AUTHEN, o n´umero de quadros PRORES e o

n´umero de quadros ASSREQ. O campo STATUS deve ser igual a 1, para indicar a ocorrˆencia do ataque.

Os registros com grande n´umero de quadros de requisi¸c˜ao de associa¸c˜ao foram montados de acordo com a Tabela 4.4.

Tabela 4.4: Forma¸c˜ao dos Registros do Ataque Association Flood - Tipo B.

ASSREQ PRORES AUTHEN MANAGE STATUS

De 50 a 70 De 29 a 31 De 29 a 31 ASSREQ + PRORES + AUTHEN 1

O campo ASSREQ deve variar entre 50 e 70. Os campos PRORES e AUTHEN devem variar entre 29 e 31, pois se verificou dos dados capturados na rede que, sempre que h´a um grande n´umero de quadros de requisi¸c˜ao de associa¸c˜ao na rede, h´a tamb´em um n´umero consider´avel de quadros de resposta de probing e de requisi¸c˜ao de autentica¸c˜ao. O n´umero de quadros MANAGE deve ser igual `a soma entre o n´umero de quadros ASSREQ, o n´umero de quadros PRORES e o n´umero de quadros AUTHEN. O campo STATUS deve ser igual a 1, para indicar a ocorrˆencia do ataque.

4.5.3

Ataque De-Authentication

Ap´os uma esta¸c˜ao cliente ter selecionado um ponto de acesso para se comunicar, ela deve primeiramente se autenticar junto ao mesmo antes que qualquer comu- nica¸c˜ao possa ocorrer. O framework de autentica¸c˜ao do padr˜ao 802.11 possui tamb´em uma mensagem que permite que clientes e pontos de acesso requisitem explicitamente a sua desautentica¸c˜ao m´utua. Infelizmente, essa mensagem n˜ao ´e autenticada usando nenhum tipo de criptografia. Consequentemente, o atacante pode falsific´a-la, tentando se passar pelo ponto de acesso ou mesmo pelo cliente, e direcion´a-la para a outra parte, conforme pode ser visualizado atrav´es da Figura 4.12. Em resposta, o ponto de acesso ou o cliente vai sair do estado autenticado e vai rejeitar todos os pacotes seguintes, at´e que a autentica¸c˜ao seja restabele- cida (Bellardo and Savage, 2003 ). Com a repeti¸c˜ao persistente desse ataque, um cliente pode ser privado de transmitir ou receber seus dados indefinidamente.

Os registros do ataque de-authentication foram montados de acordo com a Tabela 4.5. Nesses registros, os campos determinantes para a ocorrˆencia do ata-

Figura 4.12: Ataque De-authentication.

que s˜ao DEAUTH (Deauthentication), MANAGE (n´umero de quadros do tipo Management) e STATUS (status do registro).

Tabela 4.5: Forma¸c˜ao dos Registros do Ataque De-authentication.

DEAUTH MANAGE STATUS De 40 a 80 Igual a DEAUTH 1

O campo DEAUTH deve variar entre 40 e 80. O n´umero de quadros MANAGE deve ser igual ao n´umero de quadros DEAUTH. O campo STATUS deve ser igual a 1, para indicar a ocorrˆencia do ataque.