日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。
4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)
13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。
Table of Contents
SECURITY(7) FreeBSD 多方面の情報マニュアル SECURITY(7)
名称
security -- FreeBSD の元でのセキュリティの入門
解説
セキュリティは、システム管理者から始めて終了する機能です。すべての BSD マ
ルチユーザシステムには、いくつかの本来備わっているセキュリティがあります
が、ユーザを ``正直に'' 保つのために構築するジョブと維持されている追加の
セキュリティメカニズムは、たぶん sysadmin の単一の最大の仕事の 1 つです。
マシンは、単にそれらを行うのと同じくらい安全で、セキュリティの問題は、い
つも便宜上人間の必要と競争します。一般的に、UNIX システムは、同時に存在す
るプロセスの莫大な数を実行することができ、これらのプロセスの多くは、サー
バとして動作します -- 外部に存在するものが、それらに接続し通信することが
できることを意味します。昔のミニコンピュータとメインフレームのようなもの
は、今日のデスクトップとなり、コンピュータがネットワークにつながりイン
ターネットワークにつながれるようになるとともに、セキュリティは、さらに大
きな問題となります。
セキュリティは、階層化されたオニオンアプローチを通して最もよく実装されま
す。nutshell で、利用者が行いたいものは、セキュリティの多くの層が便利なの
と同じくらい作成することで、次に、侵入のためのシステムを慎重に監視するこ
とです。
システムセキュリティは、また、クラッシュすることを試みる攻撃を含んで、攻
撃の様々な形式を扱うことに関連しています、そうでなければシステムを使用で
きなくしますが、root を破ることを試みません。いくつかのカテゴリにセキュリ
ティの懸案事項を分割することができます:
1. サービス拒否攻撃 (DoS)
2. ユーザアカウントを危険にさらすこと
3. アクセス可能なサーバを通して root を危険にさらすこと
4. ユーザアカウントを通して root を危険にさらすこと
5. 裏口の作成
サービス拒否攻撃は、必要なリソースをマシンから奪う動作です。通常、サービ
ス拒否攻撃 (DoS) は、クラッシュを試みるか、またはそうでなければ、圧倒的な
そのサーバまたはネットワークスタックよってマシンを使用できなくすることを
試みる強力なメカニズムです。いくつかのサービス拒否攻撃 (DoS) は、単一のパ
ケットでマシンをクラッシュするために、ネットワークスタックのバグをうまく
利用しようとします。後者は、カーネルにバグ修正を適用することによってのみ
修正することができます。サーバへの攻撃は、しばしば、悪条件の下のシステム
でサーバが被るロードを制限するためにオプションを適切に指定することによっ
て修正することができます。強力なネットワーク攻撃は、より扱いづらくなりま
す。例えば、偽造パケット攻撃は、インターネットから利用者のシステムを切り
離すことを除いて停止することはほとんど不可能です。利用者のマシンを停止す
ることはできませんが、利用者のインターネットのパイプを満たすことができま
す。
ユーザアカウントを危険にさらすことは、サービス拒否攻撃 (Dos) よりさらに一
般的です。多くのシステム管理者 (sysadmin) は、それらのマシンで標準の
telnetd(8) と ftpd(8) をまだ実行します。これらのサーバは、デフォルトで、
暗号化された接続上で動作しません。利用者が、中規模のユーザベースであるな
ら、(システムにログインする最も一般的で、便利な方法である) リモート位置か
ら利用者のシステムにログインしている利用者のユーザの 1 人以上は、各自のパ
スワードを盗聴されるかもしれない結果となります。用心深いシステム管理者
は、成功したログインに対してさえ不審な送信元アドレスを検索してリモートア
クセスログを解析します。
いったん攻撃者がユーザのアカウントへのアクセスがあると、攻撃者が root を
破ることができることを常に仮定しなければなりません。しかしながら、現実
は、十分に安全で、維持されたシステムであり、ユーザアカウントへのアクセス
は、必ずしも root への攻撃者のアクセスを与えられられません。root へのアク
セスなしで、攻撃者は、一般的に攻撃者の軌跡を隠すことができず、せいぜい、
単にユーザのファイルに干渉するか、またはマシンを破損することにとどまらず
何も行わないので、違いは、重要です。ユーザが、システム管理者 (sysadmin)
が取る予防措置を行わない傾向があるので、ユーザアカウントのセキュリティ侵
害は、よく見られることです。
システム管理者は、潜在的に、マシンの root を破るための多くの方法があるこ
とを心に留めていなければなりません。攻撃者は、root のパスワードを知ってい
ますかもしれず、攻撃者は、root で実行しているサーバにバグを見つけるかもし
れず、そのサーバとのネットワーク接続を越えて toot を破ることができるか、
または攻撃者は、いったん攻撃者がユーザのアカウントを破られると、攻撃者が
root を破ることができる SUID root プログラムのバグを知っているかもしれま
せん。攻撃者が、マシンの root を破るための方法を見つけたなら、攻撃者は、
バックドア (裏口) をインストールする必要はありません。root のホール (穴)
の多くが、見つけられ、攻撃者自身の後をクリーンアップするために攻撃者に
よってかなりの量の動作を含む日付をクローズされるので、ほとんどの攻撃者
は、バックドア (裏口) をインストールします。これは、利用者に、攻撃者を検
出するための便利な方法を与えます。バックドア (裏口) をインストールするこ
とを不可能にすることは、元もと攻撃者が破るために使用した穴を閉じないの
で、実際、利用者のセキュリティに有害であるかもしれません。
セキュリティの改善方法は、常にマルチレイヤの ``オニオン皮'' アプローチで
実装されるべきで、次のように分類することができます:
1. ルートとスタッフのアカウントの安全
2. root の安全 -- root で実行するサーバと SUID/SGID バイナリ
3. ユーザアカウントの安全
4. パスワードファイルの安全
5. カーネルのコア、raw デバイスとファイルシステムの安全
6. システムに行われた不適切な変更の迅速な検出
7. パラノイア (偏執症)
root アカウントの安全とスタッフアカウントの安全
利用者が root のアカウントの安全を確保しなかったなら、スタッフのアカウン
トの安全の確保を煩わせることはありません。ほとんどのシステムは、root アカ
ウントに割り当てられたパスワードがあります。利用者が行う最初のことは、パ
スワードが常に危険にさらされていることを仮定することです。これは、利用者
がパスワードを削除するべきであることを意味しません。パスワードは、ほとん
どの場合マシンへのコンソールアクセスのために必要です。それが意味している
ものは、利用者が、コンソールの外側でパスワードを使用するか、またはたぶん
su(1) ユーティリティと同様に使用を可能にするべきではないことです。例え
ば、利用者の PTY は、telnet(1) を通して直接的な root のログインが許可され
ないように、/etc/ttys ファイルで ``insecure'' であるように指定されている
ことを確かめてください。sshd(8) のような他のログインサービスを使用してい
るなら、直接的なルートのログインが同様に、無効にされていることを確かめて
ください。ftp(1) のようなサービスが、しばしば、クラックの手に落ちる -- す
べてのアクセス方法を考慮してください。直接的なルートのログインは、システ
ムコンソールを通してのみ許可されるべきです。
もちろん、システム管理者 (sysadmin) として、利用者は、root になることがで
きなければならないので、少しの穴 (ホール) を開けます。しかし、操作するこ
れらの穴 (ホール) が追加のパスワードの検証を必要とすることをよく確かめま
す。root をアクセス可能にするための一方の方法は、適切なスタッフアカウント
を (/etc/group の) ``wheel'' グループに追加することです。wheel グループに
置かれたスタッフメンバは、root に su(1) で root になることを許可します。
利用者は、決して、それらのパスワードエントリで wheel グループにそれらを置
くことによってスタッフメンバにネイティブの wheel アクセスを与えるべきでは
ありません。スタッフアカウントは、``staff'' グループに置くべきで、次に、
/etc/group ファイルを通して wheel グループに追加するべきです。実際に root
アクセスが必要であるそれらのスタッフメンバだけが、wheel グループに置かれ
るべきです。それは、また、Kerberos のような認証方法を使用するとき、wheel
グループに誰も置く必要なしに root に ksu(1) を許可する root アカウントで
Kerberos の .k5login ファイルを使用することが可能です。wheel メカニズム
は、侵入者が利用者のパスワードファイルを手に入れて、スタッフアカウントに
入り込むことができるなら、侵入者が root を破ることを可能にするので、これ
は、よりよい解決策になります。wheel メカニズムがあることは、何もないこと
より良く、必ずしも最も安全なオプションではありません。
ルートアカウントを安全にするための間接的な方法は、代わりのログインアクセ
ス方式とスタッフアカウントのための暗号化されたパスワードを * で外すことを
使用して利用者のスタッフアカウントを安全にすることです。このように、侵入
者は、パスワードファイルを盗むことができるかもしれませんが、たとえ root
が、(もちろん、利用者は、コンソールへの root アクセスを制限することを仮定
する) それに関連した暗号化されたパスワードがあったとしても、スタッフアカ
ウントまたは root を破ることはできないでしょう。スタッフメンバは、秘密鍵/
公開鍵のペアを使用して kerberos(8) または ssh(1) のような安全なログインメ
カニズムを通してそれらのスタッフアカウントの中に入ます。利用者が Kerberos
のような何かを使用するとき、利用者は、一般的に、Kerberos サーバと利用者の
デスクトップのワークステーションを実行するマシンを安全にしなければなりま
せん。利用者が SSH で公開鍵/秘密鍵のペアを使用するとき、利用者は、一般的
に利用者が、(通常、利用者のワークステーション) from にログインしているマ
シンを安全にしなければなりませんが、利用者は、また、利用者が、ssh-
keygen(1) でそれを作成するとき、鍵ペアを保護しているパスワードによって保
護の追加のレイヤを鍵ペアに追加することができます。また、スタッフアカウン
トのためのパスワードを星印 (*) で外すことができることは、利用者が設定した
安全なアクセス方法を通してログインのみできることを保証します。したがっ
て、利用者は、多くの侵入者によって使用される重要な穴 (ホール) を塞ぐすべ
てのそれらのセッションのための暗号化された接続を安全に使用するすべてのス
タッフメンバを強制することができます: 関係のない、それほど安全ではないマ
シンからネットワークを除き見するもの。
また、より間接的なセキュリティのメカニズムは、利用者がより制限されたサー
バからそれほど制限されていないサーバにログインすることを仮定します。例え
ば、利用者のメインボックスがすべての種類のサーバを実行しているなら、利用
者のワークステーションは、どれも実行するべきではありません。利用者のワー
クステーションを適度に安全とするためには、利用者は、全くサーバなしを含む
それ以下のできるだけ少しのサーバで実行するべきで、利用者は、パスワードで
保護された画面ブランカ (blanker) を実行するべきです。もちろん、ワークス
テーションへの物理的なアクセスを与え、攻撃者は、利用者がそれに置く、あら
ゆる種類のセキュリティを破ることができます。これは、利用者が考慮するべき
明確な問題ですが、利用者のワークステーションまたはサーバに物質的にアクセ
スできない人々からネットワークを越えて、また、利用者は、リモートで起こる
侵入の大部分の事実も考慮するべきです。
Kerberos のような何かを使用することは、また、1 つの場所のスタッフアカウン
トのためのパスワードを無効にするか、または変更する能力を利用者に与え、ス
タッフメンバのアカウントがあるすべてのマシンに直ちに影響します。スタッフ
メンバのアカウントに障害が起こるなら、すべてのマシンでスタッフメンバのパ
スワードを直ちに変更する能力を過小評価されるべきではありません。個別のパ
スワードで、N マシンのパスワードを変更することは、混乱するかもしれませ
ん。利用者は、Kerberos で再びパスワードを付けることの制限を与えることがで
きます: しばらくしてから、タイムアウトを行うことができる Kerberos チケッ
トのみならず、Kerberos システムは、ユーザが時間の特定の期間の後に、新しい
パスワードを選択することを必要とするかもしれません (例えば、1 ヵ月に 1
回)。
root の安全 -- root で実行するサーバと SUID/SGID バイナリ
用心深いシステム管理者 (sysadmin) は、それ以上でもそれ以下でもなく必要な
サーバを実行するだけです。しばしばサードパーティのサーバは、よりバグが発
生しやすいことに注意してください。例えば、imapd(8) または popper(8)
(ports/mail/popper) の古いバージョンを実行することは、全世界に世界共通の
ルートのチケットを与えるようなものです。利用者が慎重にチェックしなかった
サーバを決して実行してはいけません。多くのサーバは、ルートとして実行され
る必要はありません。例えば、特別なユーザの ``sandbox'' で talkd(8),
comsat(8) と fingerd(8) デーモンを実行することができます。サンドボックス
(sandbox) は、利用者がとても苦労することがないなら、完全ではありません
が、セキュリティへのオニオン (タマネギ) のような階層構造にするアプローチ
(onion approach) は、まだ持ちこえています: 誰かが、サンドボックスで実行し
ているサーバを通して押し入ることができるなら、彼らは、まだサンドボックス
の外に脱出しなければなりません。攻撃者が打ち破らなければならないより多く
の層は、攻撃者の成功の可能性をより低くします。ルートの穴は、歴史的に、基
本的なシステムサーバを含んで、これまで、ルートとして実行される実質的にす
べてのサーバで見つけられます。人々が、sshd(8) を通してのみログインし、決
して telnetd(8) を通してログインしないマシンを通して利用者が実行している
なら、それらのサービスをオフにしてください!
FreeBSD は、現在、サウンドボックで、talkd(8), comsat(8) と fingerd(8) を
実行していることをデフォルトとしています。利用者が新しいシステムをインス
トールしているか、または既存のシステムをアップグレードするかどうかに依存
して、これらのサンドボックスによって使用される特別なユーザアカウントは、
インストールされません。用心深いシステム管理者 (sysadmin) は、可能なとき
はいつでも、サーバのためのサンドボックスを研究して、実装します。
通常、サンドボックスで実行しない多くの他のサーバがあります: sendmail(8),
popper(8), imapd(8), ftpd(8) などです。これらのいくつかの代案があります
が、それらをインストールすることは、利用者が自発的に置くより多くの作業を
必要とするかもしれません (便利さのファクタは、再び打ちます)。利用者は、
root として、これらのサーバを実行しなければならず、それらを通して起こるか
もしれない侵入を検出する他のメカニズムを信頼しなければなりません。
システムの他の大きな潜在的なルートの穴は、システムにインストールされた
SUID root と SGID バイナリです。su(1) のような、これらのバイナリのほとん
どは、/bin, /sbin, /usr/bin または /usr/sbin に存在します。100% 安全なも
のはありませんが、システムデフォルトの SUID と SGID バイナリは、適度に安
全であると見なすことができます。いまだに、root の穴は、時々これらのバイナ
リに見つかります。root の穴は、(通常、SUID である) xterm(1)
(ports/x11/xterm) を脆弱にした、1998 年に Xlib で見つかりました。それは、
残念と思うより安全であることがよりよく、用心深いシステム管理者 (sysadmin)
は、スタッフだけがアクセスすることができる特別なグループにスタッフだけ
が、実行するべき SUID バイナリを制限し、誰も使用しないあらゆる SUID バイ
ナリ (``chmod 000'') の rid を取得します。一般的にディスプレイがないサー
バは、xterm(1) バイナリを必要としません。SGID バイナリは、ほとんど危険で
あるかもしれません。侵入者が SGID kmem バイナリを破ることができるなら、侵
入者は、/dev/kmem を読み込むことができ、したがって、暗号化されたパスワー
ドファイルを読み込み、あらゆるパスワード化されるアカウントを潜在的にセ
キュリティ侵害することになります。代わりに、グループ ``kmem'' を破る侵入
者は、安全な方法を通してログインするユーザによって使用された PTY を含ん
で、PTY を通して送信されたキーストロークを監視することができます。``tty''
グループを破る侵入者は、ほとんどあらゆるユーザの TTY に書く込むことができ
ます。ユーザが、キーボードのシミュレーション機能がある端末プログラムまた
はエミュレータを実行しているなら、侵入者は、ユーザの端末が、そのユーザと
して実行されるコマンドをエコーする、データストリームを潜在的に生成するこ
とができます。
ユーザアカウントの安全性
ユーザアカウントは、通常安全であることは最も難しいことです。利用者は、利
用者のスタッフとそれらのパスワードを * で外し、厳格なアクセス制限を課すこ
とができますが、利用者は、持っているかもしれない、あらゆる一般的なユーザ
アカウントで、そうすることができないかもしれません。利用者に十分な制御が
あるなら、利用者は、勝ち抜き、ユーザアカウントを適切に確保することができ
ます。そうでなければ、利用者は、単に、それらのアカウントの監視でより用心
深くしなければなりません。ユーザアカウントのための SSH と Kerberos の使用
は、要求される特別の管理と技術的なサポートのためにより問題となりますが、
それでも、暗号化されたパスワードファイルと比較する非常によい解決策です。
パスワードファイルの安全性
唯一の確実な発火方法は、できるだけより多くのパスワードを * で外すことで、
それらのアカウントへのアクセスのための SSH または Kerberos を使用します。
たとえ暗号化されたパスワードファイル (/etc/spwd.db) がルートによってのみ
読み込みできるとしても、たとえ攻撃者がルートの書き込みアクセスを得ること
ができなくても、そのファイルへの読み込みアクセスを取得することが侵入者に
可能となります。
利用者のセキュリティのスクリプトは、常にパスワードファイルへの変更を
チェックし、報告するべきです (以下のファイルの整合性のチェックを参照)。
カーネルのコア、raw デバイスとファイルシステムの安全
攻撃者が root を破るなら、彼は、ほぼ何でも行なうことができますが、特定の
便利さがあります。例えば、ごく最近のカーネルは、組み込まれたパケットの覗
き見するデバイスドライバがあります。FreeBSD の下で、それは、bpf(4) デバイ
スと呼ばれます。侵入者は、通常、信用できなくなったマシンのパケットの覗き
見を実行することを試みます。利用者は、侵入者に機能を与える必要はなく、ほ
とんどのシステムは、コンパイルされている bpf(4) デバイスがあるべきではあ
りません。
しかし、たとえ利用者が bpf(4) デバイスをオフに切り替えても、利用者は、ま
だ、心配な /dev/mem と /dev/kmem があります。そのことについては、侵入者
は、まだ raw (生の) ディスクデバイスに書き込むことができます。また、モ
ジュールローダ kldload(8) と呼ばれる別のカーネル機能があります。積極的な
侵入者は、彼自身の bpf(4) デバイスまたは実行しているカーネルで他の覗き見
デバイスをインストールするために KLD モジュールを使用することができます。
これらの問題を避けるために、利用者は、より高いセキュリティレベル、少なく
ともレベル 1 で、カーネルを実行しなければなりません。kern.securelevel 変
数について sysctl(8) でセキュリティレベルを設定することができます。いった
ん利用者がセキュリティレベルを 1 に設定すると、raw (生の) デバイスへの書
き込みアクセスは、拒否され、schg のような、特別の chflags(1) フラグが、強
制されます。また、利用者は、セキュリティレベルが設定されるポイントまで、
実行するものすべて -- schg フラグが重大なスタートアップバイナリ、ディレク
トリとスクリプトファイルで設定されることを保証しなければなりません。これ
は、大げさであるかもしれず、システムをアップグレードすることは、利用者が
より高いセキュリティレベルで操作するとき、より難しくなります。利用者は、
より高いセキュリティレベルでシステムを危険にさらして、実行しますが、すべ
てのシステムファイルとありとあらゆるディレクトリのために schg フラグを設
定しません。別の可能性は、単に / と /usr を読み込み専用でマウントすること
です。利用者が、保護することを試みるものをあまりに厳格とすることは、侵入
の極めて重要な検出を防止することに注意するべきです。
カーネルは、5 つの違ったセキュリティレベルで実行します。スーパユーザのプ
ロセスは、レベルを上げることができますが、どんなプロセスもそれを下げるこ
とはできません。セキュリティレベルは、次の通りです:
-1 永久に不安全なモード - 不安全なモードでシステムを常に実行します。こ
れは、デフォルトの初期値です。
0 不安全なモード - 不変、追加専用フラグをオフに切り替えることができま
す。すべてのデバイスは、それらのパーミッションに従って読み込みまた
は書き込みすることができます。
1 安全モード - システム不変とシステム追加専用フラグを切り替えることが
できます。マウントされたファイルシステム、/dev/mem と /dev/kmem の
ためのディスクは、書き込みのためにオープンすることができません。
/dev/io (利用者のプラットフォームにそれがあるなら) は、全くオープン
されません。カーネルモジュール (kld(4) 参照) は、ロードするか、また
はアンロードできません。カーネルデバッガは、debug.kdb.enter sysctl
を使用して入力されません。パニックまたはトラップを、
debug.kdb.panic, debug.kdb.panic_str と他の sysctl を使用して強制す
ることができません。
2 高度な安全モード - 安全モードと同じですが、さらに、マウントされてい
るか、マウントされていないかに関係なく (mount(2) を除いて) ディスク
は、書き込みのためにオープンすることができません。このレベルは、そ
れらをアンマウントすることによってファイルシステムを不正に改ざんす
ることを排除しますが、システムがマルチユーザの間に、newfs(8) を実行
することも禁止します。
さらに、カーネルの時刻の変更は、1 秒以下に制限されます。これ以上の
時間を変更する試みは、``Time adjustment clamped to +1 second'' (時
間の調整は、+1 秒に固定されます) というメッセージがログ登録されま
す。
3 ネットワーク安全モード - 高度な安全モードと同じですが、さらに、IP
パケットフィルタ規則 (ipfw(8), ipfirewall(4) と pfctl(8) 参照) は、
変更することができず、dummynet(4) または pf(4) 設定は、調整すること
ができません。
rc.conf(5) に文書化された変数で、セキュリティレベルを設定することができま
す。
ファイルの整合性のチェック: バイナリ、設定ファイルなど
それについて現実的によく考えてみると、利用者は、利用者のコアシステムの設
定のみを保護することができます、便利さの要素が顕在化する前にそれほどの
ファイルを制御します。例えば、/ と /usr のほとんどのファイルで schg ビッ
トを設定するために chflags(1) を使用することは、ファイルを保護される間
に、それが検出ウィンドウもクローズするので、おそらく逆効果です、利用者の
セキュリティオニオン (security onion) の最後のレイヤ (層) は、たぶん最も
重要な -- 検出です。訳注: security onion は、Ubuntu ベースの侵入検知、セ
キュリティ監視です。利用者のセキュリティの残りは、利用者が潜在的な侵入を
検出することができないなら、ほどんど役に立たない (か、またはより悪い、セ
キュリティの錯覚がある利用者の存在)。オニオンの半分のジョブは、動作中に攻
撃者を捕獲する検出の層のチャンスを与えるために攻撃者を止めるのではなく、
攻撃者の速度を落すことです。
侵入を検出する最も良い方法は、ファイルが修正される、ファイルが失われる
か、または予期しないファイルを検索することです。修正されたファイルを検索
するのに最も良い方法は、他の (しばしば集中される) アクセスが制限されたシ
ステムからです。特別に安全な制限されたアクセスシステムで利用者のセキュリ
ティのスクリプトを書くことは、潜在的な攻撃者にそれらをほとんど見えなくし
ます、そしてこれは、重要です。最大限に利用するために、利用者は、一般的に
ビジネスの他のマシンに制限されたアクセスボックス重要なアクセスを与えられ
なければなりません、通常、制限されたアクセスボックスへの他のマシンの読み
込み専用 NFS エクスポートをすることによる、または、制限されたアクセスボッ
クスを他のマシンに SSH することを許可するために SSH 鍵ペア (keypair) を設
定することによることのいずれかです。そのネットワークトラフィックを除い
て、利用者が事実上検出されない各クライアントボックスのファイルシステムを
監視することを可能にして -- NFS は、最小の可視の方法です。利用者の制限さ
れたアクセスサーバがスイッチを通してクライアントボックスと接続されている
なら、NFS の方法は、しばしばよりよい選択です。利用者の制限されたアクセス
サーバがハブを通して、または経路制御のいくつかの層 (レイヤ) を通してクラ
イアントボックスに接続されるなら、NFS 方法は、あまりにも安全でなく (ネッ
トワークの観点で) と使用している SSH は、SSH が置かれる監査トレーストラッ
クと同等でよりよい選択であるかもしれません。
いったん利用者が、監視すると思われているクライアントシステムに、少なくと
も読み込みアクセスで制限アクセスボックスを与えると、利用者は、実際の監視
をするために、スクリプトを書かなければなりません。NFS マウントが与えられ
て、利用者は、find(1) と md5(1) のような簡単なシステムユーティリティのた
めにスクリプトを書くことができます。少なくとも 1 日に 1 回クライアント
ボックスファイルのボックスを物理的に md5(1) を行い、さらにしばしば /etc
と /usr/local/etc で見つかるような制御ファイルをテストすることは、最もよ
いことです。制限されたアクセスの知られているマシンが有効である基本の MD5
情報と関連する不一致が見つかるとき、チェックするシステム管理者 (sysadmin)
に叫び声をあげるべきです。よいセキュリティのスクリプトは、また、不適切な
SUID バイナリをチェックし、/ と /usr のようなシステムパーティションで新し
いファイルまたは削除されたファイルをチェックします。
NFS でなく SSH を使用するとき、セキュリティのスクリプトを書くことは、ずっ
と難しいことです。利用者は、本質的に、それらを実行するために、それらを見
えるようにし、安全のために、それらのスクリプトが使用する (find(1) のよう
な) バイナリを scp(1) する必要もあり、クライアントボックスへのスクリプト
を scp(1) しなければなりません。クライアントボックスの sshd(8) デーモン
は、すでに障害が起きたかもしれません。全体に、SSH を使用することは、安全
でないリンク上で実行しているとき、必要とされますが、また、それを扱うこと
は、大変困難です。
また、よいセキュリティのスクリプトは、ユーザとスタッフメンバのアクセス設
定ファイルの変更をチェックします: .rhosts, .shosts, .ssh/authorized_keys
その他、MD5 チェックの範囲から外れているかもしれないファイル。
利用者にユーザのディスク空間に莫大な量があるなら、それらのパーティション
ですべてのファイルを通して実行するには時間がかかりすぎるかもしれません。
この場合に、それらのパーティションで SUID バイナリを許可しないマウントフ
ラグを設定することは、よい考えです。nosuid オプション (mount(8) を参照)
は、利用者が調べたいものです。この層 (レイヤ) のオブジェクトは、侵入が効
率的であるかどうかにかかわらず、侵入を検出することであるので、すくなくと
も週に 1 回とにかく、それらをスキャンします。
プロセスのアカウンティング (accton(8)) を参照) は、侵入後の評価メカニズム
として使用することを勧めるオペレーティングシステムの比較的に低いオーバ
ヘッドの機能です。侵入が起こった後に、ファイルがまだそのままであると仮定
して、どのように実際に、侵入者がシステムに侵入したかを突きとめることに特
に役に立ちます。
最後に、セキュリティのスクリプトは、ログファイルを処理するべきで、ログ自
体は、できるだけ安全な方法で生成されるべきです -- リモート syslog は、非
常に有益にすることができます。侵入者が彼の軌跡を覆い隠すことを試み、ログ
ファイルは、初期の侵入の時間と方法を突きとめようとしているシステム管理者
(sysadmin) のために重要な意味を持ちます。ログファイルの永続的なレコードを
保存する 1 つの方法は、シリアルポートにシステムコンソールを実行すること
で、コンソールを監視している安全なマシンを通して継続して情報を収集するこ
とです。
パラノイア (偏執症)
わずかなパラノイアは、決して害を与えることはありません。概して、システム
管理者 (sysadmin) は、それらが便利さに影響しない限り、かなり多くのセキュ
リティ機能を追加することができ、いくつかの追加された考えによって便利さに
影響するセキュリティ機能を追加することができます。さらに重要なことでさ
え、セキュリティ管理者は、すこしまぜこぜにするべきです -- 利用者が、逐語
的なこのマニュアルページによって与えられるそれらのような提案を使用するな
ら、利用者は、常にこのマニュアルページにもアクセスすることができる予想さ
れる攻撃者に利用者のやり方を与えます。
オンサービス拒否攻撃 (DoS attack) の特別のセクション
このセクションは、サービス拒否攻撃 (Denial of Service attack) を対象にし
ています。Dos 攻撃は、通常、パケット攻撃です。利用者のネットワークを飽和
させる最新の偽造パケット攻撃に関して行うことができることはありませんが、
利用者は、一般的に、攻撃が利用者のサーバをダウンすることができないことを
保証することによって損傷を制限することができます。
1. サーバの fork の制限。
2. スプリングボード (springboard; 踏み切板) 攻撃の制限 (ICMP 応答
攻撃、ping ブロードキャスト (同報通信) など)
3. カーネルの経路制御のキャッシュ
共通の DoS (サービス拒否) 攻撃は、マシンが死ぬまで、サーバが、プロセス、
ファイル記述子、とメモリを消費することを試みる fork しているサーバに対し
ています。inetd(8) サーバは、この種類の攻撃を制限するいくつかのオプション
があります。マシンがダウンすることを防止することが可能ですが、攻撃によっ
て混乱させられたサービスを防止することは、一般的に、可能ではないことが注
意されるべきです。inetd(8) マニュアルページを注意深く読み、特に -c, -C と
-R オプションに注意を払ってください。疑似 IP (spoofed-IP) 攻撃は、
inetd(8) への -C オプションを巧みに逃れるので、通常、オプションの組み合わ
せが使用されなければならないことに注意してください。いくつかのスタンドア
ロンのサーバには、セルフ fork 制限パラメータがあります。
sendmail(8) デーモンには、ロードの遅れのために sendmail(8) のロード制限オ
プションを使用する試みよりもよりよい動作する傾向にある
-OMaxDaemonChildren オプションがあります。利用者は、利用者の予期される
ロードを処理するために十分高い sendmail(8) 開始するとき、
MaxDaemonChildren パラメータを指定するべきですが、コンピュータが直面する
下落なしで、sendmail の数を処理できないことが、それほど高くありません。ま
た、``queued'' モード (-ODeliveryMode=queued) で sendmail(8) を実行し、
キューの実行 (``sendmail -q15m'') から切り離された (``sendmail -bd'')
デーモンを実行することは、慎重です。利用者がまだリアルタイムの配信を望ん
でいるなら、利用者は、-q1m のように、はるかに低い間隔でキューを実行するこ
とができますが、カスケード失敗を防止する sendmail(8) のために合理的な
MaxDaemonChildren オプションを指定すると確信しています。
syslogd(8) デーモンを、直接攻撃することができて、利用者に、可能ならいつで
も -s オプションを使用することを強く推奨します、そうでなければ、-a オプ
ションを使用することを強く推奨します。
利用者は、また、直接攻撃することができる tcpwrapper の逆 ident のような接
続返し (connect-back) のサービスにかなり注意するべきです。訳注: ident の
意味不明。利用者は、一般的に、この理由のための tcpwrapper の逆の ident 機
能を使用したくありません。
それは、利用者の境界ルータでそれらをオフにするファイアウォールすることに
よって外部のアクセスから内部のサービスを保護するために非常に良い考えで
す。ここでの考えは、ネットワークベースの root を危うくすることから内部の
サービスを保護するほどではなく、利用者の LAN の外側から飽和 (saturation)
攻撃を防止することです。常に、排他的なファイアウォールを設定します、すな
わち、`ポート A、B、C、D と M-Z を除いたファイアウォールのすべて'。このよ
うに、利用者は、talkd(8), sendmail(8) と他のインターネットアクセス可能な
サービスのような、ある種の特有のサービスを除いて、利用者の下位のポートの
すべてをファイアウォールでオフにすることができます。利用者が、包括的また
は許容的なファイアウォールとして -- 他の方法でファイアウォールを設定しよ
うと試みるなら、利用者が、2、3 のサービスの ``close'' (クローズ) を忘れる
か、または、利用者が新しい内部サービスを追加し、ファイアウォールを更新す
ることを忘れるよい可能性があります。利用者は、まだ、利用者の下位のポート
を危険にさらすことなく、許容的な操作を許可するために、ファイアウォールで
大きな番号を付けられたポートの範囲を広げることができます。また、FreeBSD
によって、利用者は、利用者のファイアウォールの設定の複雑さも緩和すること
ができる、様々な net.inet.ip.portrange sysctl の (``sysctl
net.inet.ip.portrange'') を通して動的なバインディングのために使用される
ポート番号範囲を制御することができることを注意してください。私は、通常、
4000 から 5000 までの最初/最後の範囲と 49152 から 65535 までの高位のポー
ト (hiport) の範囲を使用し、次に (もちろん、ある種の特有のインターネット
アクセス可能なポートを除いて) 私のファイアウォールで 4000 未満をすべて遮
断します。
別の共通のサービス DoS (サービス拒否) 攻撃は、ある意味、サーバが、次に、
サーバ、ローカルネットワークまたはある他のマシンをオーバロードする応答を
生成して、サーバを攻撃する -- 踏み台攻撃 (springboard attack) と呼ばれま
す。この種類の最も共通の攻撃は、ICMP PING BROADCAST 攻撃です。攻撃者は、
彼らが攻撃したい実際のマシンに設定される発信元 IP アドレスで利用者の LAN
のブロードキャスト (同報通信) アドレスに送信された ping パケットになりす
まします。利用者の境界ルータが ping のブロードキャスト (同報通信) アドレ
スを厳しい態度で臨むように設定されていないなら、利用者の LAN は、特に、攻
撃者が、すぐに数 10 の異なるネットワークを越えてブロードキャストアドレス
に同じトリックを使用するとき、犠牲者を飽和させるために、偽造された送信元
アドレスへの十分な応答を生成して終ります。120 メガビットを超えるブロード
キャスト (同報通信) 攻撃が、測定されています。2 番目の共通の踏み台攻撃
は、ICMP エラー報告システムの反対です。ICMP エラー応答を生成するパケット
を構築することによって、攻撃者は、サーバの着信するネットワークを飽和させ
ることができ、サーバが、ICMP 応答でその発信するネットワークを飽和させま
す。この攻撃のタイプは、また、特に、サーバがそれが十分に速く生成する ICMP
応答を排出することができないなら、mbuf の外でそれを実行することによって
サーバも破壊することができます。FreeBSD カーネルには、これらの種類の攻撃
の有効性を制限する ICMP_BANDLIM と呼ばれる新しいカーネルのコンパイルオプ
ションがあります。踏み台攻撃の最後の主要なクラスは、UDP エコーサービスの
ような特定の内部の inetd(8) サービスに関連しています。攻撃者は、サーバ A
と B の両方が利用者の LAN にあるサーバ A のエコーポートである送信元アドレ
スで UDP パケットとサーバ B のエコーポートである宛先アドレスを単に偽りま
す。次に、2 つのサーバは、この 1 つのパケットを互いの間で往復してバウンド
させます。攻撃者は、この方法で少しのパケットを注入することによって単に両
方のサーバとそれらの LAN の両方に負荷をかけることができます。同様の問題
は、内部の chargen ポートに存在します。有能なシステム管理者 (sysadmin)
は、これらの inetd(8) 内部テストサービスのすべてをオフにします。
Kerberos と SSH でのアクセス問題
利用者がそれらを使用するつもりであるなら、アドレスされる必要がある Ker
beros と SSH の両方で少しの問題があります。Kerberos5 は、優秀な認証プロト
コルですが、kerberos 化された telnet(1) は、最低の石 (suck rocks) です。
訳注: suck rocks の意味不明。それらを、バイナリのストリームを扱うために適
切でないようにするバグがあります。また、デフォルトで、Kerberos は、利用者
が -x オプションを使用しないなら、セッションを暗号化しません。SSH は、デ
フォルトですべてを暗号化します。
SSH は、暗号化鍵を転送するためにセットアップするときを除いて、あらゆる点
でまったくよく動作します。これが意味しているものは、利用者には、鍵を保持
している安全なワークステーションがあり、利用者にシステムの残りにアクセス
を与え、利用者の ssh(1) は、利用者の鍵が露出される、安全でなくなったマシ
ンになります。実際の鍵自体は、露出されませんが、ssh(1) は、利用者のログイ
ンの持続時間のための転送ポートをインストールし、攻撃者が、安全でなくなっ
たマシンの root を破るなら、攻撃者は、利用者の鍵がアンロックするあらゆる
他のマシンへのアクセスを得るために利用者の鍵を使用するために、そのポート
を利用することができます。
利用者が、スタッフログインのために可能なときはいつでも Kerberos との組み
合わせで SSH を使用することをお勧めします。SSH は、Kerberos サポートとと
もにコンパイルすることができます。これは、同時に Kerberos を通してパス
ワードを保護する間に、潜在的に露出可能な SSH 鍵への利用者の依存を減らしま
す。SSH 鍵は、(Kerberos が適さない何か) 安全なマシンから自動化されたタス
クのためだけに使用されるべきです。また、利用者が、SSH 設定で鍵転送するこ
とをオフにするか、または、SSH は、特有のマシンからログインする実体を使用
可能にするためだけに、その authorized_keys を許可する、from=IP/DOMAIN オ
プションの使用することをお勧めします。
ノブとひねり (KNOBS AND TWEAKS)
FreeBSD は、いくらかの内観情報アクセスをより制限する、いくつかのノブとひ
ねり (knobs and tweak) ハンドルを提供しています。いくらかの人々は、改良し
ているシステムセキュリティとみなされ、これを考慮するので、ノブは、ハード
ウェア状態のリークのいくつかの緩和を有効にする制御とともにそこで簡単にリ
ストされます。
ハードウェア緩和 sysctl ノブは、既存の名前を受け付ける後方互換性のシム
(shim) で machdep.mitigations の下で、移動され以下に記述されたました。(有
効 / 真が、常に緩和がアクティブであることを常に示すことができるように) 将
来の変更は、個別の sysctl の意味を正当化します。その理由で、以前の名前
は、緩和を設定するために、正規の方法のままで、ここで文書化されます。
machdep.mitigations の下の暫定的な sysctl のための後方互換性の シム
(shim) は、追加されません。
security.bsd.see_other_uids 異なる uid によって所有されているプ
ロセスの可視性を制限します。ノブ
は、ps(1) のようなユーティリティか
ら制限された出力の結果となるデータ
の kern.proc sysctl フィルタリング
に直接影響します。
security.bsd.see_other_gids 異なる gid によって所有されているプ
ロセスと同じです。
security.bsd.see_jail_proc jail に属しているプロセスと同じで
す。
security.bsd.conservative_signals 有効にされるとき、特権がないユーザ
は、ジョブ制御と変更される uid でプ
ログラムを実行しているプロセスに
SIGKILL, SIGINT と SIGTERM のよう
な、通常の終了シグナルを送信するこ
とを許可されるだけです。
security.bsd.unprivileged_proc_debug root でないユーザへのデバッグ機能を
処理する利用可能性を制御します。ま
た、proccontrol(1) モード trace を
参照してください。
vm.pmap.pti 調整変数、amd64 のみ。ユーザモード
のページテーブルが、いくらかの
Intel CPU でいわゆるメルトダウン情
報のリークを防止するために不適切な
部分を削除する仮想記憶システムの操
作のモードを有効にします。デフォル
トで、システムは、CPU が回避方法を
必要として、それを自動的に有効にす
るかどうかを検出します。また
proccontrol(1) モード kpti を参照し
てください。
machdep.mitigations.flush_rsb_ctxsw amd64。クロスプロセス ret2spec 攻撃
を防止するために、コンテキストス
イッチで制御リターンスタックバッ
ファ (Controls Return Stack Buffer)
は、フラッシュします。マシンが SMEP
をサポートするなら、デフォルトで必
要とされるだけで、有効にされるだけ
で、そうでなければ、IBRS は、とにか
く、カーネルエントリで必要なフラッ
シュを行ないます。
hw.mds_disable amd64 と i386。マイクロアーキテク
チャデータサンプリング (Microarchi
tectural Data Sampling) ハードウェ
ア情報のリーク緩和を制御します。
hw.spec_store_bypass_disable amd64 と i386。投機的格納バイパス
(Speculative Store ) ハードウェア情
報のリーク緩和を制御します。
hw.ibrs_disable amd64 と i386。間接分岐制限推測
(Indirect Branch Restricted Specu
lation) ハードウェア情報のリーク緩
和を制御します。
machdep.syscall_ret_l1d_flush amd64。EEXIST, EAGAIN, EXDEV,
ENOENT, ENOTCONN と EINPROGRESS 以
外のエラーを報告する syscall からの
返りで L1D キャッシュの強制フラッ
シュを制御します。これは、たいて
い、未知のハードウェアの問題のため
の未知のガジェットの仮定の開発を防
止するために追加される偏執症の設定
です。エラーコードの除外リストは、
通常のシステム操作で起こる最も共通
のエラーから成ります、
machdep.nmi_flush_l1d_sw amd64。NMI の L1D キャッシュの強制
フラッシュを制御します。これは、L1
端末障害ハードウェア情報のリークの
bhyve 緩和のために、ソフトウェア補
助を提供しています。
hw.vmm.vmx.l1d_flush amd64。bhyve ハイパーバイザの L1 端
末障害の緩和を制御します。
vm.pmap.allow_2m_x_ept amd64。物理メモリを機械加工するため
にゲストの物理アドレス空白をマップ
するために Intel CPU のハイパーバイ
ザによって使用される EPT ページテー
ブル形式の下で実行形式のためのスー
パーページの使用を許可します。ペー
ジサイズの変更で呼び出されるマシン
チェックエラー回避の CPU 誤字のまわ
りで動作するために無効にされます。
machdep.mitigations.rngds.enable amd64 と i386。特別レジスタバッファ
データサンプリング (Special Regis
ter Buffer Data Sampling) 対 MCU ア
クセスの最適化の緩和を制御します。0
に設定されるとき、緩和は、無効にさ
れ、RDSEED と RDRAND 命令は、共有さ
れたバッファアクセスのためのオーバ
ヘッドをシリアライゼィションを被
り、オフコアのメモリのアクセスをシ
リアライズしません。
kern.elf32.aslr.enable 通常の non-PIE (位置独立な実行形式)
の 32 ビットバイナリのためのシステ
ムグローバルアドレス空間レイアウト
ランダム化 (Address Space Layout
Randomization; ASLR) を制御します。
またイメージごとに制御注フラグに
よって影響される proccontrol(1)
モード aslr を参照してください。
kern.elf32.aslr.pie_enable 位置独立の (PIE) の 32 ビットバイナ
リのためのシステムグローバルアドレ
ス空間レイアウトランダム化 (Address
Space Layout Randomization) を制御
します。
kern.elf32.aslr.honor_sbrk ASLR を、それほど攻撃的ではないよう
にし、sbrk 領域に依存している古いバ
イナリとのより互換性があるようにし
ます。
kern.elf32.aslr.stack_gap ASLR がバイナリのために有効にされる
なら、0 以外の値は、文字列と aux ベ
クトルの終わりの間のランダム化され
たスタックのギャップを作成します。
値は、ギャップで無駄にする主要なス
タックの最大のパーセンテージです。
50 より大きくなることができません、
すなわち、スタックのほぼ半分。
kern.elf64.aslr.enable 64 ビットバイナリ ASLR 制御。
kern.elf64.aslr.pie_enable 64 ビット PIE バイナリ ASLR 制御。
kern.elf64.aslr.honor_sbrk 64 ビットバイナリ ASLR sbrk 互換性
の制御。
kern.elf64.aslr.stack_gap 64 ビットバイナリのためのスタック
ギャップを制御します。
kern.elf32.nxstack 32 ビットプロセスのための実行形式で
ないスタックを有効にします。ハード
ウェアと対応するバイナリによってサ
ポートされるなら、デフォルトで有効
にされます。
kern.elf64.nxstack 64 ビットプロセスのための実行形式で
ないスタックを有効にします。
kern.elf32.allow_wx 32 ビットプロセスのための、同時に書
き込み可能で実行形式なページのマッ
ピングを有効にします。
kern.elf64.allow_wx 64 ビットプロセスのための、同時に書
き込み可能で実行形式なページのマッ
ピングを有効にします。
関連項目
chflags(1), find(1), md5(1), netstat(1), openssl(1), proccontrol(1),
ps(1), ssh(1), xdm(1) (ports/x11/xorg-clients), 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 13.0 February 28, 2021 FreeBSD 13.0