Top twenty security hole from SANS.org

　昨年に引き続き、今年もSANS.orgから代表的なセキュリティホールが発表されました。

　今年の特徴は、昨年のTop tenからTop twentyと、一気に２倍の数になったことと、昨年のTop ten中、9つが今年もランクインしていることです。

　つまり、昨年よりもサイト構築に注意しなければならないことが増えたということであり、かつ昨年来、全く進歩のないサイトがまだ世界中に存在している、ということに外なりません。

　そこで、やはり昨年に引き続き、今年も日本語でっち上げ訳を作成し、情報の発信に勤めようと思います。

　また、私のコメント等を随所に書きます。また、でっち上げ訳ですので、訳は１対１になっているとは限りません。従って、英語の勉強には役立ちません（笑）。

　なお、訳や要点の抽出に問題がある場合もありますので、原文に目を通すことを推奨します。原文の方がより詳細な情報となっていることにもご留意ください。

　誤訳その他についてはぜひぜひご一報ください。

留意点

コンピュータ全般の問題

　ここでは、どのOSにも言える、一般的なセキュリティ問題について扱っています。


G1:OSやアプリケーションをデフォルトインストールしたままの状態

G1.1:概略

　多くのOSやアプリケーションが、ユーザがより便利に使えるよう、何でもかんでもインストールする用にインストーラーを設計している。

　これは便利な一面、ユーザが使いもしない（そして存在も知らない）多くの機能をインストールする結果となる。

　このような機能に対し、ユーザはパッチを当てようとはしないし、そもそもパッチの必要性も感じない。

　こういった、パッチの当たっていないシステムは攻撃者の餌食となる。

　また、OSは多くのポートをオープンする。それは攻撃に使用される場合も多い。

　そして、勝手にインストールされるサンプルスクリプトなどは攻撃に悪用しやすいものが多い。

G1.2:影響範囲

　ほとんどすべてのOS、アプリケーション。特に、WWWサーバ用CGIなどは多くの場合、危険である。

G1.3:CVE番号

（注：これは一部に過ぎないことに注意）

CVE-1999-0415, CVE-1999-0678, CVE-1999-0707, CVE-1999-0722, CVE-1999-0746, CVE-1999-0954, CVE-2000-0112, CVE-2000-0192, CVE-2000-0193, CVE-2000-0217, CVE-2000-0234, CVE-2000-0283, CVE-2000-0611, CVE-2000-0639, CVE-2000-0672, CVE-2000-0762, CVE-2000-0868, CVE-2000-0869, CVE-2000-1059

G1.4:問題の確認方法

　標準インストールを行い、サービスを停止せず、ろくにパッチも当ててないとしたら、この問題に当てはまる。ポートスキャナや脆弱性スキャナでシステムを再確認しましょう。

G1.5:対処方法

　いらないプログラムは削除し、いらないサービスは停止し、いらないポートは閉じる。また、インストールの「よい」ガイドラインを参考にする。

（しかＰ：G1について。論外だけど、非常に多いパターン。なにせコンピュータベンダーすらこういったことを平気でやるからね、まじで。ましてや一般の人の９割はこうでしょ？）

G2:パスワードなしとかすぐばれそうなパスワードの使用

G2.1:概要

　多くのシステムはユーザ名とパスワード「だけ」を利用して安全性を確保している。しかし、パスワードを設定していない、デフォルトのパスワードを使用している、推測しやすいパスワードを使用しているなどの場合、簡単に侵入できてしまう。

　特に、システムにデフォルトで入力されているユーザ名にはパスワードがないか、すでに知られたパスワードが使用されている。

G2.2:影響範囲

　ユーザ名とパスワードを使用する多くのOSとアプリケーション。

G2.3:CVE番号

（注：これは一部に過ぎないことに注意）

CVE-1999-0291, CAN-1999-0501, CAN-1999-0502, CAN-1999-0503, CAN-1999-0505, CAN-1999-0506, CAN-1999-0507, CAN-1999-0508, CAN-1999-0516, CAN-1999-0517, CAN-1999-0518, CAN-1999-0519

G2.4:問題の確認方法

どのようなアカウントがシステムに存在するか確認すること。

  1. システムアカウントを調査し、リストを作る。ルータ、プリンタなどのパスワードチェックを忘れずに。
  2. アカウントの停止、追加のルールを作る。
  3. アカウントの停止、追加などはリストとクロスチェックする。
  4. いい加減なパスワードを調査するためにパスワードクラックツールを使用しなさい。ただし、使うことを許諾されてからにすること。
  5. 使われることのないアカウントを停止するための確固とした手続きを策定し、実行しなさい。

G2.5:対処方法

　パスワードなしはパスワードをつけ、弱いパスワードは強いものに変え、場合によってはアカウントを停止する。

　ユーザに強いパスワードを義務づけるため、プログラムによるチェックを行うなどの方策で、安易なパスワードを排除する。

　さもなければ、諮問認証などの新しい手段の導入を検討する。

（しかＰ：G2について。なにより、アカウントの整理、リストアップをしましょう。そして、安易なパスワードがなぜ危険かについて周知徹底することも重要です。ただし、絶対守らないやつはいる！なので、罰則規定も必要かと思います。）

G3:やってないか、やってもおざなりのバックアップ

G3.1:概要

　問題が発生した時、復帰には最新のバックアップからデータを復帰するための手段を取らなければならない。

　しかし、毎日バックアップをするものの、本当にバックアップできているかどうか確認していない。また、バックアップのポリシーや手続きこそ策定されているが、復帰のポリシーや手続きが策定されていなかったりする場合がある。

　そういった問題は、クラッキングされたときにはじめて確認される場合が多い。

　第２の問題として、バックアップメディア自体を物理的に保護していないことがあげられる。

　バックアップデータは、サーバ上の重要なデータと同様に保護される必要がある。

G3.2:影響範囲

　ミッションクリティカルなすべてのシステム

G3.3:CVE番号

　なし

G3.4:問題の確認方法

　まず、システムバックアップの対象を決定し、そのシステムにどの様な脅威が存在するか確認した上で実施する必要がある。

　バックアップのポリシーもきちんと策定しなければならない。

　その上で、以下の項目を確認する。
  1. バックアップ手順は問題ないか？
  2. バックアップの間隔は許容範囲か？
  3. きちんとした手続きを踏んだバックアップか？
  4. メディアに正確にバックアップされているか？
  5. メディアはきちんと保護され、外部に保存されているか？
  6. ほかのメディアにリストア用のユーティリティが存在するか？
  7. 復元の手続きはきちんと機能するか？

G3.5:対処方法

　バックアップは、少なくとも毎日行われなければならない。

　最低でも、週１回のフルバックアップと、毎日の差分バックアップをする必要がある。

　また、最低月１回、バックアップメディアが正確にバックアップしていることをテストサーバを用いてテストすべきである。

　一部のクリティカルなシステムでは、毎日、または１日数回のフルバックアップを行う必要があるだろう。

　究極のバックアップはフェイルオーバー能力を持つ十二分に冗長化されたシステムだろうか。

　それは、リアルタイム性が必要な電子商取り引きシステムやインフラシステム、国防などのシステムには必要だろう。

（しかＰ：これはさすがに耳が痛い^^;;。個人ではつらいかもしれないですね。間隔は空けてもいいですから、バックアップをしましょう。また、リストアについてもテストしましょう。）

