Linux, Sistema inteligente, criado por pessoas inteligêntes, para pessoas inteligentes!!!

O presente artigo apresenta algumas técnicas e procedimentos dos quais os administradores de redes podem se valer para detectar e diagnosticar uma intrusão, usando uma das ferramentas mais poderosas e, ao mesmo tempo, muito simples: os logs!

Introdução

Imagine que você chegue em sua casa e perceba que ela foi aparentemente violada. O que você faz? Procura por pistas como: vidros quebrados, marcas na maçaneta, trincos forçados, portas arrombadas, objetos desaparecidos, em resumo, sinais que caracterizem e permitam estabelecer a magnitude da violação.
Analogamente, nos sistemas computacionais, intrusos deixam pistas, porém, diferente do "mundo real", as pistas estão nos registros de atividades do sistema, o qual denominamos de logs. Melhor ainda, os logs podem desempenhar um papel preventivo, na medida em que podem registrar as eventuais tentativas de ataque.
Este artigo visa familiarizar o administrador (em particular, de um sistema UNIX) com o processo de detecção, procurando pelas "pegadas" deixadas por métodos de intrusão conhecidos. Em sistemas configurados de forma correta, tais "pegadas" poderão indicar como um atacante invadiu (ou tentou invadir) seu sistema e, eventualmente, lhe dará uma idéia de sua identidade.

Arquivos de logs básicos sistemas de sistema Unix

Os diretórios comumente usados pelo UNIX para armazenar logs são: /usr/adm, /var/adm, /var/log, /etc e /etc/security. A localização exata depende do tipo e da versão do sistema operacional utilizado.
A seguir, serão apresentados alguns dos arquivos de logs encontrados em tais diretórios. É dado ênfase aqueles considerados mais importantes no processo de detecção de intrusão.
ARQUIVO lastlog
Arquivo binário que registra o horário da última vez que o usuário tentou acessar o sistema seja com ou sem sucesso. O seu conteúdo muda a cada login e é reportado toda vez que o usuário entrar no sistema ou o comando finger for executado. No Linux, estes registros devem ser explicitamente habilitados configurando a variável LASTLOG_ENAB do arquivo /etc/login.defs.

Recomenda-se configurar as permissões deste arquivo para 644, tendo como dono o usuário root.
A seguir, mostra-se um exemplo da saída gerada durante um processo de login na máquina maq2.

Connected to maq2.dominio.rnp.br.
Escape character is '^]'.

UNIX(r) System V Release 4.0 (maq2)

login: nina
Password:

Last login: Mon Feb 12 18:55:09 from maq5.dominio.rnp.br
Sun Microsystems Inc. SunOS 5.5 Generic November 1995
You have new mail.
maq2:nina[6]>

ARQUIVO utmp/utmpx
Estes arquivos registram informações relacionadas a usuários locais que encontram-se conectados ao sistema nesse momento. Os dados contidos nestes arquivos são armazenados em formato binário. Portanto, deverão ser lidos usando comandos específicos, tais como: who, whodo, write, finger e ps, os quais reportam as informações contidas neste arquivo.
Recomenda-se configurar como dono o usuário root e as permissões de acesso para 644.
Abaixo, é mostrado um exemplo de execução do comando who:

maq0:nina[5]> who
nina console Feb 10 15:23
raul pts/1 Feb 10 18:46 (maqA.rnp.br)
marcio pts/2 Feb 11 07:42 (maqB.rnp.br)
nina pts/3 Feb 11 11:29 (maq1.dominio.rnp.br)
nina pts/4 Feb 11 16:04 (maq2.dominio.rnp.br)

ARQUIVO wtmp/wtmpx
Registram dados detalhados sobre uma determinada sessão de usuário. Da mesma forma que os arquivos descritos anteriormente, os dados contidos nestes arquivos são armazenados em formato binário e legíveis unicamente através de comandos do tipo: last, acctcom, etc.
Recomenda-se configurar as permissões destes arquivos para 644, tendo como dono o usuário root.
Parte da saída da execução do comando last é mostrada a seguir:

ftp ftp 200.252.2.100 Mon Feb 12 19:49 - 19:55 (00:06)
nina pts/0 maq3.dominio.rnp. Mon Feb 12 18:05 - still logged in
reboot system boot Mon Feb 12 18:03
usuario1 pts/3 maq3.dominio.rnp. Mon Feb 12 17:36 - 18:02 (00:25)
ftp ftp site1.qqdominio.d Mon Feb 12 15:57 - 16:04 (00:07)

Vale a pena ressaltar que, em plataformas Solaris, este arquivo trunca os nomes das máquinas. Assim, quando executado o comando last, ele lista tais máquinas de maneira incompleta.
ARQUIVO sulog
Registra tentativas de execução do comando su, tenham sido estas bem ou mal sucedidas. Estes registros são habilitados através dos arquivos: /etc/default/su, no Solaris (variável SULOG) e /etc/login.defs, no Linux (variável SULOG_FILE).
Recomenda-se que este arquivo tenha como dono o usuário root e suas permissões de acesso configuradas para 600.
As seguintes linhas contidas em um arquivo sulog de um sistema Linux, mostram, respectivamente, a execução mal (-) e bem (+) sucedida do comando su. O usuário admin1 tornou-se root após uma tentativa falha e o usuário usuario1 tornou-se o usuario2.

SU 02/11 12:24 - ttyp3 admin1-root
SU 02/11 12:25 + ttyp3 admin1-root
SU 02/11 12:30 + ttyp4 usuario1-usuario2

ARQUIVO messages
Arquivo que registra qualquer mensagem enviada ao console, tendo sido ela gerada pelo kernel do sistema ou por algum mecanismo de logging tal como o syslog, o qual será abordado posteriormente.
Recomenda-se que este arquivo tenha como dono o usuário root e suas permissões de acesso configuradas para 400.
A seguir, mostra-se parte de um arquivo messages:

Aug 26 11:27:47 maq5 lpd[102]: restarted
Aug 26 11:27:48 maq5 /kernel: ed1: device timeout
Aug 26 11:28:03 maq5 last message repeated 2 times
Aug 27 02:04:44 maq5 inetd[835]: login_getclass: unknown class 'root'
Aug 27 15:54:35 maq5 login: login_getclass: unknown class 'root'
Aug 27 15:54:37 maq5 login: ROOT LOGIN (root) ON ttyv0

