第13章 セキュリティ

コンピュータセキュリティおける脅威とは何でしょうか？ 長年、脅威はリモートの攻撃者、 すなわち遠隔からの許可のないシステムへのアクセスを企てる人々と考えられていました。 今日では、この定義は従業員、悪意のあるソフトウェア、 不正なネットワークデバイス、自然災害、セキュリティの脆弱性、 そして競合する会社でさえも含めるように拡張されています。

毎日、数千ものシステムおよびネットワークが攻撃され、 数百ものシステムが許可なくアクセスされています。 簡単なアクシデントといったものから、リモートからの攻撃、 産業スパイであったり、以前働いていた従業員からの攻撃といったケースもあります。 システムのユーザとしては、 間違いがセキュリティ違反に繋がった場合には、 可能性のある問題をセキュリティチームに報告することが重要です。 管理者としては、脅威を把握し、 その脅威の影響を小さくするように準備をしておくことが重要です。

セキュリティを考える上で、 しばしばボトムアップアプローチが一番良い方法となります。 この考えでは、管理者が基本的なアカウント、システム設定を行ってから、 サードパーティ製ユーティリティの設定、 そしてネットワークレイヤに設定を広げていきます。 システムポリシーおよび手続きを行う上では、 このような設定の側面があります。

ビジネスの多くの環境では、 使用するデバイスの設定に対するセキュリティポリシがすでに策定されています。 このポリシには、最低限エンドユーザのワークステーション、 デスクトップ、携帯電話やラップトップといったモバイルデバイス、および 製品および開発サーバの両方に対するセキュリティの設定が含まれているべきです。 多くの場合には、コンピュータのセキュリティを考える際に、 標準作業手続書 (SOP) がすでに存在します。 わからなければ、セキュリティチームに尋ねてください。

システムを安全にするにあたり、最も適切な出発点は、 アカウントの監査です。 ルートアカウントのパスワードが強力であること、 シェルアクセスを必要としないアカウントは無効にすることを確実におこなってください。 また、権限を必要とするユーザに対しては、 security/sudo をインストールして、 アクセスが必要となるアプリケーションのみにアクセスを許可するようにしてください。 root ユーザのパスワードは、決して共有すべきではありません。

アカウントへのアクセスを無効にする方法は二通りあります。 一つ目の方法は、アカウントをロックする方法です。例として、 toor アカウントをロックする方法を以下に示します。

このコマンドは、アカウントの設定を "toor:*:0:0::0:0:Bourne-again Superuser:/root:" から "toor:*LOCKED**:0:0::0:0:Bourne-again Superuser:/root:" へと変更します。

ときには (おそらく追加のサービスのために)、 この方法が使えない場合があります。 そのような場合には、以下の例のように、 シェルを /sbin/nologin に変更することで、 ログインアクセスを拒否できます。

アカウント情報は、以下のように最後のエントリが "nologin" シェルとなります。

/usr/sbin/nologin シェルは、 login(1) コマンドがこのユーザにシェルを割り当てることをブロックします。

場合によっては、 システム管理者へのアクセスを他のユーザと共有する必要があります。 FreeBSD はこのために二つの方法を用意しています。 第一の方法は推奨されませんが、 ルートのパスワードを共有し、ユーザを wheel グループに加える方法です。 これを行うにには、/etc/group を編集し、 最初のグループの最後にユーザを追加してください。 ユーザはカンマ区切りで管理されています。

権限の拡大をする適切な方法は、 security/sudo port を使う方法です。 この port は、追加の監査、よりきめ細かいユーザ管理、および ユーザを service(8) のような権限が与えられたコマンのみの実行に制限することもできます。

インストールが終わったら、 visudo インタフェースを使って /usr/local/etc/sudoers ファイルを編集してください。 以下の例では、新しく webadmin グループが作成され、 trhodes ユーザがこのグループに追加されます。 その後、ユーザに apache24 を再起動するアクセス権限を与えます。 この手続きは以下のようになります。

ローカルのユーザ管理において、 security/sudo は、 非常に貴重なリソースを提供します。 また、パスワードを不必要にして、デフォルトを ssh(1) 鍵の方法だけにすることもできます。 sshd(8) 経由のパスワードによるログインを無効にし、 sudo へのローカルパスワードのみを使うようにするには、 OpenSSH をご覧ください。

パスワードは、テクノロジーにおける必要悪です。 パスワードは極めて複雑であるだけではなく、 パスワードを保護する強力なハッシュメカニズムもまた必要となります。 この文書を書いている時点では、 FreeBSD は crypt() ライブラリで DES, MD5, Blowfish, SHA256 および SHA512 に対応しています。 デフォルトは SHA512 であり、 強度の弱い暗号へは変更すべきではありません。 しかしながら、Blowfish を好むユーザもおります。 DES を除く各メカニズムでは、 開始の文字、使用しているハッシュメカニズムを識別可能な特徴を持っています。 MD5 メカニズムでは、シンボルは "$" の符号です。 SHA256 または、 SHA512 では、シンボルは "$6$"、 そして Blowfish は "$2a$" です。 暗号強度の弱いパスワードを使用している場合には、 次回のログイン時にユーザが passwd(1) を実行して再ハッシュ化することを促すべきです。

ネットワークに接続しているシステムについては、 二要素認証を使用すべきです。 この認証では、通常あなたが所有する要素と知っている要素が用いられます。 FreeBSD のベースシステムに含まれている OpenSSH および ssh-keys では、 ネットワークへのすべてのログインにおける二要素認証の交換で、 パスワードを使用すべきではありません。 より詳細な情報については、ハンドブックの OpenSSH 節をご覧ください。 Kerberose のユーザは、ネットワークで OpenSSH を実装するために追加の変更が必要になるでしょう。

