上記事のことで、昨日またまたサーバが停止しました。
いい加減にしてくれとrebootをかけてエラーログを確認したのですが、よくよく考えたらapacheのエラーログばかりで通常時のアクセスログを確認していなかったことに気づきました。何やっとんねん。
ということで確認した内容と、対応した内容を記します。
今回確認した事象(おさらい)
・不定期にDISK I/O負荷が急増する
・事象発生時にはサイトにアクセスできなくなる
・コンソールはかろうじて動くがかなり重い
・rebootすれば解消する
apacheのアクセスログを確認する
/var/log/httpd配下のaccsess.logを確認してみると、以下の通り。
同じIPアドレスからサーバの特定のファイルxmlrpc.phpにずっと接続してきている…※攻撃者のIPはいっそ晒してやりたかったのですが、その辺のモラルやら法律には疎いので黒で塗りつぶしています
つまりあっしのサーバは、攻撃者の接続要求クエリ→失敗→攻撃者の接続要求…の繰り返しで高負荷がかかってしまっていたらしい。
xmlrpc.phpとはなんぞや？
と思って調べてみると、外部からWordpressを制御するプログラムの様ですね。スマホのアプリとかを利用して記事を投稿する際はこのプログラムを使うらしく、よく攻撃の対象にされるとのこと。へえ。
.htaccessでアクセス制限しちゃいましょう
xmlrpc.phpを配置している階層にある.htaccessに以下の記述をしました。そもそもxmlrpc.phpにアクセスさせず403エラーを返す様にします。
<Files xmlrpc.php>
Order allow,deny
Deny from all
</Files>
CPU負荷が一気に下がった
日●の株価ばりにCPU負荷が急落しました。攻撃者のIPからのアクセスはまだ続いておりますが、全て403のエラーで返すことに成功しています。
apacheに対する接続要求はまだ続いているので、てっきりiptableでIPアドレス制限するまでは負荷は落ちないと思っていたのですが、403を返している時点でそれ以降の処理はさせていないのかしら。まあIPも制限するけど。
ということで久々の障害調査ですが、やはり結構時間喰いますねー。ある程度障害にあたりがつけばネットに解決する情報はたくさん載っているのですが、今回は始めて確認した事象なのでそこに行くまでに時間がかかってしまった…
まさか自分の大学時代の研究内容に触れることを、数年後自分が身をもって体験するとは…笑
とは言えアクセスログを確認せずエラーログばかり確認していたのはかなり反省。もう少しapacheについて勉強しよう。
おしまい。