Merge from the English version.

1.5 -> 1.12	security/security.sgml

Submitted by:	kuriyama, Ako Umatani <uh7a-umtn@asahi-net.or.jp>
Reviewed by:	Yasushi Kimura <kimuyasu@remus.dti.ne.jp>, kuriyama,
		Shun SUZUKI <si006@ccm.gs.niigata-u.ac.jp>
This commit is contained in:
Jun Kuriyama 1999-11-23 04:57:33 +00:00
parent 7fd749b0ed
commit 7b83d5ec29
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/www/; revision=6100

View file

@ -1,94 +1,113 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD$">
<!ENTITY title "FreeBSD Security Guide">
<!ENTITY title "FreeBSD Security Information">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
<!-- $FreeBSD$ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.5 -->
<!-- Original revision: 1.12 -->
<html>
&header;
<P>このガイドは多くの FreeBSD セキュリティの達人がシステムを安全にしたり
安全なコードを書くために使っている Tips や Tricks をドキュメント化しようと
したものです. 外部の攻撃から FreeBSD システムを守るための数多くの方法と,
もしそういった攻撃が行われた時にいかに復旧すればいいのかということを学ぶ
ための手助けとなるようにデザインされています. また, システムプログラマが
よりセキュリティを意識し, セキュリティホールを作ってしまうようなことを初期
段階で防ぐための方法も載せてあります.</P>
<H2>はじめに</H2>
<P>このページについてのコメントや訂正の指摘はいつでも歓迎しています. もし
ここに載せたい変更がある時は, <a href="mailto:security-officer@freebsd.org">
FreeBSD セキュリティ担当者</a> までメールを送って下さい.</P>
<P>この web ページは, FreeBSD オペレーティングシステムのセキュリティ
に関して, 初心者, ベテランを問わず手助けになるよう書かれています.
FreeBSD の開発チームは, セキュリティに非常に気を使っており,
OS をできる限り安全なものにしようと常に努力しています.</P>
<P>ここではどのようにして様々な外部からの攻撃からあなたの
システムを守るか, またセキュリティに関わるバグを発見した場合に
誰に連絡すれば良いのか, などについて, 多くの情報や情報への
リンクを掲載しています.</P>
<H2>目次</H2>
<UL>
<LI><A HREF="#sec">FreeBSD セキュリティ担当者について</A></LI>
<LI><A HREF="#adv">FreeBSD のセキュリティ勧告</A></LI>
<LI><A HREF="#ml">FreeBSD セキュリティメーリングリストについて</A></LI>
<LI><A HREF="#tat">FreeBSD セキュリティの Tips and Tricks</A></LI>
<LI><A HREF="#spg">安全なプログラミングのためのガイドライン</A></LI>
<LI><A HREF="#misc">その他の関連するセキュリティ情報</A></LI>
</UL>
<A NAME=sec></A>
<H2>FreeBSD セキュリティ担当者</H2>
<P>FreeBSD はセキュリティを深刻なものと受け止めているため, セキュリティに
関する情報交換のための窓口となるセキュリティ担当者を設けています. この
セキュリティ担当者の主な役割は, FreeBSD ユーザのかかえるシステムを安全に
保つために, 既知のセキュリティホールが発見された時に勧告を広報することと
ともに, セキュリティ問題を安全なものに保つことでです.
することです.
また, セキュリティ担当者は世界各国の <A HREF="http://www.cert.org/">CERT</A>
(訳注: 日本では <A HREF="http://www.jpcert.or.jp/">JPCERT/CC</a>) や
<A HREF="http://www.first.org/">FIRST</A> チームと連絡を取り合い, FreeBSD や
FreeBSD でよく使われるユーティリティのセキュリティ上の弱点に関する情報交換を
行ない, 広大な世界中のセキュリティに関する最新の情報の入手に努めます.
<P>セキュリティに関して取り組んでいる人たちとの情報交換を
円滑にするため, FreeBSD はセキュリティ関係の窓口として
<a href="mailto:security-officer@freebsd.org">セキュリティ担当者</a>
を設けています.
このセキュリティ担当者は実際には複数の人物により構成されており,
FreeBSD の既知のセキュリティホールや,
潜在的なセキュリティ問題に関して勧告を広報することが主な
役割となります.</P>
<P>もしセキュリティに関するバグの可能性について
FreeBSD チームのだれかに連絡とをる必要が生じたなら,
あなたが発見したことの詳細と, 何が問題となっているのかを書いて
<A HREF="mailto:security-officer@FreeBSD.org">セキュリティ担当者に
メールを送ってください</A>.
また, セキュリティ担当者は世界各国の
<A HREF="http://www.cert.org">CERT</A>
(訳注: 日本では <A HREF="http://www.jpcert.or.jp/">JPCERT/CC</a>)
や <A HREF="http://www.first.org/">FIRST</A> チームと
連絡を取り合い, FreeBSD 本体や FreeBSD でよく使われる
ユーティリティのセキュリティ上の弱点に関する情報交換を行っています.
セキュリティ担当者は, これらの団体における活発なメンバでもあります.</P>
<P>気がかりな問題があってセキュリティ担当者と連絡を取る必要がある場合は,
あなたからのメッセージを暗号化するために, セキュリティ担当者の
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP key</A>
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP 公開鍵</A>
を使用して下さい.</P>
<H2>FreeBSD のセキュリティ勧告:</H2>
<A NAME=adv></A>
<H2>FreeBSD のセキュリティ勧告</H2>
<P>FreeBSD はセキュリティ勧告を提供しています. この勧告は, 以下のような
いくつかある FreeBSD の最新のリリースをカバーしています.</P>
<P>FreeBSD セキュリティ担当者は, FreeBSD の以下のリリースに対して
セキュリティ勧告を提供しています:</P>
<UL>
<LI> FreeBSD の最新の公式リリース
<LI> FreeBSD-current
<LI> FreeBSD-stable (最新のリリース系統が 2 つ以上リリースされている場合)
<LI> 以前のリリース系統での FreeBSD-stable (``最新 stable''のリリース
系統がまだ 2 つリリースされていない場合)
<LI> FreeBSD-stable (このブランチから 2 つ以上リリースされている場合)
<LI> 以前の FreeBSD-stable (最新の stable ブランチからのリリース
がまだ 2 つに満たない場合)
</UL>
現時点では, セキュリティ勧告は以下のリリースをサポートしています:
<UL>
<LI> FreeBSD 2.2.6
<LI> FreeBSD 2.2.8
<LI> FreeBSD 3.1
<LI> FreeBSD 3.2
<LI> FreeBSD-current
<LI> FreeBSD-stable
</UL>
<P>これ以前の古いリリースについては, 積極的にメンテナンスされることは
ありませんので, サポートされているリリースいずれかへのアップグレードを
ありませんので, 上記のサポートされているのいずれかへのアップグレードを
強く推奨します.</P>
<P>セキュリティホールが活発に悪用されている (との連絡がエンドユーザから,
もしくは CERT のような団体から寄せられている) 場合, あるいはセキュリティ
ホールが (例えば, 一般的なメーリングリスト宛てに送られるなどの理由で)
周知のものとなった場合に, 勧告が公表されることとなります.</P>
<P>全ての開発の努力と同様に, セキュリティフィックスはまず
<P>全ての開発の努力と同様に, セキュリティに関する修正はまず
<A HREF="../handbook/current.html">FreeBSD-current</A>
ブランチに持ち込まれます. 数日間のテストを経て, 我々のカバーしている
ブランチに導入されます. 数日間のテストを経て, 我々のカバーしている
FreeBSD-stable ブランチに対応するように, 修正内容が持ち込まれ, 勧告が公表
されることになります.</P>
<P>勧告は, 以下の FreeBSD メーリングリストを通じて公表されます.
<UL>
<LI> FreeBSD-security-notifications@freebsd.org
<LI> FreeBSD-security@freebsd.org
<LI> FreeBSD-announce@freebsd.org (訳注: この内容は
<LI>FreeBSD-security-notifications@freebsd.org
<LI>FreeBSD-security@freebsd.org
<LI>FreeBSD-announce@freebsd.org (訳注: この内容は
announce-jp@jp.freebsd.org にも配送されます)
</UL>
<P>勧告は, 常に FreeBSD セキュリティ担当者の
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc">PGP 鍵</A>
で署名された後,
で署名され,
<A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/index.html">FTP CERT リポジトリ</A>
に関連パッチとともにアーカイブされます. これ (訳注: 原文のこと) を書いている
時点では, 以下の勧告が公開されています.</P>
@ -123,12 +142,15 @@ FreeBSD-stable
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:04.mmap.asc">FreeBSD-SA-98:04.mmap.asc</A></LI>
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:05.nfs.asc">FreeBSD-SA-98:05.nfs.asc</A></LI>
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:06.icmp.asc">FreeBSD-SA-98:06.icmp.asc</A></LI>
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:07.rst.asc">FreeBSD-SA-98:07.rst.asc</A></LI>
<LI><A HREF="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-98:08.fragment.asc">FreeBSD-SA-98:08.fragment.asc</A></LI>
</UL>
<H2>FreeBSD のセキュリティに関する情報</H2>
<A NAME=ml></A>
<H2>FreeBSD のセキュリティメーリングリストについて</H2>
<P>FreeBSD のセキュリティについて最新の情報に触れ続けたいのであれば, 以下の
メーリングリストに参加することができます.</P>
<P>もしいくつかの FreeBSD システムを管理/利用しているのなら,
以下のメーリングリストのうち少なくとも一つに参加するべきです:</P>
<PRE>
freebsd-security セキュリティ一般に関する議論
@ -142,75 +164,331 @@ freebsd-security-notification
と書かれたメールを
<A HREF="mailto:majordomo@freebsd.org">majordomo@FreeBSD.ORG</A>
宛てに送って下さい.
例えば,
<PRE>
% echo "subscribe freebsd-security" | mail majordomo@freebsd.org
</PRE>
とします. もしメーリングリストから脱退したい場合は,
<PRE>
% echo "unsubscribe freebsd-security" | mail majordomo@freebsd.org
</PRE>
とします.
<A NAME=spg></A>
<H2>安全なプログラミングのためのガイドライン</H2>
<P><P><UL>
<LI>いかなる場合も入力の源 (source of input) を信用しないでください.
例えばコマンドライン引数, 環境変数, 設定ファイル, 入ってくる TCP/UDP/ICMP
パケット, ホスト名の lookup, 関数の引数などです.
もし受け取ったデータの長さ, 内容が自分の制御下にないなら,
内容をコピーするプログラム, 関数は十分に注意しなければなりません.
特に注意しなければならないのは以下のようなことです:
<P></P>
<UL>
<LI>境界のわからないデータによる strcpy() や sprintf() の呼び出し.
長さが分かっている場合には strncpy や snprintf() を使います.
(長さが分からない場合には何らかの境界チェックを実装します.)
要するに, gets() や sprintf() は決して使ってはいけない, ということです, 以上.
もし使ったとしたら, 邪悪な小人があなたの後ろから忍び寄ることでしょう.
<P></P></LI>
<LI>もし特定の文字を禁止したユーザの入力を必要とした場合には,
決してそれらの禁止した文字をチェックしてはいけません.
代りに, あなたが許可した文字でのみ構成されているかどうかを
チェックします. 基本的には, 明示的に許可したもの以外は
すべて禁止する, とします.
<P></P></LI>
<LI>strncpy() と strncat() のマニュアルページを良く読むこと.
これらがどのように働くのか良く理解してください!!!
strncpy() が末端の \0 を付け加えないかもしれないのに対して,
strncat() は \0 を付け加えます.
<P></P></LI>
<LI>strvis() と getenv() の誤用に注意する.
strvis() では, 簡単に期待とは違った文字列になってしまいます.
getenv() はプログラムが予想する長さよりも長い文字列を返すことがあります.
これらの二つの関数は, プログラムへの攻撃に際し鍵となる手法のひとつで,
環境変数に予想外の値を設定しスタックや変数を上書きします.
もしあなたのプログラムが環境変数を読み込むなら, 偏執症になってください.
しつこいくらいの偏執症に.
<P></P></LI>
<LI>open() や stat() を使うときは, 毎回自問自答してください:
「これがシンボリックリンクだったらどうなる?」
<P></P></LI>
<LI>mktemp(), tempnam(), mkstemp() などの代りに mkstemp() を使うようにする.
一般的に /tmp で起こる競合に注意することはもちろんのこと,
めったに起こらない状況にも注意を払ってください:
<UL>
<LI>ディレクトリを作成する. これは成功も失敗も有り得る.</LI>
<LI>O_CREAT | O_EXECL でファイルをオープンする</LI>
</UL>
mkstemp を使った場合, これらのケースもうまく面倒を見てくれます.
よってすべての一時的なファイルは, 競合条件を排除し,
パーミッションが適切かどうかを保証するために mkstemp() を使うべきです.
<P></P></LI>
<LI>攻撃者が他の任意のシステムへ/からパケットを送る/受け取ることができる
場合, 攻撃者は私たちが受け取るデータを完全に制御できるようになり,
<B>一切の</B>データは信用できなくなります.
<P></P></LI>
<LI>設定ファイルが正しい書式で書かれているとか, 適切なユーティリティで出
力されていることを仮定してはいけません.
ユーザが指定する端末名や言語指定文字列など, パス名に使う可能性のあるものでは,
'/' や '../../../' などの文字列が含まれる可能性を考慮する必要があります.
setuid root で動くプログラムの場合には, ユーザにより指定されたパスを
<B>絶対に</B>信用してはいけません.
<P></P></LI>
<LI>データが格納される方法にセキュリティホール/弱点がないかどうか
探してください.
詮索好きな眼から保護するために, すべての一時ファイルのパーミッション
は 600 にするべきです.
<P></P></LI>
<LI>特権で動作するプログラムは, ありきたりの問題を grep するだけ
ではいけません.
strcpy() やその類似関数の誤用による, バッファオーバーフローを
引き起こす方法は数多く存在するので,
そのようなプログラムではすべての行でオーバーフローの可能性を
探ってください.
<P></P></LI>
<LI>ある個所で特権を放棄したからといって, それで exploit が
なくなるというわけではありません.
攻撃者は, あとで /bin/sh を実行する際に再び特権が得られるように,
スタックに必要なコードを置いておくかもしれません.</LI></UL>
<P></P></LI>
<LI>uid で管理しましょう.
できる限り早く特権を放棄しましょう(しかも完全に).
euid と uid を入れ替えるだけでは十分ではありません.
可能なら setuid() を使いましょう.
<P></P></LI>
<LI>エラーが発生しても設定ファイルを表示しないようにします.
行番号と行内での位置が分かれば十分です.
これはすべてのライブラリ, suid/sgid プログラムに当てはまります.
<P></P></LI>
<LI>既存のコードのセキュリティ上の問題を発見するために,
コードを見直すときには以下の点に注意します:<P></P><UL>
<LI>自分のセキュリティ上の修正に自信がない場合には,
あらかじめ同意を得ているレビュアーに送って, あなたのコードを
見直してもらってください.
セキュリティ上の修正と銘打って何かを壊してしまうと,
とても恥ずかしい思いをすることになりますので,
良く理解していないコードを commit しないでください.
<P></P></LI>
<LI>あなたが commit 権限を持っていない場合,
権限を持ったレビュアーは, その変更をチェックする最後の人間となります.
その人がチェックと, 最終バージョンをソースツリーに取り入れる作業の
両方を行うことになります.
<P></P></LI>
<LI>レビュー用に変更点を送る際には, context diff もしくは unified diff
を用いるようにします.
この diff は patch(1) に簡単に適用できます.
単純にファイル全体を送るようなことはしないでください.
diff の出力は読みやすく,
(複数の変更が同時に加えられたような場合でも)
手元のソースに簡単に適用できます.
すべての変更は -current ブランチに対して行うようにします.
<P></P></LI>
<LI>レビュアーに変更点を送付する前に, 必ず自分でその変更をテストするよう
にします(関連するソースをビルドして実行する, など).
明らかに壊れているものをレビューしたがる人はいませんし,
そのようなものは提出者が自分が何をしたかをよく確認していない,
ということをはっきりさせるにすぎません.
(which is also hardly
confidence building)
もし特定のバージョンのものが入っているマシンのアカウントが必要なら,
そう尋ねてください.
プロジェクトはそのような目的のためのリソースを用意しています.
<P></P></LI>
<LI>コミッターへの注意: -current へのパッチを -stable ブランチに
適切に適用することを忘れないでください.
<P></P></LI>
<LI>あなたのスタイルに合うようにコードを書き直す必要はありません.
そんなことはレビュアーの仕事をより困難にするだけです.
明白な理由がない限りそのようなことはしないでください.</LI></UL>
<P></P></LI>
<LI>シグナルハンドラの内部で複雑なことをしているプログラムを
探してください.
ライブラリ内の多くのコードは, このようなことを安全に行えるほど
再入可能ではありません.
<P></P></LI>
<LI>realloc() の使い方には特別な注意を払ってください.
多くの場合, この関数は正しく使われていません.
<P></P></LI>
<LI>固定サイズのバッファを使うときには, バッファのサイズが変わっても
コードの部分が変更されないということが無いように, sizeof() を
使うようにしてください. たとえば:
<LISTING>
char buf[1024];
struct foo { ... };
...
BAD:
xxx(buf, 1024)
xxx(yyy, sizeof(struct foo))
GOOD:
xxx(buf, sizeof(buf))
xxx(yyy, sizeof(yyy))
</LISTING>
ポインタが指しているもののサイズを知りたいときに,
ポインタの sizeof をとったりしないよう注意してください.
<P></P></LI>
<LI>"char foo[###]" のようなものを見たときには,
すべての foo の使い方が正しいかどうかを調べて,
オーバーフローする可能性がないかどうかをチェックしてください.
オーバーフローが避けられない場合には,
すくなくともバッファを malloc して, スタック上を動き回ることが
できないようにしてください.
<P></P></LI>
<LI>ファイル識別子はできる限り早く close してください.
ライブラリルーチンでは, ファイル識別子は常に "使ったら close"
するようにしてください.
<P><P></LI>
</UL>
<A NAME=tat></A>
<H2>FreeBSD セキュリティ Tips and Tricks</H2>
<P>FreeBSD システム (実際にはどの Unix システムでも) を
セキュアにするにはいくつかのステップがあります:
<UL>
<LI>潜在的に危険なソフトウェアを無効にする<BR><P></P>
多くのソフトウェアは特定のリソースを使うために,
set-uid として実行可能にすることによって
特権ユーザとして実行されなければなりません.
たとえば UUCP や PPP はシリアルポートを使うために,
sendmail はメールスプールに書き込むために,
bind は特権ポートを使うために, 特権ユーザとして実行されます.
UUCP を使わない場合には,
システムにソフトウェアがあっても役にたちません.
また, 無効にしている方が得策といえます.
もちろん, これを行うには, 将来的にその機能が必要かの見極めと,
必要なものと不要なものを分別する知識が必要です.<BR><P></P>
swapinfo のように, セキュリティ上の危険性を高める可能性はあるが,
それほど有用ではないユーティリティに気がつくかと思います.
('chmod ug-s ファイル名' コマンドを使い)
プログラムの set-uid ビットを外しても, root の時は swapinfo を常に
使い続けることができます.
しかし, 多くの s ビットを外すために, 常時 root になっている, という
ことはあまりよいことではありません.
不要なプログラムを削除するだけではなく, 提供しないサービスも
取り除きます.
<TT>/etc/inetd.conf</TT> や <TT>/etc/rc.conf</TT> ファイルを編集し,
不要なサービスをすべて停止することで取り除くことができます.<P></P>
<LI>セキュリティ上のバグがあるソフトウェアを修正するには
(または, クラッカーの一歩先を行くには)<BR><P></P>
まずは, 様々な <A HREF="#ml">FreeBSD Security メーリングリスト</A>
を購読して下さい. バグの最新情報や修正を入手することができます.
修正は, すぐに当てるようにして下さい.<P></P>
<LI>バックアップ - セキュリティ侵害が起こった場合は,
システムを修復して下さい.<BR><P></P>
常時バックアップを取り, 書き換えられていないことが確実な OS
(例として, CD-Rom) を準備しておきましょう.
バックアップが攻撃者によって書き換えられ,
編集されたデータを含まないようにしてください.
<LI>システムの状態を監視するソフトウェアのインストール<BR><P></P>
(packages や ports にある) tcp wrappers や tripwire のようなプログラムを
用いて, システムを監視することができます.
このようなプログラムは,
侵入者を検知するのに役立ちます. また, 毎日 root アカウントへ送られて
くる /etc/security スクリプトの出力に目を通すようにして下さい.<P></P>
<LI>システムに携わる人の育成<BR><P></P>
ユーザーは, 自分が何をしているのか
を理解しなくてはいけません.
自分のパスワードを他人に渡したり, 簡単に推測できるパスワード
の使用を避けることを教えます. システム/ネットワークの
セキュリティは, ユーザー自身の手の中にあることを理解すれば
いいのです.<P></P>
</UL>
<P>システムのセキュリティを強化する方法の tips の応用編に
ついては, 以下の FreeBSD Security How-To サイトをご利用下さい.
<A HREF="http://www.freebsd.org/~jkb/howto.html">
http://www.freebsd.org/~jkb/howto.html</A></P>
<P>セキュリティとは, 継続です.
セキュリティに関する, 最新の開発状況を常に把握するようにしてください.</P>
<A NAME=misc></A>
<H2>セキュリティ上の問題を見つけてしまった時にすべきこと:</H2>
<UL>
<LI><B>セキュリティ侵害の度合を決定する:</B><BR>
どのような特権で攻撃が行なわれるのでしょう? 一般ユーザでしょうか, それとも
より高い (root 権限に匹敵する) ユーザでしょうか?</LI>
<LI><B>セキュリティ侵害のレベルを決める</B><BR>
攻撃者はどのような特権を得たのか? root 特権を得たのか, それともユー
ザーレベルのアクセス権を得ただけなのか?
</LI>
<LI><B>もはやオリジナルの状態でなくなったシステムの部分を決定する:</B><BR>
どのソフトウェアが不正に改変されているのでしょうか? 安心できるメディアから
OS を再インストールする, あるいはオリジナルソフトウェアの MD5 値をチェック
して, システムをチェックすることもできるでしょう. tripwire パッケージは
(訳注: システムの重要なファイルの) MD5 値を保存することもできます, もっとも
その tripwire が改変されている場合もよく行なわれるということに気づき, 確実に
問題がないとはっきりしているコピーを使用するようにして下さい.</LI>
<LI><B>システム (カーネルや userland) の状態が変更されていないか判断する
</B><BR>
どのソフトウェアが変更されたのか? 新しいカーネルはインストール
されたのか? (telnetd, login のような) システムバイナリは編集されたのか?
OS にたいして変更された疑いがある場合は, 安全なメディアから OS の
再インストールを行います.</LI>
<LI><B>どのようにしてブレークインが行なわれるのかを検出する:</B><BR>
よく知られているセキュリティ上の問題によるものなのでしょうか? 誤った
設定によるものなのでしょうか? 新しいバグであれば, FreeBSD セキュリティ
担当者に連絡して下さい.</LI>
<LI><B>不正侵入の手口を見つける</B><BR>
よく知られているセキュリティバグを通じて侵入はなされたのか?
そうであれば, 正しいパッチを当てて下さい.
設定ミスによって侵入がなされたのか?
侵入は新しいバグによるものなのか?
もしそれが新しいバグによるものと思われる場合,
<A HREF="mailto:security-officer@freebsd.org">
FreeBSD Security Officer</A> までご連絡ください.</LI>
<LI><B>セキュリティホールの修正:</B><BR>
問題を修正した新しいソフトウェアをインストールして下さい. 手早く修正版を
入手できない場合は, 修正版を入手するまで, 一時的にシステムへの外部からの
アクセスを無効化しなければなりません.</LI>
<LI><B>セキュリティホールを修正する</B><BR>
問題を解決するために, 新しいソフトウェアをインストールするか,
古いソフトウェアにパッチを当てます. 既に危険にさらされたアカウント
を無効にします.</LI>
<LI><B>その他の情報源</B><BR>
<A HREF="http://www.cert.org">CERT</A>にも,
システムに侵入された際に取るべき手順について
<A HREF="http://www.cert.org/nav/recovering.html">詳細</A>が
載っています.</LI>
</UL>
<P><B>あなたが自問するかも知れないであろうその他の質問:</B></P>
<H2>その他の関連するセキュリティ情報</H2>
<UL>
<LI>誰に警告しようか? セキュリティ担当者に連絡することができます, あるいは
よりローカルグループ内の権威者に相談することもできます. その選択は, あなた
次第です.</LI>
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">
The COAST archive</A>には, セキュリティに関する豊富なコレクション
があります.</LI>
<LI>問題の原因となっている人を追跡したいだろうか? 問題がすぐ修正されない
うちは, そのクラッカーを捕まえる機会があります. それから, そのクラッカーを
ハードディスクから追い出す機会もあります. その選択は, あなた次第です.</LI>
<LI><A href="http://www.cs.purdue.edu/coast/hotlist/">The COAST Security
Hotlist</A>は, セキュリティ情報を探す際に最初に目を通すとよいでしょう.
役立つセキュリティリンクが多数あります.
あなたがセキュリティについて知りたいと思っていることすべてが
……いや, それ以上のことが載っています.</LI>
<LI><A href="http://www.cert.org">http://www.cert.org</A>や
<A href="http://www.auscert.org.au">http://www.auscert.org.au</A>
のような様々なCERTチーム</LI>
<LI><A HREF="http://www.geek-girl.com/bugtraq/">Bugtraq</A>や
<A HREF="http://www.nfr.net/forum/firewall-wizards.html">
Firewall Wizards</A>のようなメーリングリスト</LI>
</UL>
<H2><A href="secure.html">FreeBSD システムを安全に保つ方法</A></H2>
<P>FreeBSD システム, それから実際のところ種々 UNIX システムを安全なものと
する手順がいくつかあります.</P>
<H2><a href="programmers.html">セキュリティに関する, プログラマのためのべきべからず集</a></H2>
<H2>その他の有用なセキュリティ情報:</H2>
<UL>
<LI><A href="http://www.cs.purdue.edu/coast/archive/index.html">The COAST
アーカイブ</A>
には, セキュリティに関連した情報の膨大な集大成が入っています.</LI>
<LI><A href="http://www.cs.purdue.edu/coast/hotlist/">
The COAST セキュリティホットリスト</A>
このページは, セキュリティに関連した情報を探すための, まさに適切な
出発点です. 数百を越える有用なセキュリティへのポインタが含まれています.
あなたの知りたいセキュリティに関すること全て ... そしてさらには ...</LI>
<LI>世界各国の CERT (例えば, <A href="http://www.cert.org/">www.cert.org</A> や
<A href="http://www.auscert.org.au/">www.auscert.org.au</A>)
(訳注: 日本では
<A href="http://www.jpcert.or.jp/">JPCERT/CC (コンピュータ緊急対策センター)</A>
があります)</LI>
<LI>メーリングリスト: Bugtraq, BOS</LI>
</UL>
&footer
</body>
&footer
</body>
</html>