バックドアおよびルートキットは、 それらがインストールされた後に脅威となります。 インストールされると、この悪意のあるソフトウェアは、 攻撃者のために侵入口を設置します。 実際的には、システムが一度汚染された後に、調査が行われ、 消去されます。 慎重なセキュリティやシステムエンジニアでさえも、 攻撃者が残したソフトウェアを見逃してしまうという恐ろしいリスクが存在しています。

バックドアまたはルートキットソフトウェアは、 管理者にとって役に立つことが一つあります。 それは、一度検出すると、 システムのどこかが危険に冒されていることの痕跡となります。 しかし、通常この種のアプリケーションは、とてもうまく隠れています。 バックドアおよびルートキットを検出するツールが存在しており、 それうちの一つが、 security/rkhunter です。

インストール後、以下のコマンドでシステムをチェックできます。 実行すると多くの情報が出力されます。

このプロセスを実行中に ENTER キーを何度か押す必要があります。 完了すると、ステータスメッセージが画面に表示されます。 このメッセージは、チェックしたファイルの量、疑わしいファイルの数、 可能性のあるルートキット等の情報を含みます。 チェックの最中、隠されたファイル、 OpenSSH プロトコルの選択、そして、 時には、インストールされているソフトウェアの漸弱性のバージョンに関する一般的なセキュリティの警告が出力されます。 すぐに、もしくはより詳細な解析が行われた後に、対応が可能です。

管理者は皆、 担当しているシステム上で何が実行されているかを把握している必要があります。 rkhunter, lsof や netstat(1) および ps(1) といったネイティブのツールは、 システムに関するかなり多くの情報を与えてくれます。 正常な状態がどのような状態であるかを把握しておき、 本来と違う状況になった場合には、質問をしたり、 疑い深くなってください。 セキュリティが破られることを避けることは理想ですが、 破られたことを把握することは必須です。

システムファイルおよびバイナリの検証は、 システム管理者およびセキュリティチームに対して、 システムの変更に関する情報を提供してくれるため重要です。 いかなるシステムにおいても、システム管理チームの知らないところで、 内部のコマンドやアプリケーションは変更すべきではありません。 システムの変更ををモニタリングするソフトウェアアプリケーションは、 侵入検知システム (Intrusion Detection System) または IDS と呼ばれます。

FreeBSD は、基本的な IDS システムをネイティブで提供しています。 実際に、毎晩の periodic(8) セキュリティに関するメールの中では、 管理者に変更点を通知します。 情報はローカルに保存されているので、 悪意のあるユーザが変更し、情報を "欺く" 可能性があります。 そのため、バイナリの署名の別のセットを作成して、 読み取り専用の root 所有のディレクトリ、できれば、 USB ディスクまたは rsync サーバといったシステムとは別のシステムに保存してください。

まず最初に、シードを生成する必要があります。 これは、数値定数で、ハッシュ値の生成やハッシュ値の検証で使われます。 このシードがないと、 ファイルのチェックサムの値を偽ったり検証が可能になります。 以下の例では、シードは -s フラグで指定されています。 最初に以下のコマンドを用いて /bin のハッシュ値およびチェックサムを生成してください。

このコマンドの出力は以下のようになります。

bin_cksum_mtree ファイルを見ると、 以下のような出力となります。

コンピュータのホスト名、現在の日付と時間、mtree(8) を実行したユーザの情報すべてがこのレポートには含まれています。 また、各バイナリに対するチェックサム、サイズ、タイムスタンプおよび SHA256 ダイジェストも含まれています。

バイナリ署名の検証のために、 以下のコマンドを実行すると、現在の署名のリストを読み込み、 結果を出力します。

このコマンドを実行すると、すでにチェックサムを生成している /bin に対して、同様のチェックサムを生成します。 このコマンドを実行してから変更が行われていないので、 bin_chksum_output への主力は空となります。 変更が行われた場合をシミュレートするために、 /bin/cat ファイルの日付を touch(1) を使って変更して、 再度検証のコマンドを実行してみます。

security/aide のような、 より高度な IDS システムもありますが、 ほとんどのケースにおいて、 mtree(8) は管理者が必要とする機能を提供します。 悪意のあるユーザが、 シード値およびチェックサムの出力を見れないようにすることが重要です。

システムの機能の多くは、sysctl(8) を使って調整できます。 Denial of Service (DOS) スタイルの攻撃を避けるためのセキュリティ機能に対しても同様です。 この節では、より重要な調整についても触れています。 sysctl(8) により、設定が変更された時はいつでも、 望まない危害が起こる可能性は高まり、 システムの可用性に影響します。 システム全体の設定を変更する時には、 システムの CIA を考える必要があります。

以下では、sysctl(8) の一覧、 および変更がシステムにどのように影響するかを説明します。

デフォルトでは、FreeBSD のカーネルはセキュリティレベル -1 で起動します。 このセキュリティレベルは、 変更不可のファイルフラグを外したり、 すべてのデバイスに対して読み込みおよび書き込みができたりするので、 "insecure mode" と呼ばれます。 このセキュアレベルは、管理者または init(8) による起動時のスクリプトにより変更されない限り -1 のままです。 /etc/rc.conf において、 kern_securelevel_enable を YES とし、 kern_securelevel に必要とする値を設定することで、 システム起動時にセキュアレベルを高めることができます。 これらの設定についてのより詳細な情報については、 security(7) および init(8) をご覧ください。

