1 files changed, 0 insertions, 634 deletions

diff --git a/ja_JP.eucJP/man/man7/security.7 b/ja_JP.eucJP/man/man7/security.7
deleted file mode 100644
index 534e92d12a..0000000000
--- a/ja_JP.eucJP/man/man7/security.7
+++ /dev/null
@@ -1,634 +0,0 @@
-.\" 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 1998/12/26 05:19:42 dillon 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 サーバを実行させています。これらの
-サーバは、デフォルトでは、暗号化されたコネクション上で動作していません。
-その結果、抱えているユーザ数が標準的な大きさならば、リモート
-.Pq そのシステムにログインするのに最も普通で便利な場所
-からログインしているユーザのうち一人以上は、パスワードを覗き見られて
-しまうでしょう。
-システム管理者が注意深いならば、たとえログインが成功していたとしても、
-リモートアクセスログをときどき解析して、疑わしいソースアドレスを探すものです。
-.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 /etc/group の
-wheel グループに加えることがあります。
-wheel グループに置かれたスタッフメンバには、
-.Sq su
-を使って root になることが許されます。スタッフメンバに、
-パスワードファイルのエントリでそのまま wheel のアクセス権を
-与えてはいけません。スタッフは、
-.Sq staff
-かその類のグループに置き、その中で本当に root になる必要がある人
-だけを wheel グループに加えるようにします。残念ながら、wheel の
-仕組みだけだと、侵入者がパスワードファイルを手に入れると、攻撃者が
-破る必要があるのは 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 チケットをしばらくしてからタイムアウトにすることだけでなく、
-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 など、
-これらのバイナリのほとんどは、/bin, /sbin, /usr/bin, /usr/sbin に
-存在します。100% 安全なものは存在しないとはいえ、システムデフォルトの
-siud/sgid バイナリは比較的安全といえます。それでもなお、root の穴が
-これらのバイナリにときおり発見されています。1998 年に Xlib で見つかった
-root の穴は、xterm
-.Pq 普通、suid 設定されています
-を攻撃可能にしていました。
-安全である方がよいので、用心深いシステム管理者は残念に思いながらも、
-スタッフのみが実行する必要がある suid バイナリは、スタッフのみが
-アクセス可能な特別なグループに含めるように制限を加え、
-誰も使わない suid バイナリは chmod 000 して片付けてしまうでしょう。
-ディスプレイを持たないサーバは、一般的に xterm のバイナリを必要としません。
-sgid バイナリもほとんど同様の危険な存在になり得ます。
-侵入者が sgid-kmem のバイナリを破ることができた場合、
-その侵入者は /dev/kmem を読み出すことができるようになります。
-つまり、暗号化されたパスワードファイルを読み出すことができる
-ようになるので、パスワードを持つどのアカウントをも、
-.Pq 潜在的な
-危険に晒すことになります。
-tty グループを破った侵入者は、ほとんどすべてのユーザの端末に書き込みが
-できます。talk-back 機能を持つ端末プログラムやエミュレータをユーザが実行
-していると、
-.Pq 結局、そのユーザとして実行される
-コマンドをユーザの端末にエコーさせるデータストリームを
-侵入者が生成できる可能性があります。
-.Sh ユーザアカウントの安全性を高める
-.Pp
-ユーザアカウントは、普通、安全性を高めることが最も困難です。
-スタッフに対して、アテナイのドラコのような厳格なアクセス制限を課し、
-スタッフのパスワードを\ * で外すことができるとはいえ、管理者が持ちうる
-一般ユーザすべてのアカウントに対して同じことはできないかも知れません。
-十分な管理を保つならば、管理者は勝利し、ユーザの
-アカウントを適切な状態で安全を確保できるかもしれません。それが
-保てないならば、一般ユーザのアカウントをモニタしていっそう気を配るように
-するしかありません。一般ユーザアカウントでの ssh や kerberos の利用は、
-いろいろ問題をはらんでいます。それでも、暗号化パスワードと比較すると、
-はるかに良い解です。
-.Sh パスワードファイルの安全性を高める
-.Pp
-できるだけ多くのパスワードを\ * で外し、それらのアカウントのアクセスには
-ssh や kerberos を使うようにすることが、唯一の確実な方法です。たとえ暗号化
-パスワードファイル 
-.Pq /etc/spwd.db
-が root でのみ読み出し可能だとしても、
-たとえ root の書き込み権限が得られないにしても、侵入者がそのファイルの
-読み出しアクセス権限を得ることは可能かも知れません。
-.Pp
-セキュリティスクリプトは常にパスワードファイルの変更をチェックし、報告
-するようにすべきです (後述の「ファイルの完全性のチェック」を参照して下さい)。
-.Sh カーネルのコア、raw デバイス、ファイルシステムの安全性を高める
-.Pp
-root の権限を破ると、攻撃者はほとんど何でもできますが、
-もっと簡便なこともいくつかあります。例えば、最近のカーネルのほとんどでは、
-組み込みのパケット覗き見デバイス
-.Pq packet sniffing device
-ドライバを備えています。
-.Bx Free
-では
-.Sq bpf
-デバイスと呼ばれています。侵入者は普通、危険に晒された
-マシンでパケット覗き見プログラムを実行させようと試みます。侵入者に
-わざわざそういう機能を提供する必要はないので、ほとんどのシステムで bpf
-デバイスを組み込むべきではありません。不幸なことに、ローダブルカーネル
-モジュール 
-.Pq Loadable Kernel Module:LKM
-インタフェースと呼ばれる
-カーネル機能があります。やる気まんまんの侵入者は、LKM を使って
-自分独自の bpf もしくはその他覗き見デバイスを動作中のカーネルに
-インストールすることが可能です。
-モジュールローダを使う必要がないのであれば、カーネル設定で
-NO_LKM オプションを設定してこの機能を無効にして下さい。
-.Pp
-bpf デバイスを外し、モジュールローダを無効にしても、/dev/mem と /dev/kmem
-という悩みの種がまだ残っています。この問題に関しては、侵入者は raw
-デバイスに書き込むこともできます。この問題を避けるため、システム管理者は
-カーネルをより高い安全レベル
-.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
-してから、
-リモートシステムのすべてのファイル
-.Pq もしくは、少なくとも /, /var, /usr パーティション!
-に対して md5 を適用するシェルコマンドを
-ssh を使ってリモートマシンで実行するものです。
-安全なマシンは、チェック結果をファイルにコピーし、前回のチェック結果と
-diff を取り
-.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
-.Sq nodev
-オプション
-.Pc
-を不許可にしておき、スキャンしないで済ませることも有益かもしれません。
-それでも、私ならば、少なくとも週に 1 回はスキャンする
-でしょう。というのは、タマネギのこの層の目的は侵入の検知だからです。
-.Pp
-プロセスアカウンティング
-.Po
-.Xr accton 1
-参照
-.Pc
-は、侵入後の評価の仕組みとして利用をお勧めする、
-比較的オーバヘッドの低いオペレーティングシステムの機能です。
-侵入を受けた後でも当該ファイルが無傷であるとするなら、
-侵入者が実際のところどのようにしてシステムの root を破ったかを
-追跡するのに際して特に有益です。
-.Pp
-最後に、セキュリティスクリプトはログファイルを処理するようにして、
-ログファイル自体はできるだけ安全性の高い方法で
-(リモート 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
-で実行することや、
-デーモン
-.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 を使用しています。さらに、
-.Pq いくつかのインターネットアクセス可能なポートを除くのはもちろんですが
-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 が低くなっていないこと。自分のサーバが 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
-によって書かれました。
-最初に現れたのは、
-.Bx Free -3.0.1
-で 1998 年 12 月のことです。
-.\" translated by Norihiro Kumagai, 98-12-29