Auditoria e detecção de invasões Windows

Capítulo 9 - Auditoria e detecção de invasões Página 1 de 25
Capítulo 9 - Auditoria e detecção de invasões

Este material é parte integrante do Securing Windows 2000 Server Solution e o material original, com todos os capítulos
em inglês, pode ser encontrado em http://www.microsoft.com/technet/security/prodtech/windows/secwin2k/default.asp.
Em qualquer ambiente seguro, é necessário monitorar continuamente as invasões e os ataques. Seria contraproducente
implementar sistemas seguros e não executar auditorias, pressupondo que os ataques não ocorrerão.
Há vários motivos pelos quais o monitoramento e a auditoria de invasões são muito importantes. Entre eles estão:
z Qualquer ambiente computacional funcional está potencialmente aberto a ataques. Independentemente do nível
de segurança estabelecido, sempre existe o risco de um ataque.
z Com freqüência, os ataques bem-sucedidos são posteriores a uma série de fracassos. Para detectar os ataques e
tentar impedi-los, é necessário fazer o monitoramento.
z Quanto mais cedo um ataque for descoberto, mais fácil será evitar danos.
z Para se recuperar de um ataque, você precisa identificar os danos.
z A auditoria e a detecção de invasões ajudam a determinar quem foi responsável pelo ataque.
z A combinação de auditoria e detecção de invasões ajuda a correlacionar informações para identificar padrões de
ataques.
z A revisão regular dos logs de segurança ajuda a identificar problemas de configuração ignorados, como
permissões incorretas ou configurações imprecisas para bloqueio de contas.
z Depois que um ataque é detectado, a auditoria pode ajudar a determinar quais recursos de rede estão
comprometidos.
Este capítulo mostra como fazer auditoria do ambiente para ter o máximo de chances de identificar e rastrear um ataque.
Além disso, analisa o monitoramento de invasões - incluindo o uso de sistemas de detecção de invasões, softwares
projetados especificamente para identificar comportamentos que indicam um ataque em andamento.
Auditoria
Como parte da estratégia de segurança geral, você deve determinar o nível de auditoria apropriado para o ambiente. A
auditoria deve identificar ataques, com êxito ou com falha, que representem uma ameaça para a rede ou que estejam
voltados para recursos que você considerou valiosos em sua avaliação de riscos.
Ao decidir os critérios da auditoria, tenha em mente que, quanto mais detalhada for a auditoria, mais eventos serão
gerados e aumentará a dificuldade para identificar os eventos críticos. Se você optar por auditorias abrangentes,
considere usar ferramentas adicionais, como o Microsoft(r) Operations Manager (MOM), para ajudar a filtrar os eventos
mais importantes.
Os eventos de auditoria podem ser divididos em duas categorias: eventos com êxito e eventos com falha. Um evento com
êxito indica que um usuário conseguiu obter o acesso a um recurso; um evento com falha indica que o usuário tentou,
mas fracassou.
Os eventos com falha são muito úteis para rastrear tentativas de ataques no ambiente, mas a interpretação dos eventos
com êxito é muito mais difícil. Embora a grande maioria dos eventos de auditoria com êxito sejam simplesmente
indicações de atividade normal, um atacante que consegue obter acesso a um sistema também gerará um evento com
êxito. Com freqüência, um padrão de eventos é tão importante quanto os eventos em si. Por exemplo, uma série de falhas
seguidas por um êxito pode indicar uma tentativa de ataque que, por fim, teve êxito.
Sempre que possível, você deve associar os eventos de auditoria às outras informações que possui sobre os usuários. Por
exemplo, se usuários tirarem férias, você pode optar por desativar suas contas enquanto estiverem ausente e auditá-las
quando forem reativadas.
Como ativar a auditoria

A auditoria é ativada usando a diretiva de grupo, que pode ser aplicada no site, no domínio, na unidade organizacional
(UO) ou no computador local. As configurações de diretivas de auditoria estão disponíveis em:
file://C:\Sndbox\carol\batch08\09detect_170856\09DETECT.htm 29/05/03
Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy
Geralmente, é recomendável implementar a auditoria em um alto nível na hierarquia de serviço de diretório do Microsoft
(r) Active Directory(r), porque isso ajudará a manter a consistência das configurações de auditoria. A Contoso
implementou a auditoria nos níveis de servidor membro e OU de controladores de domínio. Para obter detalhes, consulte
o Capítulo 6, "Fortalecendo o Windows 2000 Server".
Você pode ter optado por manter alguns servidores fora do domínio. A auditoria pode ser configurada nesses
computadores, editando a diretiva de grupo no computador local ou usando o utilitário Auditpol.exe no Windows 2000
Server Resource Kit.
Observação Para acessar a diretiva de grupo de um computador local, inicie o Microsoft Management
Console (MMC) e depois adicione o snap-in de diretiva de grupo. Isso tornará o computador local o foco
do snap-in.
Definindo configurações do log de eventos

Todos os eventos gerados pela auditoria aparecerão em Visualizar eventos. Você deve determinar como os logs de
eventos armazenarão os eventos gerados. Essas configurações podem ser definidas diretamente em Visualizar eventos, ou
na diretiva de grupo. Neste guia, definimos as configurações de Visualizar eventos na diretiva de grupo. Para obter
detalhes sobre as configurações recomendadas, consulte o Capítulo 6, "Fortalecendo o Windows 2000 Server".
Se você remover as configurações de Visualizar eventos da diretiva de grupo, poderá defini-las diretamente em
Visualizar eventos. Porém, é recomendável definir as configurações de Visualizar eventos na diretiva de grupo, para
garantir o uso de configurações consistentes em computadores semelhantes.
No ambiente da Contoso, a diretiva de grupo não está configurada para desligar os sistemas da organização se o log de
segurança chegar à capacidade máxima. Em vez disso, os sistemas são configurados para substituir os logs de eventos,
conforme necessário.
Eventos a serem auditados

O Microsoft(r) Windows(r) 2000 fornece várias categorias para auditoria de eventos de segurança. Ao projetar a
estratégia de auditoria de segurança da empresa, você precisará decidir se as categorias de eventos de auditoria de
segurança a seguir devem ser incluídas:
z Eventos de logon
z Eventos de logon de conta
z Eventos de acesso a objetos
z Eventos de acesso ao serviço de diretório
z Eventos de uso de privilégios
z Eventos de rastreamento de processos
z Eventos do sistema
z Eventos de alteração de diretiva
As seções a seguir detalham algumas das identificações de eventos mais comuns, retornadas quando a auditoria é ativada
para categorias específicas.
Observação As ferramentas usadas para pesquisar e coletar informações de log de eventos são discutidas
na seção Métodos de detecção passivos, posteriormente neste capítulo.
Eventos de logon
Se você ativar a auditoria de eventos de logon, cada vez que um usuário fizer logon em um computador ou encerrar o
logon, um evento é gerado no log de segurança do computador onde a tentativa de logon ocorreu. Além disso, quando
um usuário se conecta com um servidor remoto, um evento de logon é gerado no log de segurança do servidor remoto.
Os eventos de logon são criados quando a sessão e o símbolo de logon são criados ou destruídos, respectivamente.
Os eventos de logon podem ser úteis para rastrear tentativas de logon interativo em servidores ou investigar ataques
iniciados em um computador específico. As auditorias com êxito geram uma entrada de auditoria quando uma tentativa
de logon tem êxito. As auditorias com falha geram uma entrada de auditoria quando uma tentativa de logon falha.
Observação Os eventos de logon incluem eventos de logon de usuário e de computador. Você verá
entradas de log de eventos de segurança separadas para a conta do computador e a conta do usuário, se
ocorrer uma tentativa de conexão de rede com um computador executando Microsoft(r) Windows NT(r)
ou Windows 2000. Os computadores com Windows 9x não possuem contas de computador no diretório e
não geram entradas de evento de logon de computador em eventos de logon de rede.
Como parte das diretivas básicas de servidor membro e controlador de domínio, a auditoria de eventos de logon com
êxito e com falha está ativada. Portanto, você verá as identificações de eventos a seguir para logons interativos e logons
de serviços de terminal em conexões com computadores que executam serviços de terminal no log de eventos de
segurança.
Tabela 9.1 Eventos de logon que aparecem no log de eventos de segurança
Identificação Descrição
do evento
528 Um usuário fez logon com êxito em um computador.
529 A tentativa de logon foi efetuada com um nome de usuário desconhecido, ou com um
nome de usuário conhecido e uma senha inválida.
530 Ocorreu uma tentativa de logon com a conta do usuário fora do horário permitido.
531 Ocorreu uma tentativa de logon com uma conta desativada.
532 Ocorreu uma tentativa de logon com uma conta expirada.
533 O usuário não tem permissão para fazer logon neste computador.
534 O usuário tentou fazer logon com um tipo de logon que não é permitido, como rede,
interativo, em lote, de serviço ou interativo remoto.
535 A senha da conta especificada expirou.
536 O serviço de logon de rede não está ativo.
537 A tentativa de logon falhou por outros motivos.
538 Um usuário fez logoff.
539 A conta foi bloqueada quando a tentativa de logon ocorreu. Este evento pode indicar
que um ataque com senhas foi iniciado sem êxito e resultou no bloqueio da conta.
540 Logon de rede com êxito. Este evento indica que um usuário remoto se conectou com
êxito a partir da rede para um recurso local no servidor, gerando um símbolo para o
usuário da rede.
682 Um usuário reconectou-se a uma sessão desconectada de serviços de terminal. Este
evento indica que ocorreu uma conexão com uma sessão anterior de serviços de
terminal.
683 Um usuário desconectou uma sessão de serviços de terminal sem fazer logoff. Este
evento é gerado quando um usuário é conectado a uma sessão de serviços de terminal
pela rede. Ele aparece no Terminal Server.
Os eventos de segurança a seguir podem ser diagnosticados usando entradas de eventos de logon:
z Falhas em tentativas de logon local. Qualquer das identificações de eventos a seguir indica tentativas de logon
com falhas: 529, 530, 531, 532, 533, 534 e 537. Você verá os eventos 529 e 534 se um atacante tentar adivinhar
uma combinação de nome de usuário e senha para uma conta local e falhar. Porém, esses eventos também podem
ocorrer quando um usuário esquece a senha ou começa a navegar na rede em Meus locais de rede. Em um
ambiente em grande escala, pode ser difícil interpretar esses eventos com eficácia. Como regra, você deve
investigar esses padrões se ocorrerem repetidamente ou coincidirem com outros fatores incomuns. Por exemplo,
vários eventos 529 seguidos por um evento 528 à noite poderiam indicar o êxito de um ataque com senhas (ou um
administrador muito cansado).
z Uso inadequado da conta. Os eventos 530, 531, 532 e 533 também podem representar o uso inadequado de uma
conta de usuário. Os eventos indicam que a combinação de conta/senha foi informada corretamente, mas outras
restrições estão impedindo o êxito do logon. Sempre que possível, você deve investigar esses eventos para
determinar se ocorreu uso inadequado ou se a restrição atual precisa ser modificada. Por exemplo, pode ser
necessário ampliar o horário de logon de algumas contas.
z Bloqueios de contas. O evento 539 indica que uma conta foi bloqueada. Isso pode indicar que um ataque com
senhas falhou. Você deve procurar eventos 529 anteriores pela mesma conta de usuário e tentar identificar o
padrão das tentativas de logon.
z Ataques de serviços de terminal. As sessões de serviços de terminal podem ser deixadas em um estado
conectado que permite que os processos continuem em execução após o fim da sessão. A identificação de evento
683 indica quando um usuário não faz logout da sessão de serviços de terminal e a identificação de evento 682
indica que ocorreu uma conexão com uma sessão desconectada anteriormente.
A Contoso está monitorando grandes quantidades de falhas em tentativas de logon e grandes quantidades de bloqueios de
contas. No ambiente da Contoso, não é incomum que os usuários deixem sessões de serviços de terminal desconectadas
por motivos legítimos.
Eventos de logon de conta

