恥ずかしながら、仕事先のサーバーをクラッカーに壊されてしまった。
言い訳がましいが、僕はプログラマーでサーバー管理は別の人の仕事となっていた。
で、「ファイアーウォール設定はちゃんとやってある」の言葉に安心していたのだが、設定が悪かったようだ。
…というか、設定を検証したところ、ミスがあってファイアーウォールがまったく役立っていなかった。
サーバーでは、負荷とリスク（故障での停止など）の分散を狙って、Linux クラスタを組んである。
クラスタとは複数台のコンピューターをまとめて１台に見えるようにする技術で、仕事を手分けできるので処理が軽くなる。
また、どれかが故障で停止した場合、自動的にそのコンピューターは「使わない」設定に切り替わるため、故障の心配も少なくなる。
クラスタで一番重要なのが「ロードバランサ−」と呼ばれるサーバーで、これ自体複数台用意される。
ロードバランサ−は、アクセスを受け取り、その配置下にあるコンピューターに振り分ける。
同時に、不正なアクセスに対してはアクセスを拒否するファイアーウォールの役目も担うことになる。
このファイアーウォールの設定がうまくいっていなかったのが被害の原因だった。
ログの解析によれば、クラッカーは６日にロードバランサ−のうち１台に入り込んでいる。外国のIPアドレスだが、プロクシかも知れないので外国人とも言い切れない。
気付いたのは、ゴールデンウィーク明けの７日。
なぜかサーバー上で作業をしようとすると、コアを吐きまくる。（Macで言えば爆弾が出る、Winでいえば不正な処理となる、という状態）
ロードバランサ−は２台あるので、ネットワークから外しても問題ない。調子が悪いので外してしまう。
翌８日、サーバー管理者が詳しく調べたところ、クラッカー進入の形跡を発見。
知らないユーザーが勝手に追加されており、あろうことか管理者権限を与えられていた。
どうやら、この「不正なユーザー」が、なにか新しいプログラムを入れようとしたらしい。
しかし、共有ライブラリのバージョンが違ったためにうまく動かず、その「新しいプログラム」のほうを修正するのではなく、共有ライブラリを別のものに入れ替えるという暴挙に出ている。
結果、その共有ライブラリを使っているプログラム（＝ほとんどすべてのプログラム）が動かなくなってしまったのだった。
この「新しいプログラム」だが、サーバー起動時に自動的に動くようになっていた。
しかも、起動させるスクリプトを書き間違えている (^^;
なんのプログラムかはわからなかったし、怖いので実行もさせなかったが、名前からすると SSH （セキュリティシェル：セキュリティを高めるためのプログラムの一つ）に、裏口をつくりだす役割があるようだった。
クラッカーがどうやって入り込んだかわからないが、なんらかのセキュリティホールを利用したのだろう。
そこで、サーバー管理者は現在動いている方のロードバランサ−にもセキュリティホールが在るだろうと考え、プログラムのアップデートを行った。
…その結果、ロードバランサ−は起動しなくなった (^^;
２台のうち片方はネットワークから外され、もう一台は起動しなくなった。つまり、サービスが停止したことを意味している。
普段僕は自宅で仕事をしているのだが、この事態に管理者から電話がかかり、夕方に緊急出動。
駆けつけるまでに、コンテンツサーバーのうち１台を直接ネットワークに接続し、サービスは復帰していた。
しかし、負荷分散も無い状態で一番お客さんの多い夜中が訪れれば、処理速度に問題が出ることが予想された。あまり時間は無い。
クラックされたロードバランサ−は、再インストール中だった。
僕はアップデートに失敗したロードバランサ−のハードディスクを外し、別のマシンに接続する。
そして、アップデートしたプログラムをすべて、古いバージョン（そのときハードディスクを接続したマシンは、元々ロードバランサ−が使っていたのと同じバージョンの Linux を入れてあった）に戻す。
「戻す」と簡単に言っても、実際には戻さないといけないファイルは千件を越え、いろいろな場所に散らばっている。
こういうときに役立つのが perl だ。パッケージ管理プログラムから「インストールしたファイル一覧」を受け取り、すべてのファイルを古いバージョンに戻すためのプログラムを作る。作成所要時間2分、わずか10行程度の小さなプログラムだ。
これで起動が可能になった。
ついで、注意深くプログラムをアップデートする。起動しただけでは「元の弱い状態」に戻っただけでダメなのだ。
これで既知のセキュリティホールは全部ふさがっただろう。しかしまだ問題がある。
ロードバランサ−は、現在の RedHat Linux ではサポートされていないのだ。
そのため、最新版のプログラムでもちゃんと動いてくれるのか確認する必要がある。
この確認は結構時間がかかった。
インターネットと同等のネットワークを用意して、その上で検証しないといけないのだ。
現在停止中のコンテンツサーバーと、バージョンアップされたロードバランサ−、それに適当なルーターと「外部」を装ったWindowsマシンを準備。ロードバランサ−が正しく動作して、コンテンツサーバーからデータが外部まで流れることを確認する。
さて、ここからが山場だ。ファイアーウォールの設定をやり直さないといけない。
インターネットでは、コンピューターの接続は65536個ある「ポート」を使って行われる。
ファイアーウォールは、この入り口を守る門番のようなものだ。
まず、すべてのポートを「誰も入れない」状態にする。
ついで、「内部のコンピューターからはすべて入れてもいい」という指示を出す。これがないとメンテナンスも出来ないからだ。
さらに、「外部から WEB と MAIL と DNS は入れてもいい」と指示する。これが無いと、お客さんがコンテンツにアクセスできない。
ほかにもいろいろと細かな設定があるのだが、これに非常に時間がかかった。
設定している間に、一番お客さんが来る時間である、「深夜12時」が来てしまう。
この時間帯には、１秒に 10件以上のアクセスがある。正しくロードバランサ−が動いていればなんて事の無い数なのだが、コンテンツサーバー１台で処理している場合にはちょっと困る量だ。
案の定、サーバーが処理しきれずに停止する (^^; 停止したら処理を「リセット」すればいいだけなのだが、こちらにも気を使いながらのサーバー設定作業となる。
深夜２時ごろ、ロードバランサーの設定にOKを出し、ネットワークに接続する。
同時に、いままで動いていたコンテンツサーバーを外す。こいつは設定を変えて動かしていたので、また設定を戻さないといけない。
外したコンテンツサーバーを使い、再インストールしたロードバランサーが正常に動作することを確認しないといけない。
…これが、やはりすぐには動作しない。なにかしら設定忘れがあったりして、その箇所を見つけるだけでも時間がかかる。
一通り設定が終わったのが午前４時。
さて、これで終わりか…と思ったら、まだあった。
ファイアーウォールの設定がまだうまくないらしい。
外からの攻撃に強くすることだけを考えていたため、そちらは万全なのだが中から外にアクセスするとうまく行かない。
これではなにかと作業に支障がある。
何が悪いのか調べ、一通り設定が終わる頃には朝７時となっていた。久しぶりの徹夜。
すでに１日たって（もちろんぐっすり寝ました）、これもいい経験だと思うので日記に記しておく。
本当は恥ずかしい話なんだけどね (^^;
自宅サーバーを導入しようと思っていた矢先の出来事だったので、いい勉強になりました。
自宅サーバーでは、ファイアーウォールをきっちりと設定することにしよう。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |