Mitigação dos Ataques DDoS dentro de Redes OpenFlow

Transcrição

1 UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS UNIDADE ACADÊMICA DE GRADUAÇÃO CURSO DE CIÊNCIA DA COMPUTAÇÃO Gabriele Gayer Ramires Mitigação dos Ataques DDoS dentro de Redes OpenFlow São Leopoldo 2012

2 Gabriele Gayer Ramires Mitigação dos Ataques DDoS dentro de Redes OpenFlow Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação, pelo Curso de Ciência da Computação da Universidade do Vale do Rio dos Sinos UNISINOS Orientador: Rafael Bohrer Ávila São Leopoldo 2012

3

4 4 RESUMO Com o progresso da tecnologia e o crescimento acelerado no desenvolvimento de novas aplicações e protocolos, surge a carência de um ambiente confiável para testar essas novas tecnologias. O OpenFlow é uma rede que supri 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 remodelar o nível de segurança na plataforma OpenFlow utilizando o sistema D-Ward( sistema de defesa DDoS implantado na rede local). Este sistema emprega estatísticas de tráfego de fluxo e alguns métodos como: a classificação de fluxo e o ajuste de limite de taxa para detectar ataques, isto agregado a arquitetura OpenFlow. Com essa junção pretende-se mitigar os ataques DDoS dentro de uma rede OpenFlow. Palavras-Chave: Protocolo OpenFlow, D-Ward, Mitigação.

5 ABSTRACT With the advancement of technology in business and accelerated growth in the development of new applications and protocols arises the need of a trusted environment to test these new technologies. The OpenFlow is a network that appears to meet this need as it allows the customization, differing from a normal network, allowing flexibility for experiments. Another analysis to be made is the part that involves the reliability of the experiments done that need accurate answers to keep the quality level of development. This work aims to optimize the level of security within the network using OpenFlow system D-Ward would be a DDoS defense system deployed in local area network, which uses statistics of traffic flow and some methods of classification and flow of adjustment limit rate to detect attacks using a feedback system parameters for new detections together to unite this implementation architecture OpenFlow. With this merger we intend to mitigate DDoS attacks within an OpenFlow network. Keywords: OpenFlow Protocol, D-ward, Mitigation.

6 6 LISTA DE FIGURAS Figura 1 - Switch OpenFlow...14 Figura 2 - Mecanismo do Switch OpenFlow Figura 3 - Arquitetura D-ward Figura 4 - Ataque DDoS em Progresso...21 Figura 5 - Arquitetura PushBack Figura 6 - Comunicação entre Cliente e Servidor...26 Figura 7 - Operação de Loop de Detecção Figura 8 - Algoritmo FEBR Figura 9 - Arquitetura MADROF Figura 10 - Sistema MADROF... 34

7 LISTA DE TABELA Tabela 1 Cronograma... 36

8 LISTA DE SIGLAS DDOS MADROF UNISINOS Distributed Denial of servicec Mitigação de Ataques DDoS em Redes OpenFlow Universidade do Vale do Rio dos Sinos

9 SUMÁRIO 1 INTRODUÇÃO OPENFLOW Especificação e arquitetura Controlador NOX Aplicações TRABALHOS RELACIONADOS Attacking DDoS at the Source Arquitetura do Sistema Implementing Pushback: Router-Based Defense Against DDoS Arquitetura do mecanismo Algoritmo Pushback SIFF: A Stateless Internet Flow Filter to Mitigate DDoS Flooding Attacks Arquitetura do Mecanismo Protocolo de Comunicação Lightweight DDoS Flooding Attack Detection Using NOX/OpenFlow OpenFlow based Flow Level Bandwidth Provisioning for CICQ Switches Descrição do Algoritmo FEBR Considerações sobre os Trabalhos relatados PROPOSTA CRONOGRAMA REFERÊNCIAS... 39

10 10 1 INTRODUÇÃO Com o grande avanço tecnológico desta última década, o fluxo de dados na internet aumentou, diminuindo a segurança entre as redes. Uma das ameaças que passou a fazer parte de sites de noticias e na imprensa em geral foi o DDoS ( Distributed Denial of Service) ( MENEGAZZO et al., 2011), ou seja, ataque distribuído de negação de serviço. Este ataque ocorre quando um computador mestre pode ter sob seu comando milhares de computadores ("Zombies" - zumbis), neste caso, as tarefas de ataque de negação de serviço são distribuídas a um "exército" de máquinas escravizadas. Detectar este ataque tornou-se um dos principais desafios à segurança da Internet atualmente ( SACHDEVA et al., 2010). Por exemplo, o Banco HSBC, foi o alvo escolhido no dia 02 de fevereiro de 2012, pela "Operação #OpWeeksPayment" do grupo Anonymous, que deixou as operações de internet banking da instituição indisponíveis para os seus clientes durante algumas horas (EXAME ONLINE, 2012). Outros bancos sofreram o mesmo tipo de ataque com autoria do mesmo grupo. Com o crescimento da utilização de soluções tecnológicas percebe-se a dependência da tecnologia e da segurança para o sucesso das organizações e empresas. O mecanismo de ataque DDoS baseia-se na exploração massiva de serviços expostos na rede, onde o ataque ocorre com o envio de uma grande quantidade de pacotes para um alvo de forma coordenada a partir de várias origens. Causando ao alvo, por exemplo, um servidor que for atingido por este ataque, um consumo dos seus recursos assim interrompendo os serviços disponibilizados pelo servidor: aplicativos, sites e serviços on-line. (BRAGA et al., 2010). Buscando maneiras de investigar e testar formas que possibilitem experimentos para a detecção de ataques DDoS surge a ideia do OpenFlow por ser uma interface aberta e programável para controle de tabelas de fluxos dos switches de rede, roteadores e pontos de acesso. A arquitetura OpenFlow nos permite controlar os fluxos escolhendo o encaminhamento e o processamento do pacotes. Logo, o OpenFlow é capacitado para experimentar com novos protocolos, novos modelos de segurança, e/ou novos esquemas de endereçamento. O OpenFlow possui um protocolo próprio para configuração e uma API (Application Programming Interface), utilizada por pesquisadores e desenvolvedores para estudos de novos protocolos. Antes da descoberta do OpenFlow a maior parte das novas ideias da comunidade