Quando um usuário faz logon em um domínio, o logon é processado em um controlador de domínio. Se você auditar os
eventos de logon de conta nos controladores de domínio, verá essa tentativa de logon registrada no controlador de
domínio que valida a conta. Os eventos de logon de conta são criados quando um pacote de autenticação valida as
credenciais de um usuário. Quando credenciais de domínio são usadas, os eventos de logon de conta só são gerados nos
logs de eventos dos controladores de domínio. Caso sejam apresentadas credenciais locais de banco de dados do
Gerenciador de contas de segurança (SAM), os eventos de logon de conta são criados no log de eventos de segurança do
servidor.
Como o evento de logon de conta pode ser registrado em qualquer controlador de domínio válido no domínio, você deve
consolidar os logs de segurança de todos os controladores de domínio para analisar todos os eventos de logon de conta no
domínio.
Observação Como ocorre com os eventos de logon, os eventos de logon de conta incluem eventos de
logon de usuário e de computador.
Como parte das diretivas básicas de servidor membro e controlador de domínio, a auditoria de eventos de logon de conta
com êxito e com falha está ativada. Portanto, você verá as identificações de eventos a seguir para logons de rede e
autenticação de serviços de terminal.
Tabela 9.2 Eventos de logon de conta que aparecem no log de eventos
do evento
672 Uma permissão do serviço de autenticação (AS) foi emitida e validada com êxito.
673 Uma permissão do serviço de concessão de tickets (TGS) foi concedida.
674 Um objeto de segurança renovou um ticket AS ou TGS.
675 Falha na pré-autenticação.
676 Falha na solicitação de bilhete de autenticação.
677 Não foi concedida um ticket TGS.
678 Uma conta foi mapeada com êxito para uma conta de domínio.
680 Identifica a conta usada para a tentativa de logon com êxito. Este evento também
indica o pacote de autenticação usado para autenticar a conta.
681 Ocorreu uma tentativa de logon em conta de domínio.
682 Um usuário reconectou-se a uma sessão desconectada de serviços de terminal.
683 Um usuário desconectou uma sessão de serviços de terminal sem fazer logoff.
Para todos esses eventos, o log de eventos mostra informações detalhadas sobre cada logon específico. Os eventos de
segurança a seguir podem ser diagnosticados usando entradas de eventos de logon de conta:
z Falhas em tentativas de logon em domínio. As identificações de eventos 675 e 677 indicam falhas em tentativas
de logon no domínio.
z Questões de sincronização de tempo. Se a diferença entre a hora em um cliente e o controlador de domínio que
o autentica é superior a cinco minutos (por padrão), a identificação de evento 675 aparecerá no log de segurança.
z Ataques de serviços de terminal. As sessões de serviços de terminal podem ser deixadas em um estado
conectado que permite que os processos continuem em execução após o fim da sessão do Terminal Server. A
identificação de evento 683 indica quando um usuário não faz logout da sessão de serviços de terminal e a
identificação de evento 682 indica que ocorreu uma conexão com uma sessão desconectada anteriormente. Para
evitar desconexões ou para encerrar as sessões desconectadas, defina o intervalo de tempo para finalizar uma
sessão desconectada no console de Configuração dos serviços de terminal, nas propriedades do protocolo RDP-
TCP.
Atualmente, a Contoso está monitorando quantidades incomuns de falhas em tentativas de logon em domínio. No
ambiente deles, os outros eventos não são relevantes. Ao definir essas configurações, eles determinaram que a melhor
abordagem era começar com uma configuração relativamente rigorosa e reduzi-la progressivamente, até que o número de
alertas positivos falsos fosse reduzido. Atualmente, eles estão monitorando os casos em que 10 logins com falha ocorrem
em um período de 10 minutos. Esses números podem ser diferentes em todos os ambientes.
Gerenciamento de contas
A auditoria de gerenciamento de contas é usada para determinar quando usuários ou grupos são criados, alterados ou
excluídos. Pode ser usada para determinar quando um objeto de segurança foi criado e quem executou a tarefa.
Como parte das diretivas básicas de servidor membro e controlador de domínio, a auditoria de gerenciamento de contas
com êxito e com falha está ativada. Portanto, você verá as identificações de eventos a seguir registradas no log de
segurança.
Tabela 9.3 Eventos de gerenciamento de contas que aparecem no log de eventos
do evento
624 Criação de conta de usuário
625 Alteração do tipo de conta de usuário
626 Configurações de conta de usuário
627 Tentativa de alteração de senha
628 Definição de senha de conta de usuário
629 Conta de usuário desativada
630 Exclusão de conta de usuário
631 Criação de grupo global com segurança ativada
632 Adição de membro ao grupo global com segurança ativada
633 Remoção de membro do grupo global com segurança ativada
634 Exclusão de grupo global com segurança ativada
635 Criação de grupo local com segurança desativada
636 Adição de membro ao grupo local com segurança ativada
637 Remoção de membro do grupo local com segurança ativada
638 Exclusão de grupo local com segurança ativada
639 Alteração de grupo local com segurança ativada
641 Alteração de grupo global com segurança ativada
642 Alteração de conta de usuário
643 Alteração em diretiva de domínio
644 Conta de usuário bloqueada
Os eventos de gerenciamento de contas a seguir podem ser diagnosticados usando entradas do log de segurança:
z Criação de uma conta de usuário . As identificações de eventos 624 e 626 identificam quando contas de usuário
são criadas e ativadas. Se a criação de contas está limitada a indivíduos específicos na organização, você pode
usar esses eventos para identificar se pessoas não autorizadas criaram contas de usuário.
z Alteração de senha de conta de usuário. A modificação de uma senha de usuário por outra pessoa pode indicar
que uma conta foi invadida por outro usuário. Procure as identificações de eventos 627 e 628, que indicam êxito
em uma tentativa de alteração de senha. Analise os detalhes para determinar se outra conta executou a alteração e
se a conta é membro do suporte técnico ou de outra equipe de serviços que redefine senhas de contas de usuários.
z Alteração de status de conta de usuário. Um atacante pode tentar apagar seus rastros desativando ou excluindo
uma conta usada durante um ataque. Todas as ocorrências de identificações de eventos 629 e 630 devem ser
investigadas para garantir que são transações autorizadas. Procure também ocorrências da identificação de evento
626 seguida por uma identificação de evento 629 pouco tempo depois. Isso pode indicar que uma conta
desativada foi ativada, usada e desativada novamente.
z Modificação de grupos de segurança. As mudanças de membros em Administradores de domínio,
Administradores, qualquer dos grupos de operadores ou em grupos globais, universais ou locais de domínio
personalizados nas quais funções administrativas são delegadas devem ser revisadas. Para modificações em
membros de grupos globais, procure as identificações de eventos 632 e 633. Para modificações em membros de
grupos locais de domínio, procure as identificações de eventos 636 e 637.
z Bloqueio de contas. Quando uma conta é bloqueada, dois eventos serão registrados no mestre de operações do
emulador de controlador de domínio primário (PDC). Um evento 644 indicará que o nome da conta foi bloqueado
e, em seguida, um evento 642 é registrado, indicando que a conta do usuário foi alterada e agora está bloqueada.
Esse evento só é registrado no emulador de PDC.
Como a Contoso é uma empresa relativamente grande, uma grande quantidade de tarefas de manutenção de contas ocorre
diariamente. O monitoramento de todos esses eventos causaria alertas em quantidade excessiva para que possam ser
abordados de forma razoável no ambiente.
Acesso a objetos
A auditoria pode ser ativada para todos os objetos em uma rede baseada em Windows 2000 com uma lista de controle de
acesso do sistema (SACL). Uma SACL contém uma lista de usuários e grupos para os quais as ações sobre o objeto
devem ser auditadas. Quase todos os objetos que um usuário pode manipular no Windows 2000 possuem uma SACL.
Isso inclui arquivos e pastas em unidades, impressoras e chaves do Registro do sistema de arquivos NTFS.
Uma SACL consiste em entradas de controle de acesso (ACEs). Cada ACE contém três informações:
z O objeto de segurança a ser auditado.

z Os tipos de acesso específicos a serem auditados (a máscara de acesso).
z Um sinalizador para indicar se serão auditados os acessos com falhas, os acessos com êxito ou ambos.
Se você quer que os eventos apareçam no log de segurança, primeiro ative a Auditoria para acesso a objetos e depois
defina a SACL para cada objeto que deseja auditar.
As auditorias no Windows 2000 são geradas quando um identificador para um objeto é aberto. O Windows 2000 usa um
subsistema de segurança em modo de núcleo que só permite que os programas acessem objetos pelo núcleo. Isso impede
que os programas tentem ignorar o sistema de segurança. Como o espaço na memória do núcleo é isolado dos programas
de modo de usuário, um programa refere-se a um objeto por meio de uma estrutura de dados denominada identificador.
A seguir, é apresentada uma tentativa de acesso típica:
1. Um usuário instrui um programa a acessar um objeto (por exemplo, Arquivo/Abrir).