ARQUIVO loginlog
Registra tentativas falhas de acesso a um sistema. No Solaris, para habilitar os logs neste arquivo, bastará criá-lo, pois, na configuração original, ele não existe. No Linux, é preciso configurar a variável FAILED_LOG do arquivo /etc/login.defs.
Para gerar logs de entrada neste arquivo, é preciso indicar o número mínimo de tentativas consecutivas sem sucesso. "Por default," no Solaris e no Linux este número é de cinco, mas ele pode ser alterado. No Linux isto é feito através do arquivo /etc/login.defs (variável LOGIN RETRIES).
Recomenda-se configurar as permissões deste arquivo como 600, tendo como dono o usuário root.
A seguir, é mostrado parte do conteúdo de um arquivo loginlog, onde foi configurado como sendo três o número mínimo de tentativas sem sucesso.

usuario1:/dev/pts/9:Wed Dec 2 16:06:12 1998
usuario1:/dev/pts/9:Wed Dec 2 16:06:19 1998
usuario1:/dev/pts/9:Wed Dec 2 16:06:26 1998
usuario5:/dev/pts/9:Wed Apr 01 09:06:33 1999
usuario5:/dev/pts/9:Wed Apr 01 09:06:39 1999
usuario5:/dev/pts/9:Wed Apr 01 09:06:39 1999

ARQUIVOS pacct/acct
Estes arquivos registram comandos executados individualmente pelo usuário. O mecanismo de logging que utiliza arquivos deste tipo é conhecido como process accounting (processo de contabilidade) e deverá ser inicializado pelo usuário root.
No Solaris, isto é feito através do comando:
# /usr/lib/acct/accton /var/adm/pacct
Para finalizá-lo, bastará executar o mesmo comando sem argumentos. Vale a pena salientar que, usado em conjunto com o arquivo wtmp é possível fazer um rastreamento dos horários em que tais comandos foram executados. O script /usr/lib/acct/startup executa esta função.
No Freebsd, o processo de contabilidade é inicializado mediante o comando accton, tendo como argumento o arquivo de contabilidade default, que é o /var/account/acct. A princípio, este arquivo não existe e, portanto, deverá ser criado. Para finalizar este processo basta executar o mesmo comando sem argumentos.
No Linux, o processo de contabilidade poderá ser ativado conforme descrito no documento: Process-Accounting (mini-HOWTO)
Recomenda-se que estes arquivos tenham como dono o usuário root e suas permissões de acesso configuradas para 600.
No AIX, o arquivo de contabilidade padrão é o /var/adm/pacct. Ele deverá ser expressamente criado com permissões 600 e ter como dono o usuário adm e grupo adm. O comando turnacct permite inicializar e finalizar o processo de contabilidade. Para maiores detalhes de como configurar seu sistema, por favor remeta-se aos manuais do AIX.
Os arquivos de contabilidade (pacct/acct) são lidos através do comando lastcomm. A título de exemplo, é apresentada a saída da execução deste comando em um ambiente Freebsd.

$ lastcomm nina

lastcomm nina
more - nina ttyp1 0.17 us Mon Feb 15 15:03
ls - nina ttyp1 0.00 us Mon Feb 15 15:03
uname - nina ttyp1 0.00 us Mon Feb 15 15:03
grep - nina ttyp1 0.03 us Mon Feb 15 15:00
ps - nina ttyp1 0.02 us Mon Feb 15 15:02
pwd - nina ttyp1 0.00 us Mon Feb 15 15:02

Cabe ressaltar que alguns dos arquivos de logs mencionados (tais como o wtmp/wtmpx, messages, etc) tendem a crescer muito rapidamente, fazendo imperativo o uso de algum mecanismo de circulação de logs.

Syslog: o sistema de logs Unix

Sistema de registro de mensagens de logs incorporado em todas as versões modernas de UNIX.
O syslog implementa um mecanismo onde cada mensagem de log está associada a uma facilidade e a uma prioridade. A primeira especifica o programa ou aplicação que gera tal mensagem, enquanto que a segunda indica a prioridade com a qual a mesma deve ser atendida.
Ao ser inicializado o daemon syslogd, ele lê seu arquivo de configuração (geralmente, o /etc/syslog.conf), a fim de determinar o tipo de eventos que o syslog deverá registrar e o lugar onde estes eventos deverão ser registrados.
O arquivo syslog.conf é composto por entradas que seguem o formato abaixo (vale lembrar que os campos devem, necessariamente, estar separados por caracteres de tabulação - TABs):

facilidade.prioridade destino

De acordo com o tipo e a prioridade da mensagem recebida, o daemon syslogd executará a ação indicada no campo destino: armazenando tal mensagem em um arquivo específico, enviando alertas a um determinado usuário (ou ao console), ou, ainda, enviando a mensagem a um outro servidor de logs remoto (conhecido como loghost ).
Não é intenção deste artigo aprofundar-se na variedade de "prioridades" e "facilidades" suportadas pelo syslog e, de modo geral, na configuração do arquivo syslog.conf, mesmo porque existem nuances entre as diversas implementações UNIX. Cabe ao leitor consultar as páginas do manual que tratam deste arquivo para obter maiores detalhes.
Para fins de ilustração, é apresentado o conteúdo de um arquivo de configuração típico:

# Exemplo de um arquivo de configuração do syslog
# em uma máquina com Solaris.
#
# /etc/syslog.conf
#
*.err;kern.notice;auth.notice /dev/console
*.alert; user.none root
*.emerg; user.none *
*.debug @loghost

A primeira linha indica que todas as mensagens de erros [prioridade err] (ou de prioridade maior) serão enviadas ao console do sistema, junto com as mensagens geradas pelo kernel [kern] e pelo processo de autorização/segurança [auth] que tenham prioridade notice [notice] (ou de prioridade maior).
A segunda entrada do arquivo indica que todas as mensagens de alerta [alert] (ou de prioridade maior), exceto as geradas pelo usuário [user], serão enviadas ao terminal do usuário root.
Adicionalmente, qualquer mensagem de emergência [emerg] será difundida a todos os usuários que estiverem conectados nesse momento.
Por último, qualquer outra mensagem será enviada ao loghost (máquina que centraliza os logs).

Arquivos de logs gerados por alguns serviços de rede

