15.3. FreeBSDの安全性を高める

15.3.1. root アカウントとスタッフアカウントの安全性を高める

root のアカウントの安全性を確保しないうちから スタッフのアカウントの安全性をうんぬんしてもしかたがありません。 ほとんどのシステムでは、root アカウントに割り当てたパスワードが 1 つあり ます。まず最初にすべきことは、このパスワードはいつで も不正利用の危険に晒されていると仮定することです。これは root のパスワードを消すべきだと言っているのではありません。 root のパスワードは、マシンにコンソールからアクセスするのには、 ほとんどいつでも必要なものです。ここで言いたいのは、コンソール 以外からは、そして可能なら su(1) コマンドを実行する場合も root のパスワードを使えないようにするべきである、ということで す。たとえば、あなたが使っている pty が、 /etc/ttys ファイルで insecure と指定 されているか確認してください。そうすると、 telnet や rlogin 経由では root で直接ログインできないようになります。 これは、/etc/ssh/sshd_config を編集して PermitRootLogin に NO が設定されるようにすることで実現できます。 sshd のような、別のログインサービス を使っている場合でも同様に、直接 root へログインすることを許し ていないかどうか確認してください。すべてのアクセス手段 – たとえば FTP のようなサービスが、良くクラックの対象となることを考えましょう。 root への直接ログインは、 システムコンソール経由でのみ可能であるべきなのです。

また当然、システム管理者として自分が root になれるようにしておく必要が ありますから、そのための穴をいくつか開けておきます。し かし、それらの穴を動作させるには、さらに追加のパスワード認証が 必要であるようにしておくことが重要です。 root でアクセス可能と する方法の一つとして、適切なスタッフアカウントを (/etc/group 中の) wheel グループに加えることがあります。 wheel グループに入っているスタッフメンバは su を使って root になることが許されます。 パスワードエントリにおいて、スタッフメンバを wheel グループに置くことによって直接 wheel 権限を与えてはいけません。スタッフメンバのアカウントは staff グループに所属させるべきで、その上で /etc/group ファイルを通して wheel グループに加えるべきです。実際に root アクセスの必要なスタッフメンバのみ wheel グループに置くようにすべきです。 他の認証方法の場合、たとえば Kerberos を使用する場合には、 root アカウントの Kerberos .k5login ファイルを使えば、誰も wheel グループに置く必要なく root に ksu(1) することを許可できます。このやり 方はよりよい解決策なのかもしれません。なぜなら、 wheel のメカニズムでは、侵入者がパスワード ファイルを手に入れ、スタッフアカウントのいずれか 1 つを破るこ とができると、 root を破ることがまだできてしまうからです。 wheel のメカニズムを用いる方が、 何もしないよりは良いのですが、 必ずしも最も安全な選択肢とは限りません。

スタッフのアカウント、また究極には root アカウントの安全性 を高める間接的な方法は、別のログインアクセスの方法を用いてスタッ フのアカウントの安全性を高め、その上でそのスタッフのアカウント の暗号化パスワードを “アスタリスク化” するものです。 vipw(8) コマンドを使えば、暗号化されたパスワードを “*” 1 文字に置き換えられます。 このコマンドは、/etc/master.passwd ファイルとユーザ/パスワードデータベースを更新して、 パスワード認証によるログインができないようにします。

たとえば、次のスタッフアカウントを、

foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh

こう変更します。

foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh

