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):
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.