Nesta seção, pretende-se apresentar alguns dos arquivos de logs específicos que são utilizados por serviços de rede, atendo-se em explicar brevemente como habilitar os logs nestes serviços. A título de ilustração, serão considerados apenas os serviços mais "expostos" (e portanto, mais vulneráveis) na Internet. Em particular, para este artigo, se trabalhará com os seguintes servidores: Apache (HTTP), Sendmail (MAIL), Bind8 (DNS) e WU-FTP (FTP).
SERVIÇO DE TRANSFER^ENCIA DE ARQUIVOS (FTP) (20/21)
Em particular, o servidor WU-FTP permite registrar informações bastante úteis. Dentre elas, destacam-se por auxiliar na tarefa de detecção de intrusão, os seguintes tipos de logs:

logs dos arquivos transferidos de/para o sistema (informações armazenadas no arquivo xferlog);
logs dos comandos FTP executados durante uma sessão;
logs dos usuários que estiveram ou estão atualmente acessando o servidor FTP.

O artigo "Configurando seu Servidor FTP de Maneira Segura" descreve detalhadamente como configurar o servidor WU-FTP para obter estes arquivos de logs. A sua leitura é altamente recomendada.
O exemplo a seguir é representa uma entrada registrada no arquivo xferlog após a transferência de um arquivo. Nela um usuário anônimo, a partir da máquina maq.dominio.com.br, faz o download do arquivo security_tools, disponibilizado no servidor FTP público.

Fri May 8 21:45:30 1998 1 maq.dominio.com.br 12422
/pub/info/papers/cert/security_tools b _ o a mozilla@ ftp 0 *

Se as mensagens de logs, geradas via syslog, são enviadas a um arquivo específico, tal como o ftplog, recomenda-se que este tenha como dono o usuário root e as suas permissões de acesso configuradas para 600. O mesmo vale para o arquivo xferlog.
SERVIÇO DE CORREIO ELETRÔNICO (MAIL)
O mecanismo utilizado pelo Sendmail para gerar as suas mensagens de logs é o syslog , descrito anteriormente. A facilidade padrão destas mensagens é mail (variável LOG_MAIL). A prioridade é definida pela opção LogLevel, a qual, a partir das versões 8.9.X, vem configurada para 9, o que equivale à prioridade info. Considera-se esta configuração default, no mínimo, adequada.
A seguir, são mostradas as duas entradas de logs geradas pelo Sendmail ao ser enviada uma mensagem electrônica pelo usuário nina@cais.rnp.br para o usuário billgates@microsoft.com. Estes logs foram registrados no maillog, arquivo geralmente usado pelo syslog para armazenar mensagens geradas pelo Sendmail.

Apr 18 15:50:14 mx-cais sendmail[25838]: PAA25838: from=< nina@cais.rnp.br >,
size=1127, class=0, pri=61127, nrcpts=2, msgid=
< Pine.SOL.3.96.990518154928.25280D-100000@cais1 >, proto=SMTP,
relay=nina@mx.cais.rnp.br [200.144.121.33]

Apr 18 15:50:59 mx-cais sendmail[25840]: PAA25838: to=< billgates@microsoft.com >,
ctladdr=< nina@cais.rnp.br > (101/100), delay=00:00:45, xdelay=00:00:44,
mailer=esmtp, relay=mx.microsoft.com. [131.107.3.125], stat=Sent (PAA18294
Message accepted for delivery)

Se as mensagens de logs forem enviadas para um arquivo específico, tal como o maillog, recomenda-se que este arquivo tenha como dono o usuário root e as suas permissões de acesso configuradas para 600.
SERVIÇO DE RESOLUÇÃO DE NOMES (DNS) (53)
Um dos aspectos que recebeu mais atenção na versão Bind8 foi, justamente, o relacionado ao mecanismo de logging. Esta versão implementa um sistema totalmente categorizado.
Através da diretiva logging é possível configurar uma série de opções no servidor de nomes. É ela que especifica o que o servidor DNS deverá registrar e onde tais mensagens de logs deverão ser enviadas.
Não pretende-se entrar em detalhes de como configurar esta diretiva, cabe ao leitor consultar a documentação que acompanha a distribuição do pacote Bind8, ou a documentação on line na seguinte URL: http://www.isc.org/bind8.2/logging.html.
No entanto, para fins de ilustração, é apresentado a seguir um exemplo de configuração desta diretiva:

//
// Arquivo /etc/named.conf
//
// ...
//
// [início do trecho]
//
logging {
channel default_log {
file "/var/log/bindlog" size 5M versions 4;
severity info;
print-time yes;
print-category yes;
print-severity yes;
};
category lame-servers { null; };
category cname { null; };
category default { default_log; };
};
// [fim do trecho]

As linhas acima especificam que, exceto as mensagens da categoria "lame-servers" e "cname" que serão descartadas, todas as outras mensagens serão enviadas ao arquivo /var/log/bindlog. As mensagens de logs deverão incluir o horário, categoria e severidade respectivos. A seguir, é apresentado um exemplo dos logs gerados pela configuração acima:

16-Apr-1999 07:13:57.425 response-checks: info: bad referral (arpa !<<br/> 52.136.200.in-addr.arpa)
16-Apr-1999 08:03:48.463 maintenance: info: Cleaned cache of 5 RRs
16-Apr-1999 08:03:48.468 statistics: info: USAGE 924260628 923951026
CPU=6.35801u/2.85031s

Se as mensagens de logs geradas via syslog forem enviadas para um arquivo específico, tal como o bindlog, recomenda-se que este arquivo tenha como dono o usuário root e as suas permissões de acesso configuradas para 600.
SERVIÇO DE WEB (HTTP) (80)
O servidor Apache provê dois arquivos de logs: access_log e error_log.
Através do arquivo access_log, é possível determinar os hosts e usuários que acessaram o servidor Web, os arquivos requisitados, os horários em que tais requisições foram feitas e, ainda, o estado de tais requisições.
O arquivo error_log contém informação respeito dos erros encontrados e o estado do servidor Web (inicialização e finalização).
Ambos podem ser habilitados e desabilitados a partir de diretivas específicas no arquivo de configuração httpd.conf.
O servidor httpd permite definir onde serão armazenados estes arquivos. Geralmente, eles ficam no diretório logs. Recomenda-se, por um lado, que este diretório tenha como dono e grupo o root, e suas permissões de acesso configuradas para 755; por outro lado, que os arquivos contidos nele tenham igualmente o usuário root como dono e as suas permissões de acesso configuradas para 600.
A seguir, um exemplo de uma entrada no arquivo de logs (access_log) do servidor www.cais.rnp.br, onde o documento index.html foi acessado com sucesso a partir da máquina cache.dominio.rnp.br.