G4:大量に開かれたポート

G4.1:概要

　ユーザや攻撃者は、開かれたポートを通してシステムに接続する。多くのポートが開いているシステムは、接続できる可能性を拡大する事になる。

　つまり、安全にシステムを運用するには、必要最小限のポートを開くのみにとどめ、必要のないポートは閉じなければならない。

G4.2:影響範囲

　ほぼすべてのOS

G4.3:CVE番号

（注：これは一部に過ぎないことに注意）

CVE-1999-0189, CVE-1999-0288, CVE-1999-0351, CVE-1999-0416, CVE-1999-0675, CVE-1999-0772, CVE-1999-0903, CVE-2000-0070, CVE-2000-0179, CVE-2000-0339, CVE-2000-0453, CVE-2000-0532, CVE-2000-0558, CVE-2000-0783, CVE-2000-0983,

G4.4:問題の確認方法

　netstatコマンドは、ローカルシステム上で簡便に開かれたポートを確認できるが、最もよい方法はシステムに対してポートスキャンをすることである。

　これによって、実際に開いているすべてのポートを確認できる。この結果と、netstatの結果が異なる場合には調査が必要である。

　なぜそのポートが開き、どのプログラムがそのポートを利用しているか確認すべきである。

　確認されていない、または正当性のないポートはすべて閉じるべきである。

　また、最終的にチェックしたポートのリストは記録し、定期的に確認すべきである。

　最も人気のあるポートスキャナはnmapである。これは、UNIX、NTそれぞれで使用可能である。

　ほかのポートスキャナでも問題ない。必要なのは、TCP、UDPそれぞれのポート番号1-65535をすべて調べることである。

　ただし、ポートスキャンを行う場合、許可を得る必要がある。ポートスキャンの方法によってはシステムに悪影響を及ぼす場合もある上、ファイアウォールやIDSにより、攻撃と見なされる場合がある。

G4.5:対処方法

　必要最小限のポートを開くのみとし、他のポートは閉じることを徹底する必要がある。

　ポートを閉じるためには、サービスを停止し、削除することが必要である。

　UNIXシステムでは、サービスはinetd（コンフィギュレーションファイルはinetd.conf）によって制御されている。inetd.confを編集し、ポートを開くか閉じるかを設定した上で、inetdを再起動することで不用意なポートが開かれることを制御できる。

　inetdで制御されていないサービスでは、ブート時にスクリプト（例：/etc/rc、/etc/rc.localや/etc/rc*.dなど）によって実行される。

　詳細はシステムのマニュアルを参照すること。

　WindowsNT/2000では、fportと呼ばれるプログラムによって、どのプログラムがポートを使用しているか確認することができる。

　またWindowsXPでは、netstatの-oオプションで同様の調査が可能である。

　これらの調査で、どのプログラムを停止することでポートを閉じることが可能か確認できる。

（しかＰ：ポートが開きっぱなしはできる限り避けましょう。必要最低限、これが鉄則。）

G5:内向き、外向きパケットが適切にフィルタリングされていない

G5.1:概要

攻撃者が相手コンピュータを攻略しようとするとき、自分の居所を隠すため、IPアドレスのスプーフィングをよく行う。

　例えば、非常にポピュラーな手法であるスマーフ攻撃では、何千ものマシンにパケットストリームを送信するために、ルータの機能を使用する。

　各パケットは、攻撃対象マシンのIPアドレスを含んでいる。

　スプーフされたパケットを大量に送信されたコンピュータまたはそのネットワークはシャットダウンさせられる。

　外向き、内向きのパケットについてフィルタリングを行うことは、高いレベルの防御の手助けになる。

　その時のフィルタリングルールは以下のとおりとなる。
  1. ネットワークに入るパケットには、内部ネットワークのソースアドレスがあってはならない
  2. ネットワークに入るパケットには、内部ネットワークのディスティネーションアドレスがなくてはならない
  3. ネットワークから出るパケットには、内部ネットワークのソースアドレスがなくてはならない
  4. ネットワークから出るパケットには、内部アドレスのディスティネーションがあってはならない
  5. ネットワークに入る、もしくは出るアドレスにはプライベートアドレス、もしくはRFC1918で規定されたアドレスがソース、ディスティネーションともにあってはならない
    上記アドレスは、10.x.x.x/8、172.16.x.x/12、192.168.x.x/16およびループバックの127.0.0.0/8を含む
  6. ソースルートパケットおよびIPオプションフィールドのセットされたパケットは通してはならない

G5.2:影響範囲

　ほとんどのOSとネットワーク機器

G5.3:CVE番号

（注：これは一部に過ぎないことに注意）

　CAN-1999-0528, CAN-1999-0529, CAN-1999-0240, CAN-1999-0588

G5.4:問題の確認方法

　スプーフされたパケットを送信して、ファイアウォールがそれを適切にブロックするか確認する。また、ブロックしたことが適切にログに記録されなければならない。

　ただし、これによって、ログファイルが一杯になるという新しい攻撃になってしまうことに注意しなければならない。このため、ロギングシステムが高負荷に耐えられるかどうかも確認すること。

　nmapのようなプログラムを使用することで、フィルタリングテストを行うことが可能である。

　一度、フィルタリングが適切になされていたとしても、これが本当に効果的に機能しているとは限らないため、テストはたびたび行う必要がある。

　

G5.5:対処方法

　これらの攻撃から防御するためには、ルータまたはファイアウォールが適切にセットアップされている必要がある。

（しかＰ：フィルタくらいしましょうね。ただし、Windows系のパーソナルファイアウォールなどは、起動時１，２分の間無防備になることが分かっています。無防備になっている時は、ダミーネットワークに繋いで外部から繋がれないようにしましょう。また、ポートは閉じましょう。）

G6:行っていないか、不完全なログ収集

G6.1:概要

　セキュリティにおける格言の一つは「防止は理想的である、しかし、検出は必要である」、である。

　インターネットとつながっている限り、攻撃者が嗅ぎ回るなどの機会は存在する。

　新しい脆弱性は毎週のように発見され、新しい脆弱性を利用する攻撃者から自信を守るすべはほとんど存在しない。

　いったん攻撃を受けた際、ログなしでは攻撃者が何を行ったか調べることはできない。

　あなたは、OSをクリーンインストールするか、バックアップから復元するかを行わなければならないが、その復旧方法では攻撃者がシステムを管理下においたままである、と言うことになる。

　何がネットワーク上で起こっているかが分からないと、攻撃されていることすら分からないだろう。

　ログは、何が生じ、どのシステムが攻撃され、どのシステムが攻略されてしまったかについて調査する際の詳細な情報となる。

　ログ収集はすべてのシステムで定期的にされる必要がある。また、ログはいつ必要になるか決まっているわけではないため、アーカイブされ、バックアップされる必要がある。

　大部分の専門家は、攻撃者によってログが上書きされることで検出が不能とならないように、すべてのログをログ収集サーバに送信し、上書き不能メディアに書き込むことを要求している。

G6.2:影響範囲

　すべてのOSとネットワーク機器

G6.3:CVE番号

　CAN-1999-0575, CAN-1999-0576, CAN-1999-0578

G6.4:問題の確認方法

　システムのシステムログをチェックする。もしログがない、もしくはログを集中的に保存、バックアップしていなければ、脆弱性を持っている。

G6.5:対処方法

