Não acontece só aos outros.


Um vista de olhos no MRTG nunca engana:






e sobre a máquina encontramos:




Visivelmente o hacker pode lançar programas em root. A máquina está então hackada e deve ser reinstalada.




Existe programas em execução, que têm um pid e que não conseguem ser vistos através do ps, certamente porque ps foi substituído por um ps hackado que filtra todos os programas do hacker para enganar.



Paramos imediatamente a máquina.

Com sorte temos uma máquina apenas Semi Hackada.

Ver também: Exemplo de Máquina Hackada .



As origens dos problemas são múltiplos, mas podemos resumi-los desta forma:

• Utiliza telnet. O seu login e password circulam pela Internet em claro e podem ser apanhados a todo momento. Deve utilizar ssh. O seguinte guia fala sobre este assunto: SshSobreServidorDedicado.

• Utiliza ftp. O seu login e password circulam pela Internet em claro e é a mesmo que a password root. Sftp é a sua solução.

• Utiliza pop3/imap com a password (que circula sem encriptação) e é a password root. Utilize APOP ou POP3S/IMAPS. O seguinte guia trata sobre este assunto: SmtpPop3Imap.

Se não actualiza a sua máquina com releases ReleasePatchSeguranca, arrisca a ter a sua máquina hackada (mais ou menos 250 scans são efectuados por dia sobre a nossa rede no âmbito de detectar as falhas de segurança).



Em caso de hack, o seu servidor será posto em modo de rescue FTP automaticamente, e receberá os seus códigos de acesso por e-mail.

Poderá ainda pedir ao suporte para passar o seu servidor para o modo de Rescue, unicamente por ticket incidente, justificando ainda o seu pedido e a sua plena consciência que deverá corrigir o problema antes de re-activar o servidor. Estaremos atentos para o facto de que precisa corrigir as falhas antes de colocar o servidor em funcionamento normal da rede (modo HDD) .



Falha de script CGI

Os sintomas
Um ficheiro g00dies.tgz transferido na pasta /tmp com outros ficheiros x, k, etc...
O programa x é um backdoor. Se executado dará acesso a máquina.
Encontramos o bash.history do utilizador nobody em /tmp, cujo o conteúdo é:



O que se constata
Conseguimos ver que foram executados comandos em nobody, porém este utilizador é essencialmente utilizado por Apache. Parece que o hacker aproveitou de uma vulnerabilidade de um script CGI.


Resolução
- Kill de todos os processos suspeitos em curso.
O hacker pelos visto não passou por root (pode aproveitar uma falha de um kernel<2.4.24), no entanto, fazermos algumas operações/verificações elementares:

• Mudar todas as password: root, user, mysql, mail, etc... (vemos que o hacker executou mingetty)
• Fazer uma procura exaustiva dos ficheiros modificados pelo hack: find /rep -cmin -60 (verifica os ficheiros modificados há menos de uma hora).

- Consulte depois os logs de Apache por volta da hora na qual houve esse hack para encontrar o script em causa.