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
Version complète: sur le forum Webmaster Hub : Dédié hacké, comment faire ?
Webmaster Hub > Création et exploitation de Sites Internet > Les fondations d'un site > Hébergement de Sites
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.
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.
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 ?
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 ?
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à.
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à.
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.
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.
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
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
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.
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.
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.
Ici cela ne semble pas le cas mais bon... je n'en mettrais pas ma main à couper perso.
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...
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...
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.
- 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.
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
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
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 :
Apparement rien d'anormal non ?
Merci encore
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 :
CODE
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 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 named
root 24358 0.0 0.0 3072 1400 ? S Mar18 0:00 /usr/sbin/sshd
root 7492 0.0 0.0 5984 1892 ? S 09:07 0:00 \_ sshd: root_AT_ttyp0
root 18445 0.0 0.0 2464 1332 ttyp0 S 09:07 0:00 \_ -bash
root 14276 0.0 0.0 2632 740 ttyp0 R 09:08 0:00 \_ ps auwx --forest
root 23578 0.0 0.0 1408 580 ? S Mar18 0:00 syslogd -m 0
root 4881 0.0 0.0 1332 468 ? S Mar18 0:00 klogd -2
root 17223 0.0 0.0 2116 940 ? S Mar18 0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid
qmails 15793 0.0 0.0 1376 392 ? S Mar18 0:00 qmail-send
qmaill 9664 0.0 0.0 1308 288 ? S Mar18 0:00 \_ /usr/local/bin/tai64n
root 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-rspawn
qmailq 24796 0.0 0.0 1320 328 ? S Mar18 0:00 \_ qmail-clean
qmaill 18523 0.0 0.0 1332 348 ? S Mar18 0:00 /usr/local/bin/multilog /var/log/qmail
root 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/vc
qmaill 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-smtpd
root 32586 0.0 0.2 12132 5056 ? S Mar18 0:01 /usr/local/apache/bin/httpd
nobody 19823 0.0 0.3 12680 6208 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpd
nobody 25464 0.0 0.2 12488 5992 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpd
nobody 28335 0.0 0.2 12456 6000 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpd
nobody 14277 0.0 0.2 12380 5920 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpd
nobody 7913 0.0 0.3 12676 6220 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpd
nobody 4238 0.0 0.2 12376 5908 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 5263 0.0 0.2 12364 5892 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 10811 0.0 0.2 12644 6144 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 29108 0.0 0.2 12476 6008 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 27779 0.0 0.3 12644 6176 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 16794 0.0 0.3 12752 6264 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 10633 0.0 0.2 12460 6000 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 27830 0.0 0.3 12760 6232 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 24666 0.0 0.2 12368 5904 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 10735 0.0 0.2 12548 6056 ? S 08:04 0:00 \_ /usr/local/apache/bin/httpd
nobody 7552 0.0 0.2 12368 5880 ? S 08:15 0:00 \_ /usr/local/apache/bin/httpd
nobody 26239 0.0 0.2 12372 5900 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpd
nobody 23719 0.0 0.3 12704 6176 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpd
nobody 9271 0.0 0.2 12464 5936 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpd
nobody 16899 0.0 0.2 12364 5876 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpd
root 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 imapd
root 16804 0.0 0.0 1512 660 ? S Mar18 0:00 crond
root 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.ne
mysql 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/mys
daemon 21013 0.0 0.0 1376 544 ? S Mar18 0:00 /usr/sbin/atd
root 30937 0.0 0.0 1384 504 ? S Mar18 0:00 watchdog
root 8023 0.0 0.0 1308 296 ? S Mar18 0:00 /usr/local/clockspeed/bin/clockspeed
root 3132 0.0 0.2 6960 5480 ? S Mar18 0:00 /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf
root 21143 0.0 0.2 7048 5692 ? S 09:06 0:00 \_ /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf
root 24769 0.0 0.0 1316 416 tty1 S Mar18 0:00 /sbin/mingetty tty1
root 12620 0.0 0.0 1316 416 tty2 S Mar18 0:00 /sbin/mingetty tty2
root 3032 0.0 0.0 1316 416 tty3 S Mar18 0:00 /sbin/mingetty tty3
root 24226 0.0 0.0 1320 420 tty4 S Mar18 0:00 /sbin/mingetty tty4
root 29546 0.0 0.0 1320 420 tty5 S Mar18 0:00 /sbin/mingetty tty5
root 1970 0.0 0.0 1320 420 tty6 S Mar18 0:00 /sbin/mingetty tty6
root 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/dom
clickane 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/dom
root 28418 0.0 0.0 1328 468 ttyS0 S Mar18 0:00 /sbin/agetty ttyS0 9600
root 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 named
root 24358 0.0 0.0 3072 1400 ? S Mar18 0:00 /usr/sbin/sshd
root 7492 0.0 0.0 5984 1892 ? S 09:07 0:00 \_ sshd: root_AT_ttyp0
root 18445 0.0 0.0 2464 1332 ttyp0 S 09:07 0:00 \_ -bash
root 14276 0.0 0.0 2632 740 ttyp0 R 09:08 0:00 \_ ps auwx --forest
root 23578 0.0 0.0 1408 580 ? S Mar18 0:00 syslogd -m 0
root 4881 0.0 0.0 1332 468 ? S Mar18 0:00 klogd -2
root 17223 0.0 0.0 2116 940 ? S Mar18 0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid
qmails 15793 0.0 0.0 1376 392 ? S Mar18 0:00 qmail-send
qmaill 9664 0.0 0.0 1308 288 ? S Mar18 0:00 \_ /usr/local/bin/tai64n
root 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-rspawn
qmailq 24796 0.0 0.0 1320 328 ? S Mar18 0:00 \_ qmail-clean
qmaill 18523 0.0 0.0 1332 348 ? S Mar18 0:00 /usr/local/bin/multilog /var/log/qmail
root 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/vc
qmaill 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-smtpd
root 32586 0.0 0.2 12132 5056 ? S Mar18 0:01 /usr/local/apache/bin/httpd
nobody 19823 0.0 0.3 12680 6208 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpd
nobody 25464 0.0 0.2 12488 5992 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpd
nobody 28335 0.0 0.2 12456 6000 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpd
nobody 14277 0.0 0.2 12380 5920 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpd
nobody 7913 0.0 0.3 12676 6220 ? S 05:43 0:00 \_ /usr/local/apache/bin/httpd
nobody 4238 0.0 0.2 12376 5908 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 5263 0.0 0.2 12364 5892 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 10811 0.0 0.2 12644 6144 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 29108 0.0 0.2 12476 6008 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 27779 0.0 0.3 12644 6176 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 16794 0.0 0.3 12752 6264 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 10633 0.0 0.2 12460 6000 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 27830 0.0 0.3 12760 6232 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 24666 0.0 0.2 12368 5904 ? S 07:44 0:00 \_ /usr/local/apache/bin/httpd
nobody 10735 0.0 0.2 12548 6056 ? S 08:04 0:00 \_ /usr/local/apache/bin/httpd
nobody 7552 0.0 0.2 12368 5880 ? S 08:15 0:00 \_ /usr/local/apache/bin/httpd
nobody 26239 0.0 0.2 12372 5900 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpd
nobody 23719 0.0 0.3 12704 6176 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpd
nobody 9271 0.0 0.2 12464 5936 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpd
nobody 16899 0.0 0.2 12364 5876 ? S 08:25 0:00 \_ /usr/local/apache/bin/httpd
root 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 imapd
root 16804 0.0 0.0 1512 660 ? S Mar18 0:00 crond
root 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.ne
mysql 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/mys
daemon 21013 0.0 0.0 1376 544 ? S Mar18 0:00 /usr/sbin/atd
root 30937 0.0 0.0 1384 504 ? S Mar18 0:00 watchdog
root 8023 0.0 0.0 1308 296 ? S Mar18 0:00 /usr/local/clockspeed/bin/clockspeed
root 3132 0.0 0.2 6960 5480 ? S Mar18 0:00 /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf
root 21143 0.0 0.2 7048 5692 ? S 09:06 0:00 \_ /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf
root 24769 0.0 0.0 1316 416 tty1 S Mar18 0:00 /sbin/mingetty tty1
root 12620 0.0 0.0 1316 416 tty2 S Mar18 0:00 /sbin/mingetty tty2
root 3032 0.0 0.0 1316 416 tty3 S Mar18 0:00 /sbin/mingetty tty3
root 24226 0.0 0.0 1320 420 tty4 S Mar18 0:00 /sbin/mingetty tty4
root 29546 0.0 0.0 1320 420 tty5 S Mar18 0:00 /sbin/mingetty tty5
root 1970 0.0 0.0 1320 420 tty6 S Mar18 0:00 /sbin/mingetty tty6
root 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/dom
clickane 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/dom
root 28418 0.0 0.0 1328 468 ttyS0 S Mar18 0:00 /sbin/agetty ttyS0 9600
Apparement rien d'anormal non ?
Merci encore
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.
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.
700 kilobits/sec est tout ce qu'on veut sauf un trafic anormal
Je ne vois rien d'anormal dans ta liste de process...
Je ne vois rien d'anormal dans ta liste de process...
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.
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.
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
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.
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.
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 ;-)
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 ;-)
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.
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.
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.
pour commencer, peut-être un lien vers le site concerné ?
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
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
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 ?
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 ?
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 ?
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 ?
C'est très simple, pour prévoir celà, tu as une panoplie de logiciel à ta guise dont http://www.bb4.org/, tripwire.com qui te permettent de surveiller l'activité de ton serveur, notamment, les tentatives d'intrusions, failles et autres.
Je pourrais faire un article dessus (securisation et surveillance serveur) au cas ou !
Je pourrais faire un article dessus (securisation et surveillance serveur) au cas ou !
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez cliquer ici.