Denial of Service (DoS)

[helldanger1]

Autor: Carlos E. Morimoto

Os ataques DoS, ou ataques de negação de serviço são feitos não com o objetivo de invadir o sistema, mas sim com o propósito de torná-lo indisponível. O que os torna preocupantes é que eles podem ser lançados contra qualquer host conectado à Internet. Não é necessário que serviços com vulnerabilidades de segurança estejam ativos.

Por exemplo, é possível tornar um servidor web indisponível enviando um grande volume de requisições, aparentemente válidas, para acesso às páginas hospedadas. Se o servidor não possuir nenhum tipo de filtro ou regra de firewall que limite o volume de páginas servidas a um único endereço, ele passará a simplesmente tentar responder a todas as requisições, o que saturará o link ou consumirá todos os recursos do servidor, fazendo com que ele deixe de responder a requisições de usuários válidos.

Se o servidor possuir uma quota de tráfego (na maioria dos planos de dedicated hosting existe uma quota de tráfego de 1 ou 2 TB mensais), o atacante pode simplesmente simular um volume constante de requisições (sobretudo download de arquivos hospedados no servidor) de forma a esgotar a quota de trafego e assim fazer com que o servidor fique indisponível.

Mesmo mecanismos destinados a aumentar a segurança do servidor podem ser usados. Por exemplo, se o servidor é configurado para bloquear logins no SSH depois de um certo volume de tentativas de acesso usando senhas incorretas, o atacante pode bloquear o acesso de usuários válidos tentando repetidamente acessar o servidor usando logins variados. Por não saber as senhas, ela não conseguirá acesso ao servidor, mas em compensação pode conseguir disparar o sistema de bloqueio, tornando o servidor temporariamente indisponível para os usuários legítimos.

O tipo mais famoso de ataque DoS é o DDoS, ou "Distributed denial of service" (ataque distribuído de negação de serviço), onde o ataque é lançado usando centenas ou milhares de hosts (situados em locais diferentes) simultaneamente. Nesse caso, o ataque é especialmente difícil de conter, pois é necessário bloquear as requisições provenientes de cada um dos endereços usados antes que cheguem ao servidor. Ou seja, o bloqueio precisa ser feito pela empresa que administra os links de acesso e não no servidor propriamente dito.

Para lançar um ataque DDoS, é necessário ter à disposição um número muito grande de máquinas, que precisam ser invadidas previamente usando vulnerabilidades diversas, formando uma botnet. Os hosts controlados são chamados de zumbis (zombie computers) e continuam desempenhando suas tarefas de forma aparente normal, até que sejam usadas em ataques.

Servidores hospedados em grandes datacenters, universidades ou em órgãos governamentais são especialmente efetivos, já que são normalmente ligados a links muito rápidos, mas o arroz de festa são máquinas domésticas, rodando versões vulneráveis do Windows, que podem ser infectadas em massa usando trojans e vírus.

Um pequeno aplicativo de controle é instalado em cada uma das máquinas, de forma que elas possam ser controladas através de algum ponto central, como um canal de IRC ou uma página web secreta. Tipicamente, os servidores (que utilizam links dedicados, com IP fixo e melhor conectividade) são usados como controladores da botnet, coordenando a operação dos PCs domésticos.

Depois de obter o controle de um número suficiente de máquinas, o atacante precisa de apenas alguns comandos para fazer com que o ataque seja lançado. Com um número suficiente de máquinas à disposição, é possível derrubar qualquer servidor conectado à grande rede.

Além de ser usada em ataques DDoS, a botnet pode ser usada para diversos propósitos, incluindo o envio de spam (estima-se que mais de 50% dos spams sejam enviados a partir de zumbis), distribuição de arquivos, hospedagem de páginas ilegais, fraudes contra sistemas de venda de anúncios (as máquinas são usadas para simular cliques nos anúncios) e qualquer outra atividade lucrativa. A época romântica, das pixações de páginas e ataques massivos contra sites conhecidos deu lugar a quadrilhas organizadas, que usam as máquinas invadidas para ganhar dinheiro.

 

[helldanger1]

Firewalls

A ilustração mais usada para descrever um firewall é a de um muro, que isola a rede local da Internet. Mas, na prática, a operação do firewall lembra muito mais a de um escritório de alfândega, que tem a função de fiscalizar o que entra e o que sai, bloqueando itens ilegais e permitindo a passagem de itens autorizados. Uma outra analogia poderia ser feita com relação aos seguranças de uma loja, que precisam impedir a ação de assaltantes, sem com isso impedir a entrada de clientes. Um firewall que simplesmente bloqueasse a passagem de todos os pacotes (como um muro) seria inútil, pois simplesmente desconectaria o PC da rede.

Na vida real, o firewall é uma coleção de regras que são aplicadas ao tráfego de rede. Baseado nelas, o firewall decide o que deve ou não passar. É justamente por isso que nenhum firewall é 100% seguro, já que ele precisa fazer seu trabalho sem prejudicar o uso normal da rede.

Outra coisa a ter em mente é que o firewall é destinado a limitar o acesso aos serviços disponíveis, evitando que os compartilhamentos de rede do seu servidor, destinados à rede interna sejam acessados via Internet, ou limitando o acesso a determinadas portas e a determinados endereços da rede, por exemplo.

