兼任サーバー管理者のためのサーバーセキュリティ その2

テーマ:兆候を掴む

前のメモから、このメモのテーマは、管理するサーバーへのアタックの兆候をつかむこと。

自分が管理しているサーバーが、特別に重要な役割を負っているものでない限り、データを盗んだり、踏み台にしようという輩からサーバーを防御することは難しくありません。そのためには何をすればいいのか?ですが、まずは、常識的な防御を行い、アクセスログから兆候を掴むところから始めます。

まず、攻撃者サイドから考える

攻撃者にもレベルがあり、偶然目にした外部コンピュータへの侵入や攻撃方法を試してみたいだけの初心者、何度か他人のコンピュータに実際に侵入している中級者、コンピュータとネットワークを知り尽くしている上級者がいると思います。
レベルに応じて興味の対象は異なると考えますが、そもそも、他人のマシンを利用して何がしたいの?と考えると、

  1. 興味本位
  2. 本来は外部に公開していないデータを読み取る
  3. 迷惑行為をして喜ぶ(サービスを落としたり、コンピューターをリブートしたり、データ消去したり)
  4. データ改ざん
  5. 踏み台(正式サービスを踏み台)にして自分のホスト情報を隠す Proxy にする
  6. 踏み台(バックドアを仕掛ける)にして、他のホストに侵入する
  7. 盗聴用に使う(コンピュータ設置場所ネットワークの情報を見る)
  8. リモートコントロール(ボット化)する

こんなところでしょう。
ホームページデータの改ざん(4) や 迷惑行為(3) を行うと侵入がばれてしまい、以後セキュリティ対策されてアクセスできなくなる可能性大です。でも初心者はやってみたい。
いつでも、外からアクセスできるようにしたり、情報を集めて定期的に anonymous サーバーにアップロードするようにセットして、アクセスしている形跡を残さないようにしておくのが、踏み台としての侵入には都合がいいはず。だからサーバーは見かけ上正常に動いている状態を続けます。

いずれにせよ、まずは目的を持ってサーバーホストに侵入しないと目的に近づけません。

コンピューターに侵入するには、

  • 正面玄関から入る
  • サービスの脆弱性を利用して、無理矢理裏口を作って入る
  • ユーザーに別の玄関を作ってもらって、そこから入る
  • 正式OSやアプリケーションにあらかじめ組み込まれているバックドアから入る

のいずれかになります。

これらの可能性を考えると次のようになります。

正面玄関

わざわざ、入れないところから入るより、リモートメンテナンス用に開かれている telnet や ssh ポートがあるなら、そこから入る方が楽です。
パスワードを付けていないユーザーアカウント、よくある文字列のパスワードを使用しているアカウント、サービスを動かすために必要なアカウント;例えば mysql ;がデフォルトパスワードのままになっていたりすると狙われます。

脆弱性を突いて裏口を作る

詳しいことは省略しますが、脆弱性があるサービスプログラムが高い権限で動いていると、外部からバッファー・オーバーフローを起こすコードを送り込むことにより、プログラムを乗っ取られることがあります。乗っ取られたプログラムは元の権限所有者として動くので、管理者権限で動いているプログラムが乗っ取られると、そのコンピューターに対して何でも出来ることになります。これが裏口となります。

別の玄関

無料ソフトをダウンロードしてインストールしたら、目的の機能以外にバックドアが仕掛けられているというものです。
Windows用有料ゲームソフトが無料で遊べると何処かの掲示板に書いてあって、URLをクリックしてダウンロードしたらゲームとウィルスに感染するという話は今でもよく耳にします。

Unixサーバーでは可能性は低いと思います。

正式OSに初めからバックドアが仕掛けてある

Windows, MacOS, iOS, Unix系 OSでは起きないはずですが、Android には最初からルートキットやバックドアが仕掛けられているという噂をしばしば耳にします。実際のところOSなのかアプリケーションなのかはよく分かりませんが、Android系モバイル端末を購入して、ネットワークに接続して置いておくだけで、中国に割り当てられているネットワークにHTTP POSTアクセスが発生しているという動作を実際に目にします。

