Remote OS detection via TCP/IP Stack FingerPrinting
by Fyodor <fyodor@dhp.com> (insecure.org)
この文書は、自由に配布して構いません。最新版は常に以下のサイトから入手
可能です。
http://nmap.org/nmap-fingerprinting-article.html
訳注) フィンガープリントとは、その名の通り「指紋」のことですが、この文
書では敢えてフィンガープリントと訳しています。
これは各 OS ベンダのRFCの解釈に違いがあり、それを反映してTCP/IPの実装
がそれぞれ異なる特徴があります。原著者はそれを指してフィンガープリント
(finger print)と呼んでいます。
概要
この文書では、ホストのTCP/IPスタックに問い合わせを行うことによって、貴
重な情報を収集する方法について議論します。まず、スタックフィンガープリ
ンティングとは別の、「古典的」なホストの判別方法について説明します。そ
して、フィンガープリントを行うツールの中で、いくつかの最新の「技術水準」
に到達していると言えるものについて解説します。次に、リモートホストから
情報を入手する技法を説明し、最後にこれらの技法を実装した、拙作の nmap
について、人気のある多くのインターネットサイトで利用している OS の種類
を nmap が判定する様子を写し出したスナップショットを示しながら詳しく紹
介します。
理由
システム上の OS の種類を判定する理由は明らかなので、ここでは簡単にしか
説明しません。代表的な理由には、大体において、セキュリティホールの有無
は、OS のバージョンに依存するという点です。例えば、侵入検査中に、53 番
ポートが開いていることが分かったとします。そのポートでサービスを提供し
ている Bind のバージョンが旧く、脆弱なものであれば攻撃すると、最初の一
回でデーモンがクラッシュしてしまい、ほかの攻撃を試す前に終了してしまい
ます。TCP/IPスタック実装の実態から調査を行う賢いフィンガープリントツー
ルを使えば、ターゲットのマシンに 'Solaris 2.51'なのか 'Linux 2.0.35'が
稼動しているのかが即座に分かり、この情報に合うようにシェルコードをプロ
グラムできます。
スキャンの中でも最悪な行為は、500,000 台ものホストに対して事前にスキ
ャンを走らせ、OS の種類と開いているポートを調べておくことです。
そしてほかの誰かが、例えば、Sun の comsat デーモンに存在する root権限を
奪取する攻撃手法を公開したとします。技量に乏しいクラッカーは、'UDP/512'
や'Solaris 2.6' というキーワードで、スキャンから得たリストから検索を行
い root 権限を奪取できるマシンを山のように見つけます。お気づきの通り、
これは「スクリプトキディ(SCRIPT KIDDIES)」の行動にすぎません。
スキルがあることを見せるわけでもなく、脆弱性に対して即時に対策を適用し
ていない脆弱な教育機関のサイトを見つけたからといって、誰も感銘を受けま
せん。また新しく発見された侵入手口を使って政府の web サイトを改竄し、
いかに自分は優秀で、そのサイトのシステム管理者がトンマであるかと、自己
顕示しても誰も見向きもしません。
ほかの情報取得の手口として、ソーシャルエンジニアリングという手がありま
す。例えば、標的とする企業にスキャンを走らせ、nmap からは、'Datavoice
TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06' という結果が出力されたとします。
クラッカーは、'Datavoice support' としてその企業に電話をかけ、PRISM 3000
のセキュリティ上の問題があることを連絡します。「セキュリティホール情報
を早々に発表しますが、その前に全ての顧客はこのパッチをインストールして
ください。このメールをお客様にお送りしたのは・・・」だまされやすいシス
テム管理者は、CSU/DSU について詳しく知っているのは、Datavoice の正式社
員である技術者しかいないと思い込んでしまいます。
さらに、ビジネスの相手として目論んでいる企業の評価にもスキャンを利用す
る方法が考えられます。新規にISP(インターネットサービスプロバイダ)を
選ぶときは、スキャンをかけ、どのような機器を利用しているのかを調べてみ
てください。「年間費99ドル」という契約は、安いルータや Windows のマシ
ンの多くから PPP サービスが稼動しているということを知った瞬間にそれ程
割のいいものではないと感じるでしょう。
古典的テクニック
スタックフィンガープリンティングは、特殊な方法で OS の識別の課題を解決
することで行われています。この技術はもっとも信用されていると作者は考え
ています。しかし、他の多くの解決策も利用でき得ます。悲しいことですが、
以下は多種ある技法の中の最も効果的な技法です。
playground~> telnet hpux.u-aizu.ac.jp
Trying 163.143.103.12 ...
Connected to hpux.u-aizu.ac.jp.
Escape character is '^]'.
HP-UX hpux B.10.01 A 9000/715 (ttyp2)
login:
マシンが、稼動しているシステムの種類を世間に対して露骨に応えるのであれ
ばフィンガープリントを採取する手間を取る必要は全くありません。遺憾なこ
とに、ベンダから今日市場に出荷されているシステムの多くがこうしたバナー
を返します。そして、多くのシステム管理者はそれを無効にしません。OS の
種類を判定する方法 (例えばフィンガープリンティングのような) があるから
バナーを無効にしても意味がないと思われるかもしれませんが、だからといっ
て、誰が接続してくるか分からない相手に対して OS 情報を与える必要はない
でしょう。
このような技法が行われるようになってから、バナーを無効にする傾向が増え
システム情報をあまり提供しないようになったり、また、バナーに偽りの情報
を与えるのも通常のように行われています。それでも、何千ドルを支払って購
入する商用の ISS スキャナが実行することと言えば、OS の種類や OS のバー
ジョンを出力するバナー取りのみです。nmap や queso をダウンロードして、
無駄使いをおやめください。
バナーを無効にした場合でも、多くのアプリケーションは、この種の情報を
聞かれると自動的に返します。例えば、FTP サーバの場合、以下のように表示
します。
payfonez> telnet ftp.netscape.com 21
Trying 207.200.74.26 ...
Connected to ftp.netscape.com.
Escape character is '^]'.
220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready.
SYST
215 UNIX Type: L8 Version: SUNOS
まず、デフォルト設定のままでは、バナーにシステムに関する詳細情報が含
まれます。さらに'SYST' コマンドを与えれば、もっと多くの情報を返して
くれます。
匿名FTPサーバの場合でも、通常、/bin/lsや他のバイナリをダウンロードする
ことができるので、そのバイナリが動くFTPサーバのアーキテクチャ情報が得
られます。その他にも、アプリケーションから情報が漏洩してしまうことは多々
あります。Web サーバを例に取ると、以下のように表示します。
playground> echo 'GET / HTTP/1.0\n' | nc hotbot.com 80 | egrep '^Server:'
Server: Microsoft-IIS/4.0
playground>
どんな OS の種類であるかは、もうお分かりですね。
ほかの古典的なテクニックとしては、DNS 上にあるホストレコード情報(これ
は稀なケースですが)を利用したり、ソーシャルエンジニアリング(social engineering)
などの手口があります。マシンが 161/udp (snmp) でコネクションを待ち受
けている場合CMU(カーネギーメロン大学)の SNMP 管理用ツール群で提供され
ている'snmpwalk'と'public'のコミュニティ名を使って多くの詳細情報が得
られます。
最新のフィンガープリンティングプログラム
TCP/IP 実装を見てフィンガープリンティングを行う OS の種類を判定するプ
ログラムは、nmap が最初というわけではありません。Johan 氏が作成した
IRC のスプーフィングツールはよく使われており、バージョン 3 (またはそれ
以前のバージョン) でも基本的なフィンガープリンティングを行っています。
TCP フラグを検査するだけの簡易的な方法で、「Linux」「4.4BSD」、「Win95」
「未詳(Unknown)」のような OS の種類に分類します。
ほかには、「Confidence Remains High Issue #7」で Shok 氏から今年の1月
に公開された checkos があります。フィンガープリンティングのテクニック
は、SIRC のものと同じです。プログラム自体もほとんど同じものです。
Checkos は、一般公開される以前、一部の間でしか手に入れることのできない
ものだったので、誰が誰から盗み出したのか不思議なくらいです。どちらのツ
ールも一方の相手に敬意を表してないようです。checkos で追加された唯一の
機能が、telnet のバナーチェックで、これに関する利点と問題は前述したと
おりです。(追記: Shok 氏は chekos を公開する予定ではなかったので、プロ
グラムソースの一部の所有権は SIRC にあることを特別に記載しなかったと後
で述べています。)
Su1d も、OS の種類を判定するプログラムを書きました。これは、SS と呼ば
れるプログラムで、バージョン3.11 で12種類の OS を識別します。このプロ
グラムについては、作者が贔屓しています。というのも通信に関連するプログ
ラムは、私の nmap に由来していることを示しているからです。
そして、queso があります。このプログラムは、最も新しく、ほかのプログラ
ムと比べて、大きく進展しています。新しい検査手法を加えただけでなくOS
のフィンガープリントに関連するプログラムを省いた初めてのツールです。ほ
かのスキャナーには、通常以下のようなプログラムが含まれています。
/* from ss */
if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) &&
(flagsthree & TH_ACK))
reportos(argv[2],argv[3],"Livingston Portmaster ComOS");
一方、queso は、上記のようなコード部分を設定ファイルへ移動させ、拡張が
可能になり、判定する OS の種類を増加させるには、フィンガープリントを
処理するファイルに、数行を追加するだけで済むようにしました。
queso は、Apostols.org の中でも優秀な一人である Savage 氏が開発したツ
ールです。
これまで取り上げた全てのプログラムには、フィンガープリントのテストの数
がとても限られているのでOSバージョンの絞り込みの精度が十分ではない、
という問題があります。
「このマシンは、OpenBSD、FreeBSD、NetBSD と推定する」という大雑把な回
答だけでなく、できればリリースバージョンまで明らかにさせたいのです。単
に「Solaris」と回答するだけでなく、「Solaris 2.6」まで知りたいわけです。
そこで作者はより詳細な回答を得るために、多くのフィンガープリンティング
技法を nmap に適用しました。次の章でこれを説明します。
フィンガープリンティングの方法
TCP/IP スタックの実装状態から判断するフィンガープリント手法は数多くあ
ります。基本的には、OS ごとの実装の違いを探り相違点を調べるプログラム
を書いたものになります。このような相違点を調べる方法を十分に組合せるこ
とができれば、OS の種類を細かく調べ上げることができます。例えば、nmap
は、Solaris 2.4 、Solaris 2.5-2.51、Solaris 2.6 を区別することができ
この結果は高く信頼できます。また Linux kernel 2.0.30、2.0.31-34、
2.0.35 をそれぞれ区別します。以下にその方法を説明します。
FIN プローブ -- FIN パケット(あるいは ACK や SYN フラグがたっていない
パケット)を開いているポートに送信し、応答を待ちます。RFC 793 では
応答しない反応が正常な動作ですが、これを解釈し直して、MS Windows、
BSDI、CISCO、HP/UX、MVS、IRIX などで実装されている多くの例が、RESET
を送り返してしまいます。最近のほとんどのツールでは、この相違点を利
用しています。
贋フラグプローブ -- ここで紹介する手法を利用したスキャナは、queso が初
めてでした。この手法では、SYN パケットの TCP ヘッダに未定義の TCP
フラグ(64 または 128)に設定します。バージョン 2.0.35 前の Linux マ
シンでは、このフラグを応答パケットに添付して送信します。Linux 以外
のオペレーティングシステムに同じような欠陥があるかどうか見つけてい
ませんが、ほかのオペレーティングシステムでも SYN パケットに贋フラグ
が立てられて送信されると、接続をリセットするようです。この動作を利
用して、オペレーティングシステムの種類を推測することができます。
TCP ISN(イニシャルシーケンス番号) サンプリング -- TCPのコネクション開
設要求への応答のイニシャルシーケンス番号の割り当て方法を調べて、TCP
の実装によって異なるパターンを見つけだす手法です。このようなパターン
から、様々なグループに分類し、例えば、お決まりの 64K(多くの旧い UNIX)、
乱数を増加させるパターン(最近の Solaris、IRIX、FreeBSD、Digital UNIX、
Cray ほか)乱数のパターン(Linux 2.0.*、OpenVMS、最近の AIX など)の
分類があります。
Windows（その他少数のOSを含む）は、"時間に依存した"モデルを採用して
おり、イニシャルシーケンス番号は、一定の時間間隔毎に固定の微少な値分、
増加されて行きます。当然、このような値は、古いOSの64Kの動作を推測でき
るのと同じように簡単に推測できます。私の好きなパターンは、「一定」数
のもので、常に、同じ番号を割り当てるマシンです。このような一定数を使
用するものには、3Com ハブ(0x803)や Apple LaserWriter プリンタ(0xC7001)
があります。
シーケンス番号や番号間の差の集合上に定義された、分散や最大公約数あ
るいはその他の関数を計算してランダムな増分を行うOSのバージョンもあ
ります。
イニシャルシーケンス番号は、セキュリティにおいて重要な意味があるこ
とにご注意ください。この点における詳細な情報は、SDSC の「セキュリ
ティ専門家」、Tsutomu "Shimmy" Shimomura 氏にお聞きください。彼が
どのようにして侵入されたか尋ねることができます。ここに関連する事件
の中で、Nmap は、OS 判定のために私が知っている中で初めて使用された
ものです。
Don't Fragment bit の監視 -- 多くの OS は、送信されるパケットの IP
ヘッダ中の "Don't Fragment" bit に 1 をセットします。これは性能
向上に役立っています(但しやっかいな面もあり、Solarisはこの操作を
行っているために、フラグメント処理に関するnmapのスキャンが使えま
せん)。
全ての OS が上記に当てはまるわけではなく、いくつかの OS で場合に
よっては当てはまることがありますので、この bit に注意することで、
標的 OS の情報を取得することができます。
私自身、このような場合を見たことはありませんが。
TCP 初期ウィンドウサイズ -- これは、単に返信用のパケットのウィンドウ
サイズをチェックしています。以前のスキャナは、TCPのRSTパケットのウィ
ンドウサイズが0でないなら、"BSD 4.4系"のOSであると単純に判定して
いました。quesoや nmap のような最近のスキャナでは、OS によって大
体においてウィンドウサイズが決まっているので、これを追跡します。
OS によっては、ウィンドウサイズを見るだけで特徴があるので、この検
証で実際、多くの情報を得られます(例えば、AIX は私が調べた中では、
唯一 0x3F25 を使う OS です)。
「完全に変更が加えられた」NT5用 の TCP スタックは、0x402E を使用し
ます。興味深いことに、この値は、OpenBSD と FreeBSD のものと全く同
じです。
ACK 値 -- この値には基準があるように思われがちですが、実装では、ACK 値
が異なる場合があります。例えば、閉じた TCP ポートに FIN|PSH|URG を送
信すると、多くの実装では ACK に接続リクエスト側のイニシャルシーケンス
番号と同じ値を設定します。ただし、Windows や馬鹿なプリンタは、接続リ
クエスト側のイニシャルシーケンス番号に１を加えたものを返します。また
Windows は、開いたポートに SYN|FIN|URG|PSH を送信すると、不定値を返し
ます。送信側のイニシャルシーケンス番号と同じ値を返す時もあれば、１を
加えたものだったり、乱数値であったりします。マイクロソフト製品がこの
ような値を与えるのにどのようなプログラムを書いているのでしょうね。
ICMP エラーメッセージ抑制 -- OS によっては、RFC1812 の推奨に従い、様々
なエラーメッセージが送信する割合を制限する場合があります。例えば、
Linuxカーネル(net/ipv4/icmp.h)は、到達不能メッセージの生成を4秒毎
に80個までに制限しており、それを超過すれば1/4秒のペナルティを付加し
ます。
これを検証する方法は、UDP のハイポートへ適当にいくつものパケットを
送り、受信される到達不能メッセージ数を数えてみてください。
私はこれを見たことがありませんので、これを nmap(UDP ポートスキャン
以外は)の機能に加えていません。この検証方法で OS の種類を判定する
には、いくつものパケットを送信し受信するメッセージを数える処理が
あるので、少々時間がかかります。また、ネットワーク上でパケットが
単にドロップする可能性があるので、面倒くさい時もあるでしょう。
ICMP メッセージ引用 -- RFCでは、エラーを引き起こす原因となったIPメッ
セージ中のある少量の部分をICMPエラーメッセージで引用することを規定
しています。大部分の実装では、ポートへの到達不能メッセージは IP
ヘッダ + 8バイトになっていますが、Solaris の場合はこのサイズより多く、
Linuxではさらに多くを返します。ここでの素晴らしい点は、Linux や
Solaris のホストでポートが開いていない場合でも相手のホストの OS
の種類を推定できることです。
ICMP エラーメッセージ整合性 -- ここでの考え方は、Theo De Raadt 氏
(OpenBSD開発指揮者である)が comp.security.unix に投稿した記事を
参考にしています。前述したように、接続先のホストは接続開始側のメッ
セージに到達不能メッセージエラーを付けて送り返します。但し、いくつ
かのOSでは、元のメッセージヘッダを処理の「作業領域」として使う場合
があるので、受信したICMPメッセージ内で引用されているヘッダの内容は、
元の値とは少し変わっていることがあります。
例えば、AIX や BSDI は、IP の'total length'を返信しますが、これが通
常より20バイト多目になっています。BSDI、FreeBSD、OpenBSD、ULTRIX、
VAXen などは IP の ID に矛盾が生じます。TTL が変更されるため、チェ
ックサムも変更されますが、いくつかのマシン(AIX や FreeBSDなど)では
矛盾した、または、O のチェックサムが返信されます。UDP のチェックサ
ムでも同様です。このように、nmap は ICMP エラーに関して細かな違いを
色々と検証してくれる見事なツールなのです。
サービスの種類(type of service、TOS) -- ICMP ポート到達不能メッセージ
の type of service (TOS) 値に注目します。多くのスタック実装では、
この値を 0 にしていますが、Linux は 0xC0 を使います。この値は標準の
TOS値には存在せず、TOSフィールドの中（私の知る限り)未使用の、前2bit
の領域を使っています。(訳注: RFC791では、8bitのTOSフィールド中、前
2bitが未使用とされています) このように実装した理由は不明ですが、仮に
この値を0に変更した場合でも、少なくとも古いバージョンと新しいバージョン
であるかの判定は可能です。
フラグメンテーション処理 -- この手法は、Secure Networks 社(今では、ネ
ットワークアソシエイツ社の多数の Windowsユーザに所有されていますが)
の Thomas H. Ptacek 氏が得意とするものです。ここでは、IP フラグメン
テーションのオーバーラップする処理の相違点を利用しています。あるOSは
新たに受信したもので以前受信した部分を上書きしますが、別のOSは逆に
以前受信した方を優先します。パケットの再構築の仕方を調べるには様々
な探索方法があります。フラグメント化された IP を送る簡単な方法を知ら
ないので(特に、Solaris においては頭を悩ませるところです)、nmap には
この機能を加えていません。IP のフラグメンテーションのオーバーラップ
に関する詳細情報は、IDS における論文(www.secnet.com)を参照ください。
TCP オプション -- 情報取得に関して言うと、これは本当に重宝する点です。
これらのオプションが素晴らしい点とは、
1) 概して、オプションであるいう点です(当たり前ですが)。
従って、全てのホストがオプションを実装している訳ではありません。
2) オプションをつけてクエリーを開始すると、ホストにオプションが実装
されているかどうかが分かります。標的ホストにオプションがサポート
されているかどうかは、応答パケットを見ることで分かります。
3) 一つのパケットにオプション全体を設定することができるので、一度に
全てのテストができます。
nmap は、ほとんど全ての探索用パケットにこれらのオプションを付けて
送ります。
Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops;
応答が返ってくる際に、どのオプションが受信されるか、そしてサポート
されているのかを見ることができます。最近の FreeBSD のような OS では
上記すべてのオプションをサポートしていますが、Linux 2.0.X はその内
の僅かしかサポートしていません。最近の Linux 2.1.X カーネルは、上記
すべてをサポートしています。一方、TCP シーケンス番号を簡単に推測で
きてしまう脆弱性があります。 是非、検証してみてください。
いくつかの OS で同じ組のオプションがサポートされていたとしても、オプ
ションの値によってそれらの相違を見ることができる場合があります。例え
ば、Linux に対して小さな MSS を送信すると、通常その MSS 自体をエコー
バックしてきます。ほかのホストでは、異なる値が受信されます。
同じ組のオプションと同じオプション値が受信される場合でも、オプション
が送られる順番やパディングの場所に相違を見ることができます。例えば、
Solaris の場合、'NNTNWME' が返ってきます。つまり、
<no op><no op><timestamp><no op><window scale><echoed MSS>
です。
一方、Linux 2.1.122 は MENNTNW を返します。同じ組のオプション、値で
すが、送られる順番が異なるのです。
TCP オプションを利用した OS 検知ツールはほかに見たことがありません
が、これは便利だと言えるでしょう。
ほかにも便利なオプションがあり、T/TCP や選択可能な ack をサポート
するようなものもあります。
Exploit 年代記 -- 上記すべての検証を行った上でも、nmap は、Win95、WinNT
Win98 に実装された TCP スタックの相違を見分けることができません。
Win98 が Win95 が出荷されてから4年後に出荷されたことを考えるとあき
れてしまいますね。何かしら(TCP にオプションを付けるなど) TCP スタック
に改善が見られてもいいのではないでしょうか。変更が行われていれば、
その相違から OS の種類を区別することができます。残念ながら、変更は
されなかったようです。NT 上に実装されたスタックは、Win95 に実装された
酷いものと同じであるのは明らかですね。また、Win98 でも更新するには至
らなかったようです。
しかし、希望を捨てないでください。解決策があります。初期に開発された
Windows 用 DoS 攻撃(Ping of Death、Winnuke など)で試すことができます。
また、それ以降に開発された Teardrop and Land なども利用できます。そ
れぞれの攻撃を仕掛けた後、標的マシンがクラッシュしたかどうかを ping
で調べてください。マシンがクラッシュしたところで、おおよそ何の
Service Pack、または Hotfix が適用されているかを絞り込むことができま
す。
この機能は、nmap に加えていませんが、搭載したくてわくわくしています。
SYN Flood Resistance -- いくつかの OS には、あまりに多くの 偽造された
SYN パケットが送られると、ほかの接続を受け付けることができない場合
があります(送信元アドレスを偽造したSYNパケットを使うのは、本当の送信
元であるホストでコネクションをいちいちリセットする手間を省くためです)。
OS は、一度に 8 個のパケットしか処理できないのがほとんどです。最近の
Linux カーネル(ほかの OSに比べて) SYN クッキーなどのような様々な方法
を使って、この問題が深刻化するのを防いでいます。
そこで、まず開いているポートに送信元アドレスを偽造した8個のSYNパケッ
トを送信し、次に自分のホストアドレスを送信元として同じポートにSYNパケッ
トを送り正しくコネクションが開設されるかどうかを調べれば、標的のホスト
のOSについての情報を得ることができます。しかし、これは、nmap に実装し
ませんでした。というのは、大量のSYN を送ると相手が怒る場合があるから
です。仮に、標的ホストの OS を識別しようとしていただけ、と説明しても
相手は落ち着いたままでいられないかもしれません。
NMAP の実装と結果
これまで述べてきたOS識別方法(除外すると言及したものを除く)を実装して
みました。この実装はnmapに組み込まれており、フィンガープリントを行う
為の開いているポートと閉じているポートの番号の情報も既に持っています
ので、特に指定する必要はありません。
これは既に nmap に実装されていますので、開いている、閉じているポート
の調査は、フィンガープリントによって自動的に調べてくれます。また、こ
れは、Linux、*BSD、Solaris 2.51/2.6，ほかのOS 上で動作します。
新しいバージョンの nmap は、以下に示す簡単な文法のフィンガープリント用
のテンプレートファイルを解釈します。
例
FingerPrint IRIX 6.2 - 6.4 # Thanks to Lamont Granquist
TSeq(Class=i800)
T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=N%W=C000|EF2A%ACK=O%Flags=A%Ops=NNT)
T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
初めの行を見てください。('>'は追加されています)
> FingerPrint IRIX 6.2 - 6.3 # Thanks to Lamont Granquist
これは単に、フィンガープリントが、IRIX バージョン 6.2 から 6.3 に対応
していることを表しています。Lamont Granquist 氏は、親切にも検証した
IRIX ホストの IP アドレス、フィンガープリントを送ってくれました。
> TSeq(Class=i800)
これは、イニシャルシーケンス番号のサンプリングの際、"i800クラス"として
扱うことを表しており、直前の番号よりも800の倍数分増加した値を使っている、
ということを意味します。
> T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
それぞれの検証名は、「テスト(test)」に因んで T1 となっています。この検
証では、SYN パケットにいくつもの TCP オプションを付けて開いたポートに
送ります。DF=N は、"Don't fragment" のビットが立っていないことを表して
います。W=C000|EF2A は、ウィンドウの通知は、0xC000 もしくは EF2A であ
ることを示しています。ACK=S++ は、ACK のイニシャルシーケンス番号が、１
つずつ増加していくことを表し、Flags = AS は、ACK と SYN のフラグが立っ
て応答されたことを表しています。Ops = MNWNNT は、オプションが次の順番
になっていることを表しています。
<MSS (not echoed)><NOP><Window scale><NOP><NOP><Timestamp>
> T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
テスト2では、同じオプションの値を全てNULLにして開いたポートに送信します。
Resp=Yは、応答を必ず受信することを表し、Ops= は、その応答パケットには
どのようなオプションも含まれないだろう、ということを表しています。ここ
でもし'%Ops='全体を記述しなかったら、すべての応答オプションにマッチン
グしてしまいます。
> T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M)
テスト3 は、開いたポートに SYN|FIN|URG|PSH にオプションを付けて送るも
のです。
> T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
これは、開いたポートへの ACK です。ここでは、Resp= がないことに気付き
ます。これは、応答がない(これは、ネットワークや邪悪なファイアウォール
上でパケットがドロップされたのかもしれません)からと言って、検証自体が
無効になるというわけではありません。この場合でも、ほかに一致する点がな
いかどうかどうかを見て検証することができます。これを行う理由は、ほとん
どの OSが応答しますが、応答がない場合は通常ネットワークの環境に拠るこ
とが多くOS 自体の原因ではないからです。テスト2 とテスト3で Resp タグを
置いているのは、いくつかの OS が、これらに応答しないでドロップするため
です。
> T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
> T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
> T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)
これらのテストは、SYN、ACK、FIN|PSH|URG のそれぞれを閉じたポートに対し
て検証しています。いつもの同じオプションも設定しています。もちろん、
この検証を区別する名前は、分かり易い'T5'、'T6'、'T7'となっています。
> PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
この大きな塊の行は、到達不能メッセージに対する検証です。DF=N は、既に
もうご存知でしょう。TOS=0 は、IP パケット内の TOS が、0 であることを
示しています。次の2つのフィールドは、IP ヘッダのメッセージフィールドと
そのエコーメッセージの合計の長さを16進数で表しています。RID=E は、オリ
ジナルの UDP パケットのコピーから得られる RID 値 を推測したものです。
(例えば、送った値と同じ値になります) RIPCK=E は、チェックサムが適切で
あることを表します。(適切でなければ RIPCK=F になります) UCK=E は、UDP
のチェックサムが適切であることになります。ULEN=は、UDP の長さが 0x134
を表し、DAT=E は、UDP データが正しくエコーされていることを示していま
す。多くの実装では、UDP データを適切に送り返さないので、デフォルトで
DAT=E が設定されています。
この機能が付いた nmap は、6番目のプライベートベータ版以降になります。
Phrack でこれを読んでいる頃には、リリースされていると思いますが、リリ
ースされていないかもしれません。最新版については、
http://nmap.org/ を参照してください。
人気のあるサイトのスナップショット
これは、我々の努力して行った興味深い結果です。インターネットサイトを
適当に選んで、そのサイトが利用している OS の種類を判定しています。多く
は、telnet のバナーを除去していたり、このような情報を隠していますが、
フィンガープリントには関係ありません！また、これは、あなたの好きな
弱点を抱える OS を利用している人々を見つけ出すいい方法ですね。
この例の中で、使用されているコマンドは、nmap -sS -p 80 -O -v <host>
また、探索はほとんどが、10/18/98 に行われました。その時以来、それら
のサイトは、サーバを更新、または変更しているかもしれません。
以下のサイトは私の嫌いなサイトです。
# "Hacker" sites or (in a couple cases) sites that think they are
www.l0pht.com => OpenBSD 2.2 - 2.4
insecure.org => Linux 2.0.31-34
www.rhino9.ml.org => Windows 95/NT # No comment :)
www.technotronic.com => Linux 2.0.31-34
www.nmrc.org => FreeBSD 2.2.6 - 3.0
www.cultdeadcow.com => OpenBSD 2.2 - 2.4
www.kevinmitnick.com => Linux 2.0.31-34 # Free Kevin!
www.2600.com => FreeBSD 2.2.6 - 3.0 Beta
www.antionline.com => FreeBSD 2.2.6 - 3.0 Beta
www.rootshell.com => Linux 2.0.35 # Changed to OpenBSD after
# they got owned.
# Security vendors, consultants, etc.
www.repsec.com => Linux 2.0.35
www.iss.net => Linux 2.0.31-34
www.checkpoint.com => Solaris 2.5 - 2.51
www.infowar.com => Win95/NT
# Vendor loyalty to their OS
www.li.org => Linux 2.0.35 # Linux International
www.redhat.com => Linux 2.0.31-34 # I wonder what distribution :)
www.debian.org => Linux 2.0.35
www.linux.org => Linux 2.1.122 - 2.1.126
www.sgi.com => IRIX 6.2 - 6.4
www.netbsd.org => NetBSD 1.3X
www.openbsd.org => Solaris 2.6 # Ahem :) (its because UAlberta
# is hosting them)
www.freebsd.org => FreeBSD 2.2.6-3.0 Beta
# Ivy league
www.harvard.edu => Solaris 2.6
www.yale.edu => Solaris 2.5 - 2.51
www.caltech.edu => SunOS 4.1.2-4.1.4 # Hello! This is the 90's :)
www.stanford.edu => Solaris 2.6
www.mit.edu => Solaris 2.5 - 2.51 # Coincidence that so many good
# schools seem to like Sun?
# Perhaps it is the 40%
# .edu discount :)
www.berkeley.edu => UNIX OSF1 V 4.0,4.0B,4.0D
www.oxford.edu => Linux 2.0.33-34 # Rock on!
# Lamer sites
www.aol.com => IRIX 6.2 - 6.4 # No wonder they are so insecure :)
www.happyhacker.org => OpenBSD 2.2-2.4 # Sick of being owned, Carolyn?
# Even the most secure OS is
# useless in the hands of an
# incompetent admin.
# Misc
www.lwn.net => Linux 2.0.31-34 # This Linux news site rocks!
www.slashdot.org => Linux 2.1.122 - 2.1.126
www.whitehouse.gov => IRIX 5.3
sunsite.unc.edu => Solaris 2.6
注釈:Microsoft の白書には、彼らのセキュリティについての怠慢さについて
こう語っています。
「Microsoft に対するセキュリティ軽視の考え方は、ここ数年で変ってきてい
ます。Windows NT は、そのセキュリティ機能のおかげで人気を博しています。」
私の見解からすれば、Windows は、セキュリティコミュニティの間では、全く
人気がないように思えます。Windows を搭載したマシンは上記全体のうち2つし
かありませんし、Windows は実装が乱れている(標準的な考え方からすると)の
で、nmap にとって非常に判定しやすい OS です。
もちろん、ほかにもチェックしなければならないサイトはいくつもあります。
これは、Transmeta 社の超極秘の Web サイトです。興味深いことに、この会社
は、Microsoft 社の Paul Allen 氏が出資していますが、Linus Torvalds 氏
を雇っています。ですので、より Paul 氏に密着していて、NT が稼動してい
るのでしょう。もしくは、反逆して Linux 革命に移るのでしょうか。
見てみましょう。
次のコマンドを使用しました。
nmap -sS -F -o transmeta.log -v -O www.transmeta.com//24
これは、既知のポート(/etc/services)に対してSYN スキャンを行っており、
その結果を'transmeta.log'に出力しています。つまり、OS スキャン、
そして、www.transmeta.com が設置されたネットワーク上をクラスC で探査
しています。まとめた結果は以下のとおりです。
neon-best.transmeta.com (206.184.214.10) => Linux 2.0.33-34
www.transmeta.com (206.184.214.11) => Linux 2.0.30
neosilicon.transmeta.com (206.184.214.14) => Linux 2.0.33-34
ssl.transmeta.com (206.184.214.15) => Linux unknown version
linux.kernel.org (206.184.214.34) => Linux 2.0.35
www.linuxbase.org (206.184.214.35) => Linux 2.0.35 ( possibly the same
machine as above )
この結果で、上の質問に対する回答がはっきりと分かりましたね :)。
謝辞
Nmap が多くの OS の種類を推定できる理由は、新しくおもしろいマシンの
フィンガープリントを探そうとして努力した多くの方々のおかげです。
特に、Jan Koum、van Hauser、Dmess0r、David O'Brien、James W. Abendschan、
Solar Designer、Chris Wilson、Stuart Stock、Mea Culpa、Lamont Granquist、
Dr. Who、Jordan Ritter、Brett Eldridge、Pluvius は、インターネット上
からでは通常見つからない変ったマシンの IP アドレスをたくさん教えてくれ
ました。
Richard Stallman には、GNU Emacs を作っていただき感謝しております。こ
の記事を書くにあたって、vi、cat、^D などを使っていたのであれば上手くい
かないような、単語編集もスムーズにいきました。
ご質問、コメントなどは、fyodor@DHP.com へお送りください(こちらのメール
アドレスが何らかの理由で使用できない場合は、fyodor@insecure.org をお使
いください)。Nmap は、http://insecure.org/nmap から入手できます。
----------------------------------------------------------------------
この和訳は以下の2名が行いました。
ご質問等は訳者にお知らせください。
柳岡 裕美 (YANAOKA Hiromi) yanaoka@lac.co.jp
坂井 順行 (SAKAI Yoriyuki) sakai@lac.co.jp
----------------------------------------------------------------------
初版発行(原文): October 18, 1998
最終更新日(原文) : April 10, 1999
初版発行(日本語版) : August 17, 2000
最終更新日(日本語版) : September 11, 2000
----------------------------------------------------------------------
