diff --git a/ja/security/security.sgml b/ja/security/security.sgml
index c1c6707e25..139e4db13a 100644
--- a/ja/security/security.sgml
+++ b/ja/security/security.sgml
@@ -1,818 +1,820 @@
-
+
%includes;
]>
-
+
-
+
&header;
はじめに
このページは、FreeBSD のセキュリティに関して、
初心者、ベテランを問わず手助けになるよう書かれています。
FreeBSD では、セキュリティを非常に重要なものと捉えており、
OS をできる限りセキュアなものにしようと常に努力しています。
ここではどのようにしてさまざまな攻撃からあなたのシステムを守るか、
またセキュリティに関わるバグを発見した場合に誰に連絡すれば良いのか、
などについて、多くの情報や情報へのリンクを掲載しています。
また、システムプログラマ向けに、セキュリティ上の弱点を作成しないようにするための
さまざまな手法を紹介する項も含まれています。
目次
FreeBSD セキュリティオフィサチーム
セキュリティに関して取り組んでいる人たちとの情報交換を円滑にするため、
FreeBSD ではセキュリティ関係の窓口として
セキュリティオフィサチーム
を設けています。
セキュリティオフィサチームは、
実際にはセキュリティを専門とする複数のセキュリティオフィサにより構成されており、
FreeBSD の既知のセキュリティホールや、
潜在的なセキュリティ問題に関して勧告を広報することが主な役割となります。
もしセキュリティに関するバグの可能性について FreeBSD の誰かに連絡をとる必要が生じたら、
発見したことの詳細と、何が問題となっているのかを書いて
セキュリティオフィサチームに
メールを送ってください。
また、セキュリティオフィサチームは世界各国の
CERT
(訳注: 日本では JPCERT/CC)
や FIRST チームと
連絡を取り合い、FreeBSD 本体や FreeBSD でよく使われる
ユーティリティのセキュリティ上の弱点に関する情報交換を行っています。
セキュリティオフィサは、これらの団体における活発なメンバでもあります。
気がかりな問題があってセキュリティオフィサチームと連絡を取る必要がある場合は、
あなたからのメッセージを暗号化するために、セキュリティオフィサチームの
PGP 公開鍵
を使用して下さい。
FreeBSD のセキュリティ勧告
FreeBSD セキュリティオフィサチームは、以下の
FreeBSD リリースに対して、
セキュリティ勧告を提供しています:
- FreeBSD の最新の公式リリース
- FreeBSD-stable (このブランチから 2 つ以上リリースされている場合)
- 以前の FreeBSD-stable (最新の stable ブランチからのリリース
がまだ 2 つに満たない場合)
セキュリティ勧告は現時点で、以下のリリースをサポートしています:
- FreeBSD 4.4-RELEASE
- FreeBSD 4.5-RELEASE
- FreeBSD 4.5-STABLE
これ以前の古いリリースについては、
積極的にメンテナンスされることはありませんので、
上記のサポートされているのいずれかへのアップグレードを強く推奨します。
セキュリティに関する修正は FreeBSD の開発と同様に、まず
FreeBSD-current
ブランチに導入されます。
そして数日間のテストを経て、わたしたちのカバーしている
FreeBSD-stable ブランチに対応するように修正内容が持ち込まれ、
勧告が公表されることになります。
2000 年に発行された勧告に関する統計情報:
- ベースシステム (FreeBSD の標準的なインストール構成) および、
オプションとして Ports Collection
に含まれるサードパーティ製アプリケーションに関するものをあわせて、
全部で 81 の勧告が公開されました。
- ベースシステムに関するセキュリティ勧告は、
(さまざまな緊急度のものが) 全部で 24 発行されました。
残りの 57 勧告はオプションとして Ports Collection
に含まれるサードパーティ製アプリケーションに関するものです。
- 19 のセキュリティ上の弱点 (そのうちベースシステムに関するものが 8、
ports に関するものが 11) は、FreeBSD の監査チームが内部で行なった、
ソースコードのセキュリティ監査で発見されたものです。
- FreeBSD のみが影響を受けるセキュリティ上の弱点を述べた勧告は、
全部で 9 勧告 (そのうち、
ベースシステムに関するものが 6、ports に関するものが 3) でした。
残りの 72 勧告は、他の少なくとも一つ以上の OS も影響を受けるものです。
これの原因の多くは、ソースコードを共有していることによるものでした。
セキュリティ勧告は、以下の FreeBSD
メーリングリストを通じて公表されます。
- FreeBSD-security-notifications@FreeBSD.org
- FreeBSD-security@FreeBSD.org
- FreeBSD-announce@FreeBSD.org (訳注: この内容は
announce-jp@jp.FreeBSD.org にも配送されます)
勧告は、常に FreeBSD セキュリティオフィサの
PGP 鍵
で署名され、
FTP CERT リポジトリ
に関連パッチとともにアーカイブされます。
これ (訳注: 原文のこと) を書いている時点では、以下の勧告が公開されています
(このリストは数日ほど情報が古い場合があります。
最新の勧告は
FTP サイト をチェックしてください):
訳注:いくつかのセキュリティ勧告には、FreeBSD
日本語ドキュメンテーションプロジェクト(doc-jp)による日本語版が存在します。
この翻訳は以下のリンクから読むことができますが、
announce-jp@jp.FreeBSD.org にも配送されます。
ただし、これらは doc-jp が参考のために提供するもので、
翻訳者および doc-jp は、その内容についていかなる保証もいたしません。
日本語訳についてのお問い合わせは、
doc-jp@jp.FreeBSD.org
までお願いします。この日本語訳は PGP 署名されていませんので、
パッチ等の内容が改竄されていないことを確認するために PGP
のチェックを行なう場合には、原文を参照するようにお願いします。
FreeBSD 4.5-RELEASE released.
FreeBSD 4.4-RELEASE released.
FreeBSD 4.3-RELEASE released.
FreeBSD のセキュリティメーリングリストについて
もしいくつかの FreeBSD システムを管理/利用しているのなら、
以下のメーリングリストのうち少なくとも一つに参加するべきです:
freebsd-security セキュリティ一般に関する議論
freebsd-security-notifications セキュリティ告知 (モデレートメーリングリスト)
参加するには、メッセージの本文の部分に
subscribe <リスト名> [<メールアドレス (オプション)>]
と書かれたメールを
majordomo@FreeBSD.ORG
宛てに送って下さい。
例えば、
% echo "subscribe freebsd-security" | mail majordomo@FreeBSD.org
とします。もしメーリングリストから脱退したい場合は、
% echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org
とします。
安全なプログラミングのためのガイドライン
- いかなる場合も入力の源 (source of input) を信用しないでください。
例えばコマンドライン引数、環境変数、設定ファイル、入ってくる TCP/UDP/ICMP
パケット、ホスト名の lookup、関数の引数などです。
もし受け取ったデータの長さ、内容が自分の制御下にないなら、
内容をコピーするプログラム、関数は十分に注意しなければなりません。
特に注意しなければならないのは以下のようなことです:
- 境界のわからないデータによる strcpy() や sprintf() の呼び出し。
長さが分かっている場合には strncpy や snprintf() を使います。
(長さが分からない場合には何らかの境界チェックを実装します。)
要するに、gets() や sprintf() は決して使ってはいけない、ということです、以上。
もし使ったとしたら、邪悪な小人があなたの後ろから忍び寄ることでしょう。
- もし特定の文字を禁止したユーザの入力を必要とした場合には、
決してそれらの禁止した文字をチェックしてはいけません。
代りに、あなたが許可した文字でのみ構成されているかどうかを
チェックします。 基本的には、明示的に許可したもの以外は
すべて禁止する、とします。
- strncpy() と strncat() のマニュアルページを良く読むこと。
これらがどのように働くのか良く理解してください!!!
strncpy() が末端の \0 を付け加えないかもしれないのに対して、
strncat() は \0 を付け加えます。
- strvis() と getenv() の誤用に注意する。
strvis() では、コピー先の文字列を簡単に駄目にしてしまいます。
getenv() はプログラムが予想する長さよりも長い文字列を返すことがあります。
これらの二つの関数は、プログラムへの攻撃に際し鍵となる手法のひとつで、
環境変数に予想外の値を設定しスタックや変数を上書きします。
もしあなたのプログラムが環境変数を読み込むなら、偏執症になってください。
しつこいくらいの偏執症に。
- open() や stat() を使うときは、毎回自問自答してください:
「これがシンボリックリンクだったらどうなる？」
- mktemp()、tempnam() などの代りに mkstemp() を使うようにする。
一般的に /tmp で起こる競合に注意することはもちろんのこと、
めったに起こらない状況にも注意を払ってください:
- ディレクトリを作成する。 これは成功も失敗も有り得る。
- O_CREAT | O_EXCL でファイルをオープンする
mkstemp() を使った場合、これらのケースもうまく面倒を見てくれます。
よってすべての一時的なファイルは、競合条件を排除し、
パーミッションが適切かどうかを保証するために mkstemp() を使うべきです。
- 攻撃者が他の任意のシステムへ/からパケットを送る/受け取ることができる
場合、攻撃者は私たちが受け取るデータを完全に制御できるようになり、
一切のデータは信用できなくなります。
- 設定ファイルが正しい書式で書かれているとか、適切なユーティリティで出
力されていることを仮定してはいけません。
ユーザが指定する端末名や言語指定文字列など、パス名に使う可能性のあるものでは、
'/' や '../../../' などの文字列が含まれる可能性を考慮する必要があります。
setuid root で動くプログラムの場合には、ユーザにより指定されたパスを
絶対に信用してはいけません。
- データが格納される方法にセキュリティホール/弱点がないかどうか
探してください。
詮索好きな眼から保護するために、すべての一時ファイルのパーミッション
は 600 にするべきです。
- 特権で動作するプログラムは、ありきたりの問題を grep するだけ
ではいけません。
strcpy() やその類似関数の誤用による、バッファオーバーフローを
引き起こす方法は数多く存在するので、
そのようなプログラムではすべての行でオーバーフローの可能性を
探ってください。
- ある個所で特権を放棄したからといって、それで exploit が
なくなるというわけではありません。
攻撃者は、あとで /bin/sh を実行する際に再び特権が得られるように、
スタックに必要なコードを置いておくかもしれません。
- uid で管理しましょう。
できる限り早く特権を放棄しましょう(しかも完全に)。
euid と uid を入れ替えるだけでは十分ではありません。
可能なら setuid() を使いましょう。
- エラーが発生しても設定ファイルを表示しないようにします。
行番号と行内での位置が分かれば十分です。
これはすべてのライブラリ、suid/sgid プログラムに当てはまります。
- 既存のコードのセキュリティ上の問題を発見するために、
コードを見直すときには以下の点に注意します:
- 自分のセキュリティ上の修正に自信がない場合には、
あらかじめ同意を得ているレビュアーに送って、あなたのコードを
見直してもらってください。
セキュリティ上の修正と銘打って何かを壊してしまうと、
とても恥ずかしい思いをすることになりますので、
良く理解していないコードを commit しないでください。
- あなたが commit 権限を持っていない場合、
権限を持ったレビュアーは、その変更をチェックする最後の人間となります。
その人がチェックと、最終バージョンをソースツリーに取り入れる作業の
両方を行うことになります。
- レビュー用に変更点を送る際には、context diff もしくは unified diff
を用いるようにします。
この diff は patch(1) に簡単に適用できます。
単純にファイル全体を送るようなことはしないでください。
diff の出力は読みやすく、
(複数の変更が同時に加えられたような場合でも)
手元のソースに簡単に適用できます。
すべての変更は -current ブランチに対して行うようにします。
- レビュアーに変更点を送付する前に、必ず自分でその変更をテストするよう
にします(関連するソースをビルドして実行する、など)。
明らかに壊れているものをレビューしたがる人はいません。
そのようなものは提出者が自分が何をしたかをよく確認していない、
ということをはっきりさせるにすぎません。
(そんなことでは信頼を得られませんね)。
もし特定のバージョンのものが入っているマシンのアカウントが必要なら、
そう尋ねてください。
プロジェクトはそのような目的のためのリソースを用意しています。
- コミッターへの注意: -current へのパッチを -stable ブランチに
適切に適用することを忘れないでください。
- あなたのスタイルに合うようにコードを書き直す必要はありません。
そんなことはレビュアーの仕事をより困難にするだけです。
明白な理由がない限りそのようなことはしないでください。
- シグナルハンドラの内部で複雑なことをしているプログラムを
探してください。
ライブラリ内の多くのコードは、このようなことを安全に行えるほど
再入可能ではありません。
- realloc() の使い方には特別な注意を払ってください。
多くの場合、この関数は正しく使われていません。
- 固定サイズのバッファを使うときには、バッファのサイズが変わっても
コードの部分が変更されないということが無いように、sizeof() を
使うようにしてください。 たとえば:
char buf[1024];
struct foo { ...};
...
BAD:
xxx(buf, 1024)
xxx(yyy, sizeof(struct foo))
GOOD:
xxx(buf, sizeof(buf))
xxx(yyy, sizeof(yyy))
ポインタが指しているもののサイズを知りたいときに、
ポインタの sizeof をとったりしないよう注意してください。
- "char foo[###]" のようなものを見たときには、
すべての foo の使い方が正しいかどうかを調べて、
オーバーフローする可能性がないかどうかをチェックしてください。
オーバーフローが避けられない場合には、
すくなくともバッファを malloc して、スタック上を動き回ることが
できないようにしてください。
- ファイル識別子はできる限り早く close してください。
ライブラリルーチンでは、ファイル識別子は常に “使ったら close”
するようにしてください。
有用なツールとして its4 の ports が /usr/ports/security/its4/ に
あります。 これは自動化された C のコードの検査ツールで、コード中で
潜在的な問題点をハイライト表示します。 これは最初のチェックには
便利ですが盲信して頼りすぎてはいけません。 完全な監査は
コード全体を人の目で確かめることが必要です。
確実なプログラミングテクニックとリソースに関する更なる情報は、
リソースセンターの
How to Write Secure Code
を見てください。
FreeBSD セキュリティ Tips and Tricks
FreeBSD システム (実際にはどの Unix システムでも) を
セキュアにするにはいくつかのステップがあります:
- 潜在的に危険なソフトウェアを無効にする
多くのソフトウェアは特定のリソースを使うために、
set-uid として実行可能にすることによって
特権ユーザとして実行されなければなりません。
たとえば UUCP や PPP はシリアルポートを使うために、
sendmail はメールスプールに書き込むために、
bind は特権ポートを使うために、特権ユーザとして実行されます。
UUCP を使わない場合には、
システムにソフトウェアがあっても役にたちません。
また、無効にしている方が得策といえます。
もちろん、これを行うには、将来的にその機能が必要かの見極めと、
必要なものと不要なものを分別する知識が必要です。
swapinfo のように、セキュリティ上の危険性を高める可能性はあるが、
それほど有用ではないユーティリティに気がつくかと思います。
('chmod ug-s ファイル名' コマンドを使い)
プログラムの set-uid ビットを外しても、root の時は swapinfo を常に
使い続けることができます。
しかし、多くの s ビットを外すために、常時 root になっている、という
ことはあまりよいことではありません。
不要なプログラムを削除するだけではなく、提供しないサービスも
取り除きます。
/etc/inetd.conf や /etc/rc.conf ファイルを編集し、
不要なサービスをすべて停止することで取り除くことができます。
- セキュリティ上のバグがあるソフトウェアを修正するには
(または、クラッカーの一歩先を行くには)
まずは、様々な FreeBSD Security メーリングリスト
を購読して下さい。バグの最新情報や修正を入手することができます。
修正は、すぐに当てるようにして下さい。
- バックアップ - セキュリティ侵害が起こった場合は、
システムを修復して下さい。
常時バックアップを取り、書き換えられていないことが確実な OS
(例として、CD-Rom) を準備しておきましょう。
攻撃者によって変造されたり書き換えられたデータがバックアップに
含まないようにしてください。
- システムの状態を監視するソフトウェアのインストール
(packages や ports にある) tcp wrappers や tripwire のようなプログラムを
用いて、システムを監視することができます。
このようなプログラムは、
侵入者を検知するのに役立ちます。また、毎日 root アカウントへ送られて
くる /etc/security スクリプトの出力に目を通すようにして下さい。
- システムに携わる人の育成
ユーザーは、自分が何をしているのか
を理解しなくてはいけません。
自分のパスワードを他人に渡したり、簡単に推測できるパスワード
の使用を避けることを教えます。システム/ネットワークの
セキュリティは、ユーザー自身の手の中にあることを理解すれば
いいのです。
システムのセキュリティを強化する方法の tips の応用編に
ついては、以下の FreeBSD Security How-To サイトをご利用下さい。
http://www.FreeBSD.org/~jkb/howto.html
セキュリティとは、継続です。
セキュリティに関する、最新の開発状況を常に把握するようにしてください。
セキュリティ上の問題を見つけてしまった時にすべきこと:
- セキュリティ侵害のレベルを決める
攻撃者はどのような特権を得たのか? root 特権を得たのか、それともユー
ザーレベルのアクセス権を得ただけなのか?
- システム (カーネルや userland) の状態が変更されていないか判断する
どのソフトウェアが変更されたのか? 新しいカーネルはインストール
されたのか? (telnetd、login のような) システムバイナリは編集されたのか?
OS にたいして変更された疑いがある場合は、安全なメディアから OS の
再インストールを行います。
- 不正侵入の手口を見つける
よく知られているセキュリティバグを通じて侵入はなされたのか?
そうであれば、正しいパッチを当てて下さい。
設定ミスによって侵入がなされたのか?
侵入は新しいバグによるものなのか?
もしそれが新しいバグによるものと思われる場合、
FreeBSD Security Officer までご連絡ください。
- セキュリティホールを修正する
問題を解決するために、新しいソフトウェアをインストールするか、
古いソフトウェアにパッチを当てます。危険にさらされたアカウント全てを
を無効にします。
- その他の情報源
CERTにも、
システムに侵入された際に取るべき手順について
詳細が
載っています。
その他の関連するセキュリティ情報
&footer;