2. O programa solicita um identificador ao sistema, especificando qual tipo de acesso (leitura, gravação e assim por
diante) é desejado.
3. O subsistema de segurança compara a lista de controle de acesso discricionária (DACL) no objeto solicitado com
o símbolo do usuário, procurando entradas na DACL que correspondam ao usuário ou a um grupo ao qual o
usuário pertence e que tenha os direitos de acesso solicitados pelo programa.
4. O sistema compara a SACL no objeto solicitado com o símbolo do usuário, procurando entradas na SACL que
correspondam aos direitos efetivos que estão sendo retornados para o programa, ou aos direitos solicitados pelo
programa. Se uma entrada de controle de acesso (ACE) de auditoria com falha corresponder a um acesso que foi
solicitado mas não foi concedido, um evento de auditoria com falha é gerado. Se uma entrada de controle de
acesso (ACE) de auditoria com êxito corresponder a um acesso que foi concedido, um evento de auditoria com
êxito é gerado.
5. Se qualquer acesso foi concedido, o sistema retorna um identificador ao programa, que pode usá-lo para acessar o
objeto.
É muito importante observar que, quando a auditoria ocorre e o evento é gerado, nada ocorreu com o objeto ainda. Isso é
fundamental para interpretar eventos de auditoria. As auditorias de gravação são geradas antes que o arquivo seja
gravado e as auditorias de leitura são geradas antes que o arquivo seja lido.
Com todas as auditorias, é muito importante adotar uma abordagem direcionada para a auditoria do acesso a objetos. No
plano de auditoria, decida qual tipo de objetos deve auditar e depois determine qual tipo de tentativas de acesso (êxito,
falha ou ambos) deseja monitorar para cada tipo de objeto auditado. Uma abordagem ampla demais da auditoria terá um
impacto significativo sobre o desempenho do sistema e resultará na coleta de uma quantidade de dados superior ao
necessário ou ao útil.
De forma geral, você desejará auditar todo o acesso aos objetos escolhidos, incluindo as contas não confiáveis. Para
alcançar isso, adicione o Grupo Todos à SACL nos objetos que deseja auditar. Cuidado ao auditar o êxito do acesso a
objetos, porque isso pode criar um número muito grande de entradas de auditoria no log de segurança. Contudo, por
exemplo, se você estiver examinando a exclusão de um arquivo crítico, precisará examinar eventos de auditoria com
êxito para determinar qual conta de usuário excluiu o arquivo.
As diretivas básicas de servidor membro e controlador de domínio estão configuradas para auditar o êxito e a falha no
acesso a objetos. Porém, nenhuma SACL está definida nos objetos e será necessário defini-las de acordo com as
necessidades do ambiente. As SACLs podem ser definidas diretamente nos objetos ou usando a diretiva de grupo. Se o
objeto que requer auditoria existe em vários computadores, defina as SACLs na diretiva de grupo.
A auditoria para acesso a objetos gerará os eventos a seguir no log de segurança.
Tabela 9.4 Eventos de acesso a objetos que aparecem no log de eventos
do evento
560 O acesso foi concedido a um objeto já existente.
562 Um identificador para um objeto foi fechado.
563 Ocorreu uma tentativa de abrir um objeto com a intenção de excluí-lo. (Isso é usado
por sistemas de arquivos quando o indicador FILE_DELETE_ON_CLOSE é
especificado.)
564 Um objeto protegido foi excluído.
565 O acesso foi concedido a um tipo de objeto já existente.
Se você está procurando eventos de acesso a objetos específicos, precisará pesquisar eventos com a identificação de
objeto 560. As informações úteis estão nos detalhes do evento e será necessário pesquisar neles para identificar os
eventos específicos que está procurando. A tabela a seguir mostra algumas ações que poderão ser necessárias e como
executá-las.
Tabela 9.5 Como executar as ações de auditoria principais para o evento de acesso a objetos 560
Ação de auditoria Como executá-la

Localizar um arquivo, pasta ou objeto específico Nos detalhes do evento 560, procurar o caminho
completo do arquivo ou da pasta em que deseja
inspecionar ações.
Determinar ações de um usuário específico Definir um filtro que identifica o usuário
específico em um evento 560.
Determinar ações executadas em um computador Definir um filtro que identifica a conta de
específico computador específica onde a tarefa foi

executada em um evento 560.
A Contoso não está monitorando especificamente quaisquer eventos de acesso a objetos, mas está monitorando o acesso
a objetos para alguns arquivos. Essas informações podem ser extremamente úteis ao reagir a um incidente de segurança.
Acesso ao serviço de diretório

Os objetos do Active Directory têm SACLs associadas a eles e, portanto, podem ser auditados. Conforme foi
mencionado anteriormente, você audita contas de usuários e grupos do Active Directory auditando o gerenciamento de
contas. Porém, para auditar a modificação de objetos em outros contextos de nomeação, como os contextos de nomeação
de configuração e esquema, você deve auditar o acesso a objetos e, em seguida, definir a SACL para os recipientes
específicos que deseja auditar. As entradas de auditoria são geradas quando os usuários listados na SACL de um objeto
do Active Directory tentam acessar o objeto.
Você pode modificar a SACL para recipientes e objetos no contexto de nomeação de configuração (e em outros
contextos de nomeação) usando o snap-in ADSIEDIT do MMC. Isso é realizado exibindo o contexto requerido no
console do ADSIEDIT e, em seguida, modificando a SACL do objeto na caixa de diálogo Configurações de segurança
avançadas.
É muito difícil localizar eventos específicos para acesso a serviços de diretório, devido ao grande volume de eventos
(geralmente inofensivos) que ocorrem. Por esse motivo, as diretivas básicas de servidor membro e controlador de
domínio auditam apenas eventos de logon com falha para acesso a serviços de diretório. Isso ajudará a identificar quando
um atacante tenta obter acesso não autorizado ao Active Directory.
A tentativa de acesso ao diretório será mostrada como um evento de serviço de diretório com a identificação 565 no log
de segurança. Só é possível determinar a qual objeto o evento corresponde observando os detalhes do evento de
segurança.
A Contoso não está monitorando especificamente quaisquer eventos de acesso a serviços de diretório, mas está
monitorando o acesso a objetos para alguns arquivos. Essas informações podem ser extremamente úteis ao reagir a um
incidente de segurança.
Uso de privilégios
Quando os usuários trabalham em um ambiente de tecnologia da informação (TI), exercem direitos de usuário
predefinidos. Se você auditar o uso de privilégios quanto a êxitos e falhas, um evento será gerado cada vez que um
usuário tentar exercer um direito de usuário.
Mesmo que você audite o uso de privilégios, nem todos os direitos de usuário são auditados. Por padrão, os direitos de
usuário a seguir são excluídos:
z Ignorar verificação de passagem

z Depurar programas
z Criar um objeto de símbolo
z Substituir símbolo de nível de processo
z Gerar auditorias de segurança
z Fazer backup de arquivos e diretórios
z Restaurar arquivos e diretórios
Você pode substituir o comportamento padrão de não fazer auditoria de direitos de usuário de backup e restauração,
ativando a opção de segurança Fazer auditoria do uso dos privilégios Backup e Restauração na diretiva de grupo.
Auditar o êxito do uso de privilégios criará um número muito grande de entradas no log de segurança. Por esse motivo,
as diretivas básicas de servidor membro e controlador de domínio auditam apenas as falhas no uso de privilégios.
Os eventos a seguir são gerados se a auditoria para uso de privilégios estiver ativada.
Tabela 9.6 Eventos de uso de privilégios que aparecem no log de eventos
do evento
576 Os privilégios especificados foram adicionados ao símbolo de acesso de um usuário.
(Este evento é gerado quando o usuário faz logon.)
577 Um usuário tentou executar uma operação privilegiada de serviço do sistema.
578 Foram usados privilégios em um identificador já aberto para um objeto protegido.
Estes são exemplos de algumas das entradas de log de eventos que podem existir quando direitos de usuário específicos
são usados:
z Agir como parte do sistema operacional. Procure a identificação de evento 577 ou 578 com o privilégio de
acesso SeTcbPrivilege indicado. A conta de usuário que usou o direito de usuário está identificada nos detalhes
do evento. Esse evento pode indicar uma tentativa de usuário para aumentar os privilégios de segurança ao agir
como parte do sistema operacional. Por exemplo, o ataque GetAdmin, onde um usuário tenta adicionar sua conta
ao grupo Administradores, usa este privilégio. As únicas entradas para este evento devem ser para a conta do
sistema e quaisquer contas de serviço às quais esse direito de usuário foi atribuído.
z Alterar a hora do sistema. Procure a identificação de evento 577 ou 578 com o privilégio de acesso
SeSystemtimePrivilege indicado. A conta de usuário que usou o direito de usuário está identificada nos detalhes
do evento. Esse evento pode indicar uma tentativa de usuário de alterar a hora do sistema para ocultar a hora
verdadeira em que um evento ocorre.
z Forçar o encerramento a partir de um sistema remoto. Procure a identificação de evento 577 ou 578 com o
privilégio de acesso de direito de usuário SeRemoteShutdownPrivilege indicado. O identificador de segurança
específico (SID) ao qual o direito de usuário é atribuído e o nome de usuário do objeto de segurança que atribuiu
o direito são incluídos nos detalhes do evento.
z Carregar e descarregar drivers de dispositivo. Procure a identificação de evento 577 ou 578 com o privilégio
de acesso SeLoadDriverPrivilege indicado. A conta de usuário que usou este direito de usuário está identificada
nos detalhes do evento. Este evento pode indicar uma tentativa de usuário de carregar uma versão não autorizada
ou cavalo de Tróia (um tipo de código mal-intencionado) de um driver de dispositivo.
z Gerenciar a auditoria e o log de segurança. Procure a identificação de evento 577 ou 578 com o privilégio de
acesso SeSecurityPrivilege indicado. A conta de usuário que usou este direito de usuário está identificada nos
detalhes do evento. Este evento ocorrerá quando o log de eventos for limpo e quando eventos de uso de privilégio
forem gravados no log de segurança.
z Desligar o sistema. Procure a identificação de evento 577 com o privilégio de acesso SeShutdownPrivilege
indicado. A conta de usuário que usou este direito de usuário está identificada nos detalhes do evento. Este evento
ocorrerá quando uma tentativa de encerrar o computador ocorrer.
z Apropriar-se de arquivos ou outros objetos. Procure a identificação de evento 577 ou 578 com o privilégio de
acesso SeTakeOwnershipPrivilege indicado. A conta de usuário que usou o direito de usuário está identificada
nos detalhes do evento. Este evento pode indicar que um atacante está tentando ignorar as configurações de
segurança atuais, apropriando-se de um objeto.
A Contoso está monitorando especificamente quaisquer eventos que indiquem um encerramento normal ou forçado a
partir de um sistema remoto, assim como quaisquer eventos que indiquem que o log de auditoria e segurança foi
modificado.
Rastreamento de processos
Se você auditar informações de rastreamento detalhadas para processos executando em computadores baseados em
Windows 2000, o log de eventos mostrará tentativas de criar e encerrar processos. Ele também registrará quando um
processo tenta gerar um identificador para um objeto ou obter acesso indireto a um objeto.
Devido ao número muito grande de entradas de auditoria criadas, as diretivas básicas de servidor membro e controlador
de domínio não habilitam auditoria para rastreamento de processos. Porém, se você optar por auditar os êxitos e as
falhas, as identificações de eventos a seguir serão registradas no log de eventos.
Tabela 9.7 Eventos de rastreamento de processos que aparecem no log de eventos
do evento
592 Um novo processo foi criado.
593 Um processo foi fechado.
594 Um identificador para um objeto foi duplicado.
595 O acesso indireto a um objeto foi obtido.
A Contoso não está monitorando eventos de rastreamento de processos e não os ativou nas diretivas de servidor.
Eventos do sistema
Os eventos do sistema são gerados quando um usuário ou processo altera aspectos do ambiente do computador. Você
pode auditar tentativas de fazer alterações no sistema, como encerrar o computador ou alterar a hora do sistema.
Se você auditar eventos do sistema, também deve auditar quando o log de segurança é limpo. Isso é muito importante
porque, com freqüência, os atacantes tentarão limpar seus rastros depois de alterar um ambiente.
As diretivas básicas de servidor membro e controlador de domínio auditam o êxito e a falha de eventos do sistema. Isso
levará às seguintes identificações de eventos no log de eventos.
Tabela 9.8 Eventos do sistema que aparecem no log de eventos
do evento
512 O Windows está se inicializando.
513 O Windows está se encerrando.
514 Um pacote de autenticação foi carregado pela autoridade de segurança local.
515 Um processo de logon confiável foi registrado na autoridade de segurança local.
516 Os recursos internos alocados para o enfileiramento de mensagens de eventos de
segurança foram esgotados, levando à perda de algumas mensagens de eventos de
segurança.
517 O log de segurança foi limpo.
518 Um pacote de notificação foi carregado pelo Gerenciador de contas de segurança.
Você pode usar essas identificações de eventos para capturar várias questões de segurança:
z Desligamento/reinicialização de computador. A identificação de evento 513 mostra cada instância de

