2014年7月9日水曜日

はじめてのせきゅりてーいんしでんと

ある程度コの業界にいたら一度は経験するよね


セキュリティインシデント。なんと禍々しい響きであろうか……。

まあ、ボクもそこそこの期間コの業界でお仕事しているわけなのですが、セキュリティインシデントのひとつやふたつは経験するものですよね。まあ、経験したとして、様々な事情や思惑、そしてしがらみが影響して、その体験談なりなんなりをペラペラ喋るわけにもいかず。「セキュリティの専門家のお話」的な場でもなければ、その手の話を耳にするのも難しかったり(*1)。その善し悪しはともかく。

ってことで、ちょっとペラペラ喋ってみようかなと思ったのでこのエントリを書いてみました。なお、本エントリでは、現在進行形でボクとお付き合いのある方面に関する話ではないので、その点だけご注意を。

ボクはセキュリティの専門家ではないってのと、もう結構前の話だってのと、いろいろな事情で多分にフェイクを交えているってことで、たぶんご期待にそぐわない内容になっているかと。もし、セキュリティインシデントについての深い話を聞きたいというなら、ボクのブログを開いた時点で間違ってます。

最初の一歩


そのインシデントとの出会いは、「なんかサーバが応答しなくなったんだけど」という障害レポートだったんですよ。まあ、他の誰かが構築して運用していたサーバだったのですが、いろいろ縁があってボクの所に話が舞い込んできた系のアレですね。始めは好奇心っていうか、まあよくあるアレかな〜なんてノリで話を聞いていたんですけどね。

一通り話を聞いてもいまいちピンとこなかったのもあり、ひとまず状況把握のために情報収集に着手したんですよ。

そのサーバはオールインワンなLAMPサーバで、外部向けサービスとしてはApacheだけが動いてるZE☆……的なブツでした。SSHでログインできるはずってことで、リモートからログインを試みたわけですがタイムアウト。Webブラウザからアクセスしてみてもタイムアウト。まー、とりあえずしばらく待ってみたりもしたわけですが、状況が変わらないってことで一旦リブートしましょうかという流れに。何もできなかったので(*2)。

で、そのサービスの管理コンソールからリブートしてみたわけなんですが、これも反応なしで。仕方ないので、業者さんの緊急対応窓口に電話して、強制的に(ハード的に)リブート操作をお願いするはめになったわけで。

まあ、やいのやいのいってるうちに無事リブートできて、サーバにログインできるようになった訳なのですが……。大変残念なことにこのサーバ、「何がおきたか」を調査するための環境が一切整っておらず……。一応/var/log配下のログとかを調べてみたものの、特に過負荷になっているという兆候も見られず……。ハード的な障害の可能性もなく……。怪しいプロセスがいるわけでもなく……。

端的に言えば、このときには「なぜサーバが応答しなくなったのか」という理由はサッパリ分かりませんでした。とりあえず、このタイミングで死活監視設定を入れたり、また再現したときに原因が追跡できるようにいろいろセッティングしたり(*3)して対応終了という形に。

それからしばらくは平和でした(*4)。ええ。

再び出会う


で、あるとき死活監視システムが「例のサーバが応答しなくなったぜ!」というアラートを発したわけで。とりあえず即時SSHで接続を試みたのですが、もうその時点で完全フリーズ状態とでもいうべき状況になっていたわけで。まあ、例によっていろいろあがいてみたものの、手の出しようがなかったのでリブートしてみた次第で(*5)。前回同様に。

リブート後、SSHでサーバにログインしてみて調査開始なわけですよ。前回と違っていろいろ仕込んでるんでね。

いろいろ見た中で「あれ?これ明らかにおかしい!」ってのがひとつあって、sarコマンドによるとサーバが応答しなくなった時間の前後に、I/Oウェイトがかなり高い値になっていることが分かったわけで。あー、これが原因か、と。問題は、なんでそんな状況になったかって話なんですが、I/Oウェイトの値が高いということはディスクアクセスがすげぇことなってるってことなわけで。でも、その時間帯ディスクアクセスが跳ね上がるようなことやってないんですよね。アクセスが集中しているわけでもないし、集中してたとしてもこんなにディスクアクセスがあるとは思えないし。

まあ、結論から言えば、このときも直接的な原因はサッパリだったんですよ。ので、I/Oウェイトの値を監視して、一定値以上になったらApacheを落として通知するような小細工を入れたり、前回のサーバダウン時と同じような時間帯だったのである程度おちつくまでその時間帯にSSHでログインしておいて有人監視するという方針で対応することに。

このときは「長期戦になるかな〜」なんてことを考えていたわけですが、そんな思いはすぐに裏切られたのです。

お前か……お前だったのか……


有人監視をスタートしてから数日後、また兆候が現れたのですよ。うん、なんか徐々にI/Oウェイトが高くなってきてる。とりあえず、psコマンドでプロセスをチェックしてみたのですが、特に異常もな……いやちょっとまった。なんかApacheユーザのプロセスで変な処理が走ってるぞ……って事に気づいたわけで。