暗号化されたパスワードは “*” と一致することがないので、 この変更によって通常のログインはできなくなります。 こうした後は、スタッフメンバは認証のために kerberos(1) や 公開鍵 / 秘密鍵の組を用いる ssh(1) のような代わりとなる認 証手段を利用しなければなりません。 Kerberos のようなログイン機構を使う場合は、一般に Kerberos サーバを実行するマシンと自分のデスクトップワークステーションの安全性を確保しなければなりません。 また ssh で公開鍵 / 秘密鍵の組を使う場合、 一般に、ログイン元マシン (通常は自分のワー クステーション) の安全性を確保しなければなりません。ここで、 ssh-keygen(1) で公開鍵 / 秘密鍵の組を生成する際、鍵の組 をパスワードで防御することにより、鍵の組への防御層を追加するこ ともできます。スタッフアカウントのパスワードを “アスタリスク” でつぶすことができると、 管理者自身が設定 した安全性の高い方法でしかスタッフメンバがログインできないこと も保証できます。こうして、多くの侵入者が使う重大なセキュリティ の穴である、 安全性の低い無関係なマシンからネットワークを覗き見る方法を塞ぐようなセッションを提供する、 安全性の高い暗号 化されたコネクションを使うことを、スタッフメンバ全員に強制する ことができるのです。

より間接的なセキュリティの仕組みでは、制限の強いサーバから 制限の弱いサーバへログインすることを前提としています。たとえば、 メインマシンで、様々な種類のサーバを実行させている場合、ワーク ステーションではそれらのサーバを実行させてはなりません。ワーク ステーションを十分に安全にしておくためには、実行するサーバの数 を、一つもサーバが実行されていないというくらいにまでできる限り 減らすべきです。また、パスワードで保護されたスクリーンセーバを 走らせておくべきです。ワークステーションへの物理的アクセスが与 えられたとすると、もちろん言うまでもなく、攻撃者は管理者が設定 したいかなる種類のセキュリティをもうち破ることができるのです。 このことは、管理者として必ず考えておかねばならない問題ですが、 システム破りの大多数は、ネットワーク経由でリモートから、ワーク ステーションやサーバへの物理的アクセス手段を持たない人々によっ て行われるという事実もまた、念頭に置いておく必要があります。

Kerberos のような方法を使うことで、 スタッフアカウントのパ スワードの変更もしくは停止を一箇所で行なうことと、スタッフメン バがアカウントを持つすべてのマシンに即時にその効果を及ぼすこと が可能となります。スタッフメンバのアカウントが危険に晒されたと きに、すべてのマシンでスタッフメンバのパスワードを即座に変更す る能力を過小評価してはいけません。パスワードが分散されている状 況では、N 台のマシンでパスワードを変更すると、てんやわんやの事 態を招く可能性があります。Kerberos を使用すると、パスワードの 再発行に制限 (re-passwording restriction) を課することもできま す。この機能を使うことにより、ある Kerberos チケットをしばらく 経つとタイムアウトにすることができるだけでなく、一定期間 ( 例 えば、1 ヶ月に 1 回) 経つと、ユーザに新しいパスワードを選ぶよ うに要求することもできます。

15.3.2. root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める

用心深いシステム管理者は、自分に必要なサーバプロセスだけを 過不足なく実行させるものです。サードパーティ製のサーバは、よくバグを持っ ていがちだということに注意して下さい。たとえば、古いバージョンの imapd や popper を実行させておくのは、全世界に万能の root の切符を与えているようなものです。自分で注意深くチェックしていない サーバは、決して実行してはいけません。root で実行させる必要のあるサーバはほとんどありません。たとえば、 ntalk, comsat, finger デーモンを、専用ユーザの 砂場 (sandbox) で実行させることができます。 管理者が膨大な数の問題を経験していないのなら、 この「砂場」は完 璧ではありませんが、セキュリティに関するタマネギ的アプローチは ここでも成り立ちます。砂場で実行されているサーバプロセスを経由 して侵入を果たすことができたとしても、攻撃者はさらに砂場から外 に脱出しなければなりません。攻撃者が通過せねばならない層の数が 増えれば増えるほど、それだけ攻撃者が侵入に成功する確率が減りま す。Root の抜け穴は歴史的に、基本システムサーバも含め、 root 権限で実行されるほとんどすべてのサーバプロセスで発見されています。 ユーザが sshd 経由でのみログインし、 telnetd, rshd, rlogind 経由でログインすることが決 してないマシンを稼働させているのであれば、それらのサービスを停 止させて下さい!

