Como detectar um processo oculto no linux?

Temos uma caixa que suspeitamos estar enraizada no trabalho. A questão é como a encontramos? Não sou administrador do sistema, mas fui trazido para a equipe para resolver a situação e estou curioso para encontrar bons lugares para procurar, como problemas?

A razão pela qual suspeitamos disso é que notamos uma utilização de rede mais alta do que o normal na máquina a partir de portas altas (o que parecem ser aleatórias).

O que podemos fazer para localizar o filho problemático? O que podemos fazer para proteger isso no futuro? Existe monitoramento que possamos executar para nos conscientizar disso no futuro? (Além do monitoramento de rede em que já estamos trabalhando, fique de olho.)

Agradecemos antecipadamente e posso fornecer mais detalhes, se necessário. Aprecie seu tempo.

Você não pode confiar em nenhuma ferramenta do sistema que tenha na máquina. Os rootkits substituirão ps, netstat, ls e mais para ocultar sua presença. Você deve colocar a máquina offline, retirar o disco rígido, fazer uma cópia forense (pense em dd) e trabalhar a partir dela em uma máquina secundária para procurar o rootkit.

Se você insistir em trabalhar na máquina ao vivo (que geralmente é inútil), poderá tentar fazer o download de uma distribuição de resgate em CD (é muito importante que a cópia seja somente leitura) e use suas cópias de ps, lsmod etc.

Mesmo isso pode falhar, pois um rootkit pode instalar módulos do kernel para ocultar entradas no / proc onde ferramentas como ps normalmente operam.

Boa sorte!

O problema com o rootkit bem construído é que eles modificam o comando do seu sistema; como ps e top para não mostrar os processos do rootkit e ls para não mostrar arquivos do rootkit.

Então, o que você precisa fazer é obter esses comandos possivelmente da fonte ou na forma binairies. (Certifique-se de estar bem assinado). Mas o truque de um kit raiz (eu já vi) é que eles talvez tenham corrompido seu compilador também. Portanto, quando o compilador sabe que está compilando ls ou ps ou qualquer comando, ele também os infectará.

Quando vi esse problema, disse que tudo bem, recompile o gcc, mas não é o que eu preciso para compilar o gcc ... o infecte gcc ... então, quando ele sabe que está se compilando, ele o infecta para que ele possa infectar o comando.

Você dirá que isso é grande e difícil de detectar, sim, mas são raros os kits de raiz que são tão à prova de balas que acabei de lhe dar o pior caso.

Sério, se você tem certeza de que existe um kit raiz no seu servidor, reinstale-o!

A melhor maneira de saber se o servidor foi "enraizado" é estar executando um sistema de detecção de intrusão (HIDS) baseado em host. Infelizmente, se você não estiver executando um HIDS agora, será tarde demais para instalar um. O momento apropriado para instalar um HIDS é quando o servidor é instalado pela primeira vez e antes de ser colocado em uma rede.

Resumidamente, a maioria dos HIDS trabalha computando hashes criptográficos de todos os binários do sistema e armazenando esses hashes (junto com várias outras estatísticas de arquivos) em um banco de dados, chamado banco de dados de linha de base. Em seguida, periodicamente, o HIDS resgata seu sistema, comparando todos os arquivos em seu banco de dados de linha de base com os arquivos reais do sistema.

Sim, é claro, é possível que um rootkit modifique seu banco de dados de linha de base, e é por isso que você precisa tirar uma cópia desse banco de dados e armazená-lo separadamente do servidor antes de colocá-lo online. Então, se você suspeitar que está "enraizado" (e suspeitar que seu banco de dados de linha de base também foi violado), você pode inicializar o sistema a partir da mídia de instalação, restaurar o banco de dados em bom estado a partir do backup e executar uma varredura no bem conhecido. É muito mais provável, no entanto, que um rootkit não preveja a derrota de seu HIDS específico e, portanto, você receberá uma notificação do HIDS de que os arquivos do sistema foram alterados, indicando uma provável invasão do sistema.

Como você não estava executando um HIDS, não há uma maneira rápida de determinar com certeza se você está enraizado ou quais arquivos do sistema foram modificados. Você pode gastar muito tempo comparando os arquivos do sistema com arquivos em boas condições extraídos da mídia de instalação em boas condições, mas esse tempo provavelmente é mais bem gasto na reinstalação do sistema a partir dessa mídia. Se você deseja investigar como ficou enraizado após o fato, o melhor caminho é tirar uma imagem do seu sistema antes de limpá-lo e reinstalá-lo.

Consulte um post anterior feito

Dor ao remover um rootkit perl

É realmente importante que você leia isso ..

Quanto a responder suas perguntas ..

