por Lance E. Spitzner
Sua rede está sendo pesquisada atrás de vulnerabilidades. Isto pode acontecer somente uma vez por mês ou duas vezes por dia, não importa, existem pessoas lá fora que estão sondando tua rede e sistemas procurando fraquezas. Posso falar com certeza por que ainda não trabalhei em uma rede que não tivesse sido sondada. Minha rede pessoal de seis máquinas, em minha residência, está conectada a uma linha ISDN dedicada. Esta rede não tem nenhuma informação de valor, nem representa nenhuma organização, e mesmo assim ela é sondada duas a quatro vezes por semana. Se você tem um sistema ou rede conectado à Internet, você é um alvo. Este artigo discute como você pode proteger-se detectando estas tentativas de invasão. Também veremos o que pode ser feito quando estas tentativas são descobertas.
Os métodos que iremos discutir são simples de usar e de implementar. Para organizações maiores ou com mais conscientes da segurança, deve-se considerar sistemas de detecção de intrusos de terceiros, como o Network Flight Recorder (http://www.nfr.net/nfr/). Estes sistemas mais avançados de IDS usam análise de tráfego e algoritmos avançados para determinar se uma sondagem foi feita. Nossa abordagem será um pouco mais simples.
Existe uma variedade de sondagens diferentes que os hackers tentam. O primeiro tipo para o qual nos iremos preparar é o mais comum, a pesquisa de portas (port scans). Pesquisas de porta é o que acontece quando um indivíduo tenta conectar-se a uma variedade diferente de portas. Esta pesquisas podem ser usadas contra um alvo específico, ou usadas para pesquisar intervalos inteiros de endereços IP, geralmente escolhidos de forma aleatória. Este é um dos métodos de aquisição de informações mais popular usados por hackers, hoje em dia, uma vez que identificam portas e serviços abertos.
Para detectar estas pesquisas, vamos montar um sistema que envie mails de alerta sempre que alguém se conectar a uma determinada porta. Priemiro, identificamos de três a cinco portas mais comumente pesquisadas. Então selecionamos dois a tres sistemas para vigiar estas portas. Quando estas portas são pesquisadas, o sistema registra (log) a tentativa, executa várias ações predeterminadas, e envia uma um email de alerta para um ponto de contato.
O resultado final é que você vai receber uma mensagem para cada porta
pesquisada. Se você tem 3 sistema, cada um vigiando 4 portas, então você
irá receber até 12 emails de uma simples pesquisa de porta. Entretanto,
este não é normalmente o caso. Se houverem hackers pesquisando uma rede
inteira, eles estão procurando, normalmente, por uma única vulnerabilidade,
como o imap (porta 143). neste caso, iremos receber somente
três emails, um de cada sistema. Quando estão pesquisando um único sistema,
geralmente fazem uma pesquisa em um intervalo de portas, como da porta 1 a
1024. Neste caso, receberemos somente 4 emails, um para cada porta do
sistema. Baseado nos emails que você recebe, é fácil determinar em que o
invasor está interessado. Veja a figura 1 (no fim
do texto).
Para implementar esta metodologia, primeiro identificamos dois ou três sistemas que serão usados para monitoração. Geralmente eu seleciono servidores DNS, pois são alvos primários, muitas ferramentas de pesquisa começam pesquisando Name Servers para construir um banco de dados de endereços IP. Então seleciono de três a cinco portas mais comumente pesquisadas. Certifique-se que você não está usando estas portas, ou sempre que alguém conectar-se a estas portas você receberá um alerta. Para identificar portas normalmente pesquisadas, os alertas CERT são um bom lugar para iniciar, você pode encontrar estes alertas em http://www.cert.org/. As portas que iremos utilizar são
imap | (porta 143) |
SMB | (porta 139) |
login | (porta 513) |
http | (porta 80) |
Prefiro estas portas por que os hackers normalmente pesquisam estas, mas a maioria dos sistemas não estarão usando as mesmas. Certifique-se que estas portas não estão realmente bloqueadas por um roteador ou firewall. Iremos então configurar vários sistemas para vigiarem estas portas, alertando-nos quando houver uma conexão.
Nossa implementação usa TCP Wrappers. Criado por Wietse Venema, TCP Wrappers permite que controlemos, registremos, e, mais importante, possamos reagir a qualquer sistema protegido. Quando alguém conecta-se a um dos sistemas definidos acima, TCP Wrappers vai regsitrar a conexão (via syslog) e então disparar nosso mecanismo de alerta.
Para aqueles que não tem o TCP Wrappers instalado, eu recomendo fortemente
que o façam. É extremamente fácil de compilar, configurar e implementar.
Você pode encontrar o mesmo em muitos repositórios de ferramentas, como em
ftp://coast.cs.purdue.edu/pub/tools/unix.
Antes de compilar o mesmo, habilite extensões de linguagem no
Makefile (esta opção melhora a configurabilidade do programa).
Iremos utilizar esta capacidade para nossos objetivos de detecção de
invasão. Para mais informações sobre a instalação de TCP Wrappers, eu
recomendo que leia meu artigo "Armoring Solaris".
Uma vez o TCP Wrappers compilado e instalado, vamos proteger as quatro
portas definidas acima. As portas são definidas primeiramente em
/etc/services a então acrescentadas ao arquivo
/etc/inetd.conf. Abaixo há um exemplo de como proteger o
imap no arquivo /etc/inetd.conf.
imap stream tcp nowait root /usr/local/bind/tcpd imap.trap
Quando alguém conecta-se com a porta 143, o tcpd aceita a
conexão do inetd. Então pesquisa no arquivo
/etc/hosts.allow pelo controle de acesso. É onde definimos
quais conexões tem permissão para lançar o alerta. Finalmente, ele termina
por lançar o imap.trap. Será necessário mudar
imap.trap para cada serviço respectivamente, como
http.trap para http ou smb.trap para
smb. A seguir temos um exemplo da entrada em
/etc/hosts.allow, que nos alerta contra uma possível sonda:
imap.trap: ALL: spawn (/var/adm/ids.sh %d %h %H)
Ela informa ao tcpd para aceitar todas as conexões à porta 143, não
importando o IP, e iniciar nosso script de detecção de intruso, o script
que irá nos alertar da tentativa. Queremos o comando spawn, em
vez de twist, pois o twist utiliza o cliente
remoto para stdout (saída padrão) e stderr (saída
padrão de erros). As três expansões de parâmetros que seguem
ids.sh (definidas pelo TCP Wrappers) são variáveis.
O script /bar/adm/ids.sh é onde toda a ação acontece. Você
pode modificá-lo de acordo com seu gosto pessoal. Foi incluído um exemplo
que classifica os dados, executa um safe_finger ao cliente,
efetua um email ao ponto de contato, e, opcionalmente, lança um
snoop para rastrear qualquer ação adicional (veja a Figura 2).
A partir de agora, sempre que alguém fizer conexão a uma das portas
predeterminadas, receberemos um email formatado com todos os dados
críticos. Por exemplo, se um usuário pesquisar nossa rede atrás de portas
143, a procura de vulnerabilidades imap. Três de nossos
sistemas estarão "ouvindo" a tal porta. A conexão é feita, e o
tcpd é lançado. Este examina /etc/hosts.allow, e
encontra uma entrada para imap.trap. Este procedimento lança
nosso script de detecção de intrusão
/var/adm/ids.sh, que classifica os dados, efetua um
finger ao cliente, e envia um email de alerta. Existe também a
opção de lançar uma ferramenta, no caso, o snoop. A última
coisa que acontece é que o tcpd tenta executar
/usr/sbin/imap.trap, que não é encontrado. O tcpd
sai, registrando um erro no syslog. Para evitar isto, você
pode criar um shell script /usr/sbin/imap.trap, que não faz
nada além de sair.
Uma coisa que deve-se ter em mente são os ataques do tipo "Denial of
Service" (N.T.: DoS - Negação de Serviço, um ataque feito de forma a
sobrecarregar um serviço, até que o mesmo não consiga mais atender demandas
legítimas, tipo sobrecarregar um servidor Web a ponto do mesmo não ser mais
acessível por ninguém). Quanto mais coisas teu script fizer, mais ele irá
sobrecarregar o sistema. Um ataque pode desabilitar o sistema ao fazer
múltiplas conexões para determinadas portas, criando múltiplos processos do
script. Recomenda-se que, se você implementa uma variedade de ações em
seus scripts, estabeleça um limite ao número de processos por endereço IP
fonte. Uma maneira simples de conseguir isto é usar um grep
sobre o tcpdlog, procurando pela origem. Se você não encontra
a fonte, é a primeira vez que o sistema efetuou um teste sobre você, então
execute o script de classificação. Caso contrário, o sistema origem já
havia feito uma pesquisa anteriormente, o que pede apenas um registro da
entrada.
Uma alternativa ao uso de TCP Wrappers é registrar rotas.
Muitos de nós não podem ser dar ao luxo de usar três sistemas para detectar
intrusões. Entretanto, pode-se usar a metodologia descrita acima sobre seu
roteador Internet. Novamente, você seleciona dois ou três sistemas e três
ou quatro portas para serem monitoradas. Crie uma ACL
(Access Control List - Lista de Controle de Acessos) em seu
roteador que proíba as portas e sistemas especificados. Faça esta ACL
registrar todas as tentativas de conexão em um servidor de
syslog. Desta forma, é possível monitorar qualquer tráfego
proibido e rapidamente determinar se sua rede foi testada. Eu obtive muito
sucesso implementando isto como o Swatch, que automatiza tanto
o processo de filtragem quanto o processo de alerta.
Estas soluções não são à prova de idiotas. Muitos dos port
scanners atuais não completam a seqüência SYN/ACK
durante uma conexão. De fato, muitas pesquisas usam pacotes inválidos (como
as pesquisas FIN e Xmas). O método que foi
discutido aqui não detecta algumas destas pesquisas. Para uma detecção de
intrusos mais robusta, há a necessidade de ferramentas mais avançadas,
capazes de detectar estas pesquisas "stealth".
Existem outras maneiras de implementar detecção de intrusos em seu sistema.
Novamente, é preciso primeiro identificar a metodologia da invasão, e então
implementar um procedimento de rastreio e alerta. Um exemplo seria
tentativas de força bruta para efetuar um login. Cinco
tentativas consecutivas de fazer login são registradas no arquivo
/var/adm/loginlog. Isto pode acontecer quando um hacker está
testando seu sistema atrás de combinações fracas de login/senha. Eu
configurei meu sistema para executar um cronjob diariamente e
verificar se existem quaisquer entradas no arquivo. Se existem, ou alguém
esqueceu sua senha e está tentando adivinhar a mesma, ou um hacker em
potencial está tentando uma entrada usando força bruta. O cronjob envia as
entradas via email, copia para um arquivo, e limpa o arquivo de log. Outro
exemplo é o ataque /cgi-bin/test-cgi, comumente usado contra servidores
web. Em vez de desabilitar este script cgi, eu alterei o mesmo para
efetuar um log e enviar um mail quando alguém tenta esta invasão. Isto não
envolve mais que a alteração do shell script test-cgi (certifique-se de
testar o mesmo antes de implementá-lo em seu sistema).
Como demonstramos, existem uma variedade de maneiras simples de implementar alguma detecção básica de invasão. Apesar de não serem à prova de idiotas, estas metodologias ajudam a identificar sondagens potenciais e a proteger sua rede. Agora, que você implementou detecção de intruso, o que fará quando descobrir que seus sistemas estão sendo testados?
O primeiro paso é confirmar que seus sitemas estão realmente sendo sondados. Só por que você recebe um alerta de email do seu TCP Wrappper NÃO significa que você está sendo testado. Um usuário confuso pode estar conectando ao sistema errado, ou alguém simplesmente apertou uma tecla errada. Nada é mais embaraçante que acusar alguém de algo que esta pessoa não fez. Entretanto, se você tem três sistemas consecutivos pesquisados na mesma porta e na mesma hora, isto indica que você foi sondado. E agora?
A última coisa que você quer é lançar um contra ataque no sistema e tirar o mesmo do ar. Quando sua rede é pesquisada, você pode se sentir frustrado e querer devolver a frustração ao sistema que sondou você... Já que tem alguém se preparando para te atacar, você não deveria agir? Entretanto, você deve ser cuidadoso na forma de reagir.
Mesmo com as melhores intenções, você pode fazer mais mal que bem. Por exemplo, digamos que você descubra que o sistema que efetuou a pesquisa foi atacado e alterado, e está sendo usado como ponto de lançamento. Você identifica a saída que o hacker deixou, obtém acesso, copia todas as ferramentas e reigistros usados, e faz uma notificação ao proprietário do sistema e várias organizações de resposta a emergências. Mesmo pensando que você fez a coisa certa, você causou mais mal que bem.
Basicamente, existem muitas coisas que podem dar errado e não muitas coisas
que podem dar certo quando você age por conta própria. A melhor coisa que
você pode fazer é primeiro obter o máximo de informações que puder.
Identifique qualquer registro que mostre as sondagens partindo do endereço
identificado. Então identifique os indivíduos e organizações responsáveis
pelo incidente. O banco de dados wois, dig, e
nslookup são excelentes métodos para descobrir quem é o
responsável pelo sistema. Envie um email ao mesmo com detalhes sobre o que
aconteceu, quando, e inclua entradas de log para verificação. Você pode
tambem enviar uma cópia para a organização, para manter os mesmos
informados. Se as invasões forem sérias o suficiente, faça contato com
organizações de resposta profissionais, como o CERT http://www.cert.org/ ou o CIAC em http://www.ciac.org/. Se as tentativas de
invasão continuarem, sem resposta de parte dos proprietários do sistema,
entre em contato com a organização. O telefone pode ser uma ferramente
muito poderosa.
Cedo ou tarde, teus sistemas e redes podem ser sondados atrás de vulnerabilidades. Tomando algumas das medidas básicas que discutimos, você estará melhor preparado para registrar e identificar estas tentativsa. Uma vez identificadas, você pode rastrear estas sondas e conseguir um melhor entendimento das ameaças à sua rede e a reagir a estas ameaças. Quando identificar a ameaça, é melhor coletar o máximo possível de informações, e notificar os indivíduos e a organização responsável pelo sistema. Agir por conta própria geralmente cria uma baderna, causando mais problemas que benefícios. Trabalhando em conjunto com outros, pode-se chegar a uma solução melhor.
Subject: ### Intrusion Detection Alert ###
You have received this alert because the network
is potentially being scanned. The information below
is the packet that was logged and dropped.
Date: Sat Jan 24
Time: 18:47:46
Source: ICARUS.CC.UIC.EDU
Destination: lisa
Service: imap
--- Finger Results ---
[ICARUS.CC.UIC.EDU]
Login Name TTY Idle When Where
Spitzner Lance Everett Spitzn pts/72 Sun 18:42 lspitz-4.soho.entera
#!/bin/ksh
#
# Script launched by tcpd for intrusion detection purposes
#
USER=lance@spitzner.net
SRV=`echo $1 | cut -f1 -d.`
DATE=`date "+%a %b %e"`
TIME=`date "+%T"`
FINGER=`/usr/local/bin/safe_finger @$2`
MAIL=/usr/bin/mail
$MAIL $USER <<EOF
Subject: ### Intrusion Detection Alert ###
You have received this alert because the network
is potentially being scanned. The information below
is the packet that was logged and dropped.
Date: $DATE
Time: $TIME
Source: $2
Destination: $3
Service: $SRV
--- Finger Results ---
$FINGER
EOF
##### If the service is imap, lets go ahead and snoop the session.
if [ $SRV=imap ]; then
snoop -v -c 5000 -o /var/adm/$2_snoop.$$ $2 &
fi
Lance Spitzner gosta de aprender detonando seus sistemas Unix em casa. Antes disso, ele foi um Oficial na Rapid Deployment Force, onde detonava coisas de natureza bem diferente. Você pode encontrá-lo em lance@spitznet.net