Seguranca em rede – seguranca da informacao – Agora em outro dominio

Clique aqui e veja nosso novo site

Iae galera,

Estamos agora em outro site… http://www.segurancaemrede.com

E la iremos disponibilizar tudo quanté conteudo que pensarem.

Inclusive os livros que muitas pessoas estao pedindo atraves deste site

Ataque em ferramenta forense da microsoft, O que e Forense

Clique aqui e veja nosso novo site

Clique aqui e veja nosso novo site
Os hackers lançaram um programa que, dizendo eles, pode sabotar a suíte de utilitários forenses que a Microsoft fornece gratuitamente para autoridades no mundo todo.

Conhecida como Decaf, a ferramenta lançada pelos hackers monitora sistemas com o Windows visando detectar a presença do COFEE, uma suíte com 150 utilitários usados pela polícia para a coleta de evidências digitais.

Quando um pendrive com a ferramenta da Microsoft é inserido em um computador com o Decaf, o programa dos hackers executa uma série de medidas contra ela.

A Microsoft fornece o COFEE gratuitamente para as autoridades desde 2007. O COFEE (abreviatura de Computer Online Forensic Evidence Extractor) permite a coleta de histórico de navegação, arquivos temporários e outros dados presentes nos computadores baseados em Windows. A ferramenta da Microsoft é distribuída através da Interpol.

Quando o COFEE vazou na internet em novembro de 2009, a Microsoft minimizou a possibilidade de que os hackers poderiam criar contra-medidas contra sua ferramenta.

O Decaf pode remover os logs do COFEE, desativar os drives USB e até mesmo contaminar ou simular uma grande variedade de endereços MAC (identificadores únicos de placas de rede). Futuras versões permitirão que os usuários travem remotamente os sistemas protegidos.

O Decaf pode ser encontrado em quase todos lugares da internet hoje, a partir do BitTorent.

___________________________________________________________

O que é Prática Forense?

Prática forense é a aplicação de técnicas científicas dentro de um processo legal. Essas práticas envolvem pesquisadores altamente especializados – ou criminalistas – que localizam vestígios. Mas esses vestígios só podem proporcionar provas conclusivas quando são testados em laboratório.

Como os criminosos desenvolveram vias cada vez mais criativas de driblar a lei, nossa força policial foi obrigada a descobrir maneiras mais eficientes de levar esses delinqüentes a julgamento. Mesmo que aparentemente eles não deixem pistas, os detetives(Especialistas) descobriram há algum tempo que isto não é verdade.

Fontes: discoverybrasil, baboo

Evolução do IP vs Clean Slate, o que é clean slate, Qual será o futuro da internet?

Clique aqui e veja nosso novo site

Evolução do IP vs Clean Slate

Uma das discussões centrais destes dois dias de evento foi em torno da forma que a rede terá no futuro. Há pesquisadores que defendem que uma nova Internet deve ser criada, ou seja, que deve-se abandonar o protocolo IP, sobre o qual está fundamentada a Internet atual, e desenvolver uma base inteiramente nova sobre a qual a rede passará a funcionar. Esta idéia de “recomeçar a Internet do zero” é conhecida entre os pesquisadores como Clean Slate, ou arquitetura disruptiva.

Os que pensam desta forma argumentam que a Internet como conhecemos foi criada há aproximadamente 30 anos, com o objetivo de atender um público restrito (cientistas e pesquisadores). Hoje, entretanto, a mesma estrutura básica é usada mundialmente por centenas de milhões de pessoas que enviam, consultam e recebem cada vez mais informações (de texto, de imagens, de áudio, de vídeo etc). Como a rede não foi a princípio preparada para isto, os novos aplicativos que surgiram ao longo dos anos foram sendo “ajustados” a rede de maneira desordenada. Atualmente, portanto, a Internet seria constituída por vários “remendos”, responsáveis por uma série de vulnerabilidades, instabilidades, incompatibilidades e outros problemas da rede. Os defensores do Clean Slate argumentam que uma Internet recalculada do zero seria mais robusta e confiável, com maior flexibilidade e facilidade de administração.

Os que defendem o IP argumentam que este protocolo vem funcionando satisfatoriamente nos últimos 30 anos e que, embora uma mudança na Internet seja necessária, ela partirá de uma evolução do próprio IP, e não de uma ruptura com ele. Vale ressaltar que estas visões não são totalmente excludentes: além de ser possível que o novo desenho seja baseado em uma adaptação do protocolo IP (e não uma ruptura completa com este), é possível, ainda, que o IP seja agregado a uma nova estrutura, mesmo que ela não tenha este protocolo como base.

Aparentemente há um consenso entre os pesquisadores de que as mudanças estruturais na Internet (ocorram elas em decorrência de uma evolução do IP ou a partir de um redesenho da arquitetura), ainda devem ser amplamente discutidas durante a próxima década. Isto pois embora todos concordem que a Internet precisa passar por profundas mudanças, ainda não se tem estabelecida nenhuma solução concreta. Desta forma, o workshop do CPqD incluiu também palestras sobre possíveis soluções para alguns dos problemas pontuais da rede, assim como apresentações sobre possibilidades de novas aplicações para a Internet atual e futura.

Problemas e possíveis soluções

Além das questões relativas às redes experimentais, o workshop contou ainda com palestras sobre diversos outros fatores que gravitam em torno do tema “Futuro da Internet”, tais como: desafios e tendências em segurança; questões em torno da mobilidade crescente dos dispositivos conectados a Internet; possibilidades para separar identificação e localização; hiperconectividade; novos requisitos na engenharia de tráfego e gerenciamento de recursos; monitoramento de redes; soluções ópticas para o aumento da sustentabilidade energética das redes, entre outros.

Um dos temas apresentados no evento diz respeito aos ambientes experimentais para o teste das novas soluções para a Internet, importante tanto quando se fala da rede do futuro, quanto quando se fala das redes atuais. Embora muitos pesquisadores concordem que em muitos casos estes ambientes (também conhecidos como testbeds) não dão a medida exata do que ocorre em situações reais, a necessidade deles é não somente inegável, como também crescente, dado o número cada vez maior de aplicações para a Internet.

A palestra do diretor de Inovação da RNP, Michael Stanton, teve como tema justamente os ambientes de suporte para trabalhos de Pesquisa e Desenvolvimento (P&D) experimentais em redes e aplicações distribuídas.

Stanton descreveu a evolução desses ambientes, que podem ser infraestruturas físicas ou virtuais, bem como a maneira como o suporte é dado. Além das atividades já realizadas no Brasil, ele também examinou o contexto de algumas redes experimentais usadas no exterior, especialmente as relacionadas ao futuro desenvolvimento da Internet.

No cenário internacional, o diretor de Inovação da RNP destacou o PlanetLab, uma infraestrutura mundial para a realização de pesquisas em tecnologias e protocolos de aplicações Internet (TCP/IP), atualmente presente em mais de 400 nós espalhados pelo mundo. A contribuição fundamental do PlanetLab para a realização de pesquisa experimental é o uso da virtualização de recursos computacionais nestes nós, permitindo que múltiplas aplicações possam ser instaladas paralelamente em cada nó, e que uma determinada aplicação possa estar presente em uma fração de muitos nós diferentes, o que é chamada de uma “fatia”.