O firewall trabalha verificando os endereços de origem e de destino dos pacotes, portas a que são destinados e o status das conexões. Ele não é destinado a verificar o conteúdo dos pacotes e por isso pouco pode fazer com relação a vírus, trojans, phishing e outros ataques similares. Para eles, temos os antivírus, que trabalham verificando o conteúdo dos arquivos acessados. Para oferecer uma proteção mais completa, muitos firewalls para Windows passaram a incluir também ferramentas de detecção de malwares, mesclando as duas categorias e uma única classe de aplicativos. Um exemplo de firewall "híbrido" é o Comodo, que veremos a seguir.

Uma boa forma de entender como funciona um firewall é examinar alguns exemplos de scripts de firewall para o IPtables. Ele nada mais é do que o firewall "padrão" no Linux, que é diretamente integrado ao Kernel e pode ser tanto programado diretamente quando usado como base para o desenvolvimento de firewalls gráficos. Existem diversos firewall gráficos para Linux, como o Firestarter (que veremos em detalhes a seguir), mas todos eles utilizam como base o IPtables, programando a ação do firewall de acordo com a sua configuração.

Por exemplo, quando você diz ao Firestarter que deseja permitir conexões na porta 22 TCP (a porta do SSH) a partir de qualquer endereço, ele incluiria uma regra similar a esta na programação do firewall:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Este é um comando que poderia ser executado diretamente no terminal, ou usado como parte de um script de configuração do firewall. Ele diz que qualquer pacote de entrada (INPUT), usando o protocolo TCP (-p tcp), destinado à porta 22 (--dport 22) deve ser aceito (-j ACCEPT).

Ao bloquear o acesso ao domínio "orkut.com" para os PCs da rede local que acessam através da conexão compartilhada pelo servidor, seria incluída uma regra similar a essa:

iptables -A FORWARD -d orkut.com -j REJECT

A regra "FORWARD" se aplica a pacotes que são recebidos em uma interface e roteados para outra, como no caso dos pacotes recebidos na interface de rede local e roteados para a Internet. A opção "-d orkut.com" rotula os pacotes destinados ao servidor do orkut, enquanto a regra "-j REJECT" diz o que deve ser feito com eles, ou seja, diz que eles devem ser rejeitados. Com isso, o servidor passa a se recusar a encaminhar requisições de páginas para os servidores do domínio especificado, impedindo que os usuários acessem o serviço.

 

[helldanger1]

Você pode imaginar que o firewall é programado com uma sequência de regras como essas, que dizem o que ele deve fazer em cada situação prevista, terminando com uma regra mais geral, que diz que pacotes que não se enquadram nas regras estabelecidas devem ser recusados (ou aceitos, de acordo com a política de acesso adotada).

Cada pacote que passa pelo firewall precisa então passar por cada uma das regras, até que o firewall encontre uma que diga o que fazer com ele. Se existem duas regras conflitantes (uma diz que o pacote deve ser aceito e outra diz que ele deve ser recusado, por exemplo), vale a regra que aparecer primeiro na lista.

Aqui temos um exemplo bem simples de script com regras para o IPtables, que autoriza acessos provenientes da rede local (que no exemplo utiliza a interface "eth1" e a faixa de endereços 192.168.1.x, com máscara 255.255.255.0), permite acessos (a partir de qualquer endereço) na porta 22, libera o tráfego na interface de loopback e em seguida bloqueia conexões de entrada não especificadas nas regras anteriores, deixando passar apenas pacotes de resposta para as conexões iniciadas por você:

iptables -A INPUT -i eth1 -s 192.168.1.0/255.255.255.0 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Um script de firewall mais completo poderia ter várias dezenas de linhas, que logo se tornariam um emaranhado difícil de administrar. Firewalls gráficos como o Firestarter reduzem a complexidade, administrando as regras para você.

No mundo Windows, a presença de um firewall pré-instalado no sistema é um fenômeno relativamente recente. Até o Windows 2000, o sistema simplesmente não contava com firewall algum, o que permitiu o surgimento de inúmeros firewalls domésticos oferecidos por empresas independentes, como o Zone Alarm.

O Windows XP original trouxe um firewall simples batizado de ICF (Internet Connection Firewall), que era destinado a oferecer um nível mínimo de proteção a máquinas destinadas a compartilhar a conexão com a rede local. O ICF evoluiu bastante desde então, dando origem ao Windows Firewall, incluído a partir do Windows XP SP2, que embora ainda ofereça um conjunto modesto de recursos, já é bem mais utilizável que o antecessor.

Vamos então colocar a mão na massa, estudando sobre a configuração do Windows Firewall, do Comodo (uma opção de firewall para Windows com um volume bem maior de recursos) e do Firestarter, para Linux.

 

[helldanger1]

Executando com um usuário separado

