Denial of Service (DoS)

[helldanger1]

Para isso, selecione o relatório que será exportado no menu da esquerda e use a opção "Report > Export". Para que o suporte à geração de arquivos PDF funcione, você deve ter instalado o pacote "htmldoc", disponível via apt-get:

# apt-get install htmldoc

Naturalmente, assim como você pode utilizar o Nessus para detectar e tapar brechas de segurança, outras pessoas podem utilizá-lo para detectar vulnerabilidades na sua rede e lançar ataques. Hoje em dia, a variedade de scripts e ferramentas gráficas prontas que exploram vulnerabilidades é tão grande que você pode encontrar algum exploit fácil de usar para praticamente qualquer vulnerabilidade que você possa encontrar. Basta saber fazer pesquisas no Google.

Estes exploits prontos são o grande perigo, pois não requerem nenhum tipo de prática ou habilidade para serem usados. Basta indicar o IP a ser atacado e pronto. Ou seja, aquele garoto com quem você brigou no chat pode muito bem fazer um estrago na sua rede caso algum serviço ativo no seu servidor possua alguma vulnerabilidade grave. É importante resolver o problema antes que alguém o faça por você.

Gerar o relatório do Nessus é só o primeiro passo. Se você administra um servidor, é importante acompanhar sites especializados em notícias relacionadas à segurança, como o Welcome to LWN.net [LWN.net] e o Home - The Community's Center for Security. A maioria das distribuições oferecem boletins por e-mail que avisam quando novas atualizações de segurança estão disponíveis.

Lembre-se de que, apesar das notícias de brechas e atualizações serem sempre muito freqüentes, você só precisa se preocupar com os servidores que você mantém ativos na sua máquina. Se você mantém apenas o SSH e o FreeNX, por exemplo, não precisa se preocupar com as atualizações do Apache e do Sendmail.

Além dos servidores, clientes de e-mail e navegadores (entre outras categorias de programas) também costumam receber atualizações de segurança com uma certa freqüência. Estes programas clientes não podem ser atacados diretamente, ou seja, ninguém poderá explorar um buffer overflow no Firefox (por exemplo) apenas por ele estar instalado; seria necessário que você acessasse alguma página contendo o script malicioso. É aí que entram os ataques de engenharia social, como no caso dos e-mails com textos que tentam levá-lo a clicar em um link ou ao executar um arquivo anexado.

 

[helldanger1]

ARP poisoning e MAC flooding

Como disse anteriormente, o Wireshark pode ser usado também pelo lado negro da força. Se você estiver em uma rede local, com micros ligados através de um hub ou através de uma rede wireless, outro usuário pode usá-lo para capturar todas as suas transmissões.

Isto é extremamente perigoso. Qualquer um que tenha a chance de plugar um notebook na rede ou colocá-lo dentro da área de cobertura de sua rede wireless, poderá capturar dados e senhas suficientes para comprometer boa parte do sistema de segurança da sua empresa. Apenas conexões feitas através do SSH e outros programas que utilizam encriptação forte estariam a salvo.

Naturalmente, além de alguém de fora, existe a possibilidade de um dos seus próprios funcionários resolver começar a brincar de script kiddie, pregando peças nos outros e causando danos. Como vimos, isso não requer muita prática. Enfim, a menos que você esteja em uma simples rede doméstica, onde exista uma certa confiança mútua, utilizar um hub burro é simplesmente um risco grande demais a correr.

Ao utilizar um hub-switch, o risco é um pouco menor, já que, por default, os pacotes são enviados apenas às portas corretas. Entretanto, muitos sistemas são vulneráveis a ataques de ARP poisoning, sem falar dos ataques de MAC flooding, que permitem burlar a proteção. Vamos então a uma explicação mais detalhada de como eles funcionam.

