vu que c'est un .cgi par pur hazard tu aurais pas awstats, pas a jour de qui plus est ?¿

enfin pour etre plus precis dans mes option voi si tu peu pas bloquer directement le dis .cgi
comment bloquer le CGI ?
Je ne peux faire aucun kill #numéro_processus sur les soretyu.cgi
Aucun ne se ferme. j'ai plein de processus de qmail dont un qui est en <defunc> mais qui ne veut pas se virer

j'ai effectivement awstats.
j'ai fait un find /var/www -name soretyu.cgi
aucune réponse....
Je suis étonné qu'OVH ne soit pas plus exigent sur ce point! étonnant de la part d'un hébergeur que de proposer des systèmes à faible durée de support... Surtout que cela revient encore moins chère à passer sur CentOS vu que le support est assuré pendant longtemps et donc des économies!
je passerai volontier à quelque chose de mieux si je pouvais. Mais vous devez tous savoir que c'est pas forcément évident et que ca se passe pas toujours comme on le souhaiterait......Y'a des BDD, des utilisateurs, des permissions, des chemins, des scripts contenant des chemins en dur (hé oui, certains vieux scripts peuvent être pourris)....Tout ca, ca demande plusieurs jours, et quand y'a plusieurs dizaines de clients sur un serveur, on peut pas se permettre, dejà, y'a plus de messagerie...
Donc certes, la migration, j'y pense et c'est le prochain objectif une fois cette merde réglée, mais tout d'abord, je dois rétablir la messagerie.

Avec des kill -9 #id, j'arrive a tuer les processus cgi, mais bon, ils vont probablement revenir...
Quelqu'un a une idée sur ce que je pourrai faire ?
Salut,

Tu pourrais mettren en place un petit script shell que tu lancerais à fréquence tres courtes, qui permettrait de tuer tous les process contenant l'extension cgi, si tu es sur et certain que sur ton serveur tu n'as pas de site web utilisant de cgi.

ps -eaf >> tous_mes_process.txt
une boucle for sur le fichier recherchant avec un sed ou autre commande le numéro du process contenant un fichier cgi...
et tu tues avec le kill -9 le process en question.

PS : j'ai eu une fois une attaque à cause d'un site basé sur un portail tout fait, genre phpnuke, postnuke, joomla ou autre, je ne sais plus lequel.

Bon courage.
teh_advizor wrote:je suis bien d'accord sur ce point, mais un serveur avec des dizaines de sites dessus, si l'update foire, bonjour les dégats...
Et si quelqu'un prend le contrôle de la machine par le biais d'une faille et efface le contenu des disques, par sûr que ce soit mieux.
AU passage... C'est qui qui a mis FC4 toi ou OVH?
Il me semble qu'à une époque OVH proposait FC4 avec Plesk.... (qui marchait pas encore sous CentOS 5)... beurk (plesk)

+
bon un cgi est un script, il dois être dans ton répertoire cgi-bin de ton serveur. (ce serais le meilleur des cas)
si il n'y est pas c'est que tu a une faille du type "awsats pas a jour grave", y a eu une faille de comblé permettant ce type de souci.
une faille permettant d'apeller un script externe et de le lancer sur le serveur.
donc a voir de ce cotes.

si ton fichier .cgi n'est pas sur ton serveur, il vas te falloir passer les log a la moulinette et trouver quel est le script qui merde et laisse exécuter un cgi externe sur ton serveur.
si il est sur ton serveur il faudra trouver comment il est entrée ...
remi wrote:Il me semble qu'à une époque OVH proposait FC4 avec Plesk.... (qui marchait pas encore sous CentOS 5)... beurk (plesk)
plesk est la PLAIE des sites dédiés, la première chose que je fais c'est le court-circuiter.