Introdução

Este documento sugere passos para responder a um compromisso de segurança nos Sistemas Operativos UNIX ou NT.

Note que todas as acções desencadeadas nesta actividade devem estar de acordo com as políticas e procedimentos da sua organização.

A. Antes de começar

1. Consulte a sua política de segurança

2. Se não dispuser de política de segurança
- 2.1. Consulte as chefias da organização
  Dependendo de como a sua organização está estruturada, pode ser importante notificar as chefias para facilitar a coordenação interna do esforço de recuperação da intrusão. Deve também estar atento à possibilidade das intrusões poderem captar a atenção da comunicação social.
- 2.2. Consulte a assessoria jurídica
  Antes de começar a recuperação a sua organização deve decidir se é ou não uma opção dar início a uma investigação legal.
  
  As equipas de resposta a incidentes de segurança (CSIRTs e/ou CERTs) tem normalmente uma predominância técnica na abordagem das situações, e, assim sendo, não prestam apoio ou orientações legais.
  
  Se estiver interessado em perseguir a via legal, sugere-se que consulte as chefias e assessoria juridica para determinar se alguma lei foi infringida, e, com essa base, pode tentar o contacto com as autoridades no sentido de averiguar da possibilidade de iniciar uma investigação.
- 2.3. Informar outras entidades
  Pode ser necessário notificar outras entidades, como por exemplo, outras assistências técnicas dos sistemas afectados, ou as respectivas comunidades utilizadoras.
3. Documentação de todos os passos realizados na recuperação
É muito importante documentar todos os passos realizados na recuperação, pelas seguintes razões:
- Diminui a probabilidade de serem tomadas decisões apressadas ou mal fundamentadas, que podem vir a ter efeitos secundários indesejáveis;
- Através da consulta do registo das acções efectuadas, pode ser possível recuperar o sistema para situações anteriores a determinadas acções;
- Pode ser útil numa investigação legal.

B. Obter controlo do sistema

1. Desligar os sistemas comprometidos da rede
Para voltar a obter controlo dos sistemas precisará de desligá-los da rede, incluindo ligações dial-up ou de consola. Após esta acção pode escolher operar o sistema em single-user no caso de um sistema Unix, ou como administrador local no NT. Para isso no entanto pode perder informações úteis sobre o estado do sistema porque os processos existentes serão removidos por acção da reinicialização do sistema.

Se não desligar os sistemas comprometidos da rede, corre o risco do intruso poder desfazer as acções que se vão tomando no sentido da recuperação.
2. Realização de uma cópia da imagem dos sistemas
Antes de analisar a intrusão é recomendável que seja realizada uma cópia total do sistema. Essa cópia pode ser necessária no futuro para recuperação de dados ou para realização de investigações adicionais.

Se tiver disponíveis discos sobressalentes dos mesmos modelos (e capacidades) aos instalados nos sistemas comprometidos, pode usar o comando “dd” fornecido com os sistemas UNIX, para fazer uma cópia exacta dos discos presentes nos sistemas comprometidos.

Por exemplo, num sistema Linux com dois discos SCSI, o comando seguinte faria uma réplica do disco “/dev/sda” para o disco “/dev/sdb”.

# dd if=/dev/sda of=/dev/sdb

Por favor consulte a página de manual do commando “dd” para mais informações.

Há várias formas de fazer cópias idênticas de discos. No caso de sistemas NT, não está disponível um comando como o “dd”, mas existem outras ferramentas disponíveis no mercado capazes do mesmo efeito.

Após a criação das cópias, os suportes físicos devem ser etiquetados e armazenados em local seguro. Para além desta cópia extraordinária, e se os sistemas comprometidos dispuserem de backups regulares, é aconselhável assegurar que os backups realizados nesse âmbito não serão reescritos.

C. Análise da intrusão

1. Procurar modificações em sofware de sistema ou ficheiros de configuração
Os resultados dados por sistemas com a segurança comprometida não são de confiança. Em concreto a procura de modificações usando ferramentas do próprio sistema comprometido, não é de confiança. Existem root-kits que após instalados modificam o sistema para esconder a intrusão, dando resultados falsificados aos comandos típicos de procura de intrusão, como por exemplo, no caso Unix, os comandos “ls”, “lsmod” e outros.