FreeBSD では、今では ntalkd, comsat, finger は砂場で実行させることがデフォ ルトになっています。次に砂場で実行させるべきプログラムの候補と して、named(8) があります。 /etc/defaults/rc.conf ファイルには、 named を砂場で実行するために必要な 引数がコメントアウトされた形式で含まれています。新しいシステム をインストールしているか、それとも既存のシステムをアップグレー ドして使っているかに依存しますが、砂場として使用する特別のユー ザアカウントがインストールされていないかもしれません。用心深い システム管理者であれば、できるだけいつでも研究を怠らず、サーバ に砂場を仕込むものでしょう。

通常、砂場で実行しないサーバが他にいくつかあります。 sendmail, popper, imapd, ftpd などです。これらのうちいくつか のサーバには代わりとなるものがありますが、代わりのものをインス トールするには、あなたが思うより多くの仕事が必要になるかもしれ ません (便利さという要素がまたも勝利を収めるわけです)。これら のサーバは、root 権限で実行しなければばならないかもしれません。また、 これらのサーバ経由で生じる侵入を検出するためには、他の仕組みに 頼らなくてはならないかもしれません。

システムの root 権限の潜在的な穴で他に大きなものには、シ ステムにインストールされた suid-root/sgid バイナリがあります。 これらのバイナリは、rlogin のように、 /bin, /sbin, /usr/bin, /usr/sbin に存在するものがほとんどです。100% 安全なものは存在しないとは いえ、システムデフォルトの siud/sgid バイナリは比較的安全とい えます。それでもなお、root セキュリティホールがこれらのバイナリにときおり発見されています。 1998 年に xterm (普通、suid 設定されています) を脆弱にしていた Xlib の root セキュリティホールが見つかりました。 安全である方がよいので、 用心深いシステム管理者は残念に思いながらも、スタッフのみが実行 する必要がある suid バイナリは、スタッフのみがアクセス可能な特 別なグループに含めるように制限を加え、誰も使わない suid バイナ リは (chmod 000 を実行して) 片付けてしまう でしょう。ディスプレイを持たないサーバは、一般的に xterm のバイナリを必要としません。 sgid バイナリもほとんど同様の危険な存在になり得ます。侵入者が kmem に sgid されたバイナリを破ることができた場合、その侵入者 は /dev/kmem を読み出すことができるように なるでしょう。つまり、暗号化されたパスワードファイルを読み出す ことができるようになるので、パスワードを持つどのアカウントをも、 潜在的な危険に晒すことになります。他にも、 kmem グループを破った侵入者が pty を通して 送られたキーストロークを監視できるという危険があります。キース トロークには、安全な方法でログインするユーザが使っている pty も含まれます。 tty グループを破った侵入者は、ほぼ任意のユーザの tty へ書き込みができます。ユーザが端末プログラムやキーボードを シミュレーションする機能を持ったエミュレータを使っている場合、 侵入者は潜在的に、結局そのユーザとして実行されるコマンドをユー ザの端末にエコーさせるデータストリームを生成できる可能性があり ます。

15.3.3. ユーザアカウントの安全性を高める

ユーザアカウントは、普通、安全性を高めることが最も困難です。 スタッフに対しては、とても厳格なアクセス制限を強制しパスワードを “アスタリスク” で外すことができるでしょうが、 管理者が 持ちうる一般ユーザすべてのアカウントに対して同じことはできない かもしれません。管理者が十分に統率をとることができるなら、管理 者は勝利し、ユーザのアカウントの安全を適切に確保できるかもしれ ません。それができないならば、よりいっそう気を配って一般ユーザ のアカウントを監視するよりほかありません。 一般ユーザアカウントに対し ssh や Kerberos を利用することには、 システム管理がさらに増えたりテクニカルサポートが必要に なるなどの問題があります。それでも、暗号化パスワードファイルと 比較するとはるかに良い解です。