cache.dominio.rnp.br - - [02/Dec/1998:16:37:24 -0200] "GET /index.html
HTTP/1.0" 200 4169

Por outro lado, num acesso mal sucedido a um outro documento (index2.html), o arquivo error_log registrou a seguinte entrada:

[Wed Dec 02 16:37:25 1998] access to /dir_raiz_doc/index2.html failed
for cache.dominio.rnp.br, reason: File does not exist

De modo geral, qualquer serviço de rede inicializado pelo super daemon inetd (tais como: popd, imapd, ftpd, telnetd, sshd, etc) podem gerar suas mensagens de logs através da conhecida ferramenta TCP Wrappers, via syslog .
Complementando as seções anteriores, é importante mencionar que existem diversos tipos de logs que auxiliam na tarefa de detecção de intrusão, tais como:

Logs de firewall (logs do IPFW, logs do IP-Filter, logs do IP Chains, logs do Cisco, etc)
Logs de atividade do usuário (.bash_history, .history, sh_history, etc)
Logs gerados por um analisador de tráfego (tcpdump, por exemplo)
Logs gerados por sistemas de detecção de intrusão (nfr, por exemplo)

Considera-se a abordagem destes tipos de logs o suficientemente extensa para justificar a sua não inclusão no presente artigo. No entanto, na seção seguinte, serão mostrados alguns desses logs, a fim de familiarizar o administrador com seu respectivo formato.

O que é relevante?

A maior dificuldade em um processo de detecção de intrusão decorre da imensa quantidade de informação gerada pelos eventos diários de um sistema. Separar os dados relevantes dos comuns é algo que requer tempo, atenção e, até mesmo, experiência.
Portanto, através de diversos exemplos, esta seção visa familiarizar o administrador com padrões de ocorrências nos logs que denotem algum tipo de atividade suspeita. Para tal, foram considerados os arquivos de logs básicos e os arquivos de logs gerados por alguns dos serviços de rede, principalmente aqueles com reconhecidas vulnerabilidades associadas.
ARQUIVOS DE LOGS BÁSICOS DE SISTEMAS UNIX
Arquivo utmp/utmpx
Execute o comando who regularmente e fique atento a eventuais acessos de usuários cuja presença não seja esperada (por exemplo, usuários que supostamente deveriam estar tomando sol em uma praia isolada, sem Internet :-)), acessos que ocorram em horários inesperados ou que se originem de lugares suspeitos.
Arquivo wtmp/wtmpx
Usando o comando last verifique o seguinte:

Acessos de usuários que ocorram em horários não usuais.

usuario1 pts/4 maq.suspeito.com.br Wed Abr 7 03:14 - 06:02 (02:47)
Acessos de usuários que se conectam a partir de lugares inesperados

usuario2 pts/3 maq.dominio.inesperado. Wed Abr 7 12:10 - still logged in
Eventuais reinicializações do sistema

reboot system boot Fri Apr 9 05:36

Arquivo sulog
Procure por entradas que indiquem uso inapropriado do comando su, tais como:

Usuários comuns se tornando inesperadamente usuários privilegiados

SU 03/31 12:52 + pts/6 us_comum-root
Tentativas falhas de execução do comando su

SU 09/02 20:09 - pts/2 usuario2-root
Execução do comando su em horários pouco usuais.

SU 09/02 03:20 + pts/4 usuario1-root

Arquivo messages
Repare em entradas que indiquem:

Paralizações do sistema inesperadas

Aug 16 15:41:27 maq2 unix: halted by usuario1
Eventuais reinicializações do sistema.

Aug 20 02:31:04 maq2 reboot: rebooted by root
Tentativas sem sucesso da execução dos comandos su e login

Oct 10 08:53:30 maq2 login: 4 LOGIN FAILURES ON 0, usuario3
Oct 10 08:53:30 maq2 su: 'su root' failed for usuario3 on /dev/pts/5
Tentativas bem sucedidas da execução do comando su, mas inesperadas.

Set 28 13:28:11 maq2 su: 'su root' succeeded for us_inesperado on /dev/pts/5

Arquivo pacct/acct
Deve-se atentar também para:

Usuários executando comandos suspeitos;
Atividade de rede fora do comum (pode significar o disparo de um múltiplo scan, por exemplo);
Um aumento significativo de uso do sistema de arquivos (se um usuário costuma usar pouco os sistemas de arquivos, e recentemente, tem mostrado um aumento na taxa de uso do sistema, pode significar que teve sua conta invadida).

ARQUIVOS DE LOGS GERADOS POR SERVIÇOS DE REDE
Ataques ao Serviço FTP (portas 20/21)
O seguinte log, registrado pelo arquivo xferlog, mostra que foi feito o download (indicado pela opção "O" de outgoing) do arquivo /etc/passwd a partir da máquina 200.136.100.253. Note que esse arquivo é o arquivo /etc/passwd que se encontra no diretório home do usuário ftp (anônimo), não na raíz do sistema.

Mon Dec 22 11:00:13 1997 1 200.136.100.253 526 /etc/passwd b _ o a
IE40user@ ftp 0 *

As seguintes linhas mostram um hacker "municiando-se" para iniciar (ou completar) mais um ataque. A vítima aparente é a máquina local, a princípio. Repare que no último log, a opção "O" de outgoing (saindo do servidor) denota a inteção do hacker de provavelmente atacar outros sistemas (no caso, a próxima vítima parece ser a máquina 200.144.121.253) a partir do host comprometido.

Sat Jun 6 07:16:06 1998 1 200.136.100.254 2628 /tmp/trojano.c b _ i r
suspeito ftp 0 *
Sat Jun 6 22:34:17 1998 4 200.136.100.254 14433 /tmp/sniffer a _ i r
suspeito ftp 0 *
Sat Jun 6 22:37:13 1998 3 200.144.121.253 5188 /tmp/sniffer.c a _ o r
suspeito ftp 0 *

Parte de uma sessão FTP é é mostrada a seguir. Nela, observa-se que um usuário da máquina maq-suspeito.hacker.org.br tentou executar comandos não autorizados.

