訳注 草案

通常はインターネットに晒されていて攻撃を受けやすいため、高度に保護され た計算機システムであり、内部のネットワークのユーザのための主な接続点と して機能する。中世の城郭の外壁にある強固に防護された突起部 (稜堡) から 命名されている^※。

The man in the middle forgery attack depends on being able to carry out a complete conversation while claiming to be the trusted host.

マン・イン・ザ・ミドル (man in the middle) 偽造攻撃^※の成功は、 信頼されているホストの振りをしながら、 完全な対話を行うことができるかどうかにかかっている。

ipchains has a very useful feature that allows the kernel-filtering rules to be tested. The ipchains command allows you to specify IP header values to be tested against the currently loaded kernel filtering rules. Using the standard target names, the command prints how the kernel would react if the packet had really been sent to the firewall. At the time of writing, it is not possible to generate and test arbitrary packets.

ipchains では、カーネルフィルタルールをテストするこ とが可能で、これは非常に有用な機能である。ipchains コマンドを 使うと、現在ロードされているカーネルフィルタルールに対して、テストする IP ヘッダの値を与えることができる。このコマンドは、そのパケットが実際に ファイアウォールに送られた時にカーネルがどのように反応するかを標準的なター ゲット名で表示する。本書の執筆時点では、任意のパケットの発生とテストを行 うことはできない^※。

ipfilter は、別の種類の Unix 用パケットフィルタシステムである。 これは、フリーな BSD 実装 (FreeBSD、OpenBSD、NetBSD) で開発されたが、 他にも Solaris や SunOS の古いバージョン、IRIX、 Linux 等の Unix オペレーティングシステムに移植され、 動作が確認されている^※。

Ironically, the most powerful packet filtering package that Microsoft makes available for Windows NT is actually part of Microsoft's Proxy Server. While it still does not provide all of the features that a packet filtering router would provide, it does include alerting and logging options, specification of port ranges, and filtering of fragments. As of this writing, a new version of Proxy Server is due out shortly, and it is expected to have still more packet filtering features.

皮肉なことに、Microsoft が Windows NT 用に提供している最も強力なパケッ トフィルタパッケージは、実際には Microsoft Proxy Server の一部として提 供されている。これもまたパケットフィルタリングルータが提供するすべての 機能は提供しないが、警告と記録のオプション、ポートの範囲の指定、フラグ メントのフィルタ機能が含まれている。 本書の執筆時点では、近々新しいバージョンの Proxy Server が登場し、より 多くのパケットフィルタ機能を持つことが予想されている^※。

For example, you want to receive mail from the Internet, and whether that's managed by packets or by Murphy's ghost is irrelevant to you.

たとえば、あなたはインターネットからの メールを受け取りたいだけであって、それがパケットで送られて来ようと、マー フィーの幽霊^※ が運んで来ようとどちらでも構わないのである。

The "IP protocol" entries do not control UDP and TCP; if you wish to deny UDP and TCP, you must set the TCP and UDP entries to allow only specified ports and then avoid specifying any ports.

「IP プロトコル」の項目では UDP や TCP を制御できない。UDP や TCP を全部禁止したければ、TCP と UDP に関する「一部許可する」項目を設定し、 それから許可のポート指定をすべて削除する必要がある^※。

Several methods have been proposed, including using a separate TCP port for a new SSMTP protocol. Although a port has been reserved for use by SSMTP, very few mail servers support it, and it is not a standard.

いくつもの方式が提案され、その中には新しい TCP ポートで SSMTP という新しいプロトコルを利用する方式も含まれている。 SSMTP のためのポートは確保されてはいるが、 それをサポートするメールサーバはごくわずかしかなく、 標準化もされていない^※。

STARTTLS is supported by some current mail servers, but not many.

現状では、いくつかのメールサーバが STARTTLS をサポートしているが、 その数は決して多くない^※。

この代用 SMTP サーバを使用すれば、攻撃者が Sendmail やその他 の複雑な SMTP サーバに直接 SMTP で接続を行うことは決してできなくなる。 このようなシステムでは、データの内容に由来するセキュリティホールを塞ぐ ことはできないが、この種のセキュリティホールはどんなファイアウォールで あっても防御が極めて困難である。とはいえ、Sendmail にデータに由来する のセキュリティホールが見つかるのは幸いにも非常に稀で、実際、現在までに たった1つの実例しか存在しない^※。

今でも新しい問題は発見されていないかを確認。

"Biff" is not an acronym; it is the name of the original programmer's dog, which used to bark at the mailman.

"Biff" は略語ではなく、これを最初に作ったプログラマの飼っていた犬の名 前である。この犬は郵便配達人に吠えたてる癖があった^※。

There is also a standard in progress that extends the POP protocol to allow clients and servers to negotiate the use of TLS on a normal POP connection. This is the preferred method for providing encryption for services, since it doesn't require a new port, and the supply of port numbers is limited. Unfortunately, the standard is not yet complete and support for it is not widespread.

また POP プロトコルを拡張して、クライアントとサーバが通常の POP 接続上で TLS の使用を交渉できるようにしようと標準化の作業が進めら れている。ポート番号には限りがあるが、この方法なら新規のポートが必要な いので、サービスに暗号化を提供する方式としてはこの方が好ましい。残念な がら、標準化作業はまだ完了しておらず、この拡張のサポートは普及していな い^※。

Similarly, an Internet standard is evolving that will allow IMAP to use TLS to support the encryption of messages as they pass between the server and client, but currently few servers and clients support this option. There is also an assigned port for IMAP over SSL, which is supported by a slightly larger number of clients and servers.

IMAP で TLS を使用できるようにして、サーバとクライアントの間で交わされ るメッセージの暗号化をサポートしようというインターネット標準の策定作業 が進められているが、これも同様に、この機能をサポートしているサーバやク ライアントは現在のところほとんど存在しない ^※。

NFS clients may also be vulnerable to less obvious forms of attack from NFS servers. Mounting a filesystem is a privileged operation, so NFS clients run as root. A hostile server may be able to exploit buffer overflow errors in the NFS client, causing it to run arbitrary programs. In general, this is not transparent to the user (it interferes with the ability to use whatever filesystem the client was trying to get to), and it requires an attacker with a high level of control over the server machine. In traditional fixed NFS server environments, it's not a major threat. On the other hand, the use of automounters, which are discussed in a later section, can make it an effective attack.

また NFS クライアントは、 NFS サーバからのより複雑な攻撃に対しても無防備であることがある。 ファイルシステムをマウントすることは特権が必要な操作であるから、 NFS クライアントは root として動作している^※。 悪意あるサーバが、NFS クライアントのバッファオーバーフローエラーを悪用して、 任意のプログラムを実行させられるかもしれない。 このような場合、普通はユーザも気づくだろうし (クライアントがファイルシステムにアクセスする能力を阻害する)、 攻撃者にはサーバ機の高度な制御が要求される。 伝統的な固定 NFS サーバ環境では、あまり大きな脅威ではない。 だが、後の節で述べるオートマウントを利用していると、 これが効果的な攻撃になりうる。

Originally, NFS filesystems were mounted by machines at boot time, which has some significant disadvantages. It means that at boot time, a machine has to decide what server it's going to get particular files from, and the only way to change that decision is to reboot. It also has to mount all the filesystems it might ever need. On a multi-user system, where different users want different files, this results in a lot of wasted communication as machines mount filesystems that they don't actually need. It can also result in major annoyances as machines wait around for crashed file servers, sometimes pointlessly.

元々は NFS ファイルシステムは計算機の起動時にマウントされていたが、 これには重大な欠点がある。 つまり、計算機は起動時に、 どのファイルをどのサーバから取得するかを判断しなければならず、 その判断を変更するには再起動するしかない^※。 また、後に必要になるファイルシステムをすべてマウントしなければならない。 マルチユーザシステムではユーザごとに必要なファイルが異なり、 したがって計算機が実際には必要でないファイルシステムをマウントするので、 結果として無駄な通信が大量に発生する。 さらには、クラッシュしたファイルサーバを、 時々意味もなく待つという大きな頭痛の種を産み出すこともある。

The IETF is working on a protocol called the Internet Printing Protocol (IPP), which is designed to be used across the Internet.