　ログをローカルに保存するとともに、リモートシステムにログを送信するようにすべてのシステムをセットアップする。これは、冗長性とセキュリティにおける特別なレイヤーを提供する。

　これによって、２つのログが存在し、お互いを比較することができる。どの様な差も、システム上での疑わしいものとして示される。

　加えて、ログファイルの相互チェックが可能となる。１つのサーバにおけるログファイルの１行は疑わしくないかもしれないが、５０のサーバの同様なログは、問題が生じていることを示すかもしれない。

　また、可能な限り、wtite-onceメディアにログ情報を書き込むこと。

（しかＰ：ログをおろそかにするものはいつか泣きます。場合によってはアメリカあたりのサイトから損害賠償、とか言われて人生棒にふるかもしれないですよ。）

G7:脆弱性を持つCGIプログラム

G7.1:概要

　マイクロソフトのIISとapacheを含む大部分のhttpサーバは、WWWによる対話機能（データ収集や検証など）を提供するためにCommon Gateway Interface(CGI)機能をサポートしている。

　実際、大部分のhttpサーバはサンプルCGIプログラムを提供し、インストールする。

　残念なことに、非常に多くのCGIプログラマーはプログラムが、インターネット上のすべてのユーザがhttpサーバを動かしているコンピュータにダイレクトにリンクしていることを考慮していない。

　比較的簡単に確認でき、その強力な機能により、httpサーバを動かしている特権レベルでコンピュータを操作することができるため、攻撃者は脆弱性のあるCGIプログラムを魅力的なターゲットと見なしている。

　侵入者は、WWWページを改竄し、クレジットカード情報を盗み、将来利用可能なようにバックドアをセットアップするのに、脆弱性のあるCGIプログラムを攻撃することが知られている。

　司法省のWWWサイトが攻撃されたとき、詳細な評価の結果、CGIのセキュリティホールを悪用した、というのが最も可能性が高い、と結論されている。

　同様に、無学、もしくは不注意なプログラマによって作られたWWWサーバアプリケーションは、脅威に対して弱い。

　また、一般に、サンプルのCGIプログラムは常にシステムから削除される必要がある。

G7.2:影響範囲

　すべてのhttpサーバ

G7.3:CVE番号

（注：これは一部に過ぎないことに注意）

CVE-1999-0067, CVE-1999-0346, CVE-2000-0207, CVE-1999-0467, CAN-1999-0509, CVE-1999-0021, CVE-1999-0039, CVE-1999-0058, CVE-2000-0012, CVE-2000-0039, CVE-2000-0208, CAN-1999-0455, CAN-1999-0477

G7.4:問題の確認方法

　httpサーバ上にサンプルコードが存在する場合、脆弱性を持っている。

　また、もしCGIプログラムを使用しているならば、最新バージョンであることを確認し、脆弱性スキャンを実行する。

　攻撃者が行う可能性のあることをシミュレートすることで、システムを防御する準備を行うことが可能となる。

　問題のあるCGIスクリプトを見つけるために、whiskerのようなCGIスキャナを利用してもよい。

G7.5:対処方法

　脆弱性のあるCGIプログラムに対して実施しておく必要のあるものを以下に列記する。
  1. すべてのサンプルCGIを削除する
  2. 残っているCGIを検査し、安全でないCGIプログラムを削除する
  3. CGIプログラマが入力バッファ長について厳しいポリシーを持っていることを確認する
  4. 削除できない既知の脆弱性を持つものにパッチを適用する
  5. cgi-binディレクトリにコンパイラ、インタプリタをインストールしていないことを確認する
  6. 「view-source」スクリプトを削除する
  7. 特権でhttpサーバを実行しない
  8. 必要ないならば、CGIサポートを設定しない
（しかＰ：インストールすりゃいいってものじゃないです。サーバを作るのなら、そうじは怠らないようにしましょう）

Windowsシステム固有の問題

　ここでは、Windowsシステム固有の問題について列記してあります。

W1:Unicodeの問題（WWWサーバのディレクトリをさかのぼってしまう）

W1.1:概要

　UNICODEは、あらゆる文字を固有の数字で表すことで、どの様な言語、プラットフォーム、プログラムでも利用できるようにする技術である。

　UNICODEは、マイクロソフトを含む大部分のベンダーに採用された。

　IISサーバに不当なUNICODE(UTF-8)シーケンスを含む、慎重に作られたURLを送信することで、攻撃者はサーバ上で文字通り「上に、外に歩い」て、任意のスクリプトを実行させることができる。

　この種の攻撃は、「ディレクトリ横断攻撃」として知られている。

　UNICODEにおいては、/と\は、それぞれ%2f、%5cと表すことができる。

　しかし、「非常に長い」シーケンスを使ってこれらの文字を表すことが可能である。

　非常に長いシーケンスは、実際に文字表現に必要なものより長く、技術的に不当な表現である。

　/と\はそれぞれ１バイトで表現できる。非常に長い表現（例えば%c0%af）では、２バイトを用いて文字を表示することもできる。

　IISは、このような長いシーケンスでかかれた場合、セキュリティチェックが機能するように作成されていない。

　そのため、URLで、非常に長いUNICODEシーケンスを利用することで、マイクロソフトのセキュリティチェックを回避できる。

　UNICODEの問題に関する追加情報は以下で確認できる。

W1.2:影響範囲

　WindowsNT4.0上で動作するIIS4.0とサービスパック２の適用されていない、Windows2000上で動作するIIS5.0

W1.3:CVE番号

CVE-2000-0884

W1.4:問題の確認方法

　パッチの適用されていないIISを使用している場合、問題があるだろう。

　問題の確認に最もよい方法は、hfnetchkを実行することである。

　hfnetchkは、１台、もしくはネットワーク上にある複数のシステムのパッチレベルを確認する、管理者のために作成されたツールである。

　UNICODEディレクトリ横断問題は以下のアップデートでフィックスされている。

　　もし、上記のいずれについてもインストールされていないならば、この問題に対して脆弱性を持っていることになる。

　より詳しい検証のためには、それが成功するかどうか自身のシステム上でテストすることが可能である。

　IIS-httpサーバに対して、以下のURLを送信してみる。

　このURLは正確に特定のシステムをテストするためには修正する必要がある。

　もしscriptsディレクトリを削除している場合、このコマンドは失敗する。

　実行可能権限を持つディレクトリを一時的に作成するかscripts意外の実行権限を持つディレクトリを使用することでシステムのテストを行うことができる。

　例えば、scriptsディレクトリを削除した場合でも、その代わりにcgi-binディレクトリが存在するかもしれない。

　scriptsディレクトリの代わりにcgi-binディレクトリを使用して、システムのテストをする必要がある。

　もし、問題が存在するならば、上記のURLはCドライブのファイルリストを出力するだろう。

　あなたがシステムに対して行ったことは、本質的に攻撃者が行っていることと同じである。

　唯一の差は、攻撃者が重要な損害を与えたり、バックドアを作成するなどと異なり、侵入に使われないコマンド（dirのような）を実行したことだけである。

W1.5対処方法
　これらの攻撃を防御するためには、マイクロソフトからパッチを入手、インストールしなければならない。

　これらのフィックス用パッチをダウンロードするための情報は、Microsoft Security Bulletinにある。

　IIS LockdownツールとURL Scanは、この脆弱性を保護することができる。IIS Lockdownは、管理者がIISサーバをロックすることができるように設計されている。また、以下で入手可能である。

