Como detectar um processo oculto no linux?

Question

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 saber onde os bons lugares para procurar, como o problema, podem estar?

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

O que podemos fazer para localizar o problema infantil? O que podemos fazer para nos proteger disso no futuro? Existe algum monitoramento que possamos executar para nos informar disso no futuro? (Além do monitoramento de rede em que já estamos trabalhando para ficar de olho.)

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

    

Answer 1

Você não pode confiar em nenhuma ferramenta de sistema que você tenha na máquina. Os rootkits substituirão ps, netstat, ls e muito mais para ocultar sua presença. Você deve deixar a máquina offline, retirar seu disco rígido, fazer uma cópia forense (pense em dd) e depois trabalhar em uma máquina virtual para procurar pelo rootkit.

Se você insistir em trabalhar na máquina ao vivo (o que geralmente é fútil), então você pode tentar baixar uma distribuição de recuperação em CD (é muito importante que a cópia seja somente leitura) e usar 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 o ps normalmente operam.

Boa sorte!

    

Answer 2

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 a partir da fonte ou na forma de binairies. (Certifique-se de estar bem assinado). Mas o truque de um kit de root (eu vi isso) é que eles talvez corromperam o seu compilador também. Então, quando o compilador sabe que ele está compilando ls ou ps ou qualquer comando, ele os infecta também.

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

Você vai dizer que isso é grande e difícil de detectar, mas é raro o kit de root que é tão à prova de balas que acabei de lhe dar o pior caso.

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

    

Answer 3

A melhor maneira de saber se o seu servidor foi "enraizado" é rodar um sistema de detecção de invasões baseado em host (HIDS). Infelizmente, se você não estiver executando um HIDS agora, então é tarde demais para instalar um. O momento adequado para instalar um HIDS é quando o servidor é instalado pela primeira vez e antes é 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. Então, periodicamente, o HIDS redimensiona seu sistema, comparando todos os arquivos em seu banco de dados de linha de base com os arquivos de sistema atuais.

Sim, é claro, é possível que um rootkit modifique seu banco de dados de linha de base, e é por isso que você precisa fazer uma cópia desse banco de dados e armazená-lo separadamente do servidor antes de colocar o banco de dados servidor online. Então, se você suspeitar que está "enraizado" (e suspeitar que seu banco de dados de base também foi adulterado), poderá inicializar seu sistema a partir da mídia de instalação, restaurar o banco de dados em bom estado de seu backup e executar uma verificação bem conhecido. É muito mais provável, no entanto, que um rootkit não tenha antecipação de ter que derrotar seus HIDS particulares, e assim você receberá uma notificação dos 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, você não tem nenhuma maneira rápida de determinar se você foi rooteado ou quais arquivos do sistema foram modificados. Você pode gastar muito tempo comparando seus arquivos de sistema com os arquivos conhecidos de boa qualidade retirados de uma mídia de instalação de boa qualidade, mas é mais provável que esse tempo seja mais bem gasto reinstalando o sistema a partir dessa mídia. Se você quer investigar como você foi enraizado após o fato, o melhor caminho é tirar uma foto do seu sistema antes de limpá-lo e reinstalá-lo.

    

Answer 4

Por favor, consulte um post anterior feito

Pain remove um rootkit perl

É realmente importante que você leia isso ...

Para responder às suas perguntas ...

Eu geralmente uso um IDS / IPS (sistema de detecção / proteção de intrusão) como snort. faz um ótimo trabalho contra o jogo sujo, e eu vi isso 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 os problemas e as alterações / ser rootkit'd

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

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

Espero que isso ajude ..: D

    

Answer 5

As portas altas aleatórias são as portas efêmeras, o que indica que você provavelmente tem uma ou mais conexões de programas externas deste sistema.

Se não estiver enraizado, netstat -np | grep -v ^unix poderá fornecer uma pista sobre quais programas estão gerando o tráfego.

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

Existem várias coisas que você pode fazer para evitar enraizar-se:

• Mantenha seu sistema com patches, especialmente o kernel. Monitora as razões da liberação do kernel para determinar os vetores de ataque.
• Instale e use apenas os programas necessários. Faça o mínimo de instalação possível.
• Execute o mínimo possível como root. Muitos programas mudam para userids não privilegiados depois de concluírem a configuração que requer privilégios de root.

EDITAR: Se você estiver enraizado, usar programas ps e ls vinculados estaticamente pode indicar uma diferença entre os programas em execução encontrados pelas duas ferramentas. Diferenças na lista também podem surgir à medida que os programas de curta duração morrem.

    

Answer 6

A correção real para um sistema que pode ser enraizado é reinstalá-lo a partir de fontes seguras. Como os CDs de instalação. Em seguida, restaure seus dados somente 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. Então copie e insira.

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 por interceptações syscall) e outros recursos. Pode ter scripts que pegarão a saída do módulo e a compararão com a saída de ps, netstat, ls, etc. Ou poderá examinar a memória no espaço do kernel para obter assinaturas de rootkits conhecidas e reportar.

    

Answer 7

Isso é como um rato: se você vê um, tem cem pessoas vivendo lá. Se você vir sinais de comprometimento, deve assumir que todo o sistema está comprometido. É por isso que todos estão sugerindo que você reinstale o sistema em vez de gastar muito tempo procurando. Eu encontrei várias situações em que uma máquina foi comprometida e os administradores achavam que tinham limpado a bagunça, apenas para se arrepender depois.

É muito comum os rootkits substituírem os binários do sistema, como ps, top, netstat. E também é comum ao trojan ssh. Portanto, procurar por esquisitices de checksum nesses arquivos é uma abordagem primordial. Se você estiver em um sistema baseado em rpm, o rpm -V geralmente é uma boa ferramenta, ou o dpkg-verify no Debian / Ubuntu. Ou você pode checar os checksums diretamente (mas fique de olho no prelink, o que muda os binários rapidamente por razões de velocidade). Isso não é confiável, mas muitos ataques 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 para procurar: portas mostradas abertas de um nmap externo que não parece aberto via netstat na máquina, e pids em /proc que não aparecem em ps . E se você tiver o syslog remoto ativado, procure por logins ssh que não possuem registros no lastlog.

    

Answer 8

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 rodar mod_security também na sua camada Apache junto com um firewall. Normalmente, eles encontram um webapp ou script desatualizado e melhoram o acesso a partir dele com scripts de shell Perl e outras coisas divertidas.

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

Além disso: netstat -anp para ver o que está escutando em certas portas.

Novamente, eles são bons se você não tiver sido enraizado, apenas comprometido.