Samhain, o guarda eletrônico, irá detectar essas pistas e soar o alarme.

Transcrição

1 CAPA O sistema de detecção de intrusão Samhain Em guarda O Samhain notifica o administrador de tentativas de invasão e até envia arquivos de log para um servidor central. por Tim Schürmann Gary Blakeley, 123RF Grandes empresas não só trancam suas portas à noite, como também contratam um guarda. O guarda faz rondas regulares pelo edifício e soa um alarme caso algo estranha aconteça. Normalmente, não se contratam guardas para vigiar seu computador, mas adota-se o firewall para bloquear as portas, além da esperança de que atualizações regulares acabem com qualquer vulnerabilidade. Os sistemas modernos são complexos e, cada vez mais, invasores encontram portas deixadas entreabertas. Quando um invasor entra em um servidor, tenta se esconder de usuários e administradores, geralmente com a instalação de um rootkit. O rootkit deixará pistas, e o Samhain, o guarda eletrônico, irá detectar essas pistas e soar o alarme. Sniffer O Samhain garante a integridade de um sistema Linux verificando regularmente mudanças em arquivos. Para isso, ele gera um checksum, ou impressão digital, de cada arquivo que monitora. Essa impressão digital muda se o arquivo for manipulado por um malware. O Samhain confere o checksum e outros atributos críticos dos arquivos em intervalos regulares e alerta o administrador caso encontre algo errado. Se necessário, ele também pode monitorar todos os logins e logouts, procurar programas SUID no sistema e vigiar o kernel, atentando para qualquer mudança. O Samhain pode relatar acontecimentos suspeitos para vários alvos; além de manter o clássico arquivo de log, ele o envia a um servidor central de logs ou pode mandá-lo por para o administrador. O Samhain monitora apenas o computador local e funciona como um detector de invasões baseado em máquinas (HIDS host-based intrusion detection system) [1]. Em contraste com as alternativas de IDS baseado em rede (NIDS) [2], o Samhain ignora o tráfego que sai e entra na rede. A ferramenta, portanto, só soa o alarme quando o agressor começa a manipular o sistema. No entanto, isso não significa que o Samhain não seja necessário; se os 39

2 SEGURANÇA Samhain invasores passarem pelo controle de admissão, a única maneira de controlá-los é com um guarda fazendo patrulhas rotineiras. Um HIDS é, portanto, a única maneira de descobrir novas invasões e exploits a partir da rede interna isto é, de pessoas da própria empresa. Como se pode imaginar, criminosos não gostam de sistemas de detecção de intrusão e costumam visá-los em seus ataques. O Samhain usa vários artifícios para se proteger disso. Por exemplo, ele pode esconder seu próprio processo, e só aceita comandos com o uso da senha correta, caso assim seja configurado. Instalação O Samhain é distribuído sob a GPL e está disponível para download no site do projeto [3]. Há pacotes equivalentes nos repositórios da maioria das distribuições, mas não é aconselhável usá-los. Por um lado, esses pacotes geralmente são obsoletos (como no caso do Ubuntu 9.04) e por outro, é difícil ou impossível verificar os fontes e a integridade do programa. Se as instruções forem seguidas, será possível notar que a instalação do Samhain é, em princípio, muito simples. Descompacte o arquivo no disco após o download; isso irá mostrar o pacote com o código-fonte e uma assinatura PGP. Antes de fazer qualquer coisa, convém conferir a assinatura do arquivo: $ gpg --keyserver pgp.mit.edu \ --recv-key 0F571F6C $ gpg --verify \ samhain-<versão>.tar.gz.asc \ samhain-<versão>.tar.gz A assinatura é do autor do Samhain, Rainer Wichmann; a impressão digital também está disponível na página de download [3]. Se tudo estiver correto, basta seguir o procedimento normal (figura 1): $./configure $ make # make install Se for desejável iniciar o Samhain como um daemon na inicialização, o comando: # make install-boot dará conta do recado. Infelizmente, este é só o começo, como revela a documentação do Samhain. Na maioria dos casos, será necessário recompilar o Samhain com diferentes Tabela 1: Parâmetros do configure relevantes para segurança Parâmetro --with-kcheck=/boot/ System.map-$(uname -r) --enable-login-watch --enable-suidcheck --enable-install-name=nome --enable-nocl=abc --enable-micro-stealth=number --enable-stealth=number --enable-khide=/boot/ System.map-$(uname -r) --enable-static Significado Faz o Samhain checar o kernel, assumindo que o arquivo /dev/kmem está acessível. Faz o Samhain checar logins e logouts. Faz o Samhain relatar arquivos cujos SUID e SGID tenham sido alterados recentemente. Renomeia o Samhain para NOME; todos os arquivos e pastas relacionados são, assim, alterados (``/etc/nomerc etc.). O Samhain só executará uma ação se o primeiro argumento da linha de comando for ABC. Por exemplo, samhain ABC -t check inicia uma checagem. Isso impede que outros programas controlem o Samhain remotamente. Strings do código-fonte ficam invisíveis para o comando strings. Isso dificulta um ataque que tente achar o Samhain. number precisa ser um número inteiro entre 127 e 255. Em contraste com --enable-micro-stealth, esta opção altera strings no arquivo de log e no banco de dados do Samhain. Para ver o log, é necessário usar o comando samhain -jl /caminho/do/log less. Ao mesmo tempo, o arquivo de configuração tem que ser esteganograficamente criptografado em uma imagem PostScript. A ferramenta samhain_stealth se encarrega disso. number precisa ser um número inteiro entre 127 e 255. Cria um módulo do kernel que esconde todos os processos e arquivos com uma string samhain. Faz o link estático do binário do Samhain estaticamente. Isso aumenta o arquivo, mas evita que bibliotecas dinâmicas comprometidas afetem o Samhain. 40