O firewall protege contra worms e invasões, ataques "de fora para dentro", mas não protege contra vírus e trojans executados localmente.
No primeiro tipo de ataque, o invasor procura uma porta aberta, tenta identificar o servidor ou programa que está ativo na porta (o SSH ou Apache, por exemplo), pesquisa por alguma vulnerabilidade conhecida ou erro de configuração e, caso encontre alguma coisa, lança um ataque, tentando utilizar a falha para obter acesso ao sistema. Com o firewall ativo, o ataque é frustrado logo no início, já que com todas as portas fechadas, simplesmente não existe por onde entrar, a menos que exista alguma falha de segurança no próprio IPtables, o que seria bastante improvável.
Imagine que um desktop que acessa a web apenas como cliente é uma casa, enquanto que um servidor é uma loja de porta aberta. Você pode fechar e reforçar todas as portas, transformando sua casa em um bunker (habilitar o firewall, fechando todas as portas), onde ninguém terá como entrar, a menos que consiga convencer você a abrir a porta para ele. Em um servidor a questão é mais complicada já que, assim como em uma loja, é preciso deixar a porta bem aberta para que os clientes possam entrar e sair.
A segurança, nesse caso, precisa ser feita em vários níveis. Em primeiro vem o firewall, que bloqueia todas as portas que não são usadas, mantendo abertas apenas as portas realmente utilizadas. Em segundo lugar vem a questão das atualizações de segurança. Ninguém invade um servidor simplesmente porque o SSH está habilitado, invade caso esteja em uso uma versão desatualizada, com alguma vulnerabilidade conhecida, ou caso exista alguma conta de usuário ativa, com uma senha fácil. Mantendo o servidor atualizado e seguindo regras básicas de segurança, o risco é pequeno.
Na hora de escolher uma distribuição para ser usada em um servidor, um dos quesitos mais importantes a analisar é justamente a questão das atualizações de segurança: em quanto tempo os pacotes são atualizados ao ser descoberta uma vulnerabilidade e por quanto tempo são disponibilizadas atualizações para a versão em uso.
A maior parte das distribuições comerciais oferece atualizações de segurança por 12 ou 18 meses depois de lançada uma nova versão. Nesse quesito, as distribuições baseadas no Debian levam uma certa vantagem, pois no Debian as atualizações são oferecidas de forma contínua. Sempre que uma nova versão é lançada, você pode atualizar os pacotes utilizando o apt-get e, assim, continuar instalando as atualizações indefinidamente.
O segundo tipo de ataque, que engloba vírus, trojans e afins, exige interação do usuário. Um vírus nunca se instala sozinho (caso contrário não seria um vírus, mas sim um worm), se instala porque alguém executou o arquivo que chegou por e-mail ou por um programa P2P, por exemplo.
No Windows, esta tarefa ficaria por conta do antivírus, antispyware & cia. Entretanto, como ainda não temos uma quantidade expressiva destas pragas no Linux, apenas o firewall em geral já é suficiente. Digo por enquanto, pois conforme o uso do sistema em desktops cresça, é natural que o número de vírus e pragas em geral para a plataforma também cresça, obrigando-nos a tomar mais cuidados.

 

[helldanger1]

Caso eventualmente os vírus e trojans tornem-se um problema no Linux, com certeza surgirão várias opções de antivírus, mas, mesmo antes que isso aconteça, existe um conjunto de cuidados simples que podem manter seu micro seguro desde já.
O Linux é reconhecidamente um sistema multiusuário, onde as permissões de arquivos e executáveis impedem que um usuário danifique arquivos ou configurações de outro, ou modifique as configurações do sistema. Embora isso torne as coisas mais complicadas em diversas situações, também cria uma barreira de segurança adicional bastante interessante.
Ao invés de rodar todos os programas e executar todo tipo de arquivo com seu usuário principal, crie um segundo login (ou até mais de um) e o utilize para executar arquivos suspeitos ou programas que possam ter problemas de segurança, como, por exemplo, clientes de IRC e navegadores.
Para isso, abra um terminal e use o comando "su" para logar-se usando o segundo usuário, como em "su joao". Depois de fornecer a senha, todos os programas executados dentro do terminal serão executados pelo outro usuário. Se por acaso você executar qualquer programa malicioso, apenas o usuário separado é afetado, sem comprometer seus arquivos pessoais, muito menos os arquivos do sistema. Em caso de problemas, basta deletá-lo e criar outro.
Em distribuições baseadas no Debian, o sistema vem configurado para não permitir que outros usuários executem programas gráficos dentro de uma sessão gráfica já aberta. Ao tentar rodar qualquer programa gráfico, você recebe uma mensagem como:

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
konqueror: cannot connect to X server :0.0

Isso é solucionado por um utilitário chamado "sux", que substitui o su, transferindo também as credenciais do X. Basta instalar o pacote "sux" (usando o apt-get, ou outro gerenciador de pacotes disponível) e usá-lo para trocar o usuário, como em: "sux joao".

 

[helldanger1]

Usando o Nmap

O Nmap é um portscan de uso geral. Ele é um dos componentes-base usados pelo Nessus (que veremos a seguir), mas pode também ser usado diretamente, sempre que você precisar verificar rapidamente as portas abertas em determinado host, seja na sua rede local, seja na Internet.

O Nmap é um pacote muito utilizado e por isso está disponível em todas as principais distribuições. Você pode instalá-lo usando o yast (SuSE), yum (Fedora), urpmi (Mandriva), ou outro gerenciador de pacotes disponível. Nas distribuições derivadas do Debian, você pode instalá-lo via apt-get:

# apt-get install nmap

Para usar todos os recursos do Nmap, você deve executá-lo como root. O uso mais simples é escanear diretamente uma máquina da rede, como em:

# nmap 192.168.0.3

