3.1: Dificuldades de defesa contra DDoS

Uma série de características do DDoS o tornam um desafio difícil de combater. Os ataques de alagamento feitos em DDoS alvejam um recurso específico da vítima e tentam esgotá-lo, criando um sem número de pacotes a ele destinado. Como estes ataques não precisam de um tipo de pacote específico, cria-se uma variedade deles, que se misturam ao tráfego legítimo, que terá poucas chances de conseguir resposta, não só por em geral ser menor em número, mas por a vítima detectar que está sofrendo congestionamento e passar a baixar ainda mais a velocidade de resposta do recurso, para poder atender a todos os requerimentos – falsos ou verdadeiros.

Como já foi mostrado, existe um bom número de ferramentas para DDoS difundidas na internet, facilmente encontradas. Com elas, é fácil fazer o tráfego de ataque passar-se por tráfego legítimo - e pode-se ainda usar IP spoofing. Com um alto tráfego em controle do atacante, não só se sobrepuja o recurso da vítima, como também torna-se difícil caracterizar o tráfego como legítimo ou falso. E, mesmo que se consiga isto, ainda se encontra dificuldade nos números, pois são dezenas, centenas ou milhares os agentes a serviço do atacante, distribuídos em máquinas ao longo da internet. A própria forma como a internet foi desenvolvida, para permitir fácil acesso, gera uma série de brechas das quais se pode aproveitar para mais ataques.

Com o número e eficiência de ataques apenas aumentando, muito se investiu em P&D para enfrentá-los. Mesmo assim, o combate ainda é difícil, e as dificuldades são, sobretudo, IP spoofing, similaridade entre pacotes legítimos e falsos, prontidão e performance dos sistemas.

3.2: Prevenir e remediar

Prevenir sempre é melhor que remediar, quando possível. Existem duas formas de prevenir ataques de negação de serviço: Evitar que atacantes ajam ou  aumentar as capacidades do sistema para resistir a cargas de tráfego, para que um ataque falhe ao tentar sobrecarregar o sistema e impedi-lo de oferecer serviços a clientes legítimos.

Medidas para evitar que ataques DDoS sejam sequer possíveis incluem impedir que atacantes consigam reunir número suficiente de agentes para atacar, cobrar por uso das redes (de tal forma que conseguir tráfego suficiente para um ataque seja economicamente inviável).

A solução definitiva seria ter sistemas perfeitos.

Mas, como isto é pura fantasia, resta elevar a segurança dos sistemas existentes, tomando medidas plausíveis:

·        Melhor programação elevará o nível da segurança das aplicações e dos sistemas operacionais. Há já métodos conhecidos para evitar bugs de segurança conhecidos, como overflows de buffer. Um programador melhor educado terá capacidade de reduzir a freqüência de alguns destes problemas.

·        Melhorias no desenvolvimento e projeto de software e ferramentas de teste podem ajudar programadores a escrever códigos que não tenham falhas óbvias de segurança.

·        Melhorias na segurança de sistemas operacionais, tanto da perspectiva de código quanto modelos de segurança melhor desenvolvidos reduzirão as chances de um atacante de achar vulnerabilidades a serem maliciosamente exploradas.

·        Ferramentas automatizadas para verificação de programas melhorarão a capacidade de encontrar erros nos códigos, permitindo que desenvolvedores de software façam declarações mais absolutas sobre a segurança de seus códigos. Isso permitiria aos consumidores escolher os produtos mais seguros.

 

Se não for possível prevenir um problema, só resta remediá-lo. E em se tratando de ataques de Negação de Serviço, às vezes é melhor remediar do que propriamente prevenir. Existem muitos ataques ocorrendo na internet, mas as vítimas são relativamente poucas. Se os ataques têm vítimas mais direcionadas e o custo de prevenção contra eles é alto, é melhor investir na reação contra os ataques, que têm menor ou nenhum custo a menos que um ataque efetivamente ocorra.

Mas, reação não significa que não há preparação. Diferente do que acontece quando se está prevenido, para remediar um problema é preciso diagnosticá-lo, ou seja, ele precisa acontecer e ser detectado.

Sendo as medidas contra DoS e DDoS preventivas ou reativas, ou até uma combinação de ambas, há objetivos que se deseja conseguir. A defesa deve ser efetiva, isto é, ela tem que funcionar. Isto vale tanto para medidas que impeçam ataques de ocorrer quanto para reações aos ataques. Deve ser completa no que se refere a ser capaz de lidar com todos os tipos de ataque. Embora este seja um objetivo óbvio, é bastante difícil de se conseguir: novos ataques surgem a todo momento, especialmente para quebrar defesas existentes. As defesas devem também ser capaz de continuar fornecendo serviços a clientes legítimos, que é o principal objetivo das medidas contra DDoS. Para isso, é preciso uma baixa taxa de falsos positivos, ou seja, baixa taxa de tráfego legítimo sendo confundido com tráfego falso. Por fim, deve ser necessário baixo custo operacional e bom retorno, fazendo com que os sistemas operem normalmente durante ataques.

