ネットワーク WG
Request for Comments: 2179
分類: 情報提供
A. Gwinn
Networld+Interop NOC チーム
1997年7月

English

展示会におけるネットワークセキュリティ
(Network Security For Trade Shows)

このメモの位置づけ

このメモは、インターネットコミュニティのための情報を提供します。 これは、いかなるインターネットの基準をも規定するものではありません。 このメモの配布は制限されていません。

要旨

本書は、Networld + Interop のような展示会において、 ベンダーや他の参加者が、 認証されていない人間によってなされるネットワークやシステムへの攻撃に対して効果的な防御を設計するのを助けるために書かれています。 一般に、多くのシステム管理者や展示会のコーディネーターが、 展示会におけるシステムセキュリティの重要性を見落としがちであることが見うけられてきました。 事実、展示会におけるシステムは、 少なくともオフィスにあるプラットフォームと同等に攻撃されやすいといえます。 展示会のシステムは、 オフィスコンピュータと同等の深刻さで取り扱われる必要があります。 展示会システムのセキュリティの侵害は、 展示者のデモンストレーションを(しばしばイベント全体を!)運用できなくしてしまう可能性があり、 運用できなくなったこともあります。

本書は、数多くのインターネットセキュリティについてのわかりやすい本に置き換わるものを意図したわけではありません。 むしろ、この目的はコストのかかる攻撃の可能性を最小化するために、 しばしば見落とされてきた簡単なやり方についてのチェックリスト形式の文書を提供することにあります。 我々は、展示者が本書に対して特別の注意を払い、 これをすべての関連する代表者たちと共有することを強く薦めます。

物理的セキュリティ English

技術的なセキュリティの論点に対応する前に、 最も頻繁に過小評価されて見落とされてきたセキュリティ侵害のひとつは、 単純なローテク攻撃です。 よくある被害者は、おそらくrootでログインしたままシステムを離れる人です。 あるいは、匿名の「助っ人」の誰かが、 「問題の識別」の際にユーザを支援するためにパスワードを聞いてくるかもしれません。 この種の手法は、侵入者、 特にrootでログインした者がシステムファイルにアクセスすることを許してしまいます。

豆知識:

システムセキュリティ English

この章では、 ベンダーのネットワークにあるワークステーションのための技術的なセキュリティ手続きを検討します。 詳細についてはUnixシステム向けに書かれてはいますが、 一般的な手続きはすべてのプラットフォームに適用されます。

パスワードセキュリティ English

パスワードが無いこと、もしくは推測が容易なパスワードは、 システムへの扉としては比較的ローテクなものです。 しかし、それらは、相当数の侵入事例の原因となっています。 よいパスワードは、システムセキュリティの指標のひとつです。

Windows 95のようなPCオペレーティングシステムやMacOSは、 デフォルトでは適切なパスワードセキュリティを提供していません。 Windowsのログインパスワードには、セキュリティ機能はありません。 ("ESC"キーをたたけば、ユーザはパスワード入力を迂回できてしまいます。) このようなマシンに対して、 パスワードセキュリティを施すことは可能ですが、この文書の範疇外です。

豆知識:

超過権限アカウント English

システムベンダーには、複数の特権アカウントをもったシステム (例えば、root権限[UID=0]のアカウントをもったUnixシステム) を出荷していることが知られているところがあります。 また、ベンダーによっては、ユーザを特定の管理プログラムの中に置く、 分離されたシステム管理者アカウントをもたせている可能性があります。 各、超過権限アカウントは、濫用の可能性をもたらしてしまいます。

一般にUnixシステムが追加的なrootアカウントを必要としない場合、 "*"を/etc/passwdのパスワードフィールドに置くことか、 システムが拡充されたセキュリティを採用している場合、 管理ツールを使用することによって、それらを実行不能にすることができます。 すべてのシステムについて、超過権限アカウントがないかを検証し、 それからそれらを実行不能にするか、もしくは、 それらのパスワードを適切に変更してください。

