[サーバートラブル対応記録] いきなりダウンしててんてこ舞いの巻

それはいきなり発生した事象でした。 自分で管理しているサーバーは、外部監視システムにて、障害アラートが発生するように事前にセットしておくのが、WEBサービスの基本マナーです。 その外部監視が、大量に発生したのが、某月某日の午後16時過ぎ。 こうした複数のサーバーでの同時アラートは、まず考えられることは、サーバープロバイダの障害か、ネットワーク回線障害だろうと、のほほんとしていたが、このサーバーの中に、他社から頼まれて公開しているホームページなどもあるため、あまり悠長にしてはいけないと考え、とりあえず、原因究明をしようと考えて、できる限りの調査をしてみました。 ところが、sshもアクセス出来ない上、VPSの管理画面もアクセスエラーになる始末。 いよいよ、サーバー管理会社の粗相ではないかと疑っていた所、gmailに先方からメールが入って事態が明確になってきました。

障害の正体

それは、どうやら管理しているサーバーの中で、外部サーバーに対して大量にパケットを送信しているものがあるとの事で、規約によりアカウント停止の刑に処するとの冷たい書かれ方がされていました。 ※ウソです、本当はもっと丁寧に冷酷に書かれていました。 そういえば、以前からサーバーのproc数がたまに膨大に増える時間帯があったと記憶していた。 それにしても、予告もなしに、いきなりバンするなんて、国内サービスでは、なかなかの冷酷さ。 確かにこのプロバイダーは、値段は激安だが、評判があまり良くないので、致し方ないと考えたのだが、データを復旧できないのも困る。 データさえあれば、別IDCに乗せ替えてDNSを切り替えてしまえばそれで収束するのだが、いかんせん、サーバーを復旧してくれないことには、そうも行かない。 これは下手に出て、ちゃんとサーバー起動するまで、おとなしくするしか無いと考え、メールで対応策を送り、返答を待つことにした。

対策検討

とはいえ、これは、自分のセキュリティ対策の甘さが招いた事象なため、考えられる原因と、その対応策、今後のセキュリティ体制を考えてみることにした。 おそらく、入力フォームリクエスト・フォージェリというすごく初歩的な脆弱性により、サイト内のPHP書き換えを狙われたのだと、自分なりに結論立てた。 某会社のお問合せフォームを簡易に作成して、設置してあげたのだが、その際に確認画面の表示で、プログラム起動できる脆弱性が潜んでいたのだと考えられる。 簡易に作ってもこうしたセキュリティの手を抜くことはいけませんね。 これの対応策は、入力フォームデータの記号系の文字列は、必ず一定のエンコードをして表示処理や、バックシステム処理を行わないと行けないところを手を抜いてしまったんですね。 ちゃんとphpなどでの受け渡しには、エンコードすることで今後の対応は完了でしょう。 あと、wordpressは、脆弱性を狙われやすいので、今後はこうした一般的なフレームワークは使わないようにしようと心に誓いました。

IDCから返答があったのは次の日

かなり時間が経ってから、返答があり、延々と先方の規約の説明と、対応策の説明を繰り返され、丸2日ぐらい捨ててしまいました。 先方も、ちゃんとした対応策を提示されているので、復旧しないという選択肢は無く、その後は無事に復旧してもらうことができました。 世間的に長期休暇のタイミングであったので、思ったよりも早く復旧できたのはうれしかったのだが、そもそも、1時間ぐらいは警告予備時間をもらえたら、その間に対策を施すことは可能であったため、今回のバン対応は、かなり非人道的な策であったとして、そういう評価をする事になりました。 そういえば、サーバーのファイル書き換えも微妙に発生していたので、書き換え検知なども検討しなければいけないけど、この手の手法は、WEBアプリケーションごとに構築しなければいけないので、であれば、自分発信で、書き換え検知サービスを作ってみようかとも考えて、仕事にプラスに持っていくことにしました。 同じ思いをしたことがある人や、書き換え検知などのサービスを欲している人などがいれば、是非交流会をしてみたいですね。