Diretórios temporários suspeitos no CentOS 5.5

Question

Acabei de notar alguns diretórios estranhos armazenados em ambos os /tmp em duas das minhas caixas CentOS.

Em uma máquina, o diretório temp é chamado /tmp/www4-679109 , enquanto na segunda máquina o diretório temp é /tmp/sos_e6X9_3 .

Ambos os diretórios suspeitos contêm quatro subdiretórios: etc proc sys var.

A pasta etc nesta árvore de diretórios suspeitos contém uma cópia idêntica do meu arquivo de configuração master send.cf sendmail. /tmp/sos_e6X9_3/etc/mail/submit.cf e /etc/mail/submit.cf . Isso me faz pensar que de alguma forma o sendmail foi usado para retransmitir mensagens. Embora eu não consiga verificar se os arquivos do maillog foram inconclusivos, este foi o caso.

Além disso, este diretório estranho suspenso contém algum tipo de arquivo de log de auditoria dentro dele. ( /tmp/sos_e6X9_3/var/log/audit/audit.log.1 )

Snippet de conteúdo de um arquivo de log:

type=LOGIN msg=audit(1293719401.416:2772543): login pid=6662 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=557197
type=LOGIN msg=audit(1293719401.417:2772544): login pid=6660 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=557198
type=LOGIN msg=audit(1293719401.418:2772545): login pid=6649 uid=0 old auid=4294967295 new auid=599 old ses=4294967295 new ses=557199
type=LOGIN msg=audit(1293719401.420:2772546): login pid=6665 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=557200
type=USER_ACCT msg=audit(1293719401.423:2772547): user pid=6668 uid=0 auid=4294967295 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='PAM: accounting acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'
type=USER_START msg=audit(1293719401.424:2772548): user pid=6653 uid=0 auid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='PAM: session open acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'

O que mais me preocupa com esses arquivos e diretórios suspeitos nas minhas caixas do CentOS é que parece que o diretório deles é procfs em /tmp/sos_e6X9_3/proc . A única diferença com /tmp/sos_e6X9_3/proc e /proc é que, no /tmp/sos_e6X9_3/proc , não há informações visíveis sobre o processo.

Mantive as duas máquinas CentOS atualizadas e não altero o sendmail, o que poderia torná-lo vulnerável (a menos que o sendmail esteja vulnerável).

Alguém tem alguma idéia / feedback sobre por que esses arquivos temporários e pastas suspeitos foram criados?

ATUALIZAÇÃO: Parece que os arquivos suspeitos foram gerados pelo utilitário sosreport quando estávamos trabalhando com o suporte da Red Hat em um problema diferente. Verifiquei o log e os carimbos de data e hora correspondem ao timestamp com os arquivos e diretórios suspeitos. Obrigado pelo seu apoio e feedback. Vocês são demais!

    

Answer 1

O diretório sos encontrado em / tmp é criado quando o comando sosreport é executado. Este é um utilitário da Red Hat que coleta informações do sistema que são úteis para o Suporte da Red Hat ao solucionar problemas do seu sistema. Isso, até onde eu sei, não é útil no CentOS, mas como o CentOS é baseado no RHEL, é por isso que existe (suposição).

Edit: Eu senti falta da sua impressão negrito dizendo que você descobriu que ela lida com o sosreport.

    

Answer 2

Eu definitivamente rodaria 'chkrootkit' e 'rkhunter' imediatamente. Se você pode baixar um binário para netstat, lsof, ls, less e ps e executá-los diretamente, então você terá uma idéia melhor do que as caixas estão fazendo.

Observe que esses binários baixados e limpos só devem ser confiáveis para essa sessão de login. Faça o download deles toda vez que precisar deles. Eu vi arquivos sobrescritos em cada login após um compromisso.

Se você puder firewallar tudo, exceto o IP de administrador do SSH por alguns minutos, melhor será o desempenho desses testes.

Durante sua busca cuidadosa ao redor da máquina, procure QUALQUER coisa diferente. Desde a saída de cor formatada de 'top' até a velocidade 'w' carregada.

    

Answer 3

Não importa se você realmente encontra um rootkit, gostaria de:

1. alterar todas as senhas relevantes no ambiente,
2. reinicialize o boxen em um CD ao vivo e grave a imagem completa do disco na rede em algum lugar para análise posterior,
3. esfregue os discos usando dd if = / dev / zero de = / dev / < whatever & gt ;. Certifique-se de substituir o MBR,
4. reinstale usando um repositório público ,
5. analise a imagem para tentar descobrir o que aconteceu e
6. comunique as conclusões a alguma câmara de compensação relevante.

Sim, isso é um pouco paranóico, mas normalmente é um caminho mais rápido para a recuperação do que tentar estudar o problema e ser inteligente.

Parece que o OP é um servidor de e-mail. Se assim for, você tem um problema adicional em que a caixa pode estar enviando correio contaminado. Eu não liberaria minhas filas de correio até ter certeza absoluta de que ele não estava sendo reescrito no caminho.