Em 2006, o ambiente PlanetLab foi estendido para permitir experimentos com outras arquiteturas de Internet, além do TCP/IP. Este “meta-testbed” se chama Vini, e permite que os servidores nos nós possam funcionar como roteadores para diversos protocolos. A virtualização dos recursos em Vini inclui também os roteadores e os enlaces entre estes.

O Vini serviu como inspiração para o Global Environment for Network Innovations (Geni), uma iniciativa da norte-americana National Science Foundation (NSF) para criação de um ambiente compartilhado de experimentação que auxilie na validação de novas arquiteturas de redes. O objetivo do Geni é apoiar pesquisas que possam levar a uma futura Internet melhor, com características como maior segurança, integração com tecnologias ópticas e de rádio, maior atratividade econômica, entre outras. Uma das palavras-chave do ambiente Geni é a virtualização, que permite que múltiplas arquiteturas funcionem em uma infraestrutura compartilhada, dando uma representação razoável da complexidade da Internet. Michael falou ainda de outras iniciativas similares ao Geni, como a europeia Future Internet Research & Experimentation (Fire) e a japonesa Akari.

Para concluir, o diretor de Inovação da RNP examinou as perspectivas para montar no Brasil um programa de P&D experimental sobre a Internet do Futuro, com a participação da RNP. Inicialmente falou sobre o projeto Giga, que tratou da implementação de uma rede óptica experimental própria, com de 2,5 Gbps e 735 Km de extensão. A primeira fase do projeto foi oficialmente encerrada em 200. Atualmente, a RNP e o CPqD buscam recursos para continuar mantendo a rede experimental ativa, sendo a proposta da RNP a realização de P&D em arquiteturas novas de rede, visando o futuro da Internet. Além disto, a RNP e quatro universidades formularam em 2008 uma linha de pesquisa experimental em futuras arquiteturas de rede, com base em ambiente inspirado no Vini, para compor o projeto Ciência Web (consórcio liderado pela UFRJ), um dos selecionados no recente edital do INCT (Institutos Nacionais de Ciência e Tecnologia) do CNPq. Nesta proposta a RNP proveria conectividade a longa distância para a rede experimental pretendida.

O uso de Vini neste contexto requereria uma infraestrutura subjacente de camada 2 do modelo OSI, para poder implementar possivelmente múltiplos protocolos de rede (camada 3), sendo IP apenas uma das alternativas. Os atuais planos da RNP são compatíveis com este projeto, com a migração do backbone para tecnologia de rede de camadas 1 e 2, e o uso amplo de Ethernet (camada 2) nas redes metro (pertencentes a iniciativa Redes Comunitárias de Educação e Pesquisa – Redecomep) e nas principais conexões internacionais (Whren-Lila/AtlanticWave). Seria possível, portanto, imaginar que a RNP do futuro pudesse reservar banda para experimentação, isolada do tráfego de “produção”, em toda sua extensão, como é feito em Geni.

Stanton encerrou a apresentação apontando as oportunidades que surgiriam para realizar P&D colaborativos com pesquisadores de outros países se existisse uma rede experimental do tipo Geni no Brasil, que pudesse ser interconectada (federada) com as iniciativas semelhantes em outros países, e notou que as políticas enunciadas por Geni e Fire dão suporte a esta forma de colaboração. Para Stanton, isto permitiria ao Brasil participar no esforço internacional para definir como seria a Internet do Futuro.

Redes híbridas

Outro assunto bastante abordado ao longo do workshop foram as redes híbridas, que se apresentam no cenário acadêmico como uma tendência mundial. Em uma rede híbrida, a mesma infraestrutura de comunicação é usada simultaneamente para prestar serviço de pacotes IP, como opera hoje a rede Ipê, e para circuitos fim-a-fim voltados a aplicações selecionadas. Atualmente, estes circuitos fim-a-fim, que funcionam como canais diretos de transferência de dados entre dois pontos, são configurados manualmente, uma atividade demorada, trabalhosa e sujeita a erros.

A discussão sobre qual é a melhor solução tecnológica para tornar automático o aprovisionamento dos circuitos fim-a-fim, permitindo que ele seja feito sob demanda e de maneira agendada, também foi abordada durante o workshop, assim como diversos outros assuntos relativos às redes híbridas.

Em maio, o projeto Futura RNP, que lança as bases para a próxima a nova rede acadêmica brasileira (possivelmente de arquitetura híbrida), completará um ano. Vale ressaltar que a maioria dos palestrantes que se apresentaram no workshop são parceiros da RNP no Futura RNP.

O futuro da internet está nas maos de quem ?

Fonte: RNP

o que é listem,SYN-SENT,SYN-RCVD,ESTABLISHED,FIN-WAIT-1,CLOSE-WAIT,FIN-WAIT-2,LAST-ACK,TIME-WAIT,CLOSED:

Esse POST tem como objetivo detalhar os estados de uma conexão TCP para instantaneamente viabilizar a análise do resultado da captura de pacotes na rede.

O TCP é o protocolo da camada de transporte do modelo de referência OSI que é orientado a conexão.

Por ter essa característica, antes de ocorrer a transmissão de dados deve-se estabelecer uma sessão de comunicação entre as duas partes. Essa sessão é estabelecida através de um processo chamado three-way handshake, Figura 1, que irá sincronizar os números de seqüência e oferecer informações de controle necessárias para estabelecimento da conexão.

Como o início e o fim de uma sessão de comunicação são bem definidos e o TCP acompanha o estado de suas conexões com flags é importante saber quais são os muitos estados que uma conexão TCP passa.

O estabelecimento da conexão TCP com o 3-way handshake.

Os estados possíveis da conexão TCP são os seguintes:

• LISTEN: esse é o estado verdadeiro de uma conexão TCP, ele ocorre quando um host está esperando um pedido para iniciar uma conexão.
• SYN-SENT: esse estado indica que o host enviou um SYN para iniciar a conexão e está aguardando a resposta SYN-ACK adequada.
• SYN-RCVD: esse estado indica que o host enviou a resposta SYN-ACK depois de ter recebido o SYN.
• ESTABLISHED: esse estado indica que a conexão foi estabelecida. O host que iniciou a conexão entra nesse estado depois de receber o SYN-ACK e o host que responde depois que recebe o ACK.

Como verificamos na Figura 1 esses são os estados que os hosts passam no processo de estabelecimento da conexão TCP no processo chamado 3-way handshake.

Existem outros estados que acontecem no desmembramento de uma conexão TCP:

• FIN-WAIT-1: O estado que um host se encontra após ter enviado um pacote FIN inicial pedindo um fechamento correto da conexão TCP.
• CLOSE-WAIT: O estado da conexão do host que recebeu um FIN inicial e envia de volta um ACK para confirmar o FIN.
• FIN-WAIT-2: O estado da conexão do host que recebeu a resposta ACK para seu FIN inicial, e indica que agora está esperando um FIN final.
• LAST-ACK: Esse estado indica que o host acabou de enviar seu segundo FIN, que é necessário para encerramento correto da conexão TCP, e está aguardando uma confirmação.
• TIME-WAIT: Nesse estado encontra-se o host iniciador que recebeu um FIN final e enviou um ACK para fechar a conexão. Nesse momento ele não irá mais receber nenhuma confirmação do ACK que acabou de enviar, portanto espera um período de tempo para fechar a conexão.
• CLOSED: pode-se considerar como “sem estado”. Esse estado existe antes que uma conexão seja iniciada ou quando ela é finalizada.