つぎに変更を検討すべき sysctl(8) は、 net.inet.tcp.blackhole および net.inet.udp.blackhole です。 これらを設定すると、閉じたポートに対して届く SYN パケットはドロップされ、 RST レスポンスを返しません。 通常は、RST を返し、 そのポートが閉じられていることを伝えます。 これにより、システムに対する "ステルス" スキャンに対し、ある程度の防御となります。 net.inet.tcp.blackhole を "2"、 net.inet.udp.blackhole を "1" に設定してください。 詳細な情報について blackhole(4) をご覧ください。

さらに、net.inet.icmp.drop_redirect および net.inet.ip.redirect も設定すべきです。 これら 2 つの sysctl(8) は、リダイレクト攻撃を防ぐ助けとなるでしょう。 リダイレクト攻撃は、 故意に通常のネットワークでは必要としないような大量の ICMP タイプ 5 のパケットを発生します。 そのため net.inet.icmp.drop_redirect を "1"、 net.inet.ip.redirect を "0" に設定して下さい。

ソースルーティングは、 内部ネットワーク上でルーティングできないアドレスを検出したりアクセスするための方法です。 通常ルーティングできないアドレスは、 意図してルーティングできないようにしているので、 この設定はおそらく無効にすべきです。 この機能を無効にするには、 net.inet.ip.sourceroute および net.inet.ip.accept_sourceroute を "0" に設定してください。

ブロードキャストアドレスに対するすべての ICMP エコーリクエストは、ドロップしてください。 ネットワーク上のコンピュータがサブネットにあるすべてのホストにメッセージを送る必要がある場合には、 メッセージはブロードキャストアドレスに送られます。 外部のホストについては、 このような送信をする必要はないので、 外部からブロードキャストへのリクエストをすべて拒否するように、 net.inet.icmp.bmcastecho を "0" に設定してください。

まだ多くの sysctl(8) が security(7) で説明されています。 さらに多くの情報を調べることが推奨されます。

OPIE を初めて初期化するには、 opiepasswd(1) を実行してください。

Enter new secret pass phrase: または Enter secret password: というプロンプトに対して、 パスワードまたはパスフレーズを入力してください。 このパスワードは、 ログインするときに使うワンタイムパスワードを生成するために使うものであり、 ログインのためのパスワードではありません。 "ID" から始まる行は、1 回分のパラメータで、 ログイン名とシーケンス番号とシードです。 ログインするときには、 システム側がこれらのパラメータを覚えていて表示してくれるので、 これらのパラメータを覚えておく必要はありません。 最後の行が、今述べたパラメータと入力された秘密のパスワードから計算されたワンタイムパスワードです。 次にログインするときに打ち込むべきワンタイムパスワードがこれです。

信頼できない通信路を使って秘密のパスフレーズを初期化または変更するためには、 opiekey(1) を実行するための信頼できる通信路を用意しておく必要があります。 たとえばそれは、 信頼できるマシンのシェルプロンプトだったりするでしょう。 (訳注: ここでの通信路とはマシンそのものになります。 信頼できるマシンとは、 信頼できる人がしっかり管理しているマシンということです)。 他に準備しておくものとして、シーケンス番号 (100 は適切な値といえるでしょう) と、場合によっては自分で考えた、 またはランダムに生成されたシードがあります。 信頼できない通信路を使うときには、opiepasswd(1) を使ってコンピュータを初期化してください。

デフォルトのシードで構わなければ、Return を押してください。アクセスパスワードを入れる前に、 あらかじめ用意しておいた信頼できる通信路へ移って、 先ほどと同じパラメータを入力します。

信頼できない通信路の方に戻って、 生成されたワンタイムパスワードをコピーして対応するプログラムに入力します。

OPIE を初期化したら、 ログイン時には以下のようなプロンプトが出てくるでしょう。

OPIE のプロンプトには便利な機能が備わっています。 パスワードプロンプトに対して、 Return を押すとエコーモードに切り替わり、 タイプした文字がそのまま見えるようになるのです。 これは、 紙に印刷していたりするワンタイムパスワードを手で入力しなければならない場合に役立つ機能です。

次に、 このログインプロンプトに対して入力するワンタイムパスワードを生成してください。 これは、opiekey(1) プログラムを使える信頼できるマシン上で行わなければなりません。 このプログラムには Windows®, Mac OS® および FreeBSD 版があります。 どちらも、 コマンドラインからシーケンス番号とシードを指定しなければなりません。 ログインしようとしているマシンのログインプロンプトから直接カットアンドペーストすると楽でしょう。

信頼できるシステムで

ワンタイムパスワードが生成されたので、 ログインを続けてください。

都合によっては、 信頼できるマシンや信頼できる通信路が一切確保できないようなことがあるでしょう。 このような場合には、opiekey(1) を使って複数のワンタイムパスワードを生成できます。 たとえば

-n 5 という引数によって 5 個のワンタイムパスワードを順に生成します。 また 30 は、 最後のシーケンス番号となるべき数字です。出力は使う順番とは 逆 に出力されていることに注意してください (訳注: 一番最初に使うワンタイムパスワードは一番最後に出力されたものです)。 もしあなたがセキュリティに偏執するなら、 この結果を紙と鉛筆を使って手で書き移した方がよいかもしれません。 そうでなければ、この結果を印刷すると良いでしょう。 ここで、 出力の各行はシーケンス番号とそれに対応する一回分のワンタイムパスワードです。 消費済みのワンタイムパスワードをペンで消していってください。

OPIE は、ログインセッションの IP アドレスをベースとした UNIX® パスワードの使用を制限できます。 関連ファイルは、/etc/opieaccess で、 デフォルトで用意されています。 このファイルの詳細や、 このファイルを使用する際に考慮すべきセキュリィについては opieaccess(5) を確認してください。

