Procurando rootkits no seu sistema
Rootkits são ferramentas utilizadas, geralmente, com o objetivo de ocultar a presença de invasores nas máquinas. Com essas ferramentas alguém não-autorizado, mas que já conseguiu entrar na máquina, pode ter controle sobre a mesma e nem ser notado. Neste artigo eu mostro como procurar rootkits no seu sistema.
[ Hits: 69.824 ]
Por: Hugo Doria em 11/06/2008 | Blog: http://hugodoria.org
Introdução
Rootkits são ferramentas utilizadas, geralmente, com o objetivo de ocultar a presença de invasores nas máquinas. Com essas ferramentas alguém não-autorizado, mas que já conseguiu entrar na máquina, pode ter controle sobre a máquina e nem ser notado.
Muitos rootkits acompanham uma gama de binários (como o ls, ps, who, find etc) modificados para que os processos rodados pelo invasor não possam ser vistos pelo administrador da máquina. Além disso, muitos vírus atuais utilizam rootkits.
Existem dois aplicativos que podem te ajudar a detectar rootkits no seu sistema: rkhunter e chkrootkit. A seguir eu mostro como instalar e executar ambos.
# pacman -Sy rkhunter
No Ubuntu (e derivados):
# apt-get install rkhunter
Antes de checar o sistema com o rkhunter, execute os dois comandos abaixo:
# rkhunter --propupda
# rkhunter --update
O primeiro comando atualiza a base com as propriedades dos arquivos e o segundo atualiza a base do rkhunter.
Depois de tudo atualizado você pode checar seu sistema com o comando:
# rkhunter -c
A saída do rkhunter é colorida e bem simples de se ler. Ele checa diversas coisas no sistema e sempre que um item estiver OK (ou Not found), ele marca em verde. Quando não, aparece um WARNING em vermelho.
Se você quiser que apenas os WARNINGs aparecem na tela faça:
# rkhunter -c --rwo
No final de tudo o rkhunter mostra um resumo do que aconteceu:
Todo o log da operação é armazenado, por padrão, em /var/log/rkhunter.log. Você pode sempre consultá-lo. Para mudar o arquivo do log use:
# rkhunter -c -l /caminho/para/seu/arquivo.log
Você pode, também, fazer com que o rkhunter te envie um email sempre que encontrar algum WARNING. Para isso abra o arquivo /etc/rkhunter.conf e procure a linha que começa com "#MAIL-ON-WARNING". Descomente-a e atribua seu email a ela. Fica algo assim:
Acho que isto é suficiente para que você possa rodar o rkhunter com sucesso. ;)
Recomendo que você dê uma olhada na man page. Lá, e no site do rkhunter, você pode encontrar estas e outras opções com mais detalhes:
$ man rkhunter
Muitos rootkits acompanham uma gama de binários (como o ls, ps, who, find etc) modificados para que os processos rodados pelo invasor não possam ser vistos pelo administrador da máquina. Além disso, muitos vírus atuais utilizam rootkits.
Existem dois aplicativos que podem te ajudar a detectar rootkits no seu sistema: rkhunter e chkrootkit. A seguir eu mostro como instalar e executar ambos.
Usando o rkhunter
Para instalar o rkhunter faça. No Arch Linux:# pacman -Sy rkhunter
No Ubuntu (e derivados):
# apt-get install rkhunter
Antes de checar o sistema com o rkhunter, execute os dois comandos abaixo:
# rkhunter --propupda
# rkhunter --update
O primeiro comando atualiza a base com as propriedades dos arquivos e o segundo atualiza a base do rkhunter.
Depois de tudo atualizado você pode checar seu sistema com o comando:
# rkhunter -c
A saída do rkhunter é colorida e bem simples de se ler. Ele checa diversas coisas no sistema e sempre que um item estiver OK (ou Not found), ele marca em verde. Quando não, aparece um WARNING em vermelho.
Se você quiser que apenas os WARNINGs aparecem na tela faça:
# rkhunter -c --rwo
No final de tudo o rkhunter mostra um resumo do que aconteceu:
Todo o log da operação é armazenado, por padrão, em /var/log/rkhunter.log. Você pode sempre consultá-lo. Para mudar o arquivo do log use:
# rkhunter -c -l /caminho/para/seu/arquivo.log
Você pode, também, fazer com que o rkhunter te envie um email sempre que encontrar algum WARNING. Para isso abra o arquivo /etc/rkhunter.conf e procure a linha que começa com "#MAIL-ON-WARNING". Descomente-a e atribua seu email a ela. Fica algo assim:
MAIL-ON-WARNING=fulano@empresa.com
Acho que isto é suficiente para que você possa rodar o rkhunter com sucesso. ;)
Recomendo que você dê uma olhada na man page. Lá, e no site do rkhunter, você pode encontrar estas e outras opções com mais detalhes:
$ man rkhunter
Páginas do artigo
1. Introdução2. Usando o chkrootkit
3. E se achar rootkits?
Outros artigos deste autor
Como criar pacotes para o Arch Linux (parte 2) - pacotes svn e cvs
ProFTPD com autenticação via MySQL
KDEmod: Tornando mais simples o KDE do seu Arch Linux
Leitura recomendada
Testando configurações e segurança do Apache com Nikto
Integração de servidores Linux com Active Directory
Metasploit - Instalação e utilização em ambiente GNU/Linux
Gerenciar e configurar inetd e serviços relacionados
Alta disponibilidade com IP compartilhado - UCARP
Comentários
[1] Comentário enviado por y2h4ck em 11/06/2008 - 10:23h
"Caso algum rootkit (não o warning) seja encontrado, minha sugestão é: Faça backup de arquivos pessoais e formate a máquina."
Eu apenas sou da seguinte opnião, se um atacante teve tempo pra colocar um rootkit em sua máquina ( ou seja ... ele precisa de acesso uid=0(root) para modificar o sistema), nem faça backup de nada, pois se vc não tinha backups ... essa não é a melhor hora pra faze-los pois o atacante pode esconder algum código malicioso (uma backdoor, um trojan, ou anyshit like this) junto aos seus arquivos.
E ao contrário do que muitos podem pensar ao lerem este comentário, esta tática é muito adotada. Qual o melhor jeito de garantir o acesso a um sistema do que escondendo seu acesso junto aos "queridos arquivos" do root do sistema :)
Gostei do seu artigo, 2 ferramentas muito boas.
[]
Anderson
"Caso algum rootkit (não o warning) seja encontrado, minha sugestão é: Faça backup de arquivos pessoais e formate a máquina."
Eu apenas sou da seguinte opnião, se um atacante teve tempo pra colocar um rootkit em sua máquina ( ou seja ... ele precisa de acesso uid=0(root) para modificar o sistema), nem faça backup de nada, pois se vc não tinha backups ... essa não é a melhor hora pra faze-los pois o atacante pode esconder algum código malicioso (uma backdoor, um trojan, ou anyshit like this) junto aos seus arquivos.
E ao contrário do que muitos podem pensar ao lerem este comentário, esta tática é muito adotada. Qual o melhor jeito de garantir o acesso a um sistema do que escondendo seu acesso junto aos "queridos arquivos" do root do sistema :)
Gostei do seu artigo, 2 ferramentas muito boas.
[]
Anderson
[2] Comentário enviado por thiagodvp em 11/06/2008 - 12:11h
"Caso algum rootkit (não o warning) seja encontrado, minha sugestão é: Faça backup de arquivos pessoais e formate a máquina."
Não concordo com a frase acima, se achar um rootkit, primeiro tem que saber como ele conseguiu entrar no sistema. Tem que combater a causa e não a consequencia.
Se vc formatar o sistema sem saber da causa vai continuar com uma brecha que provavelmente será explorada novamente.
Com excessão dessa ultima parte, gostei muito do artigo
Parabéns
"Caso algum rootkit (não o warning) seja encontrado, minha sugestão é: Faça backup de arquivos pessoais e formate a máquina."
Não concordo com a frase acima, se achar um rootkit, primeiro tem que saber como ele conseguiu entrar no sistema. Tem que combater a causa e não a consequencia.
Se vc formatar o sistema sem saber da causa vai continuar com uma brecha que provavelmente será explorada novamente.
Com excessão dessa ultima parte, gostei muito do artigo
Parabéns
[3] Comentário enviado por albfneto em 11/06/2008 - 12:42h
Taí, aprendendo... em windows, os rootkits são um tipo especial d emalware, não sabia que Linux pegava rootkits!
Taí, aprendendo... em windows, os rootkits são um tipo especial d emalware, não sabia que Linux pegava rootkits!
[4] Comentário enviado por hdoria em 12/06/2008 - 08:35h
Opa pessoal,
Boas dicas. Mas, infelizmente eu ainda acredito que neste caso é a melhor solução. É algo bem diferente de quando dá algum problema no sistema, hardware, módulo ou algo do tipo. Em situações como essa é possível resolver o problema apenas consertando algo aqui e ali, sem precisar formatar a máquina.
Invasão é algo bem além disso. Você não tem como saber o que o invasor fez na sua máquina ou o que foi infectado se você não tiver ferramentas adequadas. Só passar o anti-rookit não é suficiente, ainda mais se você estive usando-o da própria máquina infectada. O melhor jeito de evitar formatar (e situações do tipo) é usar uma série de ferramentas como tripwire, iptables, snort, analisador de logs, anti-rootkit, backups etc. Mas convenhamos: se você já usa corretamente boa parte delas, dificilmente você foi invadido.
Imagina você deixar um servidor de produção importantíssimo da sua empresa com vários rootkits. Simplesmente não dá. O melhor é, como falei, usar todas as ferramentas e ter uma política de backup. No dia que achar algum rootkit, se tem um backup de um momento imediatamente anterior para restaurar o sistema. E aí sim, você pode descobrir o que pode ter afetado sua segurança, restaurar o backup e consertar todos os problemas no sistema limpo. Enquanto isso sua empresa agradece.
Opa pessoal,
Boas dicas. Mas, infelizmente eu ainda acredito que neste caso é a melhor solução. É algo bem diferente de quando dá algum problema no sistema, hardware, módulo ou algo do tipo. Em situações como essa é possível resolver o problema apenas consertando algo aqui e ali, sem precisar formatar a máquina.
Invasão é algo bem além disso. Você não tem como saber o que o invasor fez na sua máquina ou o que foi infectado se você não tiver ferramentas adequadas. Só passar o anti-rookit não é suficiente, ainda mais se você estive usando-o da própria máquina infectada. O melhor jeito de evitar formatar (e situações do tipo) é usar uma série de ferramentas como tripwire, iptables, snort, analisador de logs, anti-rootkit, backups etc. Mas convenhamos: se você já usa corretamente boa parte delas, dificilmente você foi invadido.
Imagina você deixar um servidor de produção importantíssimo da sua empresa com vários rootkits. Simplesmente não dá. O melhor é, como falei, usar todas as ferramentas e ter uma política de backup. No dia que achar algum rootkit, se tem um backup de um momento imediatamente anterior para restaurar o sistema. E aí sim, você pode descobrir o que pode ter afetado sua segurança, restaurar o backup e consertar todos os problemas no sistema limpo. Enquanto isso sua empresa agradece.
[5] Comentário enviado por Yrrak em 12/06/2008 - 08:52h
Ótimo artigo, parabéns...
Só tenho um detalhe a comentar.
Para realizar o update do programa você indicou o comando "rkhunter --propupda" sendo que o certo é "rkhunter --propupd" sem o a no final.
Abraço
Ótimo artigo, parabéns...
Só tenho um detalhe a comentar.
Para realizar o update do programa você indicou o comando "rkhunter --propupda" sendo que o certo é "rkhunter --propupd" sem o a no final.
Abraço
[6] Comentário enviado por Teixeira em 12/06/2008 - 13:23h
Como em informática a lei de Murphy se encaixa como uma luva, sempre é bom:
- Manter os arquivos pessoais em outra partição; Assim, quando tiver realmente que reformatar, pelo menos esses arquivos estarão protegidos.
- Fazer backup regular (bem, backup bem protegido MESMO é aquele que é feito diariamente e guardado com cópias em outros prédios, em lados opostos da cidade, e com todos os requisitos físicos de segurança).
- Não acreditar que Linux seja inatacável por pessoas mal-intencionadas, inclusive dentro da LAN;
- Não sair navegando alegremente pela LAN ou principalmente pela WEB estando logado como 'root';
Gostei do artigo. Muito bom.
Como em informática a lei de Murphy se encaixa como uma luva, sempre é bom:
- Manter os arquivos pessoais em outra partição; Assim, quando tiver realmente que reformatar, pelo menos esses arquivos estarão protegidos.
- Fazer backup regular (bem, backup bem protegido MESMO é aquele que é feito diariamente e guardado com cópias em outros prédios, em lados opostos da cidade, e com todos os requisitos físicos de segurança).
- Não acreditar que Linux seja inatacável por pessoas mal-intencionadas, inclusive dentro da LAN;
- Não sair navegando alegremente pela LAN ou principalmente pela WEB estando logado como 'root';
Gostei do artigo. Muito bom.
[7] Comentário enviado por iz@bel em 12/06/2008 - 15:08h
Olá pessoal! E agora???
Esse foi o meu /var/log/rkhunter.log [só os Warning ]:
[14:58:50] Checking '/etc/xinetd.d/vmware-authd' for enabled services [ Warning ]
[14:58:50] Checking for enabled xinetd services [ Warning ]
[14:58:50] Warning: Found enabled xinetd service: /etc/xinetd.d/vmware-authd
[14:59:07] Checking /dev for suspicious file types [ Warning ]
[14:59:07] Warning: Suspicious file types found in /dev:
[14:59:07] /dev/shm/pulse-shm-3809702359: data
[14:59:08] Checking for hidden files and directories [ Warning ]
[14:59:08] Warning: Hidden directory found: /etc/.java
[14:59:08] Warning: Hidden directory found: /dev/.static
[14:59:08] Warning: Hidden directory found: /dev/.udev
[14:59:08] Warning: Hidden directory found: /dev/.initramfs
Eu tenho vmware-serve e java instalado.
Uso ubuntu 8.04 e internet DHCP.
E agora????
Olá pessoal! E agora???
Esse foi o meu /var/log/rkhunter.log [só os Warning ]:
[14:58:50] Checking '/etc/xinetd.d/vmware-authd' for enabled services [ Warning ]
[14:58:50] Checking for enabled xinetd services [ Warning ]
[14:58:50] Warning: Found enabled xinetd service: /etc/xinetd.d/vmware-authd
[14:59:07] Checking /dev for suspicious file types [ Warning ]
[14:59:07] Warning: Suspicious file types found in /dev:
[14:59:07] /dev/shm/pulse-shm-3809702359: data
[14:59:08] Checking for hidden files and directories [ Warning ]
[14:59:08] Warning: Hidden directory found: /etc/.java
[14:59:08] Warning: Hidden directory found: /dev/.static
[14:59:08] Warning: Hidden directory found: /dev/.udev
[14:59:08] Warning: Hidden directory found: /dev/.initramfs
Eu tenho vmware-serve e java instalado.
Uso ubuntu 8.04 e internet DHCP.
E agora????
[8] Comentário enviado por U-Neeks em 16/11/2008 - 20:00h
izabeljp
''veja o log do rkhunter/chkrootkit. Lá vocês podem obter maiores informações sobre o WARNING. Em muitos dos casos estes warnings não são motivos de preocupação.''
Todo o log da operação é armazenado, por padrão, em /var/log/rkhunter.log
izabeljp
''veja o log do rkhunter/chkrootkit. Lá vocês podem obter maiores informações sobre o WARNING. Em muitos dos casos estes warnings não são motivos de preocupação.''
Todo o log da operação é armazenado, por padrão, em /var/log/rkhunter.log
[9] Comentário enviado por sacioz em 19/09/2015 - 18:15h
Olá
Muito obrigado pelo artigo ... suponho que seja possivel usá-lo no openBSD tbm , sem conflitos .
Como no da Is@ , meu scan tbm apresentou 2probs , 1 hidden outro o java , vou deixar kieto por mientras...
Olá
Muito obrigado pelo artigo ... suponho que seja possivel usá-lo no openBSD tbm , sem conflitos .
Como no da Is@ , meu scan tbm apresentou 2probs , 1 hidden outro o java , vou deixar kieto por mientras...
[10] Comentário enviado por removido em 27/02/2017 - 22:14h
[5] Comentário enviado por Yrrak em 12/06/2008 - 08:52h
Ótimo artigo, parabéns...
Só tenho um detalhe a comentar.
Para realizar o update do programa você indicou o comando "rkhunter --propupda" sendo que o certo é "rkhunter --propupd" sem o a no final.
Abraço
Realmente o comando esta errado o correto é rkhunter --propupd
--propupd [{filename | directory | package name},...]
One of the checks rkhunter performs is to compare various current file properties of various commands, against those it has
previously stored. This command option causes rkhunter to update its data file of stored values with the current values.
If the filename option is used, then it must either be a full pathname, or a plain file name (for example, 'awk'). When
used, then only the entry in the file properties database for that file will be updated. If the directory option is used,
then only those files listed in the database that are in the given directory will be updated. Similarly, if the package name
option is used, then only those files in the database which are part of the specified package will be updated. The package
name must be the base part of the name, no version numbers should be included - for example, 'coreutils'. Package names
will, of course, only be stored in the file properties database if a package manager is being used. If a package name is the
same as a file name - for example, 'file' could refer to the 'file' command or to the RPM 'file' package (which contains the
'file' command) - the package name will be used. If no specific option is given, then the entire database is updated.
WARNING: It is the users responsibility to ensure that the files on the system are genuine and from a reliable source.
rkhunter can only report if a file has changed, but not on what has caused the change. Hence, if a file has changed, and the
--propupd command option is used, then rkhunter will assume that the file is genuine.
Fonte:
man rkhunter
[5] Comentário enviado por Yrrak em 12/06/2008 - 08:52h
Ótimo artigo, parabéns...
Só tenho um detalhe a comentar.
Para realizar o update do programa você indicou o comando "rkhunter --propupda" sendo que o certo é "rkhunter --propupd" sem o a no final.
Abraço
Realmente o comando esta errado o correto é rkhunter --propupd
--propupd [{filename | directory | package name},...]
One of the checks rkhunter performs is to compare various current file properties of various commands, against those it has
previously stored. This command option causes rkhunter to update its data file of stored values with the current values.
If the filename option is used, then it must either be a full pathname, or a plain file name (for example, 'awk'). When
used, then only the entry in the file properties database for that file will be updated. If the directory option is used,
then only those files listed in the database that are in the given directory will be updated. Similarly, if the package name
option is used, then only those files in the database which are part of the specified package will be updated. The package
name must be the base part of the name, no version numbers should be included - for example, 'coreutils'. Package names
will, of course, only be stored in the file properties database if a package manager is being used. If a package name is the
same as a file name - for example, 'file' could refer to the 'file' command or to the RPM 'file' package (which contains the
'file' command) - the package name will be used. If no specific option is given, then the entire database is updated.
WARNING: It is the users responsibility to ensure that the files on the system are genuine and from a reliable source.
rkhunter can only report if a file has changed, but not on what has caused the change. Hence, if a file has changed, and the
--propupd command option is used, then rkhunter will assume that the file is genuine.
Fonte:
man rkhunter
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Servidor de Backup com Ubuntu Server 24.04 LTS, RAID e Duplicati (Dell PowerEdge T420)
Visualizar câmeras IP ONVIF no Linux sem necessidade de instalar aplicativos
Atualizar Debian Online de uma Versão para outra
Dicas
Dica para encontrar diversos jogos Indies criativos
Instalando Discord no Debian 13
Instalar driver Nvidia no Debian 13
Redimensionando, espelhando, convertendo e rotacionando imagens com script
Tópicos
Instalar Linux e grub em hd ssd externo [RESOLVIDO] (5)
Software livre - será que eu estou tão errado assim? (14)
Top 10 do mês
-
Xerxes
1° lugar - 58.816 pts -
Fábio Berbert de Paula
2° lugar - 35.743 pts -
Buckminster
3° lugar - 21.605 pts -
Sidnei Serra
4° lugar - 13.513 pts -
Mauricio Ferrari
5° lugar - 12.772 pts -
Alberto Federman Neto.
6° lugar - 12.300 pts -
Samuel Leonardo
7° lugar - 12.289 pts -
Daniel Lara Souza
8° lugar - 11.335 pts -
Andre (pinduvoz)
9° lugar - 11.172 pts -
edps
10° lugar - 10.672 pts
Scripts
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
