[SECURITE] Infection

Support Debian
#1

Bonjour à tous.

Tout d’abord, un grand merci à toute la communauté de ce site, qui fait preuve d’une grande patience envers moi sur un p’tit problème (dont ce n’est pas le sujet ici.

Bref, je vous résumé ici mon probleme.

Je loue un serveur sur le net, et l’organisme auquel je loue ma machine m’as retransmi un mail indiquant qu’un scan de type brute-force etait fait a partir de mon server vers d’autres machine.

Bref, il semblerai que mon serveur soit infecté.

Après quelques recherche j’ai utilisé rkhunter, qui ne m’affiche rien de méchant si ce n’est :

/usr/bin/unhide.rb [ Warning ]
Et donc, en fin de rapport :

[code]System checks summary

File properties checks…
Files checked: 132
Suspect files: 1

Rootkit checks…
Rootkits checked : 306
Possible rootkits: 0

Applications checks…
All checks skipped

The system checks took: 12 minutes and 52 seconds

All results have been written to the log file (/var/log/rkhunter.log)

One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)
[/code]

Après en avoir discuter avec le type du support de mon prestataire; il semblerai que ce soit effectivement une infection…

Estc-e que quelqu’un s’y connais de ce côté, et est-ce que ce quelqu’un pourrai m’aider à nettoyer ma machine, et la sécuriser par la suite?
Pour info, j’ai fail2ban d’installé, mais peut etre la config a revoir du coup :confused:

#2

Hello,

Y a un paquet de trucs a savoir gérer en terme de sécurité.

Honnetement a part lire de la doc et monter en compétence y a rien d’autre.

De toute manière si ta machine est compromise, il ne faut surtout rien nettoyer. Il faut surtout l’exploser et remonter une archi sure.

Un système compromis et un système à exterminer (ou analyser a des fins d’apprentissage)

http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html

Enjoy!

#3

[quote=“johnnyB”]Hello,

Y a un paquet de trucs a savoir gérer en terme de sécurité.

Honnetement a part lire de la doc et monter en compétence y a rien d’autre.

De toute manière si ta machine est compromise, il ne faut surtout rien nettoyer. Il faut surtout l’exploser et remonter une archi sure.

Un système compromis et un système à exterminer (ou analyser a des fins d’apprentissage)

http://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html

Enjoy![/quote]

Va dire ça aux clients en infogérance semi complète qui font n’importe quoi avec par exemple un phpmyadmin :whistle: surtout lorsque ce sont de très gros clients avec un paquet de site sur la machine :wink:

#4

Ya pas une autre solution qu’ à l’américaine? Je ne peut pas nécessairement tout exploser pour tout refaire.

Si on peut la sécuriser de zéro, on peut la sécuriser aujourd’hui, telle qu’elle est, non?

#5

Ce que tu demandes, c’est un audit de ta machine,je ne pense pas que quelqu’un ici ai du temps pour ça. Il serait plus simple de sauvegarder à des fins d’étude ton système compromis, et de refaire une installation propre, avec des mots de passes en béton armé. Sur le wiki tu trouveras une approche (non-exhaustive) sur la sécurité. Courage tu as de belles heures d’étude devant toi.

isalo.org/wiki.debian-fr/Securite

#6

Tu peux éventuellement tester les fichiers des paquets debian avec debsum.

Ensuite tu vires ou vérifies tout ce qui est dans /usr/local/bin, ou tu vires du PATH ce répertoire.

Tu vérifies un par un TOUS les fichiers de /etc/default ainsi que chacun des scripts appelé par /etc/rc*.d

Si tu as un site dynamique, tu supprimes tout le site existant et remet une sauvegarde récente et fonctionnelle. Regarde notamment si tu n’as pas un fichier php rajouté.

En tout état de cause, si ta machine fais des scans regardes par tcpdump où ça va et qui lance le processus.

Mais c’est très délicat de remettre une machine bancale d’aplomb. Une reinstallation complète est plus sûr.

#7

Je vais voir ta solution en premier lieu, dans le pire des cas, ben, à l’américaine.

En tout cas, merci de ta réponse.

#8

Après avoir lancer rkhunter sur mon poste utilisateur Wheezy XFCE, j’ai la même chose que toi…

/usr/bin/who [ OK ] /usr/bin/whoami [ OK ] /usr/bin/unhide.rb [ Warning ] /usr/bin/mawk [ OK ]