3 opções para o comando configure, principalmente se ele for instalado em vários computadores mais uma razão para usar o código fonte e não os pacotes das distribuições. A tabela 1 lista outros parâmetros importantes para o configure. Antes de habilitálos, convém familiarizar-se com o arquivo de configuração. Filtro O Samhain monitora arquivos do sistema Linux e soa um alarme se algo for alterado. No entanto, muitos arquivos mudam com o uso normal. Por exemplo, os arquivos de log aumentam, arquivos temporários aparecem em /tmp/ e usuários trabalhando com seus documentos no OpenOffice.org alteram as horas de alteração de seus arquivos. Se o programa tivesse que relatar todos estes eventos, as invasões se perderiam no meio de uma enxurrada de informações inúteis. Por esse motivo, é uma boa ideia informar ao Samhain quais arquivos devem ser monitorados e quais atividades precisam ser relatadas antes de inicializá-lo. O arquivo de configuração /etc/samhainrc é usado para isso. O modelo padrão parece muito complexo, mas é um bom ponto de partida. Assim como os antigos arquivos.ini (Windows), o arquivo de configuração inclui seções iniciadas com nomes entre colchetes. Cada configuração é um par opção-valor; o programa ignora linhas iniciadas por #. Para começar, defina o destino dos alertas do Samhain. Isso é feito na seção [Log], onde fica a configuração de...severity, com as opções de saída. Por exemplo, LogSeverity armazena mensagens em um arquivo de log, MailSeverity envia um , PrintSeverity imprime a informação no console e SyslogSeverity usa o Syslog. Para habilitar um desses tipos de notificação, basta remover o sinal # Tabela 2: Níveis de severidade (crescente) Nível debug info notice warn mark err crit alert e especificar a severidade que uma mensagem precisa ter para ser considerada importante. Por exemplo, se o seguinte for especificado: LogSeverity=err Significado o arquivo de log irá conter apenas erros, problemas críticos e a desativação do próprio Samhain. A tabela 2 lista os níveis de gravidade e seus conteúdos. Se for necessário receber alertas do Samhain via , será preciso encontrar a seção [Misc] correta Para programadores resolverem problemas Todas as informações Observar Avisos Timestamps Erros Problemas Críticos Erros que terminam o Samhain NOTA: Cada nível inclui todos os níveis subordinados; assim, warn também irá relatar erros. (cuidado: o exemplo de configuração tem múltiplas seções com esse nome) e inserir os dados da listagem 1. Depois, o arquivo de logs será armazenado em /var/log/samhain_log por padrão. É possível definir outro lugar durante a configuração, com a opção --with-log-file=/caminho/ do/arquivo, ou adicionar: SetLogfilePath = /caminho/do /arquivo à seção [Misc]. Listagem 1: Configuração para transmissão de 01 [Misc] 02 # Destinatário: 03 SetMailAdress = nome@exemplo.br 04 # Se necessário, faça relay: 05 SetMailRelay = relay.exemplo.br 06 # Sempre enviar este número de mensagens num único 07 SetMaiNum = # Tempo máximo (em segundos) antes de enviar mensagens: 09 SetMailTime = # Assunto dos s enviados: 11 MailSubject = Subject Listagem 2: Trecho do arquivo de configuração 01 [ReadOnly] 02 dir=/pasta/importante 03 file=/meu/arquivo.txt [GrowingLogFiles] 06 file=/var/logs/um.log 41

