14.3. Supervisão: Prevenção, Detecção, Desencorajamento
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.
The list of monitored files is stored in /etc/logcheck/logcheck.logfiles and /etc/logcheck/logcheck.logfiles.d/; the default values work fine with systemd and rsyslog if their configuration files have not been completely overhauled.
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 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.
The gnome-system-monitor graphical tool is similar to top and it provides roughly the same features. Alternatives are atop and htop, which provide similar functionality, but differ in usability features, like the scrolling ability.
Processor load, memory usage, network traffic and free disk space are information that are constantly varying. Keeping a history of their evolution is often useful in determining exactly how the computer is used.
There are many dedicated tools for this task. The sysstat package, for example, collects and displays system performance statistics locally. The data can then be visualized with the sar command. Most tools, though, can fetch data via SNMP (Simple Network Management Protocol) in order to centralize this information. An added benefit is that this allows fetching data from network elements that may not be general-purpose computers, such as dedicated network routers or 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, a compreensão dos conceitos envolvidos na configuração ainda requer algum esforço. A leitura da documentação HTML (
/usr/share/doc/cacti/html/Table-of-Contents.html) deve ser considerada um pré-requisito.
14.3.3. Evitando intrusões
Atacantes tentam obter acesso a servidores ao adivinhar senhas, por isso senhas fortes sempre devem ser usadas. E mesmo assim, você também deve estabelecer medidas contra ataques de força bruta. Um ataque de força bruta é uma tentativa de autenticação em um sistema de software não autorizado realizando múltiplas tentativas de acesso em um curto período de tempo.
A melhor maneira de parar um ataque de força bruta é limitar o número de tentativas de acesso vindo de uma mesma origem, geralmente banindo temporariamente um endereço IP.
Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attempts to a log file or the system journal. It can be found in the package fail2ban.
Fail2Ban é configurado através de um protocolo simples pelo fail2ban-client, que também lê arquivos de configuração e emite comandos de configuração correspondentes para o servidor, fail2ban-server. Possui quatro tipos de arquivos de configuração, todos armazenados em /etc/fail2ban/:
fail2ban.conf and fail2ban.d/*.conf. Global configuration (such as logging).
filter.d/*.conf. Filtros que especificam como detectar falhas de autenticação. O pacote Debian já contém filtros para muitos programas comuns.
action.d/*.conf. Ações que definem os comandos para banir ou desfazer o banimento de endereços IP.
jail.conf and jail.d/*.conf. It is where jails, the combinations of filters and actions, are defined.
Vamos dar uma olhada na configuração do sshd em /etc/fail2ban/jail.conf para melhor entendimento de como Fail2Ban funciona...
[...]
[DEFAULT]
[...]
bantime = 1h
[...]
findtime = 10m
[...]
maxretry = 5
[...]
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban will check for failed login attempts for sshd using Python regular expressions defined in /etc/fail2ban/filter.d/sshd.conf against the log file of sshd, which is defined in the variable sshd_log in the file /etc/fail2ban/paths-common.conf. If Fail2Ban detects five failed login attempts within 10 minutes, it will ban the IP address where those attempts originated for 1 hour.
The default backend used now is systemd. The old log files, like auth.log are only available if rsyslog has been installed and enabled.
Para habilitar, desabilitar ou configurar “prisões“, o arquivo de configuração principal /etc/fail2ban/jail.conf não deve ser alterado. Em vez disso, deve ser feito em /etc/fail2ban/jail.d/defaults-debian.conf ou arquivos dentro do mesmo diretório.
If docker containers are involved, the rules injected into iptables by fail2ban to block traffic from specific IPs must be applied to the right chain by chain = DOCKER-USER. Otherwise, the ban will not work.
Fail2Ban é uma maneira muito simples e eficaz de proteger contra a maioria dos ataques de força bruta mais comuns, mas não pode proteger contra ataques de força bruta distribuídos, que ocorre quando um invasor usa um grande número de máquinas espalhadas pela Internet.
A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt. It is also possible to increase the block time with each ban for the same IP.
14.3.4. 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 evoluírem, exceto os dados. É interessante, portanto, certificar-se de que os arquivos realmente não alteram: qualquer mudança seria assim inesperada, valendo a pena investigar. Esta seção apresenta algumas ferramentas capazes de monitorar os arquivos e para avisar o(a) administrador(a) quando ocorrer uma mudança inesperada (ou simplesmente para listar tais mudanças).
14.3.4.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. The same is true for debsums.
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?????? c /etc/logcheck/logcheck.logfiles.d/syslog.logfiles
??5?????? c /etc/logrotate.d/apt
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/systemd/journald.conf
??5?????? c /etc/lvm/lvm.conf
No exemplo acima, o dpkg reporta uma alteração no arquivo service do SSH que o administrador fez no arquivo empacotado ao invés de usar uma sobrescrita apropriada no /etc/systemd/system/ssh.service.d/override.conf (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.4.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 (enquanto 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és 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 autenticados 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 do pacote dctrl-tools, que não é instalado por padrão.
debsums pode ser executado frequentemente como uma configuração cronjob CRON_CHECK em /etc/default/debsums. Para ignorar certos arquivos fora do diretório /etc, os quais foram alterados de propósito ou espera-se que sejam alterados (como /usr/share/misc/pci.ids), você pode adicioná-los ao /etc/debsums-ignore.
14.3.4.3. Monitorando Arquivos: AIDE
A ferramenta AIDE (Advanced Intrusion Detection Environment - Ambiente Avançado de Detecção de Intrusão) permite verificar a integridade de arquivos, e detectar qualquer mudança em relação 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 alterações são detectadas, AIDE grava 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 podem 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 apenas pelo update-aide.conf para gerar /var/lib/aide/aide.conf.autogenerated). A configuração indica quais propriedades de quais 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 as mesmas, mas tanto o conteúdo quanto as permissões de programas executáveis devem ser constantes. Embora não seja muito complexa, a sintaxe de configuração não é totalmente intuitiva, e a leitura da página de manual aide.conf(5) é recomendada.
Uma nova versão do banco de dados é gerada diariamente em /var/lib/aide/aide.db.new; se todas as alterações registradas eram legítimas, ele pode ser usado para substituir o banco de dados de referência.
14.3.5. Detectando Intrusões (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. The tool can be considered the successor of
snort, which has been removed from Debian.
A configuração do suricata envolve rever e editar o /etc/suricata/suricata.yaml, que é muito grande porque cada parâmetro é abundantemente comentado. Uma configuração mínima 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.
On top of this, you should also edit to define the network interface. You might also want to set LISTENMODE=pcap in /etc/default/suricata 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).
Para detectar mau comportamento, suricata precisa de um conjunto de regras de monitoramento: você pode encontrar essas regras no pacote snort-rules-default. O snort é a referência histórica no ecossistema IDS e suricata é capaz de reutilizar regras escritas para ele.
Alternativamente, o oinkmaster (no pacote de mesmo nome) pode ser usado para baixar um conjunto de regras do Snort a partir de fontes externas.
Unfortunately, the mentioned packages are not part of the current Debian
Bookworm release. But they can still be retrieved via the Debian package search or from the Debian snapshot archive.
