Segurança

Controles e
Auditoria
Versão 1.0 - 2012
Técnicas e Ferramentas para gerar controles e
tornar auditável um Sistemas Linux

Prof. Msc. Sandro Melo

sandro@4nix.com.br
Conceitos Iniciais

●
Introdução
– Definição
– Importância
●
Controles para auditoria de:
– Trilha de comandos
– Políticas de Controle de Acesso (SO e Rede)
●
Sistema Operacional GNU/Linux
– Serviços;
– Kernel;
– Auditoria;
– Rastreabilidade/evidência;
– Manutenção dos controles;
 Hardening - Importância

●
Adequação as Normas
– ISO 17799, ISO 27002, PCI BSS
●
Guia de referência para boas práticas dos processos e
gestão da Segurança da Informação Corporativa;
●
Controle de Acesso
– Lógico e Físico
●
Políticas
●
Processos (gestão da continuidade de negócio)
●
É um processo da fase do Gerenciamento de Riscos
– Avaliação de todos os ativos
 Hardening

A instalação de qualquer sistema Computacional deverá

conter em seus planejamento métodos e ferramentas para
controle e auditoria, seja qual for a finalidade do servidor.

Administradores de sistema tem por obrigação melhorar a

segurança ativando controles nativos ou implementando-os.

O Linux nos possibilita implementar vários “Controles

Técnicos”.
 Onde fazer Hardening

HARDENING USERLAND
Controles de Autenticação,
Controles de Serviço de Redes,
Logs, Auditoria

HARDENING KERNEL SPACE

(Utiliznado recursos como
GrSecurit/PAX, Selinux, LIDS)
 Nível de Segurança Desejado 1/2

Implemente diretivas de segurança em seus servidores

seguindo as orientações do TSEC (Livro Laranja)
desenvolvido pelo DOD USA. Buscando atender o nível C2
de segurança pelo menos no que diz respeito a
recomendações de Trilha de Auditoria.

Lembrando que os níveis de segurança variam do nível mais

baixo D a mais alto A.

Todos esses conceitos evoluiram e hoje a base para

referência de o “Common Critéria"
 Níveis de Segurança

A
B3
B2 RSBAC
Modelo RBAC
B1 Pax/GRSecurity

C2

Nativo
C1 Modelo DAC
no Linux

D SEM Modelo MSDOS

 Controles para ROOT

Criar uma conta com exclusivo acesso a “su”para;

Registrar atividades do uso do “su”
Impossibilitar o Login do “root” localmente;
Impossibilitar o Login do “root” remotamente;
 Controles p/ Serviços

Customizar o Sistema de Logs para registrar todos os

eventos possíveis, implementando também logs remotos;
Desabilitar protocolos que permitem autenticação baseada
em IP;
Desativar serviços desnecessários, inclusive impressão,
ftp, R-TOOLS como: rlogin, rsh e rcp.
Proteger com senha o modo single-user;
Otimizar TCP Wrappers;
Acrescentar banners com mensagens legais sobre
utilização do sistema;
As capacidade do padrao DAC em
Sistemas Linux
Quota
 Controles de Quotas de Usuário

●
Para controlar a utilização do sistema de arquivos, pode-
se fazer uso de quotas, que devem ser especificadas
para partições e não para diretórios.
●
O primeiro passo é incluir as opções usrquota e
grpquota no arquivo /etc/fstab, na partição em que
se deseja utilizar
# vi /etc/fstab
/dev/hda9 /home ext3
defaults,usrquota,grpquota 0 2
●
Há dois padrões para o uso de quotas, quota1 e quota2,
sendo que para cada um deve-se carregar o módulo
específico no kernel, quota_v1 e quota_v2
 Controles de Quotas de Usuário
●
Trabalharemos com o padrão de quota2. Deve-se criar dois
arquivos de controle de quota
– aquota.user – gerencia quotas de usuários
– aquota.group – gerencia quotas de grupos
# cd /home
# touch aquota.user aquota.group
Somente o root deve ter permissão para leitura e escrita sobre eles
# chmod 600 aquota.user
# chmod 600 aquota.group
●
Deve-se remontar o sistemas de arquivos, mas, coomo geralmente
este está sempre ocupado, recomenda-se salvar aplicações e
reiniciar o sistema.
 Controles de Quotas de Usuário