　URL Scanは、多くのURLリクエストをフィルタリングすることができる。例えば、UTF8を含むリクエストを濾過することが可能である。

入手先を以下に示す。

W2:ISAPIエクステンションのバッファオーバーフロー

W2.1:概要

　マイクロソフトのIISは、WindowsNTとWindows2000サーバ上で最も多く使用されるhttpサーバソフトウェアである。

　IISがインストールされるとき、いくつかのISAPIエクステンションは自動的にインストールされる。

　ISAPI（Internet Services Application Programming Interface）は開発者がDLLを使用してIISサーバの能力を拡張することをサポートする。

　idq.dllのように、いくつかのDLLはバウンドエラーのチェックをきちんと行っていないものもある。

　特に、これらは本来許容されないほど長い入力文字列をチェックしていない。

　攻撃者は、バッファオーバーフロー攻撃として知られる方法を用いて、これらのDLLに攻撃用コードを送信し、IISサーバを掌握することが可能である。

W2.2:影響範囲

　idq.dllのバッファオーバーフローは、マイクロソフトIndex Server 2.0とIndexing Serviceが影響する。

　.printerバッファオーバーフローは、IIS5.0のインストールされたWindows2000 Server、Advanced Server、Server Data Center Editionが影響する。

　問題のあるDLLはWindows2000 Professionalにも含まれるが、デフォルトではマッピングされない。

　予防として、できれば、Webベースでの印刷は行わず、ワークステーション上で印刷するようにGroup Policyを設計する必要がある。

W2.3:CVE番号

　CVE-1999-0412, CVE-2001-0241, CAN-2000-1147, CAN-2001-0500

W2.4:問題の確認方法

　httpサーバがサービスパック２をインストールされていないならば、そのサーバは問題がある。

　どのパッチが適用されているか分からない場合には、hfnetchkをダウンロードし、実行するべきである。

　以下のパッチは、.printerバッファオーバーフローの修正を含んでいる。

　以下のパッチは、idq.dllバッファオーバーフローの修正を含んでいる。

W2.5:対処方法

　マイクロソフトから最新のパッチをダウンロード、適用する必要がある。これらは、以下で入手可能である。

　この問題は、WindowsXPには影響しない。

　また、管理者はどの様なISAPIエクステンションでも、使用しないならばマッピングを外す必要がある。

　また、エクステンションが再マッピングされていないことを定期的に確認する必要がある。

　「最小の特権」原理を忘れてはいけない。システムは必要最小限のサービスにとどめるべきである。

　IIS Lockdownツールは、管理者がIISサーバをロックすることができるように設計されている。また、以下で入手可能である。

　URL Scanは、多くのURLリクエストをフィルタリングすることができる。例えば、UTF8を含むリクエストを濾過することが可能である。

　入手先を以下に示す。

W3:IIS-RDSに対する攻撃

W3.1:概要

　マイクロソフトのInternet Infomation Server(IIS)は、WindowsNT4.0上で動くもっとも代表的なhttpサーバプログラムである。

　悪意のあるユーザは、管理者特権でリモートコマンドを実行するために、IISのRemote Data Services(RDS)のプログラミング上の問題を悪用する。

W3.2:影響範囲

　IIS4.0を実行しているWindowsNT4.0で、仮想ディレクトリの/msadcがマッピングされているもの。

W3.3:CVE番号

　CVE-1999-1011

W3.4:問題の確認方法

　パッチの適用されていないシステムは、問題がある。

　RDSに関する問題と、それを修正する方法についての優れたガイドは以下に存在する。

W3.5:対処方法

　この問題は、パッチによって修正されない。

　この問題に対処するためには、以下のセキュリティ発表を一読すること。

　または、MDACのバージョンを2.1以上にアップデートすることによって、問題に対処できる。

　最新バージョンは以下の場所にある。

W4:NETBIOS-保護されていないWindowsのネットワーク共有

W4.1:概要

　Server Message Block(SMB)プロトコル（Common Internet File System(CIFS)プロトコルとしても知られている）は、ネットワーク上でのファイル共有を可能にする。

　不適当な設定の場合、重要なファイルを晒してしまったり、インターネットに接続している誰に対してもファイルシステムのすべてにアクセス可能としてしまう。

　多くのコンピュータの所有者は、同僚や他の研修者の使用環境を改善するために、ドライブをネットワーク上で読み書き可能とするとき、知らず知らずの家に攻撃者に対しても開いてしまう。

　政府のコンピュータサイト管理者は、任務計画のためのソフトウェア開発のためにそれらのファイルを読み出し可能としたため、他の人々も簡単にアクセス可能となった。

　２日以内に、攻撃者は開いたファイル共有を発見し、計画のソフトウェアを盗み出した。

　Windowsマシン上でのファイル共有機能を使用することは、情報の窃盗と、特定の早く感染するウィルスに対して脆弱にしてしまう。

　マッキントッシュとUnixコンピュータもまた、ユーザがファイル共有を使用した場合、同様に脆弱となる。

　Windowsのファイル共有に使用されるSMBメカニズムが、システムから重要なシステム情報を入手するために攻撃者に利用される場合もある。

　ユーザーとグループの情報（ユーザ名、最後のログオン日時、パスワードポリシー、RASに関する情報）、システム情報と特定のレジストリキーがNetBIOS Session Serviceに対する「Nullセッション」として知られている接続によってアクセス場合もある。

　この情報は、パスワード推測やパスワード総当たり攻撃を使用するのに役立つため、攻撃者にとって非常に有用である。

W4.2:影響範囲

　Microsoft Windows NT4.0およびWindows 2000

W4.3:CVE番号

　CVE-1999-0366, CVE-2000-0222, CVE-2000-0979, CAN-1999-0518, CAN-1999-0519, CAN-1999-0520, CAN-1999-0621, CAN-2000-1079

W4.4:問題の確認方法

　SMBファイル共有と関連する脆弱性を早く、無料で、しかも安全に検査する方法（これはどの様なWindowsシステムでも効果的である）は、Gibson Reseatch CorporationｎWWWサイトで利用可能である。

　どの様なシステムのSMBによる公開も、リアルタイムの評価結果を「ShieldsUP」アイコンをクリックすることで得られる。

　詳細な情報は、WindowsユーザがSMBの脆弱性を扱う手助けになる。

　注意しなければならないのは、あなたのコンピュータが、なんらかのネットワークデバイスを介してネットワークに接続されている場合、ShieldUPツールが脆弱性を持たないと報告するということである。

　これは、例えば、ISPがダイアルアップネットワークなどでSMBをブロックしている場合などがあげられる。SheldsUPは問題がない、と報告する。

　しかし、この場合、同じダイアルアップネットワークに存在する他の人々があなたのコンピュータの脆弱性を攻撃可能となっている場合がある。

　Microsoft Personal Security Advisorは、SMB攻撃に弱いどうかを報告し、問題を修復することができる。これは、ローカルで実行されるので、その結果は常に信頼できる。

　これは、以下で利用可能である。

W4.5:対処方法