以下は opieaccess の例です。

この行では、(なりすましされやすい) IP ソースアドレスが、 ある値やマスクにマッチするユーザに対して、 UNIX® パスワードをいつでも許可します。

もし opieaccess のどのルールにも一致しなければ、 デフォルトでは非 OPIE ログインは使えません。

FreeBSD 上で TCP Wrappers を有効にするには、 rc.conf から -Ww オプションで inetd(8) サーバが起動されることを確認してください。 その後、/etc/hosts.allow を適切に設定してください。

最も簡単な設定におけるデーモンの接続ポリシは、 /etc/hosts.allow の中で、 オプションごとに許可またはブロックするように設定するというものです。 FreeBSD のデフォルトの設定では、inetd(8) から起動されたすべてのデーモンの接続を許可します。

基本的な設定は、通常 daemon : address : action という形式です。ここで、 daemon は、 inetd(8) が起動するデーモンの名前です。 address の部分は、有効なホスト名、 IP アドレスまたは、 括弧 ([ ]) で囲まれた IPv6 アドレスです。 action は、 allow または deny です。 TCP Wrappers は、 最初にマッチしたルールが適用されます。 これは、設定ファイルに対するルールにマッチするかどうかのスキャンは、 昇順に行われることを意味しています。 マッチすると、ルールが適用され、 検索のプロセスは終了します。

例として、POP3 の接続を mail/qpopper デーモン経由で許可するには、以下の行を hosts.allow に追加してください。

この行を追加したら、 inetd(8) を再起動してください。

TCP Wrappers は、 接続を取り扱う以上の制御を行う高度な設定も提供しています。 ある時は、 接続しているホストまたはデーモンにコメントを返すことが適切であることがあります。 別の場合では、おそらくログエントリを記録したり、 管理者にメールで送る必要があることもあるでしょう。 またその他の状況としては、 サービスをローカルの接続のみの使用に制限する必要がある場合もあります。 これらはすべて、ワイルドカード と呼ばれる設定のオプション (拡張文字および外部コマンドの実行) で可能となります。

Kerberos は、 ネットワークのセキュリティ問題を解決するために、 MIT で開発されました。 Kerberos プロトコルは、 必ずしも安全ではないインターネット接続においても、 サーバに対して (逆もまた同様に)、 強い暗号を使って身元を証明します。

Kerberos は、 ネットワーク認証プロトコルの名前であり、 Kerberos telnet のように、 このプログラムを実装しているプログラムを表すための形容詞でもあります。 プロトコルの現在のバージョンはバージョン 5 で、 RFC 1510 として文書化されています。

このプロトコルのいくつものフリーの実装が、 さまざまなオペレーティングシステムで利用できます。 最初の Kerberos を開発したマサチューセッツ工科大学 (MIT) は、 開発した Kerberos パッケージを継続的に保守しています。 アメリカ合衆国では暗号製品として良く使われていますが、 歴史的には、 アメリカ合衆国 の輸出規制により制限されてきました。 MIT で実装された Kerberos は、 security/krb5 package または port から利用できます。 バージョン 5 のもう一つの実装が、 Heimdal Kerberos です。 この実装は、アメリカ合衆国の外で開発されたため、 輸出の制限を避けることができます。 Heimdal Kerberos は security/heimdal> package または port からインストールできますが、最小構成は FreeBSD の base インストールに含まれています。

以下の説明では FreeBSD に含まれている Heimdal ディストリビューションの使用を想定しています。

鍵配布センター (KDC) は、 Kerberos が提供する中心的な認証サービスで、 Kerberos チケットを発行するコンピュータです。 KDC は、 Kerberos のレルムの中のすべてのコンピュータから "信頼"されています。 そのため、厳重なセキュリティに対する配慮が必要となります。

Kerberos サーバの実行にコンピュータのリソースはほとんど必要ありませんが、 セキュリティの観点から、KDC としてのみ機能する専用のコンピュータが推奨されます。

KDC を設定するにあたって、 KDC として動作するために、 適切に /etc/rc.conf が設定されていることを確認してください。 必要に応じて、 システムの設定を反映するようにパスを調整する必要があります。

次に、/etc/krb5.conf を以下のように編集してください。

/etc/krb5.conf の中で、 KDC は、 完全修飾されたホスト名 kerberos.example.org を使うことが想定されています。 KDC が異なるホスト名を持つ場合には、 名前の解決が行われるように、適切に CNAME (エイリアス) エントリをゾーンファイルに追加してください。

次に Kerberos データベースを作成してください。 このデータベースには、 マスター鍵により暗号化されたすべてのプリンシパルの鍵が含まれています。 このパスワードは、 /var/heimdal/m-key に保存されるため、 覚える必要はありません。 マスター鍵を作成するには、kstash(8) を実行して、 パスワードを入力してください。

マスター鍵を作成したら、kadmin -l を使ってデータベースを初期化してください。 このオプションを使うと、kadmin(8) は、 kadmind(8) ネットワークサービスを使わず、 ローカルのデータベースファイルを直接変更します。 これにより、 データベースを作成する前に、データベースへの接続を試みてしまうという、 卵が先か鶏が先かという問題を回避できます。 kadmin(8) プロンプトで、 init を使って、 レルムに関する初期のデータベースを作成してください。

最後に、kadmin(8) プロンプトで add を使って最初のプリンシパルを作成して下さい。 差し当たりは、 プリンシパルに対するデフォルトのオプションに従ってください。 後で modify を使うことで、 変更することができます。 kadmin(8) プロンプトで ? と入力すると、 利用可能なオプションを確認できます。