Apr 17 10:07:56 maq2 ftpd[11075]: connection from maq-suspeito.hacker.org.br
(200.236.100.254)
Apr 17 10:07:56 maq2 ftpd[11075]: <--- 220
Apr 17 10:07:56 maq2 ftpd[11075]: maq2.cais.rnp.br FTP server (Version 6.00)
ready.
Apr 17 10:07:56 maq2 ftpd[11075]: command: USER anonymous
Apr 17 10:07:56 maq2 ftpd[11075]: <--- 331
Apr 17 10:07:56 maq2 ftpd[11075]: Guest login ok, send your email address as
password.
Apr 17 10:07:56 maq2 ftpd[11075]: command: PASS ddd@
Apr 17 10:07:57 maq2 ftpd[11075]: <--- 230
Apr 17 10:07:57 maq2 ftpd[11075]: Guest login ok, access restrictions apply.
Apr 17 10:07:57 maq2 ftpd[11075]: ANONYMOUS FTP LOGIN FROM
suspeito.hacker.org.br, ddd@
Apr 17 10:07:57 maq2 ftpd[11075]: command: MKD .a
Apr 17 10:07:57 maq2 ftpd[11075]: mkdir .a
Apr 17 10:07:57 maq2 ftpd[11075]: <--- 550
Apr 17 10:07:57 maq2 ftpd[11075]: .a: Permission denied.
Apr 17 10:07:57 maq2 ftpd[11075]: command: SITE exec /bin/sh -c /bin/id
Apr 17 10:07:57 maq2 ftpd[11075]: <--- 500
Apr 17 10:07:57 maq2 ftpd[11075]: 'SITE EXEC /bin/sh -c /bin/id': command not
understood.
[...]

O seguinte cenário indica uma tentativa de denial-of-service em um servidor FTP:

Jan 17 03:00:57 maq-vitima ftpd[15453]: connect from
ppp144.hacker.org.br
Jan 17 03:00:57 maq-vitima ftpd[1636]: connect from ppp144.hacker.org.br
Jan 17 03:00:58 maq-vitima ftpd[26403]: connect from ppp144.hacker.org.br
Jan 17 03:00:58 maq-vitima ftpd[29453]: connect from ppp144.hacker.org.br
Jan 17 03:00:58 maq-vitima ftpd[32230]: connect from ppp144.hacker.org.br
[...sequência de inúmeras tentativas de acesso...]

Ataques ao Serviço SSH (porta 22)
O seguinte log não caracteriza exatamente um ataque, mas uma tentativa de acesso (probe) do usuário root à máquina maq-vitima.coitado.br, a partir da máquina de IP 200.136.100.244:

Apr 30 18:34:46 maq-vitima.coitado.br sshd[1989]: refused connect
from root@200.136.100.244

Ataques ao Serviço TELNET (porta 23)
O log apresentado a seguir registrou uma conexão inesperada de uma máquina remota com sucesso. No exemplo, esta entrada se torna suspeita desde o momento que o IP corresponde a uma máquina localizada na Alemanha. Vale a pena conferir se é provável um acesso vindo de lá (um professor participando de um congreso, por exemplo).

Jan 10 21:06:20 maq-vitima telnetd[2495]: connect from 134.100.13.129

Por outro lado, este outro log denota uma tentativa de conexão sem sucesso.

Jul 28 12:36:01 maq-vitima in.telnetd[9878]: refused connect from
200.136.100.254.

Ataques ao Serviço SMTP (porta 25)
O seguinte log, gerado por um sistema Linux, denota que possivelmente a máquina; com IP 200.144.121.236 esteja sofrendo um ataque do tipo syn flood na porta 25, caracterizando uma tentativa de denial-of-service na máquina vítima

Sep 29 18:39:49 vitima kernel: Warning: possible SYN flood from
200.136.100.253 on 200.144.121.236:25. Sending cookies.

Não deve surprender que os nomes de usuários ainda sejam usados para ganhar acesso a um determinado sistema, isto pelo simples fato que, incrivelmente, muitos deles usam como senha seu próprio login. Pois bem, o comando vrfy fornece ao atacante um meio de descobrir tais nomes.

Jan 22 05:23:01 mx-cais sendmail[11128]: ppp44.abuser.com.br
[200.239.45.63]: vrfy felipe
Jan 22 05:23:03 mx-cais sendmail[11130]: ppp63.abuser.com.br
[200.239.45.63]: vrfy mocoto

O seguinte log mostra uma tentativa de relay (ato de retransmitir uma mensagem recebida de uma estação para outra). No caso, um usuário forjou uma mensagem fazendo-se passar por batman@yahoo.com, usando a máquina mx_relay.dominio.com.br para enviar tal mensagem.

Mar 10 21:21:34 maq_ataque sendmail[18509]: VAA18509:
from=batman@yahoo.com, size=20, class=0, pri=30020, nrcpts=1,
msgid=<199903110021.VAA18509@dominio.com.br>, proto=SMTP,
relay=mx_relay.dominio.com.br [200.144.121.71]

O log abaixo mostra uma tentativa de relay sem sucesso:

Mar 10 21:15:22 maq_ataque sendmail[14727]: VAA14727: ruleset=check_rcpt,
arg1=nina@cais.rnp.br, relay=user@mx-relay.dominio.org.br [200.144.121.171],
reject=550 user@mx-legitimo.com.br... Relaying denied

Ataques ao Serviço DNS (porta 53)
O primeiro dos logs apresentandos abaixo caracteriza uma tentativa de transferência de zona não autorizada do domínio .br, partindo da máquina cujo IP é 200.136.100.1; o segundo, por sua vez, aponta uma tentativa com sucesso.

Jul 6 05:45:37 ns_vitima named[361]: unapproved AXFR from
[200.136.100.1].11541 for "br" (acl)

May 21 14:08:40 ns_vitima named[3566]: approved AXFR from
[200.136.100.234].1105 for "com.br"

Vale a pena lembrar que, geralmente, tentativas de transferência de zona antecedem as invasões. Pretende-se com isto recolher informações sobre as máquinas pertencentes a um determinado domínio.
Uma tentativa de atualização de zona é mostrada no seguinte log:

29-Dec-1998 22:43:03.860 unapproved update from [200.136.100.244].2946
for com.br

Os logs registrados por uma aplicação comercial indicam uma provável tentativa de ataque ao servidor DNS usando o mecanismo de buffer overflow.

[High] Thu Oct 01 08:17:49 1998: DNS Length Overflow Exploit - from
200.136.100.234
(200.136.100.234) to vitima.com.br (200.144.121.25)

Como os próprios logs indicam, há a possibilidade de um syn flood na porta 53.

Warning: possible SYN flood from 200.211.187.194 on 204.145.251.1:53.
Sending cookies.
validated probe(200.211.187.194:2801, 204.145.251.1:53, -117477482)
validated probe(200.211.187.194:2800, 204.145.251.1:53, -1011513209)
validated probe(200.211.187.194:2802, 204.145.251.1:53, 157911477)

