Blindagem de Servidores baseado

na Norma ISO 27002

www.linuxforce.com.br
Registro de Eventos

Quando temos algum problema com o nosso servidor, o primeiro lugar à consultar
são os logs

Importância dos Logs de sistema

São os logs que trazem as informações do que está acontecendo no sistema. Muitas
vezes, só olhando os logs já conseguimos descobrir qual é o problema, e mesmo
se não sabemos qual é o problema, podemos copiar um trecho do log e procurar no
Google. Todos os logs estão no diretório /var/log.

E o que a norma diz sobre o Registro de Eventos?

No documento postado no prepara-se para a aula, mostra o que a norma fala sobre
os Logs(registro de eventos). Ela menciona o item 10.10 e 10.10.1, falando sobre o

3
 Linux Force – www.linuxforce.com.br

que deve ser registrado. E fala do item 10.10.3 na questão de segurança dos logs.

Interesse de um cracker nos logs de sistema

O Cracker não tem interesse somente no conteúdo dos logs. Ele está mais interes-
sando em destruir os logs, apagar os rastros dele, para ninguém desconfiar que ele
esteve ali.

A aplicação padrão de um sistema GNU/Linux é o Syslog.

Quem é o Syslog-NG?

O NG, é de Next Generation. O Syslog-NG é um substituto do Syslog, tem mais re-

cursos e traz uma gama maior de opções de registro de Logs para o administrador.

Estrutura do Syslog

A estrutura do Syslog é dividia basicamente em 3 partes:

• facilidade (facility)

Página 4 Blindagem de Servidores baseado na Norma ISO 27002

 Linux Force – www.linuxforce.com.br

• nível (level)

• destino (destination)

No arquivo syslog.conf, elas são unidas da seguinte maneira:

1 facilidade . n í vel destino

Mas quais são as facilidades, níveis e destinos que podemos usar?

Blindagem de Servidores baseado na Norma ISO 27002 Página 5

 Linux Force – www.linuxforce.com.br

Exem-
plo:

1 cron . info / var / log / cron . info

Isso quer dizer que todos os logs de facilidade cron, com nível info, serão gravados
do arquivo /var/log/cron.info.

Página 6 Blindagem de Servidores baseado na Norma ISO 27002

 Linux Force – www.linuxforce.com.br

Estrutura do Syslog-NG

O Syslgo-NG trabalha no mesmo esquema, as facilidades, níveis e destinos são os

mesmos para ele.

Diferença do Syslog-NG em relação ao Syslog

O Syslog-NG, cria novas possibilidades de criação de logs, ele trabalha como se

fosse um quebra cabeça, do jeito que está na figura:

Fora isso, ele permite trabalhar com uma estrutura totalmente personalizada de logs
remotos, no Syslog, os logs de outras máquinas ficam no mesmo arquivo local do
servidor de logs, o que causa uma confusão na hora de pesquisar, o syslog-ng separa
em arquivos e até uma estrutura inteira de diretório para um máquina.

O syslog-ng permite também que se faça logs por palavras, podendo personalizar
ainda mais os logs, conforme a necessidade do administrador.

Instalacão do syslog-NG:

1 # aptitude install syslog - ng

Blindagem de Servidores baseado na Norma ISO 27002 Página 7

 Linux Force – www.linuxforce.com.br

Durante a instalacão do syslog-ng, ele remove o syslog e um programa cha-

mado klogd.

O klogd é o responsável pelos logs de Kernel, e o Syslog pelos logs de sistema. O

Syslog-ng, vai fazer o papel dos dois serviços.

O arquivo de configuração do syslog-ng, fica em /etc/syslog-ng, e chama- se syslog-

ng.conf. Nós não vamos usar o arquivo original, vamos usar um arquivo que está
postado no forceclass. É basicamente o mesmo arquivo, mas está organizado de
uma maneira que fica mais fácil de entender.

1 # cd / etc / syslog - ng
2 # vim syslog - ng . conf

