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) entregue(s). A atividade de monitoramento pode ajudar a detectar tentativas de invasão e permitir uma reação rápida antes que elas 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 mais suscinto (filtra ainda mais mensagens).
Nos três casos, o 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 leitura necessária - quiçá desafiadora.
As regras aplicadas podem ser divididas em vários tipos:
aquelas que qualificam uma mensagem como uma tentativa de invasão (armazenada em um arquivo no diretório /etc/logcheck/cracking.d/);
aquelas cancelando essas qualificações (/etc/logcheck/cracking.ignore.d/);
aquelas classificando uma mensagem como um alerta de segurança (/etc/logcheck/violations.d/);
aquelas cancelando esta classificação (/etc/logcheck/violations.ignore.d/);
e 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 diretórios /etc/logcheck/ignore.d.{paranoid,server,workstation}/ indique que o evento deve ser ignorado. Naturalmente, os únicos diretórios levados em consideração são aqueles que correspondem aos níveis de verbosidade iguais ou maiores que o modo de funcionamento selecionado.
14.3.2. Monitorando Atividades
top é uma ferramenta interativa que exibe uma lista de processos em execução. A ordem padrão baseia-se na quantidade atual de utilização do processador e pode ser obtida com a tecla P. Outras ordenações incluem ordenar por 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. A tecla r permite fazer renice num 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 processos que consomem recursos 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 de 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 suas necessidades e hábitos pessoais.
A ferramenta gráfica 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, o
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. A leitura da documentação HTML (
/usr/share/doc/cacti/html/index.html) deve ser considerada 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 evoluirem, exceto 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
O dpkg --verify (ou dpkg -V) é uma ferramenta interessante já que permite encontrar quais arquivos instalados foram modificados (potencialmente por um invasor), mas isso é apenas um pequeno passo. Para fazer seu trabalho ele confia nos checksums armazenados no próprio banco de dados do dpkg, que é armazenado no disco rígido (eles podem ser encontrados em /var/lib/dpkg/info/pacote.md5sums); Um atacante que faz o serviço bem feito irá atualizar esses arquivos para que eles contenham os novos checksums dos arquivos subvertidos.
Ao rodar dpkg -V todos os pacotes instalados serão verificados e será impressa uma linha para cada arquivo que falhar em algum teste. O formato de saída é o mesmo que o do rpm -V onde cada caractere denota um teste em algum metadado específico. Infelizmente o dpkg não armazena o metadado necessário para a maioria dos testes e irá, assim, exibir uma interrogação para estes. Atualmente apenas o teste de checksum pode render um "5" no terceiro caractere (quando ele falha).
# 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
No exemplo acima, o dpkg reporta uma alteração no arquivo service do SSH que o administrador fez no arquivo empacotado ao invéz de usar uma sobrescrita apropriada no /etc/systemd/system/ssh.service (que seria armazenada abaixo de /etc como qualquer mudança de configuração deveria ser). Ele também lista múltiplos arquivos de configuração (identificados pela letra "c" no segundo campo) que foram legitimamente modificados.
14.3.3.2. Auditando Pacotes: debsums e seus limites
O debsums é o ancestral do dpkg -V e sendo assim é praticamente obsoleto. Ele sofre das mesmas limitações que o dpkg. Felizmente, algumas das limitações podem ser superadas (enqunato que o dpkg não oferece tais ações).
Já que dados no disco não são confiáveis, o debsums oferece fazer sua checagem com base nos arquivos .deb ao invéz de confiar no banco de dados do dpkg. Para baixar arquivos .deb confiáveis de todos os pacotes instalados, nós podemos confiar nos downloads autênticados pelo APT. Essa operação pode ser lenta e tediosa, e deve assim, não ser considerada uma técnica proativa a ser usada no cotidiano.
# 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 (no pacote Debian com o mesmo nome) é um NIDS - um
Sistema de Detecção de Intrusão de Rede. Sua função é ouvir a rede e tentar detectar tentativas de infiltração e/ou atos hostis (incluindo ataques de negação de serviço). Todos esses eventos são registrados em múltiplos arquivos em
/var/log/suricata. Existem ferramentas de terceiros (Kibana/logstash) para melhor navegar pelos dados coletados.
A configuração do suricata envolve rever e editar o /etc/suricata/suricata-debian.yaml, que é muito grande porque cada parâmetro é abundantemente comentado. Uma configuração minima requer descrever o intervalo de endereços que a rede local cobre (parâmetro HOME_NET). Na prática, isso significa o conjunto de todos os alvos possíveis de ataque. Mas para obter o máximo dele requer uma leitura completa para adaptá-lo para a situação local.
No topo disso, você deveria também editar o /etc/default/suricata para definir a interface de rede a ser monitorada e para habilitar o script init (setando RUN=yes). Você também deve querer definir LISTENMODE=pcap porquê o padrão LISTENMODE=nfqueue requer configurações adicionais para funcionar de maneira apropriada (o firewall netfilter tem que ser configurado para passar pacotes para alguma fila do espaço de usuário manipulada pelo suricata via o alvo NFQUEUE).
Para detectar maus comportamentos, o suricata precisa de um conjunto de regras de monitoramento: você pode encontrar tais regras no pacote snort-rules-default. O snort é a referência histórica no ecosistema de IDS e o suricata é capaz de reusar as regras escritas para ele. Infelizmente, esse pacote não está presente no Debian Jessie e deve ser obtido a partir de outro lançamento Debian como o Testing ou Unstable.
Alternativamente, o oinkmaster (em pacote de mesmo nome) pode ser usado para baixar um conjunto de regras do Snort a partir de fontes externas.