15.3.4. パスワードファイルの安全性を高める

できるだけ多くのパスワードを * で外し、 それらのアカウントのアクセスには ssh や Kerberos を使うようにすることが、唯一の確実な方法です。 暗号化パスワードファイル (/etc/spwd.db) は root でのみ読み出し可能だけれども、 たとえ、侵入者が root の書き込み権限は得られなくとも、 読み出しアクセス権限を得ることは可能かもしれません。

セキュリティスクリプトで常にパスワードファイルの変更をチェッ クし、報告するようにすべきです (ファイルの完全性のチェック 節参照)。

15.3.5. カーネルのコア、raw デバイス、ファイルシステムの安全性を 高める

root の権限を破ると、攻撃者はほとんど何でもできますが、特に重宝さ れる特定の事柄もいくつかあります。たとえば、最近のカーネルは、組 み込みのパケット覗き見デバイス (packet sniffing device) ドライ バを備えているものがほとんどです。FreeBSD では bpf デバイスと呼ばれています。侵入者 は普通、侵入済みのマシンでパケット覗き見プログラムを実行させよ うと試みます。侵入者にわざわざそういう機能を提供する必要はない ので、ほとんどのシステムで bpf デバイスを組み込むべきではありません。

bpf デバイスを外しても、 /dev/mem と /dev/kmem という悩みの種がまだ残っています。この問題に関しては、侵入者は raw ディスクデバイスに書き込 むこともできます。ほかにも、モジュールローダ、kldload(8) とい う、別のカーネル機能があります。やる気まんまんの侵入者は、KLD モジュールを使って自分独自の bpf もしくはその他覗き見デバイス を動作中のカーネルにインストールできます。この問題を 避けるため、システム管理者はカーネルをより高い安全レベル ( securelevel)、少なくとも安全レベル 1 で実行させる必要がありま す。安全レベルは sysctl を使って kern.securelevel 変数を操作して設定できます。ひとたび安全レベルに 1 を設定すると、raw デバ イスに対する書き込みアクセスは拒否され、たとえば schg のような特別な chflags フラグの機能が 強制されます。システム起動に関わる重要なバイナリやディレクトリ、 スクリプトファイルなど、安全レベルが設定されるまでの間に実行さ れるすべてのものに対しても、確実に schg フラグを設定してください。この設定をやり過ぎても 構いませんが、より高い安全レベルで動作している場合、システムの アップグレードがはるかに困難になります。システムをより高い安全 レベルで実行させるようにするが、すべてのシステムファイルとディ レクトリに schg フラグを設定しないというところで妥協するという手もあります。 もう一つの可能性としては、単純に / および /usr を読み 込み専用でマウントすることです。ここで特筆すべきことは、システ ムを守ろうとして厳しくしすぎると、侵入を検出するという非常に重 要なことができなくなってしまうということです。

15.3.6. ファイルの完全性のチェック: バイナリ、設定ファイルなど

ことこの問題に至ると、システム管理者にできることは、便利さ という要素がその醜い頭を上げない程度に、コアシステムの設定と制 御ファイルを防御することだけです。たとえば、 / および /usr にある 大部分のファイルに schg ビットを設定するた めに chflags を使用するのは、おそらく逆効果 でしょう。なぜなら、そうすることでファイルは保護できますが、侵 入を検出する窓を閉ざしてしまうことにもなるからです。セキュリティ のタマネギの最後の層はおそらく最も重要なもの – 検出で す。セキュリティの残りのものは、突然の侵入を検出できなければ、 まったく有用ではありません (あるいは、もっと悪ければ、安全性に 対する間違った感覚を植え付けてしまいます)。タマネギの仕事の半 分は、もう半分の検出側が攻撃者を攻撃の最中に捕えるようにするた めに、攻撃者を食い止めるのではなく侵入を遅らせることなのです。