Devido a este problema, sugere-se que os computadores comprometidos sejam re-arrancados (boot) com um sistema operativo que se saiba não ter sido comprometido. A actividade de análise deve partir de um sistema operativo que se saiba não estar comprometido. Uma possibilidade para atingir este objectivo é instalar um disco adicional no sistema com um sistema operativo limpo, e realizar a análise arrancando o sistema a partir desse disco.

Alguns dos binários que são tipicamente substituídos por Cavalos de Tróia em sistemas Unix são: telnet, in.telnetd, login, su, ftp, ls, ps, netstat, ifconfig, find, du, df, libc, sync, inetd e syslogd. É conveniente verificar também qualquer executável referido em /etc/inetd.conf , ou noutras configurações de arranque do sistema, programas de sistema e rede críticos, bem como bibliotecas partilhadas.

Em sistemas NT, os Cavalos de Tróia normalmente introduzem vírus ou “sistemas de administração remota” como por exemplo o Back Orifice and NetBus. Já aconteceram casos em que o ficheiro de sistema que trata a conectividade Internet foi substituído por um Cavalo de Tróia.

A comparação dos ficheiros executáveis e das configurações no sistema comprometido, contra as versões dadas como boas, não deve basear-se em datas de alteração ou tamanhos, mas sim na comparação do conteúdo dos ficheiros, ou então na comparação de sínteses tipo MD5.

Sugere-se que a inspecção a sistemas Unix inclua:
- verificação se o ficheiro /etc/passwd tem entradas inesperadas;
- verificação se o ficheiro /etc/inetd.conf foi modificado, bem como os outros ficheiros de configuração de arranque do sistema;
- caso se disponibilizem comandos remotos (rsh e/ou outros), verificar se os ficheiros de autorização (/etc/hosts.equiv, .rhosts) contém entradas inesperadas;
- verificação de programas SUID (set user ID) e SGID (set group ID). O comando seguinte de procura pode ajudar nessa verificação:
- # find / ( -perm -004000 -o -perm -002000 ) -type f -print
- verificação de utilizadores ou pertenças a grupos estranhas;
- verificação de alterações no registo de sistema que arranquem programas, em “logon” ou em serviços;
- verificação de shares não autorizadas, escondidas, utilizando o comando “net share” ou “Server Manager tool”
- verificação de processos estranhos a correr, utilizando o task manager.
2. Procurar modificações em dados
Frequentemente os dados são modificados pelo intruso, pelo que é recomendável verificar a sua integridade.
3. Procurar por ferramentas e dados deixados pelo intruso
Os intrusos tem o hábito de instalar ferramentas feitas à medida para monitorização e acesso do/ao sistema comprometido. As classes de ficheiros normalmente encontradas nestes casos são:
- Analisadores de tráfego (network sniffers) – um analisador de tráfego simples é uma ferramenta capacidades de monitorização e registo para ficheiro. Os intrusos tendem a usar estas ferramentas para descobrir logins e passwords que passam em claro na rede, bem como para reconhecer outros pormenores da rede. Os sniffers são mais comuns em sistemas Unix do que em sistemas NT, mas nestes últimos deve verificar-se a existência de key-loggers.
- Programas “Cavalo de Tróia” – Estes programas tipicamente apresentam uma mímica de um programa legitimo no sistema, mas funcionam para benefício do intruso, com objectivos que podem passar por recolher logins e password, fornecer acesso remoto ao sistema, ou outros.
- Backdoor – Uma backdoor é um ponto de entrada no sistema, dissimulado, e utilizado pelo intruso.
- Exploração de vulnerabilidades – Muitos compromissos de segurança resultam da exploração de vulnerabilidades de segurança presentes em software legitimo a correr nos sistemas. Por vezes as ferramentas usadas para escalar privilégios dentro dos servidores, são deixadas pelo intruso, possivelmente em directórios de sistema escondidos.
- Outras ferramentas dos intrusos – A lista de ferramentas dada atrás não é conclusiva ou compreensiva. Há muitas outras ferramentas que um intruso pode deixar para trás. Alguns tipos destas ferramentas normalmente utilizados são:
  - para procura de vulnerabilidades
  - Ferramentas para lançar ataques de reconhecimento a outros pontos da Internet
  - Ferramentas para lançar ataques de negação de serviço
  - Ferramentas para explorar os recursos disponíveis no servidor
