os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
doc/ja/security/security.sgml
Hiroki Sato 5305bb945d www cleanup mega commit: 
- Move includes.nav*.sgml to share/sgml/navibar.ent and
   <lang>/share/sgml/navibar.l10n.ent.

 - Move includes.sgml and includes.xsl to
   share/sgml/common.ent, share/sgml/header.ent, <lang>/share/sgml/l10n.ent,
   and <lang>/share/sgml/header.l10n.ent.

 - Move most of XSLT libraries to share/sgml/*.xsl and
   <lang>/share/sgml/*.xsl.

 - Move news.xml and other *.xml files for the similar purpose
   to share/sgml/*.xml and <lang>/share/sgml/*.xml.

 - Switch to use a custom DTD for HTML document.  Now we use
   "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension", which is
   HTML 4.01 + some entities previously pulled via
   "<!ENTITY % includes SYSTEM "includes.sgml"> %includes;" line.
   The location of entity file will be resolved by using catalog file.

 - Add DOCTYPE declearation to XML documents.  This makes the followings
   possible:

   * Use of &foo; entities for SGML in an XML file instead of defining
     {$foo} as the same content.

   * &symbolic; entities for Latin characters.

 - Duplicated information between SGML and XML, or English and
   translated doc, has been removed as much as possible.
2006-08-19 21:26:51 +00:00

636 lines
25 KiB
Text
Raw Blame History

<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD: www/ja/security/security.sgml,v 1.84 2005/10/04 16:21:53 hrs Exp $">
<!ENTITY title "FreeBSD Security Information">
<!ENTITY % navinclude.support "INCLUDE">
<!ENTITY advisories.html.inc SYSTEM "advisories.html.inc">
]>
<!-- $FreeBSD: www/ja/security/security.sgml,v 1.84 2005/10/04 16:21:53 hrs Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.150 -->
<html>
&header;
<H2>はじめに</H2>
<P>このページは、FreeBSD のセキュリティに関して、
初心者、ベテランを問わず手助けになるよう書かれています。
FreeBSD では、セキュリティを非常に重要なものと捉えており、
OS をできる限りセキュアなものにしようと常に努力しています。</P>
<P>ここではどのようにしてさまざまな攻撃からあなたのシステムを守るか、
またセキュリティに関わるバグを発見した場合に誰に連絡すれば良いのか、
などについて、多くの情報や情報へのリンクを掲載しています。
また、システムプログラマ向けに、セキュリティ上の弱点を作成しないようにするための
さまざまな手法を紹介する項も含まれています。</P>
<H2>目次</H2>
<UL>
<LI><A HREF="#sec">FreeBSD セキュリティオフィサについて</A></LI>
<LI><A HREF="#pol">情報の取り扱いに関する方針</A></LI>
<LI><A HREF="#adv">FreeBSD のセキュリティ勧告</A></LI>
<LI><A HREF="#ml">FreeBSD セキュリティメーリングリストについて</A></LI>
<LI><A HREF="#tat">FreeBSD セキュリティの Tips と 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 ではセキュリティ関係の窓口としてセキュリティオフィサを設けています。</P>
<P>もしセキュリティに関するバグの可能性について
FreeBSD プロジェクトと連絡をとる必要が生じたら、
発見したことの詳細と、何が問題となっているのかを書いて
<a HREF="mailto:security-officer@FreeBSD.org">セキュリティオフィサ</a>に
メールを送ってください。</P>
<P>FreeBSD プロジェクトでは、脆弱性の報告に対して臨機応変に対応する目的で
セキュリティオフィサのメールエイリアスに 4 人
(セキュリティオフィサ、セキュリティオフィサ補佐、コアチームメンバ 2 人)
が登録されています。つまり、
<a href="mailto:security-officer@FreeBSD.org">&lt;security-officer@FreeBSD.org&gt;</a>
へ送られたメールは、現在以下のメールアドレスへ届くようになっています。</P>
<table>
<tr valign="top">
<td>Jacques Vidrine <a
href="mailto:nectar@FreeBSD.org">&lt;nectar@FreeBSD.org&gt;</a></td>
<td>セキュリティオフィサ</td>
</tr>
<tr valign="top">
<td>Chris Faulhaber <a
href="mailto:jedgar@FreeBSD.org">&lt;jedgar@FreeBSD.org&gt;</a></td>
<td>セキュリティオフィサ補佐</td>
</tr>
<tr valign="top">
<td>Robert Watson <a
href="mailto:rwatson@FreeBSD.org">&lt;rwatson@FreeBSD.org&gt;</a></td>
<td>FreeBSD コアチームメンバ、リリースエンジニアリング渉外、<br>
TrustedBSD プロジェクト渉外、システムセキュリティアーキテクチャの専門家</td>
</tr>
<tr valign="top">
<td>Warner Losh <a
href="mailto:imp@FreeBSD.org">&lt;imp@FreeBSD.org&gt;</a></td>
<td>FreeBSD コアチーム渉外、名誉セキュリティオフィサ</td>
</tr>
</table>
<P>また、セキュリティオフィサが選出したコミッターグループである
<a href="mailto:security-team@FreeBSD.org">セキュリティオフィサチーム
&lt;security-team@FreeBSD.org&gt;</a> が、
セキュリティオフィサをサポートしています。</P>
<p>セキュリティオフィサ宛のメッセージに暗号化が必要な場合には、
セキュリティオフィサの
<a href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/public_key.asc">PGP
公開鍵</a>を使って暗号化してください。</p>
<a NAME="pol"></a>
<h2>情報の取り扱いに関する方針</h2>
<p>セキュリティオフィサは一般的な方針として、
脆弱性の発見から、その危険性の解析と修正、修正のテスト、
関係する他の組織との調整などに必要と思われる時間が経過した後に、
その問題に関するすべての情報を公開することを原則とします。</p>
<p>セキュリティオフィサは、
FreeBSD プロジェクトの資源を脅かすような緊急性の高い脆弱性を
<a href="mailto:admins@FreeBSD.org">FreeBSD
クラスタ管理者</a>の一人ないし複数の人たちに<em>かならず</em>通知します。</p>
<p>セキュリティオフィサは、
問題を完全に理解したり修正するために専門的知識や意見が必要とされる場合、
報告されたセキュリティ上の脆弱性について議論を行なうために
セキュリティオフィサ以外の FreeBSD の開発者や外部の開発者に協力を求めることがあります。
報告された脆弱性に関する情報には不必要な流出を最小限に抑える努力を行い、また、
議論に参加する専門家はセキュリティオフィサの方針に従います。
過去、議論に参加した専門家たちは、FFS、VM システム、ネットワークスタックなど、
オペレーティングシステムの非常に複雑なコンポーネントについて
豊富な経験を持っていることを理由に選ばれています。</p>
<p>FreeBSD のリリース作業が進行中の場合、セキュリティオフィサは
適切なリリースサイクルや、予定されているリリースに深刻なセキュリティ上の
バグが含まれているかどうかといった情報を判断材料として提供する目的で、
リリースエンジニアに脆弱性の存在やその影響の大きさを知らせることがあります。
ただしそれが必要だと判断された場合には、
脆弱性の存在やその影響に関する情報の不必要な漏洩を防ぐために、
リリースエンジニアに脆弱性の情報を提供しない場合もあります。</p>
<p>FreeBSD セキュリティオフィサは、FreeBSD とコードを共有しているサードパーティベンダ
(OpenBSD および NetBSD プロジェクト、Apple、FreeBSD に由来するソフトウェアのベンダ、
Linux ベンダのセキュリティリスト) はもちろんのこと、
他の団体や CERT
(訳注: 日本では <A HREF="http://www.jpcert.or.jp/">JPCERT/CC</a>)
のような、脆弱性やセキュリティに関する出来事を追跡する組織と
緊密に協調して作業を行っています。
脆弱性は FreeBSD 以外の実装にも影響することがあり、(頻繁ではありませんが)
世界中のネットワークコミュニティに影響する可能性もあります。
そのような際、セキュリティオフィサは脆弱性に関する情報を他の団体へ公開することがあります。
もしそれが不都合な場合は、脆弱性の報告にその旨を明記してください。</p>
<p>あなたが情報を提供する際に、提供する情報に何か特別な扱いが必要ならば、
それを明記するのを忘れないようにお願いします。</p>
<p>脆弱性の報告を行なう際に、報告者が他のベンダとの間で公開の日程を調整したいと考えている場合は、
脆弱性の報告にその旨を明記してください。明確な指定がない場合、
FreeBSD セキュリティオフィサは、解決策の検証が十分に行なわれ次第、
可能な限り迅速に情報を公開できるような時期を選びます。
ただし、もし脆弱性が (bugtraq のような) 公的なフォーラムで活発に議論されているとか、
すでに積極的に悪用されているといった状態ならば、
セキュリティオフィサはユーザコミュニティの安全を最大限に確保するため、
報告者の指定した公開スケジュールを無視する可能性があることに注意してください。</p>
<p>報告者は
FreeBSD プロジェクトがオープンソースプロジェクトだということ、
また、FreeBSD のソースツリーに加えられたあらゆる変更が
記録されているリビジョン管理情報は、世界中からアクセス可能であるということに
注意してください。
公開スケジュールの指定は、セキュリティ勧告、修正パッチ、更新情報の公開に加え、
ソースツリーへの最初の修正も考慮したものである必要があります。
なお、セキュリティ勧告、修正パッチ、バイナリアップデートの生成にはリビジョン管理システムが利用されるため、
ツリーへの修正とこれらの作業の間には必然的に時間的な遅れが生じます。</p>
<p>情報を提供する際は、PGP を使って暗号化しても構いません。
また、その旨を明記すれば、それに対する返信も PGP を用いて暗号化されます。</p>
<A NAME=adv></A>
<H2>FreeBSD のセキュリティ勧告</H2>
<P>FreeBSD セキュリティオフィサは、以下の FreeBSD
開発ブランチに対してセキュリティ勧告を提供しています。
これには <EM>-STABLE ブランチ</EM> と
<EM>セキュリティブランチ</EM> が含まれます
(<EM>-CURRENT ブランチ</EM> に対する勧告は提供されません)。</P>
<UL>
<LI><P>通常、-STABLE ブランチは一つだけですが、
(たとえば FreeBSD 4.x から 5.x のように) 開発の中心となるブランチが新しいものへと移行する期間は
二つの -STABLE ブランチが存在することになります。
-STABLE ブランチには
<TT>RELENG_4</TT> のような CVS タグ名が付けられています。
これに対応する構築物は
<TT>FreeBSD 4.6-STABLE</TT> のような名前になります。</P></LI>
<LI><P>FreeBSD の各リリースには、
対応するセキュリティブランチがひとつ用意されています。
セキュリティブランチには
<TT>RELENG_4_6</TT> のような CVS タグ名が付けられています。
これに対応する構築物は
<TT>FreeBSD 4.6-RELEASE-p7</TT> のような名前になります。</P></LI>
</UL>
<P>各ブランチに対するセキュリティオフィサのサポートには、
「原則としてリリース後 12 ヵ月間」という期限があります。
現在サポートされているブランチの保守終了予定日は、次のとおりです。
<EM>保守終了予定日</EM>の列には、
そのブランチに対応する最も早い保守終了予定日が記入されています。ただし、
これらの予定日は延長される可能性があること、また、そうするにふさわしい理由があれば
ブランチの保守が記載されている日付よりも早く終了する可能性もあるということに
ご注意ください。</P>
<table class="tblbasic">
<TR>
<TH>ブランチ</TH>
<TH>リリース</TH>
<TH>保守終了予定日</TH>
</TR>
<TR>
<TD>RELENG_4</TD>
<TD>なし</TD>
<TD>2004 年 10 月 31 日</TD>
</TR>
<TR>
<TD>RELENG_4_8</TD>
<TD>4.8-RELEASE</TD>
<TD>2004 年 3 月 31日</TD>
</TR>
<TR>
<TD>RELENG_4_9</TD>
<TD>4.9-RELEASE</TD>
<TD>2004 年 10 月 31日</TD>
</TR>
<TR>
<TD>RELENG_5_1</TD>
<TD>5.1-RELEASE</TD>
<TD>2004 年 2 月 28 日</TD>
</TR>
<TR>
<TD>RELENG_5_2</TD>
<TD>5.2-RELEASE</TD>
<TD>2004 年 7 月 31 日</TD>
</TR>
</TABLE>
<P>これ以前の古いリリースについては、
積極的にメンテナンスされることはありませんので、
上記のサポートされているリリースのいずれかへのアップグレードを強く推奨します。</P>
<P>セキュリティに関する修正は FreeBSD の開発と同様に、まず
<A HREF="&enbase;/doc/ja_JP.eucJP/books/handbook/cutting-edge.html#CURRENT">FreeBSD-current</A>
ブランチに導入されます。
そして数日間のテストを経て、わたしたちのカバーしている
FreeBSD-stable ブランチに対応するように修正内容が持ち込まれ、
勧告が公表されることになります。</P>
<P>2002 年に発行された勧告に関する統計情報:</P>
<ul>
<li>ベースシステムに関するセキュリティ勧告は、(さまざまな緊急度のものが) 44 発行されました。</li>
<li>FreeBSD のみが影響を受けるセキュリティ上の弱点を扱った勧告は、12 ありました。
残りの 32 勧告は、他の少なくとも一つ以上の OS も影響を受けるものです
(これの原因の多くは、ソースコードを共有していることによるものでした)。</li>
<li>セキュリティ情報は、6 発行されました。これは、オプションとして
Ports Collection に含まれているサードパーティ製アプリケーションの、
全部で 95 ある問題を扱っています。</li>
</ul>
<P>セキュリティ勧告は、以下の FreeBSD
メーリングリストを通じて公表されます。</P>
<UL>
<LI>FreeBSD-security-notifications@FreeBSD.org</LI>
<LI>FreeBSD-security@FreeBSD.org</LI>
<LI>FreeBSD-announce@FreeBSD.org (訳注: この内容は
announce-jp@jp.FreeBSD.org にも配送されます)</LI>
</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>
に関連パッチとともにアーカイブされます。
これ (訳注: 原文のこと) を書いている時点では、以下の勧告が公開されています
(このリストは数日ほど情報が古い場合があります。
最新の勧告は <A HREF="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/">
FTP サイト</A> をチェックしてください):</P>
<p><b>訳注:</b>いくつかのセキュリティ勧告には、FreeBSD
日本語ドキュメンテーションプロジェクト(doc-jp)による日本語版が存在します。
この翻訳は以下のリンクから読むことができますが、
announce-jp@jp.FreeBSD.org にも配送されます。
ただし、これらは doc-jp が参考のために提供するもので、
翻訳者および doc-jp は、その内容についていかなる保証もいたしません。
</p>
<p>日本語訳についてのお問い合わせは、
<a href="mailto:doc-jp@jp.FreeBSD.org">doc-jp@jp.FreeBSD.org</a>
までお願いします。この日本語訳は PGP 署名されていませんので、
パッチ等の内容が改竄されていないことを確認するために PGP
のチェックを行なう場合には、原文を参照するようにお願いします。
</p>
&advisories.html.inc;
<A NAME=ml></A>
<H2>FreeBSD のセキュリティメーリングリストについて</H2>
<P>もしいくつかの FreeBSD システムを管理/利用しているのなら、
以下のメーリングリストのうち少なくとも一つに参加するべきです:</P>
<TABLE>
<TR>
<TD><A HREF="http://lists.freebsd.org/mailman/listinfo/freebsd-security">freebsd-security</A></TD>
<TD>セキュリティ一般に関する議論</TD>
</TR>
<TR>
<TD><A HREF="http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications">freebsd-security-notifications</A></TD>
<TD>セキュリティ告知 (流量の少ないモデレートメーリングリスト)</TD>
</TR>
</TABLE>
<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() を使うようにする。
一般的に /tmp で起こる競合に注意することはもちろんのこと、
めったに起こらない状況にも注意を払ってください:
<UL>
<LI>ディレクトリを作成する。 これは成功も失敗も有り得る。</LI>
<LI>O_CREAT | O_EXCL でファイルをオープンする</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>レビュアーに変更点を送付する前に、必ず自分でその変更をテストするよう
にします(関連するソースをビルドして実行する、など)。
明らかに壊れているものをレビューしたがる人はいません。
そのようなものは提出者が自分が何をしたかをよく確認していない、
ということをはっきりさせるにすぎません。
(そんなことでは信頼を得られませんね)。
もし特定のバージョンのものが入っているマシンのアカウントが必要なら、
そう尋ねてください。
プロジェクトはそのような目的のためのリソースを用意しています。
<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() を
使うようにしてください。 たとえば:
<pre>
char buf[1024];
struct foo { ...};
...
BAD:
xxx(buf, 1024)
xxx(yyy, sizeof(struct foo))
GOOD:
xxx(buf, sizeof(buf))
xxx(yyy, sizeof(yyy))
</pre>
ポインタが指しているもののサイズを知りたいときに、
ポインタの sizeof をとったりしないよう注意してください。
<P></P></LI>
<LI>"char foo[###]" のようなものを見たときには、
すべての foo の使い方が正しいかどうかを調べて、
オーバーフローする可能性がないかどうかをチェックしてください。
オーバーフローが避けられない場合には、
すくなくともバッファを malloc して、スタック上を動き回ることが
できないようにしてください。
<P></P></LI>
<LI>ファイル識別子はできる限り早く close してください。
ライブラリルーチンでは、ファイル識別子は常に “使ったら close”
するようにしてください。
<P></P></LI>
</UL>
<P>有用なツールとして its4 の ports が /usr/ports/security/its4/ に
あります。 これは自動化された C のコードの検査ツールで、コード中で
潜在的な問題点をハイライト表示します。 これは最初のチェックには
便利ですが盲信して頼りすぎてはいけません。 完全な監査は
コード全体を人の目で確かめることが必要です。</P>
<P>確実なプログラミングテクニックとリソースに関する更なる情報は、
リソースセンターの
<A HREF="http://www.shmoo.com/securecode/">How to Write Secure Code</A>
を見てください。</P>
<A NAME=tat></A>
<H2>FreeBSD セキュリティ Tips and Tricks</H2>
<P>FreeBSD システム (実際にはどの &unix; システムでも) を
セキュアにするにはいくつかのステップがあります:</P>
<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>
<LI>セキュリティ上のバグがあるソフトウェアを修正するには
(または、クラッカーの一歩先を行くには)<BR><P></P>
まずは、様々な <A HREF="#ml">FreeBSD Security メーリングリスト</A>
を購読して下さい。バグの最新情報や修正を入手することができます。
修正は、すぐに当てるようにして下さい。<P></P></LI>
<LI>バックアップ - セキュリティ侵害が起こった場合は、
システムを修復して下さい。<BR><P></P>
常時バックアップを取り、書き換えられていないことが確実な OS
(例として、CD-Rom) を準備しておきましょう。
攻撃者によって変造されたり書き換えられたデータがバックアップに
含まないようにしてください。<P></P></LI>
<LI>システムの状態を監視するソフトウェアのインストール<BR><P></P>
(packages や ports にある) tcp wrappers や tripwire のようなプログラムを
用いて、システムを監視することができます。
このようなプログラムは、
侵入者を検知するのに役立ちます。また、毎日 root アカウントへ送られて
くる /etc/security スクリプトの出力に目を通すようにして下さい。<P></P></LI>
<LI>システムに携わる人の育成<BR><P></P>
ユーザーは、自分が何をしているのか
を理解しなくてはいけません。
自分のパスワードを他人に渡したり、簡単に推測できるパスワード
の使用を避けることを教えます。システム/ネットワークの
セキュリティは、ユーザー自身の手の中にあることを理解すれば
いいのです。<P></P></LI>
</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>システム (カーネルや userland) の状態が変更されていないか判断する
</B><BR>
どのソフトウェアが変更されたのか? 新しいカーネルはインストール
されたのか? (telnetd、login のような) システムバイナリは編集されたのか?
OS にたいして変更された疑いがある場合は、安全なメディアから OS の
再インストールを行います。</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>
<A HREF="http://www.cert.org">CERT</A>にも、
システムに侵入された際に取るべき手順について
<A HREF="http://www.cert.org/nav/recovering.html">詳細</A>が
載っています。</LI>
</UL>
<H2>その他の関連するセキュリティ情報</H2>
<UL>
<LI><A href="http://www.cerias.purdue.edu/coast/archive/index.html">
The COAST archive</A>には、セキュリティに関する豊富なコレクション
があります。</LI>
<LI><A href="http://www.cerias.purdue.edu/infosec/hotlist/">CERIAS
(Center for Education and Research in Information Assurance and Security)</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://list.nfr.com/forum/firewall-wizards.html">
Firewall Wizards</A>のようなメーリングリスト</LI>
</UL>
&footer;
</body>
</html>
Reference in a new issue View git blame Copy permalink