みなさん、こんにちは！
ブリュの公式ブログ.netにお越しいただきまして、ありがとうございます。
このサイトでは、ITについて特化したサイトを運営しています。
今回は、メインブログの方で取れたログ、183.181.86.72:6800/php/urlblock.phpについて紹介します。
このログは直ちセキュリティ面に影響を与えるものではないのですが、WordPressの脆弱性を狙ったログのようで、不正アクセスをブロックしている痕跡となります。
よって、現時点において何らかのトラブルが生じるわけではないのですが、潜在的に脆弱性を持っており、さらに脆弱性を悪用した攻撃が行われたということですから、利用しているプラグインなどを一度見直す必要があります。
また、WordPressのバージョンなどは、最新版に変更するようにしてください。
目次
183.181.86.72:6800/php/urlblock.phpというログ
いつものようにGoogleアナリティクスを眺めていると、集客→リファラーの項目に、見慣れないアクセス履歴がありました。
クリックしてみると・・・
すべてつなげると・・・
183.181.86.72:6800/php/urlblock.php
ん？
なにこれ？
183.181.86.72って、今使っているエックスサーバー
のIPアドレス・・・
しかもurlblock.phpというファイル名が、いかにもやばそうな雰囲気を醸し出しています。
何かボットでもブロックしたのかな・・・？
と思い、あまり真剣には考えていなかったのですが、気になったので詳細を調べてみると、WordPressの脆弱性を狙った不正アクセスをブロックした痕跡のようでした。
/php/urlblock.phpは脆弱性を狙った不正アクセスの痕跡
ソースとしては、さすがはノートンを提供しているアメリカのシマンテック。
ちゃんと情報が乗っていましたよ。
urlblock.phpというのは、日本語で書くとURL 遮断アウトブレーク警告というものらしい。
URLフィルタ違反によってURLが遮断されたことを意味しています。
脅威またはポリシー違反が発生したアクセスを検知したものであり、結局のところ何らかの不正アクセスが試みられたものをブロックされたことになります。
WordPressの場合には脆弱性を狙っている不正アクセスが多く、これを検知したということでしょう。
なお、この機能はWAFとは異なるようです。
このurlblock.phpに関するシマンテックの製品は、Symantec Protection Engine for Cloud Services 8.0というものであり、分類的にはウイルス駆除などを行う系の製品です。
WAFとは動かす位置が根本的に異なるものであり、
- WAFはウェブサーバーの前段
- Symantec Protection Engine for Cloud Services 8.0はウェブサーバー内部
となります。
WAFによるブロックは、ウェブサーバーに触れることなくブロックしています。
ウェブサーバー内部への侵入前に遮断するのがWAF。
しかし、/php/urlblock.phpによるブロックは、ウェブサーバーに到達したうえでブロックされているということです。
サーバー内部への侵入者をブロックして排除するイメージです。
オートロック付きのマンションをイメージすれば、WAFはオートロックで侵入をブロックするようなもの。
/php/urlblock.phpは、部屋の前に来て、ドアを開けかけたところでブロックするもの。
要はサーバーという敷地内に侵入されているかどうかの違いがあります。
アクセスが遮断されたという結果は同じなのですが、WAFによるブロックよりも深刻度は高いです。
また、ウェブサーバーまで攻撃が到達しているとも言えます。
これは、WordPressなどに根本的に脆弱性があり、サーバー側のセキュリティをすり抜ける形で攻撃が成功していることを意味していますから、
- WordPressを最新バージョンにアップデートする
- プラグインの使用を控える
等といった対策も必要と思います。
実際、メインブログにおいてのみ利用しているプラグインはすべて停止の上、念のため削除まで行い、様子を見ることにしましたから。
/php/urlblock.phpが作動するほどの攻撃を受けていない他のWordPressサイトと同じ条件にすれば、ひとまずは安心ですからね。
結果：ゼロデイ攻撃のようでした
結局、何に対して/php/urlblock.phpが作動したのかはよくわかりませんが、2日後にWordPressのセキュリティアップデートがあったので、ゼロデイ攻撃を食らったことになるのが妥当と思います。
ゼロデイ攻撃とは、脆弱性が発見されたときに、WordPressなどの開発陣がセキュリティ対応を行う前に、既知の脆弱性に対して総攻撃を行うものです。
脆弱性が見つかった当日、つまりゼロデイに攻撃を行うから、ゼロデイ攻撃といいます。
※脆弱性：プログラムのバグをついた攻撃のこと
時系列でみると、/php/urlblock.phpを検出したのが2019/12/17 12:11です。
そして2日後の2019/12/19に、WordPressのバージョンが5.3.1から5.3.2になりました。
WordPressのアップグレードには3つのバターンがあります。
- メジャーアップデート（特に大規模）（4.9.x→5.0など）
- メジャーアップデート（5.1.x→5.2など）
- マイナーアップデート（5.1.1→5.1.2など）
メジャーアップデートに関しては機能の追加など、様々な変更が行われています。
最近でいえばWordPressが5.0系になって、エディタがGutembergに変更されました。
そして、WordPress5.1、WordPress5.2と進化していく中で、既存の様々な機能がより高機能化したりしています。
一方のマイナーアップデートに関しては、別名セキュリティアップデートとも呼ばれており、WordPressの機能をそのままにセキュリティの強化および脆弱性への対応が行われたものを示します。
今回、/php/urlblock.phpが検出され、その後5.3.1→5.3.2にアップグレードされたわけですから、正真正銘のセキュリティアップデートです。
本当にサーバー側の該当ログが見れないので、何に反応して/php/urlblock.phpが作動したのかわかりません。
しかし、こうした事実を並べていると、やはり、/php/urlblock.phpは、WordPressの脆弱性をついた不正アクセスの攻撃をブロックした痕跡ということが、だんだん現実味を帯びてきました。
まさにゼロデイ攻撃、いや、ゼロデイより前なので、マイナスワンデイ攻撃かもしれません・・・（笑）
まとめ
ここまで、Googleアナリティクスにて記録された、/php/urlblock.phpについて紹介をしてきました。
結局のところ、何に反応したのかまでは不明なのですが、サーバー側のセキュリティが作動したことは確実なようです。
また、攻撃されたログではなく、サーバーのセキュリティが作動したログなので、今すぐに心配する必要はありません。
ただ、潜在的に何かしらのセキュリティ的なリスクを含んでいることになるので、脆弱性の原因を考えてみて、心当たりがあれば早めに対策をしておきましょう。
また、WordPressやプラグインを、最新版に更新していないものがあるならば、すぐに最新版に更新してください。
以上、/php/urlblock.phpについて、参考になれば幸いです。