No ARP poisoning, o micro do atacante envia pacotes com respostas forjadas para requisições ARP de outros micros da rede. Como vimos no capítulo 4, o ARP é utilizado para descobrir os endereços MAC dos demais micros da rede, já que os switches não entendem endereços IP. Esses pacotes forjados fazem com que os outros micros passem a enviar seus pacotes para o micro do atacante, que é configurado para capturar as transmissões e retransmitir os pacotes originais para os destinatários corretos.

A rede continua funcionando normalmente, mas agora o atacante tem chance de logar todo o tráfego, usando o Wireshark ou outro sniffer. Felizmente, o Wireshark também pode ser usado para perceber as anormalidades na rede e chegar até o espertinho.

 

[helldanger1]

Os ataques de MAC flooding, por sua vez, tem como alvo o switch da rede e trabalham dentro de um princípio bastante simples. O switch possui uma área limitada de memória para armazenar a tabela com os endereços MAC dos micros da rede (que permite que ele encaminhe as transmissões para as portas corretas), de forma que, ao receber um grande número de pacotes com endereços MAC forjados, a tabela é completamente preenchida com os endereços falsos, não deixando espaço para os verdadeiros.

Nessa situação, existem apenas duas opções: ou o switch simplesmente trava, derrubando a rede, ou abandona o uso da tabela de endereços e passa a trabalhar em modo failopen, onde os frames são simplesmente retransmitidos para todas as portas, da mesma forma que um hub burro, permitindo que o atacante capture todo o tráfego da rede (até que o switch seja reiniciado).

Como switches que travam não são uma boa propaganda, os fabricantes normalmente utilizam a segunda opção, o que faz com que a maioria dos switches baratos e quase todos os hub-switches sejam vulneráveis a esse tipo de ataque.

Uma das ferramentas mais usadas é o macof, um pequeno utilitário que faz parte da suíte dsniff (que roda sobre o Linux), cujo código fonte está disponível no:
_http://www.monkey.org/~dugsong/dsniff/

O dsniff também pode ser encontrado nos repositórios de muitas distribuições, o que facilita a instalação. Nas distribuições derivadas do Debian, você pode instalá-lo via apt-get:

# apt-get install dsniff

Uma vez que o dsniff foi instalado, usar o macof é bastante simples: basta especificar a interface de saída, usando a opção "-i", e especificar o número de pacotes forjados a serem enviados, usando a opção "-n", como em:

# macof -i eth0 -n 100000

 

[helldanger1]

A maioria dos hub-switchs são capazes de armazenar entre 1000 e 8000 endereços MAC na memória, de forma que bombardeando o hub-switch com 100000 endereços MAC diferentes (o que demora cerca de um minuto e meio em uma rede de 100 megabits) você consegue chavear qualquer aparelho vulnerável para modo failopen. A partir daí, basta lançar o Wireshark e passar a capturar todo o tráfego da rede. Note que, em alguns casos, rodar o comando vai fazer o switch travar, derrubando toda a rede até que você o reinicie manualmente, o que nos modelos mais simples é feito desconectando e reconectando o cabo de energia.

O dsniff inclui também um utilitário para ARP poisoning, o arpspoof. Ao usá-lo, você deve especificar a interface de rede local e também o endereço IP do host de destino dos pacotes que você deseja capturar. Especificando o endereço do gateway da rede (o uso mais comum), você pode capturar todos os pacotes destinados à Internet.

Para usá-lo, o primeiro passo é ativar o encaminhamento de pacotes na configuração do Kernel, o que é feito usando o comando abaixo:

# echo 1 > /proc/sys/net/ipv4/ip_forward

A partir daí, você pode ativar o arpspoof, especificando o endereço de destino dos pacotes que deseja capturar, como em:

# arpspoof -i eth0 192.168.1.1

Com isso, o arpspoof passará a enviar pacotes de broadcast para toda a rede, avisando todos os micros que o novo endereço MAC do "192.168.1.1" é o endereço da sua máquina. Isso fará com que ela passe a receber o tráfego destinado a ele, permitindo que você o capture usando o Wireshark.