11 11 de pesquisa de rede não eram testada, pois tinham a convicção que a infraestrutura da Internet ossificou ou enrijeceu (MCKEOWN et al., 2008). Com as inúmeras configurações que a plataforma OpenFlow pode oferecer e com a segurança, ainda sendo um ponto muito frágil e suscetível a problemas, abre-se um novo conjunto de oportunidades para a busca por novas ideias e métodos, ou até mesmo a união de métodos já utilizados, para otimizar a segurança na rede. Atualmente faz-se necessário melhorar a segurança dentro de redes públicas e privadas e, principalmente, melhorar dentro de uma rede utilizada para testes e simulações, onde as respostas esperadas devem ser providas de uma rede altamente confiável. Diante das necessidades apresentadas surgem problemas como: o que se pode fazer para detectar e/ou minimizar os ataques de DDoS? Como identificar se determinado tráfego é legítimo ou não? Buscando fornecer respostas a esses questionamentos, esta pesquisa tem a finalidade de obter um método que faça a detecção e a mitigação dos ataques DDoS dentro de uma plataforma OpenFlow, melhorando a segurança desta rede, otimizando testes e simulações. Alguns objetivos específicos do trabalho são: Analisar trabalhos que envolvam OpenFlow e tráfego de rede; Analisar trabalhos que ofereçam métodos de mitigação de ataques DDoS; Definir cenários de testes para técnicas de mitigação de DDoS com base no OpenFlow; Analisar o controlador NOX em redes OpenFlow ; Este trabalho está estruturado da seguinte forma que segue: Inicialmente o primeiro capítulo foi apresentado a Introdução ao tema do trabalho. Em seguida, o capítulo 2 descreve o detalhamento da plataforma OpenFlow e suas principais características, seguido pelo capítulo 3 onde são analisados diversos trabalhos que empregam Openflow e técnicas de prevenção de ataques DDoS. O capítulo 4 será apresentado o método proposto e o capítulo 5 o cronograma das atividades que serão desempenhadas.

12 12

13 13 2 OPENFLOW O OpenFlow trata-se de uma plataforma que possui um protocolo próprio para comunicação entre o controlador e o switch. Utilizado para testes e simulações possibilitando pesquisadores testarem seus protocolos experimentais em redes de produção, redes metropolitanas e em backbones de uma rede de ensino e pesquisa (MCKEOWN et al., 2008). Nas redes em geral o encaminhamento dos pacotes e o roteamento são executados por somente um dispositivo. Na plataforma OpenFlow o Switch trata do encaminhamento dos pacotes e o Controlador exerce a função de decidir o roteamento dos pacotes. A configuração é feita através de uma API (Application Programming Interface), aplicativo simples e extensível do Open Flow para programar o comportamento dos fluxos de pacotes com inovação aberta e rápida. Usando esta API, pesquisadores podem rapidamente construir novos protocolos e aplicá-los em um ambiente de produção sem prejudicá-lo. (FARIAS F et al.,2011 ). Nesse protocolo aberto pode-se programar a tabela de fluxo dos equipamentos, assim o administrador de rede consegue dividir o tráfego em fluxo de produção e de pesquisa controlando-os e definindo, com isso, a rota e o tratamento que cada pacote deve receber. Nas seções abaixo serão abordados alguns aspectos importantes sobre o protocolo OpenFlow como sua arquitetura, escopo e suas aplicações. 2.1 Especificação e arquitetura OpenFlow. A figura 1 mostra de forma básica os componentes e as funções de um switch

14 14 Figura 1 Switch OpenFlow Fonte: OPENFLOW(2011) O Switch OpenFlow interage com o Controlador através de uma conexão segura usando o protocolo OpenFlow. Consiste em uma ou mais tabelas de fluxo e uma tabela de grupo, que realizam as pesquisas de pacotes e de encaminhamento através do canal seguro para o controlador externo. Usando este protocolo, o controlador pode adicionar, atualizar e excluir entradas de fluxo (OPENFLOW, 2011). O protocolo OpenFlow é aberto para comunicação e usa uma interface externa, para troca de mensagens entre os equipamentos da rede e os controladores. Essas mensagens podem ser simétricas (hello, echo vendor),assíncronas (packet in, flow removed, port status, error) ou, ainda, iniciadas pelo controlador (features, configuration, modify state, send packet, barrier). Cada tabela de fluxo no switch contém um conjunto de entradas de fluxo, cada entrada de fluxo consiste (MCKEOWN et al, 2008): 1. Um campo para o cabeçalho de pacote, que define o fluxo; 2. Outro para a ação, que define como o pacote deve ser tratado; 3. Um campo para as estatísticas, que mantém o controle do número de pacotes e bytes de cada fluxo e o tempo decorrido desde que o último pacote pertencente ao fluxo foi identificado pelo switch, essa ultima estatística auxilia na remoção de fluxos inativos. Se uma entrada for equivalente a tabela de fluxo, as instruções associadas com a entrada do fluxo especificado são executadas. Se a entrada não for equivalente, o resultado depende da configuração do switch: o pacote pode ser enviado ao controlador sobre o canal