●
Após a inicialização, consultar o status de quota para a
partição
# repquota -v -a
●
Agora, pode-se definir quanto cara usuário poderá
utilizar
#edquota -u teste
●
Teremos:
– O sistema de arquivos onde a quota está habilitada
– Limites soft e hard para o número máximo de blocos
– Limites soft e hard para o número máximo de inodes
 Controles de Quotas de Usuário
●
Para consultar a quota de um usuário
# quota -u usuario
●
Para verificar mais detalhes sobre o uso das quotas
nas partições
#quotastats
●
Desativar a quota da partição
#quotaoff -v /home
●
Para fazer uma checagem na partição e verificar se
está tudo OK
#quotacheck -vcug /home
● Desativar a quota da partição
Controles
Segurança
p/ contas
de usuários
Controles de Remover shell válidas de certos
usuários

● Script /root/invalidos.sh
#!/bin/bash

for USER in $(cat /etc/passwd| cut -f 1 -d “:” | \

grep -v ^root: | grep -v ^usuario_adm: )
do
chsh -s /sbin/nologin $USER
done
Controles de Remover shell válidas de certos
usuários

●
Para adotar essa política sempre que se criar um novo
usuário, é necessário editar os seguintes arquivos.
●
No Debian:
# vi /etc/adduser.conf
●
Nesse arquivo, pode-se mudar a variável DSHELL para um
shell inválida
DSHELL=/sbin/nologin
●
No Red Hat:
# vi /etc/default/useradd
Obs.: Muitas referências sugerem /dev/null ou /bin/false como
shell inválidas mas em ambiente REDHAT utilize /sbin/login
 Trilha de Auditoria de Comandos