Il y a un autre soucis de dossier caché. En regardant dans le log de rkhunter :

$ grep -e "Warning" /var/log/rkhunter.log [10:45:18] /usr/bin/unhide.rb [ Warning ] [10:45:18] Warning: The command '/usr/bin/unhide.rb' has been replaced by a script: /usr/bin/unhide.rb: Ruby script, ASCII text [10:48:22] Checking for hidden files and directories [ Warning ] [10:48:22] Warning: Hidden directory found: '/etc/.java'

Ma machine utilisateur n’est pas ton serveur, et souffre du même problème, ce qui est curieux. On peut toucher Skynet du doigt, mais je parierais plus sur « un faux positif ». Si quelqu’un peut faire le test sur une troisième machine, on pourrait recroiser davantage.

Quid d’une install Wheezy fraîche ? Souffrirait-elle du même warning ?
— oui : forte probabilité de faux positif
— non : un diff sur le /usr/bin/unhide.rb pourrait apporter une intéressant grille d’analyse.

En employant cette méthode, tu pourrais déjà en savoir un peu plus… avant de foutre en l’air ta config de serveur « à l’américaine ». En outre ça m’épargnerait de le faire pour ma propre config :wink:, et un faux positif avéré pourrait aussi faire l’objet d’un update de base de donnée rkhunter (je n’ai aucune idée au sujet de la façon de procéder celà dit).

#9
#10

En faisant une recherche à base de « rkhunter unhide.rb » dans un moteur de recherche, on trouve pas mal de soucis remontés en 2012 2013. Pas mal ont donné lieu à des questions sur les forum ubuntu. Il me semble donc que c’est un « faux warning positif » connu plus qu’une infection.

Comme dit dans ce commentaire : http://forum.ubuntu-fr.org/viewtopic.php?pid=7691601#p7691601, rkhunter « se contente d’attirer ton attention sur un certain nombre de choses », c’est un warning cela ne signifie pas que la machine est corrompue. Je mets ma main à couper qu’une Wheezy propre fraîchement installée va présenter le même warning.

Au vu de la structure des fichiers de rkhunter, il y a une méthode de vérification de somme de contrôle. Il y a probablement eu un update de fichier pas répercuté en somme de contrôle de référence dans la base de données de rkhunter. Je trouve toute de même cela bizarre que la base de données ne soit pas synchronisée sur le contenu des dépôts.

#11

J’ai une question : rkhunter se sert de sa base de données interne, c’est à dire celle qu’il s’est constitué lors du premier check pour comparer les hash des différents fichiers.
Comment être sur que les hash de référence ne sont pas eux mêmes corrompus (si on n’a pas lancé l’outil juste après une installation toute neuve), puisqu’il existe une commande rkhunter --propupd qui permet de mettre à jour cette base de données avec des info qui sont peut être elles même corrompues…?

J’avais un paquet de warning sur mes fichier du à des hash differents aux hash qui étaient dans la base “interne”. Après un rkhunter --propupd, je n’ai plus qu’un seul warning (sur le unhide.rb), mais j’ai bien compris que c’est parce que j’ai moi même forcé l’update de la base avec des hash des fichiers actuels, dont je n’ai aucune idée s’ils sont corrompus ou pas.

Donc soit je n’ai pas compris le fonctionnement de rkhunter, soit ce système est débile (si on doit se taper la vérif des md5 à la main pour valider tel ou tel fichier avant de mettre à jour la base interne de l’outil, il n’y a plus d’intéret a utiliser l’outil lui même…)

Si j’ai raison, alors y a t’il un site (de confiance) ou je puisse aller récupérer les hash des fichiers systèmes, afin de les comparer à mes hash courrant (puisque si mes fichiers sont corrompus, comme je ne met à jour que via les dépôts debian, je ne peux me fier au contenu de ces derniers en re-téléchargeant les fichiers afin de comparer leur hash avec celui de mes fichiers à moi) ?

edit : grillé par bobo38, on a je crois les mêmes doutes sur le fonctionnement de rkhunter.

#12

DE ce que j’ai pu voir, unhide.rb serai même un fichier nécessaire à l’execution de rkhunter… c’est ce que j’ai cru comprendre n tout cas…

Re Belzebuth :stuck_out_tongue:

#13