3.3: Mecanismos de defesa e aplicações

Independente de qual é o papel de uma vítima de DDoS, seja ela a vítima final ou uma máscara (agente) do atacante, as medidas de defesa não são muito diferentes. Já vimos que as medidas de prevenção podem não ser as melhores, e que em geral DDoS é um caso onde remediar é mais efetivo – claro, em menor tempo possível, e para isso é necessário entender como opera a rede e ter ferramentas que permitam colher e analisar corretamente dados, de tal forma que seja possível detectar o problema.

O processo de detecção é muitas vezes árduo, por ser pouco perceptível. Poucas são as conseqüências de DDoS que farão o sistema cessar completamente o funcionamento. Conexões lentas muitas vezes podem ser confundidas com problemas internos no serviço de internet, e dificilmente pensar-se-ia em um ataque DoS. É preciso implementar medidas de detecção com amplo número de atividades malignas, que possam diagnosticar e caracterizar o problema, algo que, detectada a anomalia, é muito menos difícil tendo alguma amostra do tráfego. Com isso é possível saber não só o tipo de ataque, mas também de onde ele vem. Ainda que não seja sempre possível chegar ao atacante, pode-se chegar aos agentes e operadores.

A seguir deve-se, finalmente, reagir, bloqueando o tráfego falso e identificando os servidores comprometidos no envio deles. Por fim, é preciso sempre documentar os procedimentos, para ter uma base de informações mais rica, que permita refinar cada vez mais as contra-medidas.

3.4: Linhas de pesquisa de defesa

Negação de Serviço é um problema real em Redes de Computadores, e muito tem se estudado e pesquisado para combater as ameaças. A seguir estão enumeradas e brevemente descritas algumas linhas de pesquisa em defesa contra DoS:

3.4.1: Novo Sistema de Rastreamento de Pacotes IP

Proposto por Laufer et al. no Grupo de Teleinformática e Automação da Universidade Federal do Rio de Janeiro (GTA-UFRJ). É um sistema de rastreamento de pacotes IP para determinar a origem de cada pacote recebido pela vítima. Cada roteador pelo qual passou o pacote insere nele uma assinatura que indica esta passagem. Uma técnica de filtro de Bloom (Estrutura de dados para compactação de conjuntos de elementos) é usada para que estas informações sejam minimizadas e permaneça constante para não fragmentar os pacotes. Propôs-se ainda uma generalização de filtros de Bloom para que o atacante não possa forjar as assinaturas.

Um campo fixo no pacote é reservado para alojar o filtro de Bloom onde estará armazenada a rota do pacote. Cada roteador, antes de encaminhar o pacote, insere nele seu IP de saída. Desta forma, ao receber o pacote, o receptor tem uma rota de todos os componentes da rota de ataque.

A vantagem desta abordagem é poder reconhecer a origem de cada pacote individualmente. Além disso, nenhum  estado é armazenado na infra-estrutura da rede: todos os dados do rastreamento ficam com a própria vítima-receptor. Todavia, o uso dos filtros de Bloom pode gerar falsos positivos – adicionando um roteador que não fez parte da rota de ataque à reconstrução desta ou falsos negativos – a não adição de um roteador que fez parte da rota de ataque.

3.4.2: Pushback

Proposto por Mahajan et al., a idéia é de que operadores de rede “empurrem” de volta o tráfego de ataque até a fonte, seja desconectando os cabos de rede do roteador e verificando se o tráfego pára, ou observando o tráfego da rede em equipamentos de monitoração.

3.4.3: D-WARD

Proposto por Mirkovic et al., e desenvolvido na UCLA sob supervisão da DARPA. Almeja detectar ataques antes que eles deixem a rede na qual residem os agentes DDoS. É um sistema transparente aos usuários da rede, que coleta estatísticas de tráfego bidirecional do roteador à rede fonte e as compara a modelos de tráfego construídos de acordo com especificações de protocolos de transporte e aplicação, refletindo tráfegos legítimos, suspeitos e de ataque, aplicando limitações às taxas dos considerados suspeitos e ilegítimos. A opção de diminuir e não bloquear a taxa faz com que o sistema se recupere mais eficientemente de falsos positivos.