●
O shell bash armazenas os últimos comandos no arquivo
~/.bash_history
●
Todo usuário tem seu próprio arquivo .bash_history
●
Reduzindo o número de comandos armazenados no arquivo
.bash_history pode manter protegidas as senhas
casualmente digitadas em linha de comando
●
Assim, deve-se ajustar as variáveis HISTFILESIZE e
HISTSIZE que estão no arquivo /etc/profile para:
HISTFILESIZE=15000
HISTSIZE=20000
HISTTIMEFORMAT="- %d/%m/%Y %H:%M:%S - "
Automatização da configuração do HISTORY 1/2
#!/bin/bash
RULES='HISTTIMEFORMAT="- %d/%m/%Y %H:%M:%S - "'
BASHRC_GERAL="/etc/bashrc"
BASHRC_SKEL="/etc/skel/.bashrc"
BASHRC_ROOT="/root/.bashrc"
func_readonly_hist()
{
_ARQ=”$1”
POLICE_RONLY=“readonly -n $VAR_HIST”
for VAR_HIST in HISTFILE HISTFILESIZE HISTSIZE HISTTIMEFORMAT
do
grep $POLICE_RONLY "$_ARQ" || echo $POLICE_RONLY >> “$_ARQ”
done
}
func_files()
{
for ARQ in $BASHRC_GERAL $BASHRC_SKEL $BASHRC_ROOT
do
if [ -f $ARQ ]
then
grep HISTTIMEFORMAT "$ARQ" || echo "$RULES" >> "$ARQ"
func_readonly_hist “$ARQ”
fi
done
Automatização da configuração do HISTORY 2/2

func_user()
{
for USER_HOME in $(cut -f 6 -d ":" /etc/passwd)
do

if [ -f "$USER_HOME"/.bashrc ]
then
grep HISTTIMEFORMAT "$USER_HOME"/.bashrc || echo "$RULES" >> "$USER_HOME"/.bashrc
. "$USER_HOME"/.bashrc
Fi

done

}
func_files && func_user
Controles
Segurança
em serviços
de redes
 Hardening Linux - Serviços de Rede

●
Stand alone versus Inetd
●
O modelo Inetd
– Network Super Daemon
– /etc/services : Mapeia o nome do serviço a número de porta
●
eg: ulistserv 372/tcp ulistproc
– /etc/inetd.conf : Main Configuration file for inetd.
ftp stream tcp nowait root /usr/sbin/tcpd proftpd
 Hardening Linux - Serviços de Rede

●
O modelo Xinetd
– Grande substituto para inetd
– Mais securo e flexível com avançado mecanismo de controle de
acesso
– /etc/xinetd.conf : Arquivo de Configuração principal do xinetd
– /etc/xinetd.d/ : Contém arquivos para serviços gerenciados pelo
xinetd
 Hardening Linux - Serviços de Rede

Gerenciamento de Serviços de Redes em Inetd e Xinetd

●
Para Inetd : descomentar o correspondente serviço no arquivo
inetd.conf
– Reiniciar o daemon Inetd
# pkill –HUP inetd
●
For Xinetd : Fazer mudanças em xinetd.conf e xinetd.d
– Mecanismos de controle de acesso para serviços pode ser
especificados
# /etc/rc.d/init.d/xinetd restart
●
Típicos Serviços que devem ser bloqueados
– Finger, FTP, Telnet, echo, ntalk
– rwho, rsh , rlogin, rexec, (Recomenda-se ssh, scp, sftp)
 Controles de xinetd

●
Super servidor que carregar serviços de rede baseado em
requisições a partir da rede
● /etc/xinetd.conf
– Portas a escutar
– Que servidor iniciar para cada porta
●
Verifica que serviço oferecer – Negar outros
– Arquivos /etc/xinetd.d/*
– Alterar de disable = no para disable = yes
# chmod 600 /etc/xinetd.conf
 Controles de xinetd

● stat /etc/xinetd.conf – garantir que o

proprietário é o root
● chattr +i /etc/xinetd.conf – tornar o arquivo
“imutável”, não pode ser modificado, deletado ou renomeado
and nenhum link criado
●
reiniciar o servidor xinetd após as mudanças
– /etc/init.d/xinetd reload
# chattr +i /etc/xinetd.conf
# chattr +i /etc/xinet.d/*
 Controles de
Gerenciando inicialização de serviços

●
O diretório /etc/init.d/ guarda todos os scripts de
inicialização de serviços dos sistema
●
O diretório /etc/rc.d/ guarda os links simbólicos
para cada runlevel (nível de execução) em diferentes
diretórios, por exemplo
– /etc/rc.d/rc1.d : Serviços que iniciam e param
no nível
– /etc/rc.d/rc2.d/S10network : iniciar o serviço
de rede no runlevel 2
– /etc/rc.d/rc2.d/K09smb : para o serviço smb
(samba)
 Controles de
Gerenciando inicialização de serviços

●
Estes scripts devem estar disponível para leitura
apenas para o root
# chmod -R 700 /etc/rc.d/init.d/*

Obs.: Em caso de ser demandado acesso de usuários

específicos recomenda-se SUDO.
 Controles de
Gerenciando inicialização de serviços

●
Debian:
# update-rc.d <nome> defaults [NN | NN-start NN-stop]
●
Colocando o defaults, ele irá deixar os runlevels para inicialização
como: 2, 3, 4 e 5; e para finalização: 0, 1 e 6. NN indica que o
arquivo terá a mesma prioridade na inicialização/finalização. Para
deixar diferente, especifique NN-start para a inicialização e NN-
stop para finalização.
– para remover um arquivo da inicialização/finalização:
# update-rc.d [-f] <nome_servico> remove
●
O -f pode ser usado para que o update-rc.d remova também links
simbólicos. Este comando excluirá os links dos rcN.d, e
conseqüentemente com que o serviço seja iniciado e parado
manualmente
 Controles de
Gerenciando inicialização de
serviços

●
RedHat:
# chkconfig add servico
# chkconfig servico on
Coloca servico para iniciar sempre com o sistema.
# chkconfig servico off
Retira servico da inicialização junto com o sistema.

Há outras opções para o chkconfig.

 Controles de
Gerenciando inicialização de
serviços

●
Debian:
– Para inicializar/para/reiniciar serviços manualmente
● /etc/init.d/nome_servico start|stop|restart|reload
● invoke-rc.d nome_servico start|stop|restart|reload
●
Red Hat:
– Para inicializar/para/reiniciar serviços manualmente
● /etc/init.d/nome_servico start|stop|restart|reload
● service nome_servico start|stop|restart|reload
 Controles de Desabilitar acesso a
programa de console

●
Desabilitar todo acesso equivalente a programas de console
como shutdown, reboot, poweroff e halt para
usuários comuns
● rm -f /etc/security/console.apps/<programa>
●
Arquivo xserver
– Se removido usuários comuns não poderão rodar o
xserver
– Somente root pode rodar xserver
– Usuários iniciarão o xserver apenas usando um
gerenciador de desktop; xdm/gdm
 Controles de Arquivo /etc/host.conf

●
Linux usa um arquivo para determinar de onde serão obtidos
os endereços IP corrrespondentes os nomes de máquinas
●
Editar /etc/host.conf
order hosts, bind
– Indica ao ordem de utilização dos serviços de consulta de
nomes
nospoof on
– Não forja o IP da máquina – IP spoofing é uma forma de
exploração da segurança
 Controles de Arquivo /etc/services

●
Converte um nome de serviço para um número de porta
●
Somente ao root deve ser permitido realizar alterações
nesse arquivo
●
Portanto, deve-se torná-lo imutável:
chattr +i /etc/services
 Controles de TCPWrappers

●
Segundo a norma NBR ISO/IEC 27002, em específico o item 9.4.1,
que diz respeito à “Política de utilização dos serviços de Rede”, é
conveniente que os usuários possuam controles e gerenciamento. E
ainda, no item 9.4.7, que diz a respeito ao “Controle de conexões de
Rede” é recomendável que existam controles que limitem a capacidade
de conexão dos usuários.
●
Pensando nas recomendações da norma, pode-se, inicialmente, utilizar
dois recursos para limitar o uso dos serviços de rede, que seriam o
TCPWRAPPERS (/etc/hosts.deny e /etc/hosts.allow)
combinado com limitações de conexão que podemos fazer pelo PAM
(/etc/pam.d e /etc/security) aliado à uma política bem definida e
com um estrutura de registro de eventos Syslog, que iremos
configurar posteriormente.
 Controles de TCPWrappers

●
Nega qualquer acesso remoto dos serviços

vinculados aos Supers Deamon (xinet ou inetd).

– Sua configuração deve ser efetuada através dos

arquivos /etc/hosts.allow e /etc/hosts.deny

– Em /etc/hosts.deny são configuradas as regras

para negar serviços a determinados clientes, já

em /etc/hosts.allow configuram-se regras para

permitir o acesso a determinados clientes

 Controles de TCPWrappers

● As regras de controle de acesso, existentes nestes dois

arquivos, têm o seguinte formato:
lista_de_daemons : lista_de_clientes [: comando]
– lista_de_daemons: Lista de um ou mais nomes de daemons (como
especificados no /etc/inetd.conf), ou curingas.
– lista_de_clientes: Lista de um ou mais endereços ou nomes de
máquinas, padrões ou curingas utilizados para especificar quais
clientes podem e quais não podem acessar o serviço.
– comando (opcional): É possível executar um comando sempre que
uma regra casa com um padrão e é utilizada.
 Controles de TCPWrappers

●
Curingas podem ser utilizados tanto na lista de daemons quanto na
lista de clientes.
– ALL
●
Significa todos os serviços ou todos os clientes,
dependendo apenas do campo em que se encontra.
– LOCAL
●
Este curinga casa com qualquer nome de máquina que não
contenha um caractere ponto “.”, isto é, uma máquina local.
– PARANOID
●
Casa com qualquer nome de máquina que não case com seu
endereço. Isto geralmente ocorre quando algum servidor
DNS está mal configurado ou quando alguma máquina está
tentando se passar por outra.
 Controles de TCPWrappers

Exemplo de Configuração
●
Arquivo /etc/hosts.deny:
ALL:ALL
●
Arquivo /etc/hosts.allow:
ALL: localhost
in.sshd: 192.168.0.0/24
apache2: ALL
ipop3d: ALL EXCEPT 192.168.0.0/24
●
Observem o operador EXCEPT, que permitiu que o acesso ao
serviço ipop3d fosse liberado para todos, exceto para
máquinas da rede 192.168.1.0/24
Controles de
Limitação
de uso de
recursos
com SUDO
 Controles de Sudo

●
Com o sudo, pode-se definir que comandos cada usuário
comum pode executar como se fosse root
● # apt-get install sudo
●
O arquivo de configuração do sudo é /etc/sudoers
●
Exemplo de configuração:
teste ALL=/sbin/ifconfig, /sbin/iptables
●
Define que o usuário teste pode executar os comandos
ifconfig e iptables, sendo solicitada a senha de root
 Controles de Sudo

●
Exemplo de configuração:
teste ALL=NOPASSWD: /bin/reboot, /bin/halt
●
Define que o usuário teste pode executar os comandos reboot
e halt, sem que seja solicitada a senha de root
●
Exemplo de configuração:
teste ALL=/sbin/passwd [A-Z]*,!/usr/bin/passwd root
●
Define que o usuário teste pode alterar a senha de qualquer
usuário cujo login estiver no intervalo de A-Z, exceto a senha
de root
Controles
Segurança
p/ serviço
SSH
 Controles de SSH

●
O serviço SSH é, atualmente, um dos mais úteis para
administradores de sistemas
– Permite acesso remoto a máquinas
– Confidencialidade
– Autenticidade
– Automatização de atividades
 Controles de SSH

●
Configuração:
– Os arquivos de configuração normalmente ficam em:
/etc/ssh
– Normalmente temos estes arquivos
moduli
sshd_config
ssh_host_dsa_key.pub
ssh_host_key.pub
ssh_host_rsa_key.pub
ssh_config
ssh_host_dsa_key
ssh_host_key
ssh_host_rsa_key
 Controles de SSH

●
Configurações:
– Desabilitar login como root
PermitRootLogin no

– Usar a separação de privilégios (neste caso apenas

algumas atividades são feitas com o usuário root e as
demais com outro usuário do sistema)‫‏‬
● UsePrivilegeSeparation yes
 Controles de SSH

●
Usar a versão 2 do protocolo que é mais segura
Protocol 2
●
Alterar a porta padrão
port 10648
● Restringir o endereço de escuta
ListenAddress 192.168.0.12
#(endereço ip a ser utilizado para requisições ssh)
●
Desabilitar o forward de portas
AllowTcpForwarding no
X11Forwarding no
 Controles de SSH

●
Checar as permissões dos arquivos e o donos do mesmo
StrictModes yes
●
Caso não seja necessário, desabilitar o sftp, comentando-o
#Subsystem sftp /usr/lib/misc/sftp-
server
 Controles de SSH

●
Impor restrições de login
LoginGraceTime 1m
PasswordAuthentication no
UsePAM yes
AllowUsers (usuario_ssh1) (usuario_ssh2)
PrintMotd no
UseDNS yes
●
Desabilitar as autenticações baseadas em confiança entre os
hosts
IgnoreRhosts yes
HostbasedAuthentication no
RhostsRSAAuthentication no
 Controles de Nmap

●
Para verificar se as portas corretas estão abertas, pode
usar o nmap
●
Usado também para verificar o que está aberto em um
servidor
# nmap -sS -P0 -O servidor
– sS - realiza um stealth scan , a verificaçao ocorre pelo
modo half-open connection.
– P0 - realiza o portscan sem pingar.
– O - Tenta advinhar o sistema operacional remoto
 Controles de Nmap

●
Outros exemplos
# nmap -sS 192.168.1.150
exibe as portas abertas ou em uso ou
# nmap -sF <ip> -p 1-65535
# nmap -sF 192.168.1.2 -p 1-65535
pega todas as portas em uso.
# nmap -p 1-65000 localhost
para ver as portas que estão ouvindo
Controles p/
Contabilização
e Auditoria
 Controles e Auditoria - Auditoria

●
Todos os logs gerados pelo sistema são úteis para Auditoria,
porém as informações de produção devem ser registradas de
maneira a permitir uma trilha de auditoria. Na norma NBR
ISO/IEC 17799/27002, recomenda-se no item 10.10.2, que
caso haja alguma criação, exclusão e alteração (data, id,
permissão) do arquivo, ele deve ser checado para que não
tenha nenhuma alteração maliciosa. Também devem ser
mantidas registradas todas as ações no sistema, de forma a
produzir uma trilha de referência.
●
Podemos ter um maior controle dos últimos comandos que os
usuários digitaram, através de um comando chamado
lastcomm, pertecente ao pacote acct
# apt-get install acct
 Controles e Auditoria - Auditoria

●
Para testá-lo:
# lastcomm
●
Sem argumento algum, o comando mostra uma visão
geral dos últimos comandos digitados pelos usuários
●
Podemos fazer uma consulta apenas dos últimos
comandos digitados por um determinados usuário:
# lastcomm root
●
Ou, então, fazer um busca pelas ocorrências de
determinando comando
# lastcomm wget
 Controles e Auditoria - Auditoria

●
Outra ferramenta bastante interessante e extremamente útil é o
Snoopy. Ele registra todos os comandos digitados por um usuário e o
que está digitando , e não somente os últimos como o lastcomm
# apt-get install snoopy
●
Quando ele é instalado, para o seu devido funcionamento, ele cria uma
biblioteca dentro de /lib e a insere no arquivo
/etc/ld.so.preload.
# cat /etc/ld.so.preload
●
Com um usuário qualquer digite alguns comandos e verifique os
registros do Snoopy:
# tail -f /var/log/auth.log
●
Para desativá-lo, basta comentar a linha que foi inserida no
arquivo /etc/ld.so.preload
Controles
p/ Auditoria
de Sistemas
HIDS
 Controles e Auditoria – Host IDS

●
Aide (Advanced intrusion detection environment)

●
Instalando o Aide no Debian
# apt-get install aide

●
Configuração

●
Localização dos arquivos:
– /etc/aide/aide.conf -> arquivo de confi guração.
– /var/lib/aide/aide.db -> arquivo de base de dados.
– /var/lib/aide/aide.db.new -> arquivo de saída da base de dados.
 Controles e Auditoria – Host IDS

● Edite o arquivo /etc/aide/aide.conf Abaixo, um

exemplo de configuração:
All=R+a+sha1+rmd160
/etc p+i+u+g # check somente permissões, inode, usuários e grupos do
etc
/bin All # aplica as regras definidas na variável All para todos os
arqs do /bin
/sbin All # idem /sbin

/var All # idem /var

/usr/bin All # idem /usr/bin
/usr/sbin All # idem /usr/sbin

!/var/log/.* # ignora o diretório /var/log

!/var/spool/.* # ignora o diretório de spool
/etc ConfFiles
 Controles e Auditoria – Host IDS

●
Antes de gerar uma base é necessário validar as

alterações no arquivo de configuração aide.conf.

# update-aide.conf

●
Esse comando vai criar uma cópia do arquivo de

configuração no diretório /var/lib/aide

chamado aide.conf.autogenerated que vai ser usado

pelo comando gerador de bases do Aide.

 Controles e Auditoria – Host IDS

●
Gerando uma base

# aide --init

● Foi gerado o arquivo /var/lib/aide/db.aide.new,

para ser feito a auditoria é necessário remonear o arquivo
para /var/lib/aide/db.aide,ou

# aideinit

●
Quando executado, o comando aideinit, criará o arquivo:

var/lib/aide/db.aide.new, e criará também o:

/var/lib/aide/db.aide.
 Controles e Auditoria – Host IDS

●
Simular um arquivo forjado.

# cp /bin/su /root

# echo teste > /bin/su

●
Realizando um uma auditoria
# nice -n -19 aide –C
--config=/var/lib/aide/aide.conf.autogenerated
| tee /etc/relatorio.txt
Controles
Registros
(logs) e
auditoria
 Controles e Auditoria - Servidor de Logs

●
A necessidade de registro das atividades dos usuários e serviços
dos sistemas é, notoriamente, muito importante para os
administradores. A importância é tanta, que na norma NBR
ISO/IEC 17799, recomenda-se no item 9.7.1, que diz respeito ao
“Registro (log) de eventos”, ser também prioridade uma política de
segurança onde os registros de logs devam atender às seguintes
características:
– Identificação dos usuários;
– Datas e horários de entrada (login, logout);
– identidade do terminal, nome da máquina ou IP;
– Registro das tentativas de acesso aos aceitos e rejeitados;
– Registro das tentativas de acesso a outros recursos e dados
aceitos e rejeitados.
 Controles e Auditoria - Servidor de Logs

● O syslog-ng é um novo sistema de logs de extrema facilidade

de configuração e possui grandes recursos.

● Para instalar basta executar:

# apt-get install syslog-ng

● Iremos configurar o Servidor e os Clientes para enviarem

seus logs para o Log Server
 Controles e Auditoria - Servidor de Logs

Configuração do Servidor
# vi /etc/syslog-ng/syslog-ng.conf

● Opções de Origem, Máquinas Remotas

source servremotos { udp();};

● Opções de Filtro
## Filtro para o Servidor Remote 1

filter f_servremoto1 {host(“192.168.0.1”);};

## Filtro para o Servidor Remote 2

filter f_servremoto2 {host(“192.168.0.2”);};

 Controles e Auditoria - Servidor de Logs

Configuração do Servidor
● Opções de Destino
# Destino do Logs do Servidor Remote 1

destination servremoto1{

file(“/var/logserver/servremoto1.log” owner(“root”)
group(“root”) perm(0640));};

# Destino do Logs do Servidor Remote 2

destination servremoto2{

file(“/var/logserver/servremoto2.log” owner(“root”)
group(“root”) perm(0640));};
 Controles e Auditoria - Servidor de Logs

Configuração do Servidor
● Opções de Log (Montagem do Log)
# Logs do Servidor Remote 1

log{source(servremotos); filter(f_servremoto1);
destination(servremoto1);};

# Logs do Servidor Remote 2

log{source(servremotos); filter(f_servremoto1);
filter(authpriv) ; destination(servremoto1);};

● Reiniciar o Syslog-NG
# /etc/init.d/syslog-ng restart
 Controle e Auditoria – Servidor de Logs

Configuração do Clinte (Servidor Remoto)

# vi /etc/syslog-ng/syslog-ng.conf

● Opções de Destino
destination servlog{ udp(“192.168.0.8” port(514));};

● Opções de Log (Montagem do Log)

# Registro dos Logs no Servidor

log{source(src); destination(servlog);};

● Reiniciar o Syslog-NG
# /etc/init.d/syslog-ng restart
 Controles e Auditoria - Servidor de Logs

●
Estes são os passos mais importantes, configurar a

origem (source), destino (destination) e o filtro

(filter).

●
No filtro pode-se utilizar de algumas funções como:

– facility() - Ex. facility(mail);

– level() - Ex. level(notice);

– program() - Ex. program(”^mysqld”);

 Controles e Auditoria - Servidor de Logs

● Após qualquer alteração nos arquivos de

configuração, é necessário reinicializar o serviço de
Sistema de Logs.

●
Debian:
# /etc/init.d/syslog-ng stop
# /etc/init.d/syslog-ng start

●
Redhat:
# services syslog-ng stop
# services syslog-ng start
 Controles e Auditoria
Rotacionamento de Logs

● Como os logs crescem muito rapidamente, deve-se

definir um política de logs e utiliza o recurso de
rotacionamento de logs nativo do sistema, o
LogRotate.
● O arquivo de configuração do rotacionamento no
Debian é /etc/logrotate.conf e no Red Hat é o

/etc/rotate.conf
 Controles e Auditoria
Rotacionamento de Logs
Algumas opções do LogRotate
● weekly
– Essa opção faz com os logs sejam rotacionados
semanalmente, ,mas também pode ser diariamente (daily)

● rotate 4
– Define que serão mantidos os 4 últimos rotacionamentos para
não perder o controle
● mail root
– Define, em que casos de erros de não tem existências de logos,
eles sejam enviados para o root
 Controles e Auditoria
Rotacionamento de Logs
Algumas opções do LogRotate
● create
– Essa opção determina que sejam criados novos arquivos de
log(vazios), após os antigos rodarem
● compress
– Essa opção determina que as cópias de logs sejam
compactadas, mantendo sempre o último rodado descompactado
● Pode-se definir uma estrutura personalizada para cada arquivo de
log, como no exemplo mostrado ao final do arquivo
logrotate.conf
 Controles e Auditoria
Rotacionamento de Logs

● Mesmo o rotacionamento sendo determinado pelo arquivo

de configuração logrotate.conf, pode-se forçar a
rodá-lo a qualquer momento, manualmente, por meio do
comando:

# logrotate /etc/logrotate.conf

● O controle das ações de rotacionamente é feito por meio

do contrab, o que pode ser observado em:

# cat /etc/crontab
 Controles e Auditoria - Auditoria

●
Todos os logs gerados pelo sistema são úteis para Auditoria,
porém as informações de produção devem ser registradas de
maneira a permitir uma trilha de auditoria. Na norma NBR
ISO/IEC 17799/27002, recomenda-se no item 10.10.2, que
caso haja alguma criação, exclusão e alteração (data, id,
permissão) do arquivo, ele deve ser checado para que não
tenha nenhuma alteração maliciosa. Também devem ser
mantidas registradas todas as ações no sistema, de forma a
produzir uma trilha de referência.
●
Podemos ter um maior controle dos últimos comandos que os
usuários digitaram, através de um comando chamado
lastcomm, pertecente ao pacote acct
# apt-get install acct
 Controles e Auditoria - Auditoria

●
Para testá-lo:
# lastcomm
●
Sem argumento algum, o comando mostra uma visão
geral dos últimos comandos digitados pelos usuários
●
Podemos fazer uma consulta apenas dos últimos
comandos digitados por um determinados usuário:
# lastcomm root
●
Ou, então, fazer um busca pelas ocorrências de
determinando comando
# lastcomm wget
 Controles e Auditoria - Auditoria

●
Outra ferramenta bastante interessante e extremamente útil é o
Snoopy. Ele registra todos os comandos digitados por um usuário e o
que está digitando , e não somente os últimos como o lastcomm
# apt-get install snoopy
●
Quando ele é instalado, para o seu devido funcionamento, ele cria uma
biblioteca dentro de /lib e a insere no arquivo
/etc/ld.so.preload.
# cat /etc/ld.so.preload
●
Com um usuário qualquer digite alguns comandos e verifique os
registros do Snoopy:
# tail -f /var/log/auth.log
●
Para desativá-lo, basta comentar a linha que foi inserida no
arquivo /etc/ld.so.preload
 Controles e Auditoria – Host IDS

●
Aide (Advanced intrusion detection environment)

●
Instalando o Aide no Debian
# apt-get install aide

●
Configuração

●
Localização dos arquivos:
– /etc/aide/aide.conf -> arquivo de confi guração.
– /var/lib/aide/aide.db -> arquivo de base de dados.
– /var/lib/aide/aide.db.new -> arquivo de saída da base de dados.
 Controles e Auditoria – Host IDS

●
Antes de gerar uma base é necessário validar as

alterações no arquivo de configuração aide.conf.

# update-aide.conf

●
Esse comando vai criar uma cópia do arquivo de

configuração no diretório /var/lib/aide

chamado aide.conf.autogenerated que vai ser usado

pelo comando gerador de bases do Aide.

 Controles e Auditoria – Host IDS

●
Gerando uma base

# aide --init

● Foi gerado o arquivo /var/lib/aide/db.aide.new,

para ser feito a auditoria é necessário remonear o arquivo
para /var/lib/aide/db.aide,ou

# aideinit

●
Quando executado, o comando aideinit, criará o arquivo:

var/lib/aide/db.aide.new, e criará também o:

/var/lib/aide/db.aide.
 Controles e Auditoria – Host IDS

●
Simular um arquivo forjado.

# cp /bin/su /root

# echo teste > /bin/su

●
Realizando um uma auditoria
# nice -n -19 aide –C
--config=/var/lib/aide/aide.conf.autogenerated
| tee /etc/relatorio.txt