　無防備なファイル共有を防御するためには、次のステップを実行する必要がある。

  1. データを共有する際には、必須のディレクトリだけが共有されていることを確認する。
  2. DNSによる名前解決を詐称する場合もあるので、それに対するセキュリティを確保するために、特定のIPアドレスだけに共有を許可するようにする。
  3. 共有されたディレクトリのアクセス制御が、必要とする人たちだけに許可されているように確実なアクセス制御を行う。
  4. Nullセッション接続によるユーザ、グループ、システムコンフィギュレーションとレジストリキーの列挙を防ぐ手段を講じる。詳細情報はW5を見ること。
  5. ルータ、またはホストで、NetBIOS Session Service（TCP 139）と、CIFS（TCP/UDP 445）等の通信をブロックすること。
  6. スタンドアローンか、信頼されていないドメイン環境でインターネット接続をする際には、RestrictAnonymousレジストリキーを設定することも考慮に入れること。
　詳細は、以下のWWWページを参照のこと。

W5:Nullセッション接続による情報の漏洩

W5.1:概要

　Null セッション接続（またはAnonymous Logonとしても知られている）は、匿名のユーザが（ユーザ名と共有など）情報を検索するのを許したり、認証なしでログオンする機能である。

　その機能は、explorer.exeなどのアプリケーションがリモートサーバ上の共有を列挙するのに使われている。

　WindowsNTとWindows2000システムでは、多くのローカルサービスがSYSTEMアカウント（Windows2000ではLocalSystemとして知られている）で実行される。SYSTEMアカウントは、重要なシステムオペレーションで使われている。

　一つのマシンが、他のマシンからシステムデータを検索する必要が生じたとき、SYSTEMアカウントはNullセッションを他のマシンとの間に確立する。

　SYSTEMアカウントは仮想的に無制限の特権を持ち、パスワードを持っていないため、ユーザはSYSTEMとしてはログオンできない。

　SYSTEMは、使用可能な共有、ユーザ名などの他のシステムの持つ情報にアクセスする必要がある。-Network Neighborhood type functionality.（？）

　ユーザIDとパスワードを使用して他のマシンにログインすることはできないため、アクセスにNull Sessionを使用する。

　残念なことに、攻撃者もまた、Null sessionを用いてログオン可能である。

W5.2:影響範囲

　Windows NT 4.0およびWindows 2000

W5.3:CVE番号

　CAN-2000-1200

W5.4:問題の確認方法

　以下に示すコマンドを用いて、Nullセッションによるシステム接続を試してみる。

　net use \\a.b.c.d\ipc$ "" /user:""
　（a.b.c.dはリモートシステムのIPアドレス）

　もし、「connection failed」というレスポンスが帰ってきた場合、問題は存在しない。

　応答がない場合、コマンドが成功したことを意味しており、この場合、システムには問題があることを意味している。

　または、「Hunt for NT」も使用できる。これは、www.foundstone.comによる、NT Forensic Toolkit中のコンポーネントである。

W5.5:対処方法

　ドメインコントローラは、Nullセッションで通信することを要求している。このため、コンピュータがドメイン環境で稼働している場合、攻撃者が入手可能な情報を最小にすることはできるが、すべての情報漏洩を止めることはできない。

　Windows NT 4.0では、攻撃者が利用可能な情報の入手を制限するためには、以下のレジストリキーを修正する。

　HKLM/System/CurrentControlSet/Control/LSA/RestrictAnonymous=1

　RestricAnonymousレジストリが１にセットされている場合、まだ特定の情報を攻撃者が入手可能である。（？）

　Windows2000では、１の代わりに２をセット可能である。

　そうすることで、匿名ユーザを、アクセス権を彼らおよびEveryoneグループ（匿名ユーザも含む）に与えられていないすべての情報のアクセス権から除外する。

　レジストリの修正時はいつでも、その修正でシステムが正しく動作しなくなる場合があるため、どの様な変更でもテストを行う必要がある。

　また、システムは簡単にリカバリできるよう、バックアップする必要がある。

　もし、ファイル共有とプリント共有を必要としていないのならば、TCP/IPからNetBIOSの機能を削除した方がよい。

　ドメインコントローラと特定の他のサーバ上でRestrictAnonymousを設定することは、多くのネットワークオペレーションが機能しなくなることがある事に注意する必要がある。

　このため、インターネットに直接つながっているマシンのみがこの設定をされるべきである。その他のすべてのマシンは、NetBIOSとCIFSをブロックするよう設定されたファイアウォールによって保護されなければならない。

　インターネット上のユーザが、内部のドメインコントローラや外部とのアクセス用に設計されたシステムにアクセスできるようにしてはならない。

　その様なアクセスを止めるために、外部ルータやファイアウォールで以下のポートをブロックすること。

　TCP/UDPの１３５から１３９、４４５

W6:SAM（LM Hash)のハッシュ方法の弱点

W6.1:概要

　大部分のWindowsユーザにとってLAN Managerサポートのニーズはないが、デフォルトでは、Windows NT/2000ではLAN Managerパスワードハッシュを保存している。

　LAN Managerは、現在のマイクロソフトのアプローチに比べて非常に弱い暗号化手法を用いているため、LAN Managerパスワードは非常に短い時間で解読することが可能である。

　どんなに強いパスワードを暗号化しても、１か月以内に解読することが可能である。

　LAN Managerで用いるハッシュの主要な欠点は以下のとおり。

　この特性は、パスワード買い得プログラムが、小文字の英字を除き、２つの７文字パスワードを解読すればよいことを物語っている。

　その上、LAN Managerはパスワードハッシュの盗聴に弱い欠点も持つ。盗聴は、攻撃者にユーザパスワードを提供してしまう。

W6.2:影響範囲

　Windows NTおよびWindows 2000

W6.3:CVE番号

なし

W6.3:問題の確認方法

　NTおよび2000のデフォルトインストールで利用している場合、LAN Managerハッシュがデフォルトで作られた以降は問題を持っている。

　（雇い主から特定の書面による許諾を得た上で）自動化されたパスワード解読ツール（l0phtcrack v3など）をテストすることでパスワードの強度を確認できる。

W6.4:対処方法

　LMHashのパスワード解読に対する防御法は２種類存在する。

　一つは、ネットワーク上でのLAN Manager認証を使用禁止年、NTLMv2を使用することである。

　NTLMv2（NT LanManager version 2）チャレンジ／レスポンス方法は、より強固な暗号化を用い、認証とセッションにセキュリティ対策を用いることでLan Manager（LM）の弱点を改善した。

　Windows NT 4.0のSP4以上を適用したシステム（Windows 2000を含む）では、NTLMv2のみを使用することが可能である。

　Windows NT/2000でこれを設定するレジストリキーはHKLM\System\CurrentControlSet\Control\LSA\ LMCompatibilityLevelである。

　値を３にすることで、ワークステーション、またはサーバの認証のためにNTLMv2証明を提示する。５にすることで、どんなドメインコントローラもLMおよびNTLM認証を拒否し、NTLMv2のみ受け入れるようになる。

　もし、ネットワーク中に古いシステム（例：Windows95）を使用している場合、慎重にシステムを構築する必要がある。

　古いシステムでは、Microsoft Network ClientでNTLMv2を使用できない。

　Win9Xでは、パラメータはHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibilityであり、許可されている値は０もしくは３（Directory Services Clientの場合）である。最も安全なオプションは、必要とする最小限のセキュリティレベルを満たさない古いシステムを使用しない、と言うことである。

　Microsoftのセキュリティアーティクル”How to Disable LM Authentication on Windows NT [Q147706]”は、Win9XシステムとWinNT/2000で必要となるレジストリの必要となる変更の詳細が書かれている。