4 SEGURANÇA Samhain Políticas O próximo passo é informar ao Samhain como monitorar os arquivos e diretórios alvos. As próximas linhas dizem ao Samhain que o alarme deve ser dado caso alguém tente acessar /meu/arquivo.txt, /pasta/importante ou /var/log/um.log para qualquer outra atividade além de leitura: [ReadOnly] dir=/pasta/importante file=/meu/arquivo.txt file=/var/log/um.log Caminhos absolutos são essenciais. [ReadOnly] avisa ao programa que a única mudança permitida para os arquivos listados é no timestamp do último acesso. No entanto, preste atenção a essa pequena armadilha: os arquivos de log estão sempre crescendo; então, o IDS irá emitir falsos positivos. Por esse motivo, um.log deve ser movido para a seção especial [GrowingLogFiles]. A listagem 2 mostra os resultados. O Samhain chama [ReadOnly] e [GrowingLogFiles] de políticas. A tabela 3 mostra quais outras políticas o IDS conhece. Para evitar que o Samhain vá além de um certo nível de diretórios, adicione esse número ao caminho: dir=3/pasta/importante Para ignorar subdiretórios, é possível estabelecer a profundidade da recursão como -1 na política [IgnoreAll], da seguinte forma: [IgnoreAll] dir=-1/pasta/importante/excluída Como mostrado no início do arquivo de configuração, algumas seções podem aparecer múltiplas vezes. O Samhain irá simplesmente uni-las durante a execução, mas é uma boa ideia manter os diretórios padrão; eles definem regras básicas muito úteis para os arquivos mais importantes de sistemas GNU/Linux. O Samhain é muito meticuloso com relação aos privilégios de acesso a seus arquivos críticos isso se aplica, em particular, ao arquivo de configuração. Apenas o root e as contas de usuários cujos IDs são usados pelo programa possuem permissão de escrita. Se for necessário que qualquer outro usuário modifique a configuração, usuários confiáveis deverão ser configurados. Para isso, especifique o UID com a opção --with-trusted=0,<uid>,<uid>... no comando configure. Para prevenir a manipulação, mantenha os padrões, isto é, conceda privilégios de escrita apenas para o root e execute os comandos também como root. Números Após terminar a configuração, o programa precisará ler os arquivos especificados para o monitoramento, criar um checksum único e tomar nota de outras características dos arquivos. O seguinte comando iniciará o processo: samhain -t init Dependendo do número de arquivos que o Samhain precisar monitorar, esta será uma boa hora para a pausa do café. As informações coletadas pelo programa ficarão armazenadas, por padrão, em um banco de dados localizado em /var/lib/ samhain/samhain_file (figura 2). Se esse arquivo já existir, o Samhain irá acrescentar os dados ao final. Em outras palavras, o comando anterior não deve ser usado para atualizar o banco de dados; outro comando fará isso: samhain -t update Aliás, o Samhain usa o algoritmo TIGER192 para calcular os checksums. As opções alternativas são SHA-1 e MD5; é possível selecioná-los mudando a configuração DigestAlgo no arquivo de configuração. O autor do Samhain aconselha evitar o MD5 devido a possíveis vulnerabilidades. Figura 1 Ao compilar o código-fonte, o configure cria uma chave base que será adicionada a qualquer enviado. É possível usar o comando samhain -M /caminho/do/arquivo para verificar a origem do armazenado. Figura 2 O comando samhain -d /caminho/do/bd lista o conteúdo do banco de dados de assinaturas; o formato da saída é reminiscente do ls -l. 42