IETF は IPP (Internet Printing Protocol) というプロトコルの策定作業を進めている^※。

This protocol (at the time of writing) is not yet an IETF standard, and hence, SSH version 2 is still a work in progress. SSH version 2 is also in the process of becoming an IETF standard.

本書の執筆時点では、このプロトコルはまだ IETF 標 準になっておらず、したがって SSH バージョン2はまだ未完成と言える。SSH バー ジョン2を IETF 標準にするための作業が進行中である ^※。

Telnet allows a user to remotely access a command shell on another computer. Telnet is supported by most platforms on the Internet, including not only Unix and Windows NT, but even some MS-DOS and Microsoft Windows systems (which provide access to a DOS shell via a Telnet server). The major exception is the Macintosh operating system, which doesn't have a command line-oriented shell to give users access to, regardless of whether or not they're local (unless you install the Unix-style development environment, which gives you both the shell and the Telnet server).

telnet を使うと、遠隔地から他の計算機上のコマンドシェ ルにアクセスできる。telnet は インターネット上のほとんどのプラットフォーム に実装されており、Unix や Windows NT だけでなく、MS-DOS や Microsoft Windows システムにさえもサポートしているものがある (この場合、 telnet サーバ経由で DOS シェルにアクセスできる)。Macintosh オペレーティン グシステムは大きな例外で、ローカルであるか否かに関わらず、ユーザからアクセ スできるコマンド行指向のシェルはない (ただし、シェルと telnet サーバの両方 を持った Unix 風の開発環境をインストールした場合はこの限りではない) ^※。

多くの IRC クライアントが、Direct Client Connections (DCC) という機能をサポートしている。 DCC を使うと、2台の IRC クライアントが相談して直接 TCP で接続する。 最初の相談の時を除いてサーバとの通信を行う必要はない。 ほとんどの IRC サーバは、Auth プロトコルを使って ユーザの情報を取得しようとする^※。 Auth が成功しなければ接続を受け付けない IRC サーバもある。 Auth の詳細は Chapter 21 Authentication and Auditing Services に述べられている。

There are known problems with versions of BIND 4 prior to 4.9.7 and BIND 8 prior to 8.1.2 (note that this does not guarantee that later versions don't also have problems that haven't been found yet).

バージョン 4.9.7 より 古い BIND 4 と、バージョン 8.1.2 より古い BIND 8 には問題があることが知ら れている (これは決して、それ以降のバージョンに未発見の問題がないことを保証 しているわけではない)^※。

In particular, Windows 2000 consistently uses names that contain underscores. Traditionally, DNS names have been allowed to contain only letters, numbers, or hyphens (-). The underscore ( _ ) has been forbidden by the standard. In practice, most name servers did not enforce these name restrictions. Although the underscore has been theoretically forbidden for many years, name servers that do not allow underscores became popular fairly late in the development of Windows 2000. At about the same time, a push to loosen the restrictions on allowable names began. This situation has not been resolved as of this writing; a standard under discussion would allow almost any character in a DNS name, but it has not yet been accepted. In the meantime, some servers enforce strict name rules and reject names with underscores; some servers follow tradition and accept almost any ASCII character; and some servers accept even more characters, including those outside the ASCII range (for instance, accented letters). Windows 2000 minimally requires a DNS server that will allow underscores. Windows 2000 allows machine names that use other characters outside the normally permitted types, and those names may create mysterious failures unless you use a DNS server that accepts them.

特に、Windows 2000 は首尾一貫してアンダースコア (_) を含む名前を 使用している。元々は、DNS 名にはアルファベット、数字、およびハイフン (-) だけが使用を許されてきた。標準ではアンダースコア (_) が禁止されているが、 現実には、こうした名前の制限を強制しないネームサーバがほとんどだった。理屈 では何年もの間、アンダースコアの使用が禁止されてきたわけだが、実際にアンダー スコアを認めないネームサーバが普及し始めたのは、Windows 2000 の開発がもう 終わるという頃だった。それとほぼ同時期に、使用できる名前の制限を緩めようと いう動きが出始めた。本書の執筆時点では、この結論はまだ出ていない^※。 検討中の標準は DNS 名にほぼすべての文字を認めるものなのだが、まだ一般に認 められていない。今のところは、厳格な名前規則を強制してアンダースコアを含む 名前を受け付けないサーバもあり、伝統に則ってほぼすべての ASCII 文字を受け 付けるサーバもあり、もっと多く、ASCII の範囲外の文字 (たとえばアクセント付 きの文字) も受け付けるサーバもある。Windows 2000 では、少なくともアンダー スコアを認める DNS サーバが必要である。Windows 2000 は通常は許可されていな い種類の文字を使った機器名を許しているため、こうした名前を受け付けない DNS サーバを使用していると不可解な不具合に見舞われることがある。

