O monitoramento é uma parte integrante de qualquer política de segurança por várias razões. Entre elas, que o objetivo da segurança não é normalmente restrito a garantir a confidencialidade dos dados, mas também inclui a disponibilidade assegurada dos serviços. Portanto, é imperativo verificar se tudo funciona como esperado, e para detectar em tempo hábil qualquer desvio no comportamento ou mudança na qualidade do(s) serviço(s) processado(s). Atividade de monitoramento pode ajudar a detectar tentativas de intrusão e permitir uma reação rápida antes que causem consequências graves. Esta seção analisa algumas ferramentas que podem ser usadas para monitorar vários aspectos de um sistema Debian. Como tal, completa
Seção 12.4, “Monitoramento”.
14.3.1. Monitoramento de Logs com logcheck
O programa logcheck
monitora arquivos de log a cada hora por padrão. Ele envia mensagens de log incomuns em e-mails para o administrador, para posterior análise.
A lista de arquivos monitorados é armazenada em /etc/logcheck/logcheck.logfiles
, os valores padrão funcionam bem se o arquivo /etc/rsyslog.conf
não foi completamente refeito.
logcheck
pode trabalhar em um dos três modos mais ou menos detalhados: paranoid, server e workstation. O primeiro é muito verboso, e provavelmente deve ser restrito a servidores específicos, tais como firewalls. O segundo modo (e padrão) é recomendado para a maioria dos servidores. O último é projetado para estações de trabalho, e é ainda suscinto (que filtra mais mensagens).
Nos três casos, logcheck
provavelmente deve ser personalizado para excluir algumas mensagens extras (dependendo dos serviços instalados), a menos que o administrador realmente deseje receber lotes por hora de longos e-mails desinteressantes. Uma vez que o mecanismo de seleção de mensagem é bastante complexo, /usr/share/doc/logcheck-database/README.logcheck-database.gz
é uma necessidade - se desafiador - leia.
As regras aplicadas podem ser divididas em vários tipos:
aqueles que qualificam uma mensagem como uma tentativa de invasao (armazenado em um arquivo no diretorio /etc/logcheck/cracking.d/
);
aqueles cancelando essas qualificaçoes (/etc/logcheck/cracking.ignore.d/
);
aqueles classificando uma mensagem como um alerta de segurança (/etc/logcheck/violations.d/
);
aqueles cancelando esta classificacao (/etc/logcheck/violations.ignore.d/
);
finalmente, as que se aplicam às mensagens restantes (consideradas como eventos de sistema).
Um evento de sistema é sempre sinalizado a menos que uma regra em um dos diretorios /etc/logcheck/ignore.d. {paranoid,server,workstation}/
indica que o evento deve ser ignorado. Naturalmente, apenas os directórios levados em consideração são aqueles que correspondem aos níveis de verbosidade iguais ou maiores que o modo de funcionamento seleccionado.
14.3.2. Monitorando Atividades
top
é uma ferramenta interativa que exibe uma lista de processos em execução. A triagem padrão baseia se na quantidade atual de utilização do processador e pode ser obtida com a tecla P. Outras ordens de classificação incluem uma espécie de memória ocupada (tecla M), pelo tempo total do processador (tecla T) e pelo identificador de processo (tecla N). A tecla k permite matar um processo, digitando seu identificador de processo. O tecla r permite renicing um processo, ou seja, mudar sua prioridade.
Quando o sistema parece estar sobrecarregado, top
é uma ótima ferramenta para ver quais processos estão competindo por tempo de processador ou consumindo muita memória. Em particular, muitas vezes é interessante verificar se os recursos do processos que consomem coincidem com os serviços reais conhecidos que a máquina hospeda. Um processo desconhecido rodando como o usuário www-data deve realmente se destacar e ser investigado, já que é provavelmente uma instância do software instalado e executado no sistema através de uma vulnerabilidade em uma aplicação web.
top
é uma ferramenta muito flexível e sua página de manual dá detalhes sobre como personalizar a sua exibição e adaptá la às nossas necessidades pessoais e hábitos.
As ferramentas gráficas gnome-system-monitor
é semelhante ao top
e proporciona mais ou menos os mesmos recursos.
Carga do processador, o tráfego de rede e o espaço livre no disco são informações que variam constantemente. Manter um histórico de sua evolução é muitas vezes útil para determinar exatamente como o computador é usado.
Existem muitas ferramentas dedicadas a esta tarefa. A maioria pode buscar dados via SNMP (Simple Network Management Protocol, a fim de centralizar esta informação. Um benefício adicional é que este permite buscar dados de elementos de rede que podem não ser de computadores de uso geral, tais como roteadores de rede dedicadas ou switches.
Este livro trata do Munin com algum detalhe (ver
Seção 12.4.1, “Configurando o Munin”) como parte do
Capítulo 12: “Administração Avançada”. O Debian também fornece uma ferramenta similar,
cacti. Sua implantação é um pouco mais complexa, pois se baseia apenas em SNMP. Apesar de ter uma interface web, compreender os conceitos envolvidos na configuração ainda requer algum esforço. Lendo a documentação HTML (
/usr/share/doc/cacti/html/index.html
) deve ser considerado um pré-requisito.
14.3.3. Detectando Modificações
Uma vez que o sistema esteja instalado e configurado, e impedindo atualizações de segurança, geralmente não há razão para a maioria dos arquivos e diretórios para evoluirem, exceeto os dados. É interessante, portanto, certificar se que os arquivos realmente não alteram: qualquer mudança seria, portanto, inesperada, valendo a pena investigar. Esta seção apresenta algumas ferramentas capazes de monitorar os arquivos e para avisar o administrador quando ocorrer uma mudança inesperada (ou simplesmente para listar tais mudanças).
14.3.3.1. Auditando Pacotes com o dpkg --verify
dpkg --verify
(or dpkg -V
) is an interesting tool since it allows finding what installed files have been modified (potentially by an attacker), but this should be taken with a grain of salt. To do its job it relies on checksums stored in dpkg's own database which is stored on the hard disk (they can be found in /var/lib/dpkg/info/package.md5sums
); a thorough attacker will therefore update these files so they contain the new checksums for the subverted files.
Running dpkg -V
will verify all installed packages and will print out a line for each file with a failing test. The output format is the same as the one of rpm -V
where each character denotes a test on some specific meta-data. Unfortunately dpkg
does not store the meta-data needed for most tests and will thus output question marks for them. Currently only the checksum test can yield a "5" on the third character (when it fails).
#
dpkg -V
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster
In the sample above, dpkg reports a change to SSH's service file that the administrator made to the packaged file instead of using an appropriate /etc/systemd/system/ssh.service
override (which would be stored below /etc
like any configuration change should be). It also lists multiple configuration files (identified by the "c" letter on the second field) that had been legitimately modified.
14.3.3.2. Auditando Pacotes: debsums
e seus limites
debsums
is the ancestor of dpkg -V
and is thus mostly obsolete. It suffers from the same limitations than dpkg. Fortunately, some of the limitations can be worked-around (whereas dpkg does not offer similar work-arounds).
Since the data on the disk cannot be trusted, debsums
offers to do its checks based on .deb
files instead of relying on dpkg's database. To download trusted .deb
files of all the packages installed, we can rely on APT's authenticated downloads. This operation can be slow and tedious, and should therefore not be considered a proactive technique to be used on a regular basis.
#
apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
#
debsums -p /var/cache/apt/archives --generate=all
Note que este exemplo usa o comando grep status
a partir do pacote dctrl-tools, que não é instalado por padrão.
14.3.3.3. Monitorando Arquivos: AIDE
A ferramenta AIDE (Advanced Intrusion Detection Environment - Ambiente Avançado de Deteccao Intrusao) permite verificar a integridade de arquivos, e detectar qualquer mudança em relacao a uma imagem gravada anteriormente do sistema válido. Esta imagem é armazenada como um banco de dados ( /var/lib/aide/aide.db
) que contém as informações relevantes de todos os arquivos do sistema (impressões digitais, permissões, timestamps e assim por diante). Este banco de dados é inicializado com aideinit
, que é então usado diariamente (pelo script /etc/cron.daily/
) para verificar que nada de relevante mudou. Quando forem detectadas alterações, AIDE grava os em arquivos de log (/var/log/aide/*.log
) e envia os seus resultados ao administrador por e-mail.
Muitas opções em /etc/default/aide
pode ser usadas para ajustar o comportamento do pacote aide. A configuração AIDE adequada é armazenada em /etc/aide/aide.conf
e /etc/aide/aide.conf.d/
(na verdade, esses arquivos são usados update-aide.conf
para gerar /var/lib/aide/aide.conf.autogenerated
). Configuração indica quais propriedades de arquivos precisam ser verificadas. Por exemplo, o conteúdo de arquivos log muda rotineiramente, e estas modificações podem ser ignoradas, desde que as permissões destes arquivos permaneçam o mesmo, mas ambos os conteúdos e as permissões de programas executáveis devem ser constantes. Embora não seja muito complexo, a sintaxe de configuração não é totalmente intuitiva, e a leitura de aide.conf(5) da página do manual é recomendada.
Uma nova versão do banco de dados é gerada diariamente em /var/lib/aide/aide.db.new
, se todas alterações registradas eram legítimas, ele pode ser usado para substituir o banco de dados de referência.
14.3.4. Detectando Intrusoes (IDS/NIDS)
suricata
(in the Debian package of the same name) is a NIDS — a
Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in
/var/log/suricata
. There are third party tools (Kibana/logstash) to better browse all the data collected.
Configuring suricata involves reviewing and editing /etc/suricata/suricata-debian.yaml
, which is very long because each parameter is abundantly commented. A minimal configuration requires describing the range of addresses that the local network covers (HOME_NET
parameter). In practice, this means the set of all potential attack targets. But getting the most of it requires reading it in full and adapting it to the local situation.
On top of this, you should also edit /etc/default/suricata
to define the network interface to monitor and to enable the init script (by setting RUN=yes
). You might also want to set LISTENMODE=pcap
because the default LISTENMODE=nfqueue
requires further configuration to work properly (the netfilter firewall must be configured to pass packets to some user-space queue handled by suricata via the NFQUEUE
target).
To detect bad behaviour, suricata
needs a set of monitoring rules: you can find such rules in the snort-rules-default package. snort
is the historical reference in the IDS ecosystem and suricata
is able to reuse rules written for it. Unfortunately that package is missing from Debian Jessie and should be retrieved from another Debian release like Testing or Unstable.
Alternatively, oinkmaster
(in the package of the same name) can be used to download Snort rulesets from external sources.