で、とりあえず、そのプロセスをkillしてみたんですよ。そしたら問題となっていたI/Oウェイトの値も落ち着いたわけで。それで終わり……だったら楽なんですけど、まあ「じゃあその怪しいのはなんなのよ?」って話なわけで。まあ、調べるよね。

で、調べようかと思ったとたん、また例の問題が。psコマンドで見たら例の処理が走ってるわけですよ。またkillしたよね。で、とりあえずApache止めたよね。そしたら、とりあえずは落ち着いたよね。調査できるようになったよね。

調べてみたところ、/var/tmpに怪しげなファイルが沢山……。「foo.sock」とかいう名前のディレクトリができていて、その中にまあ直感的に「あ、これ、ヤバイ」って思わせるに十分なファイルが山盛りだったわけですよ。psコマンドの結果を見返してみたら、どうもこれらのファイルを実行しているようだ、と。あー、これアレだ。シャレにならないヤツだ、と。

Apacheユーザの権限で実行されていた不審な処理は、どうも何かをダウンロードしようとしていたもののようで。その作りがアレなのとサーバスペックがチープだったのが相まって、どうやらサーバダウンを引き起こしたようで。軽くググってみたら結構メジャーどころのクラックツールっぽくて、ircサーバとか動かせるようになってるっぽく。

まあ、それまでクラックツールなんてお目にかかる機会がなかったので、ブツを保全した上でそれらのパーミッションを「000」にする形でアクセスできないように暫定対処(*6)。一旦Apacheを起動してみることに。しばらく状況を見てみたら安定しているようなので、まあ根本的な対処に移ることに。

あー、穴っすね


Apacheユーザの権限で動いていたってことは、まあWebサーバに関する部分で何かが起こってるのは確定なわけで。大人の事情で関与できるのがインフラ面だけだったのだけれど、パッチの類はちゃんと最新のものが適用されているのは確認済み。じゃあ、コンテンツ方面が怪しくねぇかな……と思うのは自然だよね。

で、ちょっと大人の事情的にアレではあったんだけども、コンテンツ方面をのぞいてみたわけですよ。そしたらね、いました。いつリリースされたのか分からないくらい古い某CMSが。なんかね、細かいことはね、書けないんだけどね。もう、それ以外にないだろって状況だったんですよね。

で、諸々の経緯をまとめて報告した訳なんですけど、どうもねそのCMS使ってねぇっぽいのね。お試しで入れてみました的なアレだったみたいでさ。デフォルトのままでさ。何もかも。脆弱性つれまくりだよねそりゃぁ……って話でね。

結局のところ、気づかない範囲で何やられてるか分からないってこともあって、

  • サーバの再構築を推奨
  • 使ってない某CMSは即時削除すること
  • コンテンツは確実に安全であると信頼できるものをベースに再設置すること
  • セキュリティアップデートは可能な限り速やかに適用すること

的なご提案をしたところでボクのお仕事終了という感じになりました。その後どうしたかは表向き知らないことになってますが、とりあえずご迷惑をおかけしない形に落ち着いたんじゃないかなって妖精さんがボクに囁いてます。

教訓:あたりまえのことをあたりまえにやろう


まあ、これがボクのインシデント対応初体験の記録ですよ。これが最善手だとは全然思わないし、今思うといろいろアレな部分も結構あるのは事実。でも、がんばった方だと思うのですよ。あの当時のボクにしてはね。

このインシデント対応からスゴイ月日が経過してから、このパターンと類似の事象(*7)に悩んだり、某DDoSアタックの影響をもろに受けたり、いろいろトラブル対応をしてきたボクですが、このときの経験はある程度活きてますね。たぶん。

みんなが口酸っぱくして言ってるけど、「あたりまえのことをあたりまえにやる」ってすごく大事だよね。例えばCMSとか使ってるなら最新版を使うようにしようとか、パッチはちゃんとあてようとか、何かあったときに「何が起こっているのか」ある程度把握できるよう準備しておこうとか。

マジ、基本をおろそかにするヤツは何やってもダメ。コの業界の人は肝に銘じましょう(*8)。


*1:よっぽど大規模にやらかしていた場合は別として
*2:とある専用サーバサービスを利用していたのでリブートとかもリモートからできたりするのです
*3:例えばchrootkitとかrkhunterとか入れたり、twipwire入れたり、sarコマンド使えるようにしたり、Apacheの設定を変更したり的な対応ね
*4:まあしばらく警戒レベルを上げていたのでチェックとかしてたんだけど特に異常は見当たらなかったのですよ
*5:もちろん業者さんの緊急対応窓口に電話しましたよ
*6:ここで消していたらまたダウンロードされて終わりかなと思ってね(Script Kiddy程度ならこの程度で詰むはずなので)
*7:外から見たときの事象は類似はしてるけど、セキュリティインシデントとか無関係なもっと平和的なオチだった
*8:現実問題として、この単純なことをやるのがどれほど大変なのかはよく存じているつもりです(大変じゃない世界に生きてる人はその幸せを大切にしましょう)

0 件のコメント:

コメントを投稿