Windows 2000 also uses a record type, the SRV record, which has not yet been standardized. A number of DNS servers support SRV, including versions of BIND starting with 4.9.6 (and all versions of BIND 8).

また、Windows 2000 は SRV レコードというレコードタイプを使用する が、これはまだ標準化されてないレコードタイプである^※。 もっとも、多くの DNS サーバが SRV をサポートしており、BIND のバージョ ン 4.9.6 以降 (および BIND 8 の全バージョン) ではサポートされている。

whois is another information-lookup protocol, much like finger. It is commonly used to obtain public information about hosts, networks, domains, and the people who manage them from various Network Information Centers (NICs), such as whois.internic.net. Sites generally don't provide their own whois server; they merely access the whois servers at the NICs. People don't expect other sites to run whois servers. whois clients are available for almost every platform and are sometimes embedded into other tools.

whois は finger とよく似た、もう1つの情報検索プロト コルである。これは、ホスト、ネットワーク、ドメイン、そしてそれを管理してい る人々の公開情報を、whois.internic.net のような様々な Network Information Center (NIC) から取得するためによく使われる^※。 一般的にサイトが 独自の whois サーバを提供するわけではなく、単に NIC にある whois サーバにアクセスするだけである。それ以外のサイトが whois サーバを動作させることは期待されていない。ほとんどすべて のプラットホームにも whois クライアントがあり、他のツールの機能 の一部として組み込まれていることもある。

Kerberos uses slightly different terminology from most authentication systems. The area of authority of a Kerberos installation is called a realm. A realm is equivalent to a Windows NT or NIS domain, and in fact Windows 2000 uses domain instead of realm. All versions of Kerberos refer to the parties involved in a transaction as principals. A principal is an entity that needs to be authenticated. In most cases, a transaction involves a user talking to a server (for instance, somebody trying to pick up mail with POP), and therefore principals are normally users and services. In some cases, something else may need to be authenticated. For instance, the principals in the transaction when a machine transfers files for diskless booting are a host and a server instead of a user and a server.

Kerberos では、他の多くの認証システムと少々異なる用語を使用する。 Kerberos の設備の権限が及ぶ範囲を realm ^※ と呼ぶ。realm は Windows NT や NIS のドメイン に相当し、実際 Windows 2000 では realm の代わりにドメインという 用語を使っている。どのバージョンの Kerberos も、処理に関わる当事者を principal と呼ぶ。principal は認証を必要とする存在のことである。 ほとんどの処理は、サーバとそこに通信しようとするユーザ (たとえば POP でメー ルを取り出そうとしている人) で構成され、このような場合には principal はユー ザとサービスである。状況によっては、認証の主体が別のものになることもある。 たとえば、計算機がディスクレス起動のためにファイルを転送しようとしている時 には、処理の principal は、ユーザとサーバではなく、ホストとサーバである。

It is updated and posted to the Firewalls mailing list (firewalls@greatcircle.com) on a regular basis.

定期的に Firewalls メーリングリスト (firewalls@greatcircle.com) に更新されたものが投稿される^※。

TIS FWTK に付属する認証サーバは、インターネットから入ってくるユー ザを認証する際のモジュール方式の解決策である。サーバは様々な認証方式を実装 しており、標準的な再利用可能パスワード (推奨しない) や、S/Key、Security Dynamics 社の SecurID カード※、 そして Digital Pathways 社の SNK-004 カード※※ などをサポートしている。さらに、サーバはモジュール方式で拡張性があり、新し い認証方式を容易に組み込めるように設計されている。