desligamento do Windows. É importante saber quando os servidores foram desligados ou reinicializados. Há
alguns motivos legítimos, como a instalação de um driver ou aplicativo que requer uma reinicialização, ou o
desligamento ou reinicialização do servidor para fins de manutenção. Contudo, um atacante pode forçar uma
reinicialização de um servidor para obter acesso ao sistema durante a inicialização. Todos os casos em que o
computador é desligado devem ser registrados para comparação com o log de eventos.
Muitos ataques envolvem a reinicialização de um computador. Ao investigar os logs de eventos, você pode
determinar quando um servidor foi reinicializado e se a reinicialização foi planejada ou não. A identificação de
evento 513 mostra a inicialização do Windows, assim como uma série de outros eventos que são gerados
automaticamente no log do sistema. Eles incluem a identificação de evento 6005, que indica que o serviço do log
de eventos foi inicializado.
Além dessa entrada, procure uma ou mais entradas de log de eventos diferentes no log do sistema. Se o
desligamento anterior foi limpo, como ocorre quando um administrador reinicializa o computador, a identificação
de evento 6006, o serviço de log de eventos foi interrompido, é gravada no log do sistema. Ao examinar os
detalhes da entrada, você pode determinar qual usuário iniciou o desligamento.
Se ocorreu uma reinicialização inesperada, uma identificação de evento 6008, o desligamento anterior do
sistema, às <horas> em <data> foi inesperado é gravado no log do sistema. Isso pode indicar um ataque de
negação de serviço (DoS) que causou um desligamento do computador. Mas lembre-se de que também pode ser
conseqüência de uma falha de energia ou de driver de dispositivo.
Se a reinicialização ocorreu devido a um erro de parada que resultou em uma tela azul, a identificação de evento
1001, com origem em gravação de despejo de memória, é gravada no log do sistema. A mensagem de erro de
parada pode ser revisada nos detalhes do evento.
Observação Para incluir o registro de entradas de identificação de evento 1001, a opção de caixa
de seleção Gravar um evento no log do sistema deve ser selecionada para ativar a seção de
configurações de recuperação do miniaplicativo Sistema do Painel de controle.
z Modificação ou limpeza do log de segurança. Um atacante pode tentar modificar os logs de segurança,
desativar a auditoria durante um ataque ou limpar o log de segurança para impedir a detecção. Se você observar
grandes intervalos de tempo sem entradas no log de segurança, procure as identificações de eventos 612 e 517
para determinar qual usuário modificou a diretiva de auditoria. Todas as ocorrências da identificação de evento
517 devem ser comparadas a um log físico, indicando todas as ocasiões em que o log de segurança foi limpo.
Uma limpeza não autorizada do log de segurança pode ser uma tentativa de ocultar eventos que existiram no log
de segurança anterior. O nome do usuário que limpou o log está incluído nos detalhes do evento.
A Contoso está monitorando desligamentos ou reinicializações de computadores e a limpeza do log de segurança.
Alteração de diretiva
A diretiva de auditoria define quais alterações no ambiente são auditadas, ajudando você a determinar se ocorreram
tentativas de ataque ao ambiente. Contudo, um atacante esperto procurará alterar a diretiva de auditoria, de forma que as
alterações efetuadas não sejam auditadas.
Se você auditar alterações na diretiva, mostrará tentativas de alterar a diretiva de auditoria, juntamente com alterações em
outras diretivas e direitos de usuário. As diretivas básicas de servidor membro e controlador de domínio auditam o êxito
e a falha de alterações em diretivas de auditoria. Você verá esses eventos registrados no log de eventos.
Tabela 9.9 Eventos de alteração de diretivas que aparecem no log de eventos
do evento
608 Um direito de usuário foi atribuído.
609 Um direito de usuário foi removido.
610 Uma relação de confiança com outro domínio foi criada.
611 Uma relação de confiança com outro domínio foi removida.
612 Uma diretiva de auditoria foi alterada.
768 Uma colisão foi detectada entre um elemento de espaço para nome em uma
floresta e um elemento de espaço para nome em outra floresta. (Ocorre quando um
elemento de espaço para nome em uma floresta sobrepõe um elemento de espaço
para nome em outra floresta.)
Os dois eventos mais importantes que devem ser procurados aqui são as identificações de eventos 608 e 609. Algumas
tentativas de ataques podem resultar na gravação desses eventos. Os exemplos a seguir gerarão a identificação de evento
608 se o direito de usuário for atribuído ou 609 se for removido. Em cada caso, o identificador de segurança específico
(SID) ao qual o direito de usuário é atribuído, juntamente com o nome de usuário do objeto de segurança que atribuiu o
direito, são incluídos nos detalhes do evento.
z Agir como parte do sistema operacional. Procure as identificações de eventos 608 e 609 com o direito de
usuário seTcbPrivilege nos detalhes do evento.
z Adicionar estações de trabalho ao domínio. Procure eventos com o direito de usuário
SeMachineAccountPrivilege nos detalhes do evento.
z Fazer backup de arquivos e diretórios. Procure eventos com o direito de usuário SeBackupPrivilege nos
detalhes do evento.
z Ignorar verificação de passagem. Procure eventos com o direito de usuário SeChangeNotifyPrivilege nos
detalhes do evento. Este direito de usuário permite que os usuários percorram uma árvore de diretórios mesmo se
o usuário não possui outras permissões para acessar o diretório.
z Alterar a hora do sistema. Procure eventos com o direito de usuário SeSystemtimePrivilege nos detalhes do
evento. Este direito de usuário permite que um objeto de segurança altere a hora do sistema, com potencial para
mascarar o momento em que um evento ocorre.
z Criar objetos compartilhados permanentes. Procure eventos com o direito de usuário
SeCreatePermanentPrivilege nos detalhes do evento. O proprietário deste direito de usuário pode criar
compartilhamentos de arquivo e impressão.
z Depurar programas.Procure eventos com o direito de usuário SeDebugPrivilege nos detalhes do evento. O
proprietário deste direito de usuário pode se vincular a qualquer processo. Por padrão, este direito só é atribuído a
administradores.
z Forçar o desligamento a partir de um sistema remoto.Procure eventos com o direito de usuário
SeRemoteShutdownPrivilege nos detalhes do evento.
z Aumentar a prioridade de agendamento.Procure eventos com o direito de usuário
SeIncreaseBasePriorityPrivilege nos detalhes do evento. Um usuário com este direito pode modificar
prioridades de processos.
z Carregar e descarregar drivers de dispositivo.Procure eventos com o direito de usuário
SeLoadDriverPrivilege nos detalhes do evento. Um usuário com este direito de usuário poderia carregar uma
versão de cavalo de Tróia de um driver de dispositivo.
z Gerenciar a auditoria e o log de segurança.Procure eventos com o direito de usuário SeSecurityPrivilege nos
detalhes do evento. Um usuário com este direito de usuário pode exibir e limpar o log de segurança.
z Substituir um símbolo de nível de processo.Procure eventos com o direito de usuário
SeAssignPrimaryTokenPrivilege nos detalhes do evento. Um usuário com este direito de usuário pode alterar o
símbolo padrão associado a um subprocesso iniciado.
z Restaurar arquivos e diretórios.Procure eventos com o direito de usuário SeRestorePrivilege nos detalhes do
evento.
z Desligar o sistema.Procure eventos com o direito de usuário SeShutdownPrivilege nos detalhes do evento. Um
usuário com este direito de usuário poderia desligar o sistema para inicializar a instalação de um novo driver de
dispositivo.
z Apropriar-se de arquivos ou outros objetos.Procure eventos com o direito de usuário
SeTakeOwnershipPrivilege nos detalhes do evento. Um usuário com este direito de usuário pode acessar qualquer
objeto ou arquivo em um disco com sistema de arquivos NTFS, apropriando-se do objeto ou arquivo.
Observação Esses eventos de auditoria somente identificam que o direito de usuário foi atribuído a um
objeto de segurança específico. Isso não significa que o objeto de segurança executou uma tarefa usando o
direito de usuário. Os eventos de auditoria determinam quando a diretiva de direitos de usuário foi
modificada.
Atualmente, a Contoso não está monitorando eventos de alteração de diretiva. Esses eventos serão utilizados para
qualquer solução de problemas ou resposta a incidente.
Monitorar alterações em diretivas de grupo pode ser muito difícil e fornecer vários alertas falsos. Isso ocorre
primariamente porque o snap-in do MMC para edição de diretivas de grupo, gpedit.msc, sempre abre diretivas com
privilégios de leitura e gravação. Mesmo que não sejam efetuadas alterações na diretiva, o evento 578 é gravado no log
de segurança do controlador de domínio, conforme mostrado abaixo.
O futuro console de gerenciamento de diretivas de grupo, cujo lançamento está previsto como um download gratuito
pouco depois da distribuição do .NET Server, ajudará a superar essas questões, permitindo que usuários autorizados
exibam as configurações de diretivas de grupo sem precisar abri-las em gpedit.msc.
Protegendo logs de eventos