5 Quadro 1: O que o Samhain monitora Conteúdo de arquivos (via checksums) Tamanho de arquivos Privilégios de acesso, donos e grupos Timestamps (por exemplo, a data da criação) Número de hardlinks Número de inode Número de dispositivos Nomes de arquivos incomuns ou ocultos Arquivos com bit SUID ou SGID (opcional) Atividade de carregamento do módulo do kernel (opcional) Tentativas de login e logout (opcional) Uma vez que o banco de dados esteja pronto, verifique a integridade do sistema com o comando: samhain -t check Esse comando fará o Samhain verificar o sistema mais uma vez para se certificar de que os checksums e as propriedades dos arquivos combinem com as entradas do banco de dados. Para automatizar essa verificação, inicie o Samhain como daemon. Se o Samhain tiver sido instalado com a opção install-boot, será preciso usar o seguinte comando: samhain -D -t check Figura 3 O Yule gerou a chave 2D1993AF832288D07 e depois a entrada (em destaque) para seu arquivo de configuração. O arquivo de configuração determina o intervalo de verificação do daemon. Esta pode ser uma opção fixa, como em: SetFilecheckTime = seconds ou uma entrada no estilo do crontab: FileCheckScheduleOne = */5 * * * * Como o banco de dados com todos os checksums é a base de todas as comparações futuras, é importante que o sistema GNU/Linux esteja limpo quando o banco de dados for criado. Um guarda não irá perceber uma porta aberta se ela estiver assim desde o início. Portanto, é bom instalar o Samhain antes de conectar o computador à rede. Além disso, certifique-se de que ninguém tenha acesso ao banco de dados. Instale-o em um ambiente write-once ou em um servidor. O servidor pode coletar todos os arquivos de log de todas as instalações do Samhain na LAN e armazenar os arquivos de configuração. O benefício dessa técnica, para o administrador, é a armazenagem centralizada de todos os arquivos críticos, de modo que um malware em um dos clientes não consiga manipulá-los. Mestre... Para configurar uma equipe clienteservidor, é necessário compilar primeiro o programa Yule no servidor. Felizmente, é possível usar o códigofonte do Samhain para isso. Basta especificar o parâmetro de configuração --enable-network=server: $./configure --enable-network=server $ make $ sudo make install Continue com: $ sudo make install-user para corrigir algumas permissões. O servidor de logs yule apenas coleta dados dos clientes e não realiza qualquer verificação de integridade. Antes de iniciar o servidor, é preciso modificar a seção [Log] do arquivo de configuração /etc/yulerc. Ele é, em grande parte, idêntico a seu equivalente do Samhain.... e Serviçais Para as instalações dos clientes Samhain enviarem seus logs para o servidor, será necessário compilar os clientes. O parâmetro de configuração --enable-network=client fará isso: $./configure --enable -network=client \ --with-logserver=server.exemplo.br \ --with-config-file=req_from_server \ --with-data-file=req_fromu_server /var/lib/samhain/samhain_file $ make 43

6 SEGURANÇA Samhain Mas não instale agora ainda é preciso fazer uma certa arrumação. Os parâmetros restantes do configure instruem o Samhain a obter suas configurações e também seu banco de dados de assinaturas a partir do servidor, server.exemplo. br. REQ_FROM_SERVER aponta para o servidor de logs; o caminho em --with-data-file aponta para a máquina local. Isso é necessário, pois o Samhain armazena os resultados da inicialização primeiro em um arquivo (local) esta opção aponta para esse arquivo. Chave Para evitar que um invasor manipule as informações transmitidas e as assinaturas, o cliente e o servidor usam uma conexão segura. Para configurar a conexão, o Samhain necessita de uma autenticação contra o Yule; por isso, o programa precisa de uma senha, que será gerada com o seguinte comando no servidor (figura 3): yule -G Quando a chave for gerada, vá para o cliente e apresente o Samhain para ele: Tabela 3: Políticas pré-definidas Política IgnoreNone ReadOnly LogFiles GrowingLogFiles Attributes IgnoreAll Prelink Significado./samhain_setpwd \ samhain new <senha> O utilitário samhain_setpwd é criado na instalação do Samhain. Ele substitui a senha gerada pelo Samhain pela nova. Na verdade, o samhain_setpwd modifica o programa binário samhain e armazena os resultados em samhain.new. Então, é possível substituir a versão existente por este arquivo: mv samhain.new samhain Após completar todos esses passos, é possível, finalmente, instalar o IDS no cliente: sudo make install e, então, montar o banco de dados de assinaturas: samhain -t init Nenhuma mudança é permitida. Apenas o último horário de acesso tem permissão de mudança. O timestamp, o checksum e o tamanho do arquivo podem mudar. O timestamp e o checksum podem mudar; o arquivo pode aumentar. O Samhain relata mudanças de donos, grupos e permissões. O Samhain verifica apenas se o arquivo existe, ignorando o resto. Semelhante a ReadOnly, mas para programas e bibliotecas que tenham sido modificados com prelink. Depois, será necessário copiar manualmente o arquivo criado (/var/ lib/samhain/samhain_file, caso você tenha seguido os exemplos deste artigo) para /var/lib/yule e renomeá-lo para file.<nome_do_computador>. Por exemplo, se o Samhain for executado em um computador chamado cliente.exemplo.br, seu banco de dados de assinaturas terá o nome file. cliente.exemplo.br. O Yule precisa saber a senha do cliente para poder verificá-lo. O seguinte comando no servidor dá conta disso: yule -P <password> O Yule cria uma string criptografada razoavelmente longa, com credenciais de autenticação completas (como mostrado na figura 3, na linha destacada): Client=HOSTNAME@ @ ABC... Então, adicione esta linha na última seção [Clients] no arquivo de configuração yulerc e substitua a string HOSTNAME com o nome do host do cliente em questão assim: [Clients] Client=client.exemplo.br@ @ ABC... Todos esses passos devem ser reproduzidos nos clientes restantes, caso seja necessário que eles enviem seus dados ao Yule. Por fim, a seção [Clients] do arquivo yulerc precisa de uma entrada para cada cliente do Samhain. Em seguida, o Yule pode ser iniciado como daemon: yule -D Uma alternativa seria usar o comando make install-boot, que também habilita o Yule na inicialização. O Yule, por padrão, faz um log de suas mensagens de erro em /var/ log/yule/yule_log. Além disso, o servidor gera o arquivo yule.html no mesmo diretório. Esse arquivo, atualizado a cada dois minutos, fornece um relatório de status dos clientes conectados. 44

