O exemplo acima ajuda agora a fazer uma revisão de segurança completa do virtualbox. Os binários suid instalados são pontos de entrada óbvios e os serviços em execução são interessantes.

Outro exemplo de execução que detecta corretamente a abertura e fechamento de portas TCP:

./dawgmon -gfA

0 changes detected (0 warnings)

nc -l -p 4455 &

[1] 12489

./dawgmon -gfA

1 change detected (0 warnings)

• port 4455 tcp opened

fg

nc -l -p 4455 ^C

./dawgmon -gfA

1 change detected (0 warnings)

• port 4455 tcp closed

A ferramenta não foi projetada para precisão absoluta. Existem recomendações muito sérias normalmente para não confiar na saída de utilitários do GNU coreutils como ls como entrada da ferramenta. Em outras palavras; raramente se deve construir ferramentas para analisar e confiar neste tipo de saída, pois ela pode mudar o tempo todo. Realisticamente, a saída dessas ferramentas é relativamente estável, já que muitas pessoas e ferramentas automáticas já confiam em suas saídas para todos os tipos de propósitos.

No entanto, o tradeoff para o dawgmon é o seguinte; precisaríamos implementar muita lógica para fazer monitoramento do sistema de arquivos por conta própria, construir binários complexos que incluam bibliotecas para fazer a análise e monitoramento de dispositivos de bloco, interfaces de rede e muito mais. Isso também tornaria a ferramenta muito mais complexa e menos sustentável. Em projetos atuais, pode-se adicionar um novo comando incluindo detecção de mudanças em muito pouco tempo, pois a ferramenta principal dawgmon já cuida do cache, execução do comando e, em seguida, fornecimento da saída anterior e atual ao executar uma comparação com uma implementação de comando. Isso significa que em projetos com restrições de tempo, pode-se adicionar rapidamente um novo comando e executar análises incluindo esses novos comandos.

Um comando pode ser adicionado simplesmente herdando da classe Command. Esta classe está definida em commands/init.py. Esse arquivo contém também a lista mestre de comandos (e a ordem em que são executados ao fazer uma análise completa). Em seguida, as propriedades como 'name', 'shell', 'command' e 'desc' terão que ser definidas e dois métodos 'parse()' e 'compare()' terão que ser implementados. Comandos suficientes estão incluídos para ter uma boa ideia de como implementar e adicionar novos.

USO

Para melhores resultados, execute a ferramenta como root. Para ajuda, digite -h/--help e para informações de versão, digite -v/--version.

Uma ação principal sempre terá que ser especificada. Essas ações são: -A: analisar o sistema -C: comparar entradas de cache -E: listar comandos disponíveis -L: listar entradas de cache

executa uma análise

dawgmon -A

executa uma análise mas apenas com alguns comandos

dawgmon -A -e list_suids -e list_tcpudp_ports

mostra a lista de comandos disponíveis

dawgmon -E

mostra as entradas de cache disponíveis para comparação

dawgmon -L

compara a entrada de cache antiga 3 com a nova entrada de cache 5

dawgmon -C 3 5

Opções adicionais para ajudar na análise são:

-d: mostrar saída de depuração -e: executar um comando específico (pode ser usado várias vezes) -f: forçar a execução sem avisar sobre execução como root -g: colorir a saída -l: localização do banco de dados de cache a ser usado -m: quantidade máxima de entradas de cache permitidas no cache (se o cache tiver mais entradas do que essa quantidade, truncará o banco de dados) -t: não exibir informações de timestamp por anomalia detectada.

Para mais informações de uso, execute a ferramenta com -h.

LIMITAÇÕES

A ferramenta analisa a saída de ferramentas de linha de comando e depende de opções específicas do GNU coreutils para parte disso. Não há razão específica pela qual esta ferramenta e as implementações de comando não possam ser rapidamente portadas para outros sistemas operacionais como os BSDs, mas atualmente não está ocorrendo detecção de Sistema Operacional nem está sendo feita uma classificação de comandos com base no suporte do Sistema Operacional. Isso teria que ser implementado primeiro.

Em relação à descoberta de pipes, sockets UNIX, arquivos em /boot, /etc e mais, deve-se notar que o uso de -xdev passado para 'find' significa que nem todos os sistemas de arquivos montados sob o diretório inicial serão percorridos. Isso significa que, por exemplo, /boot será escaneado adequadamente, mas /boot/efi pode não ser. Uma abordagem mais inteligente terá que ser usada aqui no futuro.

Os timestamps ao fazer uma análise atual podem ser um pouco confusos. Por padrão, um timestamp para uma mensagem de anomalia de aviso, normal ou depuração será o timestamp do momento de sua geração (como pode ser visto em commands/init.py). As anomalias são geradas após uma varredura completa da linha de comando ter sido feita. Portanto, a saída sobre a qual essa detecção funciona foi gerada anteriormente e, subsequentemente, os timestamps para anomalias individuais mostram um tempo após o tempo da varredura. Ao comparar entradas de cache, o timestamp da varredura está sendo usado para exibir o momento em que a detecção ocorreu, pois isso faz logicamente mais sentido.

SOBRE

Todos os direitos reservados. Copyright (C) 2017-2019 por Anvil Ventures Inc. Para informações de licenciamento, veja LICENSE. Para mais informações, entre em contato com Vincent Berg [email protected]

Para encontrar o código fonte atualizado ou contribuir com patches, acesse a seguinte URL: https://github.com/anvilventures/dawgmon/