Ataques ao Serviço FINGER (porta 79)
Como mostram os logs abaixo, foram realizadas inúmeras tentativas de acesso ao serviço finger em uma única máquina, isto pode caracterizar um ataque do tipo denial-of-service.

Apr 14 22:47:42 server in.fingerd[19147]: refused connect from 200.236.100.189
Apr 14 22:47:50 server in.fingerd[19155]: refused connect from 200.236.100.189
Apr 14 22:47:57 server in.fingerd[19163]: refused connect from 200.236.100.189
Apr 14 22:48:05 server in.fingerd[19171]: refused connect from 200.236.100.189
Apr 14 22:48:12 server in.fingerd[19179]: refused connect from 200.236.100.189
Apr 14 22:48:19 server in.fingerd[19188]: refused connect from 200.236.100.189
Apr 14 22:58:07 server in.fingerd[19268]: refused connect from 200.236.100.189
Apr 14 22:58:14 server in.fingerd[19277]: refused connect from 200.236.100.189
Apr 14 22:58:22 server in.fingerd[19287]: refused connect from 200.236.100.189

Ataques ao Serviço HTTP (porta 80)
A seguinte linha contida no arquivo access_log mostra alguém conectado à máquina maq.hacker.org.br tentando, sem sucesso, explorar um script CGI com conhecidas vulnerabilidades (no caso, o phf), com o objetivo de obter o arquivo de senhas.

maq.hacker.org.br - - [12/Jan/1998:22:41:50 -0200] "GET
/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd HTTP/1.0" 403 285

Deve-se examinar o arquivo error_log em busca de repetidas tentativas de acesso mal sucedidas, feitas por algum usuário. Algo do tipo:

[Wed Jan 13 16:15:21 1998] access to /dir_restrito failed for
maq_suspeito.org.br, reason: user guest: password mismatch
[Wed Jan 13 16:15:25 1998] access to /dir_restrito failed for
maq_suspeito.org.br, reason: user guest: password mismatch
[Wed Jan 13 16:15:30 1998] access to /dir_restrito failed for
maq_suspeito.org.br, reason: user guest: password mismatch

A mesma tentativa mostrada anteriormente é registrada por este arquivo através da seguinte entrada:

[Mon Jan 12 22:41:50 1998] access to /raiz_servidor_web/cgi-bin/phf
failed for maq.hacker.org.br, reason: Client denied by server
configuration

O arquivo error_log deve também ser "vasculhado" a procura de inesperadas reinicializações do sistema. Por exemplo, a seguinte entrada indica que o servidor Web foi paralizado, pelo horário em que este evento ocorreu, tal entrada se torna suspeita.

[Fri Dec 25 00:44:58 1998] httpd: caught SIGTERM, shutting down

Ataques ao Serviço POP (porta 110)
A seguir, é mostrada uma tentativa de acesso não autorizado partindo do domínio hacker.org.br. A mesma foi barrada pelo wrapper.

Aug 9 03:30:24 maq-vitima in.qpopper[11353]: refused connect
from abuser.hacker.org.br

As linhas abaixo mostram claramente uma tentativa de explorar uma conhecida vulnerabilidade que afeta a determinadas versões do servidor PoP: buffer overflow.

May 13 18:39:17 maq-vitima qpop[5124]: connect from 200.136.100.162
May 13 18:39:17 maq-vitima qpop[5124]: @abuser.hacker.org.br: -ERR Unknown
command: "
^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P
^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P
^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P
^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P
^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P".

Ataques ao Serviço RPCBIND (porta 111) e NFS
Esta mensagem, contida no arquivo messages de uma máquina com Linux, alerta sobre um possível syn flood.

Sep 29 18:36:47 maq-vitima kernel: Warning: possible SYN flood from
200.136.100.253 on 200.14.121.249:111. Sending cookies.

Uma tentativa não autorizada de montar o sistema de arquivo /home é bloqueada pelo sistema:

May 12 20:33:34 maq-vitima mountd[263]: Unauthorized access by NFS client
200.136.100.75.
May 12 20:33:34 maq-vitima mountd[263]: Blocked attempt of 200.136.100.75 to
mount /home

A seguir, é mostrada mais uma tentativa de buffer overflow, usando desta vez o serviço NFS.

Apr 21 17:49:33 nfs-server mountd[5418]: [truncated] NFS mount of
^P^P^P^P^P^P^P^P^P^
P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^
P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^
P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^
P^P^P^P^P^P^P

Os logs registrados mostram claramente o uso de alguma ferramenta automática para realizar uma varredura em uma classe C inteira (200.144.25.0) a procura de vulnerabilidades no serviço RPC:

12:57:57 tcp src 200.136.100.234 dst 200.144.25.2 dst_port sunrpc s_port 2666
12:57:57 tcp src 200.136.100.234 dst 200.144.25.0 dst_port sunrpc s_port 2666
12:57:57 tcp src 200.136.100.234 dst 200.144.25.1 dst_port sunrpc s_port 2666
12:57:57 tcp src 200.136.100.234 dst 200.144.25.3 dst_port sunrpc s_port 2666
12:57:57 tcp src 200.136.100.234 dst 200.144.25.4 dst_port sunrpc s_port 2666
12:57:57 tcp src 200.136.100.234 dst 200.144.25.5 dst_port sunrpc s_port 2666

[... 256 conexões registradas...]

Ataques ao Serviço IMAP (porta 143)
As seguintes linhas, contidas em um arquivo messages, mostram uma tentativa de ataque na porta 143, usando o mecanismo de buffer overflow:

Jul 16 01:32:31 maq_vitima imapd[21308]: connect from 200.136.100.247
Jul 16 01:32:34 maq_vitima imapd[21308]: Login failure
user=^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P
^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P
^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P
^P^P host=maq-ppp.hacker.org.br
Jul 16 01:32:44 maq_vitima imapd[21308]: Connection broken while reading line
user=^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P
^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P
^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P

A seguir, são mostrados os logs do arquivo messages de uma máquina com Linux, após um intruso ter ganho acesso privilegiado usando o mecanismo de buffer overflow.

Jun 21 00:09:24 maq_vitima imapd[32477]: EOF, while reading line
user=^?^?^?^?^?^?^
?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?
^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?
^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?host=maq-intruso.hacker.org.br

Os logs mostrados a seguir, gerados pelo TCPdump, reportam uma varredura stealth nas portas 143 das máquinas do domínio coitado.com.br.