7 Viena chama Quando um cliente do Samhain contacta o Yule, a autenticação é feita pela senha. Após isso, os dois negociam outra chave através de Secure Remote Password (SRP Senha Remota Segura) e usa essa chave para todas as ações posteriores. A troca de dados é, então, criptografada e enviada por TCP. Depois, o Samhain busca seu arquivo de configuração. O Yule espera que ele esteja armazenado como rc.<nome_do_host> em /var/ lib/yule/; ou seja, rc.cliente.exemplo.br, se os exemplos deste artigo forem seguidos. O melhor é usar o exemplo de configuração como ponto de partida. Para instruir o Samhain a enviar os arquivos de log para o servidor, não se esqueça de habilitar ExportSeverity na seção [Log]. Depois de examinar o arquivo de configuração, o Samhain irá procurar o banco de dados de assinaturas no diretório /var/lib/ yule/. Armado com esse banco de dados, ele irá verificar o sistema da forma normal, criar arquivos de log e enviá-los ao Yule. O Yule sempre gravará esses arquivos, independentemente das definições de configuração de filtros em /etc/ yulerc. Para habilitar a filtragem de mensagens recebidas pelo Yule, é possível usar as seguintes linhas na seção [Misc]: UseClientSeverity = yes UseClientClass = yes Informação demais Quando a dupla dinâmica Samhain e Yule estiver em execução, o administrador pode voltar ao seu trabalho normal de verificar e avaliar regularmente os arquivos de log. A única ajuda que o Samhain dará neste ponto é a opção de passar os dados para scripts e programas externos. Caso haja um analisador de arquivos de log para examinálos, seria interessante convertê-los para o formato XML. O parâmetro --enable-xml-log do configure se encarrega disso. Além do mais, o Samhain pode atuar como sensor do IDS Prelude e gravar suas informações em um banco de dados. Para permitir isso, basta compilar o Samhain com as opções --withprelude, --with-database=mysql no configure e habilitá-las no arquivo de configuração. Além do MySQL, o Samhain também é capaz de conversar com PostgreSQL (...=postgresql) e Oracle (...=oracle). Além disso, será necessário habilitar a saída para um banco de dados para usar o Beltane [4], a interface web de gerenciamento do Yule. Disponível em um pacote separado, ele ajuda a visualizar os logs e atualizar o banco de dados de assinaturas. A desvantagem é que a interface do u- suário precisa do obsoleto ambiente PHP4, inaceitável para uma ferramenta de segurança. Para facilitar a avaliação dos arquivos de log, especialmente em ambientes mais complexos, há alguns filtros mais avançados. Por exemplo, Mais informações [1] HIDS na Wikipédia (em inglês): [2] NIDS na Wikipédia (em inglês): detection_system [3] Samhain: [4] Beltane: Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site: é possível especificar que somente eventos especiais serão incluídos no log, tais como mudanças de timestamps ou alguma outra política que seja definida ou modificada. Arquivos de configuração assinados por GnuPG e o banco de dados de assinaturas são uma proteção contra tentativas de manipulação do núcleo do sistema. Antes de fazer a sintonia fina, é interessante ler o manual com atenção. Um pequeno erro de digitação já é suficiente para deixar o Samhain de fora de seu próprio banco de dados de assinaturas ou deixar escapar evidências de invasão devido a filtros muito restritivos. Conclusões O Samhain não é uma panaceia contra ataques, mas é um bom auxílio para o firewall ou para um NIDS em outro local da rede. O servidor de log Yule funciona como um ponto central de coleta na LAN, mantendo tudo organizado. Depois de vencer o complexo processo de configuração e aprender a ler os arquivos de log, será bom ter um guarda atento que detecte visitas não desejadas rápida e silenciosamente. n 45