トラブル☆しゅーたーず #8〜虹色のくじらを探して〜 に参加してきた


久々の外部活動の報告となります!

 

hbstudy、ncstudy、odstudy 様合同主催での開催となる

「トラブル☆しゅーたーず #8〜虹色のくじらを探して〜」

というイベントに参加してきました。

このイベントは、実際にニフティ様のニフティクラウドを使って、

そのクラウド上にあるサーバー/サービスの障害を復旧し、原因を究明、最終的に報告書を作成して、

サービスの所有者でありお客様である「五月女紹介」様に発表するものとなります。

 

私は学生時代から#4、#5、#6と参加してきて、#7だけは参加できなかったのですが

今回で4回目の参加となります。

 

プロローグや簡単なシナリオはこちらを参考にしてみてください!

よく作りこまれています!

イベント概要ページ(Zusaar)

トラブル☆しゅーたーず#8 読本

スクリーンショット 2014-08-10 16.19.41 スクリーンショット 2014-08-10 16.19.47 スクリーンショット 2014-08-10 16.20.20

発生した障害とチームの動きについて

私が振り分けられたのはチーム3でした。普段Twitterでもお世話になっている @riku_chaさんと一緒のチームでした。

お客様側から頂いているの障害の報告

  • WEBサイトの表示がおかしい
  • SV01(メインサーバー)のCPU負荷がとんでもない
  • 某セキュリティ会社より、自社のサーバーから外部に攻撃しているって連絡がきている

チームの動きでは…

  • 自己紹介とスキルセット(=何ができそうか、できるか)の情報共有
  • Chatworkで情報共有?
  • SSHアクセスの許可をお客様に取り、サーバー内に入って現状調査
  • SV01にてフォレンジック班、SV02にてバックアップからのリストア班、ドキュメント作成班として役割分担

大まかに上記の事をやっておりました。

ハマってしまった所

私はSV01にてフォレンジック兼ファシリテーター を努めてました。

とはいっても、tcpdumpでのログ解析が久々すぎて適切なオプションでログの取捨選択ができず、

SV01内で動いているサービスやデーモンについては「どれが正常でどれが異常なのか」が把握できず、苦戦しておりました。

一緒にフォレンジックを行っていたメンバーと、

「どうやらmysqldが原因。でもDockerの中で動いているから操作がわからねえ!しかも存在しない/etc/my.cnfを引数にして起動しているぞ!」

という所へ辿り着き、
あのネットワーク構成じゃクラウドの機能でRDB用意してるからこのサーバーでmysql動かしてるのおかしくないか?

という考えが生まれました。

(結局、このmysqldは「mysq1d」という偽装用のニセプログラムだったんですけどね)

dockerのコマンドにて

sudo docker stop "containerID"

にてコンテナごとプログラムを終了させることで、CPUの負荷高騰は収まりました。

ただし、これは一時対策にしかすぎず、真の原因がわからなかったため、”穴を塞げたか”というとそういうわけではなかったです。

 

最終的に「サイトの表示そのもの」は復旧。

SV02対応班がバックアップからのリストアを実施してくれたおかげで、サイトは復旧しました!

しかし、上記の通りセキュリティ対策が不十分なままであったり、外部サイトに攻撃を仕掛けているままであったり、

完全な復旧はできませんでした。

 

そして障害対応報告

全チーム、謝罪から始まる障害対応報告。 毎度の事ながらリアルすぎて重苦しい空気でした。

報告書提出締め切り10分前に、全く目を通していない発表用資料を@riku_chaさんの「報告者やってくれ」とのムチャぶりに応えて

私もチーム3として謝罪会見してきました。

チーム3発表資料

10469040_805399072846277_3890069742818601788_n

 

様々なチームの発表を拝見していましたが、「慣れている」方が多いですね。非常に。

 

その後は解答編にて優勝チーム発表となるのですが、

今回は優勝チームは「なし」でした。 非常にガチな体制ですね…。

 

解答編と、その後の懇親会で運営に聞いてわかったネタ明かし

  • SV01のDockerコンテナ内で[skipfish]が動いており、それを元に脆弱性を診断していた
  • モナーコインを掘っていた
  • shocker.cというExploitプログラムが動いていた

(ただしこれは現在動いているバージョンでは動作せず、参加者を惑わす罠だったらしい)

  • 手順書の「docker pull」が実施できない原因は名前解決が正しく機能していない為であり、

対象をローカルとして認識しているため、docker pullにてエラーが走った

私の頭で理解できたのはこれぐらいでしょうか。 mysq1dを偽造として動かしていたのは、オプションでバレバレなため、my.cnfを指定して無理やり動かして偽装していたなんて話も飲み会でありました。あまりこの辺は覚えていませんでしたが…。

改めて思った大切なこと、反省とか

お客様が求めているものを汲み取る

2つの障害が起きている中で、どちらを優先すべきか エンジニア目線とお客様目線では全く異なりますね。

我々エンジニア肌としては「攻撃をしているのなら、原因はなぜか?そうじゃないと止められない」という対応をしがちでした。本当は「原因とか後からでいいからまず止めてくれ、SV01についてはパージを決定しているんだから」という要望を汲み取ることができていればもう少し違う提案ができてのかもしれません。

フォレンジックだけに夢中になりきっているチームも多かったようです。

少しでも気になるものがあればググってみる

フォレンジック班としてあげていた「何が正常で何が異常なのかわからない」につながりますが、

今回、mysq1dが気付けなかったとしても、skipfishやshocker.cなど、簡単に調べられるキーワードはありました。

もう少し気にかけていればヒントになったかもしれないのに という機会損失でした。

難しく考え過ぎない

今回は最新ネタの「Docker」というコンテナ型という考え方を使ったツールにの上になり立つシステムでの障害でした。

NW図の把握が上手く出来ず、難しく考えすぎて変な勘違いを起こしたりもしていました。

実はそこまで深く触る必要もなかったのに、苦戦していました。

あとはコミュニケーション

黙々と作業してるのってやっぱり辛いですよね。運営の方々も、「笑い声が聞こえてくる」ぐらい

意思疎通を図れるチームは好評化みたいです。(馬鹿騒ぎとかではなく)

また、情報共有ツールなどを活用したり、ホワイトボードやスクリーンを使ったり…。

情報の伝達やコミュニケーションの手段、沢山ありますよね。

最後に

約1年ぶりにニフティクラウドを触ってみましたが、新しく追加されている機能が多すぎてびっくりしました。

進化は止まりませんね。素晴らしいです。

また、会場やクラウドそのものを提供して頂いたニフティさんや、運営の方々、いつもながらありがとうございます。

 

#4の頃は全く何も出来ず、#5で自分ができる役割が見え、#6ではちょっとだけ技術的な作業ができて

今回はどっぷりLinuxを操作して復旧や原因の究明に触れることができました。

参加する度に自分の成長が感じられて非常に良かったと思います。

今回の反省点を踏まえて、次回は優勝狙えたら……良いですね。

 

皆さん、おつかれさまでした。

 


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です