15 15 seguro, pode ser rejeitado, ou pode continuar na próxima tabela de fluxo (MCKEOWN et al, 2008). O canal seguro é a parte que conecta cada switch OpenFlow ao controlador, garantindo a segurança na troca e gerenciamento de informações entre o switch e o controlador. Todas as mensagens que circulam pelo canal devem ser formatadas de acordo com o protocolo OpenFlow. O canal OpenFlow usa criptografia TLS (segurança da camada de transporte), mas pode ser executado diretamente sobre o TCP (OPENFLOW, 2011). O Controlador é o software responsável por tomar decisões e adicionar e remover as entradas na tabela de fluxos, de acordo com o objetivo desejado. Por ser um elemento muito importante na comunicação dentro da arquitetura OpenFlow será tratado num capítulo separado (MCKEOWN et al, 2008). 2.2 Controlador NOX O controlador exerce a função de gerenciar as entradas de fluxos na rede. Divide a rede para experimentos adicionando e removendo entradas do fluxo, funciona como uma VLAN em comparação com a rede real que usamos. Dessa forma, o controlador OpenFlow atua como um sistema operacional(so) para gerenciamento e controle das redes, e oferece 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, assim executando múltiplos experimentos com diferentes tipos de fluxos. A escabilidade se torna um fator importante no controlador, por se tratar de um sistema centralizado, no NOX, existem três requisitos importantes ( chegada do pacote, inicialização do fluxo, mudança na rede). Figura 2 Mecanismo do Switch OpenFlow

16 16 Fonte: MCKEOWN (2008) 2.3 Aplicações Existem muitas aplicações as quais podem ser usadas no protocolo OpenFlow, experimentos podem ser os mais diversos possíveis, como exemplo do que podem ser realizados, podem-se citar experimentos: - No nível de fluxo (protocolos desenvolvidos pelo pesquisador, gerenciamento de energia, gerenciamento e administração de redes, controle de admissão e acesso, mobilidade VoIP, acesso sem-fio, permitindo que clientes móveis utilizem sua infraestrutura para se conectarem a Servidores ou à Internet). - No nível de pacotes (controlar e processar cada pacote, redirecionar fluxos através de hardware programáveis, modificar middleboxes) e alternativas para IP (novo esquema de atribuição de nomes e endereço, pacotes Não-IP podem ser definidos pelo endereço MAC de origem ou destino ou a partir de um novo Tipo de Ethernet ou IP). Outra aplicação (SHERWOOD et al, 2009) que é de extrema importância é o mecanismo FlowVisor que é usado na virtualização de redes OpenFlow. A virtualização de redes, um assunto muito estudado atualmente, é importante para permitir que em uma mesma infraestrutura física possam coexistir redes com diferentes mecanismos de encaminhamento, endereçamentos, entre outros.

17 17 3 TRABALHOS RELACIONADOS Após pesquisas realizadas sobre DDoS e OpenFlow, apresento nesta seção alguns métodos que auxiliam na mitigação de ataques DDoS dentro de redes públicas e redes que utilizam o protocolo OpenFlow. Esses métodos se relacionam com o trabalho quanto à abordagem adotada, cada trabalho explana aplicações e características diferentes, porém a mesma finalidade: a segurança. Dentre os aspectos expostos, esta proposta tem o objetivo de analisar e extrair os pontos positivos de cada trabalho relacionado. 3.1 Attacking DDoS at the 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 proposta de fazer a mitigação dos ataques em roteadores que estejam ligados diretamente na rede local (LAN do equipamento), como roteadores de borda, detectando e eliminando fluxos de ataques provenientes dessa rede Arquitetura do Sistema O sistema D-Ward encapsula três componentes importantes para o seu funcionamento. Estes componentes analisam e definem como serão tratados os fluxos de pacotes que trafegam pelo roteador, no qual o sistema está interagindo. A figura 3 representa esta arquitetura do sistema. Figura 3 Arquitetura D-Ward Fonte: MIRKOVI C (2002)

18 18 Esta arquitetura está composta de um Componente de Observação e um Componente de ajuste, conforme descrição abaixo: Componente de Observação: é responsável por monitorar todos os pacotes que circulam pelo roteador ligado a rede local classificando-os, criando modelos e fazendo estatísticas desses fluxos de pacotes. O tráfego online de fluxo é comparado com modelos prédefinidos de tráfego de fluxo normal. São geradas estatísticas sobre a comunicação bidirecional entre o conjunto de endereços rastreados e os endereços da internet, os endereços monitorados são préconfigurados no sistema D-Ward. Analisando o fluxo de pacotes comparados, é possível identificar se são fluxos de ataques ou fluxos legítimos, caso sejam fluxos legítimos devem receber um tratamento diferente. Depois da análise feita os resultados são encaminhados para o componente de ajuste. Componente de Ajuste: recebe o resultado da comparação dos fluxos, ajusta e transfere as regras com os novos limites de taxa para o roteador de origem. Os limites de taxa aplicados modificam o fluxo de tráfego associado e, portanto, afetam nas próximas observações, fechando o ciclo de respostas. Entre o Componente de Observação e o Componente de ajuste existe uma comunicação através da classificação de fluxo. A Classificação de Fluxo mantém um registro para cada endereço IP existente, onde cada registro de fluxo contém estatísticas sobre três tipos de tráfego: TCP, UDP e ICMP. Essas estatísticas incluem o número de pacotes e bytes enviados e recebidos a partir dos pares armazenados durante um intervalo de observação e o número de conexões ativas. O sistema utilizou um modelo padrão para o tratamento de cada protocolo: Para o TCP foi utilizado o TCP rto que é a relação máxima permitida para número de pacotes enviados e recebidos e para aceitação do fluxo TCP nos pares de endereços IPs. O fluxo é classificado como um fluxo de ataque se a sua razão de pacotes está acima do limiar, caso contrário, é considerado um fluxo normal. Como o tráfego UDP ocupa uma pequena percentagem do tráfego total da rede, este é conduzido por meio de poucas conexões. Devido as poucas conexões, define-se o fluxo de modelo UDP como UDP rate que é o valor máximo de taxa permitida por conexões. O modelo classifica um fluxo de ataque quando o limite dessa taxa é ultrapassado.