Para garantir que as entradas de log de eventos sejam mantidas para referência futura, você deve adotar algumas etapas
para proteger a segurança dos logs de eventos. Entre elas estão:
z Definir uma diretiva para o armazenamento, a substituição e a manutenção de todos os logs de eventos. A diretiva
deve definir todas as configurações de log de eventos requeridas e ser aplicada pela diretiva de grupo.
z Garantir que a diretiva inclua como lidar com logs de eventos cheios, especialmente o log de segurança. É
recomendável que um log de evento cheio requeira o desligamento do servidor. Essa medida pode não ser prática
em alguns ambientes, mas deve ser considerada.
z Impedir o acesso de visitantes aos logs de eventos, ativando as configurações de diretivas de segurança para
impedir que visitantes locais acessem os logs de sistema, aplicativos e segurança.
z Garantir que os eventos do sistema sejam auditados para êxitos e falhas, para determinar se ocorreram tentativas
de apagar o conteúdo do log de segurança.
z Exigir o uso de senhas completas ou métodos de autenticação com dois fatores, como logon de cartão inteligente,
por todos os objetos de segurança que tenham a capacidade de exibir ou modificar configurações de auditoria,
para impedir ataques contra essas contas com o objetivo de obter acesso a informações de auditoria.
A Contoso implementou essas configurações nos objetos de diretiva de grupo de servidor membro e controlador de
domínio. Para obter detalhes sobre essas configurações, consulte o Capítulo 6, "Fortalecendo o Windows 2000 Server", e
o Capítulo 7, "Fortalecendo funções específicas de servidor".
Além dessas etapas, você deve adotar as medidas práticas a seguir para garantir que as informações do log de eventos
sejam o mais seguras possível:
z Garanta que seu plano de segurança inclua a segurança física de todos os servidores, para evitar que um atacante
obtenha acesso físico ao computador onde a auditoria é executada. Um atacante pode remover as entradas de
auditoria, modificando ou excluindo os arquivos *.evt físicos no subsistema do disco local.
z Implemente um método para remover ou armazenar os logs de eventos em um local separado do servidor físico.
Isso pode incluir o uso de tarefas programadas para gravar os logs de eventos em CD-R ou em mídias de uma
gravação e várias leituras em intervalos regulares, ou em outros locais de rede separados do servidor. Se os
backups forem copiados para mídias externas, como fitas de backup ou CD-R, a mídia deve ser removida das
instalações em caso de incêndio ou outros desastres naturais.
Observação Impedir o acesso de convidados aos logs de eventos só impede o acesso aos logs de eventos
por usuários que não são membros do domínio. Por padrão, todos os usuários em um domínio podem
acessar os logs de aplicativos e do sistema. Somente o acesso ao log de segurança é restrito. Os objetos de
segurança aos quais o direito de usuário Gerenciar a auditoria e o log de segurança foi atribuído podem
acessar o log de segurança. Por padrão, só é atribuído a Administradores e usuários do grupo Exchange
Enterprise Servers.
Outras práticas recomendadas de auditoria

Além de configurar a auditoria, há outras práticas que devem ser implementadas para auditar com eficácia a segurança do
ambiente de servidor. Entre elas estão:
z Agendar a revisão regular dos logs de eventos

z Revisar outros arquivos de log de aplicativo
z Monitorar os serviços e os drivers instalados
z Monitorar as portas abertas
Agendar a revisão regular dos logs de eventos
Conforme foi mencionado anteriormente, o log de segurança e, potencialmente, os outros logs de eventos, devem ser
gravados em materiais removíveis ou consolidados em um local central para revisão. A revisão dos logs costuma ser a
etapa de auditoria mais negligenciada.
A Contoso trabalhou muito para garantir que haja uma única pessoa ou equipe responsável pela revisão dos logs de
eventos como tarefa regular. A revisão dos logs de eventos pode ser agendada como um evento diário ou semanal,
dependendo da quantidade de dados coletados no log de segurança. Isso costuma se basear no nível da auditoria
implementada na rede. Se mais eventos forem incluídos na auditoria, o volume de entradas no log será maior. A
programação de revisões regulares do log de eventos ajudará a obter:
z Detecção mais rápida de questões de segurança. Se é executada a revisão diária dos logs de eventos, um evento
de segurança nunca deve ter ocorrido há mais de 24 horas. Isso leva à detecção e à correção mais rápidas de
vulnerabilidades de segurança.
z Definição da responsabilidade. Se uma revisão regular dos logs de eventos for necessária, a pessoa encarregada
da revisão dos arquivos de log pode ser a responsável pela identificação de ataques potenciais.
z Redução do risco de substituição de eventos ou de inatividade do servidor. Depois que um log de eventos é
revisado, os eventos no arquivo de log podem ser arquivados para revisão futura e removidos do log de eventos
atual. Essa prática reduz o risco de que os logs de eventos fiquem cheios.
Revisar outros arquivos de log de aplicativo
Além de revisar os eventos de segurança nos logs do Windows 2000, é necessário revisar também os logs criados pelos
aplicativos. Os logs de aplicativo podem incluir informações valiosas sobre ataques potenciais, que podem suplementar
as informações encontradas nos logs de eventos. Dependendo do ambiente, você pode precisar procurar em um ou em
vários arquivos de log:
z Internet Information Services (IIS). O IIS cria arquivos de log que rastreiam as tentativas de conexão com
serviços da Web, protocolo de transferência de arquivos (FTP), protocolo de horário da rede (NTP) e o protocolo
SMTP. Cada serviço executado no IIS mantém arquivos de log separados e armazena os arquivos de log no
formato de arquivo de log estendido W3C (World Wide Web Consortium), na pasta %WinDir%\System32
\Logfiles. Cada serviço mantém uma pasta separada para dividir adicionalmente as informações dos logs. Como
alternativa, é possível configurar o IIS para armazenar os logs em um banco de dados compatível com ODBC,
como Microsoft(r) SQL Server(tm).
z Servidor Microsoft(r) Internet Security and Acceleration (ISA). O Servidor ISA fornece logs para filtros de
pacotes, o serviço de firewall do servidor ISA e o serviço de proxy da Web do servidor ISA. Como ocorre com o
IIS, os logs são armazenados no formato de arquivo de log estendido W3C por padrão mas, como alternativa,
podem ser gravados em um banco de dados compatível com ODBC. Os arquivos de log do Servidor ISA são
armazenados na pasta C:\Program Files\Microsoft ISA Server\ISALogs por padrão.
z Serviço de Autenticação da Internet (IAS). O IAS fornece autenticação centralizada e contabilidade para
autenticação de acesso remoto usando o protocolo Remote Authentication Dial-In User Service (RADIUS). Por
padrão, as solicitações de contabilidade, as solicitações de autenticação e as solicitações de status periódico são
registradas no arquivo IASlog.log, localizado na pasta %WinDir%\System32\Logfiles. Como alternativa, o
arquivo de log pode ser gravado em um formato de arquivo de banco de dados compatível, em vez do formato
IAS.
z Aplicativos de terceiros. Vários aplicativos de terceiros implementam funções de log locais para fornecer
informações detalhadas sobre o aplicativo. Para obter mais informações, consulte os arquivos de ajuda específicos
do aplicativo.
Observação Todos os computadores que mantêm arquivos de log devem usar relógios sincronizados. Isso
permite que um administrador compare eventos entre computadores e serviços, para identificar quais
ações foram adotadas por um atacante. Para obter mais informações sobre a sincronização de horário,
consulte a seção "A importância da sincronização de horário", posteriormente neste capítulo.
Monitorar os serviços e os drivers instalados
Muitos ataques contra um computador são implementados com ataques a serviços instalados no computador de destino,
ou com a substituição de drivers válidos por versões do driver que incluem um cavalo de Tróia, permitindo que um
atacante acesse o computador de destino.
As ferramentas a seguir podem ser usadas para monitorar os serviços e drivers instalados nos computadores:
z O console de serviços. O console de serviços MMC é usado para monitorar os serviços do computador local ou
de um computador remoto e permite que um administrador configure, pause, interrompa, inicie e reinicialize
todos os serviços instalados. Use-o para determinar se algum serviço configurado para início automático não está
inicializado atualmente.
z Netsvc.exe. Esta ferramenta de linha de comando, incluída no Windows 2000 Server Resource Kit, permite que
um administrador inicie, interrompa, pause, continue e consulte remotamente o status de serviços a partir da linha
de comando.
z SvcMon.exe. A ferramenta de monitoramento de serviços monitora serviços em computadores locais e remotos
para identificar alterações no estado (início ou parada). Para detectar essas alterações, a ferramenta implementa
um sistema de pesquisa. Quando um serviço monitorado pára ou se inicia, a ferramenta envia uma notificação por
e-mail. Configure os servidores, os intervalos de pesquisa e os serviços a serem monitorados usando a ferramenta
de configuração do monitor de serviços (smconfig.exe).
z Drivers.exe. Esta ferramenta exibe todos os drivers de dispositivo instalados no computador onde é executada. A
saída da ferramenta inclui informações como o nome de arquivo do driver, o tamanho do driver no disco e a data
em que o driver foi vinculado. Os dados do vínculo podem ser usados para identificar drivers instalados
recentemente. Se um driver atualizado não foi instalado recentemente, isso pode indicar uma substituição de
driver. Sempre correlacione essa informação com um evento de reinicialização do sistema em Visualizar eventos.
Observação Nem todos os serviços (como o serviço de estação de trabalho) podem ser interrompidos
diretamente, embora você possa consultá-los. Se o usuário tem muitas conexões ativas, você não pode
forçar o desligamento remoto do serviço, embora possa pausá-lo ou consultá-lo. Alguns serviços têm
outros serviços que dependem deles; tentar desligar esses serviços falhará, a menos que os serviços
dependentes sejam encerrados primeiro.
Monitorar as portas abertas
Com freqüência, os ataques são iniciados com a execução de uma varredura de portas para identificar serviços
conhecidos em execução no computador de destino. Monitore com cuidado as portas abertas nos servidores. Isso
geralmente significa varrer as portas para determinar o que pode ser acessado.
Ao executar varreduras de portas, é necessário varrer localmente no computador de destino e também a partir de um
computador remoto. Se o computador pode ser acessado de uma rede pública, a varredura de portas deve ser executada a
partir de um computador externo, para garantir que o software de firewall só permita o acesso às portas definidas.
O Netstat.exe é um utilitário de linha de comando que exibe todas as portas abertas para o protocolo de controle de
transmissão (TCP) e para o protocolo de datagrama de usuário (UDP). O comando Netstat usa a seguinte sintaxe:
NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [intervalo]
Onde:
z -a. Exibe todas as conexões e portas de escuta.

z -e. Exibe estatísticas de Ethernet. Pode ser associado à opção -s.
z -n. Exibe endereços e números de porta em formato numérico.
z -p proto. Exibe conexões para o protocolo especificado por proto; proto pode ser TCP ou UDP. Se usado com a
opção -s para exibir as estatísticas por protocolo, proto pode ser TCP, UDP ou protocolo Internet (IP).
z -r. Exibe a tabela de roteamento.
z -s. Exibe estatísticas por protocolo. Por padrão, as estatísticas são exibidas para TCP, UDP e IP; a opção -p pode
ser usada para especificar um subconjunto do padrão.
z intervalo. Exibe novamente as estatísticas selecionadas, com pausa de intervalo de segundos entre cada exibição.
Pressione CTRL+C para interromper a nova exibição das estatísticas. Se este parâmetro for omitido, Netstat
imprimirá as informações da configuração atual uma vez.
Quando você lista as portas TCP e UDP abertas no computador local, os números de portas são convertidos em nomes
com base nas entradas no arquivo de serviços disponível na pasta \%WinDir%\System32\Drivers\Etc\. Se você prefere
ver apenas números de portas, use a opção -n.
Se forem descobertas portas abertas que não são reconhecidas, investigue-as para determinar se o serviço correspondente
é necessário no computador. Se ele não for necessário, desativa ou remova o serviço associado, para impedir que o
computador escute naquela porta. Vários serviços foram desativados nas diretivas básicas de servidor membro e
controlador de domínio incluídas neste guia.
Como muitos servidores são protegidos por firewalls, ou roteadores de filtragem de pacotes, também é recomendado
executar a varredura de portas a partir de um computador remoto. Estão disponíveis muitas ferramentas de terceiros
(incluindo freewares) que podem executar varreduras remotas. A varredura remota de portas revela quais portas estão
disponíveis para os usuários externos quando eles tentam se conectar ao computador.
Observação A varredura de portas também pode ser usada para testar o sistema de detecção de invasões,
para garantir que ele detectará a varredura de portas enquanto ela ocorrer. Para obter mais informações
sobre sistemas de detecção de invasões, consulte a seção "Métodos de detecção ativa", posteriormente
neste capítulo.
Monitoramento de eventos de segurança e