侵入を検出する最も良い方法は、変更されていたり、消えていた り、入れた覚えがないのに入っているファイルを探すことです。変更 されたファイルを探すのに最も良い方法は、もう一つの (しばしば中 央に集められた)、アクセスが制限されたシステムから行なうもので す。さらに安全でアクセス制限されたシステム上でセキュリティ用ス クリプトを書けば、 スクリプトは潜在的な攻撃者からはほぼ見えなくなります。 これは重要なことです。この有効性を最大限に活用 するためには、一般的に、アクセスの制限されたマシンから実際に使っている他のマシンへのかなりのアクセスを許可する必要があります。普 通は、他のマシンからアクセス制限されたマシンへ読み込み専用の NFS エクスポートをしたり、アクセス制限されたマシンから他のマシンへ ssh 接続を行なうために、 ssh 鍵のペアを作ったりすることで行います。 ネットワークのトラフィックを別にして、NFS は最も可視性 のない方法です – 各クライアント上のファイルシステムを、 事実上検出されずに監視できるようになります。アクセス制限された サーバがスイッチを通してクライアントに接続されている場合、たい てい NFS がより良い選択肢です。アクセス制限されたサーバがハブ や、いくつかのルーティング層を通してクライアントに接続している場合、 NFS は (ネットワークの面で) あまりにも危険なので、 ssh の方が認証を行った跡は残りますが、良い方法でしょう。

アクセス制限されたマシンに、監視しようとするクライアントシ ステムへの少なくとも読み込みのアクセス権を与えたら、次に実際に 監視するためのスクリプトを書かなくてはいけません。NFS マウント をすれば、find(1) や md5(1) などの単純なシステムユー ティリティでスクリプトを書くことができます。少なくとも 1 日 1 回、クライアントのファイルを直接 md5 にかけ、さらにもっと頻繁 に /etc および /usr/local/etc にあるようなコントロール用 ファイルを試験するのが一番です。アクセス制限されたマシンが正し いと知っている、基となる md5 情報と比べて違いが見つかった場合、 システム管理者に調べて欲しいと悲鳴を上げるようにすべきです。優 れたセキュリティ用スクリプトは、/ および /usr などのシステムパーティション上で不適 当に suid されたバイナリや、新たに作成されたファイルや削除され たファイルがないかどうかを調べるでしょう。

NFS ではなく、ssh を使用する場合は、 セキュリティ用スクリプトを書くのはずっと難しいことで す。スクリプトを動かすためには、クライアントに対してスクリプト を scp しなくてはいけませんし、それは目に見 えてしまいます。そして、安全のためには、スクリプトが使うバイナ リ (find など) を scp する必要もあります。 クライアントマシンの ssh クライアントはすでに攻撃されてしまっているかもしれません。 結局のところ、安全でないリンク上の場合は ssh は必要かもしれませんが、ssh を扱うのはとても大変なことです。

優れたセキュリティ用スクリプトは、ユーザやスタッフメンバの アクセス設定ファイルの変更もチェックするものです。 .rhosts, .shosts, .ssh/authorized_keys など … MD5 チェックの範囲外になってしまうであろう ファイル群です。

ユーザ用のディスク容量が非常に大きい場合は、パーティション 上の各ファイルを見て回るのに大変な時間がかかるかもしれません。 この場合は、マウントフラグを設定して、このパーティションに suid されたバイナリやデバイスを置けないようにするのが良い考え です。nodev および nosuid オプション (mount(8) 参照) が知るべきものでしょう。 とにかく少なくとも週に 1 度はファイルシステムをスキャンするべきです。 なぜなら、この層の目的は、侵入が成功したかどうかに関わらず、侵 入があったことの検出をすることだからです。