特権アカウントが、 システムコンソール以外のどこからもアクセスすることができないことを確認してください。 しばしばシステムは、 「セキュアな」端末のリストとして/etc/securettysのようなファイルに依存します。 一般的なルールとして、端末がこのファイル中になければ、 rootログインは不可能です。 この機能の特定の使用法については、 システムのドキュメンテーションファイルの中で網羅されているはずです。

豆知識:

認証トークンの使用 English

SecureID、Cryptocard、DES Goldなどのような認証トークンは、 「ワンタイム」パスワードを生成する手段を提供します。 展示会環境において原則的に有利な点は、無造作に、 ネットワーク上のスニッファによって捕捉されるパケットを提供してしまうことです。 (特に大きなネットワーク関連の展示会においては)多くのパケットスニッファや、 他の管理ツールが、常時、 (正規に)ネットワークを監視していることを事実として扱う必要があります。 打ち込まれたパスワードは、デフォルトでは、 ネットワーク上を平文で送られるので、 他人がそれらを見ることができてしまいます。 認証トークンは、1回だけ有効で、以降は無価値なパスワードを提供します。 認証トークンの利用の論理的発展は、 サイト外でのセキュリティ問題の可能性を最小化するために「出先から本拠地へ」(展示会のネットワークから本拠地のサイトへ)それらを使用することでしょう。

このようなトークンの代替として、 クライアントとサーバー間の暗号化されたコネクションを提供するsecure shell ("ssh")プロトコルがあります。 このコネクションは、ログインのトラフィックと、 任意の「ポート to ポート」コミュニケーションの両方を運ぶことができ、 ブース内のネットワークと、 リモートシステムへ(/から)のコミュニケーションをセキュアにするための強力なツールです。

豆知識:

Anonymous FTP English

Anonymous FTPアカウントは、容易にセキュリティホールに転じえます。 別段必要でない場合、このサービスを実行不能にしてください。 anonymous FTPを使用する予定のあるイベントにおいては、 下記の豆知識がそれをセキュアにするのに役立つことでしょう。

ネットワークファイル共有 English

何らかのセキュリティをも持たない書き込み可能なファイル共有は、 情報の破壊やデモンストレーションを招待しているようなものです。 Unixシステム上のNFSと、CIFS、AppleShare、NetWareのようなPC共有機能の、 いずれを使用しているのいずれを使用しているのであろうと、 エクスポートされているファイルのセキュリティに、 よく注意する必要があります。 展示会においては、誰かのコンペティションは、 しばしば同一のネットワークを共有していることを覚えておいてください! 読み書き両方のアクセスのためのセキュリティが採用される必要があり、 各アクセスポイントが検査される必要があります。

書き込み可能なNFSファイルシステムを世界中にエクスポートすることによって、 エクスポートされたマウントポイント内にあるいかなるファイルでも読み書きできるようにしてしまいます。 これが行われた場合、 例えば、"/"もしくは"/etc"のようなシステムディレクトリについて、 自身がシステムへのアクセスできるようにするためにパスワードファイルを編集することは簡単なことです。 それゆえ、/etc/exportsは、取り扱い注意のものが、 トラステッドホスト以外にエクスポートされないように、 よく検査される必要があります。 一般公衆にエクスポートされるものはすべて、 「読み取り専用」でエクスポートされ、 ファイル共有経由で入手可能な情報は検証される必要があります。

豆知識:

トラステッドホスト English

トラステッドホストのエントリは、 他のホストであるコンピュータに対する「等価な」アクセスを他のホストに許可する手法のひとつです。 ベンダーによっては、 オープンなトラステッドホストファイルをもったシステムを出荷しているところがあります。 この論点が対応されていることを確認してください。

豆知識:

SetUIDやSetGIDの実行ファイル( Unix システム) English

Unixシステムでは、 システム実行可能プログラムの"suid"ビットは、 そのプログラムが所有者権限で実行されるようにします。 "root"にsetUIDされているプログラムは、 そのプログラムがroot特権で実行することができるようにしてしまいます。 プログラムにはroot特権をもつ、複数の正当な理由があり、 実際にroot特権をもっています。 しかし、個々のユーザディレクトリ中、もしくは、 他の非システム領域にsuidプログラムがあることは不自然でしょう。 ファイルシステムのスキャンは、 いかなるsuidもしくはsgidビットセットをもったプログラムをも発見することができます。 いかなるプログラムもそれを実行不能にする前に、 そのファイルが正規のものであるかをチェックしてください。