　”LMCompatibilityLevel and Its Effects [Q175641]”では、上記パラメータを使用した場合の相互接続性問題について説明されている。

　Technetにある、非常に役立つもう一つのアーティクルは”How to Enable NTLMv2 Authentication for Windows 95/98/2000/NT [Q239869]”である。

　これは、NTLMv2の互換性の問題を克服するために、Windows 2000のDirectory Services Client for Windows 95/98を使用する事について述べている。

　ネットワーク上でLanManハッシュを取り去ることの問題は、ハッシュが作られ続け、SAMまたはActive Directoryに格納されてしまう、と言うことである。

　マイクロソフトは、ごく最近、LanManハッシュの作成を行わないようにする新しいメカニズムを利用できるようにした。

　Windows2000で、次のレジストリキーに移動する。
　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LsaOn
　そして、RegEdit32もしくはRegEditの編集メニューでNoLMHashというキーを追加する。

　その後、レジストリエディタを終了し、コンピュータを再起動する。

　ユーザがパスワードを変更するときに、LanManハッシュを全く作成しない。もし、このキーがWindows2000 ドメインコントローラに作成されているならば、LanManハッシュは作成されず、Active Directoryで保存もされない。

　Windows XPでは、レジストリ値をセットすることで同様の機能を使用することができる。

　Hive:HKEY_LOCAL_MACHINE、Key:System\CurrentControlSet\Control\Lsa、Value:NoLMHash、Type:REG_DWORD、Data:1

　これは、Windows2000でNoLMHashキーを作成するのと同様の効果を持つ。これらの詳細の変更については、マイクロソフトKnowledgeBase Article Q299656を参照のこと。

Unixシステム固有の問題

U1:RPCサービスのバッファオーバーフロー

U1.1:概要

　リモートプロシジャコール（RPC）は、あるコンピュータが別のコンピュータ上でプログラムを実行することを可能にする機能である。

　これらは、NFSファイル要求やNISのようなアクセス網サービスなどに広く使用されている。

　RPCの欠点に起因する複数の脆弱性が見つけられている。RPCの脆弱性を利用して攻略されたコンピュータを利用し、１９９９年から２０００年初頭に分散DoS攻撃が実行されたという証拠が確認されている。

　また、アメリカ軍用システムに対する広範囲な攻撃が成功したのも、RPCの欠点を利用しており、何百もの国防総省のシステムに対して行われた。

U1.2:影響範囲

　ほとんどのUnixシステム

U1.3:CVE番号

　CVE-1999-0003, CVE-1999-0693, CVE-1999-0696, CVE-1999-0018, CVE-1999-0019, CVE-1999-0704, CAN-2001-0236, CVE-2000-0666

U1.4:問題の確認方法

　一般的に攻撃対象とされうる３つのRPCサービスのいずれかを実行しているかどうかを確認する。
　RPCプログラムが必要なエラーチェックを行っていないため、バッファオーバーフロー攻撃が成立してしまい、結果、これらのサービスは攻略される。

　バッファオーバーフローの問題は、攻撃者が、プログラムに想定されていないデータを送信する時、プログラムが貧弱なエラーチェックしか行っていない場合、実行可能なデータを送信、実行するのを許してしまうことによる。

U1.5:対処方法

　RPCへの攻撃に対しシステムを防御するためには以下のステップを実行することが必要である。
  1. 可能ならば、インターネットから直接アクセス可能なコンピュータではこのサービスを停止するか削除する。
  2. RPCが必要ならば、最新のパッチを適用する。
  3. 定期的に新しいパッチが出ていないか検索し、新しいパッチが出来次第それを適用する。
  4. 境界ルータもしくはファイアウォールでRPCポート（111）をブロックする。
  5. RPCループバックポート（32770-32789）をブロックする。
　３つの主要なRPCの脆弱性のそれぞれについてに関するドキュメントは以下にある。

U2:Sendmailの脆弱性

U2.1:概要

　Sendmailは、UnixおよびLinuxシステムにおいて、電子メールの配送を処理している最も多数のプログラムである。

　Sendmailがインターネット上で広範囲に使用されているということは、攻撃者がこれを主要なターゲットとすることを意味する。

　いくつかの欠点は長年にわたって発見されている。実際、１９８８年にCERT/CCが発表した最初の報告は、Sendmailの攻撃可能な欠点についてであった。

　攻撃手法の最大の共通点は、攻撃者がSendmailが実行されているコンピュータに巧みに作られたメールメッセージを送り、Sendmailはそのメッセージを、犠牲となるマシンのパスワードファイルをパスワード解読に使用できるように、攻撃者のマシン（もしくは他の犠牲マシン）に送信するように要求する命令と解釈してしまう。

U2.2:影響範囲

　ほとんどのバージョンのUnixとLinux

U2.3:CVE番号

　CVE-1999-0047, CVE-1999-0130, CVE-1999-0131, CVE-1999-0203, CVE-1999-0204, CVE-1999-0206

U2.4:問題の確認方法

　Sendmailは、多数の脆弱性が発見されているため、頻繁にアップデートしたり、パッチを適用しなければならない。

　Sendmailの最新バージョンとパッチレベルをチェックしている必要があり、それを実行していないならば、問題がある。

U2.5:対処方法

　Sendmailを防御する手法を以下に示す。

  1. Sendmailを最新バージョンにアップデートし、パッチを適用する。
  2. メールサーバでもメールリレーでもないマシンではSendmailをデーモンモードで実行しない。

U3:BINDの脆弱性

U3.1:概要

　Domain Name Service（DNS）は、サーバのIPアドレスをすべて知ることなく、代わりに名前（例：www.sans.org）によってシステムを特定する重要な手段である。

　The Berkeley Internet Name Domain（BIND）パッケージは、最もよく使われるDNSの実装である。

　そして、この実装は、攻撃対象として好まれている。

　悲しいことに、１９９９年中旬の調査によると、インターネットに接続されているDNSサーバの５０％くらいが脆弱性を持つBINDを実行している。

　BINDに対する典型的な例としては、侵入者はシステムログを消去し、管理者権限を得るためにツールをインストールするというものが挙げられる。

　彼らはその後、IRCユーティリティとネットワークスキャナをコンパイル、インストールする。そして、そのツールを使ってほかの脆弱性を持つBINDを実行しているほかのシステムを見つけるために１ダース以上のクラスＢネットワークをスキャンする。

　彼らは何百ものリモートシステムを攻撃するために、侵入したホストを使用し、多くのシステムを傷つける結果となる。

　この例は、DNSのようは、偏在するインターネットサービスを提供するソフトウェアが持つ一つの脆弱性によって、ネット上に生じる混乱の可能性を示している。

　BINDの古いバージョンにも、攻撃者が許可されているないアクセス権限を入手するために使用可能なバッファオーバーフロー攻撃が可能であるという問題を含んでいる。

U3.2:影響範囲

　複数のUNIXとLinuxシステム

U3.3:CVE番号

　CVE-1999-0024, CVE-1999-0184, CVE-1999-0833, CVE-1999-0009, CVE-1999-0835, CVE-1999-0848, CVE-1999-0849, CVE-1999-0851, CVE-2001-0010, CVE-2001-0011, CVE-2001-0013

U3.4:問題の確認方法

　脆弱性を調査するためにスキャナを利用する。また、BINDのバージョンを確認する。もしくは、手動で、脆弱性があるかどうか、ファイルをチェックする。