Normalmente, eu executo um IDS / IPS (sistema de detecção / proteção contra intrusões) como o snort .. ele faz um ótimo trabalho contra jogo sujo e eu o vi fazendo um ótimo trabalho em ação ..

Eu também uso Servidores Syslog para manter as mensagens de log fora dos servidores de produção, para que você possa rastrear problemas e alterações / sendo rootkit'd

Também estou frequentemente usando ferramentas de gerenciamento, como cactos, que representam graficamente a CPU, a memória, o disco, o uso da rede e informam se algo está fora do comum.

Ser rootkit'd é um problema sério, definitivamente tente descobrir a causa ..

Espero que isso ajude ..: D

As portas altas aleatórias são as portas efêmeras, o que indica que você provavelmente tem um ou mais programas conectados externamente a partir deste sistema.

Se não estiver enraizado, netstat -np | grep -v ^unixpoderá dar uma dica sobre quais programas estão gerando tráfego.

Você também pode verificar o tráfego de um sistema próximo usando o tcpdump para despejar pacotes originários do sistema que você acredita estar enraizado. Se o programa com problemas não estiver sendo executado como root, você pode fazer isso no sistema infectado.

Existem várias coisas que você pode fazer para evitar ficar enraizado:

• Mantenha seu sistema corrigido, especialmente o kernel. Monitore os motivos da liberação do kernel para determinar os vetores de ataque.
• Instale e use apenas os programas necessários. Faça a instalação mínima possível.
• Execute o mínimo possível de root. Muitos programas serão alterados para IDs de usuários sem privilégios depois de concluírem a configuração que exige privilégios de root.

EDIT: Se você está enraizado, o uso de programas ps e ls vinculados estaticamente pode indicar uma diferença entre os programas em execução encontrados pelas duas ferramentas. As diferenças na lista também podem surgir à medida que programas de curta duração desaparecem.

A correção real para um sistema que pode estar enraizado é reinstalá-lo de fontes seguras. Como os CDs de instalação. Em seguida, restaure seus dados apenas do backup. Quaisquer binários ou scripts no seu backup podem ter sido comprometidos e salvos no seu backup.

Para encontrar o kit raiz em um sistema em execução, uma maneira de fazer isso é compilar um módulo do kernel projetado para detectar rootkits. Compile-o em uma máquina diferente que esteja executando a mesma versão do sistema operacional. Em seguida, copie-o e insmod-lo.

Um detector de rootkit terá ferramentas embutidas no módulo do kernel para despejar a tabela de processos em execução, verificar a tabela syscall (para procurar interceptações do syscall) e outros recursos. Pode haver scripts que pegam a saída do módulo e a comparam com a saída do ps, netstat, ls, etc. Ou pode verificar a memória no espaço do kernel em busca de assinaturas e relatórios de rootkit conhecidos.

É como ratos: se você vir um, há cem vivendo lá. Se você perceber sinais de um comprometimento, deve presumir que todo o sistema está comprometido. É por isso que todo mundo está sugerindo que você reinstale o sistema, em vez de gastar muito tempo procurando. Eu encontrei várias situações em que uma máquina estava comprometida e os administradores de sistemas pensaram que tinham limpado a bagunça, apenas para se arrepender mais tarde.

É muito comum que os rootkits substituam os binários do sistema, como ps, top, netstat. E também é comum o Trojan ssh. Portanto, procurar esquisitices de soma de verificação nesses arquivos é uma abordagem privilegiada. Se você estiver em um sistema baseado em rpm, o rpm -V geralmente é uma boa ferramenta ou o dpkg-verifique no Debian / Ubuntu. Ou você pode verificar as somas de verificação diretamente (mas fique atento ao pré-link, que altera os binários em tempo real por motivos de velocidade). Isso não é confiável, mas muitos ataques de script-kiddie não cobrem esses traços. (Em outras palavras, se você encontrar algo, bom. Se você não encontrar algo, isso não prova que você está limpo.)

Outras coisas a procurar: portas mostradas abertas de um externo nmapque não parecem abertas netstatna máquina e pids nas /procquais não aparecem ps. E se o syslog remoto estiver ativado, procure logins ssh que não tenham registros no lastlog.

Pegue uma cópia do RKhunter e do chkrootkit. Eles geralmente são bastante decentes em ajudar a encontrar coisas que não deveriam estar lá.

É sempre bom executar o mod_security também na sua camada Apache, juntamente com um firewall. Geralmente eles encontram um aplicativo ou script desatualizado e aprimoram o acesso a partir daí com scripts de shell Perl e outras coisas divertidas.

O ps auxfww geralmente é ótimo para encontrar processos que não pertencem.

Também: netstat -anp para ver o que está escutando em determinadas portas.

Novamente, isso é bom se você não estiver enraizado, apenas comprometido.