19 19 O modelo ICMP especifica muitas mensagens de tipos diferentes, durante a operação normal como: timestamp, information request e echo. Essas mensagens devem ser em pares conforme a resposta correspondente. Trata-se da relação máxima de mensagens a partir da solicitação de informações e repostas de pacotes enviados e recebidos, que agregam o fluxo de pares. As Estatísticas de conexão são armazenadas em uma tabela hash de conexão com tamanho limitado e incluem o número de pacotes e bytes enviados e recebidos durante o intervalo de observação. Cada conexão é classificada como normal (conforme o modelo), ruim (valores dos parâmetros fora dos limites do modelo) ou transitória (não há dados suficientes para realizar a classificação) de acordo com o tipo de tráfego do seu protocolo. O registro de conexão é excluído da tabela hash se a conexão é classificada como transitória, ou normal se ficou inativa por um bom período, ou se a tabela hash alcançou seu limite de capacidade. No caso do overflow, os registros são excluídos até ter espaço suficiente, 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, assim reduzindo o número de máquinas que geram ataque na Internet. As vantagens desse sistema são muitas, facilitam o bloqueio de pacotes de ataque de forma mais rápida, o rastreamento e a investigação da origem do ataque torna-se mais eficaz, pois com o fluxo menor de pacotes permite a utilização de estratégias mais complexas de detecção com uma maior precisão. Através da implantação desse sistema, reduz-se significativamente o volume de ataques, um problema que pode ocorrer é que pacotes legítimos podem ser marcados muitas vezes como pacotes de ataques. 3.2 Implementing Pushback: Router-Based Defense Against DDoS O Pushback (IOANNDIS et al, 2002 ) é um mecanismo de defesa contra ataques distribuídos de negação de serviço (DDoS). É tratado como um problema de controle de congestionamento, pois defende-se que o problema deve ser tratado pelos roteadores. O mecanismo propõe que seja adicionado a cada roteador a implementação Pushback ou acoplado aos roteadores essa implementação. Para detectar e preferencialmente

20 20 descartar, pacotes provenientes de um ataque. Mantendo a integridade dos pacotes legítimos que circulam pelos roteadores. Para representar o mecanismo Pushback a figura 3 ilustra vários roteadores interligados, onde o servidor D será o alvo de um ataque. Onde está representado tráfegos de fluxos legítimos e não legítimos. Apenas a última conexão está efetivamente congestionada, as demais conexões internas estão seguras. Na ausência de configurações adequadas, dificilmente o tráfego normal poderia chegar ao seu destino. Tráfegos normais percorrem também ligações entre os roteadores R2- R5, R3-R6, R5-R8, R6-R8, e R8 a partir de D, mas a maior parte é descartada por congestionamento em R8-D. Figura 4 Ataque DDoS em Progresso Fonte: IONNIDIS (2002) Arquitetura do mecanismo A figura 4 representa a arquitetura do mecanismo Pushback, o exemplo consiste em um mecanismo Pushback que não pode ser inserido no próprio roteador, mas sim em uma parte externa auxiliando o equipamento. Na arquitetura proposta pacotes de entrada são analisados verificando-se sua assinatura de congestionamento. Nem todo pacote que contém essa assinatura é considerado

21 21 um ataque, pode estar apenas sendo direcionado para o mesmo fluxo de congestionamento. Após averiguar a assinatura dos pacotes, os pacotes de ataques são enviados para a análise do limite de taxa, corresponde a taxa de transmissão que os pacotes podem trafegar entre um roteador e outro. Os pacotes normais são enviados para a fila de saída. Os pacotes que não são descartados pelo limite de taxa, são enviados para a fila de saída. Se a largura de banda não for suficiente para a transmissão, os pacotes são excluídos. Figura 5 Arquitetura Pushback Fonte: IONNIDIS (2002). O mecanismo Pushback recebe pacotes descartados, tanto pelo limite de taxa quanto pela fila de saída, os parâmetros do Pushback são atualizados e as demais aplicações da rede são informadas sobre essas atualizações. Uma breve explicação de alguns parâmetros: Número Mágico tem a função de resolver problemas de sincronização entre o kernel e os processos a nível de usuário. Endereço IP de destino neste campo contém o endereço IP para o qual os pacotes devem ser encaminhados. Registro de Tempo e Tamanho do Pacote Este tempo é calculado em nanossegundos, a partir da última inicialização do roteador, e sua função juntamente com o tamanho do pacote, é calcular a largura de banda que foi consumida pelos pacotes perdidos.

22 22 fila de saída. Razão Este campo indica se os pacotes foram descartados pelo limite de taxa ou pela Algoritmo Pushback O mecanismo Pushback utiliza um algoritmo para tratar os pacotes que são descartados pelo limite de taxa e pela fila de saída, mas podem ser considerados pacotes de ataques. Para o resultado ser significativo o algoritmo trabalha com um número grande de pacotes descartados e ao mesmo tempo devem ser pequenos, para serem processados em um tempo hábil. O algoritmo detecta pacotes de ataques pelo endereço IP de destino do cabeçalho do pacote, tendo a premissa que o endereço IP de origem pode ser gerado randomicamente e não são confiáveis. Nesse caso o endereço IP de destino de cada pacote descartado é comparado com a tabela de roteamento. São selecionados e agrupados os endereços IPs de destino com o prefixo mais longo que foram comparados na tabela de roteamento e apresentaram informações similares. Para o conjunto de pacotes descartados com o mesmo prefixo selecionado, é feita uma nova verificação. É analisado se destino dos pacotes descartados possuem um prefixo maior do que o prefixo de da tabela de roteamento. Utilizando, como exemplo, um computador que é alvo de um ataque, mesmo que o prefixo capturado da tabela de roteamento for menor que 32 bits, o endereço do pacote descartado selecionado será completo 32 bits. O prefixo selecionado determina a assinatura do congestionamento. A partir do momento que foi definida a assinatura de congestionamento, o algoritmo deve decidir seu limite de taxa, através de cálculos feitos com o link da banda. Se o link de banda dos pacotes descartados é maior que o link da banda de entrada, menos 20% do link de banda de saída. Então o conjunto de pacotes descartados é ajustado de acordo com o limite de taxa e o restante do tráfego é encaminhado para o próximo roteador. Se o link da banda dos pacotes descartados for menor que o link da banda de entrada, menos 20% do link de banda de saída, é eliminado todo o tráfego pertencente à assinatura de congestionamento, e assim a fila de saída limitará o excesso de tráfego. O algoritmo tem a função de identificar pacotes que causam congestionamento entre links de entrada e saída da rede. Através do limite de taxa e da assinatura de congestionamento ele consegue descartar estes pacotes. Tornando o mecanismo Pushback um complemento para minimizar os ataques DDoS.

