Malware S.Susp.PHP.gen...

[ortolojf]

Bonjour

Finalement, Google pense que mon site est piraté.

Un Monsieur de GoogIe Community m'a donné une url de rapport détaillé de malware par rapport à mon site.

Le malware est théoriquement : S.Susp.PHP.gen

Toutes les urls indiquées dans le rapport, ne correspondent à rien de connu, et elles redirigent correctement en 301 vers des pages existantes.

Le rapport m'attribue Wordpress, alors que mon site n' a jamais eu aucun CMS.

Le Monsieur me suggère de vérifier si aucun de mes scripts n'a de liens vers des urls du rapport.

Exemples d'urls :

/php/courses_actuellesn ou n est un nombre entier entre 1 et 11.

Ils sortent d'où ces acrobates ?

Que faire ?

Le Monsieur prétend que la dernière vérification date de ce matin.

?

Merci beaucoup de votre aide.

Amicalement.

 

[ortolojf]

Pardon

Un coup de rkhunter me détecte le classique xorddos.

Comment m'en débarrasser ?

Merci beaucoup.

 

[cthierry]

Quand je te lis et que je me dis que j'ai bien fait d'utiliser Plesk pour la gestion de mes serveurs même si je sais qu'il s'agit d'une surcouche.

Sinon : https://monovm.com/blog/how-to-remove-xorddos-trojan-from-linux/

 

[ortolojf]

Bonjour cthierry

rkhunter me signale seulement le fichier /var/run/udev.pid

Ce fichier a un pid inexistant.

D'autre part, systemctl n'a jamais marché sur mon vps de Gravelines ( 8 Go RAM, 160 Go SSD ), que j'avais loué après l'incendie de Strasbourg.

Je fonctionne avec /etc/init.d/ pour les démarrages/arrêts des services.

J'ai vérifié tous les fichiers exécutables ELF non stripped, 32 ou 64 bits :

find / -type f -exec {} \; | grep -i 'elf' | egrep -v -e "not[ ]+stripped"

Aucun n'a de nom bizarre.

Même chose pour tous les fichiers autres qu'exécutables.

D'après 'netstat -n -all LISTEN', le seul port suspect est : 8892.

J'ai complété fail2ban et changé les password de mes users.

Il semblerait que rkhunter ait détecté que la date de modification de /var/run/udev.pid soit ancienne.

Les répertoires : /etc/rc[0-9].d/ et /etc/init.d/ ne contiennent rien d'anormal.


Je n'ai pas détecté de xorddos après ces manipulations.

Est-il possible que rkhunter se soit trompé ?

Merci beaucoup cthierry de ton aide.

Amicalement.

 

[cthierry]

Je ne saurai te répondre par l'affirmative, n'ayant jamais rencontré ce genre de problème. Si quelqu'un de plus calé en Linux passe dans le coin...

Mais tu n'est pas le seul à te poser des question sur les faux positifs :
https://www.google.com/search?q=/va...=chrome..69i57j69i58&sourceid=chrome&ie=UTF-8

 

[ortolojf]

C'est super cthierry

Merci beaucoup pour ton lien.

Le bug provient uniquement de ce que je n'ai pas systemctl et systemd, seulement /etc/init.d/

Il semblerait ( à part mes scripts PHP qui sont probablement clean ), que mon VPS ne soit pas infecté.

Je vais tester chkrootkit.

Merci beaucoup de ton aide.

 

[ortolojf]

Rebond

Un chkrootkit m'indique ceci :

|code=text]

Fichiers suspects :
( je remplace les fichiers par l'astérique * ).

/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_wrongrelm/*
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/noentry/*
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_time/*
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_anon/*
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest/*
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/authz_owner/*
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/file/*

Searching for suspect PHP files... nothing found

Checking `bindshell'... INFECTED PORTS: ( 465)

eth0: PACKET SNIFFER(/usr/sbin/dhclient (deleted)[546], /usr/sbin/dhclient (deleted)[498])

[/code]


Je ne sais pas ce que veut dire "infecté" pour les ports.

L'interface eth0 n'est pas en mode promiscuous.

Pour le cas des dist-packages et fichiers apache, j'utilise Nginx et pas Apache.

Que faire ?

Merci.

 

[cthierry]

Regarde si cela peut t'aider :
https://benohead.com/blog/2012/04/17/chkrootkit-false-positive-bindshell-infected-port-465/

 

[ortolojf]

Bonjour cthierry

J'ai trouvé.

Le bug venait du fait que ma page /404.php n'est pas interprétée par le php.

J'ai arrangé celà, maintenant toute erreur 404 rend le 404 tel quel.

https://quttera.com me déclare "clean".

Demain matin, je m'enquerrai auprès de Google Community pour savoir si je peux faire une demande de réexamen.

Merci beaucoup de ton aide.

 

[ortolojf]

Bonjour

J'ai fait ma demande de réexamen.

Le Monsieur de Google Community ne voyait plus de problème à mon site.

J'ai corrigé beaucoup de choses sur mon site.

Merci à tous les Wrinautes.

Respectueusement.