invasões
O monitoramento de eventos de segurança e invasões inclui tarefas passivas e ativas. Muitas invasões são detectadas
depois que o ataque ocorreu, mediante inspeção dos arquivos de log. Essa detecção posterior ao ataque com freqüência é
denominada detecção de invasões passiva. Somente com a inspeção dos arquivos de log o ataque pode ser analisado e
reconstruído com base nas informações do log.
Outras tentativas de invasão podem ser detectadas enquanto o ataque ocorre. Essa metodologia, conhecida como
detecção de invasões ativa, procura padrões de ataque conhecidos ou comandos, e bloqueia sua execução.
Esta seção analisará ferramentas que podem ser usadas para implementar as duas formas de detecção de invasões para
proteger sua rede de ataques.
A importância da sincronização de horário

Ao monitorar eventos de segurança e invasões entre vários computadores, é essencial que os relógios dos computadores
estejam sincronizados. O horário sincronizado permite que um administrador recrie o que ocorreu durante um ataque
contra vários computadores. Sem o horário sincronizado, é muito difícil determinar exatamente quando eventos
específicos ocorreram e como eles se relacionam. Informações mais detalhadas sobre a sincronização de horários estão
disponíveis no Capítulo 5, "Protegendo a infra-estrutura do domínio".
Métodos de detecção passivos

Os sistemas de detecção de invasões passivos envolvem a revisão manual de logs de eventos e logs de aplicativos. A
inspeção envolve a análise e a detecção de padrões de ataque em dados de log de eventos. Há várias ferramentas,
utilitários e aplicativos que podem ajudar a revisar logs de eventos. Esta seção descreve como cada ferramenta pode ser
usada para coordenar informações.
Visualizar eventos
O log de segurança do Windows 2000 pode ser visualizado usando o console do MMC de Visualizar eventos do
Windows 2000. Visualizar eventos permite exibir os logs de aplicativo, segurança e sistema. Você pode definir filtros
para localizar eventos específicos em Visualizar eventos.
Para definir um filtro em Visualizar eventos
1. Selecione o log de eventos específico na árvore do console.

2. Selecione Filtro no menu Exibir.
3. Selecione os parâmetros para filtragem.
Na guia Filtro da caixa de diálogo Propriedades, é possível definir os atributos a seguir para filtrar entradas de eventos:
z Tipos de evento. O filtro pode ser limitado a informações, aviso, erro, auditorias com êxito, auditorias com falhas
ou qualquer combinação de tipos de eventos.
z Origem do evento. O serviço ou driver específico que gerou o evento.
z Categoria. O filtro pode ser limitado a categorias específicas de eventos.
z Identificação do evento. Se você sabe qual é a identificação de evento que está procurando, o filtro pode limitar
a escuta a essa identificação do evento específica.
z Usuário. Você pode limitar a exibição a eventos gerados por um usuário específico.
z Computador. Você pode limitar a exibição a eventos gerados por um computador específico.
z Intervalos de data. Você pode limitar a exibição a eventos ocorridos entre datas de início e de fim específicas.
Quando o filtro é aplicado, a lista de eventos filtrados pode ser exportada para um formato separado por vírgulas ou por
tabulações, para importação em um aplicativo de banco de dados.
Conforme foi mencionado anteriormente, a Contoso tem várias pessoas em cada função administrativa responsável pela
análise de logs de eventos. Essas pessoas revisam os logs diariamente, em busca de eventos relacionados à segurança que
não foram registrados pelo sistema de monitoramento.
Ferramenta de log de eventos de despejo (Dumpel.exe)