1 # OPC Õ ES GLOBAIS
2 options { long_hostnames ( off ) ;};
3 #
----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -#

4 # OP ÇÕ ES DE ORIGEM
5 source
6 src
7 {
8 unix - dgram ( " / dev / log " ) ;
9 log_prefix ( " kernel : " ) ) ;};
10 internal () ;
11 file ("/ proc / kmsg "
12 #
----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -#

13 # OPC Õ ES DE FILTRAGEM
14 filter f_authpriv { facility ( auth , authpriv ) ; };
15 filter f_syslog { not facility ( auth , authpriv ) ; };
16 filter f_cron { facility ( cron ) ; };
17 filter f_daemon { facility ( daemon ) ; };

Página 8 Blindagem de Servidores baseado na Norma ISO 27002

 Linux Force – www.linuxforce.com.br

18 filter f_kern { facility ( kern ) ; };

19 filter f_lpr { facility ( lpr ) ; };
20 filter f_mail { facility ( mail ) ; };
21 filter f_user { facility ( user ) ; };
22 filter f_uucp { facility ( uucp ) ; };
23 filter f_news { facility ( news ) ; };
24 filter f_debug { not facility ( auth , authpriv , news , mail ) ; };
25 filter f_messages { level ( info .. warn ) and not facility ( auth ,
authpriv , cron , daemon , mail , news ) ; };
26 filter f_emergency { level ( emerg ) ; };
27 filter f_info { level ( info ) ; };
28 filter f_notice { level ( notice ) ; };
29 filter f_warn { level ( warn ) ; };
30 filter f_crit { level ( crit ) ; };
31 filter f_err { level ( err ) ; };
32 filter f_cnews { level ( notice , err , crit ) and facility ( news ) ; };
33 filter f_cother { level ( debug , info , notice , warn ) or facility (
daemon , mail ) ; };
34 filter ppp { facility ( local2 ) ; };
35
36 #
----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -#

37 # OPC Õ ES DE DESTINO
38
39 destination d_authlog { file ( " / var / log / auth . log " owner ( " root " )
group ( " adm " )
40 perm (0640) ) ; };
41
42 destination d_syslog { file ( " / var / log / syslog " owner ( " root " ) group ( "
adm ")
43 perm (0640) ) ; };
44
45 destination d_cron { file ( " / var / log / cron . log " owner ( " root " ) group ( "
adm ")
46 perm (0640) ) ; };
47

Blindagem de Servidores baseado na Norma ISO 27002 Página 9

 Linux Force – www.linuxforce.com.br

48 destination d_daemon { file ( " / var / log / daemon . log " owner ( " root " )
group ( " adm " )
49 perm (0640) ) ; };
50
51 destination d_kern { file ( " / var / log / kern . log " owner ( " root " ) group ( "
adm ")
52 perm (0640) ) ; };
53
54 destination d_lpr { file ( " / var / log / lpr . log " owner ( " root " ) group ( " adm
")
55 perm (0640) ) ; };
56
57 destination d_mail { file ( " / var / log / mail . log " owner ( " root " ) group ( "
adm ")
58 perm (0640) ) ; };
59
60 destination d_user { file ( " / var / log / user . log " owner ( " root " ) group ( "
adm ")
61 perm (0640) ) ; };
62
63 destination d_uucp { file ( " / var / log / uucp . log " owner ( " root " ) group ( "
adm ")
64 perm (0640) ) ; };
65
66 destination d_mailinfo { file ( " / var / log / mail . info " owner ( " root " )
group ( " adm " )
67 perm (0640) ) ; };
68
69 destination d_mailwarn { file ( " / var / log / mail . warn " owner ( " root " )
group ( " adm " )
70 perm (0640) ) ; };
71
72 destination d_mailerr { file ( " / var / log / mail . err " owner ( " root " ) group
(" adm " )
73 perm (0640) ) ; };
74
75 destination d_newscrit { file ( " / var / log / news / news . crit " owner ( " root "

Página 10 Blindagem de Servidores baseado na Norma ISO 27002

 Linux Force – www.linuxforce.com.br

) group ( " adm " ) perm (0640) ) ; };

76
77 destination d_newserr { file ( " / var / log / news / news . err " owner ( " root " )
group ( " adm " ) perm (0640) ) ; };
78
79 destination d_newsnotice { file ( " / var / log / news / news . notice " owner ( "
root ")
80 group (" adm " ) perm (0640) ) ; };
81
82 destination d_debug { file ( " / var / log / debug " owner ( " root " ) group ( " adm
")
83 perm (0640) ) ; };
84
85 destination d_messages { file ( " / var / log / messages " owner ( " root " )
group ( " adm " )
86 perm (0640) ) ; };
87
88 destination d_console { usertty ( " root " ) ; };
89 destination d_console_all { file ( " / dev / tty8 " ) ; };
90 destination d_xconsole { pipe ( " / dev / xconsole " ) ; };
91 destination d_ppp { file ( " / var / log / ppp . log " owner ( " root " ) group ( " adm
")
92 perm (0640) ) ; };
93
94 #
----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -#

95 # OPC Õ ES DE LOG ( Montagem do Log )

96
97 log { source ( src ) ; filter ( f_authpriv ) ; destination ( d_authlog ) ; };
98 log { source ( src ) ; filter ( f_syslog ) ; destination ( d_syslog ) ; };
99 log { source ( src ) ; filter ( f_daemon ) ; destination ( d_daemon ) ; };
100 log { source ( src ) ; filter ( f_kern ) ; destination ( d_kern ) ; };
101 log { source ( src ) ; filter ( f_lpr ) ; destination ( d_lpr ) ; };
102 log { source ( src ) ; filter ( f_mail ) ; destination ( d_mail ) ; };
103 log { source ( src ) ; filter ( f_user ) ; destination ( d_user ) ; };
104 log { source ( src ) ; filter ( f_uucp ) ; destination ( d_uucp ) ; };

Blindagem de Servidores baseado na Norma ISO 27002 Página 11

 Linux Force – www.linuxforce.com.br

105 log { source ( src ) ; filter ( f_mail ) ; filter ( f_info ) ; destination (

d_mailinfo ) ; };
106 log { source ( src ) ; filter ( f_mail ) ; filter ( f_warn ) ; destination (
d_mailwarn ) ; };
107 log { source ( src ) ; filter ( f_mail ) ; filter ( f_err ) ; destination (
d_mailerr ) ; };
108 log { source ( src ) ; filter ( f_news ) ; filter ( f_crit ) ; destination (
d_newscrit ) ; };
109 log { source ( src ) ; filter ( f_news ) ; filter ( f_err ) ; destination (
d_newserr ) ; };
110 log { source ( src ) ; filter ( f_news ) ; filter ( f_notice ) ; destination (
d_newsnotice ) ; };
111 log { source ( src ) ; filter ( f_debug ) ; destination ( d_debug ) ; };
112 log { source ( src ) ; filter ( f_messages ) ; destination ( d_messages ) ; };
113 log { source ( src ) ; filter ( f_emergency ) ; destination ( d_console ) ; };
114 log { source ( src ) ; filter ( f_cnews ) ; destination ( d_xconsole ) ; };
115 log { source ( src ) ; filter ( f_cother ) ; destination ( d_xconsole ) ; };
116 log { source ( src ) ; filter ( ppp ) ; destination ( d_ppp ) ; };
117 log { source ( src ) ; filter ( f_cron ) ; destination ( d_cron ) ; };

Nas opções de origem, a palavra source é uma palavra reservada e não pode ser
mudada, o que vem depois dela, no caso do exemplo é src, é um nome que é definido
pelo administrador, pode ser qualquer nome.

Os parâmetros unix-dgram(“/dev/log”); internal();, definem os logs de sistema que

serão gerados localmente.

Os parâmetros file(“/proc/kmsg” log_prefix(“kernel: :)), define os logs de kernel, aqui

o syslog-NG está fazendo o papel do klogd. Sem isso, o syslog-NG não gera os logs
de kernel.

Nas opções de filtro, a palavra filter é uma palavra reservada e não pode ser mudada,
o que vem depois dela, é definida pelo administrador. No nosso exemplo, foi colocado
um f_ na frente do nome de cada filtro, para facilitar a visualização dos filtros.

Página 12 Blindagem de Servidores baseado na Norma ISO 27002

 Linux Force – www.linuxforce.com.br

Podemos pegar o exemplo do f_authpriv. Esse filtro diz que ele vai capturar tudo
que tiver facilidade auth e authpriv. Como os níveis não foram especificados, ele vai
capturar essas facilidades em todos os níveis.

Outro exemplo é o f_messages. Esse filtro diz que ele vai capturar tudo que tiver
nível de info até warn, em todas as facilidades que NÃO sejam a auth, authpriv, cron,
daemon, mail e news.

As opções de destino seguem a mesma lógica. A palavra destination é uma palavra

reservada, o que vem depois dela pode ser definida pelo administrador. No nosso
exemplo foi adicionado um d_ na frente do nome de todos os destinos para facilitar a
visualização.

Todos os destinos tem o mesmo formato. Eles dizem qual é o arquivo(file) que
será gravado, quem será o usuário dono(owner) desse arquivo, quem será o grupo
dono(group) do arquivo e qual vai ser a permissão(perm) do arquivo.

Mas o que vai ser gravado no destination d_authlog?

Na verdade, até aqui não da para saber, pois até agora, só declaramos as peças, na
próxima parte de LOG é que vamos começar a juntá-las.

Na junção dos logs, nós vamos definir a origem do meu log, quais os filtros eu quero
aplicar e onde ele será gravado.

Um exemplo é que estamos dizendo que tudo que vier de origem local, será aplicado
o filtro f_authpriv e será gravado no destino d_authlog.

Depois de todas as configurações, podemos reiniciar o syslog-ng e fazer um teste:

1 # / etc / init . d / syslog - ng restart

Verifique diretório /var/log, e vejam se existe algum arquivo sobre o cron:

Blindagem de Servidores baseado na Norma ISO 27002 Página 13

 Linux Force – www.linuxforce.com.br

1 # ls / var / log

Bom, ainda não existe, mas podemos reiniciar o cron para ver o que acontece:

1 # / etc / init . d / cron restart

Agora vejam se apareceu algo do cron.

Isso é uma coisa bacana, pois o Syslog-ng só cria os arquivos sob demanda, só
quando algum evento relacionado acontece, diferente do Syslog que cria um monte
de arquivos em branco.

E se um CRACKER consegue acesso ao sistema e danifica o sistema e apaga

ou modifica os Logs? O que podemos fazer?

Para nos ajudar nesse tipo de coisa, podemos trabalhar com a estrutura Cliente e
Servidor. Nessa estrutura, podemos pegar um servidor da rede, para fazer o papel
de Servidor de Logs, e todos os outros servidores enviam os seus Logs para ele, se
algum servidor for prejudicado e não conseguirmos acessar os logs, podemos pegar
os logs que estão gravados no servidor.

Página 14 Blindagem de Servidores baseado na Norma ISO 27002

 Linux Force – www.linuxforce.com.br

Vamos primeiro as opções que podem ser acrescentadas no servidor:

1 # vim / etc / syslog - ng / syslog - ng . conf

Primeiro temos que adicionar uma opção de origem:

1 source maqremotas { udp () ;};

Por que estamos usando UDP e não TCP?

Porque o pacote UDP não possuí controle de erros igual ao TCP, ele é um protocolo
menos confiável, mas é um protocolo mais rápido. Imaginem se para toda troca de
arquivos de LOG, ele precisasse estabelecer uma conexão TCP. Inviável

Agora precisamos definir um filtro para a máquina que vai ser o cliente, ou mais de
um filtro se tiverem outras máquinas:

1 filter f_maqremota1 { netmask (192.168.200.2) ; };

ou

1 filter f_maqremota1 { host ( maquina1 ) ; };

Depois temos que inserir um destino:

1 destination d_maqremota1 { file (/ var / log / maqremota1 . log owner ( root )

2 group ( adm ) perm (0640) ) ; };

Agora precisamos juntar as peças:

Blindagem de Servidores baseado na Norma ISO 27002 Página 15

 Linux Force – www.linuxforce.com.br

1 log { source ( maqremotas ) ; filter ( f_maqremota1 ) ; destination (

d_maqremota1 ) ; };

Nesse momento, podemos salvar o arquivo e reiniciar o Syslog-ng:

1 # / etc / init . d / syslog - ng restart

Verificar se o syslog-NG abriu a porta 514/UDP:

1 # netstat - nlpu | grep 514

Agora que está tudo certo na parte servidor, precisamos configurar a parte cliente.
A parte cliente é bem mais simples. As configurações também são feitas no arquivo
syslog-ng.conf.

Primeiro colocamos uma opção de destino:

1 destination servlog { udp (192.168.200.1 port (514) ) ; };

Em seguida, colocamos a montagem do Log:

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

Com isso, todas os logs locais serão enviados para o servidor de Logs.

Para validar, é necessário reiniciar o Syslog-ng:

1 # / etc / init . d / syslog - ng restart

Página 16 Blindagem de Servidores baseado na Norma ISO 27002

 Linux Force – www.linuxforce.com.br

Auditoria com o Lastcomm e Snoopy

Olhando os logs, não dá para saber quem criou um arquivo, quem apagou ou quem
digitou determinado comando.

Se vamos fazer uma Auditoria mais aprofundada nos servidores, e precisamos que
os logs contenham usuários que digitaram comandos ou quais foram os comandos
digitados, precisaremos usar outras ferramentas para isso.

Para esse caso, podemos utilizar duas ferramentas para fazer isso. A primeira é um
comando chamado lastcomm, que pertence a um pacote chamado acct.

Então, para termos o lastcomm, precisamos instalar o acct:

# aptitude install acct

# yum install psacct

A partir desse momento o lastcomm está registrando tudo que é digitado.

Para fazer o teste, vocês podem digitar vários comandos com qualquer usuário e
depois podemos analisar o resultado.

Para ver de maneira geral digite:

1 # lastcomm

Podemos ver quais foram os últimos comando do usuário root:

Blindagem de Servidores baseado na Norma ISO 27002 Página 17

 Linux Force – www.linuxforce.com.br

1 # lastcomm root

Ou, podemos ver quem foram os últimos usuários que digitaram o comando rm:

1 # lastcomm rm

Todas as informações do comando lastcomm, estão dentro do arquivo /var/-

log/account/pacct, e só podem ser visualizadas por meio de comandos, como o last-
comm.

A segunda ferramenta que podemos utilizar, é o Snoopy.

O Snoopy é uma biblioteca que é carregada sempre que um usuário efetua um login.
Assim, ele registra tudo que é digitado.

Instalem o Snoopy:

1 # aptitude install snoopy

Na instalação será perguntado se querem carregar o snoopy no /etc/ld.so.preload.

Respodam SIM.

Para testar, é necessário fazer o login novamente com um usuário, pode ser o root
ou qualquer outro.

Depois digitem algum comandos e confiram o arquivo de log:

1 # tail -f / var / log / auth . log

Página 18 Blindagem de Servidores baseado na Norma ISO 27002

Linux Force – www.linuxforce.com.br

Para desativar o snoopy, é só editar o arquivo /etc/ld.so.preload, e comentar a linha

da lib do snoopy.

Blindagem de Servidores baseado na Norma ISO 27002 Página 19