23 SIFF: A Stateless Internet Flow Filter to Mitigate DDoS Flooding Attacks É um mecanismo (YAAR et al, 2004) que trabalha com filtro de fluxo que não armazena informações de pacotes anteriores. A rede é dividida em duas classes, privilegiada e sem privilégios. Ocorre uma comunicação em canais privilegiados através de trocas de credenciais que são geradas dinamicamente e onde seu estado não é verificado pelos roteadores da rede, possibilitando que o endereço IP do usuário final tenha a capacidade de parar um ataque. Para tornar este mecanismo possível são exemplificadas algumas propriedades: Comunicação privilegiada entre Cliente e Servidor: Permite estabelecer um canal privilegiado entre Cliente e Servidor sobre IPs onde os pacotes tenham precedência sobre os pacotes não privilegiados. Controle de fluxo privilegiado no Destinatário: SIFF possibilita ao usuário que tem o privilegio de se comunicar pelo canal ter a capacidade de suspender a comunicação no canal, assim interrompendo o fluxo de pacotes antes de serem encaminhados para a rede Limite de falsificação de endereço por Origem: O usuário recebe o privilegio de se comunicar pelo canal. Constantes Estados em Roteadores: Os roteadores que implementam o SIFF precisam manter um valor constante de estado por interface, independente do número de canais privilegiados que percorrem os roteadores. Essa é uma das principais características do mecanismo SIFF. Processamento de pacotes nos roteadores: O roteador SIFF precisa executar duas verificações de igualdade para cada pacote privilegiado, ou um único cálculo hash para cada pacote não privilegiado que encaminha. Essas verificações podem ser finalizadas em paralelo com a consulta da tabela de roteamento. Compatibilidade com versões anteriores: Para que Clientes privilegiados e servidores possam continuar usufruindo do mecanismo a atualização deve ocorrer periodicamente. Nessa proposta todos os roteadores, servidores e clientes devem possuir o mecanismo SIFF e estarem de acordo com uma camada IP modificada, para se beneficiar de suas ações. Todos os equipamentos que não possuem este tipo de aplicação poderão se comunicar com os equipamentos que tem essa facilidade, porém não irão perceber os benefícios.

24 24 O mecanismo assume que no cabeçalho da camada IP tem espaço suficiente para os roteadores inserirem uma marcação no pacote. Os roteadores com a implementação SIFF são capazes de manipular as marcações dos pacotes que encaminham. Essas manipulações podem ser executadas em paralelo com uma consulta a tabela de roteamento. O SIFF baseia-se em rotas da internet estáveis na ordem de tempo de transações entre clientes e servidores. O sistema não deverá travar de imediato, caso ocorra uma instabilidade na rede, pois geralmente o que leva a essa instabilidade são os ataques DDoS e como o mecanismo tem a função de descartar esses pacotes, a probabilidade de esta situação ocorrer é pequena Arquitetura do Mecanismo Na comunicação entre clientes e servidores que percorrem os roteadores, pacotes privilegiados são sempre prioritários em relação a pacotes não privilegiados na disputa pela largura de banda. O canal privilegiado é estabelecido através de uma credencial que o cliente obtém a partir da comunicação com um canal sem privilégios. A credencial que cada pacote recebe ao passar por um roteador, é gerada em cada roteador a partir dos dados do cabeçalho do pacote e da topologia da rede local. Quando é encaminhado um pacote privilegiado o roteador confere a parte incorporada da credencial e verifica se corresponde a marcação de um pacote sem privilégios. Se a marcação for de um pacote sem privilégios, este é encaminhado, caso não seja o pacote é descartado. As próprias credenciais são baseadas em marcações de pacotes que mudam nos roteadores com certa frequência. Os roteadores mantêm as marcações válidas e substituem marcações antigas por novas. Uma vez que o destinatário do pacote, ao invés do remetente do pacote, recebe as atualizações das credenciais, a comunicação privilegiada necessita que seja atualizada periodicamente a credencial do remetente Protocolo de Comunicação Ao iniciar a comunicação entre clientes e servidores é utilizado um tipo não privilegiado de pacote que é chamado de pacote experimental. Ao longo do trajeto desse pacote os roteadores inserem uma informação específica no pacote experimental, utilizando esta como um símbolo da credencial de um canal privilegiado entre o servidor e o cliente. Depois da comunicação estabelecida. Clientes e servidores interagem utilizando uma pacote

25 25 privilegiado chamado pacote de dados, onde são inseridas as credenciais que são transportadas pelo pacote experimental. Ao encaminhar o pacote de dados a primeira verificação que os roteadores fazem é conferir se os dados da credencial são iguais ao da informação que deveria ser inserida dentro do pacote, desde que este fosse experimental. Se as marcações do pacote estiverem corretas o pacote é transmitido, caso contrário o pacote é descartado. São inseridas informações no cabeçalho do pacote IP no campo Flags(3 bits). É utilizado um bit para cada flag: A flag de sinalização (SF) é usada para indicar que o pacote não é privilegiado, está informação pode estar no pacote experimental ou no pacote de dados. A flag do tipo pacote (PT) se está setada, indica que é um pacote de dados, caso contrário um pacote experimental. A flag de atualização da credencial (CU) quando setada, indica que o preenchimento da resposta no campo é opcional no cabeçalho. Qualquer cliente que desejar interagir com um servidor através de um canal privilegiado deve se adequar ao protocolo de comunicação para obter uma credencial. Assim podendo inserir os seus pacotes privilegiados, e vice-versa para a comunicação do servidor com o cliente. O protocolo está representado na figura 5 com as trocas de mensagens que ocorrem entre Servidor e cliente. Figura 6 Comunicação entre Cliente e Servidor Fonte: YAAR (2004) Através de um canal seguro é estabelecida a comunicação entre o cliente e o Servidor: Cliente - Envia um pacote experimental para o Servidor, com marcação alfa no pacote.

