前回はプリペイドSIMの話題でした。
そのままプリペイドSIMカードネタを進めようと思ったのですが、ここのところサイトが不安定になりいろいろ原因追求に追われていました。
今回はこの顛末について紹介したいと思います。
サイトが落ちる？
1ヶ月ほど前からこのサイトが非常に不安定になっていました。
現象としては起動して1日もしないうちに「データベースエラー」あるいは「500 Internal Server Error」が発生してしまい、サイトが表示されなくなってしまうというものです。
この状態ではサーバにSSHで接続することもできず、WebからVPSを再起動する復帰手段はありませんでした。
何が起きていたのか？
VPSを再起動させSSHでログインしてみて最初に気づいたのは、空きディスク容量が「0」になっていました。
調べてみるとnginxのログが膨大に膨れ上がっていてディスクを圧迫して制限に達していました。
ログを確認すると次のような痕跡が残っていました。
- Nginxのログ(WordPressサイト)
accept4() failed (12: Cannot allocate memory) (何度も繰り返す)
- Nginxのログ(静的なサイト)
accept4() failed (12: Cannot allocate memory) (何度も繰り返す)
- MySQLのログ
mysqld: 130821 13:38:28 [ERROR] Error in accept: Cannot allocate memory (何度も繰り返す)
- PHP5-FPMのログ
NOTICE: [pool www] child 54787 started NOTICE: [pool www] child 54787 exited with code 0 after 0.001766 seconds from start (何度も繰り返す)
ログから判断すると、メモリが不足し内部通信ができなくなっている、というように見えます。
復帰方法
上記の現象が発生した場合は、VPSを強制的に再起動しているためMYSQLのデータベースが破損している可能性が高いです。
したがって、膨れ上がったログファイルを削除するほかに次の処理を行う必要がありました。
suコマンドでrootになります。MYSQLのデータベースがあるディレクトリ(/var/lib/mysql)には一般ユーザではアクセスできないためです。なお、「WordPressのデータベースがあるディレクトリ」はDebianの場合は「/var/lib/mysql/<サイト名>」となっています。
su cd (WordPressのデータベースがあるディレクトリ)
次にMYSQLを停止したあとに、すべてにデータベースを修復します。
/etc/init.d/mysql stop myisamchk -s -r *.MYI
これでも調子が悪いときは-eをオプションをつけてみます
myisamchk -s -r -e *.MYI
「-e」オプションをつけて実行した場合に次のようなエラーが出る場合があります。
myisamchk: error: Not enough memory for blob at 71716 (need 1936028278) MyISAM-table 'wp_posts.MYI' is not fixed because of errors Try fixing it by using the --safe-recover (-o), the --force (-f) option or by not using the --quick (-q) flag
この場合は次のようにmyisamchkコマンドを実行するととりあえず最後まで完走します。
myisamchk --max-record-length=0 -s -r -e *.MYI
修復が完了したら、MYSQLを再起動します。
/etc/init.d/mysql start
調査
このサイトはServersMan@VPSのスタンダードプランを利用しているため、保証メモリは2GB(最大4GB)あり、メモリには余裕があるように思えます。
実際、平常時に使用しているメモリは800MBほどかなり余裕があります。
単にメモリが不足しているのではなく、他に原因があるのかと思い、いくつかの仮説を立てて調査してみました。
- PHPが使えるメモリが足りない？
PHPで使用するメモリは設定で上限を設けることができます。この上限が悪さしているのかもしれないと思い、上限を引き上げてみました。具体的には「/etc/php5/fpm/php.ini」の「memory_limit」を128MBから256MBに引き上げてみました。
しかし、結果は変わらず、1日もしないうちにサイトがダウンしてしまいました。
- PHPがメモリ使いすぎ？
上記の仮説とは逆にPHPがメモリを使いすぎて、システムのメモリを使い尽くしているのかもしれないと思い、逆に上限を引き下げてみました。具体的には「memory_limit」を64MBにしてみました。
しかし、効果はなく、サイトはダウンしてしまいました。
- プラグインが暴走してメモリを食っている？
思い切ってWordPressプラグインをいったんすべて無効化してみました。これは効果があったようでした。久々にサイトが24時間以上安定動作しました。しかし、翌日には再びダウンしてしまいました。
さらに、5分おきにシステムの空きメモリ、nginxの使用メモリ、php-fpmの使用メモリ、mysqlの使用メモリを記録してみたところ、使用メモリが徐々に増えていくということはなく、あるとき突然サイトがダウンしているように見えました。
結局、原因はつかめず落ちるたびに再起動するという暫定対応をとるしかありませんでした。
原因を発見！
もやもやしたまま、サイトダウン→VPS再起動→復旧を言うことを繰り返していると、ある日に初めてサイトがダウンした直後に気がつくことができました。
すぐにVPSを再起動して普及してみます、しかし・・・CPUのロードアベレージ(CPU負荷)が異常に高いのです(5以上を記録しました)。WordPressのサイトにもアクセスができません。
topコマンドをphp5-fpmのプロセスが負荷のかかっているプロセスとなっており、また、プロセスの生成→終了を激しく繰り返していることがわかりました。
とりあえず、/etc/php5/fpm/pool.d以下にある設定ファイルで、「pm=static」「pm.max_children=4」として、php5-fpmのプロセス数を4で固定化してみますと、若干安定度を回復したものの、WordPressサイトは表示されたりされなかったり不安定なままです。
ここで、ふとアクセスログを見てみると・・・
93.77.1.189 - - [25/Aug/2013:17:40:47 +0900] "POST /wp-login.php HTTP/1.0" 200 3737 "bcratchpad.jp/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0" 93.77.1.189 - - [25/Aug/2013:17:40:47 +0900] "POST /wp-login.php HTTP/1.0" 200 3737 "scratchpad.jp/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0" 2.184.47.253 - - [25/Aug/2013:17:40:47 +0900] "POST /wp-login.php HTTP/1.0" 200 3737 "scratchpad.jp/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0" 186.79.134.136 - - [25/Aug/2013:17:40:49 +0900] "POST /wp-login.php HTTP/1.0" 200 3737 "scratchpad.jp/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0" 36.231.170.146 - - [25/Aug/2013:17:40:50 +0900] "POST /wp-login.php HTTP/1.0" 200 3737 "scratchpad.jp/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0" 89.190.58.55 - - [25/Aug/2013:17:40:51 +0900] "POST /wp-login.php HTTP/1.0" 200 3737 "scratchpad.jp/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0" 93.79.224.11 - - [25/Aug/2013:17:40:54 +0900] "POST /wp-login.php HTTP/1.0" 200 3737 "scratchpad.jp/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0" ・・・・
猛烈な勢いでWordPressのログイン画面(wp-login.php)にアクセスがあるではないですか！ 1分間に20～30回の頻度です。
これは不正アクセスを狙った攻撃です。
私のサイトでは連続した不正ログインの試みによりphp5-fpmが何度も動作してCPU負荷が上がりシステムダウンにつながっていたようでした。
幸い「admin」アカウントはインストール時に削除していたため、不正ログインはされていないようですが、何らかの手を打つ必要があります。
まとめ
今回はこのサイトがWordPressを狙った攻撃により不安定になっていたことを紹介しました。
次回は、この攻撃に対する簡単な対応を紹介します。
コメント