データベース作成のセッションの例は以下のようになります。

次に KDC サービスを起動してください。 service kerberos start および service kadmind start を実行してサービスを起動してください。 この時点で、kerberos 化されたデーモンが走っていなくても、 KDC のコマンドラインから、作成したばかりの (ユーザ) プリンシパルのチケットを入手したり、 一覧を表示することができることを確認できます。

必要がなくなった時には、チケットを破棄できます。

最初に /etc/krb5.conf を KDC からクライアントコンピュータへ、 scp(1) または物理的にリムーバブルディスクを使うといった安全な方法でコピーしてください。

次に /etc/krb5.keytab を作成してください。 これが Kerberos 化されたデーモンを提供するサーバとワークステーションの間での大きな違いです: サーバには keytab が置かれている必要があります。 このファイルには、サーバのホスト鍵が含まれています。 この鍵により、ホストおよび KDC が他の身元の検証ができます。 鍵が公開されてしまうと、 サーバのセキュリティが破られてしまうため、 このファイルは安全にサーバに転送しなければなりません。

一般的には、kadmin(8) を使って、 keytab をサーバに転送します。 ホストプリンシパル (KDC 側の krb5.keytab) も kadmin(8) を使って作成するので便利です。

すでにチケットを入手し、そのチケットは、 kadmin(8) インタフェースで使用できることが kadmind.acl で許可されている必要があります。 アクセスコントロールリストの設計の詳細については、 info heimdal の "Remote administration" というタイトルの章をご覧ください。 リモートからの kadmin アクセスを有効にする代わりに、 管理者は、ローカルコンソールまたは ssh(1) を用いて安全に KDC に接続し、 kadmin -l を使用して、 ローカルで管理作業を行うことができます。

/etc/krb5.conf をインストールしたら、 Kerberos サーバから add --random-key を使ってください。 このコマンドは、サーバのホストプリンシパルを追加します。 そして、ext を用いて、 サーバのホストプリンシパルを keytab に抽出してください。 以下は、使用例です。

ext は、デフォルトでは、抽出された鍵を /etc/krb5.keytab に保存します。

KDC 上で kadmind(8) を走らせていない場合で、 リモートから kadmin(8) に接続出来ない場合には、 ホストプリンシパル (host/myserver.EXAMPLE.ORG) を直接 KDC 上で追加し、 その後、以下のように KDC 上の /etc/krb5.keytab の上書きを避けるため、 一時ファイルに抽出してください。

その後、scp(1) またはリムーバブルディスクを使って、 keytab を安全にサーバコンピュータにコピーしてください。 KDC 上の keytab を上書きすることを避けるため、 デフォルトとは異なる名前を指定してください。

これでサーバは、 krb5.conf を使って KDC と通信ができるようになりました。 そして、krb5.keytab によって身元を証明できるようになったので、 Kerberos サービスを有効にする準備が出来ました。 この例では、 telnetd(8) サービスが /etc/inetd.conf で有効に設定され、 service inetd restart によって、 inetd(8) サービスを再起動します。

重要な変更箇所は、-a 認証がユーザに設定されていることです。 詳細については、 telnetd(8) を参照してください。

クライアントコンピュータの設定は簡単です。 /etc/krb5.conf のみが必要です。 このファイルをセキュリティ的に安全な方法で、KDC からクライアントコンピュータへコピーしてください。

クライアントから、kinit(1), klist(1) および kdestroy(1) を使用し、 上記で作成したプリンシパルに対するチケットの入手、表示、 削除を行い、クライアントコンピュータを試験してください。 Kerberos アプリケーションを使って Kerberos が有効なサーバに接続することもできるはずです。 もしうまく機能しない場合でも、チケットを入手できるのであれば、 問題はおそらくサーバにあり、 クライアントまたは KDC の問題ではないと考えられます。

Kerberos 化されたアプリケーションを試験する際には、 tcpdump(1) といったパケットスニファを使用して、 パスワードが平文で送られていないことを確認してください。

コア以外の さまざまな Kerberos クライアントアプリケーションが利用可能です。 FreeBSD の "最小" インストールでは、 インストールされる Kerberos 化された唯一のサービスは、telnetd(8) です。

Heimdal port は、 Kerberos 化されている ftpd(8), rshd(8), rcp(1), rlogind(8) および他のあまり一般的ではないプログラムをインストールします。 MIT port も、すべての Kerberos クライアントアプリケーションをインストールします。

レルムのユーザは、一般的には、 ローカルユーザアカウントに対応する Kerberos プリンシパルを持ちます。 しかしながら、時々 Kerberos プリンシパルに対応しないローカルユーザアカウントへのアクセスが必要となることがあります。 たとえば、 tillman@EXAMPLE.ORG が、ローカルユーザアカウント webdevelopers へのアクセスが必要となることがあります。そして、 他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。

ユーザのホームディレクトリに置かれた .k5login および .k5users ファイルを使うことで、 この問題を解決出来ます。 たとえば、以下の行を含む .k5login を webdevelopers のホームディレクトリに置くと、 一覧にある両方のプリンシパルは、 共有のパスワードを必要としなくても、 このアカウントにアクセス出来ます。

.k5users の詳細については、 ksu(1) を参照してください。

MIT と Heimdal 版の大きな違いは、 kadmin(8) に関連しています。 このプログラムは、異なる (ただし等価な) コマンド群を持ち、そして、 異なるプロトコルを使用します。 もし KDC に MIT を使用している場合には、 Heimdal 版の kadmin(8) を使って KDC をリモートから (逆も同様に) 管理できないことを意味しています。