プロセスアカウンティング (accton(8) 参照) は、 マシンへの侵入を検出するためのメカニズムとして推奨できる、 比較的オーバヘッドの少ないオペレーティングシステムの機能です。 侵入を受けた後でも当該ファイルが無傷である場合に、侵入者が 実際にどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。

最後に、セキュリティスクリプトはログファイルを処理するよう にし、ログファイル自体もできるだけ安全性の高い方法で生成するよ うにすべきです – リモート syslog は極めて有益になり得ま す。侵入者は自分の侵入の痕跡を覆い隠そうとしますし、また、ログ ファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆく ために極めて重要です。ログファイルを永久に残しておくための 1 つの方法は、システムコンソールをシリアルポートにつないで走らせ、 コンソールを監視している安全なマシンを通して絶えず情報を集める ことです。

15.3.7. 偏執狂的方法

多少偏執狂的になっても決して悪いことにはなりません。原則的 に、システム管理者は、便利さに影響を与えない範囲でいくつでもセ キュリティ機能を追加することができます。 また、いくらか考慮した結果、 便利さに影響を与えるセキュリティ機能を追加することもできます。 より重要なことは、 セキュリティ管理者はこれを多少混ぜこぜにして使うべきだということです。 – もしあなたが、本文書に書かれている勧告をそのまま使用した場合は、 予想される攻撃者はやはり本文書を読んでいるわけですから、 あなたの防御策を教えてしまうことになります。

15.3.8. サービス妨害攻撃

このセクションではサービス妨害攻撃 (DoS 攻撃) を扱います。 サービス妨害攻撃は、普通は、パケット攻撃です。ネットワークを飽 和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシス テム管理者が打てる手はそれほど多くありませんが、一般的に、その 種の攻撃によってサーバがダウンしないことを確実にすることで、被 害をある限度に食い止めることはできます。

1. サーバの fork の制限。

2. 踏み台攻撃の制限 (ICMP 応答攻撃、ping broadcast など)。

3. カーネルの経路情報のキャッシュ。

よくあるサービス妨害攻撃は、fork するサーバプロセスに対す るものです。これは、サーバにプロセス、ファイル記述子、メモリを マシンが死ぬまで食い尽くさせようとするものです。 inetd (inetd(8) 参照) には、この種の攻撃を制限するオプションが いくつかあります。マシンがダウンすることを防止することは可能で すが、この種の攻撃によりサービスが中断することを防止することは 一般的に言ってできないことに注意する必要があります。 inetd のマニュアルページを注意深く読んで下さい。特に、 -c, -C, -R オプションに注意して下さい。IP 偽造攻撃 (spoofed-IP attack) は inetd の -C オプションの裏をかけるので、 一般にオプションを組み合わせて使用するべきであることに注意して下さ い。スタンドアロンサーバの中には、自分自身で fork を制限するパ ラメータを持っているものがあります。

Sendmail には、 -OMaxDaemonChildren オプションがあります。シ ステム負荷の値変化には遅れがあるので、sendmail の負荷限界指定 オプションを使うよりも、このオプションを使う方がまともに動作す る可能性ははるかに高いです。 sendmail の実行を開始する際に、 MaxDaemonChildren パラメータを設定するべき です。その値は、通常見込まれる負荷を扱える程度に十分高いが、そ れだけの数の sendmail を操作しよう とするとマシンが卒倒してしまうほどには高くないような値に設定す るべきです。sendmail をキュー処理モード (-ODeliveryMode=queued) で実行することや、 sendmail デーモン (sendmail -bd) をキュー処 理用プロセス (sendmail -q15m) と別に実行す ることも、用心深いことと言えます。それでもなおリアルタイムでの 配送を望むのであれば、-q1m のようにすることで、 キュー処理をはるかに短い時間間隔で行うことができます。いずれに しても、MaxDaemonChildren オプションに合理 的な値を確実に指定して、sendmail がなだれをうって失敗すること がないようにして下さい。

