当Webサイト(https://inaba-serverdesign.jp)にはアクセス解析ツールAWStatsを設置していて、ときどきアクセスをチェックしています。

少し前から「ロボットとはみなされないが、特定のIPアドレスからのPV数とヒット数が同じ＝何らかの機械的なアクセス」が増えていることに気づきました。
アクセスログを調べてみると、2017年6月6日から、以下のような、トップページへのPOSTリクエストが急増していることがわかりました。
（IPアドレスは伏せています）

xxx.xxx.xxx.xxx - - [07/Jun/2017:22:56:17 +0900] "POST / HTTP/1.1" 200 33531 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko"
xxx.xxx.xxx.xxx - - [07/Jun/2017:22:58:18 +0900] "POST / HTTP/1.1" 200 33531 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko"

このWordPressサイトでは、トップページへのPOSTリクエストは何の意味もないので、不正アクセスですね。
このようなアクセスは、それ以前は1週間にせいぜい2,3件だったのが、6月6日以降は、ほぼ2分おきに、1日あたり30から180件ぐらいありました。
あるタイミングでパタっと止まると、翌日はまた別のIPアドレスから同様のアクセスが始まります。
Whoisでアクセス元IPアドレスを調べたところ、CountryはすべてUSですが、日によってStateやOrganization Nameはバラバラでした。
ボット感染したPCからのアクセスでしょうか。

ログインページならまだわかりますが、トップページへのPOSTリクエストって、なんなんでしょうね。
せっかくなら、POSTリクエストの中身も確認しておけばよかったです。
（まあ、相手はプログラムで大量のサイトに機械的にアクセスしているだけで、WebサイトがWordPressかどうかは認識していないのでしょうが。）

「WordPress POSTリクエスト」で検索してみると、こんな記事が見つかりました。

・WordPressサイトが改ざんされたお話
https://with-planning.co.jp/wordpress-site-tampering/

「サイトにアクセスすると全く知らない別のサイトへリダイレクトされる。」
ように改ざんされていた、とのことです。
怖い。。

念のため、自分のPCをフルスキャンして、マルウェア等に感染していないことを確認しました。
サーバー側では、自分でwp-config.php, index.php, header.php等の基本的なファイルの中身や、おかしなファイルがないかチェック。
さらに、Wordfence SecurityプラグインのScan機能でチェックして、Webサイトが改ざんされていないことを確認しました。
ひと安心です。

※Wordfence SecurityプラグインのScanで、ずっと更新されていない古いプラグインがいくつかあることがわかったので、削除しました。

というわけで、このWebサイトでは、トップページへPOSTリクエストを受けても実害はないことがわかりました。
ですが、意味のないアクセスに対して、少しでもリソースを消費するのは嫌なので（それと、アクセス数としてカウントしてしまって正確なアクセス数が掴めなくなるのが嫌なので）、「トップページへのPOSTリクエスト」に対してはステータスコード「403 Forbidden」を返してブロックすることにしました。

NginxはAnd条件が指定できないので、if文を使って、こんな書き方になります。

if ( $request_method = POST ) {
    set $test A;
}
if ( $request_uri = / ) {
    set $test "${test}B";
}
if ( $test = AB ) {
    set $deny_f 1;
}

if ( $deny_f = 1) {
    return 403;
}

※個人的には、こういったブロックルールをVirtualHostごとのConfigに記載したくないので、block.conf のような、ブロックルール専用のConfigファイルを別途用意して、VirtualHostごとのConfigからIncludeしています。

Apacheだと、Rewriteルールでこんな書き方になります。

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/$
RewriteCond %{REQUEST_METHOD} ^POST
RewriteRule .* - [F]

このブロックルールを追加してからも、4時間ぐらいはアクセスが続きましたが、この日のアクセスが止まったのち、翌日からはこのPOSTリクエストが来なくなりました。
相手のほうで、エラーのステータスコードをある程度受け取ると、そのサイトへのアクセスはやめるようなつくりになっているのでしょう。

なお、WordPressのログインページについては、以下の対策を行っています。

• ログインページと管理ページはBASIC認証を設置。
• Login rebuilderプラグインでログインページのURLを wp-login.php から変更。
• Login LockDownプラグインで、一定回数ログインに失敗したときはそのIPからのアクセスを禁止。

BASIC認証は案外効いていて、WordPressのログイン履歴を見る限り、不正アクセスに突破されたことは一度もありません。
「2回パスワード入力するのは面倒。」
「ログインページで複雑なパスワードを使用していれば問題ない。」
ということでBASIC認証は無駄、という考え方もあるかもしれませんが、多重の防御はセキュリティ対策の基本です。
また、パスワード総当たりのような攻撃に対しても、アプリケーションのログイン認証よりは、BASIC認証のほうがサーバーへの負荷がはるかに少ないです。

WordPressを使うと簡単にWebサイト、ホームページを作成できるので、利用している方も多いと思いますが、ユーザーが多いということは、その分攻撃対象になりやすいとも言えます。
ログインページの防御、WordPress本体やプラグイン、テーマは最新バージョンを保つ等、基本的なセキュリティ対策は必須ですし、不正アクセスがないか、定期的にログを確認するとよいと思います。

• 3
• 0
• 0