攻撃者側から見た侵入前の事前調査（下見）：不正侵入の手口と対策（1）（1/2 ページ）
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
サーバへの不正侵入、Webページの改ざん、さらには機密情報の漏えいなど、ここ数年、インターネット上で発生するセキュリティ侵害事件が後を絶たない。そのため最近では、企業や組織の多くは、そういったセキュリティ侵害を意識してからか、ファイアウォールやIDSなどを設置し、自サイトのセキュリティ強化に取り組んでいる。
しかし、そういった対処を行っているにもかかわらず、セキュリティ侵害事件が後を絶たないのはなぜだろうか？ それは、最も根本的な問題である、実際に守るべき資産（情報）が格納されている、サーバ自身のセキュリティが確保されていないからだ、と筆者は考える。
本稿では、数回にわたり実際の攻撃者が行うであろう一連の手法と、それらの攻撃を防ぐためのサーバにおける対策方法について解説する。環境はUNIXをベースとするが、Windowsについても適時紹介する予定だ。
なお、あらかじめ断っておくが、本連載は攻撃者を育成するためのものではない。サーバ管理者に攻撃者の手口（心理）を知ってもらうことで、より効果的なサーバの運用管理に役立ててもらうことを目的としている。
他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。
本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。
また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。
第1回の本稿では攻撃者側から見た「事前調査」を解説する。なお、本稿において想定する攻撃側と守備側のネットワーク構成は以下のとおりとなる。
想定する攻撃側と守備側のネットワーク構成イメージ本稿内の実行コマンドの先頭の「%」は一般ユーザー権限、「#」は管理者権限（root）によるコマンドの実行を意味する。
事前調査（Probe）
攻撃者が対象サーバに侵入を試みる際に、最初に何を行うだろうか？ ほとんどの場合は、いきなり侵入を試みるためのexploitプログラムを実行すのではなく、まずはそのサーバにどういった脆弱性が含まれるかどうかの事前調査から行うだろう。攻撃者が行う事前調査は、一般的に以下のような流れで行うと思われる。
- 対象サーバを絞り込む
- ポートスキャンを行う
- バナーチェックを行う
- そのほかの情報収集
対象サーバを絞り込む
例えば、攻撃対象となるサイトのドメイン名がexample.co.jp だったとしよう。そのドメイン名から攻撃対象となるサーバのIPアドレスを得るためには、DNS情報を入手するのが手っ取り早い。
DNS情報を調べるには、dig、host、nslookupといったUNIXなどでも一般的に使われているコマンドを利用する。ここではdigコマンドを用いた例を紹介する。
1.すべてのDNSレコードを問い合わせる
最初に、digコマンドを使用して、example.co.jpドメインに関する A、MX、NS、PTRなどの複数のレコードを問い合わせてみた。
- 実行コマンドの書式
% dig ドメイン名 any |
- コマンドの実行例と結果
% dig example.co.jp any;
<<>> DiG 8.3 <<>> example.co.jp any ;;
ANSWER SECTION: |
出力結果の「ANSWER SECTION」および「ADDITIONAL SECTION」に注目すると、以下のことが分かる。
- example.co.jpドメインのネームサーバ（NSレコード）
- ns.example.co.jp（192.168.0.10）
- ns1.example.net - eexample.co.jpドメインあてメールの配送先（MXレコード）
- ns.example.co.jp（192.168.0.10）
攻撃対象となるサーバはns.example.co.jp（192.168.0.10）で、このサーバではメール配送（25/tcp）とDNS（53/tcp、53/udp）のサービスが提供されているものと推測できる。
なお、ns1.example.netについては、別サイト（おそらくはこのサイトが属するISP）であることから、ここでは攻撃対象外とした。
2.ゾーン情報の取得
ネームサーバがexample.co.jpであることが分かったので、続いてそのサーバに対して、example.co.jpドメインのDNSゾーンを入手できるかどうかを試みた。ゾーンには、そのドメイン空間に属するサーバのホスト名やIPアドレスなどの情報が含まれているため、取得できれば攻撃者にとって有用な情報となり得る。
ここでも同じくdigコマンドを使用した。ゾーンを取得する場合は、問い合わせタイプにaxfrを指定すればよい。
- 実行コマンドの書式
% dig @対象ネームサーバ ドメイン名 axfr |
- コマンドの実行例と結果
% dig @192.168.0.10 example.co.jp axfr
|
先に得た情報と違う点としてはwww.example.co.jpが挙げられるが、これはns.example.co.jp（192.168.0.10）の別名（CNAMEレコード）というだけで、同一サーバのようだ。wwwという名前から推測すると、Web（HTTP）サーバだろう。80/tcpおよび443/tcpポートが待機している可能性がある。
以上の結果を踏まえ、現時点で推測される攻撃対象サーバの構成は以下のとおりとなる。
- 攻撃対象サーバの構成（1）
- IPアドレス：192.168.0.10（ns.example.co.jp）
- 推測OS：不明
- サービス構成：
| 待機ポート | サービス名 | 使用ソフトウェア | |
|---|---|---|---|
| 25/tcp | smtp | 不明 | |
| 53/tcp | domain | 不明 | |
| 53/udp | domain | 不明 | |
| 80/tcp | http | 不明 | |
| 443/tcp | https | 不明 | |
ポートスキャンを行う
攻撃対象の各サーバのIPアドレスを得たならば、次に行うのがポートスキャンと呼ばれる行為だ。ポートスキャンは、主に対象ホスト上で待機（listen）しているポート番号の洗い出しのために実施される。これは、対象ホストを家に例えるなら、ポートはさしずめ玄関や窓といった出入口に相当する。つまりポートスキャンの行為そのものは、泥棒がその家への侵入を試みる際に、玄関や窓がどこにあるのかを調べるのと同じだと考えてよい。
手間をかけずにポートスキャンを行いたい場合、たいていはNmapなどのツールを使うだろう。しかし、実際の攻撃者、特に用心深い攻撃者ほどその手のツールはあまり使わないのではないかと思う。なぜならば、そういったツールによるポートスキャンは、標的サイトの管理者が気付く可能性が高くなるからだ。それは、攻撃対象サイト側で以下の設定を行っていた場合に顕著となる。
1.ファイアウォールなどによるフィルタリングを行っていた場合
ファイアウォールで通過を許可していないポートに対して一度に大量のアクセスが行われた場合、アクセス拒否した記録としてログ（ログビューア）に明示的に残るため、管理者が認識し警戒する。
条件：管理者がしっかりとログをチェックしている必要がある
2.IDSを設置していた場合
Nmapなどのよく知られたツールによるポートスキャンは、最近のIDSは検知する。例えばIDSのSnort1.8.7の場合、以下のNmapのポートキャンを検知できる。
- ICMP PING NMAP（-sPオプション）
- SCAN nmap XMAS（-sXオプション）
- SCAN nmap TCP（-sTオプション）
- SCAN nmap fingerprint attempt（-Oオプション）
条件：管理者がしっかりと検出されたアラートをチェックしている必要がある
コラム 〜 Nmapによるポートスキャンの特徴 〜
Nmapによるポートスキャンにはいくつかの特徴がある。例えばTCPconnect（） スキャン（-sT）は、コネクションの終了をFINではなくRSTで行う。また、UDPスキャンも0byteのパケットを送るという特徴を持つ。これらは、ネットワークトラフィックの抑制やポートスキャン自体の高速化を実現するために用いられているようだ。
ポートスキャンを手軽に実現する方法（telnetを使う）
Nmapなどのツールを使用せずにポートスキャンを手軽に実現できる方法として、telnetコマンドを使う手法が挙げられる。telnetは皆さんご存じのとおり、通常は対象サーバへのリモートログインに用いられるが、それは単にtelnetがデフォルトでアクセスするポート（23/tcp）というだけで、実際にはtelnetを用いて任意のTCPポートにアクセスすることが可能だ。
ここでは、telnetを使用して、よく脆弱性が指摘されているサービスが使用するポート（*1）に対してアクセスを試み、待機状態にある各ポートの洗い出しを行った。
- 実行コマンドの書式
% telnet 対象サーバ TCPポート番号 |
- コマンドの実行例と結果
% telnet 192.168.0.10 53 |
上記は53/tcpポートに対してアクセスを行った結果だ。「Connected to 192.168.0.10.」のメッセージより、TCPポートが待機状態であることが分かる。なお、確立したTCPコネクションを切断したい場合はtelnetのエスケープモード（^]）に移りquitを実行するとよい。
もし、接続を試みたポートが対象サーバ上で待機状態でなかった場合、以下のような「Connection refused」といったメッセージが出力される。
% telnet 192.168.0.10 21 |
また、途中のルータやファイアウォールでフィルタリングされているポートにアクセスした場合は、「Trying 接続先…」のまま何の応答もなく、タイムアウトするまではコマンドプロンプトも返ってこない。その場合は Ctrl＋c（Ctrlキーを押しながらcを押す）で強制終了するとよい。
以上の手順で、「よく脆弱性が指摘されているサービスが使用するポート」を探した結果、先に想定したポート（25/tcp、53/tcp、53/udp、80/tcp、443/tcp）と、新たに
192.168.0.10でリモート管理用の SSH（22/tcp）が待機状態であることが判明した。
- 攻撃対象サーバの構成（2）
- IPアドレス：192.168.0.10（ns.example.co.jp）
- 推測OS：不明
- サービス構成：
| 待機ポート | サービス名 | 使用ソフトウェア | |
|---|---|---|---|
| 22/tcp | ssh | 不明 | |
| 25/tcp | domain | 不明 | |
| 53/tcp | domain | 不明 | |
| 53/udp | domain | 不明 | |
| 80/tcp | http | 不明 | |
| 443/tcp | https | 不明 | |
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。