security(7)

security − FreeBSD におけるセキュリティ入門

セキュリティは、システム管理者とともに始まり、システム管理者とともに終る 機能です。 BSD マルチユーザシステムは、昔ながらのセキュリティをいくらかは 備えていますが、さらなるセキュリティ機構を組み込んで維持していくことで、 ユーザを ‘‘正直に’’ し続ける仕事は、システム管理者の最も大きな責務の一つ でしょう。マシンは、管理者が設定しただけのセキュリティしか示しません。セ キュリティに関する問題は、むしろ、便利さを求める人間との競合問題です。一 般に、 UNIX システムは莫大な数のプロセスを同時に実行させることができ、そ れも、サーバとして動作するものが多いのです。つまり、外部の何者かが接続し てきて、サーバプロセスと会話することができるということなのです。昨日まで 使われていたミニコンピュータやメインフレームは、今日ではデスクトップコン ピュータが取って代わり、しかも、それらはネットワークで結ばれてインター ネットと接続されるようになりました。これにより、セキュリティは昔と比べて はるかに大きな問題となっています。

セキュリティは、タマネギの階層のようなアプローチを通すと最もよく実装でき ます。手短に言って、やりたいことは、便利さを損ねない程度にできるだけ多く の階層を作り、システムに侵入されていないかを注意深く監視することです。セ キュリティの階層を作りすぎたくはありません。作りすぎると、侵入の検出が妨 げられることになるでしょう。どんなセキュリティ機構でも、侵入の検出をする ことが唯一とても重要なことなのですから。例えば、システムの各バイナリに schg フラグ ( chflags(1) 参照) を設定するのは大して意味がありません。この フラグを設定すると、一時的にはバイナリを保護することができますが、侵入し てきた攻撃者が容易に検知可能な変更をすることを妨げてしまい、結果として、 マシンのセキュリティ機構が攻撃者をまったく検知できなくなってしまうからで す。

システムセキュリティには、さまざまな形での攻撃に対処することもついて回り ます。攻撃には、root を破ろうとはしないが、システムをクラッシュさせたり、 さもなければ、システムを使用不能にしたりしようとするものも含まれていま す。セキュリティに関する問題は、いくつかのカテゴリに分類することができま す。

2. ユーザアカウントにかかる危険

3. アクセス可能なサーバを経由した root 権限にかかる危険

4. ユーザアカウントを通した root 権限にかかる危険

5. 裏口の作成

サービス不能攻撃とは、マシンから必要な資源を奪う行為です。サービス不能攻 撃は、普通は、そのマシンで実行されるサーバやネットワークスタックを圧倒し て、マシンをクラッシュさせたり、さもなければマシンを使えなくしたりするよ うな力任せの方法です。サービス不能攻撃のいくつかは、ネットワークスタック のバグを利用して、パケット一つでマシンをクラッシュさせようとします。後者 は、カーネルにバグ修正を施すことによってのみ修正することができます。サー バプロセスに対する攻撃は、オプションを適切に指定して、不利な状況にあるシ ステムにおいて、サーバプロセスが引き起こす負荷に限界を設けることで修正す ることができます。これらに比べると、ネットワークへの力任せの攻撃への対応 はずっと難しくなります。たとえば、偽造パケットによる攻撃 (spoof-packet attack) は、インターネットからシステムを切り離す以外の方法で防ぐことはほ とんど不可能です。それによって、マシンを落としてしまうことはできないかも しれませんが、インターネット回線をいっぱいにしてしまうことはできます。