　もし、脆弱性があるかどうか迷ったときには、脆弱性がある、と考えること。そして、システムのアップグレードを実施すること。

U3.5:対処方法

　BINDの脆弱性に対する防御は、以下のステップを労を惜しまず実施すること。
  1. DNSサーバとして認められていないすべてのシステム上では、BINDデーモン（namedと呼ばれている）を使用禁止にする。
    専門家たちは、DNSソフトウェア自体を削除することをすすめている。
  2. 許可されたDNSサーバの稼働するマシンでは、最新のバージョンとパッチレベルにアップデートすること。
  3. また、以下の報告に含まれているガイダンスに従うこと。
    NXTの脆弱性：
    QINV（逆クエリー）とNAMEDの脆弱性：
  4. 将来、発生する可能性のある、リモート攻撃に備えて、BINDを非特権ユーザで実行すること。
    （ただし、DNSが1024以下のポート番号を使用するために、プロセス実行時にはroot権限でなくてはならない。このため、ポートをバインドした後、ユーザIDを変更するようにBINDを設定しなくてはならない。）
  5. 同様の可能性のために、chroot()されたディレクトリ環境でBINDを実行すること。
  6. 許可されたホスト以外からのゾーン転送は拒否（使用禁止）とすること。
  7. DNSキャッシュに毒を注入（しかＰ注：偽りの情報をキャッシュさせること）されないように再帰とフェッチを使用禁止にすること。
  8. DNSサーバのバージョン文字列を出力しないようにすること。

U4:r-系コマンド

U4.1:概要

　システム管理のために、システムの信頼関係はUNIXでは広く使われている。会社は、しばしば一人の 管理者に対し、多数、場合によっては何百ものシステムに対しての管理を命ずることがある。

　管理者は、ログインしているシステムを便利に切り替えるために、たびたび信頼関係を利用したUNIX r系コマンドを利用する。

　r系コマンドは、システムにパスワードを入力することなくリモートシステムにアクセスすることを可能にする。

　ユーザ名とパスワードの組み合わせを必要とする代わりに、リモートマシンは信頼されたIPアドレスからアクセスしたものは誰であっても信用する。

　攻撃者が、そのような信頼関係を持つネットワーク上でマシンを手中に収めた場合、攻撃者は、そのマシンを信頼するすべてのマシンを手中に収めることになる。

　以下のr系コマンドがよく使用されている。
  1. rlogin（リモートログイン）
  2. rsh（リモートシェル）
  3. rcp（リモートコピー）

U4.2:影響範囲

　Linuxを含む大部分のUNIX

U4.3:CVE番号

　CVE-1999-0046, CVE-1999-0113, CVE-1999-0185, CAN-1999-0651

U4.4:問題の確認方法

　信頼関係は、/etc/hosts.equiv、または~/.rhostsファイルによって定義されている。

　UNIXシステム上２つのファイルを確認し、信頼関係が定義されているかどうか確認する。

U4.5:対処方法

　IPアドレスに基づく信頼関係を許可してはいけない。また、r系コマンドは使うべきではない。

　IPアドレスに基づく認証を迂回するのはあまりに容易である。

　認証は、トークンのようなより安全な手段、あるいは少なくともパスワードによる手段に基づくべきである。

　もし、r系コマンドが必要ならば、アクセスを制限し、慎重に他ネットワークとの接点を制御すべきである。

　また、rootアカウントで.rhostsファイルの作成は絶対に行ってはならない。

　他のユーザアカウントで作成された可能性のある.rhostsファイルは、UNIXのfindコマンドを使うことで探すことができる。