豆知識:

システムディレクトリの所有権と書き込み権限 English

すべてのシステムディレクトリの所有者と、 ファイルに書き込むのに必要なパーミッションをチェックしてください。 Windows NTのようなPC OS(オペレーティングシステム)上では、 ひたすらすべてのファイルやディレクトリをチェックするか、もしくは、 ACLをリストする"ls"のようなものを使用する以外に、 これを行う簡単なやり方はありません。

Unixシステムにおいては、 (/tmpのように)"drwxrwxrwx"のようなパーミッションをもつディレクトリは、 世界中の人が書き込め、 誰でもそのような領域にファイルを作成・変更することができます。 "/"と"/etc"には特別な注意を払ってください。 これらは個々のユーザではなくシステムアカウントによって所有される必要があります。 疑わしい場合、 そのシステムソフトウェアのベンダーに適切なディレクトリ、 もしくはファイルの権限を確認するために問い合わせてください。

ネットワークサービス English

すべての不要なサーバーは、実行不能にする必要があります。 悪名高き"R services"(rexec、rsh、rlogin)は、 セキュリティ問題に特に弱く、 特別に必要でない限り実行不能にする必要があります。 トラステッドホストファイルに対して特別の注意を払い、 トラステッドホストを装うマシンからのIPスプーフィング攻撃のリスクを知っておいてください。

豆知識:

TFTP (Trivial File Transfer Protocol)English

TFTPは侵入者にとって、 システムファイルにアクセスするための楽なやり方になりえます。 TFTPを実行不能にすることは、一般に良い実践慣行です。 TFTPが必要な場合、 エクスポートしようとしたファイルだけがアクセス可能であることを検証してください。 セキュリティをチェックする簡単なやり方は、 システムファイルのアクセス可能性をチェックするために/etc/passwdもしくは/etc/motdのようなファイルについてtftpを試してみるです。

TCP接続監視 English

パブリックドメインソフトウェア(TCP WrappersもしくはUnixシステム用の"tcpd")で、 ホストへのTCPコネクションをホスト単位で制限し監視することができます。 システムは、 認可されていない主体が当該ホストにアクセスしようとしたらシステム管理者に通知し、 syslogをとるように設定することができます。 このソフトウェアは、下記より入手することができます。:

BIND (Berkeley Internet Name Daemon) English

初期のバージョンのBINDは、様々な攻撃に弱かったといえます。 ホストをDNSとして動かす場合、最新版のBINDを使用してください。 これは下記より入手可能です。:

Sendmailとメーラーのセキュリティ English

数多くの以前のバージョンのSendmailは、 既知のセキュリティホールをもっています。 インストールされたsendmailが最新版のものであるかをチェックしてください。 あるいは、 そのプラットフォーム用の最新リリースするためにOS(オペレーティングシステム)のベンダーに問い合わせてください。

Web サーバースクリプティングのセキュリティ English

すべてのWebサーバースクリプトと実行ファイルは、 (特に"...httpd/cgi-bin"ディレクトリ)シェルコマンドが実行できてしまうものがないかチェックされる必要があります。 ここ数ヶ月の多くの攻撃は、 標的システム上の/etc/passwdにアクセスために、 "phf"のようなユーティリティの利用に集中していました。 Webサーバーの運用上、不要なスクリプトをすべて削除してください。

その他の示唆

一般的なネットワークセキュリティ English

想像されるように、 (規模の大小に関わらず)ネットワーク展示会では、 多くの人がパケットスニッファを動かしています。 大部分は、製品のデモンストレーションのために、 正当な理由でそれらを動作させる必要のある出展者です。 しかし、多くの「聞き耳」がネットワークセグメント上にあることを知っておいてください。 (誰もが情報を、 それがネットを通過する際に「聞くこと」もしくは「見ること」ができるのです。) 特に盗聴に弱いのがtelnetセッションです。 これについて、よい経験則があります。 「あなたのパスワードを入力する際に、それを見ないのはあなただけ!」