ユーザアカウントを危険に晒してしまう問題は、サービス不能攻撃よりもずっと よくある問題です。このご時勢でも、自分たちのマシンで標準の telnetd(8), rlogind(8), rshd(8), ftpd(8) サーバを実行させているシステム管理者は多いの です。これらのサーバは、デフォルトでは、暗号化されたコネクション上で動作 していません。その結果、抱えているユーザ数が標準くらいであれば、リモート ログイン (そのシステムにログインするには最も普通で便利な方法です) してい るユーザのうち一人以上は、パスワードを覗き見られてしまうでしょう。システ ム管理者が注意深い人ならば、たとえログインが成功していたとしても、リモー トアクセスログを解析して、疑わしいソースアドレスを探すものです。

ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると、攻撃者が root の権限を破る可能性があることを仮定するべきです。しかし、セキュリティを十 分維持し、手入れの行き届いたシステムにおいては、あるユーザアカウントへの アクセスが可能となっても、攻撃者に必ずしも root へのアクセス権を与えると は限らないのが現実です。この違いは重要です。というのは、root へのアクセス 権がなければ、一般的に、攻撃者は自分の侵入の痕跡を隠蔽することができませ んし、そのユーザのファイルを引っかき回したり、マシンをクラッシュさせたり できるのがせいぜいです。ユーザアカウントが危険に晒されるということは、た いへんよく起こることです。なぜなら、ユーザは、システム管理者ほどには前 もって注意を払わない傾向があるからです。

システム管理者は、あるマシン上で root の権限を破る方法は、潜在的に何通り もあるのだということを心しておかねばなりません。攻撃者が root のパスワー ドを知ってしまうかもしれません。攻撃者が root の権限で実行されるサーバの バグを見つけ、ネットワークからそのサーバへ接続して root の権限を破ること ができるかもしれません。ひとたびユーザアカウントを破ると、ユーザアカウン トから root の権限を破ることが可能であるというバグを持つ SUID-root プログ ラムの存在を、攻撃者は知っているかもしれません。あるマシン上で、攻撃者が root の権限を破る方法を知ったとすると、攻撃者は、裏口を作る必要などないか もしれません。発見され、ふさがれた root の穴の多くには、攻撃者が侵入した 跡を消そうとしてたくさん仕事した結果が含まれています。そのためにこそ、多 くの攻撃者は裏口を作るのです。この裏口は、攻撃者の検出をするのに便利なや り方です。攻撃者に裏口を作らせないようにするということは、セキュリティに とっては実際には良くないことかもしれません。なぜなら、そうすることで、攻 撃者が最初に侵入してくるために使用したセキュリティホールがふさがるわけで はないからです。

セキュリティを改善する方法は、常に、 ‘‘タマネギの皮剥き’’ のように複数の 層のアプローチで実装されるべきです。これらは次のように分類できます。

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

2. root の安全性を高める — root 権限のサーバと SUID/SGID バイナ リ。

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

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

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

6. システムに対して行なった、不適切な変更をすばやく検出する。

7. 偏執狂的方法。

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

root のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性 をうんぬんしてもしかたがありません。ほとんどのシステムでは、root アカウン トに割り当てたパスワードが 1 つあります。まず最初にすべきことは、このパス ワードは いつでも危険に晒されていると仮定することです。ここでは、root の パスワードを消すべきだと言っているのではありません。パスワードは、マシン にコンソールからアクセスするのには、ほとんどいつでも必要なものです。ここ で言いたいのは、コンソール以外からは、おそらくは、 su(1) ユーティリティを 用いてすらパスワードを使えるようにするべきではないということです。例え ば、PTY が、 /etc/ttys ファイルで ‘‘unsecure’’ と指定されているかを確認し てください。そうすることで、 telnet(1) や rlogin(1) 越しに root でログイ ンできないようになります。 sshd(8) のような、別のログインサービスを使って いる場合でも同様に、直接 root へログインすることを許していないかどうか確 認してください。アクセスする手段、例えば ftp(1) のようなサービスが、たび たびクラックの手に落ちることを考えてみてください。root に直接ログインでき るのは、システムコンソールを通したときのみにすべきです。

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

