Retourner aux forums || Retourner au forum
J'ai, du coup, mis à jour tout le serveur, bouchant par la même occasion une faille de cyrus.
Mais voilà, j'ai des couilles dont je ne sais pas si elles sont issues du piratage ou de la mise à jour.
Tous les détecteurs de rootkits restent muets, ça me rassure un peu.
Le binaire "logger" avait disparu ainsi que le répertoire /var/log. Un mkdir et un reinstall de bsdutils plus tard, plus de prob.
Mais :
apache refuse de se lancer (
Cannot load /usr/lib/apache/1.3/mod_log_config.so into server: /usr/lib/apache/1.3/mod_log_config.so: cannot open shared object file: No such file or directory )
et je n'arrive pas à résoudre le problème.
De plus, quand on se connecte par ssh, le password est toujours refusé les 3 première fois. (moi j'utilise les clés, c'est qqn d'autre qui m'a soufflé ça)
ploum@vulsini:~$ ssh ploum@frimouvy.org
Password:
Password:
Password:
ploum@frimouvy.org's password:
(et là, à la 4ème fois, ça marche)
Je n'arrive pas à trouver le problème. J'ai réinstallé login sans succès.
Bref, je demande de l'aide pour tout ça. De plus, que faire dans pareille situation ? Tous les conseils sont les bienvenus !
AU SECOURS !!!!
> Lire le message (12 commentaires, moyenne: 3,4).
j'oubliais..
Les logs de cyrus se remplissent de :
Jan 30 21:43:38 sol cyrus/lmtpd[29089]: FATAL: lmtpd: unable to init duplicate delivery database
Jan 30 21:43:38 sol cyrus/lmtpd[29090]: DBERROR: dbenv->open '/var/lib/cyrus/db' failed: DB_RUNRECOVERY: Fatal error, run database recovery
Jan 30 21:43:38 sol cyrus/lmtpd[29090]: DBERROR: init /var/lib/cyrus/db: cyrusdb error
et j'ai tenté un cyrreconstruct, mais sans succès.. :-(
pour courroner le tout...
Je me décide de faire un petit upgrade de fritalk.com, mon second serveur :
apt-get update
zsh: bus error apt-get update
Toutes les opérations apt-get me renvoie cette erreur ! Je suis maudit aujourd'hui :-(
-
[^]Re: pour courroner le tout...
Posté par doublehp (page perso, ) le 31/01/2005 à 04:10. (lien). Évalué à 1.$ dpkg -S /usr/lib/apache/1.3/mod_log_config.so
apache-common: /usr/lib/apache/1.3/mod_log_config.so
->
apt-get --reinstall install apache-common apt
si apt refuse de marcher, telecharge le pakage apt.deb sur le site de debian, et installe le a la main:
dpkg -i apt_*.deb
puis:
$ apt-cache show apt
Depends: libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.4.1-3), libstdc++5 (>= 1:3.3.4-1)
si reinstaller apt_*.deb ne resouds pas le pb, tu reinstall ces 3 dependances de la meme maniere, ou tu attaques:
dpkg -S zsh
puis reintalle a la main ceux qui te paraissent pertiments. Mais je n y crois pas.
Pour finir, comme d autres te l ont conseille:
compromission = reinstall
Hum ...
Même si tu n'avais aucun problèmes avec ta machine, je n'aurais qu'un conseil à donner :
Machine compromise => formatage.
Maintenant tu fais ce que tu veux ...
M
-
[^]Re: Hum ...
Posté par ploum (page perso, ) le 30/01/2005 à 21:06. (lien). Évalué à 2.Le problème c'est que c'est un serveur distant, et donc c'est pas évident du tout du tout.
D'autres part, l'exploit utilisé ne donnait "que" les privilèges de www-data, pas de root-
[^]Re: Hum ...
Posté par Bruno Michel (page perso, ) le 30/01/2005 à 21:34. (lien). Évalué à 5.Comment a-t-il fait pour effacer le répertoire /var/log et le binaire logger s'il n'avait que les droits de www-data ? Personnellement, je considérerais qu'il a utilisé un autre exploit pour gagner le root.
Si tu es sur qu'il n'a eu que les droits de www-data, recherche tous les fichiers lui appartenant, fait en une sauvegarde, supprime-les et réinstalle ce qu'il faut.
Mais l'idéal reste quand même un reformatage + une réinstallation complète.-
[^]Re: Hum ...
Posté par ploum (page perso, ) le 30/01/2005 à 21:40. (lien). Évalué à 2.ben je ne suis pas sur que ce soit lié. J'ai fait un dist-upgrade un peu bourrin après l'attaque et c'est là que tous les problèmes ont commencés.
J'aurais pas du faire l'upgrade direct, ça c'est vrai. J'y ai pensé un peu trop tard :-(
-
-
[^]Re: Hum ...
Posté par Maillequeule () le 30/01/2005 à 22:30. (lien). Évalué à 4.Le problème c'est qu'à partir de maintenant, et même si tu ne trouves rien, tu ne peux plus considérer ton serveur comme sûr (en supposant qu'on le puisse à un moment donné).
L'effacement de /var/log avec les droits www-data, ca me laisse songeur (ou alors c'était une installation de goret) :)
Si tu es, comme je le suppose, sur un serveur dédié chez un hébergeur, tu peux te renseigner sur le coût d'une reinstall de la machine ... C'est peut être un faible prix à payer (au sens propre et figuré) pour repartir sur de bonnes bases.
En attendant, considère ta machine comme morte, à moins d'aimer jouer avec le feu. Faire une analyse post-mortem, oui, mais une remise en production, certainement pas.
M
-
[^]Re: Hum ...
Posté par Krunch (Jabber id, page perso, ) le 31/01/2005 à 14:52. (lien). Évalué à 5.Ca serait quand même une bonne idée de réinstaller tout parce que rien ne garanti qu'une faille locale n'a pas été utilisée pour rootkiter la machine avec un truc qui n'est pas détecté par chkrootkit et compagnie.
Un moyen relativement sûr de faire la réinstallation à distance serait de commencer par compiler CryptCat ainsi que les binaires de base (BusyBox est ton ami) statiquement sur une machine sûre et les uploader sur la machine compromise. S'arranger pour ne plus utiliser que ces programmes. Notamment ne plus utiliser le sshd original qui peut avoir été compromis aussi. Tu devrais pouvoir obtenir un shell par cryptcat avec un truc genre "# cryptcat -e /safe/bin/sh -l -p 1234 -k mekmitasdigoat" et "$ cryptcat -k mekmitasdigoat example.org 1234". De la tu peux faire un chroot qui te forcerait à utiliser, les nouveaux binaires, dans ce cas, ne pas oublier de faire les mknod qui vont bien avant de passer à la suite.
Debootstraper un système Debian de base sur une machine sûre, le mettre sur un système de fichiers qui va bien, uploader la "partition" sur la machine compromise à traver CryptCat, genre "# cryptcat -k mekmitasdigoat -l -p 4321 -q0 > /safe/dev/hda2" et "$ cryptcat -k mekmitasdigoat example.org 4321 < debian-base.ext3" avec hda2 une partition "libre" que tu as démontée préalablement (genre n'importe quoi sauf /, éventuellement la partition de swap si elle est assez grosse, pas oublier de faire un swapoff avant). Maintenant tu peux monter la partition, chrooter vers le nouveau système et installer le bootloader. Ensuite yapluka rebooter et prier.
Si tu réussis, tu peux être raisonnablement sûr que tu as un système de bases propre. Si tu es paranoïaque, tu peux imaginer que le rootkit est au niveau du noyau et qu'il sait réinfecter un nouveau système que tu installes à partir de programmes non compromis ou que le sshd sait infecter les programmes qu'il voir passer de manière à ce qu'ils infectent à leur tour les fichiers qu'ils manipulent ou qu'il y a un daemon caché qui injecte du code malsain dans tous les nouveaux processes qu'il voit apparaitre ou qu'il y a quelqu'un connecté par une backdoor qui surveille ou bien... mais alors ya plus grand chose à faire à part réinstaller vraiment "from scratch".
A l'avenir pour diminuer les risques de compromission complète du système quand un daemon se fait exploiter tu peux mettre un maximum de truc dans des "jails chroot" ou mieux: des machines virtuelles en utilisant User-Mode-Linux par exemple. Par ailleurs le manuel de sécurisation Debian contient plein de trucs intéressants et faire tourner Sarge sur un serveur disponible depuis internet n'est peut-être pas une très bonne idée (oui je sais Woody est pas à jour mais au moins il y a des màj de sécurité et apt-get peut être mis dans un cron sans risque).
Bon amusement :/
Bien entendu je ne saurais être tenu pour résponsable des dégats éventuels causés par l'applications de ce que j'ai décrit plus haut.--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: Hum ...
Posté par ploum (page perso, ) le 31/01/2005 à 15:51. (lien). Évalué à 2.finalement, on a opté pour la réinstallation par OVH. ça coute plus cher, mais c'est plus rapide et sans risque.
En plus, comme je dois aussi réinstaller tout fritalk.com, je suis pas à ça prêt...
Mais je note scrupuleusement tes conseils, merci :-)
-
-
rkhunter
Je te conseile d'utiliser "rkhunter" il fait des checks des binaires et des rootkits connus
-
[^]Re: rkhunter
Posté par ploum (page perso, ) le 30/01/2005 à 21:32. (lien). Évalué à 3.j'ai essayé. Il n'a rien trouvé si ce n'est un warning dans les modules de mon noyaux. Ceux-ci sont :
ext2 51176 1 (autoclean)
dm-mod 29608 0 (unused)
8139too 15240 1
mii 2464 0 [8139too]
crc32 2912 0 [8139too]
rtc 7112 0 (autoclean)
ext3 82536 2 (autoclean)
jbd 42980 2 (autoclean) [ext3]
ide-detect 288 0 (autoclean) (unused)
piix 8904 1 (autoclean)
ide-disk 16928 4 (autoclean)
ide-core 111228 4 (autoclean) [ide-detect piix ide-disk]
unix 15500 316 (autoclean)
et ça semble correct.
Revenir en haut de page || Retourner aux forums || Retourner au forum
Cette page a été générée par Templeet en 0.0768s (dont 0.0065 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.