可能である限り、 ネットワーク越しに特権でアカウントにログインしないこと (あるいは"su"しないこと)は、よい実践慣行です。 前述のとおり、認証トークンやsshは、 システムアカウントアクセスにセキュリティを追加する簡単なやり方です。

パケットフィルタリング English

多くのルーターは、基本的なパケットフィルタリングをサポートしています。 ルーターが、 そのローカルネットワークと展示会のネットワークの間に設置可能な場合、 一般的、基本的なパケットフィルタリングが採用される必要があります。 下に、よい「一般的な」パケットフィルタのアプローチを掲げます。 このアプローチ自体は、分野ごとに並べられています。:

あなたが許容できるかを知らないトラフィックをすべて拒否する論理に基づくことは、 フィルタルールセットについてのよいアプローチであり、 実行する際の重要性の高い順に述べるならば、下記のようになります。:

一般的なグローバルな拒否/許可

  1. インターフェイスにおいてスプーフ(詐称)されたアドレスをフィルタする。 ソースアドレスを、 インターフェイスで入手可能なルーティング情報と比較し一致を確認する。 ひとつのインターフェイスに(例:外部から)到着したソースアドレスが、 他のインターフェイス上(内部)のソースアドレスをもっているパケットを拒否する。
  2. 特段、ソースルーティングが必要でないかぎり、 すべてのソースルーティングされたフィルタする。
  3. 「内部の」ホストからの外部へのコネクションを許可する。
  4. 確立されたTCPコネクションを許可する。 (プロトコルフィールドが6で、 TCPフラグフィールドがACKであるかSYNでないか)「新しい」コネクションの要求だけをフィルタする。
  5. ソースポートが25の「新しい」コネクションをフィルタする。 誰かがリモートのメールサーバーであるかのように振舞うことを防ぐ。
  6. ループバックアドレス(ソースアドレス127.0.0.1)をフィルタする。 誤った設定のなされたDNSリゾルバからのパケットを防ぐ。

特定のグローバルなサービス拒否

  1. すべての"R-command"ポートを個別にブロックする。 (デスティネーションポート512-515 )
  2. 外部からtelnetアクセスを必要としないすべてのホストからのtelnet (デスティネーションポート23)をブロックする。 (ssh を使用する場合、全てのホストから、 これをブロックすることができます!)
  3. 当該ネットワークにおいて必要に応じて、 他の特定のプロトコルを拒否するフィルタを個別に追加する。

特定のホスト/サービス許可

  1. 特定の「公開」ホストのサービス(セキュアでないFTPもしくはWWWサーバー)への特定のアクセスを追加する。
  2. 電子メール用に、 メールサーバーへのSMTP(ソースポートとデスティネーションポート25)を許可する。
  3. FTPサーバーへの内向きのFTPコネクション(ソースポート20)を許可する。
  4. ネームサーバーへのDNS(ソースポートとデスティネーションポート53、 UDP & TCP)を許可する。 ゾーン転送が不要な場合、そのTCPポートをブロックする。
  5. 適切である場合、 RIPパケットの流入(ソースポートとデスティネーションポート520、 UDP)を許可する。
  6. 他の拒否された特定のプロトコルを許可するため、もしくは、 特定のマシンへの特定のポートを開くために、個別のフィルタを追加する。

最終的なサービスの拒否

  1. 上記のフィルタによって許可されていない、 すべての他のUDPとTCPサービスを禁止する。

著者のアドレス

R. Allen Gwinn, Jr.
Associate Director, Computing
Business Information Center
Southern Methodist University
Dallas, TX 75275

電話: 214/768-3186
EMail: allen@mail.cox.smu.edu or allen@radio.net

Contributing Writer

Stephen S. Hultquist
President
Worldwide Solutions, Inc.
4450 Arapahoe Ave., Suite 100
Boulder, CO 80303

電話: +1.303.581.0800
EMail: ssh@wwsi.com

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail: miyakawa@ipa.go.jp


Copyright (C) The Internet Society (1997). All Rights Reserved.