Saídas das ferramentas usadas pelo intruso – as ferramentas usadas pelo intruso podem ter produzido saídas (output), interessantes para determinar as suas actividades, bem como outros sites envolvidos.

A procura por ferramentas utilizadas por intrusos deve ter em atenção ao seguinte:
- Ficheiros inesperados do tipo texto abaixo do directório /dev. Algumas ferramentas deixam informação nesse local.
- Ficheiros os directórios escondidos
- Ficheiros ou directórios que possam facilmente ser confundidos com nomes legitimos, como por exemplo “...” em sistemas UNIX, ou EXPLORE.EXE ou UMGR32.EXE em sistemas Windows.
4. Rever históricos (logs)
A revisão dos históricos pode ajudar a formar uma ideia de como o sistema foi comprometido, o que aconteceu enquanto durante essa situação, e que acessos externos houve. Os históricos tem que ser analisados com espirito crítico porque podem ter sido manipulados pelo intruso.

Como os logs podem conter grandes volumes de informação, não é raro haver a necessidade de sintetizar essa informação, e, nesta análise recomenda-se os seguintes critérios:
- Procurar por ocorrências fora do normal
- Procurar por ausência de logs quando supostamente deviam existir. Em concreto recomenda-se a procura por descontinuidades nas datas/hora dos logs. A existência de “buracos”, ou saltos nos logs indicia que o intruso tentou sanitizá-los e portanto
  - a) permite aferir de certa forma a competência do intruso, e
  - b) junto a essas ocorrências deve verificar-se todos as entradas de logs no sentido de verificar se a sanitização dos logs foi incompleta.
Os logs dos sistemas NT podem ser consultados através do Event-Viewer. Outras aplicações podem escrever os logs para outras localizações. O ISS por exemplo escreve os logs para o directório c:winntsystem32logfiles. Abaixo encontra-se uma lista dos logs comuns a sistemas UNIX, uma descrição da sua função, e o que procurar nesses ficheiros. Dependendo da configuração do sistema, pode haver algumas diferenças.
- messages - Este logs contém informação genérica. Procurar por anomalias neste ficheiro, bem como eventos ocorridos na altura prevista da intrusão.
- xferlog – Contém informação relativa ao FTP, e pode ser usado para descobrir ficheiros que foram puxados para o sistema
- utmp – informação dos utilizadores ligados ao sistema. Utilizar o programa “who” para aceder. * wtmp – cada vez que um utilizador entra com sucesso, sai, ou o sistema faz um reboot ou tem um “crash”, isso fica registado neste ficheiro. Este ficheiro é normalmente acedido através do programa “last”.
- secure - Algumas versões de UNIX usam este ficheiro para registar informação de segurança como por exemplo logins bem ou mal sucedidos, etc. Exemplos de aplicações que podem usar este log são os tcp-wrappers, e o SSH
5. Procurar por sinais de analisadores de rede (sniffers)
Quando ocorre uma intrusão é frequente a instalação de um programa de monitorização da rede para captura de informação das contas (login e password). Para sistemas NT é mais usual a instalação de programas de administração remota para os mesmos efeitos.

O primeiro passo para determinar se um sniffer está instalado, é verificar se algum processo tem uma interface de rede em modo promiscuo. Neste modo de funcionamento, a interface de rede passa todos os pacotes de rede para o sistema operativo, mesmo que não sejam endereçados a si.

Existem algumas ferramentas para fazer esta investigação:
- cpm – UNIX. Disponível em ftp://coast.cs.purdue.edu/pub/tools/unix/sysutils/cpm/
- ifstatus – UNIX. Disponível em ftp://coast.cs.purdue.edu/pub/tools/unix/sysutils/ifstatus/
Note-se que existem utilizações legitimas para o funcionamento das interfaces de rede em modo promiscuo, e portanto não é possível afirmar-se que o intruso está a fazer sniffing apenas sabendo-se que as interfaces estão em modo promiscuo.

Deve-se também considerar que os logs dos sniffers tendem a crescer rapidamente, e que isso pode portanto traduzir-se no volume ocupado das partições. Infelizmente as ferramentas que permitem aferir o volume, como o “df”, podem ter sido substituídas por versões falsificadas pelo que se deve ter o cuidado de fazer a verificação com uma versão limpa do Sistema Operativo.