U5:LPD(リモートプリントプロトコルデーモン）

U5.1:概要

　UNIXにおいて、ローカルプリンターとの相互接続のためのサービスである。

　LPDは、リクエストを受けるために、TCPポート515番を利用している。

　プリントジョブを１つのマシンから他のマシンへ転送するコードを開発したプログラマは、バッファオーバーフローの脆弱性を持つエラーを作成してしまった。

　デーモンが短い間隔で非常に多くのジョブを投入されてしまったとき、デーモンは異常終了するか高い特権で任意のコードを実行してしまう。

U5.2:影響範囲

　次のシステムが影響を受ける。

U5.3:CVE番号

　CVE-1999-0032, CVE-1999-0299, CVE-2000-0917, CAN-2001-0670, CAN-2001-0668, CAN-2001-0353, CAN-1999-0061

U5.4:問題の確認方法

　この脆弱性を確認するために、脆弱性を確認できるスキャナを実行することができるし、手動によるチェックも可能である。

　手動によるチェックを行う最も簡単な方法は、LPDを実行しているかどうか確認し、そのバージョン番号を確認することである。

　もし、サーバ上で脆弱性を持つバージョンの家の一つを実行していて、パッチも適用していないということであれば、システムは脆弱性を持つ。

U5.4:対処方法

　この問題が公表された際、Sunは、パッチの作成に取り組んだ。

　これらのパッチがリリースされたなら、パッチを適用すべきである。

　パッチを適用する間、この脆弱性を利用した攻撃を防御する方法は以下のとおりである。
  1. リモートプリントを行わないのであれば、/etc/inetd.confを編集してプリントサービスを停止する。
  2. /etc/systemにあるファイルを編集して、noexec_user_stackをイネーブルにし、再起動する。付け加える行は以下のとおり。
    set noexec_user_stack = 1
    set noexec_user_stack_log = 1
  3. ネットワークポート515/TCPをブロックする。
  4. tcpd-7.6パッケージに含まれる、tcp wrapperを使用する。

U6:sadmindとmountd

U6.1:概要

　Sadmindは、Solarisシステムに対して遠隔管理を可能にする。そして、システム管理機能のためにグラフィカルユーザーインターフェースを使用できる。

　mountdはUNIXホスト上で動作し、NFSマウントの制御、仲裁を行う。

　これらのアプリケーションには、攻撃者が管理者権限を取得可能なバッファーオーバーフロー（ソフトウェア開発者のプログラミングエラーによって生じている）が存在している。

U6.2:影響範囲

　複数のバージョンのUNIX

U6.3:CVE番号

　CVE-1999-0977, CVE-1999-0002, CVE-1999-0493, CVE-1999-0210

U6.4:問題の確認方法

　これらのサービスが稼働しているかどうか、また、それらが攻撃に対して脆弱かどうか確認するためにセキュリティスキャナーを使用する。

U6.5:対処方法

  1. 可能ならば、インターネットから直接アクセスできるマシンではsadmindとmountdを停止するか削除しなさい。
  2. 最新のパッチをインストールする。
    Solarisは
    IBM AIXは
    SGIは
    Compaq（Digital UNIX）は
  3. ホスト/IPアドレスベースでexportsリストを書く
  4. 可能な場合、exportするファイルシステムは読み取り専用もしくはsetuidを無効にするよう設定する
  5. 脆弱性検証のためにnfsbugでスキャンする
　追加情報は、以下で確認可能である。

U7:デフォルトのSNMPストリング

U7.1:概要

　シンプル・ネットワーク・マネージメント・プロトコル（SNMP）は、ルータからプリンタ、コンピュータまで、ネットワークに接続されたデバイスの監視し、管理するためにネットワーク管理者によく使用されている。

　SNMPは認証メカニズムとして、暗号化されていない「コミュニティストリング」のみを使用する。

　暗号化されていないことは十分に問題だが、それよりも多くのSNMPデバイスはデフォルトのコミュニティストリングとして「public」を使用しており、一部の「賢い」ネットワーク機器ベンダーではより重要な情報のために「private」を用いている。

　攻撃者は、これらの脆弱性を利用して、ネットワークの設定を変更したり、遠隔地からデバイスをシャットダウンすることが可能である。

　SNMPトラフィックが盗聴されている場合、システムやデバイスがどの様にネットワークに接続されているかなどのネットワーク構造について知られてしまうことになる。

　侵入者は、ターゲットを選定したり攻撃方法を策定するためにこれらの情報を用いる。

U7.2:影響範囲

　すべてのUNIXシステムとネットワーク機器

U7.3:CVE番号

　CAN-1999-0517, CAN-1999-0516, CAN-1999-0254, CAN-1999-0186

U7.4:問題の確認方法

　SNMPがどのデバイスで実行されているか、確認する。

　実行されている場合、共通の脆弱性を調査するためにコンフィギュレーションファイルを確認すること。

U7.5:対処方法

　以下のステップは、SNMP攻略に対する防御を行うために役立つ。

  1. SNMPを必要としない場合、使用禁止にする
  2. SNMPを使用する必要がある場合、コミュニティ名をつけるときにはパスワードと同様のポリシーに基づいたものとする
    攻撃者が推測したりパスワードクラックが難しいものを使い、定期的に変更されていることを確認する
  3. snmpwalkを用い、コミュニティ名を確認、チェックを行う
    追加情報は以下で確認可能である。
  4. ローカルネットワーク外から調査を行ったり、デバイス管理をする必要がないならば境界ルータやファイアウォールでSNMP（ポート161/UDP）をフィルターすること
  5. できるならばMIBを読み取り専用に設定する
    追加情報は以下で確認できる。

付録A:脆弱性を持つ共通のポート

　この賞では、一般にスキャンされ、攻撃されているポートを示す。

　これらのポートをブロックすることは、境界部でのセキュリティ（包括的なファイアウォールのスペックリストではない）のための必要最小限行うべきことである。

　もっとよいルールは、使用していないすべてのポートをブロックすることである。

　そして、たとえこれらのポートをブロックされていても、侵入の試みを見つけるために頻繁に監視しなければならない。警告は、適切である。


　以下のリストでポートをブロックすることは必要なサービスを使用できなくすることもあるだろう。設定する前に、これらの推奨設定の潜在的影響を考慮してください。

　これらのポートをブロックすることは包括的なセキュリティソリューションに置き換えるものではない、と言うことを忘れないでください。

　たとえポートがブロックされるとしても、システムが正しく設定されていない場合、ほかの手段（ダイアルアップモデムからや、メールに添付されたトロイの木馬、内部犯行者など）によって攻撃者はシステムを攻撃可能である。

　
  1. ログインサービス--telnet（23/tcp）、SSH（22/tcp）、FTP（21/tcp）、NetBIOS（139/tcp）、rloginなど（512/tcpから514/tcp）
  2. RPCとNFS--Portmap/rpcbind（111/tcpと111/udp）、NFS（2049/tcpと2049/udp）、lockd（4045/tcpと4045/udp）
  3. WindowsNTにおけるNetBIOS--135（tcpとudp）、137（udp）、138（udp）、139（tcp）
    Windows 2000--上記ポート445（tcpとudp）
  4. X Window--6000/tcpから6255/tcp
  5. 名前解決--DNS（53/udp、サーバでないすべてのマシン）、DNSゾーン転送（53/tcp、外部の代理サーバ以外）、LDAP（389/tcpと389/udp）
  6. メール--SMTP（25/tcp、外部のメール中継を行わないすべてのマシン）、POP（109/tcpから110/tcp）、IMAP（143/tcp）
  7. Web--HTTP（80/tcp）、SSL（443/tcp）。ただし、公開Webサーバを除く。また、よく使用される共通の上位HTTPポート（8000/tcp、8080/tcp8888/tcpなど）をブロックするようにしたい
  8. "Small Services"--20番以下のtcpとudp、time（37/tcpと37/udp）
  9. その他--TFTP（69/udp）、finger（79/tcp）、NNTP（119/tcp）、NTP（123/tcp）、lpd（515/tcp）、syslog（514/udp）、SNMP（161/tcp、161/udp、162/tcp、162/udp）、BGP（179/tcp）、SOCKS（1080/tcp）
  10. ICMP--echo要求（pingとWindowsのtraceroute）、echo応答、時間超過、行き先不到達をブロックする。ただし、「packet to big（Type3,Code4）」はブロックしない。
    （この項目は、合法的なICMPエコー要求の使用よりも既知の悪意ある使用を防ぐ方が重要であると考えている、と仮定している。）
　これらのポートに加え、スプーフされたアドレス--外部から来る内部アドレスが使用されたパケット、プライベートアドレス、IANAが予約したアドレス--はブロックする。

　また、ソースルーテッドパケットやIPオプションのセットされるすべてのパケットもブロックする。

付録B:インターネット脆弱性リストトップ10とトップ20を作成するのに協力した専門家たち

Phil Benchoff, Virginia Tech CIRT
Tina Bird, Counterpane Internet Security Inc.
Matt Bishop, University of California Davis
Chris Brenton, Dartmouth Inst. for Security Studies
Lee Brotzman, NASIRC Allied Technology Group Inc.
Steve Christey, MITRE
Rob Clyde, Symantec
Eric Cole, SANS Institute
Scott Conti, University of Massachusetts
Kelly Cooper, Genuity
Igor Gashinsky, NetSec Inc.
Bill Hancock, Exodus Communications
Shawn Hernan, CERT Coordination Center
Bill Hill, MITRE
Ron Jarrell, Virginia Tech CIRT
Christopher Klaus, Internet Security Systems
Valdis Kletnieks, Virginia Tech CIRT
Clint Kreitner, Center for Internet Security
Jimmy Kuo, Network Associates Inc.
Scott Lawler, Veridian
Jim Magdych, Network Associates Inc.
Dave Mann, BindView
Randy Marchany, Virginia Tech
William McConnell, Trend Consulting Services
Larry Merritt, National Security Agency
Mudge, @stake
Ron Nguyen, Ernst & Young
David Nolan, Arch Paging Stephen Northcutt, SANS Institute
Alan Paller, SANS Institute
Ross Patel, ViaCode Ltd and Afentis Security Team
Hal Pomeranz, Deer Run Associates
Chris Prosise, Foundstone Inc.
Jim Ransome
RAZOR Research - BindView Development
Martin Roesch, Snort
Vince Rowe, FBI, NIPC
Marcus Sachs, JTF-CNO US Department of Defense
Tony Sager, National Security Agency
Bruce Schneier, Counterpane Internet Security Inc.
Gene Schultz, Lawrence Berkeley Laboratory
Greg Shipley, Neohapsis
Derek Simmel, Carnegie Mellon University
Ed Skoudis, Predictive Systems
Gene Spafford, Purdue University CERIAS
Lance Spitzner, Sun Microsystems, GESS Team
Wayne Stenson, Honeywell
Jeff Stutzman
Frank Swift
Bob Todd, Advanced Research Corporation
Jeff Tricoli, FBI NIPC
Viriya Upatising, Loxley Information Services Co.
Laurie Zirkle, Virginia Tech CIRT