15.2. はじめに

セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。 すべての BSD Unix マルチユーザシステムは、 従来からいくつかのセキュリティ機構を備えていますが、 ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し 保守する仕事はおそらく、システム管理者としてもっとも大きな責務の一つでしょう。 マシンの安全性に反映されるのは、管理者が作業したことだけです。 またセキュリティ問題は、快適な環境に必要なものと競合します。 一般に Unix システムは膨大な数のプロセスを同時に動作させることができ、 そのプロセスの大部分は、サーバ – 外部から接続し、通信するものとして動作します。 かつてのミニコンとメインフレームがデスクトップにとってかわり、 さらにコンピュータが相互に接続されたネットワークを形成するようになった今日、 セキュリティは一層大きな関心事になってきています。

セキュリティを実装するには、 タマネギのように階層化する手法 (a layered “onion” approach) が最適です。 どうすれば良いのか簡単に説明すると、 便利な機能と同じ数だけセキュリティの階層を作り、 システムへの侵入を注意深く監視するのです。 あなたはセキュリティを過度に厳重にしたり、 侵入の監視に時間をとられたいとは思わないでしょう。 この侵入の発見という部分は、 あらゆるセキュリティ機構において最も重要な部分の一つなのです。 たとえば、システムの各バイナリに schg フラグ (chflags(1) 参照) を設定するのは、大して意味がありません。 フラグを設定すると一時的にバイナリが保護され、 侵入してきた攻撃者によってシステムに加えられる変更のうち、 容易に検出可能な変更は行なえなくなります。 しかしその結果として、セキュリティ機構がその侵入者を検出することも まったくできなくなってしまうでしょう。

また、システムセキュリティには、 さまざまな形での攻撃に対処することとも関係しています。 攻撃の中には root 権限を奪おう (“root 権限を破る”) とはしないけれども、 クラッシュやシステムの不安定状態を引き起こそうとするものもあります。 このセキュリティ問題は、いくつかに分類することが可能です。

1. サービス妨害攻撃 (denial of service attack)

2. ユーザアカウントの不正利用 (user account compromise)

3. アクセス可能なサーバを使った root 権限の不正利用

4. ユーザアカウントを経由した root 権限の不正使用

5. バックドアの設置

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

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

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

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

セキュリティを改善する方法は、常に、 タマネギの皮のように階層化する手法 (a multi-layered “onion peel” approach) で実装されるべきです。これらは次のように分類できます。

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

2. root の安全性を高める – root 権限で動作するサーバと suid/sgid バイナリ。

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

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

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

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

7. 必要と思われる以上の対応をとる (paranoia)。

本章の次の節では、上記の各項目についてより深く掘り下げていき ます。