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
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 é uma suíte de software de prevenção de intrusão que pode ser configurada para monitorar qualquer serviço que escreva tentativas acesso em um arquivo de log. Ele pode ser encontrado no pacote 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. 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. Ações que definem os comandos para banir ou desfazer o banimento de endereços IP.
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 verificará por tentativas de acesso que falharam no sshd comparando expressões regulares Python definidas em /etc/fail2ban/filter.d/sshd.conf com o arquivo de log do sshd, que é definido na variável sshd_log no arquivo /etc/fail2ban/paths_common.conf. Se o Fail2Ban detectar cinco tentativas de acesso seguidas que falharam, ele banirá o endereço IP de onde se originaram essas tentativas por 10 minutos.
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.
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
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 (no pacote Debian de 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 outras ferramentas (Kibana/logstash) para melhor navegar pelos dados coletados.
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.
Além disso, você também deve editá-lo para definir a interface da rede. Você também pode querer definir LISTENMODE=pcap porque o LISTENMODE=nfqueue padrão requer configuração adicional para funcionar corretamente (o firewall netfilter deve ser configurado para passar pacotes para alguma fila de espaço do usuário manipulada por suricata por meio do destino NFQUEUE).
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.