07:45:05.839587 200.136.100.1.31783 > maq-alvo.coitado.com.br.imap: S
1662422521:1662422521(0) win 512
07:45:08.939587 200.136.100.1.31783 > maq-alvo.coitado.com.br.imap: S
1662422521:1662422521(0) win 16060
07:45:14.979587 200.136.100.1.31783 > maq-alvo.coitado.com.br.imap: S
1662422521:1662422521(0) win 16060

Um outro probe de IMAP feito a partir da máquina com número IP 200.136.100.153 é registrado pelas regras do firewall IPFW:

Dec 15 18:04:44 maq_vitima kernel: IP fw-in deny eth0 TCP 200.144.121.233:0
200.136.100.153:143 L=40 S=0x00 I=48388 F=0x0000 T=233

Ataques aos Serviços rexec, rlogin, rshell (portas 512, 513 e 514)
Foram registrados probes a serviços que têm reconhecidas vulnerabilidades associadas.

Jan 17 02:58:02 maq-vitima rexecd[11743]: connect from zmalvado.hackers.org.br
Jan 17 02:58:02 maq-vitima rlogind[32018]: connect from zmalvado.hackers.org.br
Jan 17 02:58:02 maq-vitima rshd[19972]: connect from zmalvado.hackers.org.br

OUTROS TIPOS DE ATAQUE
Multiscan
Os seguintes logs, registrados por um roteador Cisco (com IP 200.144.121.77), mostram claramente uma varredura nas portas privilegiadas da máquina 200.144.121.244 com o intuito de levantar informações sobre possís brechas de acesso. O ataque partiu da máquina 200.136.100.253.

Mar 1 15:29:00 200.144.121.77 112369: 5w6d: %SEC-6-IPACCESSLOGP: list
101 denied tcp 200.136.100.253(1199) -> 200.144.121.244(2), 3 packets
Mar 1 15:30:10 200.144.121.77 112377: 5w6d: %SEC-6-IPACCESSLOGP: list
101 denied tcp 200.136.100.253(1201) -> 200.144.121.244(3), 3 packets
Mar 1 15:30:56 200.144.121.77 112382: 5w6d: %SEC-6-IPACCESSLOGP: list
101 denied tcp 200.136.100.253(1204) -> 200.144.121.244(4), 3 packets
Mar 1 15:30:07 200.144.121.77 112376: 5w6d: %SEC-6-IPACCESSLOGP: list
101 denied tcp 200.136.100.253(1205) -> 200.144.121.244(5), 1 packet
Mar 1 15:31:45 200.144.121.77 112386: 5w6d: %SEC-6-IPACCESSLOGP: list
101 denied tcp 200.136.100.253(1205) -> 200.144.121.244(5), 3 packets

[... 1024 tentativas registradas...]

TCP HalfScan
Um sistema de detecção de intrusão comercial alerta para um possível TCP HalfScan:

[High] Thu Sep 24 20:55:49 1998: TCP HalfScan - from 200.136.100.244
(200.136.100.244) to www.vitima.com.br (200.144.121.234)

Stealth Scan
Os logs registrados por uma aplicação comercial alertam a ocorrência de um probe na porta 143, tentando passar despercebido:

Mar 2 03:27:12 vitima abacus_sentry[297]: attackalert: FIN stealth scan
from host: maq.hacker.org.br/200.136.100.3 to TCP port: 143
Mar 2 03:27:12 vitima abacus_sentry[297]: attackalert: Host 200.136.100.3
has been blocked via wrappers.
Mar 2 03:27:12 vitima abacus_sentry[297]: attackalert: Host 200.136.100.3
has been blocked via dropped route.

Loghost

Os arquivos de logs têm uma vulnerabilidade evidente: pelo mesmo fato deles serem armazenados no próprio sistema, eles podem ser alterados ou até mesmo apagados. Aliás, esta costuma ser uma das primeiras ações realizadas pelos crackers na tentativa de cobrir seus rastros e esconder as suas atividades. Pior ainda, existem ferramentas que automatizam este processo.
Há, contudo, técnicas que tentam minimizar este problema, mas nenhuma delas o erradica definitivamente; a não ser que os logs sejam enviados a uma máquina considerada segura. É neste contexto que surge o conceito de loghost, um servidor de logs cuja função básica é a de centralizar as entradas de logs dos outros computadores na rede.
Visando garantir a integridade deste servidor, a máquina utilizada como tal deverá ser um sistema de computador que não ofereça serviço de rede (exceto o serviço syslog na porta 514/UDP para poder receber as mensagens) e que não possua contas de usuários.
Dentre as vantagens que oferece a implementação de um loghost, pode-se mencionar a facilidade do gerenciamento e monitoramento dos logs, uma vez que múltiplos arquivos provenientes de diversas máquinas estarão centralizadas em um único lugar. Por outro lado, nele podem ser instaladas ferramentas que auxiliem o administrador na árdua tarefa de manipulação e análise dos logs.

Algumas ferramentas úteis