Estes estados estão ilustrados na Figura 2, e ocorrem no fechamento correto da conexão TCP:

tutorial beff, explicaçao beff, ataque beff

Neste artigo vamos demonstrar o uso do Beef, um framework para exploits em browsers (Firefox, Opera, IE e outros navegadores), veja na sequência.

1° passo

Executar o instalador do Beef. Há duas opções (menu K—> Services —> BEFF —> Setup BeFF) ou, como usaremos aqui, via shell bash (para isso, você deve ter privilégios com root ou autenticar como root):

2° passo

Digite uma senha para acessar futuramente o painel administrativo via Web do BeFF.

3° passo

Como estamos testando, por sugestão usamos a palavra “teste” como senha, mas lembre-se das regras para obter uma senha forte. Em ambiente real e de produção, ao instalar este framework, verifique se não há ninguém por perto, pois a senha é exibida, não ofuscada por ******, tome cuidado.

4° passo

Agora o BeFF nos orienta a abrir um browser (pode ser o Firefox ou IE) e digitarmos o IP que ele demonstra nesta tela (no meu caso foi http://192.168.1.4/beff), no seu computador pode estar um pouco diferente.

O BeFF avisa sobre um exemplo de página de Internet para testar um exploits XSS, que você pode

acessar em http://192.168.1.4/beff/example.html.

5° passo

Usando o BeFF em um browser você pode ver um painel de controle que só tem acesso quem tiver a senha administrativa, que foi configurada na instalação do BeFF.

O painel de controle do BeFF é dividido em três partes básicas:

1. Menu
2. Status
3. Geral

Para testarmos a eficiência do BeFF sobre exploits de browsers, já há um exemplo criado (apenas para testes mesmo), na própria página.

Esta é a página contendo uma simulação de ataque XSS Cross-posting, que por sinal, sendo em ambiente real de produção, dentro de uma empresa é bastante perigoso.

Repare agora (onde? ZOMBIES) que foi gerado um alerta no status do BeFF, demonstrando quem está atacando através do IP de origem, sistema operacional (que o atacante está usando) e até mesmo o gerenciador de janelas (no caso KDE).

Basicamente o BeFF lhe oferece isso, detecção sobre ataques por exploits em browsers (navegadores de Internet). Aqui vemos um módulo sobre exploit para IMAP4 (protocolo para emails). Para verificar os módulos você deve criar o menu “Standard Modules” e escolher o módulo que você deseja.

Este módulo é para configurar detecção de exploit para Asterisk via browser navegador.

Módulo para detecção de exploit XSS (acho que testei isso num site “bem conhecido esses dias”, humm…não vou falar quem é não. Tenho ética profissional).

Este módulo detecta informações sobre Steal Clipboard (roubo de dados do Clipboard – Copiar/Colar ou Recortar/Colar) via Browsers (navegadores) – só funciona em Internet Explorer.

Módulo para teste de exploits em plugins Flash

Módulo para teste de exploits em plugins Java Applet.

Módulo para teste de exploits em Javascripts

Módulo para teste de exploits por URL Request (geralmente os atacantes anexam algum executável Win32).

Módulo para teste de exploits em URLs visitadas.

Módulo para detecção de exploit para Service Pack 2 do Microsoft Windows XP.

Módulo para detecção de exploit para Safari do Mac OS.

Módulo para detecção de Distributed Port Scanner (Scanner de Portas Distribuídos pela Internet).

Módulo para detecção de Distributed Port Scanner (Scanner de Portas Distribuídos pela Internet).

Configuração do BeFF, no caso em qual caminho, para você acessar via IP.

End if

//Créditos: firebits

~juancarloscunha~

tutorial ataque syn flood, Explicação syn flood, como funciona o syn flood, o que é syn flooding

Clique aqui e veja nosso novo site

 

SYN flood ou ataque SYN é uma forma de ataque de negação de serviço (também conhecido como Denial of Service – DoS) em sistemas computadorizados, na qual o atacante envia uma seqüência de requisições SYN para um sistema-alvo.

Quando um cliente tenta começar uma conexão TCP com um servidor, o cliente e o servidor trocam um série de mensagens, que normalmente são assim:

• O cliente requisita uma conexão enviando um SYN (synchronize) ao servidor.

• O servidor confirma esta requisição mandando um SYN-ACK(acknowledge) de volta ao cliente.

• O cliente por sua vez responde com um ACK, e a conexão está estabelecida.

Isto é o chamado aperto de mão em três etapas (Three-Way Handshake).

Um cliente malicioso pode não mandar esta última mensagem ACK. O servidor irá esperar por isso por um tempo, já que um simples congestionamento de rede pode ser a causa do ACK faltante, Ou seja. O servidor ficará esperando varias respostas deixando de responder as outras requisições que são feitas por outros clientes.

Esta chamada conexão semi-aberta pode ocupar recursos no servidor ou causar prejuízos para empresas usando softwares licenciados por conexão. Pode ser possível ocupar todos os recursos da máquina, com pacotes SYN. Uma vez que todos os recursos estejam ocupados, nenhuma nova conexão (legítima ou não) pode ser feita, resultando em negação de serviço. Alguns podem funcionar mal ou até mesmo travar se ficarem sem recursos desta maneira.

Algumas contra-medidas para este ataque são os SYN cookies. Apenas máquinas Sun e Linux usam SYN cookies.

Ao contrário do que muitos pensam, não se resolve negação de serviço por Syn flood limitando conexões por minuto (como usar o módulo limit ou recent do iptables), pois as conexões excedentes seriam descartadas pelo firewall, sendo que desta forma o próprio firewall tiraria o serviço do ar. Se eu, por exemplo, limito as conecões SYN a 10/seg, um atacante precisa apenas manter uma taxa de SYNs superior a 10/s para que conexões legítimas sejam descartadas pelo firewall. O firewall tornou a tarefa do atacante ainda mais fácil. Em “Iptables protege contra SYN Flood?” tem uma boa descrição dos motivos pelos quais uma configuração de firewall não resolve.

Um ataque de Syn Flood é feito com os ips forjados (spoof), para que o atacante não receba os ACKs de suas falsas solicitações.

~juancarloscunha.wordpress.com~

tutorial trojan shark, como usar o trojan shark,informacoes sobre shark

tutorial trojan shark:

Só para deixar bem claro a diferença entre trojan e cavalo de tróia.

Trojan é um programa que é usado em conexão reversa ou inversa que geralmente é usado para invasão para pegar senha ou outras informações. O cavalo de troia é um programa que tem um pacote de virus que é usado geralmente para destruir um computador.

SharK é um trojan de conexão reversa, ele ao ser enviado para a vitima, faz com que o pc diga qual o seu ip!

Como criar um server:
-Primeiro de Tudo baixe o SharK:
http://www.4shared.com/file/29631048/c5b57345/sharK_232.html
Agora execute ele e vá em SharK > Create Server
-Veja a img e siga a legenda a seguir:
http://img167.imageshack.us/my.php?image=shaaarksettingstl7.png
De preto- é o nome do seu Server!
Vermelho- é o nome do seu server onde ira aparecer na barra de tarefas (ctrl +alt +del)
Verde- É onde o trojan ira se instalar.
Roxo- É a senha do seu server

Install Events
Enable msg on first start-Isso fara com que abra uma msg de erro quando a vitima executar o arquivo!
Execute File- Executara um programa junto com o Trojan.
Open WebPage- Abrira uma pagina (www.site.com.br) ao executar o server

Binde Files- Faz com que vc junte o server com um arquivo qualquer

Finalmente!
Va em compile e aperte COMPILE

Agora é só mandar o server para alquem

Vídeos Aula
http://br.youtube.com/watch?v=rqddB-BubEI

quantos sistemas operacionais existem

quantos sistemas operacionais

existem

 

OpenSuSE

 

Antes de ter o nome OpenSuSE, a distribuição tinha o nome de SuSE Linux, sendo que existe uma outra distribuição Linux chamada SuSE Linux Enterprise. A mudança de SuSE Linux para OpenSuSE foi justamente para não haver confusão quando alguém se referia a uma das distribuições apenas pelo nome “SuSE”.

S.u.S.E é o acrônimo alemão de: “Software- und System-Entwicklung” (desenvolvimento de software e de sistemas). Esse era o nome da empresa que desenvolvia o OpenSuSE, que na época era uma tradução do Slackware Linux para alemão.

Porém há quem diga que o nome SuSE é uma homenagem ao pioneiro da computação na Alemanha Konrad Suze.

Fedora

 

Como muitos sabem, Fedora é uma distribuição criada pela RedHat (chapéu vermelho). O nome RedHat é uma referência ao boné vermelho do time de Lacrosse da Universidade Cornell.

Obs.: Essa informação foi conseguida aqui.

E Fedora é o nome de um modelo de chapéu…

Será que já deu para perceber? Acontece que o chapéu vermelho que vemos no logo da RedHat é do tipo Fedora. Daí a origem do nome dessa distribuição, criada pela RedHat.

Para mais informações sobre a origem do nome Fedora, consulte o seguinte artigo: A Origem do Nome Fedora

Debian GNU/Linux

O nome da distribuição Debian (pronuncia-se “débian”) tem sua origem nos nomes dos seus criadores: Debra e Ian Murdock, que são casados.

A distribuição foi lançada em 1993 e é a distribuição oficial do projeto GNU.

Mandriva

 

O nome da distribuição Mandriva vem da união de duas empresas: a francesa Mandrake e a brasileira Conectiva. Antes dessa fusão, cada empresa era responsável pelo desenvolvimento de uma distribuição Linux diferente.

Hoje a empresa possui uma sede administrativa em Paris e um centro de desenvolvimento em Curitiba.

Slackware

 

A distribuição Slackware tem esse nome como uma referência ao termo “slack”, usado pela Igreja de Subgenius (Church of SubGenius).

Mas o que é “slack” e o que é Igreja de Subgenius?

Igreja de Subgenius é uma pseudo-religião que satiriza outras religiões e crenças que envolvem conspirações mundiais, extra-terrestres etc.

• Informações sobre a Igreja dos Subgênios
• Página oficial da Igreja de Subgenius
• Blog da Igreja de Subgenius em português

O símbolo dessa religião é o “Bob com cachimbo”, daí a origem do símbolo “Tux com cachimbo” como mascote da distribuição Slackware!

 

“Slack” é um termo muito utilizado na Igreja de Subgenius. Na verdade “slack” é o termo que define a crença central da Igreja de Subgenius. Geralmente o termo significa sentimento de liberdade, de independência e um pensamento original que surge quando você atinge os seus objetivos pessoais.

A Igreja afirma que todos nascemos com o Slack Original, mas este nos foi roubado por uma conspiração mundial de pessoas normais, os “pinks”.

Com isso chegamos à conclusão de que o nome Slackware é uma referência ao “slack”, ou seja, ao sentimento de liberdade, originalidade e independência. Seria algo como: “não pense como os outros (pinks), seja original e independente”.

Kurumin

 

Kurumin é o nome de uma das mais famosas distribuições Linux brasileiras. Seu nome vem de “curumim”, do tupi-guarani, língua indígena, que significa “criança” e começa com a letra “K” em referência à distribuição Knoppix, que serviu de base para ela.

O mascote do Kurumin é um pinguim indígena. É uma distribuição criada para usuários iniciantes, de fácil uso, por isso a referência à “criança”. A distribuição foi descontinuada em 2008.

Knoppix

 

Knoppix é uma distribuição baseada na distribuição Debian e que tem seu nome tirado de uma derivação do nome do seu criador: Klaus Knopper, com a influência do nome Unix, que é o sistema do qual o Linux se originou.

O seu símbolo faz referência ao desenho do Homem Vitruviano de Leonardo da Vinci. Esse desenho é baseado nos conceitos do arquiteto Marco Vitruvio Polião que viveu no século I a.C e mostra a perfeição geométrica das medidas do homem baseadas na proporção áurea.

Arch Linux

 

Arch Linux, ou apenas Arch, é uma distribuição cujo nome nada mais é que o substantivo “arch”, que significa arco em inglês. Substantivo usado como radical em palavras como “architecture” (arquitetura).

Um dos diferenciais dessa distribuição é a sua otimização para processadores de arquiteturas i686 ou superiores. Arch se pronuncia “ártch”, como na palavra “archer” (arqueiro).

Seu símbolo lembra uma pirâmide (uma maravilha arquitetônica), mas com um arco na base que acaba formando, no conjunto, algo semelhante a letra “A” (de Arch Linux). Seu lema é “Keep it simple, keep it lightweight” (mantenha-o simples, mantenha-o leve), que é um lema baseado no princípio KISS (keep it simple, stupid), seguido por distribuições como Slackware.

FreeBSD

 

FreeBSD não é Linux, mas é um sistema baseado no BSD, que por sua vez é um sistema do tipo Unix. A origem do nome FreeBSD e BSD se misturam. BSD vem de Berkeley Software Distribution, algo como: programa de distribuição de Berkeley. O nome é apropriado já que esse sistema foi desenvolvido na Universidade de Berkeley.

O FreeBSD é apenas uma das diversas variações desse sistema. o “Free” significa livre em inglês, pois trata-se de um sistema operacional livre. Seu mascote é um diabinho vermelho que se chama Daemon (demônio em grego), isso devido ao fato do sistema utilizar daemons, que são programas executados na memória e que atendem requisições do processador. Seu lema é “The power to serve”, o poder para servir. Sistema muito utilizado em servidores.

Conectiva

 

Conectiva é o nome de uma distribuição brasileira que não existe mais. A Conectiva se fundiu com a Mandrake e criaram a distribuição Mandriva. Conectiva é um nome que lembra conectividade.

Mandrake

 

Mandrake era o nome de uma distribuição Linux, que agora é conhecida como Mandriva (fusão de Mandrake com Conectiva). Mandrake, o mágico, é o nome de um personagem de quadrinhos dos anos 30, do mesmo criador do personagem Fantasma. O símbolo dessa distribuição é um Tux com capa e cartola, as mesmas vestes do Mandrake, o mágico.

Puppy Linux

 

Puppy Linux é uma distribuição leve e live-CD (não precisa instalar no HD, funciona direto no CD). “Puppy” significa filhote em inglês. Seu objetivo é ser isso mesmo, um filhote, ou seja, pequeno e atraente.

Existem algumas versões que são variações do Puppy como o Chubby Puppy (filhote gordinho) que vem com programas mais pesados como o OpenOffice; Barebones Puppy (algo como: filhote esquelético) que não tem ferramentas gráficas e Puppy Unleashed (filhote separado?) que permite ao usuário escolher os aplicativos que comporão o live-CD.

Linux Mint

 

Linux Mint é uma distribuição baseada na distribuição Ubuntu. “Mint” significa hortelã em inglês, considerado um sabor refrescante e agradável. Seu objetivo é ser uma distribuição de fácil uso. Seu tema padrão é verde, cor sempre associada ao sabor hortelã (menta) nos produtos alimentícios. Seu símbolo lembra uma folha verde.

Big Linux

 

Big Linux tem o objetivo de ser uma distribuição completa para desktops. Atende todas as necessidades do usuário final, diferente de algumas distribuições em que o usuário precisa montar o sistema aos poucos.

Big Linux possui uma grande quantidade de programas já instalados, daí o seu nome: Big Linux (Grande Linux).

GoblinX

 

GoblinX é uma distribuição live-CD baseada na distribuição Slackware. Seu lema é “GoblinX Linux, Porque Beleza é Fundamental”. Seu objetivo é também proporcionar uma sensação agradável devido sua aparência. Algo um tanto estranho quando analisamos a origem do seu nome.

Goblin é o nome de uma criatura de fantasia (normalmente encontrada em histórias de fantasia medieval) que são feias, normalmente verdes e narigudas. o “X”, no nome, supõe-se que seja devido ao Linux/Unix. Seu símbolo tem a figura de um Goblin.

Damn Small Linux

 

Damn Small Linux, também conhecida como DSL é uma distribuição live-CD que tem por objetivo ser muito pequena e leve. Daí a origem de seu nome que significa algo do tipo: “Linux danado de pequeno!”.

Sua imagem ISO tem menos de 50MB, no entanto é um sistema completo. Seu símbolo possui a imagem de um pequeno pinguim.

 

tutorial ataque ddos- denial of service, Explicaçao do ataque ddos, atacar com ddos

Alguns tempos  atras os processadores eram de 2 mhz hoje sao ghz alguns processadores de nucleos duplos ou seja 2x ghz, por tanto a técnica ping da morte num cola. Não vá pensando também que é só digitar enter e pronto o pc do cara está no chao!

Eis ai uma técnica que funciona e está sendo a mais utilizada nos dias de hoje, Falarei um pouco da teoria. A pratica falo depois.

Introdução

Nos últimos tempos, o assunto de segurança de redes passou a ser noticias e polemicas. Na pauta das conversas nos cafés e esquinas das cidades tornou-se comum falar sobre os hackers, os mais recentes ataques que deixaram inacessíveis alguns dos mais famosos web sites, e até mesmo se ouvia falar em ataques de “negação de serviço” (Denial of Service(DoS)).

Mas, afinal, o que é um ataque de “negação de serviço(dos)”? Os ataques DoS são bastante conhecidos no âmbito da comunidade de segurança de redes. Estes ataques, através do envio indiscriminado de requisições a um computador alvo, visam causar a indisponibilidade dos serviços oferecidos por ele. Fazendo uma analogia simples, é o que ocorre com as companhias de telefone nas noites de natal e ano novo, quando milhares de pessoas decidem, simultaneamente, cumprimentar à meia-noite parentes e amigos no Brasil e no exterior. Nos cinco minutos posteriores à virada do ano, muito provavelmente, você simplesmente não conseguirá completar a sua ligação, pois as linhas telefônicas estarão saturadas.

Ao longo dos últimos anos, uma categoria de ataques de rede tem-se tornado bastante conhecida: a intrusão distribuída. Neste novo enfoque, os ataques não são baseados no uso de um único computador para iniciar um ataque, no lugar são utilizados centenas ou até milhares de computadores desprotegidos e ligados na Internet para lançar coordenadamente o ataque. A tecnologia distribuída não é completamente nova, no entanto, vem amadurecendo e se sofisticando de tal forma que até mesmo vândalos curiosos e sem muito conhecimento técnico podem causar danos sérios. A este respeito, o CAIS tem sido testemunha do crescente desenvolvimento e uso de ferramentas de ataque distribuídas, em várias categorias: sniffers, scanners, DoS, buffer overflow.

Seguindo na mesma linha de raciocínio, os ataques Distributed Denial of Service, nada mais são do que o resultado de se conjugar os dois conceitos: negação de serviço e intrusão distribuída. Os ataques DDoS podem ser definidos como ataques DoS diferentes partindo de várias origens, disparados simultânea e coordenadamente sobre um ou mais alvos. De uma maneira simples, ataques DoS em larga escala!.

Os primeiros ataques DDoS documentados surgiram em agosto de 1999, no entanto, esta categoria se firmou como a mais nova ameaça na Internet na semana de 7 a 11 de Fevereiro de 2000, quando vândalos cibernéticos deixaram inoperantes por algumas horas sites como o Yahoo, EBay, Amazon e CNN. Uma semana depois, teve-se notícia de ataques DDoS contra sites brasileiros, tais como: UOL, Globo On e IG, causando com isto uma certa apreensão generalizada.

Diante destes fatos, a finalidade deste artigo é desmistificar o ataque, de modo que administradores e gerentes de sistemas, conhecendo melhor o inimigo, se preparem para combatê-lo.

Desmistificando o ataque

OS PERSONAGENS

Figura 1: Ataque DDoS

Quando tratamos de um ataque, o primeiro passo para entender seu funcionamento é identificar os “personagens”. Pois bem, parece não haver um consenso a respeito da terminologia usada para descrever este tipo de ataque. Assim, esclarece-se que ao longo deste artigo será utilizada a seguinte nomenclatura:

Atacante: Quem efetivamente coordena o ataque.

Master: Máquina que recebe os parâmetros para o ataque e comanda os agentes (veja a seguir).

Agente: Máquina que efetivamente concretiza o ataque DoS contra uma ou mais vítimas, conforme for especificado pelo atacante.

Vítima: Alvo do ataque. Máquina que é “inundada” por um volume enorme de pacotes, ocasionando um extremo congestionamento da rede e resultando na paralização dos serviços oferecidos por ela.

Vale ressaltar que, além destes personagens principais, existem outros dois atuando nos bastidores:

Cliente: Aplicação que reside no master e que efetivamente controla os ataques enviando comandos aos daemons.

Daemon: Processo que roda no agente, responsável por receber e executar os comandos enviados pelo cliente.

O ATAQUE

O ataque DDoS é dado, basicamente, em três fases: uma fase de “intrusão em massa”,na qual ferramentas automáticas são usadas para comprometer máquinas e obter acesso privilegiado (acesso de root). Outra, onde o atacante instala software DDoS nas máquinas invadidas com o intuito de montar a rede de ataque. E, por último, a fase onde é lançado algum tipo de flood de pacotes contra uma ou mais vítimas, consolidando efetivamente o ataque.

Fase 1: Intrusão em massa

Esta primeira fase consiste basicamente nos seguintes passos:

1. É realizado um megascan de portas e vulnerabilidades em redes consideradas “interessantes”, como por exemplo, redes com conexões de banda-larga ou com baixo grau de monitoramento.
2. O seguinte passo é explorar as vulnerabilidades reportadas, com o objetivo de obter acesso privilegiado nessas máquinas.

Entre as vítimas preferenciais estão máquinas Solaris e Linux, devido à existência de sniffers e rootkits para esses sistemas. Entre as vulnerabilidades comumente exploradas podemos citar: wu-ftpd, serviços RPC como “cmsd”, “statd”, “ttdbserverd”, “amd”, etc.
3. É criada uma lista com os IPs das máquinas que foram invadidas e que serão utilizadas para a montagem da rede de ataque.

Fase 2: Instalação de software DDoS nas maquinas invadidas

Esta fase compreende os seguintes passos:

1. Uma conta de usuário qualquer é utilizada como repositório para as versões compiladas de todas as ferramentas de ataque DDoS.
2. Uma vez que a máquina é invadida, os binários das ferramentas de DDoS são instalados nestas máquinas para permitir que elas sejam controladas remotamente. São estas máquinas comprometidas que desempenharão os papeis de masters ou agentes.

A escolha de qual máquina será usada como master e qual como agente dependerá do critério do atacante. A princípio, o perfil dos master é o de máquinas que não são manuseadas constantemente pelos administradores e muito menos são frequentemente monitoradas. Já o perfil dos agentes é o de máquinas conectadas à Internet por links relativamente rápidos, muito utilizados em universidades e provedores de acesso.
3. Uma vez instalado e executado o daemon DDoS que roda nos agentes, eles anunciam sua presença aos masters e ficam à espera de comandos (status “ativo”). O programa DDoS cliente, que roda nos masters, registra em uma listao IP das máquinas agentes ativas. Esta lista pode ser acessada pelo atacante.
4. A partir da comunicação automatizada entre os masters e agentes organizam-se os ataques.
5. Opcionalmente, visando ocultar o comprometimento da máquina e a presençados programas de ataque, são instalados rootkits.

Vale a pena salientar que as fases 1 e 2 são realizadas quase que uma imediatamente após a outra e de maneira altamente automatizada. Assim, são relevantes as informações que apontam que os atacantes podem comprometer uma máquina e instalar nela as ferramentas de ataque DDoS em poucos segundos.

Vamo lá, tudo pronto para o ataque!!

Fase 3: Disparando o ataque

O atacante controla uma ou mais máquinas master, as quais, por sua vez, podem controlar um grande número de máquinas agentes. É a partir destes agentes que é disparado o flood de pacotes que consolida o ataque. Os agentes ficam aguardando instruções dos masters para atacar um ou mais endereços IP (vítimas), por um período específico de tempo.

Assim que o atacante ordena o ataque, uma ou mais máquinas vítimas são bombardeadas por um enorme volume de pacotes, resultando não apenas na saturação do link de rede, mas principalmente na paralização dos seus serviços.

Si você estiver lendo este tutorial, pare um pouco. E leia o post anterior a este, pois nele descrevi um pouco sobre as ferramentas de ataque ddos..( http://juancarloscunha.wordpress.com/2009/11/05/ferramentas-para-ataques-ddostutorial-trin00-tfn-tribe-flood-networkstacheldrahttfn2k-funcionamento-das-ferramentas-ddos/)

Depois de ter lido o post sobre as ferramentas ddos, continue lendo…

Como se prevenir?

Até o momento não existe uma “solução mágica” para evitar os ataques DDoS, o que sim é possível é aplicar certas estratégias para mitigar o ataque, este é o objetivo desta seção.

Dentre as estratégias recomendadas pode-se considerar as seguintes:

* Incrementar a segurança do host
Sendo que a característica principal deste ataque é a formação de uma rede de máquinas comprometidas atuando como masters e agentes, recomenda-se fortemente aumentar o nível de segurança de suas máquinas, isto dificulta a formação da rede do ataque.
* Instalar patches
Sistemas usados por intrusos para executar ataques DDoS são comumente comprometidos via vulnerabilidades conhecidas. Assim, recomenda-se manter seus sistemas atualizados aplicando os patches quando necessário.
* Aplicar filtros “anti-spoofing”
Durante os ataques DDoS, os intrusos tentam esconder seus endereços IP verdadeiros usando o mecanismo de spoofing, que basicamente consiste em forjar o endereço origem, o que dificulta a identificação da origem do ataque. Assim, se faz necessário que:
1. Os provedores de acesso implementem filtros anti-spoofing na entrada dos roteadores, de modo que ele garanta que as redes dos seus clientes não coloquem pacotes forjados na Internet.
2. As redes conectadas à Internet, de modo geral, implementem filtros anti-spoofing na saída dos roteadores de borda garantindo assim que eles próprios não enviem pacotes forjados na Internet.
* Limitar banda por tipo de tráfego
Alguns roteadores permitem limitar a banda consumida por tipo de tráfego na rede. Nos roteadores Cisco, por exemplo, isto é possível usando CAR (Commited Access Rate). No caso específico de um ataque DDoS que lança um flood de pacotes ICMP ou TCP SYN, por exemplo, você pode configurar o sistema para limitar a banda que poderá ser consumida por esse tipo de pacotes.
* Prevenir que sua rede seja usada como “amplificadora”
Sendo que algumas das ferramentas DDoS podem lançar ataques smurf (ou fraggle), que utilizam o mecanismo de envio de pacotes a endereços de broadcasting, recomenda-se que sejam implementadas em todas as interfaces dos roteadores diretivas que previnam o recebimento de pacotes endereçados a tais endereços. Isto evitará que sua rede seja usada como “amplificadora”. Maiores informações a respeito do ataque smurf (e do parente fraggle) podem ser encontradas em: http://users.quadrunner.com/chuegen/smurf
* Estabelecer um plano de contingência
Partindo da premissia que não existe sistema conectado à Internet totalmente seguro, surge que sejam considerados os efeitos da eventual indisponibilidade de algum dos sistemas e se tenha um plano de contingência apropriado, se necessário for.
* Planejamento prévio dos procedimentos de resposta
Um prévio planejamento e coordenação são críticos para garantir uma resposta adequada no momento que o ataque está acontecendo: tempo é crucial! Este planejamento deverá incluir necessariamente procedimentos de reação conjunta com o seu provedor de backbone.

^
Como detectar?

As ferramentas DDoS são muito furtivas no quesito detecção. Dentre as diversas propriedades que dificultam a sua detecção pode-se citar como mais significativa a presença de criptografia. Por outro lado, é possível modificar o código fonte de forma que as portas, senhas e valores padrões sejam alterados.

Contudo, não é impossível detectá-las. Assim, esta seção tem por objetivo apresentar alguns mecanismos que auxiliem na detecção de um eventual comprometimento da sua máquina (ou rede) que indique ela estar sendo usada em ataques DDoS. Estes mecanismos vão desde os mais convencionais até os mais modernos.

AUDITORIA

Comandos/Utilitários: Alguns comandos podem ser bastante úteis durante o processo de auditoria. Considerando os nomes padrões dos binários das ferramentas DDoS, é possível fazer uma auditoria por nome de arquivo binário usando o comando find. Caso as ferramentas não tenham sido instaladas com seus nomes padrões, é possível fazer uso do comando strings que permitiria, por exemplo, fazer uma busca no conteúdo de binários “suspeitos”. Esta busca visaria achar cadeias de caracteres, senhas e valores comumente presentes nos binários das ferramentas DDoS.

O utilitário lsof pode ser usado para realizar uma auditoria na lista de processos em busca do processo daemon inicializado pelas ferramentas DDoS. Por último, se a sua máquina estiver sendo usada como master, o IP do atacante eventualmente poderia aparecer na tabela de conexões da sua máquina (netstat). Se tiver sido instalado previamente um rootkit, este IP não se revelará.

Ferramentas de auditoria de host: Ferramentas como o Tripwire podem ajudar a verificar a presença de rootkits.

Ferramentas de auditoria de rede: O uso de um scanner de portas pode revelar um eventual comprometimento da sua máquina. Lembre-se que as ferramentas DDoS utilizam portas padrões.

Assim também, analisadores de pacotes podem ser vitais na detecção de trafego de ataque. Para uma melhor análise dos pacotes é importante conhecer as assinaturas das ferramentas DDoS mais comuns. No caso específico da ferramenta TFN2K, que utiliza pacotes randômicos e criptografados, o que prejudica em muito a detecção da ferramenta por meio de análise dos pacotes, é possível alternativamente procurar nos pacotes uma característica peculiar gerada pelo processo de criptografia.

FERRAMENTAS DE DETECÇÃO ESPECÍFICAS

Uma variedade de ferramentas foram desenvolvidas para detectar ferramentas de ataque DDoS que, eventualmente, possam ter sido instaladas no seu sistema, dentre elas:

O NIPC (National Infraestructure Protection Center) disponibilizou uma ferramenta de auditoria local chamada “find_ddos” que procura no filesystem os binários do cliente e daemon das ferramentas de Trin00, TFN, Stacheldraht e TFN2K. Atualmente estão disponíveis os binários do find_ddos para Linux e Solaris em: http://www.fbi.gov/nipc/trinoo.htm

Dave Dittrich, Marcus Ranum e outros desenvolveram um script de auditoria remota, chamado “gag” que pode ser usado para detectar agentes Stacheldraht rodando na sua rede local. Este script pode ser encontrado em: http://staff.wahington.edu/dittrich/misc/sickenscan.tar

Dave Dittrich, Marcus Ranum, George weaver e outros desenvolveram a ferramenta de auditoria remota chamada “dds” que detecta a presença de agentes Trin00, TFN e Stacheldraht. Ela se encontra disponível em: http://staff.washington.edu/dittrich/misc/ddos_scan.tar

SISTEMAS DE DETECÇÃO DE INTRUSÃO

Sistemas de detecção de intrusão mais modernos incluem assinaturas que permitem detectar ataques DDoS e comunicação entre o atacante, o master DDoS e o agente DDoS.

^
Como reagir?

* Se ferramentas DDoS forem instaladas nos seus sistemas

Isto pode significar que você está sendo usado como master ou agente. É importante determinar o papel das ferramentas encontradas. A peça encontrada pode prover informações úteis que permitam localizar outros componentes da rede de ataque. Priorize a identificação dos masters. Dependendo da situação, a melhor estratégia pode ser desabilitar imediatamente os masters ou ficar monitorando para coletar informações adicionais.

* Se seus sistemas forem vítimas de ataque DDoS

O uso do mecanismo de spoofing nos ataques DDoS dificulta em muito a identificação do atacante. Assim, se há um momento em que pode-se fazer um backtracing e chegar ao verdadeiro responsável é no exato momento em que está ocorrendo o ataque. Isto significa que é imprescindível a comunicação rápida com os operadores de rede do seu provedor de acesso/backbone.

Considere que, devido à magnitude do ataque, não é recomendável confiar na conectividade Internet para comunicação durante um ataque. Portanto, certifíque-se que sua política de segurança inclua meios alternativos de comunicação (telefone celular, pager, sinais de fumaça, etc). Mas, por favor, aja rápido, tempo é crucial!

^
Considerações finais

Não existe “solução mágica” para evitar os ataques DDoS, não com a tecnologia atual.

No lugar, existem certas estratégias que podem ser aplicadas pelos administradores e gerentes de rede para mitigá-lo. Sem dúvida, sem se conhecer o que acontece nos bastidores será uma tarefa difícil. Assim, o motivo deste artigo foi justamente desmistificar o ataque de modo que estes profissionais, conhecendo melhor o inimigo, se preparem melhor para combatê-lo.[/code]

Méritos: Liliana Esther Velásquez Alegre Solha Renata Cicilini Teixeira Jacomo Dimmit Boca Piccolini

http://www.rnp.br/newsgen/0003/ddos.html

Ferramentas para ataques DDoS,tutorial TRIN00, TFN tribe flood network,stacheldraht,TFN2K funcionamento das ferramentas ddos

Ferramentas para ataques DDoS,   funcionamento das ferramentas ddos

Ao contrário do que se pensa, os ataques DDoS não são novos. A primeira ferramenta conhecida com esse propósito(ataques ddos) surgiu em 1998. Desde então, foram diversas as ferramentas de DDoS desenvolvidas, cada vez mais sofisticadas e com interfáceis mais amigáveis. O que é no mínimo preocupante, pois nos dá uma idéia de quão rápido se movimenta o mundo hacker. A seguir, elas são listadas na ordem em que surgiram:

1. Fapi (1998)      2. Blitznet
3. Trin00 (jun/99)

4. TFN (ago/99)

5. Stacheldraht(set/99) 6. Shaft

7. TFN2K(dez/99)   8. Trank

9. Trin00 win version

Não é propósito deste artigo abordar todas as ferramentas de DDoS disponíveis,mas apenas conhecer o funcionamento básico das principais, que são: Trin00, TFN, Stacheldraht e TFN2K.

TRIN00

O Trin00 é uma ferramenta distribuída usada para lançar ataques DoScoordenados, especificamente, ataques do tipo UDP flood.Para maiores informações a respeito de ataques deste tipo, veja em: http://www.cert.org/advisories/CA-96.01 … enial.html

Uma rede Trinoo é composta por um número pequeno de masters e um grande número de agentes.

O controle remoto do master Trin00 é feito através de uma conexão TCP via porta 27665/tcp. Após conectar, o atacante deve fornecer uma senha(tipicamente, “betaalmostdone”).

A comunicação entre o master Trin00 e os agentes é feita via pacotes UDP na porta 27444/udp ou via pacotes TCP na porta 1524/tcp. A senha padrão para usar os comandos é “l44adsl” e só comandos que contêm a substring “l44″ serão processados.

A comunicação entre os agentes e o master Trin00 também é através de pacotes UDP, mas na porta 31335/udp. Quando um daemon é inicializado, ele anuncia a sua disponibilidade enviando uma mensagem (”*HELLO*”) ao master,o qual mantém uma lista dos IPs das máquinas agentes ativas, que ele controla.

Tipicamente, a aplicação cliente que roda no master tem sido encontrado sob o nome de master.c, enquanto que os daemons do Trin00 instalados em máquinas comprometidas têm sido encontrados com uma variedade de nomes, dentre eles: ns, http, rpc.trinoo, rpc.listen, trinix, etc. Tanto o programa cliente (que roda no master) quanto o daemon (que roda no agente) podem ser inicializados sem privilégios de usuário root.

TFN – TRIBE FLOOD NETWORK

O TFN é uma ferramenta distribuída usada para lançar ataques DoS coordenados a uma ou mais máquinas vítimas, a partir de várias máquinas comprometidas. Além de serem capazes de gerar ataques do tipo UDP flood como o Trin00, uma rede TFN pode gerar ataques do tipo SYN flood, ICMP flood e Smurf/Fraggle. Maiores informações a respeito deste tipo de ataques podem ser encontradas em:

http://www.cert.org/advisories/CA-96.21 … oding.html
http://www.cert.org/advisories/CA-98.01.smurf.html

Neste tipo de ataque é possível forjar o endereço origem dos pacotes lançados às vítimas, o que dificulta qualquer processo de identificação do atacante.

No caso específico de se fazer uso do ataque Smurf/Fraggle para atingir a(s) vítima(s), o flood de pacotes é enviado às chamadas “redes intermediárias” que consolidarão o ataque, não diretamente às vítimas.

O controle remoto de uma master TFN é realizado através de comandos de linha executados pelo programa cliente. A conexão entre o atacante e o cliente pode ser realizada usando qualquer um dos métodos de conexão conhecidos, tais como: rsh, telnet, etc. Não é necessária nenhuma senha para executar o cliente, no entanto, é indispensável a lista dos IPs das máquinas que têm os daemons instalados. Sabe-se que algumas versões da aplicação cliente usam criptografia (Blowfish) para ocultar o conteúdo desta lista.

A comunicação entre o cliente TFN e os daemons é feita via pacotes ICMP_ECHOREPLY.Não existe comunicação TCP ou UDP entre eles.

Tanto a aplicação cliente (comumente encontrada sob o nome de tribe) como os processos daemons instalados nas máquinas agentes (comumente encontrados sob o nome de td), devem ser executados com privilégios de usuário root.

STACHELDRAHT

Baseado no código do TFN, o Stacheldraht é outra das ferramenta distribuídas usadas para lançar ataques DoS coordenados a uma ou mais máquinas vítimas, a partir de várias máquinas comprometidas. Como seu predecessor TFN, ela também é capaz de gerar ataques DoS do tipo UDP flood, TCP flood, ICMP flood e Smurf/fraggle.

Funcionalmente, o Stacheldraht combina basicamente características das ferramentas Trin00 e TFN, mas adiciona alguns aspectos, tais como: criptografia da comunicação entre o atacante e o master;e atualização automática dos agentes.

A idéia de criptografia da comunicação entre o atacante e o master surgiu exatamente porque uma das deficiências encontradas na ferramenta TFN era que a conexão entre atacante e master era completamente desprotegida, obviamente sujeita a ataques TCP conhecidos (hijacking, por exemplo). O Stacheldraht lida com este problema incluindo um utilitário “telnet criptografado” na distribuição do código.

A atualização dos binários dos daemons instalados nos agentes pode ser realizada instruindo o daemon a apagar a sua própria imagem e substituí-la por uma nova cópia (solaris ou linux). Essa atualização é realizada via serviço rpc (514/tcp).

Uma rede Stacheldraht é composta por um pequeno número de masters onde rodam os programas clientes (comumente encontrados sob o nome de mserv, e um grande número de agentes, onde rodam os processos daemons (comumente encontrados sob o nome de leaf ou td). Todos eles devem ser executados com privilégios de root.

Como foi mencionado anteriormente, o controle remoto de um master Stacheldraht é feito através de um utilitário “telnet criptografado” que usa criptografia simétrica para proteger as informações que trafegam até o master. Este utilitário se conecta em uma porta TCP,comumente na porta 16660/tcp.

Diferencialmente do que ocorre com o Trinoo, que utiliza pacotes UDP na comunicação entre os masters e os agentes, e do TFN, que utiliza apenas pacotes ICMP, o Stacheldraht utiliza pacotes TCP (porta padrão 65000/tcp) e ICMP (ICMP_ECHOREPLY).

TFN2K – TRIBLE FLOOD NETWORK 2000

A ferramenta Tribe Flood Network 2000, mais conhecida como TFN2K, é mais uma ferramenta de ataque DoS distribuída. O TFN2K é considerado uma versão sofisticada do seu predecessor TFN. Ambas ferramentas foram escritas pelo mesmo autor, Mixter.

A seguir são mencionadas algumas características da ferramenta:

* Da mesma forma que ocorre no TFN, as vítimas podem ser atingidas por ataques do tipo UDP flood, TCP flood, ICMP flood ou Smurf/fraggle. O daemon pode ser instruído para alternar aleatoriamente entre estes quatro tipos de ataque.
* O controle remoto do master é realizado através de comandos via pacotes TCP, UDP, ICMP ou os três de modo aleatório. Estes pacotes são criptografados usando o algoritmo CAST.Deste modo, a filtragem de pacotes ou qualquer outro mecanismo passivo, torna-se impraticável e ineficiente.
* Diferentemente do TFN, esta ferramenta é completamente “silenciosa”, isto é, não existe confirmação (ACK) da recepção dos comandos, a comunicação de controle  é unidirecional. Ao invés disso, o cliente envia 20 vezes cada comando confiando em que, ao menos uma vez, o comando chegue com sucesso.
* O master pode utilizar um endereço IP forjado.

A título de ilustração se resume, através da seguinte tabela comparativa, como é realizada a comunicação entre os”personagens” encontrados em um típico ataque DDoS, para cada uma das ferramentas:
Comunicação Trin00 TFN Stacheldraht TFN2K
Atacante->Master 1524/27665/tcp icmp_echoreply 16660/tcp icmp/udp/tcp
Master->Agente 27444/udp icmp_echoreply 65000/tcp,
icmp_echoreply icmp/udp/tcp
Agente->Master 31335/udp icmp_echoreply 65000/tcp,
icmp_echoreply icmp/udp/tcp

De um modo geral, os binários das ferramentas DDoS têm sido comumente encontrados em máquinas com sistema operacional Solaris ou Linux. No entanto, a fonte dos programas pode ser facilmente portado para outras plataformas.

Ainda em relação às ferramentas, vale lembrar que a modificação do código fonte pode causar a mudança de certas propriedades da ferramenta, tais como: portas de operação, senhas de acesso e controle, nome dos comandos, etc. Isto é, a personalização da ferramenta é possível.