O log de eventos de despejo é uma ferramenta de linha de comando, incluída no Windows 2000 Server Resource Kit,
Supplement One (Microsoft Press, ISBN: 0-7356-1279-X). Ela despejará um log de eventos para um sistema local ou
remoto em um arquivo de texto separado por tabulações. Em seguida, esse arquivo pode ser importado para uma planilha
ou banco de dados, para investigações adicionais. A ferramenta também pode ser usada para incluir ou excluir
determinados tipos de eventos usando filtragem.
A sintaxe a seguir é usada pela ferramenta dumpel.exe:
dumpel -f arquivo [-s \\servidor] [-l log [-m origem]] [-e n1 n2 n3...] [-r]
[-t] [-d x]
Onde:
z -f arquivo. Especifica o nome do arquivo de saída. Não há padrão para -f; portanto, você deve especificar o
arquivo.
z -s servidor. Especifica o servidor onde você deseja despejar o log de eventos. As barras invertidas antes do nome
do servidor são opcionais.
z -l log. Especifica qual log (sistema, aplicativo, segurança) deve ser despejado. Se um nome de log inválido for
especificado, o log de aplicativo é despejado.
z -m origem. Especifica em qual origem (como redirecionador (rdr), serial e assim por diante) os registros devem
ser despejados. Somente uma origem pode ser fornecida. Se essa opção não for usada, todos os eventos são
despejados. Se for usada uma origem não registrada no Registro, são pesquisados registros desse tipo no log de
aplicativo.
z -e n1 n2 n3. O filtro procura a identificação de evento nn (pode-se especificar até 10). Se a opção -r não for
usada, somente os registros desses tipos são despejados: se -r for usada, todos os registros com exceção dos
registros desse tipo são despejados. Se essa opção não for usada, todos os eventos com o nome de origem
especificado são despejados. Não é possível usar esta opção sem a opção -m.
z -r. Especifica se a filtragem deve selecionar origens ou registros específicos, ou excluí-los dos resultados.
z -t. Especifica que seqüências de caracteres individuais sejam separadas por tabulações. Se -t não for usada, as
seqüências de caracteres são separadas por espaços.
z -d x. Despeja eventos dos últimos x dias.
Observação Dumpel só pode recuperar conteúdo dos arquivos de log do sistema, de aplicativos e de
segurança. Você não pode usar Dumpel para consultar conteúdo dos logs de eventos do serviço de
duplicação de arquivos, o sistema de nomes de domínio (DNS) ou do serviço de diretório.
EventCombMT
EventCombMT é uma ferramenta de vários segmentos que analisa logs de eventos de muitos servidores
simultaneamente, gerando um segmento de execução diferente para cada servidor incluído nos critérios de pesquisa. Esta
ferramenta permite:
z Definir uma identificação de evento, ou várias, para a pesquisa. Você pode incluir uma única identificação de
evento, ou várias identificações de eventos separadas por espaços.
z Definir um intervalo de identificações de eventos para pesquisa. As extremidades são inclusivas. Por
exemplo, para pesquisar todos os eventos entre as identificações de eventos 528 e 540, inclusive, defina o
intervalo como 528 > ID < 540. Esse recurso é útil porque a maioria dos aplicativos que gravam no log de
eventos usa um intervalo de eventos seqüencial.
z Limitar a pesquisa a logs de eventos específicos. Você pode optar por pesquisar nos logs de sistema, de
aplicativo e de segurança. Se for executado localmente em um controlador de domínio, você também pode optar
por pesquisar em logs FRS, DNS e AD.
z Limitar a pesquisa a tipos de mensagens de eventos específicos. Você pode optar por limitar a pesquisa a
eventos de erro, informativos, aviso, auditorias com êxito, auditorias com falhas ou eventos de êxito.
z Limitar a pesquisa a origens de eventos específicos. Você pode optar por limitar a pesquisa a eventos de uma
origem de eventos específica.
z Pesquisar texto específico em uma descrição de evento. Com cada evento, você pode pesquisar textos
específicos. Isso é útil se você está tentando rastrear usuários ou grupos específicos.
Observação Você não pode incluir lógica de pesquisa, como AND, OR ou NOT, no texto
específico. Além disso, não delimite texto com aspas.
z Definir intervalos de tempo específicos para varredura a partir da data e da hora específicas. Isso permite
limitar a pesquisa a eventos na semana, no dia ou no mês anterior.
Instalando a ferramenta
Para instalar a ferramenta, extraia o conteúdo do arquivo de extração automática SecWin2k.exe, incluído neste guia
(http://www.microsoft.com/technet/security/prodtech/windows/secwin2k/default.asp). Isso criará uma pasta
C:\SCI\scripts\EventComb. Depois que os arquivos forem extraídos, você pode executar a ferramenta EventCombMT
clicando duas vezes no arquivo EventCombMT.exe.
Executando a ferramenta EventComb
A primeira etapa do uso da ferramenta EventComb é definir quais computadores serão incluídos na pesquisa do log de
eventos.
Para adicionar computadores à pesquisa
1. No utilitário EventCombMT, verifique se o domínio correto é detectado automaticamente na caixa do domínio.

Se você deseja pesquisar logs de evento em outro domínio, digite manualmente o novo nome de domínio na caixa
Domain.
2. Para adicionar computadores à lista de pesquisa, clique duas vezes na caixa abaixo Select To Search/Right Click
to Add. O menu pop-up é mostrado na figura a seguir:
Figura 9.1 Usando as configurações da caixa de diálogo EventCombMT para adicionar computadores não
detectados automaticamente à lista de pesquisa
As seguintes opções estão disponíveis:

z Get DCs in domain. Adiciona todos os controladores de domínio do domínio atual à lista.
z Add single server. Permite adicionar um servidor ou estação de trabalho por nome à lista.
z Add all GCs in this domain. Permite adicionar todos os controladores de domínio no domínio
selecionado que estão configurados como servidores de catálogo global.
z Get All Servers (Slow). Adiciona todos os servidores encontrados no domínio usando o serviço de
navegador. Os servidores excluem todos os controladores de domínio.
z Get Servers from File. Permite importar um arquivo que lista todos os servidores a serem incluídos no
escopo da pesquisa. Cada servidor deve ser inserido em uma linha separada no arquivo de texto.
3. Depois que os servidores forem adicionados à lista, você deve selecionar os servidores onde a pesquisa será
executada. Quando estiver selecionado, o servidor aparecerá destacado na lista. Você pode escolher vários
servidores, usando uma combinação de CTRL+servidor desejado.
Especificando os logs de eventos e os tipos de eventos a serem pesquisados
Depois de selecionar os servidores a serem incluídos na pesquisa de log de eventos, você pode limitar o escopo da
pesquisa, selecionando quais logs e tipos de eventos devem ser incluídos.
No utilitário EventCombMT, você pode selecionar entre os logs de eventos a seguir na pesquisa:
z Sistema
z Aplicativo
z Segurança
z FRS (Log do serviço de duplicação de arquivos)
z DNS (log de servidor DNS)
z AD (log de serviço de diretório)
Você também pode selecionar os tipos de eventos a seguir para inclusão na pesquisa:
z Erro. Este evento é registrado nos logs de aplicativo e de sistema, e também aparece nos logs FRS, DNS e de
serviços de diretório.
z Informativo. Este evento é registrado nos logs de aplicativo e de sistema, e também aparece nos logs FRS, DNS
e de serviços de diretório.
z Aviso. Este evento é registrado nos logs de aplicativo e de sistema, e também aparece nos logs FRS, DNS e de
serviços de diretório.
z Auditoria com êxito. Este evento ocorre no log de segurança ou no log de aplicativo se o aplicativo registra
auditorias com êxito no log de aplicativo. Por exemplo, a ferramenta de migração do Active Directory (ADMT)
registra eventos de auditoria com êxito no log de aplicativo.
z Auditoria com falha. Este evento ocorre no log de segurança ou no log de aplicativo se o aplicativo registra
auditorias com falha no log de aplicativo. Por exemplo, a ADMT registra eventos de auditoria com falha no log
de aplicativo.
z Êxito. Este evento é muito raro, é encontrado nos logs de aplicativo e de sistema, e também aparece nos logs
FRS, DNS e de serviços de diretório. Em Visualizar eventos, os eventos com êxito são exibidos como tipo de
evento informativo.
Observação Se você conhece os detalhes sobre qual log de eventos inclui a identificação de evento, e o
tipo de evento da identificação de evento, sempre inclua essas informações nos critérios de pesquisa,
porque isso reduz o tempo da pesquisa.
Salvando pesquisas
EventCombMT permite salvar pesquisas e recarregá-las posteriormente. Isso pode ser útil se você usa EventCombMT
com freqüência para pesquisar os servidores IIS para um conjunto de eventos e seus controladores de domínio para outro.
Os critérios de pesquisa são salvos no Registro em: HKLM\Software\Microsoft\EventCombMT e podem ser editados
facilmente.
Pesquisar nos arquivos de resultados
Os resultados da pesquisa são salvos na pasta C:\Temp por padrão. Os resultados incluem um arquivo de resumo
chamado EventCombMT.txt e, para cada computador incluído na pesquisa de log de eventos, um arquivo de texto
separado chamado NomeComputador-NomeLogEventos_LOG.txt é gerado. Esses arquivos de texto individuais contêm
todos os eventos extraídos dos logs de eventos que correspondem aos seus critérios de pesquisa.
Exemplos de uso de EventCombMT
Para mostrar como EventCombMT pode ser usado, mostraremos como a ferramenta pode ser configurada para detectar
bloqueios de contas e reinícios de controladores de domínio.
Para usar EventCombMT para pesquisar reinícios de controladores de domínio
1. Na ferramenta EventCombMT, verifique se o domínio está configurado com o nome de domínio correto.
2. Na caixa Select to Search/Right Click to Add abaixo do nome do domínio, clique com o botão direito na caixa
e, em seguida, clique em Get DCs in Domain.
Observação Ao pesquisar eventos como logon de conta e gerenciamento de conta, certifique-se de

pesquisar em todos os controladores de domínio. Como o Windows 2000 usa um modelo
multicontrole para gerenciamento de contas, uma conta pode ser adicionada, modificada ou
excluída em qualquer controlador de domínio no domínio. Da mesma forma, a autenticação pode
ser validada por qualquer controlador de domínio no domínio. Por isso, não há como ter certeza de
onde a tentativa de autenticação ou atualização específica ocorre.
3. Clique com o botão direito do mouse na caixa Select to Search/Right Click to Add e, em seguida, clique em
Select All Servers in List.
4. Na ferramenta, na seção Choose Log Files to search, selecione somente o log do sistema.
5. Na seção Event Types selecione Error e Informational.
6. Na caixa Event IDs, digite as identificações de eventos a seguir: 1001 6005 6006 6008.
7. Antes de clicar no botão Search, verifique se os critérios de pesquisa estão definidos conforme mostrado na
figura abaixo.
Figura 9.2 Definindo critérios de pesquisa na caixa de diálogo Event Comb MT
Quando a pesquisa é completada, os resultados podem ser exibidos no diretório de logs, que deve se abrir
automaticamente quando a pesquisa terminar.
Para revisar as entradas do log
1. No menu File, selecione Open log directory.

2. No diretório C:\Temp, clique duas vezes no arquivo de saída de um controlador de domínio para exibir os eventos
específicos registrados pela ferramenta EventCombMT. Você verá uma saída semelhante ao seguinte:
1001,INFORMATIONAL,Save Dump,Wed Nov 28 05:45:50 2001,,O computador foi reinicializado de uma verific
(0x00000004, 0x00000002, 0x00000000, 0x84c983dc). Um despejo de memória foi salvo em: C:\WINDOWS\MEMO
6005,INFORMATIONAL,EventLog,Wed Nov 28 05:45:46 2001,,O serviço Log de eventos foi iniciado.
6008,ERROR,EventLog,Wed Nov 28 05:45:46 2001,,O desligamento anterior do sistema em 5:33:47 AM em 11/
05,INFORMATIONAL,EventLog,Tue Nov 27 14:10:53 2001,,O serviço Log de eventos foi iniciado.
6006,INFORMATIONAL,EventLog,Tue Nov 27 14:09:26 2001,,O serviço Log de eventos foi finalizado.
05,INFORMATIONAL,EventLog,Tue Nov 27 10:11:37 2001,,O serviço Log de eventos foi iniciado.
O evento 6006 indica um desligamento planejado iniciado por um usuário com direitos de usuário para desligar o
controlador de domínio. O evento 6005 indica que o serviço Log de eventos foi iniciado. Isso ocorre na inicialização.
Os eventos 6008 e 1001 indicam que o computador foi desligado sem encerramento ou reinicializado por motivo de
bloqueio, ou experimentou um erro de parada. Se existe um evento 1001, um erro de parada ocorreu e as informações de
depuração associadas e a referência ao arquivo de depuração estão incluídos.
Os eventos retornados pela ferramenta EventCombMT devem ser comparados com o tempo de inatividade conhecido, e
os eventos que não correspondem devem ser pesquisados para garantir que o servidor não foi atacado.
EventCombMT inclui várias pesquisas pré-configuradas que podem ser usadas para pesquisar eventos de segurança. Por
exemplo, há uma pesquisa predefinida que procura eventos de bloqueio de conta.
Para usar EventCombMT para pesquisar bloqueios de conta
1. Na ferramenta EventCombMT, verifique se o domínio está configurado com o nome de domínio correto.
2. Na caixa Select to Search/Right Click to Add abaixo do nome do domínio, clique com o botão direito na caixa
e, em seguida, clique em Get DCs in Domain.
3. Clique com o botão direito do mouse na caixa Select to Search/Right Click to Add e, em seguida, clique em
Select All Servers in List.
4. No menu Searches, clique em Internal searches e, em seguida, clique em Account lockout. O utilitário
EventCombMT é configurado conforme mostrado na figura a seguir:
5. Clique em Search.
6. Quando a pesquisa é completada, os resultados podem ser exibidos no diretório de logs, que deve se abrir
automaticamente quando a pesquisa terminar.
Observação Outras pesquisas predefinidas incluídas no EventcombMT são pesquisas de serviços de

duplicação de arquivos, pesquisas do Active Directory para SIDs duplicados e falhas de registro de DNS
de NETLOGON, erros de disco de hardware e erros de interface de DNS. Você também pode definir e
salvar pesquisas personalizadas.
A Contoso utiliza o EventCombMT nos casos em que está tentando diagnosticar problemas ou determinar causas de
problemas durante uma resposta a incidente. Além disso, verifica rotineiramente os bloqueios de contas ou senhas
incorretas em todos os controladores de domínio. Isso ajuda a Contoso a identificar manualmente padrões estranhos que
um sistema de monitoramento pode não detectar.
Coleta de eventos
Um dos principais objetivos da auditoria é identificar as ações adotadas por atacantes na rede. Um atacante pode tentar
comprometer vários computadores e dispositivos na rede. Portanto, para entender a extensão de qualquer ataque, você
deve ser capaz de coordenar e consolidar informações de muitos computadores.
Se os utilitários de log farão importações para um banco de dados, é mais fácil coordenar as informações de vários logs.
Desde que o horário esteja sincronizado em todos os computadores, você pode classificar os campos de hora e facilitar o
rastreamento de eventos com base em intervalos de tempo.
As seções a seguir descrevem algumas das ferramentas e utilitários que você pode usar para coletar informações de log
de eventos em um local central.
Criação de scripts
É possível criar scripts que coletam informações de log de eventos de computadores remotos e as armazenam em um
local central. Ao usar scripts, você pode escolher quando executá-los usando tarefas agendadas e determinar quais ações
devem ser adotadas depois que o log de eventos for copiado com êxito para o local central.
Um exemplo simples seria criar um arquivo de lote que usa o Dumpel.exe do Windows 2000 Server Resource Kit e
iniciar o arquivo de lote em intervalos regulares usando Tarefas programadas no Painel de controle.
O Windows 2000 Resource Kit, Supplement One inclui Eventquery.pl, um script em Perl que exibe eventos dos logs de
Visualizar eventos em computadores locais e remotos que executam Windows 2000 e oferece uma grande variedade de
filtros para ajudar a localizar eventos específicos.
Observação Para usar esse script, será necessário instalar o ActivePerl do Windows 2000 Server Resource
Kit.
Atualmente, a Contoso não utiliza uma solução de coleta de eventos. Porém, planeja utilizar o Microsoft Audit
Collection System (MACS), que será lançado no próximo ano. O MACS é uma ferramenta de coleta de eventos de
segurança que coleta eventos de forma segura utilizando compactação, assinaturas e criptografia. Depois de coletados, os
eventos são carregados em um banco de dados SQL e otimizados para análise.
Microsoft Operations Manager
O Microsoft Operations Manager (MOM) 2000 oferece um conjunto de ferramentas abrangente, que permite às empresas
analisar em detalhes os relatórios de eventos e o monitoramento de desempenho internos do Windows 2000 e de seus
aplicativos. O MOM 2000 pode coletar, armazenar e reportar eventos e dados de desempenho para um local único,
usando agentes inteligentes em computadores remotos, e permite que um administrador analise centralmente as
informações coletadas.
O pacote de gerenciamento principal do MOM 2000 coleta eventos que aparecem nos logs de eventos de segurança, de
aplicativos e do sistema, e agrega os resultados em um repositório de eventos central.
Observação O MOM 2000 armazena suas informações em um banco de dados do SQL Server e oferece
vários métodos para recuperar e analisar os dados arquivados. Os administradores podem usar o
Operations Manager Administrator Console, o Web Console ou o Operations Manager Reporting para
exibir, imprimir ou publicar os dados. Cada visualização inclui visualizações predefinidas para analisar os
dados arquivados, e permite a definição de visualizações e relatórios personalizados.
Soluções de terceiros para coleta de logs de eventos
Vários produtos de terceiros oferecem coleta e inspeção centralizadas de logs de eventos. Ao avaliar produtos de
terceiros, inclua os recursos a seguir nos critérios:
z Suporte a todos os logs do Windows 2000. Deve ser fornecido suporte para logs de Servidor DNS, serviço de
diretórios e FRS, além dos logs de aplicativo, segurança e sistema.
z Uso de um banco de dados back-end. A ferramenta deve permitir que os logs de eventos sejam armazenados
em uma estrutura de banco de dados que permita a inspeção de entradas anteriores do log de eventos para análise
de tendências e correlação de eventos entre vários servidores.
z Funcionalidade de pesquisa e relatórios. A ferramenta deve permitir a pesquisa de eventos específicos com
base em critérios fornecidos. Os resultados devem ser apresentados de forma legível.
Os produtos de terceiros que fornecem a capacidade de coleta de eventos incluem:
z Event Log Monitor - TNT Software (www.tntsoftware.com)

z Event Archiver - Dorian Software Creations (www.doriansoft.com)
z LogCaster - RippleTech (www.rippletech.com/main.php)
Métodos de detecção ativos

Os sistemas de detecção de invasões ativos analisam o tráfego de rede de entrada na camada de aplicativo, procurando
métodos de ataque conhecidos ou cargas suspeitas de camada do aplicativo. Se um pacote suspeito for recebido, o
sistema de detecção de invasões descartará o pacote e registrará uma entrada em um arquivo de log. Alguns sistemas de
detecção de invasões também podem alertar um administrador se um ataque grave for detectado.
Soluções de terceiros para detecção de invasões

Existem soluções de terceiros para sistemas de detecção de invasões de rede e de extremidade. Essas soluções de
terceiros fornecem suporte para protocolos diferentes do protocolo de transferência de hipertexto (HTTP) e também
podem verificar a ocorrência de ataques conhecidos contra computadores de rede.
Os tipos de ataques comuns que os sistemas de detecção de invasão devem identificar incluem:
z Ataques de reconhecimento. Ocorrem quando um invasor está testando uma rede, à procura de vulnerabilidades.
Os ataques potenciais incluem varreduras de ping, transferências de zona de DNS, reconhecimento de email,
verificações de portas e download de conteúdo de sites para procurar scripts vulneráveis e amostras de páginas.
z Ataques de exploração. Ocorrem quando intrusos aproveitam recursos ocultos ou bugs para obter acesso ao
sistema. Com freqüência, os pontos de ataque foram identificados por um ataque de exploração anterior.
z Ataque de negação de serviço (DoS). Ocorre quando um intruso tenta derrubar um serviço executado em um
computador sobrecarregando um recurso, como links de rede, a CPU ou o subsistema de disco. O intruso não está
tentando obter informações, mas sim desativar o computador.
Um bom sistema de detecção de invasões deve ser capaz de identificar as três formas de ataques. Dois métodos são
usados para identificar ataques:
z Detecção de anomalias. Este método considera como linha de base um computador na rede. Os desvios em
relação à linha de base podem identificar uma tentativa de invasão. Por exemplo, um aumento nas tentativas de
logon fora do horário de pico pode identificar um computador comprometido. A vantagem da detecção de
anomalias é que ela pode identificar ataques sem entender exatamente como o ataque ocorre.
z Reconhecimento de assinatura. Este método identifica ataques com base em padrões conhecidos. Muitos
ataques a servidores Web usam padrões comuns, que podem ser identificados facilmente. Ao comparar o tráfego
de entrada dos aplicativos a seqüências de assinatura em um banco de dados, um sistema de detecção de invasões
pode identificar esses ataques. A desvantagem deste método de detecção de invasões é que o banco de dados de
assinaturas deve ser atualizado com freqüência para identificar novas assinaturas de ataque.
Alguns produtos de terceiros disponíveis para testes e implantação incluem:
z BlackIce Defender (http://www.iss.net/products_services/hsoffice_protection/)

z CyberCop Scanner (http://www.ciac.org/cstc/cybercop/cybercop-scanner.html)
z ICEpac Security Suite (http://www.itsecurity.com/products/prod376.htm)
z Cisco Secure IDS (http://www.cisco.com/warp/public/cc/pd/sqsw/sqidsz/prodlit/netra_ds.htm)
z eTrust Intrusion Detection (http://www3.ca.com/Solutions/Product.asp?ID=163)
z Snort (www.snort.org/)
z Tripwire (www.tripwiresecurity.com/)
z Foundstone Attacker (www.foundstone.com/)
Avaliação de vulnerabilidade
Além de executar detecção de invasões ativa e passiva, você deve também fazer avaliações de vulnerabilidade
periódicas. As avaliações de vulnerabilidade simulam um ataque na rede e detectam as vulnerabilidades que um atacante
encontraria.
Ao executar avaliações periódicas, você pode localizar vulnerabilidades antes de um atacante e proteger a parte
enfraquecida da rede contra a vulnerabilidade.
Ao pesquisar ferramentas de avaliação de vulnerabilidade, inclua os requisitos a seguir no processo de tomada de

decisão:
z Mecanismo de atualização de banco de dados automático. A ferramenta deve fornecer um método automático
para atualização das assinaturas de vulnerabilidades, para que não fique desatualizada em pouco tempo.
z Um filtro para minimizar falsos positivos. A ferramenta deve filtrar os falsos positivos, de forma que a
organização não desperdice tempo investigando eventos não relacionados à segurança.
z Capacidade para armazenar resultados em um banco de dados. A ferramenta deve permitir o arquivamento
de resultados de análises de tendências e detectar alterações na segurança com o tempo.
z Soluções para as vulnerabilidades. Se uma vulnerabilidade for encontrada, a ferramenta deve fornecer
documentação sobre como corrigir a vulnerabilidade ou scripts que executem as tarefas de proteção.
Existem várias ferramentas de terceiros para executar avaliações de vulnerabilidade em uma rede com Windows 2000.
Entre elas estão:
z Symantec NetRecon 3.5 (http://enterprisesecurity.symantec.com/)

z BindView Security Advisor (www.bindview.com/)
z eEye Digital Security. Retina Network Security Scanner (http://www.eeye.com)
z Internet Security Systems (ISS) Internet Scanner (http://www.iss.net)
z Symantec Enterprise Security Manager 5.5 (http://enterprisesecurity.symantec.com/products/products.cfm?
ProductID=45)
Como alternativa, pode ser mais apropriado contratar um serviço de consultoria de terceiros para executar a avaliação de
vulnerabilidade. A vantagem de usar um serviço de terceiros é que eles não têm conhecimento anterior da rede e adotarão
o mesmo ponto de partida de um atacante externo. Muitas vezes, essas avaliações externas fornecerão as informações
mais úteis, devido à neutralidade da equipe de avaliação.
Resumo
A auditoria e a detecção de invasões são uma parte importante da criação de uma defesa eficaz para o seu ambiente.
Como parte do processo de gerenciamento de riscos, você deve determinar o nível de auditoria e detecção de invasões
apropriado para o ambiente. Para detecção de invasões em vários protocolos, pode ser uma boa idéia considerar
ferramentas de terceiros.
Mais informações
Para obter mais informações sobre o uso de direitos de usuário, consulte Writing Secure Code, de Michael Howard e
David LeBlanc (Microsoft Press, ISBN: 0-7356-1588-8).
Informações sobre parceiros de ISA Server:
http://www.microsoft.com/isaserver/partners/ (site em inglês).
ISA Server Solution Developers Kit (SDK):
http://www.microsoft.com/isaserver/techinfo/productdoc/2000/SDKdownload.asp (site em inglês).

Auditoria e detecção de invasões Windows

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Auditoria e detecção de invasões Windows

Caricato da

Copyright:

Formati disponibili

Capítulo 9 - Auditoria e detecção de invasões Página 1 de 25

Capítulo 9 - Auditoria e detecção de invasões

Como ativar a auditoria

Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy

Definindo configurações do log de eventos

Eventos a serem auditados

Tabela 9.1 Eventos de logon que aparecem no log de eventos de segurança

Eventos de logon de conta

Tabela 9.2 Eventos de logon de conta que aparecem no log de eventos

Tabela 9.3 Eventos de gerenciamento de contas que aparecem no log de eventos

644 Conta de usuário bloqueada

z O objeto de segurança a ser auditado.

1. Um usuário instrui um programa a acessar um objeto (por exemplo, Arquivo/Abrir).

A auditoria para acesso a objetos gerará os eventos a seguir no log de segurança.

Tabela 9.4 Eventos de acesso a objetos que aparecem no log de eventos

Ação de auditoria Como executá-la

específico computador específica onde a tarefa foi

Acesso ao serviço de diretório

z Ignorar verificação de passagem

Tabela 9.6 Eventos de uso de privilégios que aparecem no log de eventos

Tabela 9.7 Eventos de rastreamento de processos que aparecem no log de eventos

Tabela 9.8 Eventos do sistema que aparecem no log de eventos

z Desligamento/reinicialização de computador. A identificação de evento 513 mostra cada instância de

A Contoso está monitorando desligamentos ou reinicializações de computadores e a limpeza do log de segurança.

Tabela 9.9 Eventos de alteração de diretivas que aparecem no log de eventos

Protegendo logs de eventos

Outras práticas recomendadas de auditoria

z Agendar a revisão regular dos logs de eventos

Agendar a revisão regular dos logs de eventos

Revisar outros arquivos de log de aplicativo

Monitorar os serviços e os drivers instalados

Monitorar as portas abertas

NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [intervalo]

z -a. Exibe todas as conexões e portas de escuta.

Monitoramento de eventos de segurança e

A importância da sincronização de horário

Métodos de detecção passivos

Para definir um filtro em Visualizar eventos

1. Selecione o log de eventos específico na árvore do console.

Ferramenta de log de eventos de despejo (Dumpel.exe)

A sintaxe a seguir é usada pela ferramenta dumpel.exe:

Executando a ferramenta EventComb

Para adicionar computadores à pesquisa

1. No utilitário EventCombMT, verifique se o domínio correto é detectado automaticamente na caixa do domínio.

As seguintes opções estão disponíveis:

Especificando os logs de eventos e os tipos de eventos a serem pesquisados

Pesquisar nos arquivos de resultados

Exemplos de uso de EventCombMT

Para usar EventCombMT para pesquisar reinícios de controladores de domínio

Observação Ao pesquisar eventos como logon de conta e gerenciamento de conta, certifique-se de

Figura 9.2 Definindo critérios de pesquisa na caixa de diálogo Event Comb MT

Para revisar as entradas do log

1. No menu File, selecione Open log directory.

Para usar EventCombMT para pesquisar bloqueios de conta

Observação Outras pesquisas predefinidas incluídas no EventcombMT são pesquisas de serviços de

Microsoft Operations Manager

Soluções de terceiros para coleta de logs de eventos

Os produtos de terceiros que fornecem a capacidade de coleta de eventos incluem:

z Event Log Monitor - TNT Software (www.tntsoftware.com)

Métodos de detecção ativos

Soluções de terceiros para detecção de invasões

Alguns produtos de terceiros disponíveis para testes e implantação incluem:

z BlackIce Defender (http://www.iss.net/products_services/hsoffice_protection/)