26 26 Servidor - Responde incluindo a marcação alfa no campo da credencial no mesmo pacote experimental. Cliente - Envia o primeiro pacote de dados com a marcação beta no campo da credencial e com marcação alfa no pacote. Servidor Inclui no pacote experimental a resposta no campo da credencial. O mecanismo SIFF tem um design inovador que aborda o problema de ataques DDoS num ambiente de rede futuro, pode também ser implantado na internet atual. Desde que os equipamentos sejam atualizados. 3.4 Lightweight DDoS Flooding Attack Detection Using NOX/OpenFlow Este trabalho mostra uma opção de como minimizar ataques DDoS em uma rede OpenFlow (BRAGA et. al, 2010). Usando o Switch OpenFlow os autores analisaram os principais problemas que deveriam ser tratados para mitigação dos ataques. O primeiro aspecto analisado foi o cabeçalho do pacote, a fim de identificar se o pacote é legítimo ou não. Outro aspecto foi o volume padrão de fluxo da rede, esse no momento que a rede não esteja sendo atacada. Tendo como base essas premissas os autores optaram por usar redes neurais para identificar volumes de fluxo normal na rede. Foi utilizado o método de Mapas autoorganizáveis (SOM) (KOHONEN et al, 1990), que são redes neurais artificiais com o aprendizado não-supervisionado e capazes de detectar padrões, característica que contribui com a identificação desses fluxos. A arquitetura do método, representado na figura 1, usa o Controlador NOX, que interage diretamente com os switches solicitando e enviando informações. O Controlador NOX encapsula três módulos, que são: 1) Módulo coletor de fluxo é responsável por periodicamente solicitar através do canal seguro todas as entradas de fluxo que estão registradas nas tabelas de fluxo dos switches, que retransmitem as repostas pelo mesmo canal seguro. 2) Extrator de características - recebe fluxos coletados, extrai as características desses fluxos e insere na 6-tupla, correspondente a seis campos que auxiliam na classificação do fluxo. Essas características são importantes para detecção de ataques DDoS. Depois de constituir a 6-tupla, está é enviada para o módulo classificador.

27 27 3) Classificador (SOM) analisa se a 6-tupla corresponde 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. Figura 7 Operação do Loop de Detecção Fonte: MCKEOWN (2008) Uma descrição mais detalhada de cada campo da 6-tupla segue: 1) Média de pacotes por fluxo (APF): este campo corresponde a uma média de pacotes por fluxo. 2) Média de Bytes por fluxo (ABF): este campo informa o valor médio do tamanho do payload do pacote enviado. 3) Duração média por fluxo (ADF): este campo informa o valor médio do tempo de duração de um fluxo ao passar na tabela de fluxo. 4) Percentual de pares de fluxos (PPF): Este campo informa quantos pares de fluxos podem ocorrer num intervalo de tempo de um fluxo. Por 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.

28 28 5) Crescimento de um único Fluxo (GSF): Este campo informa o crescimento do número de fluxos no inicio de um ataque. 6) Crescimento de diferentes portas (GDP): Este campo informa a quantidade de portas diferentes que são geradas num ataque. Na infraestrutura de rede implementada na arquitetura todos os switches OpenFlow precisam autenticar-se no controlador NOX para autorizar a troca de pacotes entre os hosts. Cada pacote que circula pelo switch tem seu cabeçalho comparado com as entradas das tabelas de fluxo do switch. Caso o cabeçalho comparado corresponder com alguma entrada, o cabeçalho do pacote e suas estatísticas são atualizados (por exemplo, o número de bytes e de pacotes são incrementados), caso contrário, se nenhuma entrada de fluxo (na tabela de fluxo do switch) corresponder ao cabeçalho do pacote a entrada é encaminhada para o controlador. Por sua vez, o controlador pode adicionar, de acordo com a política definida, uma nova entrada de fluxo para a tabela de fluxo de cada switch. Assim, os tráfegos gerados por todos os hosts conectados ao switch irão preencher a tabela de fluxo do switch. 3.5 OpenFlow based Flow Level Bandwidth Provisioning for CICQ Switches Neste trabalho foi estudado (JIN et al, 2011) como dentro de uma plataforma OpenFlow a largura de banda pode suprir o nível de fluxo. O OpenFlow fornece um conjunto de opções para definir os fluxos. Com base na combinação de campos do cabeçalho do pacote e em uma tabela de fluxo, permite aos usuários flexibilidade para controle deste tráfego. A implementação da melhoria na largura de banda é um componente essencial do OpenFlow para isolar o tráfego entre diferentes experimentos ou tipos diferentes de tráfego dentro de uma mesma experiência. Na atual implementação do OpenFlow é suportado apenas um algoritmo baseado na modelagem de tráfego, que é necessário, mas não garante a performance. Para uma performance eficaz a primeira proposta foi o algoritmo FEBR (Implantação do nível de fluxo da banda larga ) que irá combinar várias entradas e saídas dentro de um switch através de chaves especiais que fazem esta conexão, possuem um buffer crosspoint pequeno. Este buffer crosspoint separa as entradas e saídas, simplificando o processo de escalonamento.

29 29 A implementação do algoritmo FEBR será de forma prática, pois a plataforma OpenFlow trabalha com vários switches OpenFlow, onde será aplicado o algoritmo e um ou mais controladores. O controlador interage com os switches através do protocolo OpenFlow. Com o algoritmo implementado o controlador será capaz de definir um fluxo arbitrariamente e informar aos switches OpenFlow o caminho de roteamento para prover a largura de banda desejada Descrição do Algoritmo FEBR A ideia do algoritmo é reduzir o escalonamento do switch, onde são relatados três problemas. O escalonamento de fluxo, o escalonamento de entrada e o escalonamento de saída. O escalonamento de fluxo seleciona um pacote das filas de fluxo e envia para o buffer da fila de saída virtual correspondente. No escalonamento de entrada é selecionado um pacote de uma das entradas do buffer da fila de saída virtual e é enviado para o buffer crosspoint correspondente. No escalonamento de saída é selecionado um pacote de uma das entradas do buffer crosspoint que é enviado diretamente para a saída. Na figura está representado o algoritmo. Figura 8 Algoritmo FEBR Fonte: JIN (2011)