Se um sniffer foi instalado no seu sistema, é aconselhável analisar os logs no sentido de detectar se outros sistemas estão em risco. Em principio todos os endereços de destino registados nos logs do sniffer estão em risco, e mais ainda se a sessão envolver a entrada no sistema remoto.
6. Verificar outros sistema próximos
É conveniente verificar sinais de intrusão noutros sistemas da mesma rede, ou em sistemas que tenham configuradas relações de confiança com o sistema comprometido. Essas relações de confiança podem passar, por exemplo, por entradas automáticas via SSH.

Sugere-se que os sistemas sejam verificados contra as seguintes listas de verificações:
- http://www.cert.org/tech_tips/intruder_detection_checklist.html (em Inglês)
- http://www.cert.org/tech_tips/win_intruder_detection_checklist.html (em Inglês)
7. Verificação de outros sistemas que podem estar comprometidos
É habitual haver uma cadeia de sistemas comprometidos, com um elemento padrão de exploração de uma vulnerabilidade descoberta recentemente. Se forem descobertos sistemas a montante ou a jusante do sistema comprometido, que sejam suspeitos de estar envolvidos no incidente, recomenda-se que sejam essas ocorrências reportadas aos CSIRTs correspondentes. É bem possível que esses sistemas também estejam comprometidos, e que os responsáveis não tenham ainda conhecimento da situação.

D. Contacto dos CSIRTs relevantes envolvidos no incidente

1. Reporte de incidentes
Os intrusos usam frequentemente contas comprometidas para lançar ataques a outros locais. Se encontrar evidência dum compromisso de segurança ou de actividades de intrusão, deve contactar os sites envolvidos, no sentido de informar a descoberta, e de alertar para que a actividade detectada pode indiciar que outros sistemas estejam comprometidos. Nesse contacto devem ser indicados os detalhes úteis como por exemplo das datas/horas, não esquecendo o fuso horário, e o método de intrusão.
2. Obter os contactos
Para obter os contactos do CERT.PT, consultar a página http://www.cert.pt.

Para obter contactos de outras equipas de segurança na Europa, poderá consultar a lista de CSIRTs no sítio: http://www.ti.terena.nl/.

Para obter contactos de outras equipas de segurança, poderá consultar a lista do Forum of Incident Response and Security Teams (FIRST) em http://www.first.org/team-info/.

Para obter os contactos de um domínio abaixo de .PT, deve utilizar-se o servidor WHOIS, disponível em whois.dns.pt, ou então consultar as páginas em www.dns.pt.

Para obter os contactos para um domínio em .COM, .EDU, ou .ORG, sugere-se o seguinte sítio: http://www.internic.net/whois.html

Para obter contactos das regiões da Asia-Pacifico e Austrália, sugerem-se os seguintes sítios:
- http://www.apnic.net/apnic-bin/whois.pl
- http://www.aunic.net/cgi-bin/whois.aunic
Não se recomenda o envio de emails para endereços no sistema suspeito de estar comprometido, como por exemplo “root”, “admin”, ou “postmaster”, pois esses emails poderão ser interceptados pelo intruso.

E. Recuperar da intrusão

1. Instalar uma versão limpa do sistema operativo
Note-se que se o sistema estiver comprometido, a única forma de voltar a obter confiança nele é através de uma reinstalação de raiz, a partir dos suportes de distribuição livres da possibilidade de adulteração, como por exemplo CD-ROMs. Simplesmente resolver a vulnerabilidade de origem da intrusão e outros problemas relacionados, e depois manter atenção redobrada no sistema durante algum tempo, não é suficiente porque não se teria a certeza de que todas as backdoors e outras situações teriam sido resolvidas. É pouco fiável verificar-se a integridade do sistema utilizando-se um sistema comprometido. Mesmo fazendo-se um boot de um sistema operativo limpo para verificar a integridade do sistema comprometido, é muito plausível escapar a essa análise algum pormenor importante, que depois permita a recaída do sistema.

Neste passo não se recomenda ainda que sejam recuperados os dados dos backups.
2. Desligar serviços desnecessários
O sistema terá uma utilização prevista à qual está associada um conjunto de serviços. Outros serviços que tenham sido instalados automaticamente devem ser desligados, e, se possível, desinstalados. Apenas os serviços necessários ao funcionamento previsto do servidor devem estar ligados. Se for possível, deve adoptar-se a atitude conservadora de desligar inicialmente todos os serviços, e ligar um a um, à medida das necessidades.