O D-WARD foi testado internamente e obteve bons resultados, detectando rapidamente os ataques. Suas vantagens são de detectá-los e controlá-los, assumindo que os tráfegos falsos são suficientemente diferentes dos tráfegos legítimos. A opção de limitar as taxas permite poucos efeitos colaterais, e a resposta às ofensivas é rápida.

3.4.4: NetBouncer

Outra proposta supervisionada pela DARPA, de E. O’Brien. É um mecanismo de legitimação de clientes, permitindo tráfego apenas para os legítimos. Para isso, vários testes são efetuados sobre o usuário/cliente. Uma vez autenticado, o cliente é adicionado ao grupo de clientes legítimos, aos quais é dada preferência sobre o grupo de clientes ainda não legítimos. Para evitar que o atacante forje uma autenticação, ela expira em um determinado intervalo de tempo, sendo necessária uma nova legitimação, passando pelo mesmo teste anterior ou um outro.

Embora tenha seus aspectos positivos, fornecendo bom serviço aos clientes legítimos na maioria dos casos, o NetBouncer assume certas características e capacidades dos clientes, como poder responder a pings, algo que nem todos farão, sobretudo aqueles operando sob um firewall.

As vantagens deste método é de não exigir modificações em protocolos, servidores ou clientes, sejam os da própria rede ou de outras. Mas ainda é possível conseguir um exército de agentes e forjar seus IPs, eventualmente conseguindo um que seja de um cliente legítimo.

3.4.5: Secure Overlay Service (SOS)

Com o objetivo de rotear apenas tráfego legítimo aos servidores, descartando os considerados ilegítimos, este método foi proposto por Keromytis et al. Os clientes deverão primeiro contatar pontos de acesso que verificarão a legitimidade dos pedidos, antes de permitir a entrada destes clientes na rede.

SOS foi projetado para funcionar em redes operando sob um firewall, como redes empresariais. Os pacotes precisam passar primeiro pelos pontos de acesso, e o firewall se encarrega de descartar os demais pacotes e aceitar as conexões já confiáveis.

Este método fornece proteção à comunicação com clientes legítimos. Todavia, soluções deste tipo podem ser sobrepujadas por ataques em massa sobre o firewall.

3.4.6: Prova de Trabalho

Sugere ao cliente um desafio criptografado e espera por sua solução, à qual estará atrelado o oferecimento ou não do serviço. É o método antibots mais usado atualmente, e presente geralmente em conjunto com mecanismos de autenticação em websites. Sua forma mais comum é apresentar junto à autenticação uma figura onde caracteres são representados e devem ser informados pelo usuário a uma caixa de diálogos. Bots podem forjar autenticidade pura com relativa facilidade, exaurindo o número de conexões do servidor, mas métodos de reconhecimento de padrões para detectar os caracteres em imagens ainda é difícil.

3.4.7: DefCOM

Outra proposta de Mirkovic et al., parceria da UCLA com a Universidade de Delaware que se baseia em defesas de núcleo de rede, sob perspectiva da vítima e da fonte. Detecta o ataque ocorrente e limita o tráfego, enquanto ainda respondendo a pedidos legítimos. É composto de três tipos de nós (roteadores ou servidores): geradores de alerta que detectam ataque; limitadores de taxa de tráfego e classificadores, separando pacotes legítimos de pacotes suspeitos, marcando-os. Os dois primeiros tipos de nós trabalham nas bordas da rede e o último opera no núcleo desta.

Em suma, DefCOM detecta ataques na rede da vítima, limita tráfego no núcleo desta e bloqueia tráfegos suspeitos/de ataque na rede da fonte. Utiliza o também proposto D-WARD como nó classificador para melhorar resultados.

3.4.8: COSSACK

Uma proposta de Papadopoulos et al. e desenvolvida na Universidade do Sul da Califórnia. Objetiva evitar que ataques sequer saiam do escopo da rede-fonte (é portanto mais um método de prevenção). Este método age na rede-fonte, engatilhado por uma notificação da vítima do DDoS, correlacionando e analisando tráfegos na fonte e detectando tráfego suspeito que será descartado.

Se tráfego legítimo for capturado como um falso positivo, será descartado pelo COSSACK. Esta técnica inova por colocar vigias (watchdogs) nas redes, evitando que elas se tornem redes fontes de ataque, sem que sejam necessárias modificações em protocolos ou aplicações destas redes.

3.4.9: Pi

Defesa baseada na vítima, proposta por Yaar et al., inserindo identificadores de caminho em cabeçalhos de pacotes IP não utilizados (ou pouco utilizados). A idéia principal é que estes identificadores de caminho (ou impressões digitais) sejam inseridos pelos roteadores ao longo do caminho da rede. O alvo ou vítima poderia então rejeitar pacotes com impressões digitais que já foram identificados em outros pacotes, estes sabidos pacotes integrantes de um ataque.

