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.
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 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, 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
Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log into an unauthorized software system by performing multiple login attempts in a short period of time.
The best way to stop a brute-force attack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.
Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attempts to a log file. It can be found in the package fail2ban.
Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /etc/fail2ban/:
fail2ban.conf. Configuração global (log, por exemplo).
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. Actions defining the commands for banning and “unbanning“ of IP addresses.
jail.conf. Local onde os jails, as combinações de filtros e ações são definidas.
Vamos dar uma olhada na configuração do sshd em /etc/fail2ban/jail.conf para melhor entendimento de como Fail2Ban funciona...
[...]
[DEFAULT]
[...]
bantime = 10m
[...]
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 10 minutes.
To enable, disable, or configure “jails“, the main configuration file /etc/fail2ban/jail.conf is not supposed to be altered. Instead this is supposed to be done in /etc/fail2ban/jail.d/defaults-debian.conf or files within the same directory.
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.
Uma boa maneira de fornecer proteção extra contra ataques de força bruta distribuídos é aumentar artificialmente o tempo de login após cada tentativa de falha.
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
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
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.d/override.conf 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.4.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 workarounds).
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 can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpose or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /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 an 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.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 it to define the network interface. 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).
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.
Alternatively, oinkmaster (in the package of the same name) can be used to download Snort rule sets from external sources.
