FLDPI/FNSTENV/POP/ADD: Uso irresponsável do T50

ATUALIZAÇÃO – #06

Uma nova atualização (23 de Setembro de 2022) para anunciar que, infelizmente, devido a pandemia de COVID-19, não foi possível celebrar os 10 anos do T50... Porém já estamos em 2022 e as coisas, aparentemente, estão retornando ao normal, principalmente os eventos e conferências presenciais.

O planejamento será celebrar e relembrar os +10 anos do T50 em 2023.

Acompanhem os eventos que foram confirmados e que farão parte desta celebração.

ATUALIZAÇÃO – #05

Uma rápida atualização (21 de Junho de 2019) para anunciar que serão dadas algumas pistas, ao longo do ano de 2019, da celebração que estou planejando para os 10 anos do T50...

Acompanhem os eventos que foram confirmados e que farão parte desta celebração.

ATUALIZAÇÃO – #04

Uma rápida atualização (31 de Outubro de 2017) contendo uma série de episódios do Stay Safe Podcast, onde o T50 está na pauta:

22ª Edição (41:17)
36ª Edição (27:09)

ATUALIZAÇÃO – #03

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

ArchAssault
BlackArch
Debian
Kali Linux (substituindo BackTrack)
Ubuntu

ATUALIZAÇÃO – #02

Uma outra atualização (24 de Dezembro de 2013, 31 de Outubro de 2017 e 27 de Novembro de 2017), 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 documentos:

"ANOMALIAS E SEGURANÇA EM REDES COMPUTACIONAIS: Uma abordagem prática com ataque DOS" (Por Renato Pereira Imaisumi e Henrique Pachioni Martins – Departamento de Informática – Faculdade de Tecnologia de Bauru – 2013).
"SISTEMA DE DETECÇÃO DE INTRUSÃO E BLOQUEIO DE ATAQUES UTILIZANDO IDS-SNORT" (Por Paula Souza – Curso Superior de Tecnologia em Redes – TCC – Faculdade de Tecnologia de Lins – 2013).
"AVALIAÇÃO PREVENTIVA DE VULNERABILIDADE NOS SISTEMAS COMPUTACIONAIS DA UNIVERSIDADE FEDERAL DO CEARÁ" (Por Evelyne Ferreira Avelino – Curso Superior de Tecnologia em Redes de Computadores – TCC – Universidade Federal do Ceará – 2013).
"MÉTODO DE MITIGAÇÃO CONTRA ATAQUES DE NEGAÇÃO DE SERVIÇO DISTRIBUÍDOS UTILIZANDO SISTEMAS MULTIAGENTES" (Por João Paulo Aragão Pereira – Engenharia de Computação – Dissertação – Escola Politécnica da Universidade de São Paulo – 2014).
"SISTEMAS IDS E IPS – ESTUDO E APLICAÇÃO DE FERRAMENTA OPEN SOURCE EM AMBIENTE LINUX" (Por João Ricardo Claro – Curso de Tecnologia em Sistemas para Internet – Monografia – Instituto Federal Sul-Rio-Grandense – 2015).
"ESTUDO DE CASO DE ATAQUES DE NEGAÇÃO DE SERVIÇO" (Por Luiz G. A. Cruz, Péricles D. O. Ramos, Samuel N. D. Vasconcelos e Claudines T. Torres – Curso de Tecnologia em Redes de Computadores – Artigo – Faculdade de Tecnologia de Bauru – 2015).
"TESTES DE SEGURANÇA EM SDN'S, UTILIZANDO HONEYPOT" (Por Helton Ribeiro Lustosa – Engenharia de Computação do Departamento de Computação e Sistemas – Monografia – Universidade Federal de Ouro Preto – 2016).
"PROTEGENDO SERVIDORES DE REDE COM OSSEC-HIDS" (Por Francisco de Assis de Souza Silva – Curso Superior de Tecnologia de Redes de Computadores – TCC – Faculdade de Tecnologia de Lins – 2016).
"SISTEMA DE DETECÇÃO DE INTRUSÃO EM REDES DE COMPUTADORES COM TÉCNICAS DE INTELIGÊNCIA COMPUTACIONAL" (Por Heitor Scalco Neto – Programa de Pós-Graduação em Ciência da Computação – Dissertação – Universidade Federal de Lavras – 2017).
"UMA PROPOSTA DE ARQUITETURA DE SEGURANÇA PARA A DETECÇÃO E REAÇÃO A AMEAÇAS EM REDES SDN" (Por Malxi Barroso Campos e Joberto Martins – Programa de Pós-Graduação em Sistemas de Computação – Artigo – UNIFACS Universidade Salvador – 2017).

Obs.: Caso você também tenha realizado algum trabalho acadêmico, peço que envie-me a URL.

ATUALIZAÇÃO – #01

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 Lucilium, Lucius Annaeus Seneca)

[TRADUÇÃO: Uma espada nunca mata ninguém, é uma ferramenta na mão do assassino.]

ARTIGO ORIGINAL

(9 de Fevereiro de 2012) 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:

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."

Qualquer uso do T50 para finalidade de DoS e DDoS contra qualquer entidade, empresa, instituição, etc.
As causas, os grupos de pessoas e as formas como estes grupos de pessoas estão se manifestando.

O 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 RFC1700, RFC1918 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 estas "travas" não seriam 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 (H2HC e, posteriormente, 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~~. Infelizmente, o time atual decidiu por remover as "travas".

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:

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.

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.

Para TCP SYN Flood (RFC4987), utilize SYN cookies e defesas contra anomalias do protocolo TCP.
Para UDP Flood, bloqueie qualquer tráfego não necessário para este protocolo.
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).

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.

Crie ACLs para Egress Filters (RFC3013), impedindo que sua rede seja uma origem de ataques com IP Spoofing.
Crie ACLs para Ingress Filters (RFC2827/RFC3704), bloqueando os endereços IP contidos e listados nos seguintes documentos:

RFC919, RFC922, RFC1112, RFC1122, RFC1356, RFC1700, RFC1918, RFC2365, RFC3068, RFC3330, RFC3927, RFC5735, RFC5736, RFC5737, RFC5771 e RFC6034.

Outras formas, um pouco mais esotéricas, podem ser adotadas. Por exemplo:

Cordialmente.

Nelson Brito