Product SiteDocumentation Site

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

14.3.2.1. Em Tempo Real

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.
When the system seems to be overloaded, top is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.
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.

14.3.2.2. História

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.
This book deals with Munin in some detail (see Seção 12.4.1, “Configurando o Munin”) as part of Capítulo 12: “Administração Avançada. Debian also provides a similar tool, cacti. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (/usr/share/doc/cacti/html/Table-of-Contents.html) should be considered a prerequisite.

14.3.3. Avoiding Intrusion

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 in to an unauthorised software system by performing multiple login attempts in a short period of time.
The best way to stop a brute-force atack 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 attemps 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. Global configuration (such as logging).
  • filter.d/*.conf. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.
  • action.d/*.conf. Actions defining the commands for banning and unbanning of IP addresses.
  • jail.conf. It is where jails, the combinations of filters and actions, are defined.
Let us have a look at the configuration of sshd in /etc/fail2ban/jail.conf to better understand how Fail2Ban works...
[...]
[DEFAULT]
[...]
bantime  = 10m
[...]
maxretry = 5
[...]
[sshd]
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban will check for failed login attepts for sshd using Python regular expressions defined in /etc/fail2ban/filters.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 in a row, it will ban the IP address where those attempts originated.
Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.
A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.

14.3.4. Detectando Modificações

Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).

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
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 (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 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 purpuse 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 Deteccã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.
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 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.
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 (configurando RUN=yes). Você também pode 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).
To detect bad behavior, 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.
Alternativamente, o oinkmaster (no pacote de mesmo nome) pode ser usado para baixar um conjunto de regras do Snort a partir de fontes externas.