root アカウントの安全性を高める間接的な方法として、別のログインアクセスの 方法を用いて、スタッフのアカウントの暗号化パスワードを * にしておくこと で、スタッフのアカウントの安全性を高めるものがあります。この方法だと、侵 入者はパスワードファイルを盗むことができるかもしれませんが、スタッフアカ ウントを破ることはできないでしょう。また、たとえ root が暗号化パスワード をパスワードファイルに付けていたとしても、 root アカウントも破ることはで きないでしょう (もちろん、コンソールへの root によるアクセスが限定されて いるものとします)。スタッフメンバがスタッフアカウントでログインする際に は、 kerberos(1) や ssh(1) のような、公開鍵 / 秘密鍵の鍵の組を使う安全性 の高いログインの仕組みを使います。Kerberos のような仕掛けを使う場合、一般 に、Kerberos サーバを実行するマシンと自分のデスクトップワークステーション との安全性を確保しなければなりません。SSH で公開鍵 / 秘密鍵の組を使う場 合、一般に、ログイン 元マシン (通常は自分のワークステーション) の安全性を 確保しなければなりません。ここで、 ssh-keygen(1) で公開鍵 / 秘密鍵の組を 生成する際、鍵の組をパスワードで防御することにより、鍵の組への防御層を追 加することもできます。スタッフアカウントのパスワードを * で外すことができ ると、管理者自身が設定した安全性の高い方法でしかスタッフメンバがログイン できないことも保証できます。こうして、多くの侵入者が使う重大なセキュリ ティの穴 (安全性の低い無関係なマシンからネットワークを覗き見る方法) を塞 ぐようなセッションを提供する、安全性の高い暗号化されたコネクションを使う ことを、スタッフメンバ全員に強制することができるのです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NFS ではなく、SSH を使用する場合は、セキュリティ用スクリプトを書くのは ずっと難しいことです。スクリプトをクライアントから見えるようにし、動かす ためには、クライアントに対して scp(1) を必ず行わなくてはいけません。そし て、安全のため、スクリプトが使うバイナリ ( find(1) など ) を scp(1) する 必要もあります。クライアントの sshd(8) デーモンはすでに危険に晒されている かもしれません。以上のことから、安全でないリンク上の場合は SSH は必要かも しれませんが、 SSH を扱うのはとても大変なことです。

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

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

プロセスアカウンティング ( accton(8) 参照) は、比較的オーバヘッドの低いオ ペレーティングシステムの機能で、マシンに侵入されてしまった後の評価の仕組 みとして使用することをお勧めします。侵入を受けた後でも当該ファイルが無傷 である場合に、侵入者が実際にどのようにしてシステムに侵入したかを追跡する のに特に有益です。

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

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

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

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

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

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

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

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

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

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

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

偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を生じさせるため に用いられることもあります。 net.inet.ip.rtexpire, net.inet.ip.rtminexpire, net.inet.ip.rtmaxcache の sysctl(8) パラメータを 参照して下さい。でたらめなソース IP を用いたこの偽造パケット攻撃により、 カーネルは、一時的なキャッシュ経路を経路情報テーブルに生成します。これは ‘‘netstat -rna | fgrep W3’’. で見ることができます。これらの経路は、普通 は 1600 秒程度でタイムアウトになります。カーネルがキャッシュ経路テーブル が大きくなり過ぎたことを検知すると、カーネルは動的に rtexpire を減らしま すが、 rtminexpire より小さくなるようには決して減らしません。ここに問題が 2 つあります。 (1) 負荷の軽いサーバが突然攻撃された場合、カーネルが十分素 早く反応できないこと。(2) カーネルが攻撃に耐え生き延びられるほど十分 rtminexpire が低く設定されていないこと。の 2 つです。自分のサーバが T3 も しくはそれより良質の回線でインターネットに接続されている場合、 sysctl(8) を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いこ とといえます。 (自分のマシンをクラッシュさせたくないのであれば :-)) どち らか一方でも 0 には決してしないで下さい。両パラメータを 2 秒に設定すれ ば、攻撃から経路情報テーブルを守るには十分でしょう。

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

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

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

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

chflags(1), find(1), md5(1), netstat(1), openssl(1), ssh(1), xdm(1), group(5), ttys(5), accton(8), init(8), sshd(8), sysctl(8), syslogd(8), vipw(8)

security マニュアルページは、もともと Matthew Dillon によって書かれ、 1998 年 12 月に FreeBSD 3.1 ではじめて登場しました。

FreeBSD 10.0 September 18, 1999 FreeBSD 10.0