No Linux um dos primeiros logs que você deve analisar em caso de suspeita de invasão é o auth.log. Nele por padrão são registrados as conexões SSH, atividades do cron e do comando su. Em caso de falha ao tentar logar via SSH será registrado no auth. Veja abaixo um exemplo dos registros do auth:
Dec 30 09:49:58 debian su[2441]: Successful su for root by osvaldo
Dec 30 09:49:58 debian su[2441]: + pts/0 osvaldo:root
Dec 30 09:49:58 debian su[2441]: pam_unix(su:session): session opened for user root by osvaldo(uid=1000)
Dec 30 10:00:01 debian CRON[2564]: pam_unix(cron:session): session closed for user root
Dec 30 10:00:17 debian sshd[2569]: Invalid user naoexiste from 192.168.56.101
Dec 30 10:00:17 debian sshd[2569]: Failed none for invalid user naoexiste from 192.168.56.101 port 61959 ssh2
Dec 30 10:00:21 debian sshd[2569]: pam_unix(sshd:auth): check pass; user unknown
Dec 30 10:00:50 debian sshd[2569]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.56.101
Dec 30 10:00:50 debian sshd[2569]: PAM service(sshd) ignoring max retries; 6 > 3
Dec 30 10:01:01 debian CRON[2572]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 30 10:01:01 debian CRON[2572]: pam_unix(cron:session): session closed for user root
Veja que tem algumas entradas de atividades do serviço SSHD, onde várias tentativas de acesso foi realizado porém sem sucesso devido a problemas de login. Podemos ver também atividades do comando “su” e do cron.
O problema é que ele não vai mostrar exatamente o que o usuário fez depois que realizou o login com sucesso. Nas primeiras linhas temos o usuário “osvaldo” utilizando o “su” para se tornar root no sistema e obteve sucesso em fazer isso, porém todo comando realizado pelo usuário Osvaldo que esta na máquina como root não será registrada, imagine que você tenha dois usuários normais o Osvaldo e o Matthew que usaram o comando su para se tornar root no sistema, como você vai saber quais comandos eles usaram como root? E como você vai fazer auditoria no seu sistema se não tem log dos comandos que foram executados?
A chave deste post é implementar um sistema que registre tudo o que o usuário faça no seus sistema, logar todos os comandos executados com o comando sudo, até mesmo o sudo -s e registrar as alterações em arquivos específicos.
Logando todos os comandos
Vamos primeiro implementar o que chamamos de Process Accounting, que é definido como o método de registrar e sumarizar todos os comandos executados no Linux, com isso você pode monitorar os comandos executados pelo usuário, o uso de CPU e muito mais.
Lembrando que esse teste foi realizado no Debian5, porém a idéia é a mesma para qualquer distro.
O pacote no debian que deve ser instalado é o acct. O repositório que vem configurado por padrão não tem o pacote que precisamos, por isso vamos adicionar alguns repositórios, edite o seu /etc/apt/sources.list:
deb http://ftp.br.debian.org/debian/ lenny main contrib
deb-src http://ftp.br.debian.org/debian/ lenny main contrib
deb http://security.debian.org/ lenny/updates main contrib
deb-src http://security.debian.org/ lenny/updates main contrib
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb-src http://volatile.debian.org/debian-volatile lenny/volatile main
deb http://ftp.br.debian.org/debian/ lenny-proposed-updates contrib main
deb-src http://ftp.br.debian.org/debian/ lenny-proposed-updates contrib main
deb http://ftp.br.debian.org/debian-multimedia/ lenny main
deb-src http://ftp.br.debian.org/debian/ lenny main contrib
deb http://security.debian.org/ lenny/updates main contrib
deb-src http://security.debian.org/ lenny/updates main contrib
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb-src http://volatile.debian.org/debian-volatile lenny/volatile main
deb http://ftp.br.debian.org/debian/ lenny-proposed-updates contrib main
deb-src http://ftp.br.debian.org/debian/ lenny-proposed-updates contrib main
deb http://ftp.br.debian.org/debian-multimedia/ lenny main
O grande problema desta ferramenta é que ela mostra o comando que foi usado, porém não mostra a sintaxe toda do comando. Digamos que o usuário osvaldo realizou o comando abaixo:
$cat /etc/passwd
Veja o que foi registrado pelo acct:
cat osvaldo stdin 0.02 secs Tue Jan 4 11:02
Veja que o log mostra que o comando “cat” foi usado, porém não mostra que foi realizado um cat no arquivo /etc/passwd, ai esta o problema. É interessante que tenhamos o registro de exatamente tudo que o usuário fez.
Podemos ver que com o acct não resolveu nosso problema, mas é uma boa ter ele instalado podendo junto com outros sistemas de log confirmar a auditoria que esta sendo feita no sistema. Brinque um pouco com o acct, nele vem acompanha as seguintes ferramentas:
| ac | Mostra estatística sobre o tempo de conexão do usuário |
| accton | Habilita ou desabilita o acct |
| lastcomm | Lista os comando executados (foi esse comando que usei para mostrar a saída acima) |
| sa | Realiza um sumário geral |
Para resolver este problema veja abaixo a instalação do Snoopy.
Logando o que é feito depois de sudo -s
Já que não resolvemos com o acct, vamos usar o Snoopy que loga todo comando executado no sistema até mesmo os comandos que são executados depois de usar o sudo -s, que por padrão do sistema iria mostrar o ID do root e não do usuário que usou o sudo -s.
Para instalar execute:
#aptitude install snoopy
Por padrão o snoopy vai logar no arquivo /var/log/auth.log.
Vamos realizar alguns testes. Primeiro vamos executar algum comando com o usuário osvaldo:
$cat /etc/passwd
Veja o que apareceu no log:
Jan 4 16:47:49 debian snoopy[7940]: [osvaldo, uid:1000 sid:7909]: cat /etc/passwd
Agora vamos realizar a mesma tarefa porém usando o sudo:
$sudo cat /etc/shadow
Veja o log:
Jan 4 16:49:32 debian snoopy[7951]: [osvaldo, uid:1000 sid:7909]: sudo cat /etc/shadow
Jan 4 16:49:35 debian sudo: osvaldo : TTY=pts/0 ; PWD=/home/osvaldo ; USER=root ; COMMAND=/bin/cat /etc/shadow
Jan 4 16:49:35 debian snoopy[7951]: [osvaldo, uid:0 sid:7909]: cat /etc/shadow
Neste terceiro teste vamos primeiro executar o “sudo -s" para sermos root no sistema e depois vamos ler o arquivo /etc/shadow novamente. O cenário é o seguinte, temos um sistema com vários administradores com acesso total ao sistema, podendo mudar tudo sem restrições. Neste caso precisamos ter o controle de quem alterou, apagou, modificou etc. Com isso podemos depurar com mais precisão possíveis problemas e até mesmo registrar atividades de alguém não autorizado que tenha conseguido logar no sistema.
$sudo -s
#cat cat /etc/shadow
Vamos analisar o log:
Jan 4 16:53:53 debian snoopy[7976]: [osvaldo, uid:1000 sid:7909]: sudo -s
Jan 4 16:54:02 debian snoopy[8002]: [osvaldo, uid:0 sid:7909]: cat /etc/shadow
Na primeira linha o log esta mostrando que o usuário osvaldo com a UID=1000 executou o comando “sudo -s", e foi gerado um ID (Sid=7909) para essa sessão. Na segunda linha você tem o usuário osvaldo utilizando o uid=0 (root) pata executar o comando cat, perceba que a sid é a mesma.
Registrar alterações em arquivos
No Linux temos duas ferramentas para monitorar as alterações em arquivo: inotify e auditd. Para este post vou usar o auditd que tem algumas vantagens sobre o auditd, como por exemplo, ser executado como um daemon.
Durante o boot do sistema o Auditd ler as regras que estão no arquivo /etc/audit.rules e o arquivo de configuração é o /etc/audit/auditd.conf. O auditd vem acompanhado de vários comandos, os 3 principais são:
- auditctl: controla o sistema de auditoria que é feito pelo kernel, com ele você pode deletar, adicionar, ver status das regras etc.
- aureport: para gerar um relatório resumido
- ausearch: para realizar consultas
Neste teste vamos configurar o auditd para verificar quando alguém tentar ler o arquivo /etc/passwd. Para isso execute o comano abaixo:
# auditctl -w /etc/passwd -k passw-read -p r
resumo das opções:
-w: o arquivo que deve ser auditorado
-k: uma chave para identificar este evento no log
-p: a permissão que será observada, neste caso r (read)
Vamos ver se a regra foi criada:
#auditctl -l
LIST_RULES: exit,always watch=/etc/passwd perm=r key=passw-read
Agora com um usuário normal faça um cat no arquivo /etc/passwd. Para ver o log utilize a ferramenta auseach, como mostra abaixo:
# ausearch -k passw-read
ou
#ausearch -i -f /etc/passwd
Como se trata do arquivo /etc/passwd, que é muito utilizado pelo sistema então deverá ter vários registros no log. Para facilitar vou buscar pelo registro com uid=1000 que é referente ao meu usuário do sistema osvaldo.
Veja a saída abaixo:
time->Tue Jan 4 12:50:25 2011
type=PATH msg=audit(1294156225.990:11): item=0 name="/etc/passwd" inode=41516 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1294156225.990:11): cwd="/home/osvaldo"
type=SYSCALL msg=audit(1294156225.990:11): arch=40000003 syscall=5 success=yes exit=3 a0=bff9cacd a1=8000 a2=0 a3=8000 items=1 ppid=4908 pid=4932 auid=429496
7295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=4294967295 comm="cat" exe="/bin/cat" key="passw-read"
O que nos interessa esta marcado. Temos a data, o comando, o arquivo, tudo que precisamos registrado. Podemos realizar a mesma tarefa para monitorar um diretório inteiro, apenas indique o diretório com a opção -w, por exemplo, “-w /tmp”.
Exemplos Tirados da Internet e do man da ferramenta:
Faça a sua busca usando como base a data:
#ausearch -ts today -k passw-read
#ausearch -ts 3/12/07 -k passw-read
#ausearch -ts 3/12/07 -k passw-read
Veja todas as chamadas de sistema feita por um programa:
#auditctl -a entry,always -S all -F pid=1005
Veja os arquivos abertos por um usuário:
#auditctl -a exit,always -S open -F auid=510
Veja as chamadas de sistema sem sucesso:
#auditctl -a exit,always -S open -F success!=0
Veja quem removeu o arquivo /etc/passwd usando o comando rm:
#ausearch -k passw-read -x rm
Adicione uma regra para fazer auditoria para saídas de chamadas de sistema, neste caso o "mount":
# auditctl -a exit,never -S mount
Vamos refinar um pouco nosso Auditd.
Com o auditd podemos rastrear tudo o que o usuário faz desde o seu login até o momento que ele realizar o logout. Podemos modificar o módulo PAM de alguns serviços para permitir que o auditd monitore os usuários desses serviços, para isso edite os arquivos em /etc/pam.d/. No nosso teste vamos editar o arquivo /etc/pam.d/sshd, adicione as linhas abaixo antes da linha “@include common-session” :
session required pam_loginuid.so
session include common-session
Você pode habilitar o auditd na auditoria das chamadas ao sistema (system calls) para apenas uma sessão ou permanente. Para uma sessão apenas você usa os comandos:
auditctl -e 1 (habilita)
auditctl -e 0 (desabilita)
Quando o sistema fizer o boot você perderá essa configuração, para resolver isso temos que fazer as configurações permanentes, para fazer isso edite o arquivo /etc/audit/audit.rules e adicione a linha abaixo:
-e 1
O auditd é uma poderosa ferramenta, que deve ser usada com bastante cuidado. Por isso vai essa dica, antes de criar suas regras escolha com cuidado o que você realmente precisa auditar, quanto maior o número de regras maior será a carga do sistema.
Exemplos de como criar regras no arquivo /etc/audit/audit.rules:
# exemplos de auditoria em arquivos e diretórios
-w /etc/bind/ -k dir-bind
-w /etc/audit/auditd.conf -p rxwa -k auditd-conf-file
-w /etc/audit/audit.rules -p rxwa -k auditd-rules-file
-w /etc/default/ -k dir-default
-w /etc/passwd -p rwxa -k passwd-file
# exemplos de auditoria system calls
-a entry,always -S umask
O auditd vem com um programa similar que o strace, é o autrace. Brinque um pouco com ele, leia o man. O autrace é ótimo para depurar possíveis problemas com comandos e serviços. Para incentivar vou mostrar um pequeno exemplo, onde irei executar o comando ls e ver quais são as bibliotecas que ele usa:
#autrace /bin/ls /tmp
Como saída deste comando ele vai mostrar o comando que você deve fazer para ver o rastro do comando acima, neste caso foi o comando abaixo:
#ausearch -i -p 3311
Vimos que com essas ferramentas podemos aumentar a auditoria do nosso sistema, permitindo depurar com maior precisão possíveis problemas.
by Osvaldo H Peixoto
