DETECÇÃO DE INVASÃO
Sabendo quando alguém está batendo em sua porta
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.
CONFIGURANDO A DETECÇÃO DE INVASÃO
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 emaisl 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 - Recusa 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 seu sistema ao fazer múltiplas conexões
para determinadas portas, criando múltiplos processos de teu 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 metodo que
foi discutido aqui não detecta algumas destas pesquisas. Para uma detecção de
intrusos mais robustas, 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?
REAGINDO A UMA INVASÃO
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.
1. Seus sistemas pode ter sido pesquisados, mas por acidente. Muitas vezes,
grandes empresas pesquisam suas redes internacionais e escritórios remotos.
Alguém pode ter pesquisado a rede errada (pessoalmente sei de um acontecimento
destes em uma organização).
2. Geralmente os responsáveis pelo sistema que pesquisou sua rede não tem
idéia do que aconteceu. Grandes sistemas com centenas de usuários podem ter um
usuário malicioso que esteja usando ilegalmente sua conta para sondar outras
redes. Ou o sistema foi alterado e está sendo usado como ponto de lançamento.
De qualquer forma, o administrador do sistema certamente vai gostar de saber e
corrigir o problema.
3. O IP de origem mostrado em seu registro pode não ser válido, podendo até
mesmo ser uma isca. Muitas ferramentas de pesquisa permitem ao usuário alterar
o endereço IP da origem dos pacotes para qualquer coisa que o usuário queira.
Seus logs podem mostrar que seu sistema foi pesquisado de cinco diferentes
origens, mas você foi pesquisado, na verdade, a partir da mesma máquina. O
usuário está tentando esconder a verdadeira fonte da sonda pelo uso de falsos
endereços IP. É extremamente difícil determinar qual das pesquisas é a
verdadeira sonda. E, também, o usuário pode ter falsificado o endereço IP para
colocar a culpa em outra pessoa.
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.
1. Provavelmente o hacker substituiu várias ferramentasde monitoramento e
registros no sistema comprometido. Ele pode descobrir que você esteve lá, e
simplesmente apagar o sistema para apagar qualquer traço de sua passagem
(destruindo a máquina desta forma).
2. O administrador do sistema pode saber do hacker e estar trabalhando com as
autoridades. Você acabou de detonar a investigação toda.
3. Você pode receber a culpa do incidente. O proprietário do sistema não te
conhece, e pode acusar você de ser o hacker original, que estaria tentando
proteger-se colocando a culpa em outra pessoa.
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çãol. O
telefone pode ser uma ferramente muito poderosa.
CONCLUSÃO
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.
Figure 1
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
Figure 2
#!/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 < ( geocities.com/br)