1
Utilização de OpenFlow em um Mecanismo de Mitigação de Ataques
DDoS
Gabriele Gayer Ramires1
Rafael Bohrer Ávila2
Resumo: Com o avanço da tecnologia e o desenvolvimento progressivo de novas
aplicações e protocolos, nota-se a ausência de um ambiente confiável para testar
essas novas tecnologias. O OpenFlow como outras tecnologias de Redes Definidas
por Software supre essa carência, pois permite a customização, diferenciando-se de
uma rede normal e permitindo a flexibilidade de experimentos. Outra análise a ser
feita é a confiabilidade das respostas nos experimentos realizados, onde são
esperadas respostas precisas para manter o nível de qualidade do desenvolvimento.
Este trabalho tem o objetivo de adaptar mecanismos usados no sistema D-Ward(
sistema de defesa DDoS implantado na rede local) na plataforma OpenFlow.
Utilizando esta plataforma para fazer a coleta de dados e bloqueio do ataque DDoS.
Com essa junção pretende-se mitigar os ataques DDoS dentro de uma rede
OpenFlow, obtendo também um nível bom para tráfego legítimo.
Palavras-Chave: Protocolo OpenFlow. D-Ward. Mitigação.
1 INTRODUÇÃO
A popularização da Internet durante a última década apresentou um aumento
na procura de serviços on-line, como compras, acesso a serviços bancários, busca
por vagas de emprego, dentre outras facilidades. Esse cenário trouxe como
consequência uma série de problemas de segurança, sendo um desses o ataque
distribuído de negação de serviço DDoS (Distributed Denial of Service) (
MENEGAZZO, 2011).
O ataque DDoS baseia-se na exploração massiva de serviços expostos na
rede através do envio de uma grande quantidade de pacotes para um alvo
específico, como um servidor web de aplicação ou de arquivos. Esse tipo de ataque
é feito de forma coordenada a partir de várias origens e interrompe ou causa
intermitência no acesso aos serviços disponibilizados pelo servidor (BRAGA , 2010).
Embora os ataques distribuídos de negação de serviço não sejam um fenômeno
1
2
Gabriele Gayer Ramires, aluna do curso de Ciência da Computação, [email protected].
Rafael Bohrer Ávila, professor da Universidade do Vale do Rio dos Sinos, [email protected].
2
recente, os métodos e os recursos disponíveis para conduzir e mascarar esses
ataques tem evoluído.
Na busca por novas formas para investigar e analisar ataques DDoS, bem
como para executar experimentos de soluções para a detecção desses ataques,
surge a possibilidade de adotar uma das tecnologias que tem como base o SDN
(Redes Definidas por Software) conhecida como OpenFlow (BRAGA, 2010). Essa
possibilidade se dá pelo fato de o OpenFlow prover uma interface aberta e
programável, a qual permite estabelecer um controle sobre os fluxos de pacotes nos
switches e roteadores de uma rede. Através desse controle é possível, por exemplo,
conduzir experimentos com novos protocolos, modelos de segurança e/ou
esquemas de endereçamento. (MCKEOWN, 2008).
Além de possibilitar a realização de novos experimentos, a plataforma
OpenFlow insere no mercado de tecnologia um formato diferente de rede, capaz de
oferecer segurança, estabilidade e confiabilidade. Assim sendo, esse formato torna o
OpenFlow uma plataforma importante para busca e integração de novas ideias e
métodos capazes de contribuir com a evolução e a otimização da segurança nas
redes (MCKEOWN, 2008).
Após pesquisas realizadas na literatura da área de segurança em redes,
foram analisados detalhadamente dois artigos. O primeiro é o D-Ward (MIRKOVIC,
2002) que utiliza como ponto de análise a origem da rede (LAN) para detectar
ataques. Nesse caso, são geradas estatísticas de fluxos através dos registros
armazenados, que são então comparados a modelos pré-definidos. O segundo
artigo mostra uma opção de como detectar ataques DDoS em uma rede OpenFlow
(BRAGA et. al , 2010). Neste trabalho a análise para detecção de ataques DDoS é
feita na entrada da rede (WAN) e utiliza redes neurais para classificação dos fluxos
de ataque.
Analisando detalhadamente os dois artigos, observa-se que no trabalho
D-Ward (MIRKOVIC, 2002) o uso da detecção na origem da rede (LAN), como relata
o autor, pode facilitar o rastreamento e investigação do ataque, pois o fluxo de dados
tende a ser menos intenso e mais passível de controle por estar em uma rede local
(LAN). Por outro lado, foram analisados dois problemas um por não ser muito fácil
ou prático coletar estatísticas dos roteadores. Usar uma ferramenta de gerência
seria uma alternativa, mas alguns parâmetros como o número de sessões como
3
usado no D-Ward não são diretamente observáveis nestas ferramentas. E o
segundo, uma vez detectado um ataque, é necessária uma forma de atuar sobre ele,
bloqueando-o ou reduzindo o fluxo de dados. Não há um padrão geral para realizar
tal ação em roteadores, portanto a solução sempre dependeria do fabricante do
equipamento.
Com ideias extraídas dos dois artigos este trabalho pretende obter um
método de detecção de ataques DDoS na origem da rede, utilizando a plataforma
OpenFlow para resolver as duas dificuldades apresentadas pelo D-Ward,
fornecendo meios tanto para coletar os dados, de forma bastante flexível, quanto
para atuar sobre o tráfego da rede local.
Estes dados são armazenados para geração de estatísticas que comparadas
às características pré-definidas identificam prováveis fluxos de ataques DDoS.
Dessa forma, o OpenFlow pode atuar no controle e gerenciamento desta rede
melhorando a segurança no fluxo de dados de produção como em testes e
simulações de novos protocolos.
2 OPENFLOW
OpenFlow é um padrão aberto de comunicação que possibilita gerenciar
pacotes que circulam na rede. Apoia-se no conceito de redes definidas por software
(SDN) como uma interface de programação de aplicativos que definem o
comportamento do encaminhamento dos pacotes através dos fluxos estabelecidos
(MCKEOWN, 2008).
Através
desta
inovação,
pesquisadores
podem
testar
protocolos
experimentais em redes de produção, redes metropolitanas e em backbones de
redes de ensino e pesquisa (MCKEOWN, 2008). Tendo como base a característica
de um padrão aberto para comunicação, que o OpenFlow oferece é possível testar,
avaliar e modificar vários protocolos e cenários de testes, pondo à prova a eficácia
de novos protocolos em um cenário real.
Nas redes convencionais o encaminhamento de pacotes é tratado por
roteadores e switches e não há garantias de que testes sejam realizados sem
interferência no fluxo de produção. Com a plataforma OpenFlow existe esta
possibilidade garantida através da tabela de fluxo para controle de tráfego que o
4
Figura 1 - Arquitetura de Fluxo na Plataforma OpenFlow
Fonte: Elaborada pela Autora (2013).
switch com a plataforma OpenFlow possui e o gerenciamento dos pacotes
que pode ser realizado pelo elemento chamado controlador.
O switch OpenFlow possui uma tabela onde estão armazenados todos os
fluxos de pacotes que estão circulando na rede no momento .
O controlador possui a capacidade de avaliar os fluxos, além de remover e
criar novas entradas de fluxos na tabela para redirecionar os pacotes que chegam
no switch OpenFlow. (MCKEOWN, 2008). Esta comunicação com o switch é feita
através de um canal seguro que utiliza o protocolo TLS (Transport Layer Security),
garantindo assim que qualquer comunicação entre os dois componentes seja
criptografada (OPENFLOW, 2011).
Cada uma dessas entradas da tabela consiste nos seguintes campos que
estão ilustrados na figura 1:
1. Campo para o cabeçalho do pacote que define o fluxo;
2. Campo para a ação que define como o pacote é tratado;
3. Campo para as estatísticas que mantém o controle do número de pacotes e
bytes de cada fluxo, além do tempo decorrido desde que o último pacote do fluxo
5
que foi identificado pelo switch. Essa última estatística auxilia na remoção de fluxos
inativos (MCKEOWN, 2008).
2.1 CONTROLADOR
O controlador exerce a função de gerenciamento das entradas de fluxos na
rede. É ele que divide a rede entre experimentos, adicionando e removendo
entradas de fluxos. Se comparado com uma rede comum, ele funciona como uma
VLAN. Dessa forma, o controlador atua como uma espécie de sistema operacional
(SO) para o gerenciamento e controle de redes, oferecendo uma plataforma com
base na reutilização de componentes e na definição de níveis de abstração
(comandos da API). Um controlador mais sofisticado poderia beneficiar vários
pesquisadores ao mesmo tempo com diferentes contas e permissões, executando
assim múltiplos experimentos com diferentes tipos de fluxos.
Existem três eventos críticos previstos pelo controlador: a chegada de um
pacote, a inicialização de um fluxo e uma mudança na rede. Com isso a
escalabilidade se torna um fator importante para o controlador potencializado pelo
fato de se tratar de um sistema centralizado.
O controlador também pode ser configurado para tratar outros possíveis
eventos na rede como quedas de links, inclusões e exclusões de hosts, alterações
de fluxos, entre outros eventos que ainda possam ser tratados pelo controlador.
Com base em uma rede constituída de switches, computadores e serviços
como HTTP ou FTP, o controlador coleta dados que podem ser usados nas tomadas
de decisões pelas aplicações de gerenciamento. Assim o tráfego da rede é
controlado e gerenciado pelo controlador que tem o poder de alterar as
configurações dos switches OpenFlow.
Esse controle é realizado em nível de fluxo, ou seja, uma determinada ação
de controle é aplicada ao primeiro pacote de um fluxo, sendo então replicada a todos
os outros pacotes nesse fluxo (SHERWOOD, 2009)
Ao receber um pacote o controlador deve tomar uma decisão e enviar a
requisição de mudança na tabela de fluxos do switch OpenFlow. Se a entrada for
equivalente à tabela de fluxo, as instruções associadas com a entrada do fluxo
especificado são executadas. Caso a entrada não for equivalente, o resultado
6
Figura 2 - Mecanismo do Switch OpenFlow
Fonte: Adaptado de MCKEOWN (2008)
depende da configuração que o controlador irá adicionar na tabela do switch
OpenFlow, podendo ser rejeitado ou continuar na próxima tabela de fluxo
(MCKEOW, 2008). Dependendo da aplicação, o controlador pode ou não adicionar
essa entrada, forçando que os switches sempre enviem os pacotes recebidos
para o controlador. A Figura 2 apresenta a parte interna do switch OpenFlow.
3 TRABALHOS RELACIONADOS
Serão apresentados nesta seção alguns métodos que auxiliam na mitigação
de ataques DDoS dentro de redes públicas e de redes que utilizam o protocolo
OpenFlow. Esses métodos relacionam-se com o presente trabalho quanto à
abordagem adotada. Cada trabalho aborda aplicações e características diferentes,
porém todos com a finalidade de proporcionar maior segurança dentro de uma rede.
A partir das pesquisas realizadas a respeito de DDoS e OpenFlow, analisouse uma forma de implementar o OpenFlow na origem da rede(LAN), aproveitando
características de classificação de fluxos fundamentadas nos dois artigos estudados.
7
3.1 ATTACKING DDOS AT SOURCE
O D-Ward (MIRKOVIC, 2002) é um sistema que traz uma proposta diferente
para minimizar ataques DDoS. Enquanto os demais mecanismos de defesa atacam
o problema no alvo que sofre o ataque, o D-Ward apresenta uma estratégia que
busca fazer a detecção de ataques a partir de sua origem em uma rede local. A
proposta do D-Ward concentra-se no monitoramento de fluxos de saída da rede
local do roteador de borda (LAN do roteador), detectando fluxos atacantes e
diminuindo suas taxas de transmissão e recepção até que não se observe mais o
padrão de ataque.
O tipo de defesa implementada no D-Ward serviu como base para vários
artigos, alguns deles como Deployment of Distributed Defense against DDoS
Attacks in ISP Domain que propõem a implementação de forma incremental pela
internet e o artigo Simulation Study of Flood Attacking of DDOS que verifica o mau
uso e a detecção de anomalias na rede local.
3.1.1 Arquitetura do Sistema
O sistema D-Ward encapsula dois componentes importantes para o seu
funcionamento. Esses componentes que analisam e definem como serão tratados os
fluxos de pacotes que trafegam pelo roteador onde o sistema está interagindo.
A Figura 3 representa a arquitetura que é composta de um Componente de
Observação e um Componente de ajuste, conforme descrição apresentada a seguir.
3.1.2 Componente de Observação
Responsável por monitorar todos os pacotes que circulam pelo roteador de
borda ligado à rede local. Esse monitoramento é feito com o auxílio da libpcap, que
coleta as informações de todos os pacotes a fim de detectar anomalias, como a
redução no número de pacotes de resposta ou intervalos longos entre uma
requisição e sua respectiva resposta. Esses dados são analisados conforme os
registros de fluxos armazenados na tabela hash.
Estes registros contêm:
8
Pares de hosts: host e porta de origem e host e porta de destino;
Protocolo (TCP, UDP e ICMP);
Número de pacotes enviados e recebidos de uma sessão em um
intervalo de tempo;
Número de bytes enviados e recebidos de uma sessão em um intervalo
de tempo;
Figura 3 - Arquitetura D-Ward
Fonte: Adaptado de MIRKOVI’C (2005)
Número de sessões ativas;
Os dados descritos acima formam então as informações e estatísticas dos
fluxos na rede e são extraídos em intervalos regulares de tempo para serem
analisados. O componente de observação classifica os fluxos comparando as
9
estatísticas geradas com os modelos pré-definidos. Estes modelos são descritos a
seguir:
Modelo
de Tráfego normal TCP:
durante
sessões
TCP são
estabelecidas conexões entre o host origem e o host destino. O fluxo
de dados desta conexão é controlado pela troca de mensagens que
ocorre entre ambos e através das estatísticas geradas dessas trocas
de mensagens que é definido pelo limiar do modelo TCP. Então é
determinado o TCPrto, como sendo a razão máxima permitida de
pacotes enviados e recebidos dentro de uma conexão TCP. O fluxo é
classificado como um ataque caso o TCPrto esteja acima do limiar.
Caso contrário, é considerado um fluxo normal.
Modelo de Tráfego normal ICMP: o protocolo ICMP especifica tipos
diferentes de mensagens. Durante um fluxo normal são geradas
mensagens de requisições timestamp, "pedido de informações" e
"mensagens echo", que recebem as suas respectivas respostas. A
partir destes dados são geradas estatísticas para analisar a frequência
dessas mensagens que definem o limiar deste modelo.
Utilizando esta definição, é nomeado o ICMPrto - que é a razão máxima
permitida de pedidos como "timestamp", "pedido de informações" e "mensagens
echo" enviados e recebidos dentro de uma sessão ICMP. O fluxo é classificado
como um fluxo de ataque se o ICMPrto está acima do limiar, caso contrário, é
considerado um fluxo normal.
Modelo de Tráfego normal UDP: o protocolo UDP não é orientado a
conexões, e por isso não precisa de pacotes de resposta para seu
funcionamento. Além disso, pode ter entregas fora de ordem e perda
de pacotes entre origem e destino sem que haja retransmissão. Esses
são alguns fatores de fazem o UDP ser considerado um protocolo
pouco confiável.
Com base nas observações feitas no modelo de tráfego UDP acima os
autores definiram alguns parâmetros como limiares para a análise das estatísticas
geradas para cada fluxo. O modelo classifica um fluxo UDP como ataque quando o
limiar de algum desses parâmetros for ultrapassado:
N conn: limite máximo de fluxos permitidos para o mesmo destino;
10
P conn: limite mínimo de pacotes permitidos para cada destino;
UDP rate: taxa de máxima de transmissão permitida por sessão;
3.1.3 Componente de Ajuste
Define uma taxa limite para transmissão e recepção em um fluxo específico
com base nas características e classificação deste fluxo.
Abaixo seguem as três classificações de fluxo atribuídas com base nos
modelos aqui descritos. Conforme a classificação de um fluxo será adotada uma
abordagem para regular a sua taxa limite:
1) Classificado como normal conforme o modelo;
2) Classificado como irregular quando os valores dos parâmetros estão fora
dos limites do modelo;
3) Classificado como transitório quando não há dados suficientes para realizar
a classificação dentro de seu modelo.
Quando o fluxo é classificado como de ataque após um longo período de
atividade normal, a sua taxa limite é redefinida através de uma fórmula baseada no
número de bytes enviados e número de bytes descartados durante o fluxo de
ataque. Depois de recalculada a taxa limite o fluxo continua sob monitoramento, pois
este pode voltar a apresentar um comportamento normal. Nesse caso há um novo
reajuste da taxa limite.
Conforme citado anteriormente, o sistema D-Ward utiliza uma tabela hash
para o armazenamento de registros. Os limites utilizados neste trabalho para essa
tabela são de 1.000.000 registros para conexões e 10.000 registros para fluxos.
Com a tabela hash utilizada o sistema possui algumas restrições
estabelecendo os requisitos abaixo:
Os registros de conexão são excluídos da tabela hash se a conexão é
classificada como transitória;
Se classificada como normal e ficou inativa por um bom período, estes
registros também são excluídos;
Se a tabela hash alcançou seu limite de capacidade, neste caso do
overflow, os registros são excluídos até ter espaço suficiente,
11
conexões consideradas normais não são excluídas mesmo com o
overflow da tabela hash.
A implantação desse sistema aplica-se de forma incremental, onde cada rede
deveria possuir um roteador D-WARD, reduzindo assim o número de máquinas que
geram ataque na Internet.
As vantagens desse sistema são muitas, os autores avaliaram que ele facilita
o bloqueio de pacotes de ataque de forma mais rápida, o rastreamento e a
investigação da origem do ataque torna-se o processo de identificação mais eficaz,
pois com o fluxo menor de pacotes permite a detecção com uma maior precisão.
3.2
LIGHTWEIGHT
DDOS
FLOODING
ATTACK
DETECTION
USING
NOX/OPENFLOW
Este trabalho mostra uma opção para minimizar ataques DDoS em uma rede
OpenFlow (BRAGA, 2010).
Usando o Switch OpenFlow, os autores averiguaram como trabalhar com o
fluxo de pacotes da rede, quais as informações necessárias para a análise desses
fluxos e como o controlador poderia interagir com o Switch OpenFlow. Partindo
dessas questões e com base nos dados coletados, verificou-se que o swicth precisa
autenticar-se junto ao controlador para adquirir uma identificação a qual ajudaria na
detecção dos ataques, pois através dela seria mais fácil identificar em qual switch
está ocorrendo um provável fluxo de ataque.
No estudo realizado sobre os fluxos de pacotes, identificou-se que ao
acessar o switch cada pacote tem o seu cabeçalho comparado com as entradas da
tabela de fluxo naquele equipamento (BRAGA, 2010). É então verificado se os
dados do pacote correspondem a alguma entrada na tabela de fluxos do switch e as
estatísticas desta tabela são atualizadas. No caso, as estatísticas de bytes e pacotes
do fluxo são incrementadas e a ação referente àquela entrada é executada sobre o
pacote em questão. Se as informações do pacote não correspondem a nenhuma
12
entrada na tabela, é solicitada ao controlador a adição de uma nova entrada
correspondente ao pacote recebido.
Tendo como base essas premissas, os autores identificaram que a utilização
do Switch OpenFlow em conjunto com o controlador consiste em um bom método de
Mtiigação de ataques DDoS. Sabendo que em uma rede pública circula um grande
volume de dados, os autores optaram pelo uso de redes neurais para classificação
dos fluxos.
Figura 4 - Operação do Loop de Detecção
Fonte: Adaptado de BRAGA (2010)
Para a criação de novos registros na tabela de fluxos é primeiramente
necessário um método de classificação desses fluxos. O método eleito nesse
trabalho utiliza redes neurais artificiais conhecidas como SOM (Mapas autoorganizáveis), que trabalham com aprendizado não supervisionado e são capazes
de detectar padrões (KOHONEN, 1990).
O treinamento da rede neural foi baseado somente nos padrões de entrada
com amostras sendo coletadas para alimentar a rede. Neste caso, cada amostra
13
constitui uma série características específicas extraídas dos fluxos coletados das
tabelas dos switches OpenFlow.
A arquitetura do método, representado na figura 4, usa o Controlador NOX,
que interage diretamente com os switches solicitando e enviando informações com
os três módulos, que são:
Módulo Coletor de Fluxo: é responsável, em intervalos de tempo
determinados pelo controlador, por solicitar através do canal seguro
todas as entradas de fluxo que estão registradas nos switches naquele
momento, que retransmitem as repostas pelo mesmo canal seguro.
Este módulo também recebe o resultado da classificação dos fluxos e
caso nenhum ataque seja identificado nas características enviadas é
liberado a circulação dos fluxos nos switches.
Módulo Extrator de características - recebe fluxos coletados, extrai as
seis características desses fluxos que foram definidas como
parâmetros importantes para detecção de um ataque DDoS e insere na
6-tupla, correspondente a seis campos que auxiliam na classificação
do fluxo. Depois de constituir a 6-tupla, esta é enviada para o módulo
classificador.
Classificador (SOM): analisa se as seis características correspondem a
um fluxo de ataque ou um fluxo normal, se o fluxo for considerado
normal ele retorna para o módulo coletor, caso seja detectado como
um fluxo de ataque é emitido um alerta para o administrador da rede.
Uma descrição mais detalhada das seis características.
1) Média de pacotes por fluxo (APF): esta característica tem como finalidade
identificar se os fluxos que foram coletados possuem um número de pacotes
plausível, não muito pequeno, que identificaria um fluxo de um provável ataque
(BRAGA et al., 2010). Antes de extrair a informação dos fluxos coletados, estes são
ordenados de forma ascendente conforme número de pacotes. Depois dos fluxos
ordenados é calculada a média de pacotes por fluxo com base no número de
pacotes de cada fluxo e o número total de fluxos.
2) Média de Bytes por fluxo (ABF): tendo como base os ataques de inundação
TCP, onde são enviados às vítimas pacotes de 120 bytes. Esta característica busca
14
encontrar fluxos que tenham como parâmetro um número pequeno de bytes que se
tornam prováveis fluxos de ataque. Neste cálculo é feita média de bytes por fluxo
extraindo o número de bytes por fluxo e número total de fluxo.
3) Duração média por fluxo (ADF): esta definição tem a finalidade de reduzir o
número de falsos positivos na rede, verificando o intervalo de tempo médio que um
fluxo permanece na tabela pelo pequeno número de pacotes trocados entre
aplicações.
4) Crescimento de diferentes portas (GDP): como o IP spoofing é um ataque
que consiste em mascarar pacotes IPs utilizando endereços de origem falsos, as
portas de origem e destino também podem ser geradas aleatoriamente em um
ataque.Este atributo tem a finalidade de verificar se ocorreu um crescimento no
número de portas dos fluxos analisados.
5) Crescimento dos Fluxos (GSF): tendo como base os ataques de inundação
TCP por causa do crescimento rápido do fluxos, esta particularidade verifica-se
houve um crescimento do número de fluxos nas entradas das tabelas do switch, pois
seria um sinal característico de um ataque.
6) Percentual de pares de fluxos (PPF): Esta característica, informa quantos
pares de fluxos ocorrem no intervalo de tempo para verificar se ocorre um aumento
de número de fluxos simples na rede, pois eles enviam pacotes com um IP falso
sinalizando um ataque.
Exemplo, dado quaisquer dois fluxos, ou seja, fluxo 1 e 2, as seguintes
condições são verificadas para analisar se esses fluxos constituem um par de fluxo:
- Se o IP de origem do fluxo 1 e igual ao IP destino do fluxo 2.
- Se o IP de destino do fluxo 1 é igual ao IP da origem do fluxo 2.
- E se ambos os fluxos tem o mesmo protocolo de comunicação.
Este trabalho apresentou um método leve para detecção de ataques DDoS
.Foram mostradas técnicas de extração de características de interesse com uma
baixa sobrecarga. O método é capaz de monitorar mais de um ponto de observação
com a utilização do auto-organização Mapas(SOM), abrangendo muitos casos e
proporcionando eficiência na detecção de um ataque.
4 . SISTEMA PROPOSTO
15
O sistema desenvolvido foi baseado na literatura de redes de segurança e em
informações relevantes dos dois trabalhos descritos acima com ênfase no primeiro,
que relatou a detecção de ataques na origem da rede. O objetivo do sistema em
conjunto com a plataforma OpenFlow, é verificar se as características definidas no
artigo D-Ward (MIRKOVIC, 2005) também serão eficazes na detecção de ataques
DDoS.
Foram definidas algumas características que serão examinadas nos pacotes
que circulam pela rede. Estes parâmetros são utilizados para realizar uma filtragem
dos fluxos indicando assim os prováveis fluxos de ataques.
As características citadas acima são:
- Mecanismo de Anti-spoofing: tem o objetivo de verificar se os pacotes
enviados a partir da rede local não estão com seus IPs de origem falsificados.
- Estabelecer limiares adaptativos utilizando os modelos TCP, UDP e ICMP
conforme proposto no trabalho D-Ward (MIRKOVIC, 2005).
Para o levantamento de dados estatísticos sobre as características citadas,
são armazenados pelo controlador em uma tabela hash registros referentes aos
fluxos que circulam no switch OpenFlow. Cada registro contêm os seguintes
parâmetros:
- Tipo de protocolo;
- IP de origem do pacote;
- IP de destino do pacote;
- Porta de entrada do pacote no Switch OpenFlow;
- Quantidade de pacotes enviados e recebidos;
- Total de bytes enviados e recebidos.
O hash de cada registro da tabela é calculado a partir dos quatro primeiros
parâmetros.
A estrutura do sistema está divida em componentes conforme representado
na Figura 5, cada componente exerce uma função que define se o sistema irá se
comportar conforme o esperado ou não.
Abaixo uma explicação sobre cada componente do sistema:
4.1 CONTROLADOR
16
Executa o algoritmo que define as políticas do sistema. Sua função é extrair
informações que circulam no switch OpenFlow através de troca de mensagens que
ocorrem pelo canal seguro.
No sistema proposto estas trocas de mensagens servem para tratar os
pacotes de entrada e saída do switch e os fluxos que estão armazenados na tabela
do switch.
Figura 5 – Arquitetura do Sistema
Fonte: Elaborada pela Autora (2013)
O controlador envia para o gerador de estatísticas os registros e recebe em
intervalos de tempo informações para verificar se algum limiar definido foi
ultrapassado, indicando um ataque. Caso seja um ataque, ele remove o fluxo
identificado como ataque da tabela do switch referente a porta do switch que
recebeu, até que este fluxo suspeito receba uma nova estatística.
4.2 GERADOR DE ESTATÍSTICAS
Este componente faz a análise dos dados de cada pacote novo que chega no
switch e em intervalos de tempo ele gera as estatísticas. Conforme proposto no
17
artigo D-Ward (MIRKOVIC, 2005) os limiares definidos dos modelos TCP, ICMP e
UDP são:
TCPrto: razão entre pacotes enviados e recebidos de um fluxo.
ICMPrto: razão entre pacotes enviados e recebidos de um fluxo.
N conn: limite máximo de fluxos permitidos para o mesmo destino;
P conn: limite mínimo de pacotes permitidos para cada destino;
As estatísticas são geradas através da comparação dos parâmetros de cada
registro de fluxo coletado no momento com os limiares pré-definidos acima. Além
das quatro características citadas que são os modelos definidos como limiares é
tratado mais um parâmetro que se refere à primeira característica. Este parâmetro
trata do mecanismo anti-spoofing, que faz uma análise dos pacotes enviados da
rede local (LAN) para a rede pública, pois pode ocorrer por erro ou intencionalmente,
que um dispositivo tente encaminhar pacotes cujo endereço de origem não esteja no
espaço de endereços da rede a que esteja conectado.
Como as redes internas são controláveis, os IPs dos computadores que
formam a rede local são configurados e comparados aos IP de origem dos pacotes
que circulam no switch. Se o IP de origem do pacote pertencer a lista de IPs da rede
local o fluxo segue o seu destino, caso contrário a porta do switch deste fluxo será
bloqueada seguindo a política mencionada anteriormente.
4.3 COMPONENTE DE CONTROLE DE TRÁFEGO
Este componente recebe os fluxos suspeitos de gerarem o ataque, identifica a
porta do switch e envia para o controlador tratar a resposta.
5. TESTES E RESULTADOS
O Sistema proposto, implementado em Python, atua em conjunto com o
controlador POX na detecção de ataques DDoS. O objetivo dos testes é avaliar a
taxa de identificação e bloqueio pelo sistema correspondente a ataques e também o
possível impacto nos tráfegos legítimos.
Para realização dos testes foram utilizadas ferramentas como o Mininet que é
a base para proporcionar um cenário de testes com a plataforma OpenFlow, o
18
Wireshark para monitorar os testes, o TCPReplay para reproduzir os traces legítimos
e de ataques e o TFN2K para gerar fluxo de ataque.
Abaixo uma breve explicação de cada ferramenta.
Controlador POX: é o principal componente de uma Rede Definida por
Software, é responsável por concentrar a comunicação com todos os
elementos programáveis da rede, oferecendo uma visão unificada da
rede. O controlador POX foi desenvolvido especificamente para fins de
pesquisa e ensino (NOXREPO.org).
Mininet : O Mininet foi instalado a partir de uma imagem Linux Ubuntu
executada em VMware ou VirtualBox , com aplicativos OpenFlow já
instalados. O Mininet possibilita a criação de um cenário com redes
virtuais escaláveis baseados na plataforma OpenFlow
(McKeown,2010).
Wireshark: é um analisador de protocolo que captura tráfego de uma
rede em tempo de execução usando a interface de rede do computador
(wireshark.org).
TCPReplay: é um um conjunto de ferramentas para sistemas UNIX
para edição e reprodução de tráfego de rede que foi previamente
capturado por ferramentas como o tcpdump e ethereal / wireshark. O
objetivo do tcpreplay é fornecer meios para proporcionar ambientes
confiáveis para testar uma variedade de dispositivos de rede, como
switches, roteadores, firewalls, detecção de intrusão e sistemas de
prevenção (IDS e IPS).
TFN2K: Tribe Flood Network 2000 (TFN2K) é uma ferramenta que
simula ataques DDoS contra um host. Consiste de um cliente e um
servidor. O cliente controla um ou mais daemons, que enviam um
volume de tráfego para o host destino. O cliente pode usar os
protocolos UDP, TCP, ICMP para gerar tráfego através dos daemons.
Estrutura de um ataque DDoS que é composta por quatro elementos
fundamentais:
Atacante: aquele que coordena o ataque controla os clientes;
Cliente: inicia o ataque nos daemons;
19
Daemons: processo que roda nas máquinas responsável por receber e
executar os comandos enviados pelo Cliente;
Vítima: alvo do ataque;
5.1 EXPERIMENTOS
Figura 6 – Topologia do Teste
Fonte: Elaborada pela Autora (2013).
Os testes basearam-se nos traces e na topologia utilizada pelo artigo D-Ward
(MIRKOVIC, 2005). Os traces utilizados foram capturados durante o mês de agosto
de 2001 no UCLA (Laboratório da Universidade da Califórnia), onde foram
capturados traces de tráfego legítimo e traces de ataque, os de ataque foram
gerados a partir de uma ferramenta desenvolvida pelo próprio grupo de projeto do DWard, os tipos de ataques gerados foram: TCP SYN flood, ICMP flood e UDP flood,
que também podem ser gerados pelas ferramentas TFN2K, TFN entre outras.
20
No caso do cenário utilizado os fluxos de ataque foram gerados a partir da
ferramenta TFN2K e armazenados como traces.
A Figura 6 representa o cenário criado na ferramenta Mininet onde a partir
dos host 1 é gerado o tráfego legítimo e do host 2 o tráfego de ataque, ambos em
direção à vítima, que possui um link limitado em 10Mbps. Cada host utilizou a
ferramenta TCPReplay para reproduzir um trace, sendo um legítimo e um de ataque.
As taxas utilizadas para gerar os tráfegos de ataque foram as mesmas
utilizadas nos testes do D-Ward. As taxas de ICMP e UDP são de 1Mbps a 180Mbps
com objetivo de gerar um ataque acima do link estabelecido para a vítima. Já no
TCP a intenção do ataque é extrapolar o buffer de conexões da vítima e foram
gerados tráfegos com mensagens TCP SYN com taxa de 1 até 25 kpps. Essas taxas
são menores porque os pacotes não carregam dados, somente os pedidos de
conexão. No caso do
tráfego legítimo foram geradas taxas de 1 Mbps nos
protocolos UDP,TCP e ICMP. O teste foi realizado durante 300 segundos para cada
taxa definida conforme testes realizados no artigo D-Ward.
A topologia utilizada no artigo D-Ward é mais ampla, pois possui mais
roteadores com o sistema acoplado e cada roteador possui duas máquinas na rede
local. Devido a fatores de desempenho da máquina virtual usada nos testes, o
sistema proposto trabalha com somente uma combinação de roteador e hosts na
rede local. Entende-se que esse cenário menor não afeta a validade dos testes, pois
no D-Ward a aplicação do mecanismo é feita individualmente em cada roteador.
Os testes foram realizados utilizando uma métrica de avaliação do artigo DWard (MIRKOVIC, 2005) que se refere à percentagem do tráfego legítimo que chega
a vítima enquanto está sendo gerado tráfego de ataque em direção a ela.
Adicionalmente, foi analisada nos mesmos testes a percentagem do tráfego de
ataque detectado. Os gráficos foram ilustrados a partir de dados coletados das
ferramentas de geração de tráfego e monitoramento.
A métrica analisa a quantidade de tráfego legítimo que chega à vítima
enquanto o ataque está em curso, através de duas formas: com a detecção e sem a
detecção de ataques no sistema. A quantidade de tráfego legítimo recebido é
expressa em percentagem: no caso ideal onde o ataque não interferir no tráfego
legítimo o valor seria de 100%.
21
Na Figura 7 está representado o teste do protocolo UDP, onde o eixo x
representa a vazão de tráfego de ataque e o eixo y mostra a percentagem do tráfego
legítimo. Como pode ser visto no gráfico, quando o ataque ultrapassa a banda do
link da vítima ocorre uma degradação relevante do tráfego legítimo no cenário sem
defesa. Já quando a defesa é habilitada, observa-se que quase 100% do tráfego
legítimo é recebido pela vítima.
Figura 7 – Percentual de Detecção de Tráfego Legítimo UDP
Percentual de Tráfego Legítimo (%)
100
80
60
UDP com Detecção
40
UDP sem Detecção
20
0
20
40
60
80 100 120 140 160 180
Taxa de Transmissão (Mbps)
Fonte: Elaborada pela Autora (2013).
Figura 8 – Percentual de Detecção de Tráfego Legítimo ICMP
22
Percentual Tráfego Legítimo (%)
100
80
60
ICMP com Detecção
40
ICMP sem Detecção
20
0
20 40 60 80 100 120 140 160 180
Taxa de Transmissão (Mpps)
Fonte: Elaborada pela Autora (2013).
Figura 9 – Percentual de Detecção de Tráfego Legítimo TCP
Percentual de tráfego Legítimo (%)
100
80
60
TCP com Detecção
40
TCP sem Detecção
20
0
5
10
15
20
25
Taxa de Transmissão (kpps)
Fonte: Elaborada pela Autora (2013).
Figura 10 – Tráfego de Ataque Detectado TCP
23
Percentual de Tráfego de Ataque
Detectado (%)
100
80
60
40
TCP com Detecção
20
0
0
5
10
15
20
25
Taxa de Transmissão (kpps)
Fonte : Elaborada pela Autora (2013).
Na Figura 8 é ilustrado o resultado do teste do protocolo ICMP. Assim como
no teste do UDP foi gerado tráfego de inundação em direção à vítima, que resultou
nas seguintes análises: sem a detecção a partir da taxa estabelecida no link a
proporção de mensagens ICMP recebidas pela vítima diminui consideravelmente,
com a taxa de ataque muito alta faz com que o tráfego legítimo não siga o seu
percurso.
A Figura 9 representa os resultados do teste do protocolo TCP. O objetivo do
teste não é ocupar banda e sim gerar tráfego a vítima usando o TCP SYN flood.
Verificando o desempenho no gráfico quando a detecção está desativada o nível de
tráfego legítimo é rapidamente reduzido para em torno de 80%, isso ocorre porque
diferentemente dos ataques de UDP e ICMP flood, o ataque do TCP ocasionou uma
baixa degradação no tráfego legítimo, uma vez que ele afeta somente o
estabelecimento das conexões. Assim, as conexões estabelecidas antes do início
dos ataques não sofreram perdas.
Mesmo assim, pode-se observar que o mecanismo de defesa possibilitou que
o tráfego legítimo chegasse à 100%.
A partir da Figura 10 é representado o percentual de ataques Detectados.
A Figura 10 representa que a percentagem de detecção de fluxo foi para
quase o ideal a partir de 10kpps, isto ocorre porque existe um atraso na detecção
dos ataques DDoS, mesmo que pequeno , pelo fato que os primeiros fluxos de um
24
ataque não são considerados como ataque, até uma pré-avaliação. Então uma
pequena perda de detecção de fluxos de ataque pode ocorrer para qualquer um dos
três protocolos analisados.
Figura 11 – Tráfego de Ataque Detectado UDP
Percentual de Tráfego de Ataque
Detectado (%)
100
80
60
40
UDP com Detecção
20
0
20 40 60 80 100 120 140 160 180
Taxa de Transmissão (Mbps)
Fonte: Elaborada pela Autora (2013).
Figura 12 – Tráfego de Ataque Detectado ICMP
25
Percentual de Tráfego de Ataque
Detectado
100
80
60
40
ICMP com Detecção
20
0
20 40 60 80 100 120 140 160 180
Taxa de Transmissão (Mbps)
Fonte : Elaborada pela Autora (2013).
A Figura 11 também mostra que a detecção ficou mais estável depois do
aumento da taxa de transmissão de pacotes. E pelos dados coletados foi verificado
um atraso da identificação do ataque, pois uma característica de ataque definida
pelo do D-Ward é o número de fluxos UDP para o mesmo destino. Este dado deve
chegar ao valor do parâmetro pré-definido, para assim ser considerado um fluxo de
ataque. Assim que este valor é ultrapassado todos os fluxos que entrarem nesta
mesma regra devem ser bloqueados.
Na Figura 12 o gráfico apresenta uma percentagem de ataques detectados no
caso do ICMP que também chegou próximo de 100% de detecção.
6. CONCLUSÃO
Neste trabalho o OpenFlow surge como uma alternativa para desenvolver
uma opção de defesa contra ataques DDoS. Essa plataforma é utilizada para coleta
de dados e bloqueio dos ataques, em conjunto com os mecanismos de detecção
abordados no artigo D- Ward (MIRKOVIC, 2005).
A união desses dois recursos possibilitou mais uma forma de usar a
plataforma OpenFlow como um benefício dentro de redes que necessitam de
segurança e ambientes controláveis. Um item importante a comentar é o uso da
26
própria plataforma OpenFlow para desenvolvimento do sistema, que é implementado
no próprio controlador sem a necessidade de agregar sistemas ao roteador que não
pertençam já a rede.
O sistema proposto neste trabalho apresentou resultados semelhantes
comparados aos resultados do artigo D-Ward (MIRKOVIC, 2005) quando se trata de
garantir um serviço de tráfego legítimo. Já os resultados apresentados sobre o
percentual de tráfegos de ataque bloqueados é uma contribuição original, pois não
foram apresentados naquele artigo.
Como o sistema foi implementado em Python e utilizando o controlador POX
para desenvolvimento e controle do tráfego, o desempenho foi fator limitante na
execução dos experimentos. Para trabalhos futuros é recomendável a utilização do
controlador NOX que utiliza a linguagem de programação em C/C++ possibilitando
assim um melhor desempenho para volumes grandes de tráfego.
27
USING OPENFLOW ON A MECHANISM FOR DDOS ATTACK MITIGATION
Abstract: With technology advancement and the accelerated development of new
applications and protocols, there is a demand for a reliable environment to test such
technologies. OpenFlow was other technologies for SDN fills that need, it allows
customization, permitting high level of flexibility. Another analysis to be done is the
reliability of the results of the executed tests, where precise results are expected to
maintain quality of service. This work aims to adapt mechanisms used in the system
D-Ward (DDoS defense system deployed in the network) in the OpenFlow platform.
Using this platform to make data collection and blocking DDoS attack. With this
merger is intended to mitigate the DDoS attacks in an OpenFlow network, also
obtaining a good level for legitimate traffic.
Keywords: OpenFlow Protocol, D-Ward, Mitigation.
28
REFERÊNCIAS
SACHDEVA M. DDoS Incidents and their Impact: A Review
Department of Computer Science and Engineering, SBS College of Engineering and
Technology, India. Disponível em: The International Arab Journal of Information
Technology, Vol. 7, No. 1, January 2010.
Acesso em: 20 outubro 2012
BRAGA R. Lightweight DDoS flooding attack detection using NOX/OpenFlow ,
In: CONFERENCE PUBLICATIONS, 10-14 Oct. 2010
Dept.de Cienc.da Comput.,Univ. Fed. Do Amazonas,Brazil. Disponível em:
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5735752&url=http%3A%2F%2
Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5735752. Acesso
em: 08 agosto 2012
SHERWOOD R. FlowVisor: A Network Virtualization Layer
Deutsche Telekom Inc R&D Lab, Stanford University, OPENFLOW-TR-2009
Disponivel em : http://www.OpenFlow.org/downloads/technicalreports/OpenFlow-tr2009-1-flowvisor.pdf Acessado em : 10 agosto de 2012
MCKEOWN A. OpenFlow: enabling innovation in campus networks.
Newsletter ACM SIGCOMM Computer Communication Review archive, Volume 38
Issue 2, April 2008 Pages 69-74.Disponível em:
http://dl.acm.org/citation.cfm?id=1355746 .Acesso em: 10 agosto 2012
MIRKOVIC J. Attacking DDoS at the Source, University of California Los Angeles
Computer Science Department, Network Protocols, 2002. Proceedings. 10th IEEE
International Conference on, Disponível em :
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1181418&url=http%3A%2F%2
Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1181418. Acesso
em: 08 agosto 2012
MIRKOVIC J. D-WARD: A Source-End Defense Against Flooding Denial-ofService Attacks, University of California Los Angeles Computer Science
Department, Dependable and Secure Computing, IEEE Transactions on , 2005,
Volume 2.
Disponível em:
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1510618&url=http%3A%2F%2
Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1510618
Acesso em: 20 de setembro 2013
Y. Zhang e L. Qiu. Understanding the End to End Perfomance Impact of RED in
a Heterogeneous Environment, Cornell University Library,July 2000,
Disponível em: http://www.aciri.org/floyd/red.html
Acesso em:17 de outubro de 2013
29
Lantz B, Brandon H, McKeown N. A Network in a Laptop: Rapid Prototyping for
Software-Defined Networks. 9th ACM Workshop on Hot Topics in Networks,
October 20-21, 2010, Monterey, CA.
Acesso em: 12 de novembro de 2013
T. Kohonen, The self-organizing map, Proceedings of the IEEE,
vol. 78, no. 9, pp. 1464–1480, 1990.
Acesso em: 10 de outubro de 2012
FARIAS F. Pesquisa Experimental para a Internet do Futuro:Uma Proposta
Utilizando Virtualização e o Framework OpenFlow,
XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos SBRC 2011
Disponível em: http://sbrc2011.facom.ufms.br/files/mc/mc1.pdf - Acesso em: 10
agosto 2012
Sachdeva M. Deployment of Distributed Defense against DDoS Attacks in ISP,
Domain, International Journal of Computer Applications (0975 – 8887) Volume 15–
25 No.2, February 2011 Disponível em:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.5582&rep=rep1&type=
pdf
Ming L. Simulation Study of Flood Attacking of DDOS, International Conference
on Internet Computing in Science and Engineering , Janeiro 2008. Disponível em:
http://www.asres07.umac.mo/rectors_office/docs/weizhao_cv/pub_refereed_conferen
ces/2008/3112a286%5B1%5D.pdf
OpenFlow.org, 2011. Disponível em: <http://www.OpenFlow.org/>. Acesso em: 10
agosto de 2012.
Wireshark.org, 2006. Disponível em: <http://www.wireshark.org>. Acesso em: 02 de
novembro 2013.
NOXREPO.org, 2011. Disponivel em:< http://www.noxrepo.org/pox/about-pox/> .
Acesso em: 04 de abril de 2013.
Sourceforge, 2010. “tcpreplay tool,” http://tcpreplay.sourceforge.net/.
Tribe Flood Network 2000 Tool, 2000 Disponivel em :
<http://packetstormsecurity.com/search/?q=tfn2k>. Acesso em : 10 de maio de 2013.