Naturalmente, o tráfego não poderia simplesmente ser desviado para a sua máquina, caso contrário, os pacotes deixariam de ir até o gateway da rede e os micros não conseguiriam mais acessar a Internet. Para evitar isso, o arpspoof reencaminha automaticamente todos os pacotes recebidos ao endereço correto (justamente por isso precisamos ativar o ip_forward no Kernel), fazendo com que, apesar do "desvio", o tráfego continue fluindo, como se nada estivesse acontecendo:

ARP poisoning

 

[helldanger1]

Além de permitir escutar o tráfego, o ARP poisoning pode ser usado para alterar os dados transmitidos e também para impersonar outros hosts, de forma a obter senhas de acesso e outros dados.

Imagine, por exemplo, que a estação A (cujos pacotes estão sendo capturados e retransmitidos pela estação B) deseja acessar o servidor A. Em vez de encaminhar a transmissão, como faria normalmente, a estação B responde como se fosse o servidor, pedindo o login e senha de acesso. O usuário na estação A, sem desconfiar do ataque, faz login e recebe de volta uma mensagem de "servidor em manutenção, espere 30 minutos e tente novamente" ou algo similar. De posse da senha, o atacante pode então se logar no servidor verdadeiro, usando a senha roubada.

Muitos protocolos prevêem este tipo de ataque e incluem proteções contra ele. No SSH, por exemplo, o cliente verifica a identidade do servidor a cada conexão e aborta a conexão (exibindo uma mensagem de erro bastante chamativa) antes de pedir login e senha caso a identificação seja alterada, como veremos em mais detalhes no capítulo 6.

É possível detectar ataques de ARP poisoning usando o arpwatch (também disponível via apt-get). Ele monitora os endereços ARP usados pelas estações e gera um log com as mudanças (com a opção de enviar relatórios por e-mail), permitindo que você detecte anomalias.

Em outras situações, pode ser que você mesmo, como administrador da rede, precise policiar o que os usuários estão fazendo durante o expediente na conexão da empresa. Nesse caso, sugiro que você mantenha o servidor SSH ativo nas estações de trabalho Linux e um servidor VNC (ou o recurso de administração remota) nas máquinas Windows. Assim, você pode se logar em cada uma das máquinas, sempre que necessário e rodar o Wireshark para acompanhar o tráfego de dados de cada uma, sem que o usuário tome conhecimento.

 

[helldanger1]

Outra possibilidade seria rodar o Wireshark na máquina que compartilha a conexão, assim você poderá observar os pacotes vindos de todas as máquinas da rede. Alguns modelos de switches gerenciáveis podem ser programados para direcionar todo o tráfego da rede para uma determinada porta, onde você poderia plugar um notebook para ter acesso a todo o tráfego.
No caso das redes wireless, a situação é um pouco mais complicada, pois o meio de transmissão é sempre compartilhado. Os pacotes trafegam pelo ar, por isso não é possível impedir que sejam capturados. Apesar disso, você pode dificultar bastante as coisas ativando o uso do WPA (se possível já utilizando o WPA2) e reduzindo a potência do transmissor do ponto de acesso, de forma a cobrir apenas a área necessária.
Lembre-se de que apenas informações não encriptadas podem ser capturadas. Utilizando protocolos seguros, como o SSH, as informações capturadas não terão utilidade alguma, pois estarão encriptadas.
Monitorando sua conexão durante algum tempo, você vai logo perceber vários tipos de abusos, como sites que enviam requisições para várias portas da sua máquina ao serem acessados, banners de propaganda que enviam informações sobre seus hábitos de navegação para seus sites de origem, gente escaneando suas portas usando o Nessus ou outros aplicativos similares, spywares que ficam continuamente baixando banners de propaganda ou enviando informações e assim por diante.

Essas informações são úteis não apenas para decidir quais sites e serviços evitar, mas também para ajudar na configuração do seu firewall. Pode ser que no início você não entenda muito bem os dados fornecidos pelo Wireshark, mas, depois de alguns dias observando, você vai começar a entender muito melhor como as conexões TCP funcionam.