クライアントアプリケーションでは、同じタスクを行う際に、 若干異なるコマンドラインのオプションが使われることもあります。 MIT Kerberos ウェブサイト に書かれているガイドに従うことが推奨されます。 path の問題について注意してください。 MIT port はデフォルトで /usr/local/ にインストールします。 そのため、もし PATH においてシステムのディレクトが最初に書かれている場合には、 MIT 版ではなく、"通常の" システムアプリケーションが起動してしまいます。

rc.conf を以下のように変更する必要もあります。

これを行うのは、 MIT Kerberos のアプリケーションは、 /usr/local 構造の下にインストールされるためです。

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

ssh(1) はとても良く動作しますが、 デフォルトで暗号鍵を転送してしまいます。 このため、ssh(1) を安全なワークステーションから、 安全でないマシンへのアクセスに使っているユーザに、 セキュリティリスクを引き起こします。 鍵そのものが見えてしまうわけではありませんが、 ssh(1) は login している間、転送用ポートを作ります。 攻撃者が安全でないマシンの root を破ったら、 このポートを使って、 この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。

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

以下のコマンドにより、証明書を作成できます。

"Common Name" プロンプト直後に表示されているのは、 ドメイン名です。 このプロンプトでは、検証するサーバ名の入力が必要となります。 ドメイン名以外を入力すると、役に立たない証明書が作成されます。 他のオプションとして、有効期限を指定したり、 別の暗号化アルゴリズムを選択することができます。 オプションの完全なリストは、 openssl(1) で説明されています。

このコマンドを実行したディレクトリには、 2 つのファイルが作成されているはずです。 1 つは、証明書要求 req.pem です。 このファイルを CA に送ると、 CA は含まれている内容を検証し、 検証に成功すると、証明書要求に署名を行い、 作成された証明書を送り返します。 もうひとつ、cert.pem と呼ばれるファイルが生成されます。 これは証明書の秘密鍵であり、 どのようなことがあっても保護しなくてはなりません。 もし、他の人の手に渡ると、手に入れた人は、 ユーザまたはサーバになりすますことができてしまいます。

CA の署名が必要ない場合には、 自己署名証明書を作成できます。 最初に RSA の鍵を生成してください。

次に、CA 鍵を生成してください。

この鍵を使って証明書を作成してください。

新しく 2 つのファイルがこのディレクトリに作成されます。 プライベート鍵 myca.key および 証明書 new.crt です。 これらのファイルを、好ましくは /etc 以下で、 root のみが読むことのできるディレクトリに置く必要があります。 許可属性は 0700 が適切です。 許可属性は chmod(1) を使って設定できます。

証明書の一つの利用方法は、SendmailMTA への接続を暗号化することです。 これにより、 ローカルの MTA 経由でメールを送信するユーザが、 テキスト認証を使用しなくてもすむようになります。

Sendmail を設定するには、以下の行をローカルの .mc ファイルに含めてください。

この例では、 ローカルで証明書および鍵ファイルは、ローカルの /etc/certs/ に置かれています。 ファイルの編集を保存し終わったら、 /etc/mail において make install と入力することで、ローカルの .cf ファイルを再構築する必要があります。 その後、make restart と入力して、Sendmail デーモンを再起動してください。

すべてがうまくいっていれば、 /var/log/maillog にはエラーメッセージは出力されず、 Sendmail がプロセスの一覧に表示されます。

以下は簡単な試験の例で、telnet(1) を使って、 メールサーバに接続しています。

出力に "STARTTLS" 行が表示されれば、 すべてが適切に機能しています。

この節では、IPsec を設定する過程を説明します。 IPsec を設定するためには、 カスタムカーネルの構築方法をよく知っている必要があります (FreeBSD カーネルのコンフィグレーション をご覧ください)。

IPsec は、インターネットプロトコル (IP) レイヤのトップにあるプロトコルです。 二つもしくはそれ以上のホスト間で安全に通信することを可能にします。 FreeBSD の IPsec "ネットワークスタック" は、 IPv4 および IPv6 の両方に対応している KAME 実装をベースとしています。

IPsec は二つのサブプロトコルから構成されます。

ESP および AH は、使用する環境に合わせて、 一緒に使うことも別々に使うこともできます。

IPsec は、直接二つのホスト間のトラフィックを暗号化する Transport Mode、もしくは "virtual tunnels" を構築する Tunnel Mode のどちらでも用いることができます。 後者のモードはより一般的には、 Virtual Private Network (VPN) として知られています。 FreeBSD での IPsec サブシステムに関するより詳細な情報については、 ipsec(4) を参照してください。

カーネルに IPsec のサポートを追加するには、 カスタムカーネルコンフィグレーションファイルに以下のオプションを追加してください。

IPsec のデバッグサポートが必要であれば、 以下のカーネルオプションを追加してください。

VPN の構成についての標準はありません。 VPN は、数多くの技術と共に実装することが可能です。 その各技術には、それ自身の長所と短所があります。 この節では、以下のシナリオに対して VPN を実装する戦略について説明します。

データがネットワークを平文で流れてしまうと、 ネットワークをクライアントとサーバの間のどこかで盗聴することで、 あなたのユーザ/パスワード情報やセション中を流れるデータを盗むことが可能です。 OpenSSH はこれらを予防する為にさまざまな認証と暗号化の方法を提供します。

sshd(8) が有効になっているかどうかを確認するには、 /etc/rc.conf の以下の行を確認してください。

