Uso irresponsável do T50

ATUALIZAÇÃO (2014-11-20)

Uma rápida atualização (20 de Novembro de 2014), contendo uma pequena lista onde o T50 está integrado em algumas distribuições Linux:



ATUALIZAÇÃO (2013-12-24)

Uma outra atualização (24 de Dezembro de 2013), contendo alguns trabalhos acadêmicos onde o T50 é utilizado como uma ferramenta de apoio aos estudos.

Isto demonstra que "muitos profissionais que vem utilizando o T50 de forma responsável para medir a capacidade de operação e proteção de suas redes em situações de grande volume de tráfego", conforme já havia mencionado neste texto.

Seguem os artigos (caso você também tenha realizado algum trabalho acadêmico, peço que envie-me):

ATUALIZAÇÃO (2012-06-27)

Uma pequena atualização (27 de Junho de 2012) que, na minha humilde opnião, retrata muito bem todo o tema em torno do uso irresponsável do T50:
"Quemadmodum gladius neminem occidit, occidentis telum est." (Epistulae morales ad LuciliumLucius Annaeus Seneca)
[TRADUÇÃO: Uma espada nunca mata ninguém, é uma ferramenta na mão do assassino.]

ARTIGO ORIGINAL

Há muito tempo não escrevo um artigo em português, assim como já faz muito tempo que nada escrevo sobre este tema, porém nos últimos dias foram liberados alguns alertas sobre a utilização do T50 para fins de DoS e DDoS e me senti na obrigação de romper com o silêncio.

Antes de continuar, quero re-afirmar que NÃO APÓIO:
  1. O uso irresponsável do T50 e me sinto desrespeitado quando grupos de pessoas o utiliza desta forma, pois fui categórico ao colocar um aviso no "help/usage" do T50:
    • "5. Be nice when using t50, the author DENIES its use for DoS/DDoS purposes."
  2. Qualquer uso do T50 para finalidade de DoS e DDoS contra qualquer entidade, empresa, instituição, etc.
  3. As causas, os grupos de pessoas e as formas como estes grupos de pessoas estão se manifestando.
T50, como alguns já devem saber, já está integrado na distribuição Backtrack, portanto sua finalidade de testar redes TCP/IP foi comprovada através desta integração e dos muitos profissionais que vem utilizando o T50 de forma responsável para medir a capacidade de operação e proteção de suas redes em situações de grande volume de tráfego e para isso não precisam mais comprar ou alugar equipamentos caros para realizar estes testes. Este é um exemplo do uso responsável do T50.

Porém, buscando evitar o uso irresponsável do T50, foram criadas algumas "travas" dentro do próprio código, entre elas uma trava para adequação com as RFC1700RFC1918 e RFC3330, com a qual impossibilita o uso proposital ou acidental do T50 contra redes com endereçamento válido na Internet, fazendo do T50 uma ferramenta de uso exclusivo para redes locais. Porém esta "trava" não seria um problema para desenvolvedores mal-intencionados que quisessem modificar o T50 para uso proposital contra redes com endereçamento válido.

A intenção principal da criação e, consequentemente, da liberação do código do T50 (Web Security Forum) foi apenas proporcionar e compartilhar uma ferramenta de testes de estresse em redes TCP/IP com administradores e profissionais de segurança em rede de computadores, porém, assim como tantas outras ferramentas criadas e amplamente utilizadas, o T50 começa a ser utilizado de forma irresponsável (deturpada) e com finalidades mal-intencionadas. 

Como muitos já devem saber, as técnicas empregadas no T50, com exceção do envio de multi-protocolos, não são novidades e já eram amplamente conhecidas pela comunidade de segurança (CA-1996-21).

Atualmente não faço mais parte do time de projeto do T50, porém a equipe atual manteve algumas "travas" dentro do código.

Assim como compartilhei a ferramenta, por acreditar que compartilhar o conhecimento é uma das melhores formas de se educar os profissionais e entusiastas de segurança, seguem algumas dicas, onde compartilho algumas idéias, de como se proteger destes tipos de ataque:
  1. Bloqueio no segmento de borda de qualquer protocolo que não seja utilizado pela empresa. Por exemplo:
    • Se o segmento de borda não utiliza tráfego IGMP, este tráfego deverá ser bloqueado.
    • Bloqueio de qualquer protocolo de uso "exclusivo" interno, como por exemplo: RIP, DCCP, RSVP, GRE, EIGRP e OSPF.
  2. Criação de ACLs em Routers/Firewalls, assim como criação de políticas de NIPS, para bloqueio de anomalias nos protocolos. Por exemplo:
    • Se o segmento de borda utiliza IPSec, mas o pacote IPSec venha com os cabeçalhos AH e ESP sem "payload", este tráfego deverá ser bloqueado por ser um tráfego anômalo.
    • Tanto o T50 quanto algumas outras ferramentas utilização geração aleatória de valores para alguns campos de cabeçalho de protocolos, portanto isto deve ser considerado uma anomalia e seu tráfego, consequentemente, deve ser bloqueado.
  3. Para TCP SYN Flood (RFC4987), utilize SYN cookies e defesas contra anomalias do protocolo TCP.
  4. Para UDP Flood, bloqueie qualquer tráfego não necessário para este protocolo.
  5. Monitore anomalias estatísticas do volume de tráfego na rede. Por exemplo:
    • Ataques de TCP SYN Flood, assim como demais TCP Floods, possuem pacotes de aproximadamente 40 bytes, sendo que sua utilização não deve passar de ¼ do total do tráfego TCP (obviamente esta métrica deve ser minuciosamente avaliada para cada ambiente).
  6. Tenha um contato técnico interno na sua operadora de acesso à Internet, pois somente as operadoras poderão, de forma muito mais eficaz, criar ACLs para Ingress Filters (RFC2827/RFC3704), bloqueando pacotes com IP Spoofing. Por exemplo:
    • Tráfego com endereçamento IP do bloco de endereços pertencente ao Rio de Janeiro que venham por canais de comunicação de São Paulo sugerem que este tráfego utiliza IP Spoofing, portanto a operadora será capaz de criar ACLs impedindo a propagação deste tráfego.
  7. Crie ACLs para Egress Filters (RFC3013), impedindo que sua rede seja uma origem de ataques com IP Spoofing.
  8. Crie ACLs para Ingress Filters (RFC2827/RFC3704), bloqueando os endereços IP contidos e listados nos seguintes documentos:
Outras formas, um pouco mais esotéricas, podem ser adotadas. Por exemplo:
  1. Rate Limiting
  2. Connection Limiting
  3. Traffic Shaping
  4. Quality of Service
  5. Blackhole
  6. Sinkhole
Cordialmente.
Nelson Brito