WordPress DoS攻撃対策をした話。Amazon EC2 nginx 環境下で対応しました。

スポンサーリンク

WordPress にて xmlpc.php に大量のアクセスを受けた

一応、日時を記しておきますと、2016年 6 月 18 日にこのブログに大量の DoS 攻撃を受けました。

朝の段階でブログを見た時には、「なんか表示がちょっと遅いかも」。

と、感じてはいたんですが・・・。

昼過ぎにアクセスすると、なんと Amazon EC2 で利用している nginx がエラーを吐いていました。

nginx-502-error

サイトの設定などを触った記憶はないので、まさしく青天の霹靂なわけです。

画像がちょっと小さいかもしれないのですが、エラーの内容としては、

「なんか、エラーが起きてるよー」。

とのこと。

解決にあたり、なんとも頼りないエラー表示ですが、サイトが正常に動いていないことは明らかなようなので原因を調べていくことに。

その結果、DoS 攻撃だとわかるわけですが・・・。

DoS 攻撃、DDoS 攻撃とはなに?

念のため説明しておきますと、DoS 攻撃、DDoS 攻撃とは?

DoS攻撃(ドスこうげき)(英:Denial of Service attack)は、コンピューティングにおいてサーバなどのコンピュータやネットワークリソース(資源)がサービスを提供できない状態にする意図的な行為をいう。サービス妨害攻撃と訳される。
サーバなどのコンピュータ機器にある脆弱性を攻略するものと、サーバの処理能力やネットワーク帯域に対して過剰な負荷をかけるものがある。
複数のコンピュータを攻撃側に巻き込む類型としてDDoS攻撃(ディードスこうげき)(英:Distributed Denial of Service attack)がある。

【出典:https://ja.wikipedia.org/wiki/DoS%E6%94%BB%E6%92%83】

まあ、今回の攻撃が DoS なのか、DDoS なのかはどっちでもいいのですが、非常に迷惑な話です。

まずは、サーバーの状況を確認へ

nginx がエラーを起こしているということで、Amazon EC2 の様子を見に行きます。

ssh コマンドで詳細な状況を確認・・・。

「あれ? Amazon EC2 の SSHログインってどうするんだっけ?」

と、普段サーバー関連の作業をしないので、こういった時の手順やら、コマンドを非常に忘れやすい・・・。

しかし、Amazon EC2 なら管理画面に入れば判ります。

管理画面にログインして、

「EC2」>「インスタンス」>「インスタンス上の項目で右クリック」>「接続」

と、たどれば SSH コマンドを表示してくれます。

instans-connect

私のように、「あれ?なんだったっけ?」となる人にとっては助かります。

こちらで接続法を確認して SSH でログイン。

ここからサーバーの状況を見てみます。

まずは、top コマンドでサーバーの状況を確認

もし、事前に htop をインストールしていれば、htop コマンドでサイト状況を確認します。

特にインストールしていない場合は、top コマンドが使えると思うのでそちらで代用できます。

こちら htop コマンドを実行したところ・・・。

htop-command

CPU が 100% フルフルで稼働中・・・。

これは何か尋常ではないことが起きていますね。

nginx 502 エラー について

サイトでエラー表示が出ている時に、何度かリロードしたのですが、その際に「502 Bad Gateway」の表示がありました。

nginx-502-error

これで解決方法を検索すると、「php-fpm」関連の対処法が出てきます。

こちら、リソースが足らないので、リソースを増やそう。

という設定になっていますが、問題が「Dos 攻撃」が行われている場合、リソースを増やしても問題解決にはなりません。

なので、まずは htop ないし、top でサーバー状況を確認していたほうがよいでしょう。

アクセス状況を確認する

とりあえず、アクセス条件を確認します。

アクセス状況は、nginx の場合、「var/log/nginx/access.log」だと思ったんですが。

今回、Amazon EC2 の WordPress 環境は AMIMOTO AMI を使っています。

その関係かどうかわからないのですが、「アクセスログ」は 「インスタンスid.access.log」 となっています。

インスタンス ID は Amazon EC2 の管理画面から確認できると思います。

なので、開くときは、

sudo vi var/log/nginx/インスタンスID.access.log

として開きます。

大量のアクセスを発見

アクセスログを確認すると、xmlrpc.php に大量のアクセスを発見。

64.137.235.207 - - [15/Jun/2016:03:41:54 -0700] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" "-"

こんなアクセスが 1 秒間に何度も。

いわゆる「WordPress の xmlrpc.php への DoS 攻撃」でした。

こういった攻撃があることは知っていましたが、「まあ、そのうち」。なんて、対応を後回しにしていたツケですね・・・。

もし、Wordpress でサイトを運用されている方でここの対応が未対応な方は早めに対策しておくことをおすすめします。

とりあえず原因が明確になったので、対応します。

xmlrpc.php へのアクセスできないように

IP アドレスを指定してアクセスを拒否しても良かったのですが、今回アクセスログを見る限り、大量ではないものの複数の IP アドレスがあることが判りました。

また、今後同じような攻撃を受ける可能性もあります。

よって、基本的に xmlrpc.php はアクセスできないようにしてしまいます。

nginx で xmlrpc.php へのアクセスを禁止する

nginx でこうしたアクセスの制限を記載する場合は、nginx.conf にて設定を行います。

ただ、単純に nginx.conf に追加するというわけでもないようです。

vi /etc/nginx/nginx.conf

として、設定フィルを覗いてみると、nginx は設定ファイルをインクルードしているみたいです。

最後の設定ファイルの一番下に

include /etc/nginx/conf.d/*.conf;

と、あります。

つまり。

/etc/nginx/conf.d/

配下にある、.conf ファイルを読み込んでいるということなので、このディレクトリ配下にある.conf ファイルに記述します。

location を記述する場所には決まりがある

今回、記述したいのは xmlrpc.php へのアクセスできないようにすることですので。

location = /xmlrpc.php {
    deny all;
    access_log off;
    error_log off;
}

と、追加したいのですが、追加しようとしたら、エラー判定。

この location ディレククティブ(nginx ではこの部分をそう呼ぶようです)は server コンテキストにしか記述できないよ。というエラーを返されました。

なので、設定ファイル内で server (server{〜} な感じのところ)コンテキストが記述してある場所を探します。

今回の環境は、Amazon EC2 で AMIMOTO AMI を利用した nginx の場合です。

sudo vi /etc/nginx/conf.d/default.conf

の中にありました。

server コンテキスト内に入れご状態で、location を追加します。

nginx を再起動

設定ファイルを記述したら、nginx を再起動するわけですが。

まずは、

sudo nginx -t 

で、設定ファイルを確認します。

このとき、設定ファイルの記述にエラーがあれば教えてくれます。

記述に問題ことを確認してから、再起動します。

sudo nginx -s reload

です。

これで、xmlrpc.php へアクセスはできなくなります。

副作用 外部エディタなどが使えなくなる

この xmlrpc.php は、スマホアプリなどの外部エディタからの更新を行うためのファイルだったりします。

そこへのアクセスを閉じてしまったので、外部エディタによる更新を利用している場合、そうしたツールが使えなくなります。

個人的には、そうした外部エディタは利用していないのでとりあえずは問題なし。

nginx 設定後、サイトも正常に見えるようになりました

この対策を行うと、すぐにサイトも正常に表示されるようになりました。

とりあえず、一安心。

DoS 攻撃の可能性を理解しつつ、対策を行っていなかった結果、大変なことになってしまいました。

こうした対策は予め行わないとダメですね・・・。

スポンサーリンク

シェアする

フォローする

スポンサーリンク