この設定により、次のシステムの初期化時に OpenSSH のデーモンプログラムである sshd(8) が起動します。 もしくは service(8) を使って、すぐに OpenSSH を起動することもできます。

ssh(1) を使って、 sshd(8) が動いているシステムに接続するには、 ログインをするユーザ名とホストを指定してください。

SSH はクライアントが接続した時、 サーバの信頼性の検証のために鍵指紋システム (key fingerprint system) を利用します。 初めての接続の際に、ユーザは yes と入力することを要求されます。 これ以降の login では保存されていた鍵指紋を照合することで検証が行われ、 ssh(1) クライアントは保存されていた鍵指紋が login しようとした際に送られてきたものと異なっていた場合には警告を表示します。 指紋は ~/.ssh/known_hosts に保存されます。

デフォルトでは、sshd(8) の最近の版では SSH v2 の接続のみを受け付けるように設定されています。 クライアントは可能であればバージョン 2 を用い、 バージョン 1 にフォールバックします。 クライアントは、プロトコル v1 と v2 についてそれぞれ、引数 -1 または -2 を渡すことで、利用するプロトコルを指定できます。 クライアントにおけるバージョン 1 への互換性は、 古いバージョンへの上位互換のために維持されています。

ローカルのファイルをリモートマシンへ、 あるいはリモートマシンのファイルをローカルに安全な方法でコピーするには、 scp(1) を使用してください。

前回の例でこのホストの指紋がすでに保存されていれば この scp(1) を使う時に検証が行なわれます。

scp(1) に渡される引数は、cp(1) のものと似ており、コピーするファイル (1 つまたは複数) が 1 つめの引数になり、コピー先が 2 つめの引数になります。 ファイルはネットワーク越しに SSH 接続を通して送られるので、 引数に指定するファイルに user@host:<path_to_remote_file> という形式をとるものがあります。

システム全体の設定ファイルは、OpenSSH デーモン、クライアントの両方とも /etc/ssh にあります。

ssh_config はクライアントの動作設定、 sshd_config はデーモンの動作設定を行ないます。 それぞれのファイル毎にマニュアルページが用意されており、 利用可能な設定オプションについて説明されています。

パスワードの代わりに ssh-keygen(1) を使ってユーザの認証用の DSA または RSA 暗号鍵を作ることができます。

ssh-keygen(1) は認証に使う為の公開鍵と秘密鍵のペアを作ります。 DSA または RSA 鍵に応じて、 秘密鍵は ~/.ssh/id_dsa または ~/.ssh/id_rsa に保存され、 公開鍵は ~/.ssh/id_dsa.pub または ~/.ssh/id_rsa.pub にそれぞれ保存されます。 公開鍵はセットアップのために、 DSA または RSA のどちらを使う場合にも、 リモートマシンの ~/.ssh/authorized_keys に含まれてなければなりません。

この設定により、パスワードに代わり、 SSH 鍵を使ってリモートマシンに接続できるようになります。

ssh-keygen(1) でパスフレーズを使っている場合は、 秘密鍵を使うためにユーザは毎回パスフレーズを入力する必要があります。 長いパスフレーズを毎回入力しなくてはならない負担は、 ssh-agent(1) を使うと軽減できます。 これについては、 SSH Agent による鍵のキャッシュ で説明されています。

パスフレーズを毎回入力することなしに、 SSH 鍵を利用できるようにメモリに読み込むには、 ssh-agent(1) および ssh-add(1) を使用してください。

ssh-agent(1) は、 読み込まれた秘密鍵による認証を取り扱います。 ssh-agent(1) は他のアプリケーションの起動に用いられる必要があります。 基本的なレベルではシェル、 またはウィンドウマネージャを起動します。

シェル上で ssh-agent(1) を使うには、 引数としてシェルを起動してください。 次に、ssh-add(1) を実行し、 秘密鍵のパスフレーズを入力することにより、 鍵を追加してください。 一度この過程を終えてしまえば、ユーザは、 対応する公開鍵が置かれているホストに ssh(1) でログインできるようになります。 以下はその例です。

Xorg 上で ssh-agent(1) を使うには、 ssh-agent(1) への呼び出しが ~/.xinitrc に置かれている必要があります。 これにより、Xorg 上で起動されるすべてのプログラムにおいて、 ssh-agent(1) サービスが提供されるようになります。 ~/.xinitrc の例は以下となります。

これで、Xorg を開始するときにはいつでも ssh-agent(1) が起動され、 このプログラムから XFCE が起動されます。 Xorg を再起動した後は有効になりますので、 ssh-add(1) を実行して、 すべての SSH 鍵を読み込ませてください。

OpenSSH は暗号化されたセッションの中に他のプロトコルをカプセル化するトンネルを作ることができます。

以下のコマンドは ssh(1) で telnet(1) 用のトンネルを作成します。

この例では、以下のオプションを使っています。

SSH のトンネルは localhost の指定されたポートに listen するソケットを作ることで実現されています。 SSH はローカルのホスト/ポートで受けた接続すべてを SSH 接続経由で指定されたリモートホストのポートへ転送します。

この例では、localhost のポート 5023 がリモートマシンの localhost のポート 23 に転送されるようになっています。 23 は telnet(1) で用いられるので、これは SSH トンネルを通る暗号化された man.telnet.1; セッションを作ります。

このようにして SMTP や POP3 および FTP といったセキュアではない TCP プロトコルをカプセル化できます。

ログインできるユーザや接続元を AllowUsers を使って制限することは、通常は良い考えです。 たとえば、 root が 192.168.1.32 からのみログインできるようにするには、 以下の行を /etc/ssh/sshd_config に追加してください。