syslogd は直接攻撃される可能性 があるので、可能ならばいつでも -s オプション を用いることを強く推奨します。これができないなら、 -a オプションを使って下さい。

tcpwrapper の逆 identd などの接 続返し (connect-back) を行うサービスについては十分注意を払うよ うにするべきです。これらは直接攻撃を受ける可能性があります。こ ういう事情があるので、tcpwrapper の 逆 ident 機能を使おうとは思わないのが一般的です。

境界ルータのところでファイアウォールを設けて、外部からのア クセスに対して内部サービスを防御するという考えは実によいもので す。この考えは、LAN の外部からの飽和攻撃を防ぐことにあり、内部 サービスをネットワークベースの root 権限への攻撃から防御するこ とにはあまり考慮を払っていません。ファイアウォールは常に排他的 に設定して下さい。つまり、“ポート A, B, C, D と M から Z まで以外 のすべてにファイアウォールを設ける” というふうにです。このようにすることで、 named (ゾーンのプライマリである場合)、 ntalkd, sendmail などのインターネットからア クセスできるサービスとして特に指定するもの以外の、小さい番号の ポートすべてをファイアウォールで防御することができます。ファイ アウォールをこの他のやり方 – つまり包含的もしくは受容的 なファイアウォールとして設定しようとする場合、 “close” することを忘れてしまうサービスがいくつか 出てきたり、新しい内部サービスを追加したのにファイアウォールの 更新を忘れたりする可能性がよく出てきます。ファイアウォール上の 大きい番号のポートを開けておくことにより、小さい番号のポートを 危険に晒すことなく受容的な動作を許すことができます。FreeBSD で は、net.inet.ip.portrange への sysctl (sysctl -a | fgrep portrange) をいろいろ使用することで、動的バインドに使用される ポート番号の範囲を制御できることを記憶にとどめておいてください。 これによりファイアウォールの設定を簡略化することもできます。 たとえば、通常の first/last 範囲として 4000 から 5000 を、 高位ポートの範囲として、49152 から 65535 を指定し、 (いくつかのインターネットアクセス可能 なポートをブロックから除外するのはもちろんですが) 4000 より下のすべてのポートをブロックするという設定が考えられます。

また別のよくあるサービス妨害攻撃として、踏み台攻撃 (springboard attack) と呼ばれるものがあります – これは、 あるサーバを攻撃し、そこ結果として生成される応答が自分自身、ロー カルネットワーク、そして他のマシンを過負荷に追い込むようにする 攻撃です。この種の攻撃の中で最もありふれたものに、 ICMP ping broadcast 攻撃があります。攻撃 者は、実際に攻撃したいマシンのアドレスを送信元アドレスに設定し た ping パケットを偽造して、対象の LAN のブロードキャストアド レスに向けてパケットを送信します。境界にあるルータがブロードキャ ストアドレスに対する ping パケットを握り潰すように設定されてい ない場合、LAN は、詐称された送信元アドレスに向けて応答パケット を生成するはめになり、犠牲となるマシンが飽和するところまで行っ てしまいます。攻撃者が同じトリックを異なるネットワーク上のいく つものブロードキャストアドレスに対して同時に使用した場合、とく にひどいことになります。これまでに、120 メガビット以上のブロー ドキャスト攻撃が観測されています。2 番目の踏み台攻撃は、ICMP エラー報告の仕掛けを狙うものです。攻撃者は ICMP エラー応答を生 成するパケットを生成し、サーバの受信ネットワークを飽和させ、そ の結果としてサーバが送信ネットワークを ICMP 応答で飽和させてし まうようにすることができます。mbuf を消費し尽くさせることによ り、この種の攻撃でサーバをクラッシュさせることも可能です。サー バが生成した ICMP 応答を十分速く送信できない場合、とくにひどい ことになります。FreeBSD カーネルには、この種の攻撃の効果を抑制する ICMP_BANDLIM と呼ばれる新しいカーネルコンパイルオプション があります。踏み台攻撃の 3 つめの主要なクラスに属する攻撃は、 udp echo サービスのような、特定の inetd 内部サービスに関連する ものです。攻撃者は、単に送信元アドレスがサーバ A の echo ポー トであり、送信先アドレスがサーバ B の echo ポートであるように UDP パケットを偽造します。ここでサーバ A, B はともにあなたの LAN に接続されています。この 2 つのサーバは、この一つのパケッ トを両者の間で互いに相手に対して打ち返しあいます。このようにし てパケットをほんのいくつか注入するだけで、攻撃者は両方のサーバ と LAN を過負荷状態にすることができます。同様の問題が内部 chargen ポートにも存在します。 有能なシステム管理者はこの手の inetd 内部テストサービスのすべてを無効にしておくものです。

偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を 生じさせるために用いられることもあります。 net.inet.ip.rtexpire, rtminexpire, rtmaxcache の sysctl パラメータを参照して下さい。でた らめな送信元 IP アドレスを用いた偽造パケット攻撃により、カーネ ルは、一時的なキャッシュ経路を経路情報テーブルに生成します。こ れは netstat -rna | fgrep W3 で見ることがで きます。これらの経路は、普通は 1600 秒程度でタイムアウトになり ます。カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを 検知すると、カーネルは動的に rtexpire を減らしますが、rtminexpire より小さくなるようには決して減らしません。ここに問題が 2 つあります。

1. 負荷の軽いサーバが突然攻撃された場合、カーネルが十分素 早く反応できないこと。

2. カーネルが持続的攻撃に耐えられるほど十分 rtminexpire が低く設定されていないこと。

自分のサーバが T3 もしくはそれより高速の回線でインターネッ トに接続されている場合、sysctl(8) を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いことといえます。どちらか 一方でも 0 には決してしないで下さい (自分のマシンをクラッシュ させたくないのであれば)。両パラメータを 2 秒 に設定すれば、攻撃から経路情報テーブルを守るには十分でしょう。

15.3.9. Kerberos および SSH を用いたアクセスの問題

もしあなたが、Kerberos と ssh を使いたいのだとしたら、 両者に関して言っておかねばならない問題がいくつかあります。 Kerberos V は大変優れた認証プロトコルですが、Kerberos 化された telnet や rlogin は、バイナリストリームを扱う のに不向きになってしまうようなバグがあります。さらに、デフォル トでは、Kerberos は -x オプションを使わない限 りセッションを暗号化してくれません。 ssh では、デフォルトですべてを暗号 化してくれます。

ssh はあらゆる場面でとても良く働いてくれます。 ただし、デフォルトで暗号鍵を転送してしまうこと を除けばです。これはつまり、暗号鍵を持った安全なワークステーショ ンがあって、この暗号鍵で残りのシステムとアクセスできるようになっ ている場合に、安全でないマシンへ ssh 接続を行なうとあなたの暗号鍵を使えてしまうということです。 実際の鍵そのものが見えてしまうわけではありませんが、 ssh はあなたが login している間、転送用ポートを作ります。攻撃者が安全でないマシンの root を破ったら、このポートを使って暗号鍵を取得し、 この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。

スタッフのログインには、Kerberos を組み合せた ssh を使用することを勧めます。 ssh は、Kerberos 対応機能と一緒 にコンパイルできます。こうすると、見えてしまうかもしれない ssh 鍵をあまりあてにしないで良いようになります。 また、それと同時に、Kerberos 経由でパスワードを保護することもできます。 ssh 鍵は、安全なマシンからの自動化されたタスク (Kerberos はこの用途には不向きです) のみに使用するべきです。また、 ssh の設定で鍵転送をしないようにするか、あるいは ssh が authorized_keys ファイル中に書くことを許 している from=IP/DOMAIN オプションを使用し て、特定のマシンからログインしてきたときのみ鍵が有効であるよう にすることも勧めます。