[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

2 0

[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

0 0

[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!

0 0

[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.

0 0

[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

2 0

[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.

0 0

[7] Comentário enviado por [email protected] 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????

0 0

[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

0 0

[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 [email protected] , meu scan tbm apresentou 2probs , 1 hidden outro o java , vou deixar kieto por mientras...

0 0

[10] Comentário enviado por removido em 27/02/2017 - 22:14h



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

2 0