30 30 O algoritmo FEBR apresenta algumas vantagens: pode ser implementado de forma distribuída, pois não possui um escalonador centralizado e as diferentes entradas e saídas não necessitam trocar informações entre elas. O tempo final de saída do pacote do buffer da saída virtual pode ser calculado pela entrada e transportado pelo pacote até o buffer crosspoint do escalonamento de saída. Outra vantagem é que o FEBR pode processar diretamente pacotes de tamanho variável sem precisar segmentar e remontar o pacote. O escalonamento de pacotes de tamanho variável pode alcançar um melhor rendimento e uma latência menor. Assim o FEBR não requer uma velocidade alta e tem um tamanho pequeno de buffer crosspoint, reduzindo o custo do hardware. 3.6 Considerações sobre os Trabalhos relatados Os trabalhos relatados abordam assuntos sobre mitigação de ataques DDoS, sobre OpenFlow ou uma fusão entre os dois assuntos. Cada trabalho apresenta seus pontos positivos e negativos. A implementação (BRAGA et al., 2010) trabalha com padrão de fluxo envolvendo a arquitetura OpenFlow e redes neurais. Um benefício interessante no mecanismo implementado é a utilização do método de Mapas Auto-Organizáveis (SOM), que pode ser utilizado tanto em uma plataforma OpenFlow quanto em uma rede de uma empresa, com a finalidade de obter um padrão de fluxo de tráfego na rede. Outra vantagem foi utilizar esse sistema na arquitetura OpenFlow que fornece benefícios, pois usa um protocolo próprio de comunicação, facilitando a identificação dos fluxos. Neste trabalho alguns aspectos não foram supridos, como a detecção de ataques entre redes de domínios diferentes que no caso da arquitetura OpenFlow não seria um grande problema, mas se tratando de uma rede que utiliza somente o protocolo IP para comunicação seria uma inviabilidade. O D-ward para ser considerado como sistema eficaz, necessita ser instalado em toda a rede. Para isso acontecer, os roteadores vendidos no mercado teriam que anexar essa implementação. Como o sistema é agregado na rede local facilita o bloqueio de pacotes de ataque de forma ágil, pois com o fluxo menor de pacotes utiliza estratégias mais complexas de detecção com uma maior precisão. Este método trabalha com estatísticas de tráfego, porém não utiliza nenhum método de padrão de tráfego, tipo o método SOM (BRAGA et al., 2010), mas utiliza um componente

31 31 que modela tráfegos a partir de estatísticas de conexões. Uma falha que pode ocorrer no sistema é o descarte de pacotes legítimos por estarem marcados como pacotes de ataques. No mecanismo Pushback o DDoS é tratado como um problema de congestionamento, é utilizado um método de assinatura de congestionamento nos pacotes. Essa assinatura pode constar em pacotes legítimos, mudando o percurso desse pacote. Uma fragilidade deste trabalho é a possibilidade de ocorrência de falsos positivis: como assinatura é calculada a partir da comparação com a tabela de roteamento, ocorrerão casos que os pacotes legítimos também serão encaminhados para fluxos congestionados. O sistema SIFF tenta minimizar os ataques DDoS através da troca de informações por credenciais, possibilitando que o usuário que sofrerá um ataque consiga interromper a comunicação. Está implementação é considerada inovadora, desde que esteja agregada em todos equipamentos. O sistema se torna inviável para redes instáveis, pois a implementação foi feita baseada em redes estáveis, até por não trabalhar com um mapeamento de tráfego da rede. O último trabalho relatado implementa um algoritmo para a largura de banda poder suprir o nível de fluxo desejado na arquitetura OpenFlow. Está implementação se torna viável, pois trata de uma rede que possui equipamentos que adotam um protocolo próprio de comunicação. Nessa mesma arquitetura é empregado um controlador que define e direciona os fluxos para os switches OpenFlow através do mesmo protocolo, que torna difícil a implementação em um rede normal que se comunica somente através do protocolo IP. Com base na análise apresentada, pode-se identificar um conjunto de características favoráveis à identificação de ataques DDoS. A proposta apresentada neste trabalho procura combinar essas várias características em um único sistema, conforme apresentado no capítulo a seguir.

32 32

33 33 4 PROPOSTA Os trabalhos citados no capítulo 3 apresentam diferentes formas de minimizar ataques DDoS dentro de uma rede, seja uma plataforma OpenFlow ou não. A contribuição deste trabalho é investigar uma melhor forma para fazer a mitigação de ataques DDoS em uma plataforma OpenFlow. Analisando as implementações e métodos utilizados nos trabalhos relatados, visando unificar metodologias que apresentaram um bom desempenho, foi elaborado o modelo apresentado neste trabalho. Através de pesquisas realizadas pode ser observado que a plataforma OpenFlow tem muito a agregar ao método apresentado pela sua vantagem em trabalhar com divisões de fluxos (pesquisa e produção), onde cada fluxo pode ser utilizado para testar experimentos diferentes. Por exemplo, podemos ter um fluxo com pacotes com um determinado MAC de destino, outros que tratam pacotes que não utilizam IPV4 e sim o MAC para identificação. A partir de alguns exemplos citados verificou-se que o OpenFlow pode suportar diferentes tipos de experimentos. Com a vantagem de ser possível executar testes de diferentes experimentos através de uma forma programável dos fluxos utilizando um protocolo de comunicação próprio a arquitetura OpenFlow tem a acrescentar no método, possibilitando uma estrutura estável para receber métodos que em conjunto amenizem os ataques DDoS. Figura 9 Arquitetura do Sistema MADROF Fonte: Gabriele (2012)