サーバー管理者としては、正面玄関と脆弱性だけ注意していれば、まあ大丈夫と言えます。

では、どう注意していればいいのか?

侵入者は魔法使いではなく、物理法則に従って生きている生身の人間ですから、何も情報がないところから、侵入できるホストを見つけることは出来ません。IPv4アドレスだけで約40億個あるわけですから、侵入するホストをどうやって探しているかと考えると、

  • 自分で、IP・ポートスキャンして見つける
  • 検索エンジンを使う
  • 仲間の情報網に紹介してもらう

くらいしか手がありません。

自分でIP・ポートスキャンをする

どんな侵入手段を持っているかにもよりますが、正面玄関を狙う場合、「例えば、F社のルーターは、デフォルトパスワードが admin:admin になっていて、初期値を使っているユーザーが多い。」とか「CMSを使っていて、M社のDBが一緒に動いている場合は、db123:admin というアカウントが初期値である。」というような情報を知っているとします。

そうなれば、全部のIPアドレスに対して、片っ端から telnet , ssh, ftp, pop3, poppassd などアカウント認証が通るかどうかを試して行けば1台くらいはデフォルトパスワードで使っているものがあるかもしれません。
効率を考えると、まずは認証ポートが空いているホストIPをリストアップし、その後でポートに対して存在する可能性があるアカウント情報を入力して行くことになるでしょうね。
攻撃者自身の安全性を考えると、自国に割り当てられているIPアドレスではなく、距離的に離れている他国、国交が無かったり双方の国民感情が悪い国のIPアドレスを狙う方が、万が一の場合自分への追跡を行いにくくできると考えるでしょう。

手持ちの侵入手段が、OS、サービス、バージョンを限定するなら(脆弱性を狙う場合は普通は限定されます)、OSごとのパケットの特徴を比較したりして、ターゲットにもダミーパケットを送りOSのバージョンを推測したりする必要があります。

検索エンジンを使う

侵入成功まで行かなくても、掲示板をコメントスパムで埋め尽くし、掲示板運用者や利用者が迷惑を被る話は昔からよくあります。ロボットプログラムで、スパムコメントを投稿するわけです。
例えば、掲示板プログラムのCGIをデフォルトファイル名で使っている場合は、検索エンジンでCGIプログラム名を検索すると、検索エンジンがホスト名とURLを教えてくれますので、検索結果からホストの一覧表を作ることが出来ます。最近では投稿・画像認証を用いる掲示板が増えて、ロボット投稿は出来なくなっていますが、ターゲットのCGIやCMSを見つけるために、検索エンジンは犯罪者の役にも立ちます。

情報網がある

チームで作業したり、情報交換網がある場合は、簡単に破れそうなホストを見つけて侵入してしまうかも知れませんね。これはやっかい。

長くなりましたが、IP・ポートスキャンや検索エンジンを使って、ターゲットとするホストを一覧にすることが出来ます。
この後で、実際の侵入行為に移るわけです。

全部仮定の話ですが、侵入者の攻撃パターンを推測することこのような感じでしょう。

サーバー運用者側の対策

