aodot Posté 18 Mars 2008 Posté 18 Mars 2008 (modifié) Bonjour à tous, Je viens à vous car cela fait une semaine que ça dure et je n'ai pas de solutions et OVH à part me menacer de supprimer on serveur ne répond jamais à mes mails. Je vous explique cela fait un an que je crée des sites Internet et que je les hébergent sur un serveur dédié OVH superplan 2007. Lundi dernier à 4h mon serveur se fait piraté. OVH me bloque mon serveur, je supprimer les fichiers mit par le hackeur (dosseir tmp et var/tmp). OVH relance Apache, tout est ok. Cependant rien n'y fait j'ai toujours des alerters backddor et des relances du service juridique. J'ai donc souscris à l'option sécurité totale afin de mettre de côté les failles logiciels (pas mis à jour depuis 1 an) et j'ai sécurisé tout mes scripts : pour mes formulaires j'ai interdit le code php et html et j'ai également tout fait afin d'éviter les injections avec mysql_real_escape_string() Et j'ai toujours des fichiers qui sont insérés dans le répertoire tmp et des alertes backdoor. J'ai demandé au services infogérance d'OVH si il pouvait m'enlever ce backdoor et m'indiqué d'ou provient le hack mais pas de réponse depuis 1 semaine et les relances téléphoniques ne servent à rien. J'ai essayé de trouver un service d'infogérance mais pas moyen d'en trouver et Dan n'accepte plus les release 1 d'ovh. Auriez vous une solution à ce problème qui peut me foutre dans une m..de pas possible si je ne le résout pas. Merci par avance. Cordialement Modifié 18 Mars 2008 par Dan
Kioob Posté 18 Mars 2008 Posté 18 Mars 2008 Hello, délicat quand même... je suis peut être extremiste mais pour moi à partir du moment où une machine a été compromise elle n'est plus fiable : il faut réinstaller. La release 1 d'OVH, c'est bien la vieille red hat 7 daubée ? Si c'est le cas, je ne pourrais guère t'aider non plus... c'est très éloigné de ce que j'utilise d'habitude.
aodot Posté 18 Mars 2008 Auteur Posté 18 Mars 2008 bonjour, merci pour votre réponse rapide. Je pense qui si rien ne se passe je vais réinstaller mais ce qui serait plus judicieux serait que l'infogérance d'ovh me dise d'ou provient le hack afin de combler la faille. Et surtout le grand point noir : comment réinstaller une machine ? Les guides d'ovh datent presque tous de 2 ans et plus rien n'est fiable. Il faudrait que je sache réinstaller php myadmin, mysql, tout ça quoi et la... Je serais pret à débourser de l'argent pour qu'on me réinstalle tout ça proprement mais à qui s'adresser ?
Dan Posté 18 Mars 2008 Posté 18 Mars 2008 Avant de réinstaller, il faut tout de même envisager un nettoyage. Ce sera moins douloureux que de tout effacer. Dans les emails d'alerte reçus d'OVH, tu dois avoir les noms des processus et les ports écoutés... que tu trouveras soit dans /tmp, dans /var/tmp ou dans l'un de tes répertoires de site. Pour savoir d'où cela vient, il faut analyser sérieusement les formulaires dans lesquels tes visiteurs peuvent entrer des données. C'est avec quasi-certitude de là que vient ton problème. Ou alors, un forum tel que PhpBB qui n'est pas à la dernière version.... Une commande peut rapidement te montrer quels sont les ports qui sont utilisés, et par quelles applis: "netstat -tanpu" Une autre, pour analyser les processus et voir si tu n'as pas par exemple un process httpd qui n'a pas été lancé par Apache: "ps auwx --forest" Cette commande va hiérarchiser la présentation et te permettra de visualiser rapidement ce qui coince. Dan PS: il est vrai que je n'accepte plus les serveurs en release 1 en infogérance, mais je maintiens toujours l'existant. Il en reste encore 80 tout de même Et si tu veux réinstaller... j'espère qu'au moins tu as des sauvegardes. Mais une réinstallation sans trouver la faille ne t'aidera pas car la faille sera toujours là.
aodot Posté 18 Mars 2008 Auteur Posté 18 Mars 2008 Merci Dan pour votre réponse, C'est vrai que si je réinstalle et que la faille reste présente je pense que cela fera juste repousser le problème. J'ai sécurisé mes formulaires avec mysql_real_escape_string() je pense que c'est suffisant afin de supprimer les injections. J'ai également interdit le code php et html avec strip_tags() dans les formulaires. Au niveau des alertes backdoors d'ovh, je reçois toujours les mêmes mails avec les indications suivantes : Detection date: 2008-03-18 15:17:46 Procname: 19876 Uid: nobody Pid: 30848 CommandLine: ./19876 Exe: /tmp/bind/19876 (ou var/tmp/bind/19876) Port: 19876 Danger Level: 5/10 Avec la commande "netstat -tanpu" j'obtiens parmi les quelques dizaines de lignes dsponibles ces lignes qui me paraissent bizarre : udp 0 0 0.0.0.0:10000 0.0.0.0:* 3132/perl udp 0 0 xx.xxx.xx.xxx:53 0.0.0.0:* 32470/named udp 0 0 127.0.0.1:53 0.0.0.0:* 32470/named Avec la commande "ps auwx --forest" j'ai pas mal de lignes et celles qui indiquent le répertoire en question sont celles ci : nobody 30848 0.0 0.0 1416 364 ? S 13:54 0:00 ./19876 nobody 32505 0.0 0.0 1416 392 ? S 13:54 0:00 \_ ./19876 nobody 3998 0.0 0.0 2116 1136 ttyp0 S 13:54 0:00 \_ sh -i nobody 6628 0.0 0.0 1896 872 ttyp0 S 16:12 0:00 \_ /bin/sh ./scan 121.15 nobody 31888 0.0 0.0 1316 384 ttyp0 S 16:19 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 3183 0.0 0.0 1340 484 ttyp0 S 16:58 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 31238 0.0 0.0 1340 484 ttyp0 S 16:58 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 11878 0.0 0.0 1340 484 ttyp0 S 16:58 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 5844 0.0 0.0 1340 484 ttyp0 S 16:58 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 24213 0.0 0.0 1340 484 ttyp0 S 16:58 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 25589 0.0 0.0 1340 484 ttyp0 S 16:58 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 5262 0.0 0.0 1340 484 ttyp0 S 16:58 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 10771 0.0 0.0 1340 484 ttyp0 S 16:58 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 25311 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 585 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 1103 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 8133 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 29876 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 7873 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 20402 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 5491 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 18910 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 30751 0.1 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 4027 0.1 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 27199 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 3575 0.2 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 19324 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 10465 0.0 0.0 1340 464 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 21023 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 19848 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 25898 0.1 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 1303 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 14562 0.0 0.0 1340 464 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 20425 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 9884 0.1 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 25064 0.1 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 14891 0.0 0.0 1340 464 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 12924 0.0 0.0 1340 484 ttyp0 R 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 24079 0.3 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 1287 0.1 0.0 1340 464 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 23172 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 25395 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 24292 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 4196 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 9601 0.1 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 11467 0.0 0.0 1340 464 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 16135 0.1 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 14598 0.1 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 31579 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 29815 0.0 0.0 1340 464 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 17244 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 26514 0.0 0.0 1340 464 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 25676 0.0 0.0 1340 464 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 23049 0.0 0.0 1340 464 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 31517 0.0 0.0 1340 464 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig nobody 4169 0.0 0.0 1340 484 ttyp0 S 16:59 0:00 \_ ./Horde ip.log Horde.log 50 HordeConfig A votre avis faille grave pas grave ? Il est clair que le fait de ne aps réinstaller serait un point positif. Merci par avance en tout cas.
Dan Posté 18 Mars 2008 Posté 18 Mars 2008 Les 3 lignes données par netstat sont OK. La première est pour webmin (port 10 000) et les deux autres écoutent sur le port 53 qui est le port standard de bind. par contre, je me demande ce que fait ce process 19876 ??? Tu peux le tuer avec un "kill -9 30848 32505" (vois si ces numéros de process n'ont pas changé entretemps) Et puis tuer Horde avec un "killall -9 Horde" Ensuite, vire les fichiers et répertoires bind/19876 sous /tmp et /var/tmp Assure-toi que tu n'as pas de fichiers cachés dans ces répertoires : "ls -la /tmp" et "ls -la /var/tmp" Revérifie que tu n'as plus ce process dans la liste des process actifs (ps auwx --forest) La sécurisation de tes formulaires de contact me semble insuffisante. Vas lire cette page, elle t'en apprendra beaucoup sur la sécurisation : http://www.securephpwiki.com/index.php/Email_Injection Dan
aodot Posté 18 Mars 2008 Auteur Posté 18 Mars 2008 Merci Dan, Je supprime tout ce qu'il y a dans les répertoires /tmp et /var/tmp dès que je vois quelque hose de bizarre. En gros dès que je suis sur le PC je regarde toutes les 10 minutes... C'est pas une solution mais si ça peut éviter à ovh de supprimer mon serveur... Le process 19876 qui revient toujours, se supprime automatiquement et supprime les fichiers qu'il a ajouté. Je vais essayer d'améliorer le code de sécurité des formulaires en lisant ce que tu m'as donné. Mais par contre tu ne penses que le hackeur a pu installer un virus ou cheval de troie sur le serveur ? Encore un grand merci Dan.
Kioob Posté 18 Mars 2008 Posté 18 Mars 2008 S'il a eu les droits root il peut avoir installé un "root kit" ; et malgré les quelques outils de détection, dans ce cas c'est souvent "foutu" car il aura toujours la possibilité de masquer ses actions. Ici cela ne semble pas le cas mais bon... je n'en mettrais pas ma main à couper perso.
aodot Posté 18 Mars 2008 Auteur Posté 18 Mars 2008 merci kioob pour ta réponse. C'est quand même dingue ça sert à quoi de faire ça, de pirater les serveurs.... Moi ça me met dans le brin et je sais pas quoi faire pour en sortir. Et aucune réponse d'ovh...
pluriels Posté 18 Mars 2008 Posté 18 Mars 2008 il peut y avoir des milliers de raisons pour pirater un serveur : - préparer une attaque massive sur un autre serveur, plus il y a d'attaquants, mieux c'est - profiter de l'espace de stockage - héberger des choses plus ou moins licites - envoyer des emails plus ou moins désirés - donner du travail aux spécialistes de la sécurité Par contre, l'intervention de Dan montre clairement que le point faible des serveurs web, ce sont les formulaires.
Meschac Posté 18 Mars 2008 Posté 18 Mars 2008 Salut aodot Je voulais savoir si ton site utilise un formulaire d'upload par hasard ou quelques chose dans le style.Parce que avant d'installer un rootkit sur une machine il faut au préalable l'uploader sur le serveur. Donc soit tu as une faille qui permet de retrouver le login et mot de passe via par exemple un fichier config.php ou une sql injection qui permettrais la création d'un utilisateur admin ou l'affichage de ton mot de passe en md5 pour un forum par exemple. Il se peu également que tu sois victime d'une attaque bruteforce via ssh mais j'en doute car ovh t'aurais prévenu. D'après moi ou comme te l'a également dis Dan le problème se trouve dans un formulaire... MeScHaC
aodot Posté 19 Mars 2008 Auteur Posté 19 Mars 2008 (modifié) Bonjour à tous, Merci encore tous pour vos réponses. Je ne sais pas si il y a un root kit d'installé ou si j'ai été victime d'une attaque bruteforce. Par contre j'ai utilisé la commande "kill -9 processus" que Dan m'avait indiqué et depuis hier soir pas de piques sur les mrtg.... Il y a t'il une relation ? Je ne pensais pas que le processus était toujours actif alors que les fichiers ajoutés par le hackeur n'était plus présent. Je vais bien voir si tout se passe bien aujourd'hui et je croise les doigts. Par contre oui j'utilise bien des formulaire d'upload mais dans un backoffice protégé par mot de passe, jamais sur le site en lui même. Bon on verra bien. Je vous tiens au courant de tout façon. Cordialement. EDIT 09h08 : Bon j'ai peut etre parlé trop vite : un nouveau pic à 716 kb/s en sortie. Normal ? Inquiétant ? Avec la commande ps auwx --forest j'obtiens : USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMANDroot 1 0.0 0.0 1344 508 ? S Mar18 0:05 init [3]root 2 0.0 0.0 0 0 ? SW Mar18 0:00 [keventd]root 3 0.0 0.0 0 0 ? SWN Mar18 0:00 [ksoftirqd_CPU0]root 4 0.0 0.0 0 0 ? SWN Mar18 0:00 [ksoftirqd_CPU1]root 5 0.0 0.0 0 0 ? SW Mar18 0:00 [kswapd]root 6 0.0 0.0 0 0 ? SW Mar18 0:00 [bdflush]root 7 0.0 0.0 0 0 ? SW Mar18 0:00 [kupdated]root 8 0.0 0.0 0 0 ? SW Mar18 0:00 [scsi_eh_0]root 9 0.0 0.0 0 0 ? SW Mar18 0:00 [scsi_eh_1]root 10 0.0 0.0 0 0 ? SW< Mar18 0:00 [mdrecoveryd]root 11 0.0 0.0 0 0 ? SW< Mar18 0:00 [raid1d]root 12 0.0 0.0 0 0 ? SW< Mar18 0:00 [raid1d]root 13 0.0 0.0 0 0 ? SW Mar18 0:02 [kjournald]root 30558 0.0 0.0 0 0 ? SW Mar18 0:03 [kjournald]named 32470 0.0 0.1 16244 4024 ? S Mar18 0:04 /usr/sbin/named -u namedroot 24358 0.0 0.0 3072 1400 ? S Mar18 0:00 /usr/sbin/sshdroot 7492 0.0 0.0 5984 1892 ? S 09:07 0:00 \_ sshd: root_AT_ttyp0root 18445 0.0 0.0 2464 1332 ttyp0 S 09:07 0:00 \_ -bashroot 14276 0.0 0.0 2632 740 ttyp0 R 09:08 0:00 \_ ps auwx --forestroot 23578 0.0 0.0 1408 580 ? S Mar18 0:00 syslogd -m 0root 4881 0.0 0.0 1332 468 ? S Mar18 0:00 klogd -2root 17223 0.0 0.0 2116 940 ? S Mar18 0:00 xinetd -stayalive -pidfile /var/run/xinetd.pidqmails 15793 0.0 0.0 1376 392 ? S Mar18 0:00 qmail-sendqmaill 9664 0.0 0.0 1308 288 ? S Mar18 0:00 \_ /usr/local/bin/tai64nroot 6105 0.0 0.0 1328 320 ? S Mar18 0:00 \_ qmail-lspawn ./Maildir/qmailr 27038 0.0 0.0 1328 336 ? S Mar18 0:00 \_ qmail-rspawnqmailq 24796 0.0 0.0 1320 328 ? S Mar18 0:00 \_ qmail-cleanqmaill 18523 0.0 0.0 1332 348 ? S Mar18 0:00 /usr/local/bin/multilog /var/log/qmailroot 266 0.0 0.0 1380 488 ? S Mar18 0:00 tcpserver -H -R -c100 0 pop-3 /var/qmail/bin/qmail-popup ns38973.ovh.net /home/vpopmail/bin/vcqmaill 27403 0.0 0.0 1380 500 ? S Mar18 0:00 tcpserver -H -R -x /etc/tcp.smtp.cdb -c100 -u503 -g503 0 smtp /var/qmail/bin/qmail-smtpdroot 32586 0.0 0.2 12132 5056 ? S Mar18 0:01 /usr/local/apache/bin/httpdnobody 19823 0.0 0.3 12680 6208 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpdnobody 25464 0.0 0.2 12488 5992 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpdnobody 28335 0.0 0.2 12456 6000 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpdnobody 14277 0.0 0.2 12380 5920 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpdnobody 7913 0.0 0.3 12676 6220 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpdnobody 4238 0.0 0.2 12376 5908 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpdnobody 5263 0.0 0.2 12364 5892 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpdnobody 10811 0.0 0.2 12644 6144 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpdnobody 29108 0.0 0.2 12476 6008 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpdnobody 27779 0.0 0.3 12644 6176 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpdnobody 16794 0.0 0.3 12752 6264 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpdnobody 10633 0.0 0.2 12460 6000 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpdnobody 27830 0.0 0.3 12760 6232 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpdnobody 24666 0.0 0.2 12368 5904 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpdnobody 10735 0.0 0.2 12548 6056 ? S 08:04 0:00 \_ /usr/local/apache/bin/httpdnobody 7552 0.0 0.2 12368 5880 ? S 08:15 0:00 \_ /usr/local/apache/bin/httpdnobody 26239 0.0 0.2 12372 5900 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpdnobody 23719 0.0 0.3 12704 6176 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpdnobody 9271 0.0 0.2 12464 5936 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpdnobody 16899 0.0 0.2 12364 5876 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpdroot 6923 0.0 0.0 1560 644 ? S Mar18 0:00 /usr/lib/courier-imap/libexec/couriertcpd -address=0 -stderrlogger=/usr/lib/courier-imap/sbin/root 23099 0.0 0.0 1328 440 ? S Mar18 0:00 /usr/lib/courier-imap/sbin/courierlogger imapdroot 16804 0.0 0.0 1512 660 ? S Mar18 0:00 crondroot 7990 0.0 0.0 2224 1032 ? S Mar18 0:00 /bin/sh /usr/bin/safe_mysqld --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/ns38973.ovh.nemysql 7615 0.0 0.5 12516 10628 ? S Mar18 0:03 \_ /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysdaemon 21013 0.0 0.0 1376 544 ? S Mar18 0:00 /usr/sbin/atdroot 30937 0.0 0.0 1384 504 ? S Mar18 0:00 watchdogroot 8023 0.0 0.0 1308 296 ? S Mar18 0:00 /usr/local/clockspeed/bin/clockspeedroot 3132 0.0 0.2 6960 5480 ? S Mar18 0:00 /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.confroot 21143 0.0 0.2 7048 5692 ? S 09:06 0:00 \_ /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.confroot 24769 0.0 0.0 1316 416 tty1 S Mar18 0:00 /sbin/mingetty tty1root 12620 0.0 0.0 1316 416 tty2 S Mar18 0:00 /sbin/mingetty tty2root 3032 0.0 0.0 1316 416 tty3 S Mar18 0:00 /sbin/mingetty tty3root 24226 0.0 0.0 1320 420 tty4 S Mar18 0:00 /sbin/mingetty tty4root 29546 0.0 0.0 1320 420 tty5 S Mar18 0:00 /sbin/mingetty tty5root 1970 0.0 0.0 1320 420 tty6 S Mar18 0:00 /sbin/mingetty tty6root 14099 0.0 0.0 2156 1276 ? S< Mar18 0:00 /usr/local/etc/ncftpd/ncftpd -q /usr/local/etc/ncftpd/general.cf /usr/local/etc/ncftpd/domain.root 5591 0.0 0.0 1956 800 ? SN Mar18 0:00 \_ /usr/local/etc/ncftpd/ncftpd -q /usr/local/etc/ncftpd/general.cf /usr/local/etc/ncftpd/domclickane 3624 0.0 0.0 2228 1476 ? S< Mar18 0:00 \_ /usr/local/etc/ncftpd/ncftpd -q /usr/local/etc/ncftpd/general.cf /usr/local/etc/ncftpd/domroot 28418 0.0 0.0 1328 468 ttyS0 S Mar18 0:00 /sbin/agetty ttyS0 9600 Apparement rien d'anormal non ? Merci encore Modifié 19 Mars 2008 par aodot
Meschac Posté 19 Mars 2008 Posté 19 Mars 2008 Les nouveaux rootkits cache leur processus ou prenne des noms de processus qui n'éveille pas les soupçons donc tu n'y verra que du feu... Par contre en effet un trafic important en sortie non justifiés peu être une piste. Essaye de voir si tu n'as pas des fichiers de grosse taille qui ont été uploader à ton insu. Tu peu également regarder les dates de modification de tes fichiers php.Si tu peu réupload tout tes fichiers php depuis ton PC car il est possible que le hackeur est mis une backdoor dans un de tes fichiers php. Cordialement MeScHaC.
Dan Posté 19 Mars 2008 Posté 19 Mars 2008 700 kilobits/sec est tout ce qu'on veut sauf un trafic anormal Je ne vois rien d'anormal dans ta liste de process...
aodot Posté 19 Mars 2008 Auteur Posté 19 Mars 2008 Bonjour Dan, Merci pour ta réponse. Ca me rassure lol. Quand on est hacké je pense qu'on devient parano Bon on verra bien alors. Encore merci à tous pour votre écoute et votre aide.
Kioob Posté 19 Mars 2008 Posté 19 Mars 2008 Béh tout est relatif... si en temps normal le débit sortant dépasse pas les 100kbps, un "pic" à 700kbps peut être anormal.... tout comme un "pic" à 150Mbps sur certains serveurs peut être tout à fait justifié :S
Dan Posté 19 Mars 2008 Posté 19 Mars 2008 Il suffit de quelques visiteurs qui surfent pour faire monter la BP à 700Kb/s ... même si le débit moyen est généralement plus bas.
Kioob Posté 19 Mars 2008 Posté 19 Mars 2008 Oui, ou un seul pour monter à 10Mbps... ça ne change rien au "problème" : sans plus d'infos sur le trafic "habituel" ni la durée du pic, on ne peut absolument pas se prononcer sur la valeur de ces 700Kbps.
Nicolas Posté 19 Mars 2008 Posté 19 Mars 2008 Le mieux serait p-e que tu prennes un serveur récent avec une distrib plus récente. Ensuite tu mets à jour les produits (php,mysql, phpmyadmin, etc ...) afin que ton serveur soit le plus sécurisé possible. Après tu migres site par site en vérifiant tes formulaires et scripts sensibles tout en jettant un oeil à ton serveur histoire de voir si tu as de nouvelles attaques. C'est juste une idée comme ça ;-)
Kioob Posté 19 Mars 2008 Posté 19 Mars 2008 Le minimum serait déjà de faire tourner tout ça via FastCGI, avec chaque site sous un user différent ; ça permettrait de rapidement identifier le site fautif... et de limiter toute propagation en cas de "hack". Mais bon... les problèmes de sécurité sont bien souvent pris à la légère.
aodot Posté 20 Mars 2008 Auteur Posté 20 Mars 2008 Bonjour tout le monde, Bon mon serveur a encore été victime d'un hackeur 70 Mb/s cette nuit en sortie. En me réveillant ce matin j'ai tout de suite killer le processus. Comme Dan l'a dit mes formulaire de contact doivent avoir un problème de sécurité et le hackeur doit utiliser ma fonction mail afin de spammer. Etes vous d'accord ? Cependant même en recherchant sur google assez longtemps je ne trouve pas de solutions. Mes formulaire de contact fonctionnent de la manière suivante : contact.php : formulaire avec champas à remplir qui renvoi avers contact_envoi.php contact_envoi.php : $nom=strip_tags($_POST['nom']); (par exemple) puis envoi avec fonction mail simple. Problème de sécurité ? Quelque chose à améliorer ? Merci par avance, je continue à chercher sur google.
pluriels Posté 20 Mars 2008 Posté 20 Mars 2008 pour commencer, peut-être un lien vers le site concerné ?
aodot Posté 20 Mars 2008 Auteur Posté 20 Mars 2008 Bonjour merci pour votre message mais impossible pour moi de vous indquer l'url du site. Par contre je viens de relire l'article de dan en parallèle avec un article en français qui m'indique qu'il faut interdire les chaines \r et \n... Mon site pécherait à ce niveau alors ? Je pensais que ses chaines de caractères était considérait comme du code php mais sans les balises non (quel c.n !). Je vais donc régler ce problème et je vous tiens au courant. merci
aodot Posté 20 Mars 2008 Auteur Posté 20 Mars 2008 re-bonjour, bon je viens d'avoir de nouvelles alertes backdoor. Voila ce que j'ai fait depuis plusieurs jours : - option sécurité totale donc dernières version soft - interdire le code php et html dans les formulaires - sécurisé les codes pr éviter injection XSS - interdit les chaines de caractères \n et \r dans les formulaires Mais le pirate arrive toujours à se connecter... Qu'en pensez vous ?
Kioob Posté 20 Mars 2008 Posté 20 Mars 2008 Que ça risque de s'éterniser ? Regardes les logs, les crons, lance au moins chrootkit dans le doute, installe suhosin, passe en fastcgi, etc. Mais mettre en place un environnement "sécurisé" par dessus un environnement qu'on sait compromis, il n'y a que moi que ça choque ?
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant