Uso irresponsável do T50

ATUALIZAÇÃO – #08

Um ANÚNCIO (1º de Julho de 2024):
"T50 Homecoming" – Depois de 14 anos, o T50 retorna aos palcos da Hackers to Hackers Conference,  graças ao Rodrigo Branco e ao Filipe Balestra. 
Um pequeno aquecimento para o que está por vir em 2025, quando o T50 completa 15 anos de seu lançamento... Trazendo histórias e informações nunca antes compartilhadas com a comunidade.

PS: Caso você também não saiba, o T50 foi listado, pelo SecurityTrails, como uma das "Top 25 Kali Linux Penetration Testing Tools".

ATUALIZAÇÃO – #07

Uma nova atualização (19 de Junho de 2024), há planos para celebrar os 15 anos do T50 em 2025, pois, infelizmente, não foi possível comemorar o 10 anos, como havia sido planejado.

Estes planos estão sendo discutidos, exclusivamente, com os organizadores da conferência que foi realizado o lançamento do T50 em 2010:
Fiquem ligados nas novidades, que em breve serão liberadas.

Com a pandemia (COVID-19), declarada pela OMS em 11 de Março de 2020, todas e quaisquer grandes aglomerações foram canceladas, impedindo grandes eventos e, consequentemente, não permitindo o planejamento de comemoração dos 10 anos do T50 em 2020 na conferência onde ele foi primeiramente lançado – Hackers to Hackers Conference Seventh Edition.

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:

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:

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