|
|
|
|
@ -48,9 +48,9 @@ toc::[]
|
|
|
|
|
[[security-synopsis]]
|
|
|
|
|
== この章では
|
|
|
|
|
|
|
|
|
|
この章では、基本的なシステムセキュリティの考え方、 覚えておくべき一般的なルールを紹介し、 FreeBSD における高度な話題について簡単に説明します。 ここで扱う話題の多くは、 一般的なシステムやインターネットセキュリティにもあてはまります。 システムを安全に保つことは、データ、知的財産、時間、その他を、 ハッカーやその同類から守るためには欠かせません。
|
|
|
|
|
物理的もしくは仮想的に関わらず、 セキュリティは幅広いトピックであり、 業界全体がセキュリティとともに成長しています。 システムおよびネットワークを安全にする標準的な方法は数多く文書化されており、 FreeBSD のユーザも、 攻撃や侵入者から守る方法を理解しなければなりません。
|
|
|
|
|
|
|
|
|
|
FreeBSD は、 システムとネットワークの整合性および安全性を保護する仕組みと一連のユーティリティを提供しています。
|
|
|
|
|
この章では、セキュリティの基礎や技術について説明します。 FreeBSD システムは、複数のレイヤに関連するセキュリティを提供します。 そして、安全性を高めるためにサードパーティ製のユーティリティを利用することもできます。
|
|
|
|
|
|
|
|
|
|
この章を読むと、以下のことがわかります。
|
|
|
|
|
|
|
|
|
|
@ -74,188 +74,220 @@ FreeBSD は、 システムとネットワークの整合性および安全性
|
|
|
|
|
[[security-intro]]
|
|
|
|
|
== はじめに
|
|
|
|
|
|
|
|
|
|
セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。 FreeBSD は、固有のセキュリティ機構を備えていますが、 追加のセキュリティ機構を設定し保守する仕事はおそらく、 システム管理者としてもっとも大きな責務の一つでしょう。
|
|
|
|
|
セキュリティを高めることはすべての人の責任です。 システムに弱い侵入ポイントが存在すると、侵入者は重要な情報を得たり、 ネットワーク全体に被害を及ぼすことができるようになります。 多くのセキュリティのトレーニングでは、 情報システムの機密性 (confidentiality)、 完全性 (integrity) および可用性 (availability) を意味するセキュリティの 3 要素である CIA が取り扱われます。
|
|
|
|
|
|
|
|
|
|
また、システムセキュリティには、 さまざまな形での攻撃に対処することとも関係しています。 攻撃の中には `root` 権限を奪おうとはしないけれども、 クラッシュやシステムの不安定状態を引き起こそうとするものもあります。 このセキュリティ問題は、いくつかに分類することが可能です。
|
|
|
|
|
CIA の 3 要素は、 コンピュータセキュリティの基本となる考えです。 顧客やエンドユーザは、データのプライバシーを期待します。 彼らは、データが変更されないことや、 情報が隠されていることを期待します。 彼らはまた、いつでも情報にアクセスできることを期待します。 これらは、システムの機密性、完全性、可用性を構成します。
|
|
|
|
|
|
|
|
|
|
. サービス妨害攻撃 (denial of service attack)
|
|
|
|
|
. ユーザアカウントの不正利用 (user account compromise)
|
|
|
|
|
. アクセス可能なサービスを使った root 権限の不正利用
|
|
|
|
|
. ユーザアカウントを経由した root 権限の不正使用
|
|
|
|
|
. バックドアの設置
|
|
|
|
|
セキュリティのプロフェッショナルは、CIA を守るために、多層防衛の戦略を採用します。 この多層防衛戦略ではセキュリティのレイアを複数用意することで、 一つのレイヤが破られても、 セキュリティシステム全体が破られることを防ぎます。 システムの管理者は、ファイアウォールを単に有効にするだけではなく、 ネットワークもしくはシステムを安全に保つ必要があります。 アカウントを監査し、バイナリの完全性、 悪意のあるツールがインストールされていないことを確認する必要があります。 このために、 管理者は脅威がどのようなものかを理解する必要があります。
|
|
|
|
|
|
|
|
|
|
サービス妨害攻撃 (DoS 攻撃) とは、 マシンから必要な資源を奪う行為です。 通常、サービス妨害攻撃はそのマシンで実行されるサーバやネットワークスタックを過負荷状態にして、 マシンをクラッシュさせたり、 マシンを使えなくしたりするような力任せの方法です。 サーバプロセスに対する攻撃は、オプションを適切に指定することによって、 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで対応できる場合が多いです。これらに比べると、 ネットワークへの力任せの攻撃への対応はずっと難しくなります。 この攻撃によって、マシンを落としてしまうことはできないかもしれませんが、 接続しているインターネット回線を飽和させてしまうことはできます。
|
|
|
|
|
[[security-threats]]
|
|
|
|
|
=== 脅威
|
|
|
|
|
|
|
|
|
|
ユーザアカウントの不正利用は、 DoS 攻撃よりもずっとよくある問題です。 このご時勢でも、 暗号化されていないサービスを実行させているシステム管理者は多く、 そのため、リモートからログインしているユーザは、 パスワードを覗き見られてしまう危険性があります。 システム管理者が注意深い人ならば、 リモートアクセスログを解析して、 疑わしい送信元アドレスや疑わしいログインを探すものです。
|
|
|
|
|
コンピュータセキュリティおける脅威とは何でしょうか？ 長年、脅威はリモートの攻撃者、 すなわち遠隔からの許可のないシステムへのアクセスを企てる人々と考えられていました。 今日では、この定義は従業員、悪意のあるソフトウェア、 不正なネットワークデバイス、自然災害、セキュリティの脆弱性、 そして競合する会社でさえも含めるように拡張されています。
|
|
|
|
|
|
|
|
|
|
セキュリティを十分維持し、 手入れの行き届いたシステムにおいては、 あるユーザアカウントへのアクセスが可能となっても、 必ずしも攻撃者に `root` へのアクセス権を与えるとは限りません。 `root` へのアクセス権がなければ、 攻撃者は自分の侵入の痕跡を隠蔽することができませんし、 そのユーザのファイルを引っかき回したり、 マシンをクラッシュさせたりするのがせいぜいです。 ユーザアカウントの不正利用はめずらしいことではありません。 なぜなら一般ユーザは、 システム管理者ほど注意を払わない傾向があるからです。
|
|
|
|
|
毎日、数千ものシステムおよびネットワークが攻撃され、 数百ものシステムが許可なくアクセスされています。 簡単なアクシデントといったものから、リモートからの攻撃、 産業スパイであったり、以前働いていた従業員からの攻撃といったケースもあります。 システムのユーザとしては、 間違いがセキュリティ違反に繋がった場合には、 可能性のある問題をセキュリティチームに報告することが重要です。 管理者としては、脅威を把握し、 その脅威の影響を小さくするように準備をしておくことが重要です。
|
|
|
|
|
|
|
|
|
|
`root` 権限を奪取する方法は、潜在的に何通りもあります。 攻撃者は `root` のパスワードを知っているかもしれませんし、 攻撃者が `root` 権限で実行されているサービスのバグの脆弱性を利用できるかもしれません。 また、攻撃者は SUID-root プログラムに存在するバグを知っているかもしれません。 攻撃者は、 バックドアとして知られているプログラムを使って脆弱性なシステムを探したり、 修正されていない脆弱性を利用してアクセスしたり、 攻撃者による違法行為の痕跡を消そうとしたりするかもしれません。
|
|
|
|
|
[[security-groundup]]
|
|
|
|
|
=== ボトムアップアプローチ
|
|
|
|
|
|
|
|
|
|
セキュリティを改善する方法は、常に、 タマネギの皮のように階層化する手法 (a multi-layered "onion peel" approach) で実装されるべきです。これらは次のように分類できます。
|
|
|
|
|
セキュリティを考える上で、 しばしばボトムアップアプローチが一番良い方法となります。 この考えでは、管理者が基本的なアカウント、システム設定を行ってから、 サードパーティ製ユーティリティの設定、 そしてネットワークレイヤに設定を広げていきます。 システムポリシーおよび手続きを行う上では、 このような設定の側面があります。
|
|
|
|
|
|
|
|
|
|
. `root` とスタッフのアカウントの安全性を高める。
|
|
|
|
|
. `root` の安全性を高める - `root` 権限で動作するサーバと SUID/SGID バイナリ。
|
|
|
|
|
. ユーザアカウントの安全性を高める。
|
|
|
|
|
. パスワードファイルの安全性を高める。
|
|
|
|
|
. カーネルのコア、raw デバイス、 ファイルシステムの安全性を高める。
|
|
|
|
|
. システムに対して行なわれた、 不適切な変更をすばやく検出する。
|
|
|
|
|
. 必要と思われる以上の対応をとる (paranoia)。
|
|
|
|
|
ビジネスの多くの環境では、 使用するデバイスの設定に対するセキュリティポリシがすでに策定されています。 このポリシには、最低限エンドユーザのワークステーション、 デスクトップ、携帯電話やラップトップといったモバイルデバイス、および 製品および開発サーバの両方に対するセキュリティの設定が含まれているべきです。 多くの場合には、コンピュータのセキュリティを考える際に、 標準作業手続書 (SOP) がすでに存在します。 わからなければ、セキュリティチームに尋ねてください。
|
|
|
|
|
|
|
|
|
|
次の節では、上記の項目についてより深く掘り下げていきます。
|
|
|
|
|
[[security-accounts]]
|
|
|
|
|
=== システムおよびユーザアカウント
|
|
|
|
|
|
|
|
|
|
[[securing-freebsd]]
|
|
|
|
|
== FreeBSD の安全性を高める
|
|
|
|
|
システムを安全にするにあたり、最も適切な出発点は、 アカウントの監査です。 ルートアカウントのパスワードが強力であること、 シェルアクセスを必要としないアカウントは無効にすることを確実におこなってください。 また、権限を必要とするユーザに対しては、 package:security/sudo[] をインストールして、 アクセスが必要となるアプリケーションのみにアクセスを許可するようにしてください。 root ユーザのパスワードは、決して共有すべきではありません。
|
|
|
|
|
|
|
|
|
|
この節では、<<security-intro,前節>> でとりあげた FreeBSD システムの安全性を高める方法について説明します。
|
|
|
|
|
|
|
|
|
|
[[securing-root-and-staff]]
|
|
|
|
|
=== `root` アカウントの安全性を高める
|
|
|
|
|
|
|
|
|
|
ほとんどのシステムでは、 `root` アカウントに割り当てたパスワードが 1 つあります。 このパスワードは__いつでも__不正利用の危険に晒されていると考えてください。 これはパスワードを無効にすべきだと言っているのではありません。 パスワードは、マシンにコンソールからアクセスするのには、 ほとんどいつでも必要なものです。 しかしながら、コンソール以外からは、 そして可能なら man:su[1] コマンドを実行する場合もパスワードを使えないようにするべきです。 たとえば、[.filename]#/etc/ttys# のエントリにおいて、 特定のターミナルに対し `root` でログインできないように `insecure` と設定してください。 FreeBSD では、デフォルトで、 [.filename]#/etc/ssh/sshd_config# において `PermitRootLogin` が `no` と設定されているので、man:ssh[1] を使った `root` へログインは無効になっています。 すべてのアクセス手段、たとえば FTP ようなサービスは、良くクラックの対象となることを理解してください。 `root` への直接ログインは、 システムコンソール経由でのみ可能であるべきなのです。
|
|
|
|
|
|
|
|
|
|
システム管理者は `root` になれるようにしておく必要があるので、 追加のパスワード認証の設定が必要となります。 ひとつは、適切なユーザアカウントを [.filename]#/etc/group# 中の `wheel` に加える方法です。 `wheel` のメンバは、man:su[1] を使って `root` になることが許されます。 実際に `root` アクセスの必要なユーザのみ `wheel` に置くようにすべきです。 Kerberos を使用して認証行う場合には、 `root` のホームディレクトリに [.filename]#.k5login# を作成することで、 誰も `wheel` に置く必要なく man:ksu[1] することを許可できます。
|
|
|
|
|
|
|
|
|
|
アカウントを完全にロックするには、 man:pw[8] を使ってください。
|
|
|
|
|
アカウントへのアクセスを無効にする方法は二通りあります。 一つ目の方法は、アカウントをロックする方法です。例として、 toor アカウントをロックする方法を以下に示します。
|
|
|
|
|
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# pw lock staff
|
|
|
|
|
# pw lock toor
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
これにより、指定されたユーザは、man:ssh[1] を含むいかなる方法でもログインできなくなります。
|
|
|
|
|
このコマンドは、アカウントの設定を "toor:*:0:0::0:0:Bourne-again Superuser:/root:" から "toor:*LOCKED**:0:0::0:0:Bourne-again Superuser:/root:" へと変更します。
|
|
|
|
|
|
|
|
|
|
アカウントへのアクセスをブロックするもう一つの方法は、 暗号化されたパスワードを "`*`" 1 文字に置き換えることです。 この文字は、暗号化されたパスワードにマッチすることはないので、 ユーザアクセスをブロックします。 たとえば、次のアカウントのエントリを、
|
|
|
|
|
ときには (おそらく追加のサービスのために)、 この方法が使えない場合があります。 そのような場合には、以下の例のように、 シェルを /sbin/nologin に変更することで、 ログインアクセスを拒否できます。
|
|
|
|
|
|
|
|
|
|
[.programlisting]
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh
|
|
|
|
|
# chsh -s /usr/sbin/nologin toor
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
man:vipw[8] を使って以下のように変更します。
|
|
|
|
|
[NOTE]
|
|
|
|
|
====
|
|
|
|
|
他のユーザのシェルは、スーパーユーザのみが変更できます。 通常のユーザが行おうとすると失敗します。
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
アカウント情報は、以下のように最後のエントリが "nologin" シェルとなります。
|
|
|
|
|
|
|
|
|
|
[.programlisting]
|
|
|
|
|
....
|
|
|
|
|
foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh
|
|
|
|
|
toor:*:0:0::0:0:Bourne-again Superuser:/root:/usr/sbin/nologin
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
この変更によって `foobar` は、 通常のログインはできなくなります。 このようなアクセス制限をした後は、 サイトで Kerberos をセットアップしたり、 ユーザが man:ssh[1] の鍵を設定するなどといった認証手段を利用しなければなりません。
|
|
|
|
|
|
|
|
|
|
これらのセキュリティの仕組みでは、 制限の強いサーバから制限の弱いサーバへログインすることを前提としています。 たとえば、サーバがネットワークサービスを実行させている場合、 ワークステーションではそれらのサービスを実行させてはなりません。 ワークステーションを十分に安全にしておくためには、 実行するサービスをゼロにするか、可能な限り減らし、 パスワードで保護されたスクリーンセーバを走らせておくべきです。 システムへの物理的アクセスが与えられたとすると、 もちろん言うまでもなく、 攻撃者はいかなる種類のセキュリティをもうち破ることができるのです。 幸いにも、システム破りの大多数は、ネットワーク経由でリモートから、 システムへの物理的アクセス手段を持たない人々によって行われています。
|
|
|
|
|
[.filename]#/usr/sbin/nologin# シェルは、 man:login[1] コマンドがこのユーザにシェルを割り当てることをブロックします。
|
|
|
|
|
|
|
|
|
|
Kerberos を使うことで、 ユーザのパスワードの変更もしくは停止を一箇所で行なうことと、 ユーザがアカウントを持つすべてのマシンに即時にその効果を及ぼすことが可能となります。 アカウントが危険に晒されたときに、 すべてのマシン上の関連するパスワードを即座に変更する能力を過小評価してはいけません。 Kerberos では、Kerberos チケットにタイムアウトを設定でき、 設定した期間が経過するとユーザに新しいパスワードを選ぶように要求するといった追加の制限を課することができます。
|
|
|
|
|
[[security-sudo]]
|
|
|
|
|
=== アカウントの権限を拡大する
|
|
|
|
|
|
|
|
|
|
=== root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める
|
|
|
|
|
場合によっては、 システム管理者へのアクセスを他のユーザと共有する必要があります。 FreeBSD はこのために二つの方法を用意しています。 第一の方法は推奨されませんが、 ルートのパスワードを共有し、ユーザを `wheel` グループに加える方法です。 これを行うにには、[.filename]#/etc/group# を編集し、 最初のグループの最後にユーザを追加してください。 ユーザはカンマ区切りで管理されています。
|
|
|
|
|
|
|
|
|
|
用心深いシステム管理者は、必要なサービスだけを有効にし、 サードパーティ製のサーバは、 よくバグを持っていがちだということに注意しているものです。 注意深くチェックしていないサーバは、決して実行してはいけません。 多くのデーモンは、サービス専用のアカウント、もしくは _砂場 (sandbox)_ で起動させることができるので、 `root` 権限でサービスを実行する前には、よく考えてください。 man:telnetd[8] または man:rlogind[8] のような安全ではないサービスは有効にしないでください。
|
|
|
|
|
権限の拡大をする適切な方法は、 package:security/sudo[] port を使う方法です。 この port は、追加の監査、よりきめ細かいユーザ管理、および ユーザを man:service[8] のような権限が与えられたコマンのみの実行に制限することもできます。
|
|
|
|
|
|
|
|
|
|
他のシステムの潜在的なセキュリティホールには、 SUID-root および SGID バイナリがあります。 これらのバイナリは、 man:rlogin[1] のように、[.filename]#/bin#, [.filename]#/sbin#, [.filename]#/usr/bin# または [.filename]#/usr/sbin# に存在するものがほとんどです。 100% 安全なものは存在しないとはいえ、 システムデフォルトの SUID/SGID バイナリは比較的安全といえます。 SUID バイナリは、 スタッフのみがアクセス可能な特別なグループに制限し、 使わない SUID バイナリは削除することが推奨されます。 SGID バイナリもほとんど同様の危険な存在になり得ます。 侵入者が kmem に SGID されたバイナリを破ることができた場合、 その侵入者は [.filename]#/dev/kmem# を読み出すことができるようになるでしょう。つまり、 暗号化されたパスワードファイルを読み出すことができるようになるので、 ユーザアカウントを、潜在的な危険に晒すことになります。他にも、 `kmem` グループを破った侵入者が pty を通して送られたキーストロークを監視できるという危険があります。 キーストロークには、安全な方法でログインするユーザが使っている pty も含まれます。 `tty` グループを破った侵入者は、ほぼ任意のユーザの tty へ書き込みができます。 ユーザが端末プログラムやキーボードをシミュレーションする機能を持ったエミュレータを使っている場合、 侵入者は潜在的に、 結局そのユーザとして実行されるコマンドをユーザの端末にエコーさせるデータストリームを生成できる可能性があります。
|
|
|
|
|
インストールが終わったら、 `visudo` インタフェースを使って [.filename]#/usr/local/etc/sudoers# ファイルを編集してください。 以下の例では、新しく webadmin グループが作成され、 `trhodes` ユーザがこのグループに追加されます。 その後、ユーザに package:apache24[] を再起動するアクセス権限を与えます。 この手続きは以下のようになります。
|
|
|
|
|
|
|
|
|
|
[[secure-users]]
|
|
|
|
|
=== ユーザアカウントの安全性を高める
|
|
|
|
|
|
|
|
|
|
ユーザアカウントは、普通、安全性を高めることが最も困難です。 気を配ってユーザアカウントを監視するよりほかありません。 ユーザアカウントに対し man:ssh[1] や Kerberos を利用するには、 システム管理がさらに増えたりテクニカルサポートが必要になりますが、 暗号化パスワードファイルと比較するとはるかに良い方法を提供します。
|
|
|
|
|
|
|
|
|
|
=== パスワードファイルの安全性を高める
|
|
|
|
|
|
|
|
|
|
できるだけ多くのパスワードをアスタリスクで外し、 それらのアカウントのアクセスには man:ssh[1] や Kerberos を使うようにすることが、唯一の確実な方法です。 暗号化パスワードファイル ([.filename]#/etc/spwd.db#) は `root` でのみ読み出し可能だけれども、 たとえ、侵入者が root の書き込み権限は得られなくとも、 読み出しアクセス権限を得ることは可能かもしれません。
|
|
|
|
|
|
|
|
|
|
<<security-integrity,ファイルの完全性のチェック>> 節で説明されているように、 セキュリティスクリプトでパスワードファイルの変更をチェックし、 報告するようにすべきです。
|
|
|
|
|
|
|
|
|
|
=== カーネルのコア、raw デバイス、 ファイルシステムの安全性を高める
|
|
|
|
|
|
|
|
|
|
最近のカーネルは、組み込みのパケット覗き見デバイス (packet sniffing device) ドライバを備えているものがほとんどです。 FreeBSD では [.filename]#bpf# と呼ばれています。 このデバイスは DHCP で必要となるため、 DHCP を提供したり使う必要のないシステムでは、 カスタムカーネルコンフィグレーションファイルから外すことができます。
|
|
|
|
|
|
|
|
|
|
[.filename]#bpf# を外しても、 [.filename]#/dev/mem# および [.filename]#/dev/kmem# という問題がまだ残っています。 侵入者は raw ディスクデバイスに書き込むこともできます。 やる気まんまんの侵入者は、man:kldload[8] を使って自分独自の [.filename]#bpf#、 もしくは他の覗き見デバイスを動作中のカーネルにインストールできます。 この問題を避けるため、カーネルをより高いセキュリティレベル、 少なくともセキュリティレベル 1 で実行させる必要があります。
|
|
|
|
|
|
|
|
|
|
カーネルのセキュリティレベルはいくつかの方法で設定できます。 現在動いているカーネルのセキュリティレベルを高める最も簡単な方法は、 `kern.securelevel` を設定する方法です。
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# pw groupadd webadmin -M trhodes -g 6000
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# sysctl kern.securelevel=1
|
|
|
|
|
# visudo
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
デフォルトでは、FreeBSD のカーネルはセキュリティレベル -1 で起動します。 このセキュリティレベルは、 変更不可のファイルフラグを外したり、 すべてのデバイスに対して読み込みおよび書き込みができたりするので、 "insecure mode" と呼ばれます。 このセキュアレベルは、管理者または man:init[8] による起動時のスクリプトにより変更されない限り -1 のままです。 [.filename]#/etc/rc.conf# において、 `kern_securelevel_enable` を `YES` とし、 `kern_securelevel` に必要とする値を設定することで、 システム起動時にセキュアレベルを高めることができます。
|
|
|
|
|
[.programlisting]
|
|
|
|
|
....
|
|
|
|
|
%webadmin ALL=(ALL) /usr/sbin/service apache24 *
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
セキュリティレベルを 1 以上に設定すると、 追加専用および変更不可ファイルのフラグを外すことはできなくなり、 また raw デバイスへのアクセスが拒否されます。 より高いレベルに設定すると、より多くの操作に制限がかかります。 各セキュリティレベルの完全な説明については、 man:security[7] および man:init[8] をご覧ください。
|
|
|
|
|
ローカルのユーザ管理において、 package:security/sudo[] は、 非常に貴重なリソースを提供します。 また、パスワードを不必要にして、デフォルトを man:ssh[1] 鍵の方法だけにすることもできます。 man:sshd[8] 経由のパスワードによるログインを無効にし、 `sudo` へのローカルパスワードのみを使うようにするには、 <<openssh>> をご覧ください。
|
|
|
|
|
|
|
|
|
|
[[security-passwords]]
|
|
|
|
|
=== パスワード
|
|
|
|
|
|
|
|
|
|
パスワードは、テクノロジーにおける必要悪です。 パスワードは極めて複雑であるだけではなく、 パスワードを保護する強力なハッシュメカニズムもまた必要となります。 この文書を書いている時点では、 FreeBSD は `crypt()` ライブラリで DES, MD5, Blowfish, SHA256 および SHA512 に対応しています。 デフォルトは SHA512 であり、 強度の弱い暗号へは変更すべきではありません。 しかしながら、Blowfish を好むユーザもおります。 DES を除く各メカニズムでは、 開始の文字、使用しているハッシュメカニズムを識別可能な特徴を持っています。 MD5 メカニズムでは、シンボルは "$" の符号です。 SHA256 または、 SHA512 では、シンボルは "$6$"、 そして Blowfish は "$2a$" です。 暗号強度の弱いパスワードを使用している場合には、 次回のログイン時にユーザが man:passwd[1] を実行して再ハッシュ化することを促すべきです。
|
|
|
|
|
|
|
|
|
|
[NOTE]
|
|
|
|
|
====
|
|
|
|
|
セキュリティレベルを 1 以上に設定した場合には、 [.filename]#/dev/io# へのアクセスがブロックされるため、 Xorg や、 `installworld` のプロセスでは、 いくつかのファイルの追加専用および変更不可のフラグは一時的にリセットされるため、 ソースから FreeBSD を構築してインストールするときなどで問題が引き起こされる可能性があります。 Xorg の問題については、 起動プロセス初期のセキュアレベルが十分低いときに man:xdm[1] を起動することで、この問題に対応できます。 このような応急処置は、 すべてのセキュリティレベルやそれらが課す潜在的なすべての制限には対応できないでしょう。 少し先を見越した計画的な対応をすべきです。 各セキュリティレベルで課される制限は、 システムを使用することによる利便性を著しく減らしてしまうため、 この制限を理解することは重要です。 また、各セキュリティレベルの制限を理解することで、 デフォルトの設定をよりシンプルにでき、 設定に関する意外性を少なくできるでしょう。
|
|
|
|
|
この文書を書いている時点で、Blowfish は AES でなければ、 FIPS (Federal Information Processing Standards) に準拠もしていません。 そのため、使用できない環境があります。
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
カーネルのセキュリティレベルを 1 以上に設定した場合には、 システム起動に関わる重要なバイナリやディレクトリ、 スクリプトファイル、そして、 セキュリティレベルが設定されるまでの間に実行されるすべてのものに対して、 `schg` フラグを設定することは有用でしょう。 システムをより高いセキュリティレベルで実行させるようにするが、 `schg` フラグを設定しないというところで妥協するという手もあります。 もう一つの可能性としては、単純に [.filename]#/# および [.filename]#/usr# を読み込み専用でマウントすることです。 ここで特筆すべきことは、システムを守ろうとして厳しくしすぎると、 侵入を検出することができなくなってしまうということです。
|
|
|
|
|
ネットワークに接続しているシステムについては、 二要素認証を使用すべきです。 この認証では、通常あなたが所有する要素と知っている要素が用いられます。 FreeBSD のベースシステムに含まれている OpenSSH および ssh-keys では、 ネットワークへのすべてのログインにおける二要素認証の交換で、 パスワードを使用すべきではありません。 より詳細な情報については、ハンドブックの <<openssh>> 節をご覧ください。 Kerberose のユーザは、ネットワークで OpenSSH を実装するために追加の変更が必要になるでしょう。
|
|
|
|
|
|
|
|
|
|
[[security-integrity]]
|
|
|
|
|
=== ファイルの完全性のチェック
|
|
|
|
|
[[security-rkhunter]]
|
|
|
|
|
=== バックドアおよびルートキット
|
|
|
|
|
|
|
|
|
|
システム管理者にできることは、 便利さという要素がその醜い頭を上げない程度に、 コアシステムの設定と制御ファイルを防御することだけです。 たとえば、[.filename]#/# および [.filename]#/usr# にある大部分のファイルに `schg` ビットを設定するために man:chflags[1] を使用するのは、おそらく逆効果でしょう。 なぜなら、そうすることでファイルは保護できますが、 侵入を検出する窓を閉ざしてしまうことにもなるからです。 セキュリティ対策は、 侵入の可能性を検出できなければ、有用ではなく、 もっと悪ければ、安全性に対する間違った感覚を植え付けてしまいます。 セキュリティに対する仕事の半分は、 攻撃者を攻撃の最中に捕えるようにするために、 攻撃者を食い止めるのではなく侵入を遅らせることなのです。
|
|
|
|
|
バックドアおよびルートキットは、 それらがインストールされた後に脅威となります。 インストールされると、この悪意のあるソフトウェアは、 攻撃者のために侵入口を設置します。 実際的には、システムが一度汚染された後に、調査が行われ、 消去されます。 慎重なセキュリティやシステムエンジニアでさえも、 攻撃者が残したソフトウェアを見逃してしまうという恐ろしいリスクが存在しています。
|
|
|
|
|
|
|
|
|
|
侵入を検出する最も良い方法は、変更されていたり、 消えていたり、入れた覚えがないのに入っているファイルを探すことです。 変更されたファイルを探すのに最も良い方法は、もう一つの しばしば中央に集められた、 アクセスが制限されたシステムから行なうものです。 さらに安全でアクセス制限されたシステム上でセキュリティ用スクリプトを書けば、 スクリプトは潜在的な攻撃者からはほぼ見えなくなります。 この有効性を最大限に活用するためには、 アクセスの制限されたマシンから他のマシンへのかなりのアクセスを許可する必要があります。 普通は、読み込み専用の NFS エクスポートをしたり、 man:ssh[1] 鍵のペアを設定したりします。 ネットワークのトラフィックを別にして、 NFS は最も可視性のない方法です。 管理者は、各クライアント上のファイルシステムを、 事実上検出されずに監視できるようになります。 アクセス制限されたサーバがスイッチを通してクライアントに接続されている場合、 たいてい NFS がより良い選択肢です。 アクセス制限されたサーバが、 いくつかのルーティング層を通してクライアントに接続している場合、 NFS はあまりにも危険なので、 man:ssh[1] の方が良い方法でしょう。
|
|
|
|
|
バックドアまたはルートキットソフトウェアは、 管理者にとって役に立つことが一つあります。 それは、一度検出すると、 システムのどこかが危険に冒されていることの痕跡となります。 しかし、通常この種のアプリケーションは、とてもうまく隠れています。 バックドアおよびルートキットを検出するツールが存在しており、 それうちの一つが、 package:security/rkhunter[] です。
|
|
|
|
|
|
|
|
|
|
アクセス制限されたマシンに、 監視しようとするクライアントシステムへの少なくとも読み込みのアクセス権を与えたら、 次に監視するためのスクリプトを書かなくてはいけません。 NFS マウントをすれば、man:find[1] や man:md5[1] などの単純なシステムユーティリティでスクリプトを書くことができます。 少なくとも 1 日 1 回、クライアントのシステムファイルを直接 man:md5[1] にかけ、 さらにもっと頻繁に [.filename]#/etc# および [.filename]#/usr/local/etc# にあるようなコントロール用ファイルを試験するのが一番です。 アクセス制限されたマシンが正しいと知っている、 基となる md5 情報と比べて違いが見つかった場合、 システム管理者に警告するようにすべきです。 優れたセキュリティ用スクリプトは、 [.filename]#/# および [.filename]#/usr# などのシステムパーティション上で不適当に SUID されたバイナリや、 新たに作成されたファイルや削除されたファイルがないかどうかを調べるでしょう。
|
|
|
|
|
インストール後、以下のコマンドでシステムをチェックできます。 実行すると多くの情報が出力されます。
|
|
|
|
|
|
|
|
|
|
NFS ではなく、man:ssh[1] を使用する場合は、 セキュリティ用スクリプトを書くのはより難しいことです。 たとえば、スクリプトを動かすためには、クライアントに対してスクリプトを man:scp[1] しなくてはいけませんし、 クライアントマシンの man:ssh[1] クライアントはすでに攻撃されてしまっているかもしれません。 安全でないリンク上の場合は man:ssh[1] は必要かもしれませんが、 扱いはとても大変になります。
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# rkhunter -c
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
優れたセキュリティ用スクリプトは、 [.filename]#.rhosts#, [.filename]#.ssh/authorized_keys# などの隠し設定ファイルの変更もチェックするものです。 これらは `MD5` チェックの範囲外になってしまうであろうファイル群です。
|
|
|
|
|
このプロセスを実行中に kbd:[ENTER] キーを何度か押す必要があります。 完了すると、ステータスメッセージが画面に表示されます。 このメッセージは、チェックしたファイルの量、疑わしいファイルの数、 可能性のあるルートキット等の情報を含みます。 チェックの最中、隠されたファイル、 OpenSSH プロトコルの選択、そして、 時には、インストールされているソフトウェアの漸弱性のバージョンに関する一般的なセキュリティの警告が出力されます。 すぐに、もしくはより詳細な解析が行われた後に、対応が可能です。
|
|
|
|
|
|
|
|
|
|
ユーザ用のディスク容量が非常に大きい場合は、 パーティション上の各ファイルを見て回るのに大変な時間がかかるかもしれません。 この場合は、man:mount[8] により `nosuid` を使うことで、マウントフラグを設定して、 SUID されたバイナリを置けないようにするのが良い考えです。 少なくとも週に 1 度はファイルシステムをスキャンするべきです。 なぜなら、目的は、侵入が成功したかどうかに関わらず、 不正侵入の試みがあったことの検出をすることだからです。
|
|
|
|
|
管理者は皆、 担当しているシステム上で何が実行されているかを把握している必要があります。 rkhunter, lsof や man:netstat[1] および man:ps[1] といったネイティブのツールは、 システムに関するかなり多くの情報を与えてくれます。 正常な状態がどのような状態であるかを把握しておき、 本来と違う状況になった場合には、質問をしたり、 疑い深くなってください。 セキュリティが破られることを避けることは理想ですが、 破られたことを把握することは必須です。
|
|
|
|
|
|
|
|
|
|
プロセスアカウンティング (man:accton[8] 参照) は、 マシンへの侵入を検出するためのメカニズムとして推奨できる、 比較的オーバヘッドの少ない FreeBSD の機能です。 侵入を受けた後でも当該ファイルが無傷である場合に、 侵入者がどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。
|
|
|
|
|
[[security-ids]]
|
|
|
|
|
=== バイナリ検証
|
|
|
|
|
|
|
|
|
|
最後に、 セキュリティスクリプトはログファイルを処理するようにし、 ログファイル自体もできるだけ安全性の高い方法で生成するようにし、 リモートの syslog サーバに送信するようにすべきです。 侵入者は自分の侵入の痕跡を覆い隠そうとしますし、また、 ログファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆくために極めて重要です。 ログファイルを永久に残しておくための 1 つの方法は、 システムコンソールをシリアルポートにつないで走らせ、 コンソールを監視している安全なマシンに情報を集めることです。
|
|
|
|
|
システムファイルおよびバイナリの検証は、 システム管理者およびセキュリティチームに対して、 システムの変更に関する情報を提供してくれるため重要です。 いかなるシステムにおいても、システム管理チームの知らないところで、 内部のコマンドやアプリケーションは変更すべきではありません。 システムの変更ををモニタリングするソフトウェアアプリケーションは、 侵入検知システム (Intrusion Detection System) または IDS と呼ばれます。
|
|
|
|
|
|
|
|
|
|
=== 偏執狂的方法
|
|
|
|
|
FreeBSD は、基本的な IDS システムをネイティブで提供しています。 実際に、毎晩の man:periodic[8] セキュリティに関するメールの中では、 管理者に変更点を通知します。 情報はローカルに保存されているので、 悪意のあるユーザが変更し、情報を "欺く" 可能性があります。 そのため、バイナリの署名の別のセットを作成して、 読み取り専用の root 所有のディレクトリ、できれば、 USB ディスクまたは rsync サーバといったシステムとは別のシステムに保存してください。
|
|
|
|
|
|
|
|
|
|
多少偏執狂的になっても決して悪いことにはなりません。 原則的に、システム管理者は、 便利さに影響を与えない範囲でいくつでもセキュリティ機能を追加することができます。 また、いくらか考慮した結果、 便利さに__影響を与える__セキュリティ機能を追加することもできます。 より重要なことは、 セキュリティ管理者はこれを多少混ぜこぜにして使うべきだということです。 もしこの章で書かれている推奨される方法をそのまま使用した場合は、 予想される攻撃者はやはりこの文書を読んでいるわけですから、 防御策を教えてしまうことになります。
|
|
|
|
|
まず最初に、シードを生成する必要があります。 これは、数値定数で、ハッシュ値の生成やハッシュ値の検証で使われます。 このシードがないと、 ファイルのチェックサムの値を偽ったり検証が可能になります。 以下の例では、シードは `-s` フラグで指定されています。 最初に以下のコマンドを用いて [.filename]#/bin# のハッシュ値およびチェックサムを生成してください。
|
|
|
|
|
|
|
|
|
|
=== サービス妨害攻撃
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > bin_chksum_mtree
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
DoS 攻撃は、普通は、パケット攻撃です。 ネットワークを飽和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシステム管理者が打てる手はそれほど多くありませんが、 一般的に、以下のような方法により、 その種の攻撃によってサーバがダウンしないことを確実にすることで、 被害をある限度に食い止めることはできます。
|
|
|
|
|
このコマンドの出力は以下のようになります。
|
|
|
|
|
|
|
|
|
|
. サーバの fork の制限。
|
|
|
|
|
. ICMP 応答攻撃、ping broadcast などの踏み台攻撃の制限。
|
|
|
|
|
. カーネルの経路情報のキャッシュを過剰に用意する。
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# mtree: /bin checksum: 3427012225
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
よくある DoS 攻撃は、fork するサーバに対して攻撃するもので、 多くの子プロセスを起動させることにより、 メモリ、ファイル記述子などを使いつくし、 ホストシステムを最終的に停止させます。 man:inetd[8] には、 この種の攻撃を制限するオプションがいくつかあります。 マシンがダウンすることを防止することは可能ですが、 この種の攻撃によりサービスが中断することを防止することは一般的に言ってできないことに注意する必要があります。 man:inetd[8] を注意深く読んで下さい。特に、 `-c`, `-C`, `-R` に注意して下さい。IP 偽造攻撃 (spoofed-IP attack) は man:inetd[8] の `-C` の裏をかけるので、 一般にオプションを組み合わせて使用すべきです。 スタンドアロンサーバの中には、自分自身で fork を制限するパラメータを持っているものがあります。
|
|
|
|
|
[.filename]#bin_cksum_mtree# ファイルを見ると、 以下のような出力となります。
|
|
|
|
|
|
|
|
|
|
Sendmail には、 `-OMaxDaemonChildren` があります。 システム負荷の値変化には遅れがあるので、 Sendmail の負荷限界指定オプションを使うよりも、 このオプションを使う方がまともに動作する可能性ははるかに高いです。 Sendmail を開始する際は、 通常見込まれる負荷を扱える程度に十分高いが、 コンピュータが操作できない数の Sendmail インスタンスの値よりは低い値に `MaxDaemonChildren` を設定してください。 Sendmail を `-ODeliveryMode=queued` を使って、 キュー処理モードで実行したり、 デーモン (`sendmail -bd`) をキュー処理用プロセス (`sendmail -q15m`) と別に実行することも、用心深いことと言えます。 リアルタイムでの配送を望むのであれば、 `-q1m` のようにすることで、 キュー処理をはるかに短い時間間隔で行うことができます。 いずれにしても、`MaxDaemonChildren` に合理的な値を確実に指定して、 なだれをうって失敗することがないようにして下さい。
|
|
|
|
|
[.programlisting]
|
|
|
|
|
....
|
|
|
|
|
# user: root
|
|
|
|
|
# machine: dreadnaught
|
|
|
|
|
# tree: /bin
|
|
|
|
|
# date: Mon Feb 3 10:19:53 2014
|
|
|
|
|
# .
|
|
|
|
|
/set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none
|
|
|
|
|
. type=dir mode=0755 nlink=2 size=1024 \
|
|
|
|
|
time=1380277977.000000000
|
|
|
|
|
\133 nlink=2 size=11704 time=1380277977.000000000 \
|
|
|
|
|
cksum=484492447 \
|
|
|
|
|
sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a
|
|
|
|
|
cat size=12096 time=1380277975.000000000 cksum=3909216944 \
|
|
|
|
|
sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69
|
|
|
|
|
chflags size=8168 time=1380277975.000000000 cksum=3949425175 \
|
|
|
|
|
sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3
|
|
|
|
|
chio size=18520 time=1380277975.000000000 cksum=2208263309 \
|
|
|
|
|
sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964
|
|
|
|
|
chmod size=8640 time=1380277975.000000000 cksum=2214429708 \
|
|
|
|
|
sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
コンピュータのホスト名、現在の日付と時間、man:mtree[8] を実行したユーザの情報すべてがこのレポートには含まれています。 また、各バイナリに対するチェックサム、サイズ、タイムスタンプおよび SHA256 ダイジェストも含まれています。
|
|
|
|
|
|
|
|
|
|
バイナリ署名の検証のために、 以下のコマンドを実行すると、現在の署名のリストを読み込み、 結果を出力します。
|
|
|
|
|
|
|
|
|
|
man:syslogd[8] は直接攻撃される可能性があるので、可能ならばいつでも `-s` を用いることを強く推奨します。 これができないなら、 `-a` を使って下さい。
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
逆 identd などの接続返し (connect-back) を行うサービスについては直接攻撃を受ける可能性があるので、 十分注意を払うようにするべきです。 こういう事情があるので、TCP wrapper の逆 ident 機能を使うことは推奨されません。
|
|
|
|
|
このコマンドを実行すると、すでにチェックサムを生成している [.filename]#/bin# に対して、同様のチェックサムを生成します。 このコマンドを実行してから変更が行われていないので、 [.filename]#bin_chksum_output# への主力は空となります。 変更が行われた場合をシミュレートするために、 [.filename]#/bin/cat# ファイルの日付を man:touch[1] を使って変更して、 再度検証のコマンドを実行してみます。
|
|
|
|
|
|
|
|
|
|
境界ルータのところでファイアウォールを設けて、 外部からのアクセスに対して内部サービスを防御することは推奨されます。 これは、LAN の外部からの飽和攻撃を防ぐことにあり、 内部サービスをネットワークベースの `root` 権限への攻撃から防御することにはあまり考慮を払っていません。 ファイアウォールは、デフォルトではすべての通信を禁止し、 許可する通信のみを明示して設定するように、常に排他的に設定して下さい。 FreeBSD では、`net.inet.ip.portrange` man:sysctl[8] 変数により、 動的バインドに使用されるポート番号の範囲を制御できます。
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# touch /bin/cat
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
また別のよくある DoS 攻撃として、 踏み台攻撃と呼ばれるものがあります。これは、 あるサーバを攻撃し、その結果として生成される応答がサーバ自身、 ローカルネットワーク、 もしくは他のマシンを過負荷に追い込むようにする攻撃です。 この種の攻撃の中で最もありふれたものに、 __ICMP ping broadcast 攻撃__があります。 攻撃者は、攻撃するマシンのアドレスを送信元アドレスに設定した ping パケットを偽造して、対象の LAN のブロードキャストアドレスに向けてパケットを送信します。 境界にあるルータがブロードキャストアドレスに対する ping パケットをドロップするように設定されていない場合、LAN は、 詐称された送信元アドレスに向けて、 犠牲となるマシンが飽和するまで応答パケットを生成します。 異なるネットワーク上のいくつものブロードキャストアドレスに対して同時に攻撃する場合には、 とくにひどいことになります。 2 番目の踏み台攻撃は、 サーバの受信ネットワークを飽和させるような ICMP エラー応答を生成するパケットを生成し、 その結果としてサーバが送信ネットワークを ICMP 応答で飽和させてしまう攻撃です。 メモリを消費し尽くさせることにより、 この種の攻撃でサーバをクラッシュさせることが可能です。 サーバが生成した ICMP 応答を十分速く送信できない場合、 とくにひどいことになります。 この種の攻撃の効果を抑制するには、 man:sysctl[8] 変数の `net.inet.icmp.icmplim` を使ってください。 踏み台攻撃の 3 つめの主要なクラスに属する攻撃は、 UDP echo サービスのような、特定の man:inetd[8] 内部サービスに関連するものです。 攻撃者は、送信元アドレスがサーバ A の echo ポートであり、送信先アドレスがサーバ B の echo ポートであるように UDP パケットを偽造します。 ここでサーバ A, B はともに同じ LAN に接続されています。この 2 つのサーバは、 この一つのパケットを両者の間で互いに相手に対して打ち返しあいます。 攻撃者は、このようなパケットをほんのいくつか注入するだけで、 両方のサーバと LAN を過負荷状態にすることができます。 同様の問題が chargen ポートにも存在します。 この手の inetd 内部テストサービスは無効にしてください。
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
偽造パケット攻撃は、 カーネルの経路情報キャッシュに過負荷を生じさせるために用いられることもあります。 `net.inet.ip.rtexpire`, `rtminexpire`, `rtmaxcache` の man:sysctl[8] パラメータを参照して下さい。 でたらめな送信元 IP アドレスを用いた偽造パケット攻撃により、 カーネルは、一時的なキャッシュ経路を経路情報テーブルに生成します。 これは `netstat -rna | fgrep W3` で見ることができます。 これらの経路は、普通は 1600 秒程度でタイムアウトになります。 カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを検知すると、 カーネルは動的に `rtexpire` を減らしますが、`rtminexpire` より小さくなるようには決して減らしません。 これにより 2 つの問題が引き起こされます。
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# cat bin_chksum_output
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
. 負荷の軽いサーバが突然攻撃された場合、 カーネルが十分素早く反応できないこと。
|
|
|
|
|
. カーネルが持続的攻撃に耐えられるほど十分 `rtminexpire` が低く設定されていないこと。
|
|
|
|
|
[.programlisting]
|
|
|
|
|
....
|
|
|
|
|
cat changed
|
|
|
|
|
modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
サーバが T3 もしくはそれより高速の回線でインターネットに接続されている場合、 man:sysctl[8] を用いて `rtexpire` と `rtminexpire` を手動で上書きしておくことが思慮深いことといえます。 ただし、どちらか一方でも 0 には決してしないで下さい。 コンピュータをクラッシュさせてしまうことになります。 両パラメータを 2 秒に設定すれば、 攻撃から経路情報テーブルを守るには十分でしょう。
|
|
|
|
|
package:security/aide[] のような、 より高度な IDS システムもありますが、 ほとんどのケースにおいて、 man:mtree[8] は管理者が必要とする機能を提供します。 悪意のあるユーザが、 シード値およびチェックサムの出力を見れないようにすることが重要です。
|
|
|
|
|
|
|
|
|
|
=== Kerberos および man:ssh[1] を用いたアクセスの問題
|
|
|
|
|
[[security-tuning]]
|
|
|
|
|
=== セキュリティのためのシステムの調整
|
|
|
|
|
|
|
|
|
|
もし、Kerberos と man:ssh[1] を使いたいのだとしたら、 両者に関して言っておかねばならない問題がいくつかあります。 Kerberos は大変優れた認証プロトコルですが、Kerberos 化された man:telnet[1] および man:rlogin[1] には、 バイナリストリームを扱うのに不向きになってしまうようなバグがあります。 デフォルトでは、Kerberos は `-x` を使わない限りセッションを暗号化してくれません。 一方 man:ssh[1] では、 デフォルトですべてを暗号化してくれます。
|
|
|
|
|
システムの機能の多くは、man:sysctl[8] を使って調整できます。 Denial of Service (DOS) スタイルの攻撃を避けるためのセキュリティ機能に対しても同様です。 この節では、より重要な調整についても触れています。 man:sysctl[8] により、設定が変更された時はいつでも、 望まない危害が起こる可能性は高まり、 システムの可用性に影響します。 システム全体の設定を変更する時には、 システムの CIA を考える必要があります。
|
|
|
|
|
|
|
|
|
|
man:ssh[1] はとても良く働いてくれますが、 デフォルトで暗号鍵を転送してしまいます。 これは、安全なワークステーションから、 安全でないマシンへのアクセスに man:ssh[1] を使っているユーザにセキュリティリスクを引き起こします。 鍵そのものが見えてしまうわけではありませんが、 man:ssh[1] は login している間、転送用ポートを作ります。 攻撃者が安全でないマシンの `root` を破ったら、 このポートを使って、 この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。
|
|
|
|
|
以下では、man:sysctl[8] の一覧、 および変更がシステムにどのように影響するかを説明します。
|
|
|
|
|
|
|
|
|
|
可能な時はいつでも、スタッフのログインには Kerberos を組み合せた man:ssh[1] を使用することを勧めます。 man:ssh[1] は、Kerberos 対応機能と一緒にコンパイルできます。 こうすると、見えてしまうかもしれない SSH 鍵をあまりあてにしないで良いようになり、 一方で、Kerberos 経由でパスワードが保護されます。 鍵は、安全なマシンからの自動化されたタスクのみに使用するべきです。 Kerberos はこの用途には不向きです。 また、SSH の設定で鍵転送をしないようにするか、 あるいは [.filename]#authorized_keys# の `from=IP/DOMAIN` を使用して、 特定のマシンからログインしてきたときのみ鍵が有効であるようにすることも勧めます。
|
|
|
|
|
デフォルトでは、FreeBSD のカーネルはセキュリティレベル -1 で起動します。 このセキュリティレベルは、 変更不可のファイルフラグを外したり、 すべてのデバイスに対して読み込みおよび書き込みができたりするので、 "insecure mode" と呼ばれます。 このセキュアレベルは、管理者または man:init[8] による起動時のスクリプトにより変更されない限り -1 のままです。 [.filename]#/etc/rc.conf# において、 `kern_securelevel_enable` を `YES` とし、 `kern_securelevel` に必要とする値を設定することで、 システム起動時にセキュアレベルを高めることができます。 これらの設定についてのより詳細な情報については、 man:security[7] および man:init[8] をご覧ください。
|
|
|
|
|
|
|
|
|
|
[[crypt]]
|
|
|
|
|
== DES, Blowfish, MD5, SHA256, SHA512 および Crypt
|
|
|
|
|
[WARNING]
|
|
|
|
|
====
|
|
|
|
|
`securelevel` を大きくしすぎると、 Xorg が動かなくなったり、他の問題が起きる可能性があります。 デバッグの心づもりをしてください。
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
UNIX(R) システムにおけるすべてのユーザは、 そのアカウントに対応した一つのパスワードを持っています。 それらのパスワードを秘密に保っておくために、 パスワードは "一方向ハッシュ" として知られる方式で暗号化されます。 一方向ハッシュとは、 簡単に暗号化はできるが解読は難しいという方法です。 オペレーティングシステム自身はパスワードを知りません。 その代わりに _暗号化された_ 形でのみパスワードを知っています。 "素のテキスト" としてパスワードを得る唯一の方法は、 可能な限りのパスワード空間を検索するという力任せの方法です。
|
|
|
|
|
つぎに変更を検討すべき man:sysctl[8] は、 net.inet.tcp.blackhole および net.inet.udp.blackhole です。 これらを設定すると、閉じたポートに対して届く SYN パケットはドロップされ、 RST レスポンスを返しません。 通常は、RST を返し、 そのポートが閉じられていることを伝えます。 これにより、システムに対する "ステルス" スキャンに対し、ある程度の防御となります。 net.inet.tcp.blackhole を "2"、 net.inet.udp.blackhole を "1" に設定してください。 詳細な情報について man:blackhole[4] をご覧ください。
|
|
|
|
|
|
|
|
|
|
元々、UNIX(R) においてパスワードを安全な形で暗号化できる方式は Data Encryption Standard (DES) に基づいたものだけでした。DES のソースコードを米国外に輸出することはできないという問題があったため、 FreeBSD は、米国の法律を守ることと、 未だに DES を使っていた他の UNIX(R) 一族との互換性を保つこととを両立する方法を探し出す必要がありました。 その解決方法は、DES よりも安全であると考えられている MD5 を使うことでした。
|
|
|
|
|
さらに、net.inet.icmp.drop_redirect および net.inet.ip.redirect も設定すべきです。 これら 2 つの man: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" に設定してください。
|
|
|
|
|
|
|
|
|
|
現在では、ライブラリは DES, MD5, Blowfish, SHA256 および SHA512 ハッシュ関数に対応しています。FreeBSD がどの暗号化方式を使うようにセットアップされているかを判断するには、 [.filename]#/etc/master.passwd# の暗号化されたパスワードを調べてください。 MD5 ハッシュで暗号化されたパスワードは、DES ハッシュで暗号化されたパスワードよりも長く、 `$1$` という文字で始まるという特徴を持っています。 `$2a$` で始まるパスワードは、Blowfish ハッシュ関数で暗号化されています。 DES のパスワードはこれといって識別可能な特徴は持っていませんが、 MD5 のパスワードよりは短く、そして `$` という文字を含まない 64 文字のアルファベットを使って表現されているので、 比較的短い文字列でドル記号で始まっていないものはおそらく DES のパスワードでしょう。 SHA256 と SHA512 の場合は、`$6$` から始まります。
|
|
|
|
|
ブロードキャストアドレスに対するすべての ICMP エコーリクエストは、ドロップしてください。 ネットワーク上のコンピュータがサブネットにあるすべてのホストにメッセージを送る必要がある場合には、 メッセージはブロードキャストアドレスに送られます。 外部のホストについては、 このような送信をする必要はないので、 外部からブロードキャストへのリクエストをすべて拒否するように、 net.inet.icmp.bmcastecho を "0" に設定してください。
|
|
|
|
|
|
|
|
|
|
新規パスワードがどちらのパスワード形式になるかは、 [.filename]#/etc/login.conf# の中の `passwd_format` ログインケーパビリティによって制御されます。 その値としては、 `des`, `md5`, `blf`, `sha256` または `sha512` を設定することができます。 ログインケーパビリティに関するより詳細な情報は、 man:login.conf[5] をご覧ください。
|
|
|
|
|
まだ多くの man:sysctl[8] が man:security[7] で説明されています。 さらに多くの情報を調べることが推奨されます。
|
|
|
|
|
|
|
|
|
|
[[one-time-passwords]]
|
|
|
|
|
== ワンタイムパスワード
|
|
|
|
|
@ -452,7 +484,6 @@ ALL : ALL \
|
|
|
|
|
|
|
|
|
|
[WARNING]
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
攻撃者や攻撃者のグループは、 これらのデーモンの接続のリクエストであふれさせることにより、 サーバに対して DoS 攻撃を仕掛けることができます。
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
@ -462,7 +493,7 @@ ALL : ALL \
|
|
|
|
|
....
|
|
|
|
|
# We do not allow connections from example.com:
|
|
|
|
|
ALL : .example.com \
|
|
|
|
|
: spawn (/bin/echo %a from %h attempted to access %d \
|
|
|
|
|
: spawn (/bin/echo %a from %h attempted to access %d >> \
|
|
|
|
|
/var/log/connections.log) \
|
|
|
|
|
: deny
|
|
|
|
|
....
|
|
|
|
|
@ -483,7 +514,6 @@ sendmail : PARANOID : deny
|
|
|
|
|
|
|
|
|
|
[CAUTION]
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
クライアントもしくはサーバの DNS の設定が間違っている場合に、 `PARANOID` ワイルドカードを使うと、 サーバがとても使いづらくなります。 管理者の慎重さが求められます。
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
@ -715,7 +745,7 @@ jdoe@example.org
|
|
|
|
|
|
|
|
|
|
* たとえば一週間といった長い有効期限のチケットを使いたい場合で、 OpenSSH を使って、 チケットが保存されているコンピュータに接続しようとする場合は、 Kerberos `TicketCleanup` が [.filename]#sshd_config# において `no` と設定されているか、 チケットが、ログアウト時に削除されることを確認してください。
|
|
|
|
|
* ホストプリンシパルは長い有効期限のチケットを持つことができます。 もし、ユーザプリンシパルが 1 週間の有効期限を持ち、 接続しているホストが、9 時間の有効期限を持っている場合には、 ユーザキャッシュは有効期限が切れたホストプリンシパルを持つことになり、 想定したように、 チケットキャッシュが振る舞わないことが起こりえます。
|
|
|
|
|
* man:kadmind[8] で説明されているような、 特定の問題のあるパスワードが使われることを避けるために [.filename]#krb5.dict# を設定する時には、 パスワードポリシが割り当てられたプリンシパルにのみ適用されることを覚えていてください。 [.filename]#krb5.dict# で使われている形式では、 一行に一つの文字列が置かれています。 [.filename]#/usr/shared/dict/words# にシンボリックリンクを作成することは、有効です。
|
|
|
|
|
* man:kadmind[8] で説明されているような、 特定の問題のあるパスワードが使われることを避けるために [.filename]#krb5.dict# を設定する時には、 パスワードポリシが割り当てられたプリンシパルにのみ適用されることを覚えていてください。 [.filename]#krb5.dict# で使われている形式では、 一行に一つの文字列が置かれています。 [.filename]#/usr/share/dict/words# にシンボリックリンクを作成することは、有効です。
|
|
|
|
|
|
|
|
|
|
=== MIT port との違いについて
|
|
|
|
|
|
|
|
|
|
@ -725,7 +755,7 @@ MIT と Heimdal 版の大きな違いは、 man:kadmin[8] に関連していま
|
|
|
|
|
|
|
|
|
|
[NOTE]
|
|
|
|
|
====
|
|
|
|
|
FreeBSD の MITpackage:security/krb5[] port において、 man:telnetd[8] および `klogind` 経由でのログインが奇妙な振る舞いをすることを理解するには、 port からインストールされる [.filename]#/usr/local/shared/doc/krb5/README.FreeBSD# を読んで下さい。 "incorrect permissions on cache file" の振る舞いを修正するには、 フォワードされたクレデンシャリングの所有権を適切に変更できるように、 `login.krb5` バイナリが認証に使われる必要があります。
|
|
|
|
|
FreeBSD の MITpackage:security/krb5[] port において、 man:telnetd[8] および `klogind` 経由でのログインが奇妙な振る舞いをすることを理解するには、 port からインストールされる [.filename]#/usr/local/share/doc/krb5/README.FreeBSD# を読んで下さい。 "incorrect permissions on cache file" の振る舞いを修正するには、 フォワードされたクレデンシャリングの所有権を適切に変更できるように、 `login.krb5` バイナリが認証に使われる必要があります。
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
[.filename]#rc.conf# を以下のように変更する必要もあります。
|
|
|
|
|
@ -765,9 +795,17 @@ kadmind5_server_enable="YES"
|
|
|
|
|
|
|
|
|
|
Kerberos は、 ユーザ、ホストおよびサービスの間での認証を可能にしますが、 KDC とユーザ、 ホストまたはサービスとの間の認証のメカニズムは提供しません。 これは、トロイの木馬の man:kinit[1] が、 すべてのユーザ名とパスワードを記録できることを意味しています。 package:security/tripwire[] のような、ファイルシステムの完全性を確認するためのツールにより、 この危険性を軽減することができます。
|
|
|
|
|
|
|
|
|
|
=== Kerberos および man:ssh[1] を用いたアクセスの問題
|
|
|
|
|
|
|
|
|
|
Kerberos と man:ssh[1] を使う場合には、 両者に関して知っておかねばならない問題がいくつかあります。 Kerberos は大変優れた認証プロトコルですが、Kerberos 化された man:telnet[1] および man:rlogin[1] には、 バイナリストリームを扱うのに不向きになるようなバグがあります。 デフォルトでは、Kerberos は `-x` を使わない限りセッションを暗号化してくれません。 一方 man:ssh[1] では、 デフォルトですべてを暗号化してくれます。
|
|
|
|
|
|
|
|
|
|
man:ssh[1] はとても良く動作しますが、 デフォルトで暗号鍵を転送してしまいます。 このため、man:ssh[1] を安全なワークステーションから、 安全でないマシンへのアクセスに使っているユーザに、 セキュリティリスクを引き起こします。 鍵そのものが見えてしまうわけではありませんが、 man:ssh[1] は login している間、転送用ポートを作ります。 攻撃者が安全でないマシンの `root` を破ったら、 このポートを使って、 この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。
|
|
|
|
|
|
|
|
|
|
可能な時はいつでも、スタッフのログインには Kerberos を組み合せた man:ssh[1] を使用することを勧めます。 man:ssh[1] は、Kerberos 対応機能と一緒にコンパイルできます。 このようにすることで、見えてしまう可能性のある SSH 鍵への依存を減らし、 一方で、Kerberos 経由によりパスワードが保護されます。 鍵は、安全なマシンからの自動化されたタスクのみに使用すべきです。 Kerberos はこの用途には不向きです。 また、SSH の設定で鍵転送をしないようにするか、 あるいは [.filename]#authorized_keys# の `from=IP/DOMAIN` を使用して、 特定のマシンからログインしてきたときのみ鍵が有効にすることをお勧めします。
|
|
|
|
|
|
|
|
|
|
=== リソースおよび他の情報源
|
|
|
|
|
|
|
|
|
|
* http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html[ The Kerberos FAQ]
|
|
|
|
|
* http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html[The Kerberos FAQ]
|
|
|
|
|
* http://web.mit.edu/Kerberos/www/dialogue.html[Designing an Authentication System: a Dialog in Four Scenes]
|
|
|
|
|
* http://www.ietf.org/rfc/rfc1510.txt?number=1510[RFC 1510, The Kerberos Network Authentication Service (V5)]
|
|
|
|
|
* http://web.mit.edu/Kerberos/www/[MIT Kerberos home page]
|
|
|
|
|
@ -929,7 +967,7 @@ IPsec は、直接二つのホスト間のトラフィックを暗号化する _
|
|
|
|
|
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
options IPSEC IP security
|
|
|
|
|
options IPSEC #IP security
|
|
|
|
|
device crypto
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
@ -937,7 +975,7 @@ IPsec のデバッグサポートが必要であれば、 以下のカーネル
|
|
|
|
|
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
options IPSEC_DEBUG debug for IP security
|
|
|
|
|
options IPSEC_DEBUG #debug for IP security
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
=== 家庭と会社間の VPN
|
|
|
|
|
@ -979,15 +1017,15 @@ VPN の構成についての標準はありません。 VPN は、数多くの
|
|
|
|
|
Gateway 1:
|
|
|
|
|
|
|
|
|
|
gif0: flags=8051 mtu 1280
|
|
|
|
|
tunnel inet 172.16.5.4 -- 192.168.1.12
|
|
|
|
|
tunnel inet 172.16.5.4 --> 192.168.1.12
|
|
|
|
|
inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6
|
|
|
|
|
inet 10.246.38.1 -- 10.0.0.5 netmask 0xffffff00
|
|
|
|
|
inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00
|
|
|
|
|
|
|
|
|
|
Gateway 2:
|
|
|
|
|
|
|
|
|
|
gif0: flags=8051 mtu 1280
|
|
|
|
|
tunnel inet 192.168.1.12 -- 172.16.5.4
|
|
|
|
|
inet 10.0.0.5 -- 10.246.38.1 netmask 0xffffff00
|
|
|
|
|
tunnel inet 192.168.1.12 --> 172.16.5.4
|
|
|
|
|
inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00
|
|
|
|
|
inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
@ -1162,11 +1200,11 @@ Foreground mode.
|
|
|
|
|
2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon
|
|
|
|
|
n2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a
|
|
|
|
|
2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
|
|
|
|
|
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]-172.16.5.4[0] spi=28496098(0x1b2d0e2)
|
|
|
|
|
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]-192.168.1.12[0] spi=47784998(0x2d92426)
|
|
|
|
|
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2)
|
|
|
|
|
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426)
|
|
|
|
|
2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
|
|
|
|
|
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]-172.16.5.4[0] spi=124397467(0x76a279b)
|
|
|
|
|
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]-192.168.1.12[0] spi=175852902(0xa7b4d66)
|
|
|
|
|
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b)
|
|
|
|
|
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66)
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
トンネリングが適切に行われているかどうかを確認するため、 別のコンソール上で man:tcpdump[1] を使い、 以下のようなコマンドでネットワークの通信を確認してください。 ただし、以下の例の `em0` の部分は、 必要に応じて使用しているネットワークインタフェースに置き換えてください。
|
|
|
|
|
@ -1180,9 +1218,9 @@ n2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[5
|
|
|
|
|
|
|
|
|
|
[.programlisting]
|
|
|
|
|
....
|
|
|
|
|
01:47:32.021683 IP corporatenetwork.com 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa)
|
|
|
|
|
01:47:33.022442 IP corporatenetwork.com 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb)
|
|
|
|
|
01:47:34.024218 IP corporatenetwork.com 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc)
|
|
|
|
|
01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa)
|
|
|
|
|
01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb)
|
|
|
|
|
01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc)
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
これで 2 つのネットワークは、 1 つのネットワークのように利用できます。 多くの場合、 両方のネットワークはファイアウォールにより保護されています。 両方を流れる通信を許可するには、 パケットが両方を行き来できるようにルールを追加する必要があります。 man:ipfw[8] を使ったファイアウォールの場合は、 ファイアウォールの設定ファイルに、以下の行を追加してください。
|
|
|
|
|
@ -1285,7 +1323,7 @@ COPYRIGHT 100% |*****************************| 4735
|
|
|
|
|
|
|
|
|
|
前回の例でこのホストの指紋がすでに保存されていれば この man:scp[1] を使う時に検証が行なわれます。
|
|
|
|
|
|
|
|
|
|
man:scp[1] に渡される引数は、man:cp[1] のものと似ており、コピーするファイル (1 つまたは複数) が 1 つめの引数になり、コピー先が 2 つめの引数になります。 ファイルはネットワーク越しに SSH 接続を通して送られるので、 引数に指定するファイルに `user@host:path_to_remote_file` という形式をとるものがあります。
|
|
|
|
|
man:scp[1] に渡される引数は、man:cp[1] のものと似ており、コピーするファイル (1 つまたは複数) が 1 つめの引数になり、コピー先が 2 つめの引数になります。 ファイルはネットワーク越しに SSH 接続を通して送られるので、 引数に指定するファイルに `user@host:<path_to_remote_file>` という形式をとるものがあります。
|
|
|
|
|
|
|
|
|
|
=== 設定
|
|
|
|
|
|
|
|
|
|
@ -1318,7 +1356,6 @@ man:ssh-keygen[1] は認証に使う為の公開鍵と秘密鍵のペアを作
|
|
|
|
|
|
|
|
|
|
[WARNING]
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
多くのユーザは、鍵が設計上安全と信じ、 パスフレーズなしに鍵を利用しています。 このような使用方法は _危険_ です。 管理者が鍵にパスフレーズが設定されているかを確認する方法は、 手動で鍵を調べる方法です。 秘密鍵のファイルに `ENCRYPTED` という単語が含まれている場合には、 鍵の所有者は、パスフレーズを使用しています。 弱いパスフレーズが使われている間、 少なくともシステムが危険にさらされているときには、 他のサイトへのアクセスには、 あるレベルでのパスワード類推が必要となります。 さらに、公開鍵ファイルに `from` を含めることで、 エンドユーザをより安全にできます。 たとえば、 `ssh-rsa` または `rsa-dsa` の前に、 `from="192.168.10.5` を加えることで、 この IP を持つホストからのユーザのみがアクセスできるようになります。
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
@ -1326,7 +1363,6 @@ man:ssh-keygen[1] でパスフレーズを使っている場合は、 秘密鍵
|
|
|
|
|
|
|
|
|
|
[WARNING]
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
OpenSSH のバージョンによって、 オプションやファイルに違いが出てくることがあります。 man:ssh-keygen[1] を参照して、 問題が起こることを避けてください。
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
@ -1567,7 +1603,7 @@ Ports Collection から portaudit をインストールするには、以下の
|
|
|
|
|
|
|
|
|
|
[source,bash]
|
|
|
|
|
....
|
|
|
|
|
# cd /usr/ports/ports-mgmt/portaudit make install clean
|
|
|
|
|
# cd /usr/ports/ports-mgmt/portaudit && make install clean
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
インストールの途中で、 man:periodic[8] の設定ファイルはアップデートされ、 毎日のセキュリティに関するスクリプトの実行中に portaudit が出力するように設定されます。 毎日のセキュリティに関するスクリプトの実行結果のメールが読めることを確認してください。 このメールは、`root` アカウントに送られます。 他の設定は必要ありません。
|
|
|
|
|
@ -1597,7 +1633,7 @@ portaudit は、インストールされている package の中で、 脆弱性
|
|
|
|
|
....
|
|
|
|
|
Affected package: cups-base-1.1.22.0_1
|
|
|
|
|
Type of problem: cups-base -- HPGL buffer overflow vulnerability.
|
|
|
|
|
Reference: http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html
|
|
|
|
|
Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html>
|
|
|
|
|
|
|
|
|
|
1 problem(s) in your installed packages found.
|
|
|
|
|
|
|
|
|
|
@ -1645,51 +1681,43 @@ CVE Name: CVE-XXXX-XXXX <.>
|
|
|
|
|
For general information regarding FreeBSD Security Advisories,
|
|
|
|
|
including descriptions of the fields above, security branches, and the
|
|
|
|
|
following sections, please visit
|
|
|
|
|
http://www.FreeBSD.org/security/<.>
|
|
|
|
|
http://www.FreeBSD.org/security/.
|
|
|
|
|
|
|
|
|
|
I. Background <.>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
II. Problem Description <.>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
III. Impact <.>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
IV. Workaround <.>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
V. Solution <.>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VI. Correction details <.>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VII. References <.>
|
|
|
|
|
....
|
|
|
|
|
|
|
|
|
|
<.> `Topic` フィールドでは、 問題について明記されています。 セキュリティ勧告の導入部であり、 脆弱性に影響されるユーティリティを示します。
|
|
|
|
|
|
|
|
|
|
<.> `Category` フィールドでは、 脆弱性がシステムのどの部分に影響するかを示します。 `core`, `contrib` または `ports` のどれかが示されます。 `core` カテゴリは、 FreeBSD オペレーティングシステムの `core` コンポーネントに影響する脆弱性であることを意味します。 `contrib` カテゴリは、 Sendmail のように、FreeBSD の外で開発され、FreeBSD プロジェクトに取り込まれたソフトウェアに影響する脆弱性であることを意味します。 `ports` カテゴリは、Ports Collection からインストールされるソフトウェアに影響する脆弱性であることを示しています。
|
|
|
|
|
|
|
|
|
|
<.> `Module` フィールドは、 影響するコンポーネントについて言及します。 この例では、`sys` モジュールに影響することがわかります。 そのため、この脆弱性は、 カーネルの中で使われるコンポーネントに影響します。
|
|
|
|
|
|
|
|
|
|
<.> `Announced` フィールドは、 セキュリティ勧告が発行された日、 またはアナウンスされた日が記載されています。 セキュリティチームによりこの問題が存在することが確認され、 パッチが FreeBSD ソースコードリポジトリにコミットされたことを意味します。
|
|
|
|
|
|
|
|
|
|
<.> `Credits` フィールドは、 脆弱性を通知し、報告した個人または組織を示します。
|
|
|
|
|
|
|
|
|
|
<.> `Affects` フィールドは、この脆弱性がどの FreeBSD リリースに影響するかを説明します。 カーネルでは、影響するファイルに対して man:ident[1] を実行すると、 その出力からリビジョンを簡単に確認できます。 ports の場合には、 [.filename]#/var/db/pkg# の port の名前の後に、バージョン番号が示されています。 もし、システムが FreeBSD Subversion リポジトリと同期していなかったり、 再構築が毎日行われているような状況でなければ、 おそらく、そのシステムには影響しているでしょう。
|
|
|
|
|
|
|
|
|
|
<.> `Corrected` フィールドは、 脆弱性が修正された日、時間、 タイムゾーン、およびリリースが示されます。
|
|
|
|
|
|
|
|
|
|
<.> link:http://cve.mitre.org[Common Vulnerabilities and Exposures] データベースにおいて、 脆弱性を探すために使用できる識別情報を示します。
|
|
|
|
|
|
|
|
|
|
<.> http://cve.mitre.org[Common Vulnerabilities and Exposures] データベースにおいて、 脆弱性を探すために使用できる識別情報を示します。
|
|
|
|
|
<.> `Background` フィールドは、 影響しているユーティリティに関する情報を示します。 大体の場合は、なぜユーティリティが FreeBSD に存在するか、 何のために使われているか、 どのように用いられるようになってきたか、 といった情報が示されます。
|
|
|
|
|
|
|
|
|
|
<.> `Problem Description` フィールドは、 より深くセキュリティホールについて説明します。 問題のあるコードの情報や、 このユーティリティが悪意のある使い方により、 どのようにセキュリティホールを開けうるかといったことが示されます。
|
|
|
|
|
|
|
|
|
|
<.> `Impact` フィールドは、 この問題がシステムに対して、 どのような形式の影響を与えるかについて示します。 たとえば、DoS 攻撃によるものか、 ユーザに対して意図しない特権を持たせてしまうものか、 または、攻撃者にスーパユーザのアクセスを与えるようなものか、 といったことが示されます。
|
|
|
|
|
|
|
|
|
|
<.> `Workaround` フィールドは、 時間による制限や、ネットワークの可用性または他の理由により、 システムをアップグレードできないシステム管理者に対して、 回避方法を提供します。 セキュリティを甘く見るべきではなく、 影響するシステムにはパッチを当てるか、 セキュリティホールの回避方法を実行すべきです。
|
|
|
|
|
|
|
|
|
|
<.> `Solution` フィールドは、 影響のあるシステムにパッチを当てる手順を提供します。 ここではステップごとにシステムにパッチを当て、 安全に動作するように、 試験され検証された方法が記載されます。
|
|
|
|
|
|
|
|
|
|
<.> `Correction Details` フィールドは、 Subversion ブランチまたはリリース名のピリオドをアンダースコアに置き換えたものを示します。 ここでは、 各ブランチにおいて影響するファイルのリビジョン番号も示します。
|
|
|
|
|
|
|
|
|
|
<.> `References` フィールドは、 通常、ウェブページの URL, books, メーリングリストおよびニュースグループといった、 ほかの情報へのソースを提供します。
|
|
|
|
|
|
|
|
|
|
[[security-accounting]]
|
|
|
|
|
|
Sergio Carlavilla Delgado
3 years ago