A seguir, são listadas algumas ferramentas que visam auxiliar ao administrador na desgastante tarefa de coleta e análise de logs:
FERRAMENTAS QUE AUXILIAM NA COLETA DE LOGS
TCP Wrappers
Ferramenta que tem como função básica interceptar e filtrar pedidos de conexão aos serviços de rede inicializados pelo inetd, bem como aumentar o nível de detalhamento de logs para tais serviços. As informações registradas são enviadas ao syslogd, portanto a localização do arquivo de logs é determinada pela configuração do arquivo syslog.conf. A última versão desta ferramenta pode ser encontrada em: ftp://ftp.porcupine.org/pub/security
portmap/rpcbind
Implementação do portmapper (conhecido por rpcbind, no caso específico de Solaris) que adiciona funcionalidades, tais como mecanismos de geração de logs e controle de acesso mais apurados. As últimas versões do portmap e do rpcbind podem ser encontradas em: ftp://ftp.porcupine.org/pub/security.
logdaemon
Implementações dos daemons rshd e rlogind que adicionam funcionalidades, tais como mecanismos de geração de logs e controle de acesso mais apurados. A última versão do logdaemon pode ser encontrada em: ftp://ftp.porcupine.org/pub/security
PingLogger
Ferramenta que registra pacotes ICMP. Permite determinar a ocorrência de um ataque ping flood. Pode ser encontrado em: http://ryanspc.com/tools/pinglogger.tar.gz
Smurflog
Programa que registra ataques smurf , incluindo os endereços de broadcasting utilizados. Pode ser encontrado em: http://www.sy.net/security/
FERRAMENTAS DE ANÁLISE ON-LINE
Tratam-se de ferramentas que monitoram, em tempo real, arquivos de log arbitrários (por exemplo, mensagens geradas pelo syslog) e permitem ao administrador realizar ações específicas em resposta a eventos ou padrões de eventos. Estas ações podem incluir: enviar um alerta via e-mail, enviar uma mensagem via pager, obter informações da máquina atacante devolvendo um finger, etc.
Duas das ferramentas mais conhecidas são: o Swatch (Simple WATCHdog) e o Logsurfer. O primeiro pode ser encontrado em: ftp://ftp.stanford.edu/general/security-tools/swatch e o segundo em: ftp://ftp.cert.dfn.de/pub/tools/audit/logsurfer
FERRAMENTAS DE VERIFICAÇÃO DE CONSISTÊNCIA DE LOGS
chklastlog
Verifica se alguma entrada do arquivo lastlog foi apagada. A última versão deste arquivo poderá ser encontrada em: ftp://ftp.cert.dfn.de/pub/tools/audit/chklastlog.
chkwtmp
Verifica se houve alguma alteração suspeita no arquivo wtmp. Sua última versão pode ser encontrada em: ftp://ftp.cert.dfn.de/pub/tools/audit/chkwtmp
FERRAMENTAS DE CIRCULAÇÃO DE LOGS
Um dos maiores problemas dos arquivos de logs é que eles tendem a crescer muito e, conseqüentemente, a consumir espaço em disco. Dependendo da política de logs adotada (por exemplo, registrar tudo!), este crescimento pode provocar a lotação do disco, gerando não somente um problema de administração de sistemas, como também de segurança, pois novos eventos deixarão de ser registrados.
As ferramentas listadas a seguir visam contornar este problema:
Rotate Logs
http://www.ginini.com.au/tools/rotatelogs
Newsyslog
Script bastante simples que auxilia na tarefa de rotação de logs.
OUTRAS VERSÕES DE SYSLOGD
New syslogd (nsyslogd)
Versão aprimorada do syslogd, desenvolvida por Darren Reed, também autor do IP-Filter. Dentre suas principais características, o nsyslogd implementa conexões TCP suportando SSL e arquivos de hash logs para integridade de dados. A última versão pode ser encontrada em: http://coombs.anu.edu.au/~avalon/nsyslog.html
Secure Syslog (ssyslogd)
Ferramenta de auditoria de logs, desenvolvida pela CORE-SDI com o objetivo de substituir o daemon syslog. O Secure Syslog implementa um protocolo de criptografia chamado PEO-1 que permite a auditoria remota de logs em um sistema. É possível realizar esta auditoria mesmo quando um intruso tenha conseguido privilégio de super usuário em um sistema, tendo em vista que o protocolo garante que os logs não são modificados antes nem durante a intrusão. A versão mais atualizada desta ferramenta pode ser encontrada em : http://www.core-sdi.com/Core-SDI/english/slogging/ssyslog.html
^

Recomendações gerais

Crie uma política de logs séria, identificando: os tipos de informação que podem ser registrados, os mecanismos para tal registro, onde essa tarefa será realizada e onde os arquivos de logs serão armazenados.
Determine se os mecanismos providos pelo seu sistema, e na rede de maneira geral, registram as informações necessárias.
Habilite os mecanismos de logs. Recomenda-se em uma primeira instância registrar o máximo de logs possíveis, e posteriormente, determinar que dados são mais significativos dentro de um processo de detecção de intrusão.
Monitore os arquivos de logs regularmente em busca de atividades suspeitas.
Investigue qualquer anomalia encontrada, isto é, verifique se ela pode ser atribuída a algum tipo de atividade autorizada, por exemplo: o usuário realmente estava em Toronto no dia anterior e conectou-se no sistema? Ou houve realmente uma queda de energia que fez com que o sistema seja reinicializado?
Caso seja confirmada qualquer evidência (ou tentativa) de intrusão, contacte seu respectivo grupo de segurança e reporte o incidente ou, se este grupo não existir, contate diretamente os responsáveis técnicos das redes comprometidas. Inclua na mensagem os logs e o seu timezone.
Recomenda-se criar ou fazer uso de scripts que facilitem a tarefa de análise diária de logs ou lançar mão de um analisador de logs (log analyzer).
Ao examinar sinais de intrusão, lembre-se que a informação de uma fonte pode não parecer suspeita por si mesma. Inconsistências entre diversas fontes podem ser, às vezes, a melhor indicação de atividade suspeita ou intrusões.
Faça backup dos seus logs periodicamente.
Circule seus logs em intervalos definidos e regulares.
Sincronize todas as suas máquinas e dispositivos de rede com servidores de tempo (servidores NTP) de forma a unificar o timestamps dos logs.
Recomenda-se, fortemente, a implementação de um sistema de logs centralizado (loghost).
Acompanhe regularmente alertas e boletins de segurança emitidos por fontes confiáveis. Isto aumentará seu conhecimento sobre os mecanismos de ataque mais recentes e fará com que você se aperfeiçoe na procura de atividade suspeita.
O uso de ferramentas que automatizem/auxiliem no trabalho de coleta, análise e monitoramento de logs é altamente recomendado.
Ainda no escopo de automatização de tarefas, considere a possibilidade de usar utilitários ({r|e}grep, sed, etc) e linguagens de scripts (perl, awk, etc) de forma que auxiliem:
- Na procura de padrões de ataque;
- No isolamento de logs relevantes;
- Na tomada de ações (tal como: envio de alertas ao administrador via e-mail ou via pager; acionamento de uma contramedida como backfinger; ou interrupção de algum serviço);
- Etc.
Recomenda-se, fortemente, o uso de wrappers que proverão mecanismos de logs adicionais.

Considerações finais

Com o crescente número de vulnerabilidades e formas de ataques descobertos, torna-se imperativo o uso de ferramentas para tentar "equilibrar a luta" entre administradores e usuários inescrupulosos.
Neste contexto, os logs, com certeza, desempenham um papel imprescindível no processo de detecção de intrusão. A auditoria e avaliação destes devem se tornar rotineiras e uma constante na vida dos administradores a fim de evitar surpresas desagradáveis.
Este artigo não intencionou esgotar as possibilidades do assunto, mas sim oferecer uma visão geral da sua relevância.