No esquema básico de marcação do Pi, cara roteador marca alguns bits no campo de identificação do pacote IP. A localização da marca dentro deste campo é definida pelo valor do campo TTL (tempo de vida ou time to live) do pacote. Como o TTL decrementa a cada passagem por um roteador, um caminho contíguo do pacote é construído enquanto ele se aproxima da vítima.

Este método assume que a vítima saberá identificar o volume de um tráfego de ataque, por exemplo selecionando uma alta porção de tráfego de entrada com uma mesma marcação. Naturalmente, isso pode gerar o descarte de falsos positivos que são, na verdade, tráfego legítimo contendo a mesma marca do ataque.

O método Pi entra em ação após o primeiro pacote ser identificado (pelo alvo). Por isso, está ainda sujeito a ataques por inundação, como a maioria dos métodos de defesa centrados na vítima.

3.4.10: SIFF

Yaar et al. propuseram aliviar ataques DDoS por inundação usando um mecanismo que divide o tráfego de rede em dois: Privilegiado e não-privilegiado. Os destinos finais podem trocar permissões observadas em tráfego privilegiado. Os roteadores verificarão essas permissões, que são dispostas de forma dinâmica, de tal forma que mau-comportamento (ou seja, ataque) implicará no cancelamento destas. Diferentemente de outros métodos, este não requer nenhum mecanismo extra, mas necessita de modificações nos clientes, servidores e roteadores. Os destinos finais usarão protocolo de aperto de mão para trocar permissões, e assim o tráfego privilegiado se propagaria pela rede, diferentemente do tráfego não-privilegiado. Há providências a serem tomadas para que tráfego privilegiado não seja forjado para cometer ataques. Se um destino final começar uma inundação, as credenciais de tráfego privilegiado precisam ser retiradas dele.

Os autores deste mecanismo propõem duas abordagens: Que as redes de próxima geração o integrem ou que as redes atuais incorporem estas técnicas no protocolo IPv4. É incerto que qualquer destas hipóteses desemboque em um sucesso.

Em suma, esta técnica faz muitas assunções, inclusive de que o cliente e o servidor possam atualizar seus protocolos TCP/IP para modificar as permissões. A vantagem é não haver necessidade de cooperação dos provedores de serviços de internet. Também se assume que a capacidade de inundação seja limitada e que roteadores sejam capazes de processar e guardar estados e marcar pacotes. Todas essas presunções são muito restritivas, e estão muito distantes do que se vê na internet.

3.4.11: Filtro de Contagem de Saltos (HCF)

Filtro de contagem de saltos ou Hop-Count Filtering, uma proposta de Jin et al., um projeto da Universidade de Michigan, objetivando defesa contra DDoS através da observação do TTL (um salto é exatamente uma passagem por um roteador, a qual decrementa o valor TTL), evitando tráfego falsificado. Tenta-se inferir uma contagem de saltos e associa-se cada fonte de pacotes que adentra a rede da vítima /alvo a um IP e número de saltos.

O sistema que infere a contagem de saltos começa com o TTL observado e estima o inicial que foi imposto ao pacote pelo remetente. Há apenas alguns poucos valores que sistemas operacionais usam e eles são bem diferentes, o que facilita inferências corretas. A contagem de saltos é então a diferença entre o TTL inicial e o observado.

A distribuição de contagem de saltos segue distribuição normal, já que há suficiente variedade nos valores TTL. Se um atacante planeja derrotar este esquema, terá de adivinhar o correto valor de TTL a inserir em um pacote forjado, tal que o número de saltos deduzido seja exatamente o esperado. A falsificação torna-se, então, difícil, pois o atacante agora tem de forjar o correto valor TTL associado a um dado endereço forjado de uma fonte, acrescido da apropriada diferença na contagem de saltos entre os endereços do atacante e o forjado.

Em geral, o filtro de contagem de saltos é passivo enquanto analisa tráfego e o compara às tabelas de saltos estimados. Se o número de igualdades passar de um determinado limiar, a filtragem começa. As tabelas de entrada são constantemente atualizadas examinando uma conexão TCP escolhida aleatoriamente dentro da rede protegida. Como a técnica não impede que o atacante efetue um ataque, apenas o impede de forjar tráfego, ataques vindos de fontes legítimas, carregando os corretos valores TTL, usando um exército de bots ou worms, não precisando de endereços forjados, ainda seriam problemáticos. E este tipo de ataque é hoje bem simples. Outra iniciativa centrada na vítima, o filtro de contagem de saltos não tem grande eficiência contra ataques de inundação baseados em exaurir o sistema que verifica os valores TTL.