さて、サーバー管理・運用者の方ですが、最近のサーバー構築後の常識的な設定を行っておきます。
Web, Mail とリモートメンテナンスを使うとして、以下。

  • ファイヤーウォールを使う
    • 使わないポートをファイヤーウォールで塞ぐ(ブロックするパケットは拒否ではなく、破棄する)
    • 利用するポートも可能であれば接続対象者のIPアドレスに対してのみ開ける
    • ステートフルインスペクションを使う
    • 通信を受け付けるポートだけ syn パケットを受け付ける
    • established  ステートしたTCPパケットだけ通過させる
  • アクセスコントロール
    • ファイヤーウォールを通過するパケットを認証前に、IPアドレス、ドメインレベルでアクセスコントロールする。アカウントがあろうが無かろうが、アクセス許可リストにないIPアドレスからの接続を拒否する。
      これで、正面玄関から入ってくる侵入者を閉め出します。
    • アカウントに100%パスワードを付ける。
    • 直接 root でログインさせない。root にスイッチできるユーザーを制限し、コントロールする。
    • 単位時間に接続できるコネクション数を制限する。1分間に1つのIPアドレスから接続できるコネクションを3本以下にする。(3回間違えると1分間ロックアウトされる。)一つのサービスに対して同時に接続できるコネクション数をサーバー用途に応じて絞る。
  • サービス専用アカウントを使う
    • httpd の用にWebサービスに対して接続してくる不特定のコネクションは拒否できません。万が一httpd に脆弱性があると乗っ取られる可能性があります。httpd は www や nobody というシェルレベルでは殆どどこにもアクセスできない権限のアカウントで動かしておくことにより、仮にプロセスを乗っ取られたとしても、アクセスできるのは公開されているWebページの読み出しだけという状態にします。
    • sendmail も同様で、仮に脆弱性を突かれたとしてもOSに被害が出ない低い権限でホームディレクトリも持たないユーザーで動かしておきます。
  • ロギング
    • TCPに関して、外部からの全 SYN パケットを記録する
    • UDPに関して、全パケットを記録する
    • ICMPに関して、全パケットを記録する
    • 全サービスの認証の試行をすべて記録する
    • Apache の場合、HTTP/HTTPS ログを common ではなく combined 形式で記録する
    • ログは最低1年間保管できるようにローテーションする

以上のポリシーで設定を行っておくと、グローバルIPを持つサーバーに対して、侵入のためのポートスキャンが行われると、ファイヤーウォールログと、認証ログに記録が残ります。何かが起きても、原因を探るための情報となります。
基本ルールさえ守っていれば、一発で侵入を通してしまうことはありません。必ず何処かに記録が残ります。

OSが FreeBSD の場合は、

  • root 宛に、毎日自動で daily security run out レポートが送られてきますので、典型的な怪しいアクセスはつかめます。不正ログイン試行、メール中継、ファイルが変化したシステムファイルの所在、など。これはちゃんと目を通さないといけません。
  • デイリーレポートで HTTP log は検査されないので、http-access.log http-error.log を流して見ることが重要です。おかしなアクセスは、高速スクロールしていてもパターンの変化でおかしいと気づけるようになります。また、簡単なフィルタープログラムを書くことで傾向を掴むことが出来ます。
  • できればファイヤーウォールログも、流してチェックしパターン変化に気づけば、何か起きていることに気づけます。

次の課題は、これらのログに不正の兆候が顕著に表れた場合にどうするか?ということです。

問題なのは、

隣にあるホストのセキュリティレベルが弱くて、(ネットワーク的な)隣から侵入されてしまった場合。もし、隣のコンピュータと、自分が管理しているサーバーに同じ人間のアカウントがあると、正式にログインできてしまう可能性があります。隣のコンピューターのセキュリティーに問題が無くても、隣の隣、隣の隣の隣と遡ってゆくと、誰かのアカウント情報が乗っ取られた場合が直近の危険と言えます。(だから、ネットワーク管理者は、ホスト毎にパスワードを変えろと言います。しかし、そんなことやってられないと思うし、口では違うパスワードを使っていると言っていても実際には同じパスワードを使い回している人は多い。)
そのユーザーに、管理者にスイッチする権限が与えられていなければ、即致命傷になることはありませんが、随時ログインアカウントチェックを行い、ログインした時刻やソースホストIPが正当かどうかをチェックする必要があります。
ですから、last コマンドや、auth.log を目視して、日々のログインユーザー情報チェックをすることを怠ることはできません。

私がメンテナンスしているサーバーの重要性やログから考えると、これくらいで、サーバーへの攻撃状況を把握することが出来ると考えています。

コメントを残す