admin がどこからでもログインできるようにするには、 ユーザ名そのものを記述してください。

複数のユーザは、以下のように同じ行に追加してください。

/etc/ssh/sshd_config への変更が終わったら、 以下を実行して、設定ファイルを sshd(8) に読み込ませてください。

OpenSSH ウェブサイト

クライアントオプションについて ssh(1), scp(1), ssh-keygen(1), ssh-agent(1), ssh-add(1) および ssh_config(5)

サーバオプションについて sshd(8), sftp-server(8), sshd_config(5)

getfacl(1) は、 ファイルシステムの ACL を表示します。 たとえば、test の ACL 設定を表示するには、 以下のコマンドを実行してください。

このファイルの ACL 設定を変更するには、 setfacl(1) を使用してください。

ファイルまたはファイルシステムから、 現在設定されている ACL をすべて取り除くには、-k を使ってください。 しかしながら、より好ましい方法は、 -b を使う方法です。 このオプションを使うと、ACL が動作するのに必要な基本のフィールドは残ります。

この例では、-m は、デフォルト ACL エントリを修正するために使われています。 先ほどのコマンドで設定は削除されたため、 定義されたエントリはありません。 このコマンドは、デフォルトオプションに戻し、 指定したオプションを割り当てます。 システムに存在しないユーザまたはグループを追加すると、 Invalid argument エラーが出力されてしまいます。

以下は FreeBSD セキュリティ勧告の例です。

すべてのセキュリティ勧告は以下のフォーマットに基づいています。

プロセスアカウンティングを使用する前に、 以下のコマンドを使って、 プロセスアカウンティングを有効にしておく必要があります。

一度有効に設定すると、アカウンティングは、 CPU の統計、 実行されたコマンドの情報の追跡を開始します。 すべてのアカウンティングログは、 人が読めるような形式ではなく、 sa(8) を使って見ることができます。 オプションを設定せずに実行すると、 sa(8) はユーザコールの数、全経過時間 (分)、 全 CPU、ユーザの時間 (分)、および I/O 操作の平均数などを出力します。

実行されたコマンドに関する情報を見るには、 lastcomm(1) を使ってください。 このコマンドは、 ユーザが特定の ttys(5) で実行したコマンドを出力します。 たとえば、以下のコマンドは ttyp1 ターミナル上で trhodes が実行した ls(1) の使用について、記録されているすべて示します。

他にも有用なオプションが多くあり、 lastcomm(1), acct(5) および sa(8) で説明されています。

伝統的な方法では、ログインクラスおよびログインクラスに適用するリソースの制限は /etc/login.conf で定義します。 各ユーザアカウントにはログインクラスが割り当てられています (デフォルトでは default です)。 それぞれのログインクラスには関連するログインケーパビリティの集合が割り当てられています。 ログインケーパビリティとは、 名称=値 の組のことで、名称 は周知の識別子、値 は、名称 に応じて処理される任意の文字列です。

リソースの制限は、 2 つの点で標準的なログインケーパビリティと異なっています。 第一に、どの制限についても、 ソフト リミットと _ハード _リミットがあります。 ソフトリミットは、ユーザやアプリケーションが調整できますが、 ハードリミットを超えることはできません。 ユーザはハードリミットを下げることはできますが、 上げることはスーパユーザのみができます。 第二に、ほとんどのリソースの制限は特定のユーザに対してプロセス毎に適用されるものです。

ログインクラスのリソースの制限 が最もよく使われるリソースの制限です。 利用可能なすべてのリソースの制限およびのログインケーパビリティの詳細については、 login.conf(5) に書かれています。

リソースの制限を設定するにあたり、ほかにもいくつか覚えておかなければならないことがあります。

リソースの制限と、ログインクラス、 ログインケーパビリティ一般についての詳しい情報は、 cap.mkdb(1), getrlimit(2) および login.conf(5) をご覧ください。

kern.racct.enable をゼロ以外の値に設定してください。 カスタムカーネルには以下のような特別な設定が必要となります。

システムを再起動して新しいカーネルで立ち上げると、rctl を用いてシステムにルールを設定できるようになります。

ルールの構文は、 subject, subject-id, resource および action を使って管理されます。 以下のルールの例を参照してください。

この例では、subject は user、subject-id は trhodes、resource の maxproc はプロセスの最大数、そして action は deny と設定されており、 新しいプロセスの生成がブロックされます。 これは、ユーザ trhodes のプロセスは 10 個に制限され、それ以上のプロセスは作成できないことを意味しています。 他には、コンソールにログを出力したり、 devd(8) に対し通知したり、プロセスに sigterm を送ったりといった action も利用できます。

ルールを追加する際には、注意すべき点がいくつかあります。 上の例では、プロセスの数が 10 に制限されているため、ログインして screen セッションを実行してしまうと、ユーザによる他のタスクの実行はブロックされてしまうでしょう。 リソースの制限が適応されると、エラーが出力されます。 この例では以下のような出力が行われます。

他の例としては、jail がメモリの制限を超えることを防ぐことができます。 このルールは以下のように書くことができます。

ルールを /etc/rctl.conf に追加すると、再起動してもルールは持続します。 フォーマットは、ルールから最初のコマンドの部分を除いたものとなります。 たとえば、上のルールを追加するには、以下のように追加してください。

ルールを削除するには、rctl に対し、リストから削除するように指定してください。

rctl(8) には、ルールをすべて削除する方法が記載されています。 しかしながら、特定のユーザのルールをすべて削除するには、以下のようなコマンドを実行してください。

subjects をコントロールするリソースは他にも多く用意されています。 これらについて知るには、rctl(8) をご覧ください。