@dric64 : je pense que le principe de l’update de database est que tu forces la resynchronisation à une base partagée et centralisée, ce qui évite une compromission de la copie locale. Après il faut faire confiance à la base de données… Je dis ça mais je ne suis pas un spécialiste : j’ai découvert ce rkhunter ce matin et j’ai encore du mal à en saisir les principes de fonctionnement (mais ça ne me paraîtrait pas débile). Pour moi le contenu de la database devrait être géré par apt, j’ai du mal à me figurer pourquoi il y a une option de la commande rkhunter en fait.

@dric64 : merci d’avoir confirmé que tu as le même « comportement ».

cp /usr/bin/unhide.rb ~ aptitude remove unhide.rb aptitude install unhide.rb vimdiff /usr/bin/unhide.rb ~/unhide.rb

Après ces manips, il s’avère que les fichiers sont identiques… par défaut je fais confiance au paquet officiel.

#14

[quote=“bobo38”]@dric64 : je pense que le principe de l’update de database est que tu forces la resynchronisation à une base partagée et centralisée, ce qui évite une compromission de la copie locale. Après il faut faire confiance à la base de données… Je dis ça mais je ne suis pas un spécialiste : j’ai découvert ce rkhunter ce matin et j’ai encore du mal à en saisir les principes de fonctionnement (mais ça ne me paraîtrait pas débile). Pour moi le contenu de la database devrait être géré par apt, j’ai du mal à me figurer pourquoi il y a une option de la commande rkhunter en fait.

@dric64 : merci d’avoir confirmé que tu as le même « comportement ».

cp /usr/bin/unhide.rb ~ aptitude remove unhide.rb aptitude install unhide.rb vimdiff /usr/bin/unhide.rb ~/unhide.rb

Après ces manips, il s’avère que les fichiers sont identiques… par défaut je fais confiance au paquet officiel.[/quote]

l’update (rkhunter --update) oui (il met à jour sa base de rootkit connu je pense).
L’update de la base interne (rkhunter --propupd), j’en suis pas si sur… pour moi, le propupd remet à jour la base interne avec les hash actuels de ta machine, sans aucune autre forme de vérification. J’espère me tromper.

Je trouve qu’il ne devrait pas être géré par apt, car apt est basé sur des dépôts qui sont susceptibles d’être modifiés par l’utilisateur, et donc, corrompus. Faudrait que la référence soit par défaut les fichiers publiés dans les dépots officiels.

#15

Ceci devrait répondre à vos interrogations …

[quote=“man rkhunter”]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.[/quote]

#16

ok, donc rkhunter ne me sert a rien… (enfin si quand même, il m’a mis la puce à l’oreille, il y a du potentiel d’amélioration dans ce petit outil : utiliser une base de référence fiable)

Y a t’il un site de confiance ou je peux trouver les hash (officiels) des fichiers de ma debian ?
Je vais avoir du taff de contrôle, cet après midi (114 fichiers en warning) :confused:

#17

Je l’ai dit, outil debsum.

#18

La sécurité c’est une panoplie d’outils et d’actions à mettre en place.

Il n’y a pas une méthode ou un outil.

Déjà si tu n’avais de firewall, ips/ids, checksum de fichiers, confinement, suivi régulier des failles et upgrade ou autre outils c’est juste normal de se faire peter sa machine.

rkhunter sert a checker une compromission existante et non a protéger et ce n’est pas parce que tu mets du debsum que tu est a l’abri.

La sécurité c’est une attitude et surtout c’est du taff (pentest dans environnements de dev, documentation etc. etc…

#19

J’ai tout ce que tu dis. Je pense que ma distro est sure, mais ce que j’ai vu ce matin m’a sacrément mis le doute.
D’ailleurs je viens de checker un échantillon de fichier qui remontent en warning, aucun n’est corrompu heureusement. C’est juste la bdd de rkhunter qui n’était pas à jour (pour l’instant…)

Ma technique : tout à la mano : je regarde quel fichier est en warning, je vais sur le site debian, je cherche de quel paquet il fait partie, je telecharge le paquet, je l’extrais, et je compare les somme sah1 ou md5 des fichiers). Long, mais au moins, je suis sur du résultat.

A la fin, je referai un rkhunter --propupd et ca sera une référence sure, cette fois.

#20

Ah oui, merci j’avais pas vu :mrgreen:
Mais debsum vérifie le hash des paquets debian, pas forcément de l’utilitaire suspect, non ?
je veux dire que le paquet d’origine peut être fiable, et le fichier dont il est issue corrompue si la corruption a eu lieu après coup.