Aconselha-se também que sejam verificadas as configurações no sentido de detectar e resolver fragilidades de configurações, como por exemplo, utilizadores sem password, acessos sem controlo, falta de logging, etc.
3. Instalação de remendos dos fabricantes de software
Este passo consiste em aplicar remendos de segurança aos serviços instalados. Sem este passo, o sistema pode estar à partida vulnerável a problemas de segurança que foram sendo descobertos e resolvidos.

É também aconselhável que regularmente seja verificado se novos remendos de segurança foram sendo libertados, e se devem ou não ser instalados. Para este efeito recomenda-se a consulta dos sites dos fabricantes, mais os seguintes:
4. Cautelas na reposição a partir dos backups
Existe o potencial da reposição a partir dos backups reintroduzir as vulnerabilidades de segurança. Para minimizar este risco deve haver o cuidado para não esmagar os executáveis, configurações e bibliotecas instalados e refinados com os preceitos referidos anteriormente.

No caso da percepção de risco ser muito alta relativamente a recuperar dados dos backups, recomenda-se a seguinte abordagem:
- Realizar um backup total, etiquetá-lo e armazenar em local seguro
- Instalar um sistema IDS local, que possa ser usado para comparar diferenças entre o sistema antes e depois de se recuperar o backup
- Fazer as recuperações para um directório separado, e depois fazer cópias ou movimentos cuidadosos para os locais definitivos no sistema de discos. Tenta-se desta forma evitar o esmagamento por acidente de executáveis, configurações e bibliotecas, ou introduzir novos serviços desnecessários, etc.
- Após a recuperação dos backups:
  - a) fazer uma vistoria ao sistema em busca de situações suspeitas – consultar secção “C”; e
  - b) usar o sistema IDS para verificar a existência de diferenças suspeitas no S.O.
5. Mudança de passwords
Depois dos problemas de segurança terem sido resolvidos, é aconselhável que sejam mudadas as passwords de todas as contas nos sistemas afectados. As passwords não devem ser fáceis de adivinhar por entidades não autorizadas.

F. Melhorar a segurança do sistema e da rede

1. Rever a segurança usando documentos guia
- http://www.cert.org/tech_tips/unix_configuration_guidelines.html (em Ingês)
- http://www.cert.org/tech_tips/win_configuration_guidelines.html (em Inglês)
2. Ferramentas de segurança
A ligação seguinte contém uma listagem de ferramentas de segurança que podem ajudar na tarefa de robustecer a instalação - http://www.cert.org/tech_tips/security_tools.html (em Inglês)
3. Configuração de logging
Verificar que o logging está activado para os serviços configurados. Nesta fase é conveniente que o nível de logging seja alto, dentro das limitações do sistema em espaço, CPU e outras. Para maior segurança da integridade dos logs, pode considerar-se a opção de enviar os logs para outro servidor, ou então de os enviar para dispositivos que não suporte o apagamento (cd-rom, impressoras de contínuo, ou outros.)
4. Configuração de firewalls
É recomendável a configuração de firewall para que se melhor se controle o acesso aos sistemas.

G. Ligação à Internet

Após se completarem os passos descritos atrás, o sistema pode voltar a ser ligado à Internet.

H. Actualização da política de segurança

É aconselhável que cada site tenha adoptado uma política de segurança, e, se possível, alinhada com o que é proposto no RFC2196.

Se tal política não existir na forma escrita, o conhecimento arrecadado com a recuperação de uma intrusão, e nomeadamente o seu custo, poderá ser a base motivadora para a elaboração de um documento desta natureza.

Se a política de segurança já existir, e lhe forem introduzidas mudanças, é aconselhável que as alterações sejam devidamente propagadas às entidades afectadas por essa política.

---------------------------------
Adaptação do título original “Steps for Recovering from a UNIX or NT System Compromise”, disponível em http://www.cert.org/tech_tips/win-UNIX-system_compromise.html

Autenticação Federada

Missão

O CERT.PT tem como missão contribuir para o esforço de cibersegurança nacional nomeadamente no tratamento e coordenação da resposta a incidentes, na produção de alertas e recomendações de segurança e na promoção de uma cultura de segurança em Portugal.

PT EN