Active Directory e Exchange Server
Neste artigo, abordamos como sistemas Microsoft podem funcionar com autênticas testemunhas, delatando atividades de usuários envolvendo sistema, acesso a objetos e manipulação de aplicativos. Evidentemente que não esgotamos o assunto, e nos limitamos a apresentar o funcionamento dos logs em sistemas Home Edition. Pela lógica, Servers serão capazes de processar e armazenar uma infinidade de logs, como Active Directory, Microsoft Exchange, etc.
O Active Directory é uma implementação de serviços de diretório Microsoft, concorrente do Samba, cujos arquivos de logs, por padrão, ficam armazenados em C:\Windows\NTDS, sendo eles
- Ntds.dit
- Edb*.log
- Edb.chk
- Res1.log
- Res2.log
O AD registra eventos para o gerenciador de logs "Event Viewer Directory Services". Pode-se também alterar o local de armazenamento dos logs na seguinte chave existente no Registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Diagnostics.
Já no Exchange Server 2007, podemos alterar o Storage onde os logs são gerados, em "Exchange Managment Console", podemos verificar o LogPath dos Arquivos de Logs (http://www.andersonpatricio.org/Tutoriais/Tutoriais.asp?tut=871).
Arquivos de logs do Exchange Server 2007: Extraída do Site do Consultor Anderson Patrício.
O Exchange 2003 permite a visualização de seus logs no "Event Viewer" onde é possível filtrar, dentre logs de Aplicação e Logs de Sistema, por atos específicos, como por exemplo, a gravação de todas as atividades SMTP (porta 25 - http://exchangepedia.com/blog/2007/05/exchange-server-2007-logging-smtp.html).
Em síntese, não é objetivo deste artigo analisar os logs de serviços específicos, como de Servidores Exchange ou Active Directory, mas demonstrar como se dá a habilitação, monitoramento e preservação de logs em ambientes Windows convencionais.
Habilitando os logs no Windows
Como peritos, lamentavelmente encontraremos máquinas comprometidas ou utilizadas para transações fraudulentas sem qualquer configuração de logs habilitada. Entretanto se bem configurados, os serviços de log tem muito a nos dizer. Inicialmente, deve-se informar ao sistema o interesse em auditar determinados eventos da máquina.
Em Ferramentas Administrativas, no Painel de Controle, clicamos no ícone Diretiva de Segurança Local. Na janela que surgir, disciplinamos os eventos que queremos auditar, e ainda em qual modalidade, ou seja, sucesso ou falha:
Tela Diretivas de Auditoria, onde selecionamos a Auditoria de Acesso a Objetos.
No nosso exemplo, selecionamos somente a Auditoria a objetos, que registra os acessos e modificações realizadas pelo usuário em um objeto como, por exemplo, uma impressora, uma pasta, arquivo, chave.reg, etc.
Tal informação pode ser determinante em uma perícia, quando o escopo é saber quem criou ou excluiu arquivos em um disco rígido, quem obteve acesso, ou até mesmo quem utilizou determinado dispositivo de armazenamento e impressora.
Escolhendo o que será auditado
Na Etapa anterior, apenas informamos ao sistema que desejamos a Auditoria de Acesso a Objetos. Porém, nossas atuações no sistema ainda não estão sendo fiscalizadas, é preciso que especifiquemos qual unidade ou dispositivo desejamos auditar.
Podemos então clicar com o botão direito em qualquer dispositivo ou pasta. Na janela que surgir, clicamos da guia Segurança e após em Avançado. Na janela que aparecer, clicamos na aba Auditoria e lá iremos definir as configurações sobre "quem" e "quais atividades deste alguém" queremos auditar:
Aba \"Auditoria\", podemos definir entradas com perfis de auditoria diferenciados.
Deve-se destacar que se existir algum registro em "Entradas de Auditoria", isto significa que algum objeto pai está sendo auditado, como por exemplo um disco rígido, no qual a pasta que queremos definir auditoria foi criada. Isso não impede porém que criemos uma modalidade de autoria específica para o objeto filho, basta desmarcarmos a opção da herança, "Herdar do pai as entradas de auditoria aplicáveis a objeto filho. Incluí-las nas entradas explicitamente definidas aqui".
No nosso exemplo, criamos uma pasta "Arquivos" na raiz, e pretendemos auditar as alterações e exclusões de arquivos desta pasta, realizadas pelos usuários com poderes de Administração:
Definimos que iremos auditar apenas os administradores do Sistema.
Clicando em "Ok" na aba "Auditoria", finalizamos o processo de criação registros para atividades consideradas sensíveis na Política de Segurança da Empresa.
Em tal configuração, nos interessa conhecer arquivos criados, desviados ou excluídos pelos administradores.
Rastro das atividades: criação e exclusão de arquivo
Nesta etapa, efetivamente vamos praticar ações dentro da pasta "Arquivos", que está sendo auditada pelo sistema. Neste cenário poderemos verificar como a auditoria se comporta diante destas ações. Para esta análise vamos utilizar o utilitário "Visualizar Eventos", disponível em "Ferramentas Administrativas" no Painel de Controles.
Em nosso exemplo, apenas os Eventos de Segurança serão loggados. Antes de iniciarmos, iremos nos certificar de que não existem registros de logs lançados no sistema. Ao clicar com o botão direito sobre a opção "Segurança" podemos limpar os logs existentes.
Eventos de Segurança antes da Prática de Atividades na pasta Arquivos.
Agora na pasta "Arquivos", existente na raiz do computador, vamos criar um arquivo (.doc), denominado milagre.doc. Após vamos observar o Visualizar Eventos:
Logs registrados quando da criação de um arquivo.
Como pudemos constatar, no mínimo 9 (nove) registros de logs são criados pelo sistema no simples ato de se criar um arquivo e o renomeá-lo para "milagre.doc". Interessante notar que a função DELETE é interna ao Windows até mesmo quando o comando disparado é o simples "renomear". Percebe-se também logs onde há chamada ao arquivo explorer.exe, responsável por processar os comandos emitidos pelo usuário.
Agora simulamos uma outra situação, onde por exemplo o fraudador poderia sobrescrever o arquivo real por um arquivo com "wipe" ou com um rootkit. Nesta simulação, copiamos o arquivo falso "milagre.doc" de um outro local do sistema, para a pasta "Arquivos", e o seguinte Log de Sistema é gerado:
Log nos mostra de onde o arquivo falso se originou, o que pode ser útil na análise de tentativas de \"queima de arquivo\" ou técnicas anti-forensics.
Nos resta, então, analisar as hipóteses onde o usuário exclui definitivamente um arquivo. Ao executarmos o a exclusão do arquivo "milagre.doc", na pasta "Arquivos", previamente configurada para ser auditada, visualizamos a geração dos seguintes registros de logs:
Logs gerados quando da exclusão de um arquivo definitivamente.
Interessante é que quando teclamos SHIFT+DEL sobre um arquivo e confirmamos a exclusão, efetivamente não temos noção do processo instaurado junto ao sistema operacional para que o arquivo realmente desapareça do sistema de arquivos.
São 4 (quatro) passos para a exclusão de um arquivo, passos estes que ocorrem no mesmo segundo (01:06:36 hs), sendo:
- Evento 560: O objeto milagre.doc é aberto com a instrução "delete" que é processada pelo Windows
- Evento 567: A instrução "delete" é passada ao Explorer.exe, fazendo gerar um log de acesso ao arquivo "kernel" do Windows.
- Evento 564: O Explorer então exclui o objeto "milagre.doc", gerando um ID identificador da tarefa e um ID identificador do processo de exclusão.
- Evento 562: O Explorer finaliza a tarefa acionada pelo evento 560.
Tudo isso na mesma fração de segundo!
Em síntese pudemos, com o presente trabalho, identificar as ações de um usuário determinado, inclusive a ação de exclusão de um arquivo, que nos gerou o seguinte registro, válido e registrado:
Ocultando as testemunhas: servidor remoto de logs
A máxima valoração da prova é um dos escopos do Perito Computacional, e neste cenário, deve-se ter em mente que o "evidential value" de logs computacionais podem ser máximos ou mínimos, sendo que tudo dependerá da forma em que eram custodiados, bem como da capacidade de se averiguar procedimentos de gestão que garantam autenticidade e integridade dos registros eletrônicos.
Neste contexto, instalações "default" de sistemas de logs ou livre acesso aos arquivos por outros usuários, são quesitos que são observados pelo judiciário e empresas, estes, pesando para que as provas obtidas pela análise dos logs se fragilizem.
Assim, a criação de um "servidor de logs remoto" é boa prática que atende os quesitos da IS0-IEC 27002, bem como favorece a atividade pericial. Todos os registros de logs da ferramenta "Event Viwer", são salvos em 3 (três) arquivos: SysEvent.evt, AppEvent.evt, SecEvent.evt.
Por padrão, não existe opção "amigável" para alterar os locais onde estes arquivos são armazenados, o que favorece aos crackers a queima de evidências, na maioria dos sistemas existentes. A solução é alterar via Registro do Windows: Iniciar - Executar - Regedit.
Em System\CurrentControlSet\Services\EventLog\, é possível verificar os Diretórios envolvendo os logs de Aplicação, Segurança e Sistema. Ao Acessar os diretórios, basta alterar no painel da direita o valor File, como o endereço ou nome de rede para onde deseja armazenar os arquivos de log:
Valor \"File\" do Application Log, indicando onde os arquivos de log eram armazenados: %SystemRoot%\system32|config\AppEvent.Evt.
Conclusões
Destaca-se que ambientes Windows também são capazes de gerar registro de atividades, no entanto, o perito deve atentar para indícios de finalização de auditoria e principalmente, observar os detalhes da máquina que está sob sua análise:
Registro de Evento de Segurança que informa que os serviços de Logging foram desativados.
Em conclusão, a prática demonstra que servidores de Logs remotos e com autenticação controlada proporcionam provas robustas e com maior susceptibilidade de serem aceitas e consideradas em um processo cível ou criminal.
Autor: José Milagre
Data: 10/10/2008
José Milagre é Advogado, Analista Programador, Perito Computacional, Coordenador do Instituto Tele Direito, Especialista em Direito Eletrônico pelo IPEC/SP, LLM em Direito Penal e Processo Penal pela Faculdade Fênix/SP, Presidente da Comissão de Propriedade Intelectual e Segurança da Informação da OAB/SP 21ª Subsecção, Vice-Presidente de Associação Brasileira de Forense Computacional, Professor de Forensics e Direito da Informática.
Blog: http://josemilagre.blogspot.com/
Postagens
