path: root/ja_JP.eucJP/man/man7/security.7

.\" Copyright (c) 1998, Matthew Dillon.  Terms and conditions are those of
.\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in
.\" the source tree.
.\"
.\"	%Id: security.7,v 1.4.2.1 1999/04/01 02:10:38 ghelmer Exp %
.\"
.\" jpman %Id: security.7,v 1.3 1999/02/11 11:18:48 vanitas Stab %
.Dd December 20, 1998
.Dt SECURITY 7
.Os
.Sh 名称
.Nm security
.Nd FreeBSD におけるセキュリティ入門
.Sh 解説
.Pp
セキュリティは、システム管理者とともに始まり、システム管理者と
ともに終る機能です。
.Bx
システムは昔からすべてマルチユーザに対応しています。セキュリティの仕組みを
組み込んで維持することで、ユーザを
.Sq 正直に
し続ける仕事は、システム管理者の最も大きな責務の一つでしょう。マシンは、
管理者が設定しただけのセキュリティしか示しません。セキュリティに関する
問題は、むしろ、便利さを求める人間との競合問題です。一般に、
.Ux
システムは莫大な数のプロセスを同時に実行させることができ、
それも、サーバとして動作するものが多いのです。つまり、外部の何者かが
接続してきて、サーバプロセスと会話することができるということなのです。
昨日まで使われていたミニコンピュータやメインフレームは、今日では
デスクトップコンピュータが取って代わり、しかも、それらはネットワークで結ばれて
インターネットと接続されるようになりました。これにより、セキュリティは
昔と比べてはるかに大きな問題となっています。
.Pp
セキュリティに関する問題は、いくつかのカテゴリに分類することができます。
.Bl -enum -offset indent
.It
サービス不能攻撃
.It
ユーザアカウントにかかる危険
.It
アクセス可能なサーバを経由した root 権限にかかる危険
.It
ユーザアカウントを通した root 権限にかかる危険
.El
.Pp
サービス不能攻撃とは、マシンから必要な資源を奪う行為です。
サービス不能攻撃は、普通は、そのマシンで実行されるサーバや
ネットワークスタックを圧倒して、マシンをクラッシュさせたり、
さもなければマシンを使えなくしたりするような力任せの方法です。
サービス不能攻撃のいくつかは、
ネットワークスタックのバグを利用して、パケット一つでマシンを
クラッシュさせようとします。後者は、
カーネルにバグ修正を施すことによってのみ修正することができます。
サーバプロセスに対する攻撃は、サーバのオプションを適切に指定して、
不利な状況にあるシステムにおいて、サーバプロセスが引き起こす負荷に限界を設けることで
修正することができます。これらに比べると、ネットワークへの力任せの攻撃への
対応はずっと難しくなります。たとえば、偽造パケットによる攻撃
.Pq spoof-packet attack
は、インターネットからシステムを切り離す以外の方法で防ぐことは
ほとんど不可能です。
.Pp
ユーザアカウントを危険に晒してしまう問題は、サービス不能攻撃よりもずっとよくある
問題です。このご時勢でも、自分たちのマシンで標準の telnetd, rlogind, rshd, ftpd 
サーバを実行させているシステム管理者は多いのです。これらの
サーバは、デフォルトでは、暗号化されたコネクション上で動作していません。
その結果、抱えているユーザ数が標準くらいであれば、リモートログイン
.Po
そのシステムにログインするには最も普通で便利な方法です
.Pc
しているユーザのうち一人以上は、パスワードを覗き見られて
しまうでしょう。
システム管理者が注意深い人ならば、たとえログインが成功していたとしても、
リモートアクセスログをときどき解析して、疑わしいソースアドレスを探すものです。
.Pp
ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると、攻撃者が
root の権限を破る可能性があることを仮定するべきです。しかし、
セキュリティを十分維持し、手入れの行き届いたシステムにおいては、
あるユーザアカウントへのアクセスが可能となっても、攻撃者に必ずしも
root へのアクセス権を与えるとは限らないのが現実です。この違いは重要です。
というのは、root へのアクセス権がなければ、一般的に、攻撃者は自分の
侵入の痕跡を隠蔽することができませんし、そのユーザのファイルを消して
マシンをクラッシュさせることができるのがせいぜいで、他のユーザの
ファイルには手出しできません。
.Pp
システム管理者は、あるマシン上で root の権限を破る方法がいくつかあることを
心しておかねばなりません。攻撃者が root のパスワードを知ってしまうかも
しれません。攻撃者が root の権限で実行されるサーバのバグを見つけ、
ネットワークからそのサーバへ接続して root の権限を破ることができるかも
しれません。ひとたびユーザアカウントを破ると、ユーザアカウントから
root の権限を破ることが可能であるというバグを持つ suid-root プログラムの
存在を、攻撃者は知っているかもしれません。
.Pp
セキュリティを改善する方法は、常に、
.Sq タマネギの皮剥き
のように
複数の層のアプローチで実装されます。これらは次のように分類できます。
.Bl -enum -offset indent
.It
root とスタッフのアカウントの安全性を高める。
.It
root の安全性を高める - root 権限のサーバと suid/sgid バイナリ。
.It
ユーザアカウントの安全性を高める。
.It
パスワードファイルの安全性を高める。
.It
カーネルのコア、raw デバイス、ファイルシステムの安全性を高める。
.It
ファイルの完全性のチェック: バイナリ、設定ファイルなど。
.It
偏執狂的方法。
.El
.Sh root アカウントとスタッフアカウントの安全性を高める
.Pp
root のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性を
うんぬんしてもしかたがありません。ほとんどのシステムでは、root アカウントに
割り当てたパスワードがひとつあります。まず最初にすべきことは、
このパスワードは
.Sq いつでも
危険に晒されていると仮定することです。root アカウントの安全性を確保する
ためには、ネットワーク越しに、あるいはどれか一般ユーザのアカウントから、
root のパスワードを使って root アカウントにログインすることが決して
できないことを確認することです。正しいパスワードが与えられようが
与えられまいが、telnetd, rlogind, その他ログイン処理を行なうサーバ
すべてで root でのログインを拒絶するように設定していないのであれば、
今すぐ必ず設定して下さい。直接 root でログインできるのは、
システムコンソールからだけにして下さい。ここで役に立つのが
.Sq /etc/ttys
ファイルです。ほとんどのシステムでは、デフォルトで安全ですが、
優れたシステム管理者は、設定がそうなっているか常にチェックを怠らない
ものです。
.Pp
システム管理者として、自分は root になれるようにしておかねばならないの
はもちろんですから、穴をいくつか空けておきます。しかし、それらの穴を
動作させるには、さらに追加のパスワード認証が必要であるようにして
おきます。root でアクセス可能とする方法の一つとして、
適切なスタッフアカウントを
.Pq Pa /etc/group の
wheel グループに加えることがあります。
wheel グループに置かれたスタッフメンバには、
.Sq su
を使って root になることが許されます。スタッフメンバに、
パスワードファイルのエントリでそのまま wheel のアクセス権を
与えてはいけません。スタッフは、
.Sq staff
かその類のグループに置き、その中で本当に root になる必要がある人
だけを wheel グループに加えるようにします。しかし、残念ながら、wheel の
仕組みだけだと、侵入者は、パスワードファイルを手に入れると root 権限を
破ることができてしまいます。攻撃者が破る必要があるのは root のパスワード
か、wheel グループにたまたま属するstaff アカウントのパスワードどれかひとつだけだからです。
wheel の仕組みは有益ですが、wheel グループがまったく存在しない状況と比べてそれほど
安全なわけではありません。
.Pp
root アカウントの安全性を高める間接的な方法として、別のログインアクセス
の方法を用いて、スタッフのアカウントの暗号化パスワードを\ * にして
おくことで、スタッフのアカウントの安全性を高めるものがあります。この方法
だと、侵入者がパスワードファイルを盗むことができるかもしれませんが、
スタッフアカウントを破ることはできないでしょう。また、たとえ root が暗号化
パスワードをパスワードファイルに付けていたとしても、間接的には root
アカウントも破ることができないでしょう。
スタッフメンバがスタッフアカウントでログインする際には、
.Xr kerberos 1
や
.Xr ssh 1
.Po
.Pa /usr/ports/security/ssh
参照
.Pc
のような、公開鍵 / 秘密鍵の鍵の組を使う
安全性の高いログインの仕組みを使います。kerberos のような仕掛けを使う場合、
一般に、kerberos サーバを実行するマシンと自分のデスクトップ
ワークステーションとの安全性を確保しなければなりません。ssh で
公開鍵 / 秘密鍵の組を使う場合、一般に、ログイン元マシン
.Pq 通常は自分のワークステーション
の安全性を確保しなければなりません。ここで、
.Xr ssh-keygen 1
で公開鍵 / 秘密鍵の組を生成する際、鍵の組をパスワードで防御することにより、
鍵の組への防御層を追加することもできます。スタッフアカウントの
パスワードを\ * で外すことができると、管理者自身が設定
した安全性の高い方法でしかスタッフメンバがログインできないことも保証
できます。こうして、多くの侵入者が使う重大なセキュリティの穴
.Pq 安全性の低い無関係なマシンからネットワークを覗き見る方法
を塞ぐようなセッションを提供する、安全性の高い暗号化されたコ
ネクションを使うことを、スタッフメンバ全員に強制することができ
るのです。
.Pp
より間接的なセキュリティの仕組みでは、制限の強いサーバから制限の弱い
サーバへログインすることを前提としています。例えば、メインマシンで、
様々な種類のサーバを実行させている場合、ワークステーションではそれらの
サーバを実行させてはなりません。ワークステーションを十分に
安全にしておくためには、実行するサーバの数を、一つもサーバ
が実行されていないというくらいにまでできる限り減らすべきです。
また、パスワードで保護されたスクリーンセーバを走らせておくべきです。
ワークステーションへの物理的アクセスが与えられたとすると、もちろん
言うまでもなく、攻撃者は管理者が設定したいかなる種類のセキュリティ
をもうち破ることができるのです。これは、管理者として必ず考えておか
ねばならない問題ですが、システム破りの大多数は、ネットワーク経由で
リモートから、ワークステーションやサーバへの物理的アクセス手段を持
たない人々によって行われるという事実もまた、念頭に置いておく必要
があります。
.Pp
kerberos のような方法を使うことで、スタッフアカウントのパスワードの変更
もしくは停止を一箇所で行なうことと、スタッフメンバがアカウントを持つ
すべてのマシンに即時にその効果を及ぼすことが可能となります。スタッフメンバの
アカウントが危険に晒されたときに、すべてのマシンでスタッフメンバのパスワードを
即座に変更する能力を過小評価してはいけません。パスワードが分散されている状況では、
N 台のマシンでパスワードを変更すると、てんやわんやの事態を招く可能性が
あります。kerberos を使用すると、パスワードの再発行に制限
.Pq re-passwording restriction
を課することもできます。この機能を使うことにより、
ある kerberos チケットをしばらく経つとタイムアウトにすることが
できるだけでなく、一定期間
.Pq 例えば、1 ヶ月に 1 回
経つと、ユーザに新しいパスワードを選ぶように要求することもできます。
.Sh root の安全性を高める - root 権限のサーバと suid/sgid バイナリ
.Pp
用心深いシステム管理者は、自分に必要なサーバプロセスだけを過不足なく
実行させるものです。第三者製のサーバは、よくバグを持っていがちだと
いうことに注意して下さい。例えば、古いバージョンの imapd や popper 
を実行させておくのは、全世界に共通の root の切符を与えてい
るようなものです。
自分で注意深くチェックしていないサーバは、決して実行してはいけません。
root で実行させる必要のあるサーバはほとんどありません。例えば、ntalk, comsat,
finger デーモンを、特別の「砂場
.Pq sandbox
」ユーザで実行させることができます。
.\"kuma hellofalot of trouble って何や？
.\" hell of a lot of trouble みたいですね。;-) (金ん田 '99.02.11)
管理者が膨大な数の問題に直面していないのなら、この「砂場」は完璧では
ありませんが、セキュリティに関するタマネギ的アプローチはここでも
成り立ちます。砂場で実行されているサーバプロセスを経由して侵入を
果たすことができたとしても、攻撃者はさらに砂場から外に脱出しなければ
なりません。攻撃者が通過せねばならない層の数が増えれば増えるほど、
それだけ攻撃者が侵入に成功する確率が減ります。root の抜け穴は
歴史的に、基本システムサーバも含め、
root 権限で実行されるほとんどすべてのサーバプロセスで発見されています。
ユーザが sshd 経由でのみログインし、
telnetd, rshd, rlogind 経由でログインすること
が決してないマシンを稼働させているのであれば、それらのサービスを停止させて下さい。
.Pp
.Bx Free
では、今では ntalkd, comsat, finger は砂場で実行させることが
デフォルトになっています。次に砂場で実行させるべきプログラムの候補として、
.Xr named 8
があります。デフォルトの rc.conf ファイルには、named を砂場で実行する
ために必要な引数がコメントアウトされた形式で含まれています。新しい
システムをインストールしているか、それとも既存のシステムを
アップグレードして使っているかに依存しますが、砂場として使用する
特別のユーザアカウントがインストールされていないかもしれません。
用心深いシステム管理者であれば、できるだけいつでも研究を怠らず、
サーバに砂場を仕込むものでしょう。
.Pp
通常、砂場で実行しないサーバが他にいくつかあります。sendmail, popper,
imapd, ftpd などです。これらのうちいくつかのサーバには代わりとなるも
のがありますが、
代わりのものをインストールするには、それだけ多くの仕事が必要になるので、
結局これらを喜んで入れてしまいます
.Pq 便利さという要素がまたも勝利を収めるわけです
。
これらのサーバは、root 権限で実行せねばならいかもしれません。また、
これらのサーバ経由で生じる侵入
を検出するためには、他の仕組みに頼らなくてはならないかもしれません。
.Pp
システムの root 権限の潜在的な穴で他に大きなものとして、システムに
インストールされた suid-root/sgid バイナリがあります。
これらのバイナリは、rloginのように、
.Pa /bin ,
.Pa /sbin ,
.Pa /usr/bin ,
.Pa /usr/sbin
に存在するものがほとんどです。
100% 安全なものは存在しないとはいえ、システムデフォルトの
siud/sgid バイナリは比較的安全といえます。それでもなお、root の穴が
これらのバイナリにときおり発見されています。1998 年に Xlib で見つかった
root の穴は、xterm
.Pq 普通、suid 設定されています
を攻撃可能にしていました。
安全である方がよいので、用心深いシステム管理者は残念に思いながらも、
スタッフのみが実行する必要がある suid バイナリは、スタッフのみが
アクセス可能な特別なグループに含めるように制限を加え、
誰も使わない suid バイナリは
.Pq chmod 000 を実行して
片付けてしまうでしょう。
ディスプレイを持たないサーバは、一般的に xterm のバイナリを必要としません。
sgid バイナリもほとんど同様の危険な存在になり得ます。
侵入者が kmem に sgid されたバイナリを破ることができた場合、
その侵入者は
.Pa /dev/kmem
を読み出すことができるようになります。
つまり、暗号化されたパスワードファイルを読み出すことができる
ようになるので、パスワードを持つどのアカウントをも、
.Pq 潜在的な
危険に晒すことになります。
tty グループを破った侵入者は、ほとんどすべてのユーザの端末に書き込みが
できます。talk-back 機能を持つ端末プログラムやエミュレータをユーザが実行
していると、
.Pq 結局、そのユーザとして実行される
コマンドをユーザの端末にエコーさせるデータストリームを
侵入者が生成できる可能性があります。
.Sh ユーザアカウントの安全性を高める
.Pp
ユーザアカウントは、普通、安全性を高めることが最も困難です。
スタッフに対して、アテナイのドラコのような厳格なアクセス制限を課し、
スタッフのパスワードを\ * で外すことができるとはいえ、管理者が持ちうる
一般ユーザすべてのアカウントに対して同じことはできないかも知れません。
管理者が十分に統率をとることができるなら、管理者は勝利し、ユーザの
アカウントの安全を適切に確保できるかもしれません。それが
できないならば、よりいっそう気を配って一般ユーザのアカウントを
監視するよりほかありません。一般ユーザアカウントに対し 
ssh や kerberos を利用することには、いろいろと問題があります。
それでも、暗号化パスワードと比較すると、
はるかに良い解です。
.Sh パスワードファイルの安全性を高める
.Pp
できるだけ多くのパスワードを\ * で外し、それらのアカウントのアクセスには
ssh や kerberos を使うようにすることが、唯一の確実な方法です。たとえ暗号化
パスワードファイル 
.Pq Pa /etc/spwd.db
が root でのみ読み出し可能だとしても、
侵入者がそのファイルの読み出しアクセス権限を得ることは可能かもしれません。たとえ root の書き込み権限が得られないにしてもです。
.Pp
セキュリティスクリプトは常にパスワードファイルの変更をチェックし、報告
するようにすべきです
.Po
後述の「ファイルの完全性のチェック」を参照して下さい
.Pc 。
.Sh カーネルのコア、raw デバイス、ファイルシステムの安全性を高める
.Pp
root の権限を破ると、攻撃者は何でもできますが、
もっと簡便なこともいくつかあります。例えば、最近のカーネルは、
組み込みのパケット覗き見デバイス
.Pq packet sniffing device
ドライバを備えているものがほとんどです。
.Bx Free
では
.Sq bpf
デバイスと呼ばれています。侵入者は普通、危険に晒された
マシンでパケット覗き見プログラムを実行させようと試みます。侵入者に
わざわざそういう機能を提供する必要はないので、ほとんどのシステムで bpf
デバイスを組み込むべきではありません。
.Pp
bpf デバイスを外し、モジュールローダを無効にしても、
.Pa /dev/mem
と
.Pa /dev/kmem
という悩みの種がまだ残っています。この問題に関しては、侵入者は raw
デバイスに書き込むこともできます。
また、
.Xr kldload 8
という、別のカーネル機能があります。
やる気まんまんの侵入者は、KLD モジュールを使って
自分独自の bpf もしくはその他覗き見デバイスを動作中のカーネルに
インストールすることができます。
この問題を避けるため、システム管理者は
カーネルをより高い安全レベル
.Pq securelevel
、少なくとも安全レベル 1 で実行させる必要があります。
sysctl を使って kern.securelevel 変数に安全レベルを設定することが
できます。ひとたび安全レベルに 1 を設定すると、
raw デバイスに対する書き込みアクセスは拒否され、例えば
.Sq schg
のような
特別な chflags フラグが効果を発揮します。これに加えて、
起動時において重要なバイナリ・ディレクトリ・スクリプトファイルなど、
安全レベルが設定されるまでの間に実行されるものすべてに対しても
.Sq schg
フラグを確実に on にしておく必要があります。この設定をやり過ぎても
構いませんが、より高い安全レベルで動作している場合、システムの
アップグレードがはるかに困難になります。システムをより高い安全レベルで
実行させるようにするが、お天道さまの下にあるすべてのシステムファイルと
ディレクトリに schg フラグを設定しないという妥協をする方法もあります。
.Sh ファイルの完全性のチェック: バイナリ、設定ファイルなど
.Pp
ことこの問題に至ると、システム管理者にできることは、
便利さという要素がその醜い頭を上げない程度に、
コアシステムの設定 / 制御ファイルを防御することだけです。
セキュリティのタマネギの最後の層はおそらく最も重要なもの、すなわち探知です。
.Pp
システムファイルの完全性をチェックする唯一の正しい方法は、別の、より安全な
システム経由で行なう方法だけです。
.Sq 安全
なシステムを準備することは比較的
容易です。単にそのシステム上で、サービスを一切実行しないようにするだけです。
安全なシステム
を用いて、ssh 経由で他のシステムの root 空間にアクセスします。これは
セキュリティの末端のように見えるかもしれません。しかし、管理者には信頼を
どこかに置く必要があります。いきあたりばったりでサーバプロセスを
実行するような馬鹿げたことをしない限りは、安全度の高いマシンを構築する
ことは本当に可能です。ここで
.Sq 安全
という場合、物理アクセスに対する
セキュリティをも含めて仮定していることはもちろんです。他のすべてのマシンに root のアクセス権限を持つ、安全なマシンがあれば、
「安全なマシンの上で」システムの他のマシンをチェックする
セキュリティスクリプトを書くことができるようになります。
最も普通のチェック方法は、セキュリティスクリプトで、
まず、find と md5 のバイナリファイルをリモートマシンに
.Xr scp 1
してから、
リモートシステムのすべてのファイル
.Po
もしくは、少なくとも
.Pa / ,
.Pa /var ,
.Pa /usr
パーティション!
.Pc
に対して md5 を適用するシェルコマンドを
ssh を使ってリモートマシンで実行するものです。
安全なマシンは、チェック結果をファイルにコピーし、前回のチェック結果との差分を取り
.Pq または、安全なマシン自身が持っているバイナリと比較する
、その差分を
毎日のレポートとしてスタッフメンバひとりひとりにメールで送ります。
.Pp
この種のチェックを行うもう一つの方法として、
他のマシンから主なファイルシステムを 安全なマシンにNFS export 
する方法があります。
このやり方はいくらかネットワークに負荷を掛けることになりますが、
侵入者がチェックを探知したり偽造したりすることは、
事実上不可能になります。
.Pp
優れたセキュリティスクリプトは、一般ユーザやスタッフメンバのアクセス制御
ファイル: .rhosts, .shosts, .ssh/authorized_keys など、MD5 での精細な
チェックから洩れそうなファイルの変更もチェックするようにします。
.Pp
優れたセキュリティスクリプトは、すべてのファイルシステム上で suid/sgid
バイナリのチェックを行い、前回のチェック結果もしくは何らかの
基準
.Pq 例えば、その基準を週 1 回作成する。
からの差分だけでなく、
それらバイナリの存在そのものを報告するものです。
.Sq nosuid
オプションを
fstab/mount で指定することで、あるファイルシステム上の suid/sgid
バイナリの実行機能をオフにすることができますが、root によるこれら
バイナリの実行をオフにすることはできません。さらに、root 権限を破った者は誰でも
自分自身で用意したバイナリをインストールすることだってできます。
しかしながら、ユーザのディスク空間を大量に持つ場合、
ユーザパーティション上で suid されたバイナリとデバイスを不許可に
しておき
.Po
.Pq nodev
オプション
.Pc 、
そのパーティションをスキャンしないで済ませることも有益かもしれません。
それでも私ならば、ともかく、少なくとも週に 1 回はスキャンする
でしょう。というのは、タマネギのこの層の目的は侵入を検知すること
だからです。
.Pp
プロセスアカウンティング
.Po
.Xr accton 1
参照
.Pc
は、比較的オーバヘッドの低いオペレーティングシステムの機能で、
マシンに侵入されてしまった後の評価の仕組みとして使用することをお勧め
します。
侵入を受けた後でも当該ファイルが無傷である場合に、
侵入者が実際にどのようにしてシステムの root を破ったかを
追跡するのに特に有益です。
.Pp
最後に、セキュリティスクリプトはログファイルを処理するようにし、
ログファイル自体もできるだけ安全性の高い方法で
.Sq リモート syslog は極めて有益になり得ます
生成するようにすべきです。侵入者は自分の侵入の痕跡を覆い隠そう
としますし、また、ログファイルはシステム管理者が最初の侵入の時
刻と方法を追跡してゆくために極めて重要です。
.Sh 偏執狂的方法
.Pp
多少偏執狂的になっても決して悪いことにはなりません。原則的に、
システム管理者は、便利さに影響を与えない範囲でいくつでもセキュリティ
機能を追加することができます。また、いくらか考慮した結果、便利さに
影響を与えるセキュリティ機能を追加することもできます。
.Sh サービス不能攻撃 (D.O.S. attack) についての特記事項
.Pp
このセクションではサービス不能攻撃を扱います。サービス不能攻撃は、普通は、
パケット攻撃です。ネットワークを飽和させる最先端の偽造パケット
.Pq spoofed packet
攻撃に対してシステム管理者が打てる手はそれほど多く
ありませんが、一般的に、その種の攻撃によってサーバがダウン
しないことを確実にすることで、被害をある限度に食い止める
ことはできます。
.Bl -enum -offset indent
.It
サーバの fork の制限
.It
踏み台攻撃の制限 
.Pq ICMP 応答攻撃、ping broadcast など
.It
カーネルの経路情報のキャッシュ
.El
.Pp
普通に見られるサービス不能攻撃に、fork するサーバプロセスに対する
ものがあります。これは、サーバにプロセス・ファイル記述子・メモリを
食い尽くさせて、マシンを殺そうとするものです。
inetd
.Po
.Xr inetd 8
参照
.Pc
には、この種の攻撃を制限するオプションがいくつかあります。マシンが
ダウンすることを防止することは可能ですが、この種の攻撃によりサービスが
崩壊することを防止することは一般的に言ってできないことに注意する必要が
あります。inetd のマニュアルページを注意深く読んで下さい。特に、
.Fl c ,
.Fl C ,
.Fl R
オプションに注意して下さい。IP 偽造攻撃
.Pq spoofed-IP attack
は inetd の 
.Fl C
オプションの裏をかけるので、一般にオプションを
組み合わせて使用するべきであることに注意して下さい。スタンドアロンサーバ
の中には、自分自身で fork を制限するパラメータを持っているものがあります。
.Pp
sendmail には、
.Fl OMaxDaemonChildren
オプションがあります。負荷には遅れがあるので、
sendmail の負荷に限界を設けるオプションを使うよりも、
このオプションを使う方がまともに動作する可能性ははるかに高いです。
sendmail の実行を開始する際に、
.Cm MaxDaemonChildren
パラメータを設定するべきです。その値は、
通常見込まれる負荷を扱える程度に十分高いが、
それだけの数の sendmail を操作しようとすると
マシンが卒倒してしまうほどには高くないような値に設定するべきです。
sendmail をキュー処理モード 
.Pq Fl ODeliveryMode=queued
で実行することや、
sendmail デーモン
.Pq Cm sendmail -bd
をキュー処理用プロセス
.Pq Cm sendmail -q15m
と別に実行することも、用心深いことと言えます。それでもなおリアルタイムでの
配送を望むのであれば、
.Fl q1m
のようにすることで、キュー処理をはるかに短い時間間隔で
行うことができます。いずれにしても、
.Cm MaxDaemonChildren
オプションに
合理的な値を確実に指定して、sendmail がなだれをうって失敗することが
ないようにして下さい。
.Pp
syslogd は直接攻撃される可能性があるので、可能ならばいつでも
.Fl s
オプションを用いることを強く推奨します。これができないなら、
.Fl a
オプションを使って下さい。
.Pp
tcpwrapper の逆 identd などの接続返し
.Pq connect-back
を行うサービスに
ついては十分注意を払うようにするべきです。これらは直接攻撃を受ける可能性が
あります。こういう事情があるので、tcpwrapper の逆 ident 機能を使おうとは
思わないのが一般的です。
.Pp
境界ルータのところでファイアウォールを設けて、外部からのアクセスに対して
内部サービスを防御するという考えは実によいものです。この考えは、LAN の外部
からの飽和攻撃を防ぐことにあり、root ネットワークベースの root 
権限への攻撃から内部サービスを防御することには、あまり考慮を払って
いません。ファイアウォールは常に排他的に設定して下さい。つまり、
「ポート A, B, C, D と M から Z まで
.Eo *
以外
.Ec *
のすべてに防火壁を設ける」というふうにです。
このようにすることで、named
.Pq ゾーンのプライマリである場合 ,
ntalkd, sendmail など、インターネットにアクセスを提供するサービス
として特に指定するもの以外の、小さい番号のポートすべてをファイアウォールで
防御することができます。ファイアウォールをこの他のやり方、つまり
包含的もしくは受容的なファイアウォールとして設定しようとする場合、
.Sq close
することを忘れてしまうサービスがいくつか出てきたり、新しい内部サービスを
追加したのにファイアウォールの更新を忘れたりする可能性がよく出てきます。
ファイアウォール上の大きい番号のポートを開けておいて、小さい番号のポートを
危険に晒すことなく受容的な動作を許すことができます。
.Bx Free
では、net.inet.ip.portrange への sysctl
.Pq sysctl -a \&| fgrep portrange
をいろいろ使用することで、
動的バインドに使用されるポート番号の範囲を制御できることを記憶にとどめて
おいて下さい。これによりファイアウォールの設定の複雑性を緩和できます。
私は、ファイアウォールに通常のfirst/last の範囲として、 4000 から 5000 を、
高位ポートの範囲として、49152 から 65535 を使用しています。そして、
.Po
いくつかのインターネットアクセス可能なポートを
ブロックから除外するのはもちろんですが
.Pc
4000 より下のすべてをブロックしています。
.Pp
また別のありふれたサービス不能攻撃として、踏み台攻撃
.Pq springboard attack
と呼ばれるものがあります。これは、サーバが自分自身、ローカルネットワーク、
そして他のマシンを過負荷に追い込むような応答を生成させる方法でサーバを
攻撃します。この種の攻撃の中で最もありふれたものは、ICMP PING BROADCAST
攻撃があります。攻撃者は、実際に攻撃したいマシンのアドレスをソース
アドレスに設定した ping パケットを偽造して、対象の LAN の
ブロードキャストアドレスに向けてパケットを送信します。境界にあるルータが
ブロードキャストアドレスに対する ping パケットを握り潰すように設定されていない
場合、LANは、詐称されたソースアドレスに向けて応答パケットを生成するはめになり、犠牲となるマシンが飽和するところまで行ってしまいます。攻撃者が同じトリックを
異なるネットワーク上のいくつものブロードキャスト
アドレスに対して同時に使用した場合、とくにひどいことになります。
これまでに、120 メガビット以上のブロードキャスト攻撃が観測されています。
2 番目の踏み台攻撃は、ICMP エラー報告の仕掛けを狙うものです。ICMP エラー
応答を生成するパケットを生成することにより、攻撃者はサーバの
受信ネットワークを飽和させることができ、同時に、サーバが送信
ネットワークを ICMP 応答で飽和させるようにすることができます。
mbuf を消費し尽くさせることにより、この種の攻撃でサーバを
クラッシュさせることも可能です。サーバの ICMP 応答生成が速過ぎて、
ICMP 応答の送信が追い付かない場合、とくにひどいことになります。
.Bx Free
カーネルには、この種の攻撃の効果を抑制する ICMP_BANDLIM と
呼ばれる新しいコンパイルオプションがあります。
3つめの主要なクラスに属す踏み台攻撃は、udp echo サービスのような、
ある種の内部 inetd サービスに関連するものです。攻撃者は、単に
ソースアドレスがサーバ A の echo ポートであり、ディスティネーション
アドレスがサーバ B の echo ポートであるかのように UDP パケットを
偽造します。ここでサーバ A, B はともに自分の LAN に接続されています。
この 2 つのサーバは、この一つのパケットを両者の間で互いに相手に対して
打ち返しあいます。このようにしてパケットをいくつか注入するだけで、
攻撃者は両方のサーバと LAN を過負荷状態にすることができます。
同様の問題が内部 chargen ポートにも存在します。有能なシステム管理者は
この手の inetd 内部テストサービスのすべてを無効にしておくものです。
.Pp
偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を生じさせるために
用いられることもあります。net.inet.ip.rtexpire, rtminexpire, rtmaxcache
の sysctl パラメータを参照して下さい。でたらめなソース IP を用いた
この偽造パケット攻撃により、カーネルは、一時的なキャッシュ経路を
経路情報テーブルに生成します。これは
.Sq netstat -rna \&| fgrep W3
で見ることができます。これらの経路は、普通は 1600 秒程度でタイムアウトに
なります。カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを
検知すると、カーネルは動的に rtexpire を減らしますが、rtminexpire より
小さくなるようには決して減らしません。ここに問題が 2 つあります。
(1) 負荷の軽いサーバが突然攻撃された場合、カーネルが十分素早く反応
できないこと。(2) カーネルが攻撃に耐え生き延びられるほど十分
rtminexpire が低く設定されていないこと。の2つです。
自分のサーバが T3 もしくはそれより
良質の回線でインターネットに接続されている場合、
.Xr sysctl 8
を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いこと
といえます。
.Pq 自分のマシンをクラッシュさせたくないのであれば :-)
どちらか一方でも 0 に
は決してしないで下さい。両パラメータを 2 秒に設定すれば、
攻撃から経路情報テーブルを守るには十分でしょう。

.Sh 関連項目
.Pp
.Xr accton 1 ,
.Xr chflags 1 ,
.Xr find 1 ,
.Xr kerberos 1 ,
.Xr md5 1 ,
.Xr ssh 1 ,
.Xr sshd 1 ,
.Xr syslogd 1 ,
.Xr xdm 1 ,
.Xr sysctl 8
.Sh 歴史
.Nm
マニュアルページは、もともと
.An Matthew Dillon
によって書かれました。
最初に現れたのは、
.Fx 3.1
で 1998 年 12 月のことです。
.\" translated by Norihiro Kumagai, 98-12-29