Starting nmap 3.81 ( _http://www.insecure.org/nmap/ )

Interesting ports on 192.168.0.3:
(The 1661 ports scanned but not shown below are in state: closed)

PORT STATE SERVICE
68/tcp open dhcpclient
631/tcp open ipp
MAC Address: 00:0F:B0:55:EE:16 (Compal Electronics)
Nmap finished: 1 IP address (1 host up) scanned in 0.339 seconds

Neste exemplo, o teste foi disparado contra uma máquina Linux, rodando uma instalação personalizada do Debian Sarge. As duas portas abertas são o cliente DHCP (é normal que a porta 68 fique aberta em clientes configurados via DHCP) e o servidor Cups, que escuta na porta 631. O Cups mantém esta porta aberta sempre que é ativado (você precisa dele para imprimir, tanto em compartilhamentos da rede, quanto em impressoras locais). Por padrão, ele permite apenas que o localhost imprima e acesse a interface de administração, mas é possível configurá-lo para compartilhar as impressoras com a rede de forma bem simples através do arquivo "/etc/cups/cupsd.conf".

Nem o cliente DHCP nem o Cups permitem acesso via shell, por isso, salvo eventuais graves brechas de segurança, os ataques mais graves que poderiam ser lançados neste caso seriam tentar modificar a configuração de rede, tentando responder ao cliente DHCP no lugar do servidor DHCP da rede, ou tentar usar impressoras compartilhadas no Cups.

O simples fato de uma determinada porta estar aberta, não significa que a máquina está vulnerável, mas apenas que existem serviços ativos e as portas não estão sendo bloqueadas por nenhum firewall.

 

[helldanger1]

Você pode obter mais informações sobre as portas abertas, incluindo a versão de cada serviço ativo usando a opção "-sV", como em:

# nmap -sV 192.168.0.3

Esta opção é muito mais demorada, no lugar dela você pode preferir fazer logo um scan completo usando o Nessus.

É possível também escanear de uma vez toda uma faixa de endereços, como em:

# nmap 192.168.0.1-254

Outro parâmetro interessante é a opção "-O", que faz com que o Nmap tente identificar qual é o sistema operacional usado em cada máquina. Esta identificação permite diferenciar máquinas rodando diferentes versões do Windows de máquinas rodando Linux ou MacOS, por exemplo, mas não é muito eficiente em identificar diferentes distribuições Linux, nem em identificar a versão do Windows usada. Veja um exemplo:

# nmap -O 192.168.0.4

Starting nmap 3.81 ( _http://www.insecure.org/nmap/ )
Interesting ports on 192.168.1.35:
(The 1658 ports scanned but not shown below are in state: closed)

PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
1025/tcp open NFS-or-IIS
5000/tcp open UPnP

MAC Address: 02:0F:B0:55:EE:16 (Unknown)
Device type: general purpose
Running: Microsoft Windows 95/98/ME|NT/2K/XP
OS details: Microsoft Windows Millennium Edition (Me),
Windows 2000 Pro or Advanced Server, or Windows XP
Nmap finished: 1 IP address (1 host up) scanned in 1.145 seconds

Neste caso temos uma instalação limpa do Windows XP, sem o firewall ativo. Note que a identificação do sistema não é exata, o Nmap indicou corretamente que é uma máquina Windows, mas não soube identificar precisamente a versão.

 

[helldanger1]

Continuando, os scans do Nmap podem ser facilmente detectados caso alguma das máquinas-alvo esteja com o Snort, ou outro detector de intrusões ativo, o que vai lhe render no mínimo um puxão de orelha do administrador da rede. Para dificultar isso, o Nmap oferece a opção de fazer um half-open scan, especificando a opção "-sS", como em:

# nmap -sS 192.168.0.1-254

Operando neste modo, o Nmap apenas envia um pacote SYN para cada porta alvo e espera para ver se recebe um pacote ACK de confirmação sem, entretanto, responder com o segundo pacote ACK, que abriria a conexão. Isso permite burlar muitos programas de detecção de intrusão, que monitoram e logam apenas conexões efetivamente estabelecidas.

Apesar de menos comum, é possível fazer também uma varredura de portas UDP abertas. Embora poucos serviços possam ser diretamente conectados através de portas UDP, muitos as utilizam para transferir dados e, em geral, os firewalls são configurados para bloquear apenas as portas TCP. Escanear as portas UDP é uma forma alternativa de detectar serviços abertos em uma máquina, mesmo que todas as portas TCP estejam fechadas no firewall. Existem também casos de backdoors acessíveis via UDP, como o Back Orifice (no Windows) e até mesmo (raras) brechas de segurança em serviços do Linux ou outros sistemas Unix, como uma brecha em certas versões do rpcbind do Solaris, que podia ser explorada através de uma porta UDP alta, a partir da 32770 (variando de acordo com a versão).

Os scans de UDP são rápidos se direcionados a máquinas Windows, mas são absurdamente lentos se feitos contra máquinas Linux ou BSD, onde o sistema limita o número de erros de ICMP (dos quais o scan do Nmap depende) a uma taxa de aproximadamente 20 por segundo. No Windows não existe limite.

Para usar o scan UDP, usamos a opção "-sU", como em:

# nmap -sU 192.168.0.4

Por padrão, o Nmap escaneia apenas um conjunto de 1661 portas, que incluem as usadas pelos serviços mais comuns. Uma media de segurança comum é esconder serviços como o SSH em portas altas, de forma que eles sejam mais difíceis de detectar. Nesses casos, você pode fazer um scan completo, incluindo todas as portas TCP (ou UDP) usando a opção "-p 0-65535", como em:

# nmap -sS -p 0-65535 192.168.0.4

 

[helldanger1]

A opção "-p" pode ser usada para escanear apenas uma porta específica, ou uma faixa de portas em que esteja interessado. Se executado via rede local, o scan é sempre relativamente rápido (a menos que a máquina-alvo esteja com um firewall ativo, configurado em modo "DROP"), mas, via Internet, as coisas tornam-se bem mais demoradas. Ao tentar localizar vulnerabilidades em uma determinada faixa de endereços IP, você começaria lançando o teste rápido contra toda a faixa, reservando as opções mais demoradas para algumas máquinas específicas.

A opção "-sS", combinada com a "-p 0-65535", permite localizar serviços escondidos em portas altas, mas não é capaz de dizer muito sobre eles. Ele sempre retorna algo como:

22543/tcp open unknown

Você pode escanear esta porta específica usando a opção "-sV" para descobrir mais sobre ela, como em:

# nmap -sV -p 22543 192.168.0.4

PORT STATE SERVICE VERSION
22543/tcp open ssh OpenSSH 3.8.1p1 Debian-8.sarge.4 (protocol 1.99)
Nmap finished: 1 IP address (1 host up) scanned in 0.284 seconds

Agora você sabe que a máquina tem ativo um servidor OpenSSH (versão 3.8.1, do Debian Sarge), escondido na porta 22543.

Tudo é muito simples quando a máquina alvo não possui nenhum firewall ativo. O scan é rápido e você pode lançar toda sorte de ataques sobre os serviços ativos. Mas, com um firewall ativo, as coisas tornam-se um pouco mais complicadas e demoradas. Um firewall configurado para descartar (DROP) todos os pacotes recebidos, faz com que o scan torne-se extremamente lento.

 

[helldanger1]

Versões antigas do Nmap não chegavam sequer a concluir o teste quando o alvo estava configurado dessa forma, retornando uma mensagem como:

Starting nmap 3.50 ( _http://www.insecure.org/nmap/ )
Host 192.168.0.33 appears to be down, skipping it.
Note: Host seems down.
Nmap run completed -- 1 IP address (0 hosts up) scanned in 12.053 seconds

Nestes casos, você pode forçar o Nmap a concluir o teste, a fim de detectar serviços escondidos em portas altas usando o parâmetro "-P0", como em:

# nmap -sS -P0 -p 0-65535 192.168.0.4

O problema neste caso é que o scan demora muito mais que o normal, já que, por não receber respostas, ele precisa aguardar um tempo muito maior antes de passar para a porta seguinte. Um teste executado contra um micro na Internet, através de uma conexão lenta, pode literalmente demorar dias. Apesar de não responder, o micro remoto pode ser configurado para logar suas tentativas, permitindo que o administrador tome conhecimento e aja de acordo, bloqueando seu endereço IP ou contatando seu provedor de acesso. Um firewall bem configurado é realmente uma grande vantagem de segurança para qualquer servidor.

 

[helldanger1]

Usando o Nessus

O Nessus é uma ferramenta de auditoria muito usada para detectar e corrigir vulnerabilidades nos PCs da rede local. Ele realiza uma varredura de portas, detectando servidores ativos e simulando invasões para detectar vulnerabilidades. Uma característica importante é que o Nessus procura por servidores ativos não apenas nas portas padrão, mas em todas as portas TCP. Ele é capaz de detectar uma vulnerabilidade em um servidor Apache escondido na porta 46580, por exemplo.

Até a versão 2.2.8, o Nessus era um aplicativo open-source. Os desenvolvedores trabalham na área de segurança, prestando consultoria e vendendo versões personalizadas do Nessus, com plugins e recursos adicionais. O problema é que outras empresas de segurança passaram a se aproveitar disso para incorporar recursos do Nessus em seus produtos proprietários e a desenvolver versões modificadas, que competiam diretamente com as soluções oferecidas por eles.

Isso criou um clima crescente de tensão até que os desenvolvedores decidiram mudar a licença, mudança que entrou em vigor a partir da versão 3.0. O Nessus continua sendo de uso gratuito, mas o código fonte passou a ser fechado, para evitar a concorrência predatória de outras empresas.

Você pode baixar a versão mais recente na seção de downloads do _http://www.nessus.org. Para baixar, você precisa fornecer um endereço de e-mail válido, para onde é enviado um código de ativação.

 

[helldanger1]

Existem versões do Nessus para diversos sistemas, incluindo o Linux, Windows, FreeBSD e MacOS X. Ao usar a versão Windows, é recomendável que você utilize o Windows 2003 ou outra versão server do sistema. O Windows XP não é adequado para rodar o Nessus, pois a partir do SP2 o sistema inclui políticas de segurança que limitam o número de conexões TCP simultâneas e outros recursos utilizados por ele. As proteções foram incluídas como uma forma de reduzir o potencial nocivo de malwares, mas acabaram dificultando o trabalho do Nessus.

Ao usar o Windows XP, o ideal é que você baixe apenas o cliente Nessus e o utilize para se conectar a uma máquina Linux da rede rodando o componente servidor. Nesse caso, a máquina Linux faz o trabalho pesado e o Windows XP roda apenas a interface do programa.

Com relação à versão Linux, estão disponíveis pacotes para diversas distribuições, entre eles um pacote .deb para as distribuições derivadas do Debian e pacotes .rpm para o Fedora, Red Hat e SuSE. Você precisa baixar tanto o Nessus propriamente dito, quanto o "NessusClient", disponível na mesma página:

Instale o pacote baixado usando o comando "dpkg -i" (no caso do pacote .deb), ou "rpm -Uvh" (para os pacotes .rpm), como em:

# dpkg -i Nessus-3.0.3-debian3_i386.deb

O Nessus utiliza o Nmap como portscan, por isso é necessário que ele também esteja instalado. O Nmap faz a primeira rodada de testes, detectando as portas abertas e o Nessus usa as informações fornecidas por ele como ponto de partida para executar uma rodada adicional de testes, que permitem devolver um relatório bastante detalhado das vulnerabilidades encontradas.

 

[helldanger1]

Depois de instalar, você precisa criar um login de usuário para utilizar o Nessus. Isso é necessário pois ele é dividido em dois componentes: um servidor (que é quem faz todo o trabalho pesado) e um cliente, que funciona como uma interface segura para ele. Isso permite que você instale o servidor em uma máquina que faça parte da rede que vai ser escaneada e use seu notebook para apenas rodar o cliente, o que pode ser feito até mesmo remotamente.

Com isso, seu notebook fica livre durante o teste, permitindo que você execute testes adicionais ou pesquise sobre as vulnerabilidades na web enquanto o teste é realizado. Naturalmente, você pode rodar ambos os componentes na mesma máquina, o único pré-requisito é usar uma máquina relativamente rápida, com pelo menos 256 MB de RAM livres (ou seja, descontando a memória usada pelo sistema e outros programas).

Este login não é uma conta de usuário válida no sistema. Ele é válido apenas para o Nessus, onde é usado para fazer a autenticação no módulo servidor. Para criá-lo, use o comando "/opt/nessus/sbin/nessus-add-first-user". Ele pedirá o login e senha, o tipo de autenticação (escolha "pass") e permitirá que você adicione regras para o usuário (User Rules). Se você quiser apenas criar o usuário usando as regras default, basta pressionar "Ctrl+D". Ele pedirá uma última confirmação, basta responder "y":

# /opt/nessus/sbin/nessus-add-first-user

Using /var/tmp as a temporary file holder
Add a new nessusd user
----------------------

Login : tux
Authentication (pass/cert) [pass] : pass
Login password : ********
Login password (again) : ********

User rules
----------
nessusd has a rules system which allows you to restrict the hosts
that tux has the right to test. For instance, you may want
him to be able to scan his own host only.
Please see the nessus-adduser(8) man page for the rules syntax
Enter the rules for this user, and hit ctrl-D once you are done:
(the user can have an empty rules set)
^D

Login : tux
Password : ***********
DN :
Rules :
Is that ok? (y/n) [y] y

Uma vez instalado, você pode iniciar o servidor Nessus usando o comando:

# /etc/init.d/nessusd start
ou:
# /opt/nessus/sbin/nessusd -D

Em ambos os casos ele roda em background, sem obstruir o terminal. Para fechá-lo, use o comando "killall nessusd".

Isto conclui a instalação do servidor. O próximo passo é instalar o pacote do cliente. No site você pode baixar tanto o cliente Linux, quanto o NessusWx, que roda em máquinas Windows.

No meu caso, tive um pouquinho de trabalho para instalar o cliente Linux, pois, no momento em que escrevi este tópico, ainda não estava disponível uma versão do cliente para o Debian, de forma que precisei baixar o pacote para o Fedora, convertê-lo usando o alien e criar dois links simbólicos para bibliotecas com nomes diferentes nos dois sistemas.

 

[helldanger1]

O primeiro passo foi instalar o alien via apt-get e usá-lo para converter o pacote baixado do site:

# apt-get install alien
# alien NessusClient-1.0.0.RC5-fc5.i386.rpm

O alien gera um pacote .deb com o mesmo nome do pacote original, que pode ser instalado usando o dpkg, como em:
# dpkg -i nessusclient_1.0.0.RC5-1_i386.deb

O NessusClient é aberto usando o comando "NessusClient" (que você executa usando sua conta de usuário e não como root). Entretanto, por instalar uma versão para outra distribuição, ele reclamou da falta das bibliotecas "libssl.so.6" e "libcrypto.so.6". Na verdade, ambas estavam disponíveis, porém com nomes diferentes. Acessando o diretório "/usr/lib" vi que existiam os " libssl.so.0.9.8" e " libcrypto.so.0.9.8", de forma que precisei apenas criar dois links, apontando para eles:
# cd /usr/lib
# ln -s libcrypto.so.0.9.8 libcrypto.so.6
# ln -s libssl.so.0.9.8 libssl.so.6

A partir daí, o NessusClient passou a abrir corretamente:
$ NessusClient

 

[helldanger1]

A interface desta versão é bem diferente da usada no cliente que acompanhava o Nessus 2.x, mas o funcionamento é basicamente o mesmo. Comece clicando no botão "Connect" para abrir a conexão com o servidor. Se estiver rodando-o na mesma máquina, use "localhost" como endereço, caso contrário, forneça o IP correto da máquina onde o servidor está ativo:

Da primeira vez que se conectar, ele perguntará sobre o certificado do servidor. Ele (certificado) permite que você verifique a autenticidade do servidor onde está se conectando, evitando a possibilidade de que alguém o tenha substituído por outra máquina.

Ao usar servidores Nessus remotos, você pode usar certificados de autenticidade para melhorar a segurança. Nesse caso, use o comando nessus-mkcert-client (no servidor):
# /opt/nessus/bin/nessus-mkcert-client

Ao terminar o processo, ele salva o certificado gerado em uma pasta temporária, como em:
Your client certificates are in /tmp/nessus-mkcert.9904
You will have to copy them by hand

Dentro da pasta, você encontra um arquivo ".pem" com o nome do usuário criado, como em "cert_nessuswx_joao.pem". Para usar este certificado, você deve copiá-lo para a pasta "/opt/nessus/com/nessus/CA/" (do cliente). Na hora de se conectar usando o NessusClient, marque a opção "Autentication by certificate" e indique a localização do arquivo.
Note que o uso do certificado apenas melhora a segurança da comunicação entre o servidor Nessus e o cliente. É uma medida saudável para os paranóicos de plantão.

 

[helldanger1]

Uma vez conectado ao servidor Nessus, você pode definir diversas opções dentro da aba "Global Settings". Dentro dela, algumas opções interessantes (disponíveis dentro da aba "General") são:
Port range: O default do Nessus é escanear apenas as portas de 1 a 1024, o que resulta em testes relativamente rápidos, mas que deixam passar serviços escondidos em portas altas. Para que ele escaneie todas as portas, mude para "1-65535". Note que isso torna o teste muito mais demorado, pois ele precisa enviar um pacote TCP e outro UDP para cada uma das portas, para só então executar os testes adicionais nas portas abertas.
Number of hosts to test at the same time: Esta opção determina o número de hosts que serão verificados simultaneamente durante o teste. O default para esta opção são 20 hosts, o que é adequado para situações onde você use um micro de configuração modesta para executar o teste dentro da rede local. Aumentar o número faz com que o Nessus consuma mais recursos do servidor e mais banda da rede, o que não é muito interessante caso o teste seja realizado durante o expediente.
Number of checks to perform at the same time: Esta opção determina o número de testes simultâneos em cada um dos micros escaneados. Muitos dos testes realizados pelo Nessus são demorados, porém, geram pouco tráfego de rede. Aumentar o número de testes simultâneos é uma boa forma de acelerar o teste caso sua rede tenha poucos micros.
Note que é aberta uma instância do scanner para cada host e para cada teste. Ou seja, com 100 hosts e 4 testes simultâneos em cada um, podem ser abertas até 400 instâncias, o que consumirá quase 500 MB de memória do servidor. Se você está rodando o servidor em uma máquina de configuração modesta, ou está usando sua máquina de trabalho e não deseja que ela fique muito lenta durante o teste, reduza os números.
Optimize the test: Esta opção torna o teste do Nessus mais "inteligente". Baseado em informações de testes anteriores, o scanner evita usar testes demorados, que tenham baixa probabilidade de revelar novas vulnerabilidades. Ativar esta opção, torna o teste muito mais rápido, se executado repetidamente, mas abre uma pequena possibilidade de algumas vulnerabilidades mais incomuns não serem descobertas.
Safe checks: Alguns sistemas antigos possuem brechas de segurança que podem causar travamentos. Máquinas com o Windows 95 sem atualizações de segurança, por exemplo, são vulneráveis ao famoso "ping da morte", um pacote ICMP defeituoso, que trava o sistema. Ativando esta opção, o Nessus deixa de realizar os testes que podem levar a travamentos das máquinas, ou de outros dispositivos da rede, como roteadores e modems ADSL.
Designate hosts by their MAC address: Ativando esta opção, os hosts são identificados pelo endereço MAC no relatório do teste, ao invés de pelo endereço IP. Isso pode ser útil em redes onde os clientes são configurados via DHCP.

 

[helldanger1]

Na aba "Plugins" você tem acesso à configuração dos plugins, que são scripts responsáveis por detectar vulnerabilidades específicas. Por exemplo, ao detectar que a porta "45234" está aberta, o Nessus primeiro tenta identificar qual servidor está ativo, executando um conjunto de testes. Se for detectado um servidor Apache, por exemplo, serão usados os plugins que detectam vulnerabilidades em servidores web.
O Nessus inclui um número assustador de plugins, divididos em categorias. Ao marcar a opção "Safe checks" (na aba general), são automaticamente desativados os plugins potencialmente perigosos, mas você pode reativar todos clicando no "Enable all".

Naturalmente, novas brechas de segurança são descobertas todos os dias, por isso é necessário atualizar os plugins periodicamente. Para isso, use o comando "/opt/nessus/bin/nessus-fetch", informando o código fornecido no e-mail de confirmação do registro, como em:

# /opt/nessus/bin/nessus-fetch --register FFBB-382E-3990-D3DA-2BFC

A partir daí, os plugins são atualizados automaticamente, uma vez por dia. Se preferir desativar a atualização automática, edite o arquivo "/opt/nessus/etc/nessus/nessusd.conf", substituindo a linha "auto_update = yes" por "auto_update = no".

Os plugins são os componentes mais importantes do Nessus. São eles que o diferenciam de um portscan genérico, como o Nmap. O portscan detecta que uma determinada porta está aberta e qual servidor está sendo usado, mas são os plugins que informam que está sendo usada uma versão com a vulnerabilidade X, que pode ser corrigida com a atualização Y.

As atualizações gratuitas são fornecidas com um delay de 7 dias, o que dificulta seu uso profissional (7 dias dentro do ramo de segurança é um tempo muito longo, durante o qual brechas são corrigidas e novas surgem). Para ter acesso às atualizações em tempo real, você precisa assinar o plano comercial.

 

[helldanger1]

Depois de ajustar as opções gerais, clique na opção "File > Scan Assistant" para definir a faixa de endereços que será escaneada. A primeira tarefa é definir nomes de identificação do teste nas abas "Task" e "Scope".

Depois vem o que interessa, a definição dos alvos na aba "Targets". Você pode tanto lançar o teste contra um IP isolado quanto contra uma faixa inteira de endereços. Neste caso, indique o endereço da rede seguido pela máscara, como em "192.168.1.0/24" (o 24 indica a máscara de sub-rede, no padrão CIDR), ou um intervalo de endereços, como em "192.168.1.2-253". Clicando no "Executar" o teste é finalmente lançado:

Uma novidade em relação às versões anteriores é que agora você pode definir várias faixas diferentes e criar uma configuração independente para cada uma. Você pode, por exemplo, ter uma configuração para o teste contra hosts da rede local e outra já engatilhada para testar periodicamente o servidor que hospeda seu site, por exemplo. Cada uma permite definir faixas de portas e configurações diferentes. Para lançar um teste já pré-configurado, selecione-o na lista da esquerda e clique no "Scope > Executar".

Como comentei, o teste do Nessus é feito em duas partes. A primeira é o portscan, onde ele utiliza o Nmap, combinado com alguns testes adicionais para descobrir quais portas estão abertas em cada host. A partir daí, entram em ação os plugins, que testam cada porta em busca de vulnerabilidades conhecidas.

 

[helldanger1]

Concluído o teste, ele exibe uma lista com as vulnerabilidades encontradas em cada PC. Existem três níveis de alerta; o primeiro e mais grave tem o símbolo de uma luz vermelha e indica uma brecha de segurança em um servidor ativo na máquina. No screenshot, por exemplo, temos uma instalação bastante desatualizada do Windows XP, com diversas brechas de segurança, entre elas uma vulnerabilidade no protocolo SMB (responsável pelo compartilhamento de arquivos), que permite travar a máquina remotamente e duas vulnerabilidades graves, que permitem executar código e obter acesso à máquina:

Veja que, além de apontar o problema, o Nessus oferece uma descrição detalhada da vulnerabilidade e aponta uma solução. Na maioria dos casos, o problema é corrigido simplesmente instalando as atualizações de segurança ou atualizando para a versão mais recente. Em casos em que o problema é gerado por erros de configuração, ele quase sempre fornece dicas de como corrigi-lo.

O teste do Nessus permite também identificar serviços indesejados, que podem ser desativados ou ter suas portas bloqueadas no firewall, além de avisar sobre qualquer backdoor que tenha sido instalado sem seu conhecimento.

Continuando, o segundo nível é um alerta de que um serviço potencialmente inseguro está ativo em uma determinada porta do sistema, como, por exemplo, um servidor Telnet ou XDMCP. Neste caso, não foi encontrada nenhuma vulnerabilidade específica, mas o fato de o serviço ser fundamentalmente inseguro já representa uma brecha de segurança. Tanto o Telnet quanto o XDMCP transmitem dados de forma não encriptada, o que permite que alguém mal intencionado possa sniffar a rede, capturando os dados transmitidos (incluindo as senhas dos usuários). Ambos devem ser usados apenas dentro da rede local.

O terceiro nível de alerta tem o símbolo de uma luz. Estes são apenas lembretes de que existe um servidor ativo na porta indicada, mas sem que fosse detectada qualquer brecha de segurança.

 

[helldanger1]

Como disse, em muitos casos o Nessus ajuda também a detectar erros de configuração, que podem ser perigosos. Por exemplo, este é um aviso de segurança, que mostra um servidor dedicado com o servidor DNS aberto para consultas a outros domínios:

Todo servidor web trabalha em conjunto com um servidor DNS, que responde pelos domínios dos sites hospedados. Embora não seja por si só uma brecha de segurança, esta configuração faz com que o DNS se transforme em um servidor "público", que faz a resolução de qualquer domínio solicitado, assim como os servidores DNS dos provedores de acesso. Isso abre brecha para ataques de "DNS poisoning", onde um cliente externo insere uma entrada inválida no cache do DNS, fazendo com que ele responda a algumas das consultas com endereços IPs incorretos, além de abrir uma pequena possibilidade de que o servidor seja usado como auxiliar em ataques DoS contra outros servidores.

O próprio Nessus dá a dica de como corrigir o problema. Pesquisando no Google sobre a opção "allow-recursion" que ele sugere, você chega facilmente à artigos que sugerem a inclusão das quatro linhas abaixo no final do arquivo "/etc/bind/named.conf":

options {
directory "/var/named";
recursion no;
};

Elas fazem com que o servidor DNS responda apenas pelos domínios sobre os quais tem autoridade (ou seja, os domínios dos sites hospedados no servidor), corrigindo o problema. Executando o teste novamente, o Nessus continua detectando que a porta 53 está aberta, mas não acusa mais a falha.

Concluindo, os relatórios gerados pelo Nessus podem ser salvos em diversos formatos, incluindo html, latex e PDF, um recurso extremamente interessante na hora de apresentar os resultados e explicar os problemas para outras pessoas.