• Nenhum resultado encontrado

Conformidade com as recomendações

No documento Hardening em Linux (páginas 76-79)

O registro de eventos é uma necessidade de normas de segurança como NBR IEC 27002 e PCI DSS, entre outros. Normas e documentos de boas práticas de segurança dedicam vários tópicos à importância dos logs.

Boas práticas recomendadas na ABNT NBR ISO/IEC 27002:2008: a proposta de trilha de comando de root segregada por administrador e com o valor de timestamp possibilita plena conformidade com a recomendação do item 10.10.4.

d

Ca pí tu lo 3 - H ar de ni ng e m s is te m a L in ux – R eg is tr o d e e ve nt os ( lo g) e H ID S

As boas práticas recomendadas na ABNT NBR ISO/IEC 27002:2008 informam que, tradicio- nalmente, um bom log tem de ter informações que possibilitem uma avaliação, auditoria ou mesmo uso durante a resposta a um incidente de segurança. Essa recomendação é muito bem destacada, do item 10.10.1 ao 10.10.5, que definem diretrizes orientando o registro, monitoramento e retenção de informações para auditorias sobre atividades no sistema, sejam elas autorizadas ou não. Assim, é prioridade adotar uma política de segurança na qual os registros devam atender a características como:

1 Identificação dos usuários;

1 Datas e horários de entrada (login e logout); 1 Identidade do terminal, nome da máquina ou IP;

1 Registro das tentativas de acesso aos aceitos e rejeitados;

1 Registro das tentativas de acesso a outros recursos e dados aceitos e rejeitados; 1 Alteração de arquivos;

1 Uso de privilégios, aplicativos e utilitários do sistema.

Boas práticas para arquivos de log

Alguns critérios são sugeridos para implantação de uma política de arquivos de log, no que tange a centralização, arquivamento e acesso.

q

Logs centralizados: 1 Mais fáceis de analisar.

2 Quando temos um servidor dedicado a essa tarefa, evitamos que dados impor- tantes sejam perdidos por acidente, excluídos ou alterados de propósito, caso ocorra um incidente.

Provisões para backup de arquivos de log: 1 Arquivos de log são dados importantes.

2 Precisam ter definido um procedimento de arquivamento (backup). É interessante definir um procedimento para backup periódico, que deve também estar alinhado ao termo de retenção já estabelecido.

Proteção dos arquivos de log:

1 Arquivos de log do Sistema Operacional devem ter acesso restrito a administradores e operadores.

2 Considerando o tipo de informação que há em um determinado arquivo de log, uma vez que algumas vezes podem incluir senhas e outras informações sensíveis e confidenciais.

Período de conservação dos arquivos de log:

1 Arquivar logs mantidos eternamente não é uma solução razoável.

2 Outro ponto importante é a forma como o log será mantido, pois um arquivo de log compactado ocupa muito menos espaço que um não compactado e, caso seja um arquivo do tipo ASCII, ainda sim pode ser facilmente auditado com a ajuda de ferramentas como zcat ou bzca. Por isso, não há motivos para não realizarmos procedimento de “rotacionamento de logs” com o uso de compactação de dados.

H ar de ni ng e m L inu x

Logs do sistema

q

Diretório /var/log:

1 Tradicionalmente, nos sistemas Linux, é onde ficam registrados todos os logs do sistema. 2 Esses logs são controlados pelo serviço Syslog, o programa padrão do Linux para

essa tarefa de logs, mas também comum em outros unix e dispositivos de rede como accesspoints, roteadores, firewall, IPS, IDS e outros.

Dentro do diretório /var/log, destacam-se alguns logs que não são escritos em formato texto (ASCII). Então, não são lidos por um editor de texto comum. Eles estão em formatos binários e somente os seus comandos relacionados podem mostrar o seu conteúdo. Um desses logs é o /var/log/wtmp, que contém a informação de todos os últimos registros e logins dos usuá- rios. As informações desse arquivo só podem ser visualizadas pelo comando last.

# last

# last root

# last toor

Existe também o /var/log/btmp, que é bem semelhante ao wtmp, mas mostra as últimas tentativas de login que falharam, o que pode ser muito útil em uma auditoria ou mesmo em uma Resposta a Incidente, pois, dependendo das informações que ele forneça, podemos identificar um possível ataque de Força Bruta. O seu conteúdo pode ser visualizado com o comando lastb.

# lastb

# lastb root

# lastb toor

Outro arquivo é o /var/log/lastlog, que nos mostra quando cada usuário realizou o processo de login pela última vez e permite ter uma visão bem interessante. Pode-se visualizar o seu conteúdo com o comando lastlog.

# lastlog

O arquivo /var/run/utmp permite uma visão bem detalhada de quais usuários estão ativos naquele momento, em qual terminal, horário e mais algumas informações, até mesmo se for uma conexão remota, via ssh ou telnet. O seu conteúdo pode ser visualizado por dois comandos, o w e o who, que mostram informações bem semelhantes, ambos tratando o que foi registrado no /var/run/utmp.

# w # who Boas práticas recomendadas na ABNT NBR ISO/IEC 27002:2008: as informações de log e contabilização de processo que são usadas pelos comandos: w, who,

last, lastb, lastlog e lastcomm são de

grande utilidade para auditoria no que tange a informações de logins dos usuários do sistema. Esses recursos, que já são padrão, já permitem a conformidade com o item 11.5 da norma.

Ca pí tu lo 3 - H ar de ni ng e m s is te m a L in ux – R eg is tr o d e e ve nt os ( lo g) e H ID S

Syslog-NG

q

Syslog-NG:

1 Tem como objetivo dar alternativa ágil e flexível para organizar melhor os logs forne- cidos por um sistema Linux.

Atualmente, existem muitas opções de logs no Linux; isso também vale para outros

“sabores” de Unix. No caso do Linux, é muito comum observar que a maioria das instalações atuais que usavam o Deamon Syslog tradicional passaram a usar ou o RSYSLOG ou mesmo o próprio SYSLOG-NG.

Mas antes de montar uma estrutura para organizar os registros das atividades do sistema, é necessário entender melhor o protocolo Syslog.

A definição do formato dos registros do protocolo Syslog, que é dividida em 19 recursos, também pode ser chamada de “facility”. Entretanto, esses recursos podem ser divididos em nove níveis – os quais também são definidos como “prioridade” – de acordo com o grau crítico da ação que será registrada.

Recursos (facility)

1 auth: mensagens de segurança/autorização/autenticação que falharam, desaprovadas pelo sistema;

1 Authpriv: mensagens de segurança/autenticação/autorização; 1 cron: atividades do cron e at;

1 daemon: deamons do sistema (sshd, inetd, pppd etc.); 1 Kern: mensagens do Kernel;

1 Ipr: mensagens de impressão;

1 Mail: subsistema de e-mail (sendmail, postfix, qmail etc.); 1 news: mensagens de sistemas de newsgroups;

1 user: mensagens genéricas no âmbito do usuário; 1 uucp: informações do serviço UUCP;

1 syslog: mensagens internas do syslog;

1 local0 a local7: níveis definidos localmente, e geralmente usados para locais específicos com logs remotos de Access point.

No documento Hardening em Linux (páginas 76-79)