Auth is a protocol used to identify a remote user that generated a connection. The protocol is also sometimes referred to as identd, which is the name of a popular Unix daemon that implements it.

Auth プロトコルは、 接続を開始したリモートユーザの身元を確認するために使用される。このプロトコ ルは identd と呼ばれることも多いが、identd はこのプ ロトコルを実装した有名な Unix 用デーモンの名前である^※。

ftp://info.cert.org/ ※

このサイトには、CERT-CC (Computer Emergency Response Team Coordination Center) が過去に出した勧告 (この付録の後方 にある「組織」の CERT-CC の項を参照) がすべて収められている他、小規模 なツールや文書も集められている。

FIRST (Forum of Incident Response and Security Teams) は、政 府、企業、および教育機関からの、多様な計算機セキュリティインシデント対 応組織の集まりである。FIRST は、インシデントへの迅速な対応と、メンバー やコミュニティ全体での情報共有を促進するために、インシデント防止にあたっ て協力と調和を育むことを目指している。現在、FIRST には、70近い会員数が 登録されている^※。

定期的に Firewalls メーリングリストに更新されたものが投稿される^※。

この付録では、ファイアウォールの構築や保守に役立つ、 インターネット上で入手可能ないくつかのツールやパッケージについて解説する^※。

http://www.transarc.ibm.com/
http://www.openafs.org/ ※

NOCOL は、Unix システム上で動作する、システムやネットワークを 監視するパッケージで、多様な方式で様々な種類のデバイスをポーリングでき る。syslog 情報や SNMP データを使用したり、ICMP を使って機 器の動作状況を調べたりすることができる。新しい監視方式の追加も簡単で、 そのための C と perl の API が用意されている^※。

RSA は1978年に Ronald Rivest、Adi Shamir、Leonard Adleman らによって開発された。 数学的に言えば、理解のしやすさの点でも、実装の容易さからも、 ほぼ間違いなく最も単純な公開鍵アルゴリズムである。 RSA アルゴリズムの強度は、巨大な数の因数分解が困難であるということに基 づいている。 RSA アルゴリズムは特許を取得済みであるが、 このアルゴリズムを保護すると考えられている最後の特許が 2000年の9月20日で期限切れとなる^※。

Triple DES (3DES) は、 DES の処理を2つの鍵を使って3繰り返して適用する方法であり、 鍵の大きさは112ビットになる^※。 鍵の長さが増すことで、3DES は通常の DES よりも安全だと信じられている。 3DES の処理には DES の3倍の時間がかかる。

AES (Advanced Encryption Standard) は米国の NIST によって策定されている 「21世紀の暗号アルゴリズム」である。 AES は米国政府標準として DES を置き換えることを目的としている。 DES にまつわる様々な問題があったことから、 NIST はこの標準の開発の過程を公開し、 米国国外で設計されたアルゴリズムも候補とすることを決定した。 本書の執筆時点では、標準はまだ決定されていず、 Mars、RC6、Rijndael、 Serpent、Twofish という5つの最終候補に絞られている^※。

Evaluating the strength of a cryptographic algorithm can be extremely difficult. It's not unusual for people to find problems with algorithms that have been examined before by multiple professional cryptographers. However, this sort of analysis is needed only for new cryptographic algorithms. In general, a reasonably educated and suspicious person can do an adequate job of figuring out whether a cryptographic product is appropriately secure without delving into any of the details of the algorithms involved. A good resource is the "Snake Oil FAQ", published regularly on the sci.crypt newsgroup.

暗号アルゴリズムの強度を評価することは、非常に困難な場合がある。 複数の暗号専門家によっ て精査されたアルゴリズムに、問題が発見されるのは珍しいことではない。し かし、この種の分析は新しい暗号アルゴリズムが考案された時にだけ行われる。 一般に、ある程度の教養と懐疑心を持ち合わせた人であれば、ある暗号プロダ クトが十分な安全性を持っているかどうかは、そのアルゴリズムの詳細にまで 立ち入らずとも判断できるものである。sci.crypt ニュースグルー プに定期的に投稿される "Snake Oil FAQ" が、有用な情報源として役立つだ ろう^※。