Introdução
A análise de logs é um dos aspectos mais negligenciados da questão de detecção de invasão. Hoje em dia todo desktop tem um anti-vírus, empresas com multiplos firewalls e até mesmo os mais simples usuários compram os ultimas ferramentas de segurança.
Agora, quem fica prestando atenção em toda informação que estas ferramentas geram? Ou pior, quem está prestando atenção nos registros do seus servidores de web e mail ou os logs de autenticação? Eu não estou falando sobre estatísticas bonitinhas dos seus logs de web (como o webalizer). Eu estou falando de informações de segurança cruciais que muitos desses eventos tem mas ninguem observa. Muitos dos ataques não aconteceriam (ou terminariam mais cedo) se os administradores se preocupassem em monitorar seus logs.
Nós não estamos falando que a análize de log é fácil ou que vc deve fazer manualmente olhando seus logs que entram todo dia. Por causa da complexidade e alto volume, a análize automática é ecencial. Estas são apenas algumas coisas que uma ferramenta de análize de logs deve fazer:
* Entender seus logs. Saber se são bons ou mals.
* Correlacionar os eventos maus observando com testes padrões indicativos de ataques ou intrusão.
* Correlacionar os eventos bons com os mals (por exemplo vários logins falhos seguidos de um com sucesso).
* Correlacionar os bons eventos (por exemplo vários logins com sucesso para o mesmo usuário através de vários hots em um curto expaço de tempo).
* Procurar por testes incomuns que não estão na sua bad list.
Natualmente executar tudo isso não é fácil. O objetivo principal deste documento é mostrar a você como uma ameaça pode ser detectada correlacionando testes padrões com seus logs de web, proxy e autenticação. Nos estamos usando o OSSEC HIDS como examplo porque não só faz estas análizes mas também possúi regras para multiplos formatos de logs, tornando esse correlacionamento mais simples.
Análize de logs do proxy
Quando nos referimos a análize de logs de proxy, nós geralmente usamos o squid como exemplo pois ele é o web proxy mais usado até agora. Quando o squid é implementado corretamente, todo o trafego passará pelo proxy sem nenhuma configuração extra no lado do usuário. Por causa disso, nós temos todo acesso a toda página que os usuários estão acessando. Observer o que nós detectamos com a análize dos logs do proxy é geramlmente de grande importância, porque vem de dentro da sua rede. Em seguida é mostrado algumas das formas como nós podemos monitorar os logs de nosso proxy:
Usuários internos fazendo varredura ou atacando sistemas externos
Basicamente, toda vez que um usuário acessa a uma página não existente, o squid grava o log do código de erro de HTTP (geralemente 404 ou 403). Se você ver vários códigos de erro 400 vindos de um mesmo IP em um curto tempo, um aviso deve ser enviado. Se o usuário estiver acessando uma página com links quebrados, isso pode significar um falso positivo, assim nós devemos ignorar as extenções .gif, .jpg e .png (entre outras). Usando esta aproximação, nós podemos detectar usuários internos tentando scanear ou recolhendo informações de sistemas ou sites externos. UM NIDS (Sistema de detecção de untrusão baseado em rede - Network-based Intrusion Detection System) ou uma análize baseada em assinatura seria necessário.
Usuários internos com worms, trojans ou vírus
Uma gama de worms são expecíficos para ficar acessando um site web ou uma página externa. Detectar estes acessos pode indicar um usuário interno infectado. Por exemplo, no caso do worm W32.Beagle infectar uma máquina, ele tentará acessar páginas com extenções "xxx3.php" ou "blst.php" para notificar o criador do worm. Se nós olharmos as entradas dos logs, nós sabemos que há algo errado. Abaixo você pode ver o exemplo de um alerta do OSSEC de um usuário infectado:
OSSEC HIDS Notification.
2006 May 11 11:00:00
Received From: (web-proxy) 192.168.2.1->/usr/local/squid/var/log/access.log
Rule: 5054 fired (level 12) -> "Infected machine with W32.Beagle.DP.'"
Portion of the log(s):
524 192.168.2.204 TCP_MISS/404 590 GET http://www.ordendeslichts.de/intern/xxx3.php? - DIRECT/81.201.107.6 text/html
3571 192.168.2.204 TCP_MISS/404 470 GET http://www.levada.ru/htmlarea/images/xxx3.php? - DIRECT/62.118.252.213
466 192.168.2.204 TCP_MISS/404 543 GET http://www.etype.hostingcity.net/mysql_admin_new/images/xxx3.php? - DIRECT/217.158.10.80 text/html
516 192.168.2.204 TCP_MISS/404 423 GET http//www.deadlygames.de/DG/BF/BF-Links/clans/xxx3.php? - DIRECT/81.169.145.95 text/html
528 192.168.2.204 TCP_MISS/404 423 GET http://stroyindustry.ru/service/construction/xxx3.php? - DIRECT/217.16.16.135 text/html
950 192.168.2.204 TCP_MISS/404 686 GET http://service6.valuehost.ru/images/xxx3.php? - DIRECT/217.112.42.95 text/html
505 192.168.2.204 TCP_MISS/404 1368 GET http://schiffsparty.de/bilder/uploads/xxx3.php? - DIRECT/212.227.94.133 text/html
Usuários inválidos na rede
Alguns proxy requerem autenticação do usuário. Neste caso o usuários não possúi uma credencial válida, gerando um log. Se nós olharmos um ou dois erros de autenticação, isto pode indicar que o usuário esqueceu a senha. Agora, vendo vários erros vendiso do mesmo IP, é um sinal que algo está errado (especialmente se forem usuários diferentes). Veja dois exemplos de mensagens de erro de autenticação gerados pelo squid:
1134746808.068 34 10.1.2.3 TCP_DENIED/407 2675 GET http://www.test.com/ user NONE/- text/html
1096907971.215 4 10.1.2.4 TCP_DENIED/407 3715 GET http://www.microsoft.com/isapi/redir.dll? - NONE/- text/html
Emprego de proxy errado ou violações de acesso
Se você instalar um proxy web, provavelmente você estará usando somente para tráfego web. Entretando, alguns usuários tentam usar protocolos similares para enviar e-mails externos ou relay para outros protocolos que seriam barrados de outra forma. Por exemplo, um problema comum do squid é usuários tentando usar isto para enviar e-mails. Isto pode ser facilmente resolvido bloqueando a porta 25, mas você quer saber quem está fazendo isso. Para monitorar acesso de todas as portas não usadas, nós podemos buscar o usuário. A distribuição de alertas mostrados por um usuário interno tentando enviar um e-mail:
OSSEC HIDS Notification.
2006 May 12 07:05:12
Received From: (web-proxy) 192.168.2.1->/usr/local/squid/var/logs/access.log
Rule: 5051 fired (level 10) -> "Multiple attempts to access forbidden file or directory from same source ip.'"
Portion of the log(s):
0 192.168.2.135 TCP_DENIED/403 1382 CONNECT 65.54.245.104:25 - NONE/- text/html
2 192.168.2.135 TCP_DENIED/403 1378 CONNECT 4.79.181.14:25 - NONE/- text/html
0 192.168.2.135 TCP_DENIED/403 1390 GET http://www.ebay.com/ - NONE/- text/html
3 192.168.2.135 TCP_DENIED/403 1378 CONNECT 4.79.181.14:25 - NONE/- text/html
5 192.168.2.135 TCP_DENIED/403 1392 GET http://www.yahoo.com/ - NONE/- text/html
6 192.168.2.135 TCP_DENIED/403 1384 CONNECT 66.135.192.123:80 - NONE/- text/html
2 192.168.2.135 TCP_DENIED/403 1380 CONNECT 66.94.230.75:80 - NONE/- text/html
420 192.168.2.135 TCP_DENIED/403 1390 GET http://www.ebay.com/ - NONE/- text/html
6 192.168.2.135 TCP_DENIED/403 1384 CONNECT 66.135.192.123:25 - NONE/- text/html
Violação de policiamento
Algumas empresas não permitem acesso a webmails externos ouo sites pornográficos no trabalho. Com o squid, você pode diretamente bloquear estes acessos, mas você necessita saber quem está tentando acessar as páginas proibídas. Usando a análize de logs, você pode criar uma lista de sites ou IPs indesejados ou bloquear um termo. Por default isto não é abilitado no OSSEC porque cada compania tem sua política, mas nós temos uma longa lista de webmails comuns, IPs/Sites pornográficos, sites de jogos, etc.
Análise de log de Web
Algumas pessoas usam um (IDS baseado em rede), como o Snort, para detectar ataques contra aplicações web. Entretando, muitos NIDS não possúem um bom sistema de correlação para tráfego web e isto deixa muitas informaçeos importantes, incluindo erros internos, códigos de retornos, etc. Se seu site roda em SSL, um NIDS é completamente inútil. Estes são alguns casos que podemos detectar monitorando os logs de web:
Scaneamento web ou colhendo informações
Quando alguém tenta conseguir acesso ilegal ao seu sistema, ele ou ela provavelmente scaneia buscando por aplicações vulneráveis (como versões antigas do awstats ou phpbb ). Isto faz com que seu servidor gere várias mensagens 400 de erro. Se nós detectarmos alguns destes em um pequeno intervalo de tempo vindos de um mesmo IP, nós podemos levantar a bandeira (enviar o aviso). Algumas vezes isto pode gerar falso positivos se seu site tiver links quebrados, assim ignoramos extenções .gif, .jpg and .png (como fazemos com os logs do squid). usando este tipo de correlação, nós podemos detectar novos worms ou vulnerabilidade dia zeroem sistemas web. Abaixo vários erros 404 (olhando para xmlrpc) são exemplos de scaneamendo web:
200.179.157.1 - - [13/Jan/2006:01:03:30 -0200] "POST /blog/xmlrpc.php HTTP/1.0" 404 288
200.179.157.1 - - [13/Jan/2006:01:03:31 -0200] "POST /blog/xmlsrv/xmlrpc.php HTTP/1.0" 404 295
200.179.157.1 - - [13/Jan/2006:01:03:32 -0200] "POST /blogs/xmlsrv/xmlrpc.php HTTP/1.0" 404 296
200.179.157.1 - - [13/Jan/2006:01:03:33 -0200] "POST /drupal/xmlrpc.php HTTP/1.0" 404 290
200.179.157.1 - - [13/Jan/2006:01:03:35 -0200] "POST /phpgroupware/xmlrpc.php HTTP/1.0" 404 296
200.179.157.1 - - [13/Jan/2006:01:03:36 -0200] "POST /wordpress/xmlrpc.php HTTP/1.0" 404 293
200.179.157.1 - - [13/Jan/2006:01:03:44 -0200] "POST /xmlrpc/xmlrpc.php HTTP/1.0" 404 290
200.179.157.1 - - [13/Jan/2006:01:03:46 -0200] "POST /xmlsrv/xmlrpc.php HTTP/1.o
Ataques com sucesso e falhos em aplicações web
NIDS sempre olha um conteúdo específico antes de alertar que um ataque está ocorrendo. Entretando, usando a análize de logs, nós podemos ver quando estiver ocorrendo um ataque ou não. Muito melhor, nós podemos ver os registros de conecções SSH que os NIDS não veem. Com poucas regras, nós podemos detectar injeções de SQL, problemas de diretórios tranversais, tentativas de executar comandos e vários outros ataques (com sucesso ou não).
Por exemplo, para detectar injeções no SQL, nós olhamos para algum comando SQL como select, where ou from. O mesmo se aplica a detectar tentativas de executar comandos. Cada sistema possúi vários comandos que se deve monitorar, como cat, grep, wget, dir, ls, etc. Nós precisamos observar por espaços, novas linhas, ou terminais nulos, porque são usados extensamente (e necessários) nas tentativas de execução de comandos. As regras do OSSEC para logs de web contem mais informações.
Por exemplo, nestes dois ataques de awstats. Nós vemos comandos comuns do sistema, separadores e caracteres incomuns na url. Olhando o código de resultado do HTTP, nós verificamos que um foi sucesso e o outro não (erro 404 e 200). Com acesso a informação nós podemos aumentar a severidade desta que trabalhou e diminuir desta que falhou. No OSSEC, nós fazemos isso para ataques web comuns. Se forem bem sucedidos, nós aumentamos a severidade e imediatamente alertamos o administrador e executamos uma resposta ativa.
a.b.c.d - - [13/Jan/2006:01:07:21 -0200] "GET /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget...;echo%20YYY;echo|HTTP/1.0" 404 291
a.b.c.d - - [14/Jan/2006:01:01:25 -0200] "GET /cgi-bin/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget...;echo%20YYY;echo|HTTP/1.0" 200 291[code]
Em acrécimo a isto, abaixo ataques mrgt são mostrados como outro exemplo disto:
[code] a.b.c.d - - [12/Apr/2006:08:05:46 -0300] "GET /rpc/..%%35%63..%%35%63..%%35%63..%%35%63/winnt/system32/cmd.exe?/c+dir+c:\\+/OG
HTTP/1.0" 400 294 200.179.154.180 - - [12/Apr/2006:08:05:47 -0300] "GET /cgi-bin/%2E%2E%2F%2E%2E%2F%2E%2E%%4E%4E%54%2F%73%79%73%74%65%6D%33%32%2Fping.exe%20127.0.0.1
200.255.5.3 - - [12/Apr/2006:08:05:43 -0300] "GET /cgi-bin/mrtg.cgi?cfg=/../../../../../../etc/passwd HTTP/1.0" 404 289
200.255.5.3 - - [12/Apr/2006:08:05:43 -0300] "GET /cgi-bin/mrtg.cgi?cfg=/../../../../../../winnt/win.ini HTTP/1.0" 404 289[/code]
[b]Problemas em servidores web[/b]
Uma gama de problemas em seu servidor web pode ser detectado olhando os logs. Por exemplo, os seguintes erros passariam despercebidos se não estivéssemos monitorando isto (alerta do OSSEC enviado pelo e-mail):
[code] OSSEC HIDS Notification.
2006 May 12 04:40:17
Received From: (web-server) 10.1.1.25->/var/log/apache/error_log
Rule: 102 fired (level 7) -> "Unknown problem somewhere in the system.'"
Portion of the log(s):
*** glibc detected *** corrupted double-linked list: 0xb7daca0c ***
OSSEC HIDS Notification.
2006 May 10 16:41:31
Received From: (intra-server) 10.1.2.41->/var/log/apache/error_log
Rule: 102 fired (level 7) -> "Unknown problem somewhere in the system.'"
Portion of the log(s):
[client 201.25.30.140] PHP Fatal error: Allowed memory size of 31457280 bytes exhausted (tried to allocate 39518206 bytes) in /home/site/htdocs/components/com_search/search.php on line 172, referer: http://www.mysite.com.br/index.php?option=Itemid=5&searchword=+SNORT+%2B+MYSQL+%2B+APA[/code]
[b]Análise de log de autenticação[/b]
Análise de mensagens de autenticação é extremamente crucial. Primeiro, você pode olhar quem acessou e quando especificamente. Segundo, você pode ver se alguem acessou algo que ele (a) não deveria. Você pode também procurar erros internos empregados para fora vendo as horas e os usuários de sistema que estão tentando acessar. Em acrécimo a isto, ataques brute force e outros supostos erros com senha podem ser detectados.
[b]Usuários acessando o que não deve[/b]
Muitas ferramentas de análise de logs sempre alertam tentativas de logins falhos. Entretanto o que acontece se ele(a) acessar um dispositivo que não deveria? Ou acessando quando ele(a) deveria estar trabalhando? Durante a análize, nós necessitamos criar uma base de dados para todos os usuários e sistemas que são eprmitidos o acesso. Esta técnica é usada pelo OSSEC e o chamado FTS (Visto pela primeira vez aqui). Toda vez que que o usuário acessar o sistema o OSSEC verá que o usuário nunca acessou antes, então será gerado um alerta. No primeiro dia, o OSSEC estará "aprendendo" o que os usuários acessam, causando alertas extras. Entretanto, depois disto, a base estará criada e sempre que os usuários se desviarem será dado o alerta. Com o FTS, você pode descobrir usuários inválidos na rede e usuários acessando o que não devem.
[b]Logins de usuários do sistema[/b]
Usuários do sistema são usados somente para finalidades internas e nós nunca veremos um logins com eles. Se nós virmos um destes acessando a máquina pod ssh, telnet,ftp ou outro método deverá ser dado o alerta. Isto pode indicar que uma aplicação ou processo está comprometido. OSSEC possúi uma lista de usuários de sistema (como apache, mysql, nobody, portmap, www, bin, etc). Isto é de muita ajuda para identificar isso. Exemplo de alerta do OSSEC quando o usuários nobody efetua um login:
[code] OSSEC HIDS Notification.
2006 May 12 08:59:45
Received From: (auth1) 192.168.20.55->/var/log/messages
Rule: 1601 fired (level 12) -> "System user sucessfully logged on the system.'"
Portion of the log(s):
sshd[23410]: Accepted password for nobody from 10.1.2.3 port 42802 ssh2[/code]
[b]Vários logins falhos[/b]
Brute force e ataques de dicionário são comuns mas você deve bloquear isto monitorando seus logs de autenticação. Primeiro, se você ver vários logins falhos vindos de um mesmo IP em poucos minutos, isto é provavelmente é um ataque. Segundo, se você ver vários logins falhos de IPs diferentes, isto provavelmente é um ataque distribuído ou um erro interno do seu sistema. Abaixo um alerta do OSSEC para um ataque brute forte com SSH:
[code]OSSEC HIDS Notification.
2006 May 11 21:17:07
Received From: /var/log/messages
Rule: 1512 fired (level 10) -> "SSHD brute force trying to get access to the system.'"
Portion of the log(s):
sshd[9370]: Failed password for invalid user admin from 200.30.175.162 port 58257 ssh2
sshd[9370]: Invalid user admin from 200.30.175.162
sshd[9368]: Failed password for invalid user fluffy from 200.30.175.162 port 58212 ssh2
sshd[9368]: Invalid user fluffy from 200.30.175.162
sshd[9366]: Failed password for invalid user slasher from 200.30.175.162 port 58109 ssh2
sshd[9366]: Invalid user slasher from 200.30.175.162
sshd[9364]: Failed password for invalid user sifak from 200.30.175.162 port 58030 ssh2[/code]
[b]Vários logins falhos seguidos de um login com sucesso[/b]
Este é um evento sério. Se você ver tentativas de vários usuários e vários passwords de um mesmo IP, seguidos por um sucesso, Um atacante provavelmente está com sorte. Isto pode ser um usuário que lembrou a senha depois de vários erros, causando um falso positivo. Entretando se vários usuários forem tentados, a possibilidade de ser um falso positivo é mínima.
[b]Conclusão[/b]
Este documento não está terminado ainda. Nós adicionaremos mais informações abrangendo mail, NIDS, Fireall, sistemas de logs genéricos e análize de logs do windows. nós estamos aceitando mais idéias e contribuições para faze-lo mais confiável e útil para a comunidade de segurança..
[b]Link do artigo original[/b]
* http://www.ossec.net/en/loganalysis.html
[b]Autor[/b]
* Daniel B. Cid (dcid@ossec.net)
[b]Tradução[/b]
* White_Tiger (willian@underlinux.com.br)
Retirado de "http://wiki.underlinux.com.br/index.php/Artigos/Logs-Analysis"
[/code]