34 34 Conforme a arquitetura apresentada na figura 9 o método funciona da seguinte forma: 1) Clientes (Computadores ligados ao roteador) acessam páginas web ou enviam dados (via FTP, UDP, ICMP) para Internet. Essas operações geram fluxos de pacotes que serão analisados pelo roteador OpenFlow antes de seguirem seu caminho para internet. 2) Roteador OpenFlow recebe os fluxos de pacotes e envia estatísticas de fluxo que contém o número de bytes enviados e recebidos e o número de conexões ativas no momento. Recebe do Sistema MADROF as novas regras de limite de taxa para comparar com as anteriores e fazer uma análise do fluxo, para não encaminhar os fluxos de pacotes não legítimos para Internet. 3) Controlador NOX armazena as estatísticas de fluxo de tráfego e direciona os fluxos de pacotes para a rede conforme as regras de limite de taxa aplicadas pelo roteador. 4) Sistema MADROF - recebe as estatísticas de fluxo de tráfego do roteador que contém o número de bytes recebidos e enviados e o número de conexões ativas e compara com os modelos pré-definidos do protocolo TCP, UDP e ICMP. Com o resultado da comparação faz o ajuste das regras da taxa limite e envia para o roteador novamente. Na Figura 10 que segue abaixo, serão apresentados de uma forma mais detalhada os componentes do Sistema de MADROF. Figura 10 Sistema MADROF Fonte: Gabriele (2012)

35 35 Componente de Monitoração Faz a modelagem do tráfego a partir dos parâmetros recebidos do Roteador e envia para Classificação de Fluxo. Os modelos de fluxo podem ser do tipo TCP, UDP e ICMP, que são definidos respectivamente: a razão dos pacotes enviados e recebidos, o valor máximo de taxa permitida por conexão e a de mensagens solicitadas e respondidas. Classificação de Fluxo - é feita a comparação do fluxo atual com o modelo anterior de fluxo com seus limites de taxa ajustados, e o resultado da comparação é enviado para o Realimentador. Realimentador recebe a resposta da comparação dos fluxos, faz o ajuste das novas regras de limite de taxa e realimenta o roteador atualizando seus parâmetros. Este sistema utiliza estatísticas de tráfego para classificar fluxos de pacotes legítimos e ilegítimos, armazenando estas estatísticas em uma tabela Hash com tamanho limitado. A ideia é utilizar o controlador NOX para armazenar essas estatísticas, evitando assim o limite de tamanho da tabela Hash. Outra verificação é o relato abordado no trabalho Jin et al. (2011) onde é destacado que existe um problema na plataforma OpenFlow sobre vazão de fluxo, que é tratado no trabalho com o algoritmo FEBR. Este algoritmo aperfeiçoa a forma que o switch faz o escalonamento dos fluxos de entrada e saída de pacotes aperfeiçoando o nível de fluxo. Ainda existe a limitação de ter que acoplar esse sistema a cada roteador de borda ou ligado a rede local para obter os benefícios apresentados.

36 36

37 37 5 CRONOGRAMA As seguintes etapas foram definidas para a realização deste trabalho: TCC2 Tarefas 1 á Simulação e testes em uma Plataforma OpenFlow. 2. Desenvolvimento da aplicação. 3. Validação dos resultados obtidos. 4. Escrita do artigo. 5. Entrega do artigo e apresentação do trabalho. Tabela 1 Cronograma de Atividades Fev Mar Abr Mai Jun Jul 1 X X X 2 X X 3 X X 4 X X X 5 X Fonte: Gabriele (2012).

38 38

39 39 6 REFERÊNCIAS JIN H et al. (2011), OpenFlow based Flow Level Bandwidth Provisioning for CICQ Switches, Florida International University, Disponível em: plore.ieee.org%2fxpls%2fabs_all.jsp%3farnumber%3d Acesso em: 16 de novembro de 2012 FARIAS F.et al (2011), 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: - Acesso em: 10 agosto 2012 MENEGAZZO C et al (2011), Arquitetura para Mitigação de Ataques DDoS. Departamento de Informática Universidade Federal do Paraná NR2 - Núcleo de Redes Sem Fio e Redes Avançadas. Disponível em : Acesso em: 20 outubro 2012 SACHDEVA M et al (2010), 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 Acesso em: 20 outubro 2012 BRAGA R. et al (2010), Lightweight DDoS flooding attack detection using NOX/OpenFlow, In: CONFERENCE PUBLICATIONS, Oct Dept.de Cienc.da Comput.,Univ. Fed. Do Amazonas,Brazil. Disponível em: plore.ieee.org%2fxpls%2fabs_all.jsp%3farnumber%3d Acesso em: 08 agosto 2012 SHERWOOD R. et al, (2009), FlowVisor: A Network Virtualization Layer Deutsche Telekom Inc R&D Lab, Stanford University Disponivel em : flowvisor.pdf Acessado em : 10 agosto de 2012 MCKEOWN A. et Al (2008), Openflow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38: Disponível em : em: 10 agosto 2012 YAAR A. et al (2004), SIFF: A Stateless Internet Flow Filter to Mitigate DDoS Flooding Attacks, Carnegie Mellon University, Disponível:

40 40 Acessado em : 05 de novembro de 2012 MIRKOVIC J. et al. (2002), Attacking DDoS at the Source University of California Los Angeles Computer Science Department Disponível em : plore.ieee.org%2fxpls%2fabs_all.jsp%3farnumber%3d Acesso em: 08 agosto 2012 IONNIDIS J. et al,( 2002), Implementing Pushback: Router-Based Defense Against DDoS Attacks, Columbia University, Disponível em : Acesso em:10 de outubro de 2012 IOANNDIS J et al, (2001), Controlling High Bandwidth Aggregates in the Network Extended Version. Disponível em: Acessado em : 03 de novembro de 2012 OPENFLOW, Disponível em: < Acesso em: 10 agosto de Exame, I. (2012), - Acesso em: 20 outubro 2012 Departamento de Segurança da Informação e Comunicações, Acesso em: 20 outubro 2012