English

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

このメモの位置づけ

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

要旨

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

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

物理的セキュリティ English

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

豆知識：

• 営業とサポートのスタッフにシステムへのログインについて教育する。特に、"root" もしくは他の特権アカウントについて教育する。
• 意図した目的のために展示システムを使用していない人間、特にブースの人でない者を識別する。
• 識別されている人以外には、すべてのメンテナンス目的でシステムにアクセスしようとしている人から識別を求める。

システムセキュリティ English

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

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

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

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

豆知識：

• Unix システムの /etc/passwd や、他のシステムで動作するユーザが管理するアプリケーションについて、パスワードの存在をチェックする。ベンダーによってはシステムを null パスワードで出荷しており、場合によっては特権アカウントであることさえある。
• パスワードを変更する。特にシステムと root のパスワード。
• カッコ、数字、句読点を混ぜる。特に特権アカウントについて。
• 定期的にパスワードを変更する。
• そのイベント、その会社もしくは展示されている製品に関連するパスワードを使用しない。Networld+Interop にいるシステムの人間は、ブースの人に支援を頼まれると、しばしば root パスワードさえ推測 してしまいます！

超過権限アカウント English

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

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

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

豆知識：

• Unix システム上の /etc/passwd や、他のシステム上のユーザ管理アプリケーションに、追加的な特権アカウントがないかチェックせよ。
• 特権アカウントについて、リモート ログインを実行不能にせよ。
• すべての不要な特権アカウントを実行不能にせよ。
• 「セキュアな」端末、もしくはシステム コンソールに対する root アカウントによるログインを制限せよ。

認証トークンの使用 English

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

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

豆知識：

• 特定の環境、または特定のプラットフォームにインテグレートする方法に関するより詳細な情報については、認証トークン／カードのベンダーに問い合わせる。
• パブリック ドメインユーティリティ "cryptosu"（ csu ）は、 Cryptocard とともに使用すると、Unix の "su" コマンドの代替機能を 提供し、チャレンジ／レスポンス スタイルの認証を root アクセスに 採用する。
• ssh クライアントとサーバーの利用に挑戦する。

Anonymous FTP English

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

• ユーザが "anonymous" としてログインする場合、特定のディレクトリツリー内にロックされる必要がある。FTPd が正しく適切なディレクトリに chroot していることを確認する。"cd /" は、匿名ユーザを "public" ツリーのトップにつれていく必要があり、システムの root ディレクトリにつれていってはならない。
• システムによっては、ユーザを許可されたツリーの外につれていく シンボリック リンク（もしくは「ショート カット」）を許すものも ある。anonymous FTP 階層内のすべてのリンクを検証する。
• ftp の root ディレクトリが、'ftp' アカウント以外の誰かによって 「所有されている」ことを確認する。典型的には、これは "root" に よって所有されている必要がある。
• 絶対に必要でない限り、世界中の誰でも画書き込める入力ディレクトリを使用してはならない。多くのサイトでは、これらをユーザがファイルをサイト内に転送する手段として利用している。これは（盗人コミュニティ によって "warez" と呼ばれる）盗まれたソフトウェアのアーカイブに転じてしまうことがあり得るとともに、しばしばそのようになる。
• ディレクトリパーミッションから読む権限をなくすこと（Unix システムにおいて chmod 733）は、匿名ユーザがカレントディレクトリのコンテンツをリストできることを阻止する。ファイルは、通常どおり置くことができるが、ユーザが正確なファイル名を知らない限り、取り出すことはできない。

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

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

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

豆知識：

• 必要でない限りファイル共有スペースを提供しない。
• どこにエクスポートされた情報が「見える」かを検証する。
• いかなる書き込み可能な共有も絶対に必要でない限り維持管理しない！

トラステッドホスト English

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

豆知識：

• Unix システムでは、/etc/hosts.equiv と、すべての ".rhosts" ファイル（複数の .rhosts ファイルが存在しうる) に '+' エントリ （すべてのシステムを信頼する）がないかをチェックし、これを削除 する。
• "...X11/xdm/Xsession" ファイルの中に "xhost +" エントリがないか をチェックする。通常、"xhost" エントリは、 "/usr/local/lib/xhost +" のようなパス名とともにある。これを 削除する。

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

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

豆知識：

• "find / -user root -perm -4000 -print" は、NFS でマウントされたパーティションを含めて、システム中のどこにある setuid ファイル でも発見する。
• "find / -group kmem -perm -2000 -print" は、kmem グループパーミッションについて同様のことをする。

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

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

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

ネットワークサービス English

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

豆知識：

• Unix システムにおいては、/etc/inetd.conf にある "R services" (rexec, rsh, rlogin) をコメント アウトする。
• 他のよくわからない、もしくは不要なサービスがないかチェックする。

TFTP （Trivial File Transfer Protocol） English

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

TCP 接続監視 English

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

• ftp://info.cert.org/pub/tools/tcp_wrappers/

BIND (Berkeley Internet Name Daemon) English

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

• ftp://ftp.isc.org/isc/bind

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

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

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

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

その他の示唆

• OS（オペレーティングシステム）のベンダーに、既知のセキュリティの論点がないかチェックする。すべてのシステムに最新バージョンのソフトウェア（ 特に特定の問題を解消するためのセキュリティパッチ ）が入って いることを確認する。
• 定期的に、ホスト上の log ファイルを吟味する。Unix システムにおいては　"last" コマンドが最近のログインや、どこから来たのか、についての情報を提供します。"syslogs" もしくは "Event Viewer" は、より 詳細なシステム イベントの情報に関連します。
• Web サーバーの log ファイル（...httpd/log/access_log と ...httpd/log/error_log ）は、誰が WWW サーバーにアクセスしたか、何がアクセスされたか、何が失敗したか、の情報をもっています。
• 上手なバックアップは、システムダメージに対する最善の防衛策です。システムを展示会のネットワークに設置する前にバックアップを行い、その後も展示会の期間中、バックアップを続け、さらにイベント後にバックアップします。最後のバックアップセットは、システムセキュリティの突破の試みの可能性（あるいは成功）がないかを吟味するのに有用です。

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

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

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

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

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

• 一般的なグローバルな拒否／許可
• 特定のグローバルなサービス拒否
• 特定のサービス許可
• 最終的な他の全ての TCP/UDP サービスの拒否

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

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

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.