はじめに

この web ページは, FreeBSD オペレーティングシステムのセキュリティ に関して, 初心者, ベテランを問わず手助けになるよう書かれています. FreeBSD の開発チームは, セキュリティに非常に気を使っており, OS をできる限り安全なものにしようと常に努力しています.

ここではどのようにして様々な外部からの攻撃からあなたの システムを守るか, またセキュリティに関わるバグを発見した場合に 誰に連絡すれば良いのか, などについて, 多くの情報や情報への リンクを掲載しています.

目次

• FreeBSD セキュリティ担当者について
• FreeBSD のセキュリティ勧告
• FreeBSD セキュリティメーリングリストについて
• FreeBSD セキュリティの Tips and Tricks
• 安全なプログラミングのためのガイドライン
• その他の関連するセキュリティ情報

FreeBSD セキュリティ担当者

セキュリティに関して取り組んでいる人たちとの情報交換を 円滑にするため, FreeBSD はセキュリティ関係の窓口として セキュリティ担当者 を設けています. このセキュリティ担当者は実際には複数の人物により構成されており, FreeBSD の既知のセキュリティホールや, 潜在的なセキュリティ問題に関して勧告を広報することが主な 役割となります.

もしセキュリティに関するバグの可能性について FreeBSD チームのだれかに連絡とをる必要が生じたなら, あなたが発見したことの詳細と, 何が問題となっているのかを書いて セキュリティ担当者に メールを送ってください. また, セキュリティ担当者は世界各国の CERT (訳注: 日本では JPCERT/CC) や FIRST チームと 連絡を取り合い, FreeBSD 本体や FreeBSD でよく使われる ユーティリティのセキュリティ上の弱点に関する情報交換を行っています. セキュリティ担当者は, これらの団体における活発なメンバでもあります.

気がかりな問題があってセキュリティ担当者と連絡を取る必要がある場合は, あなたからのメッセージを暗号化するために, セキュリティ担当者の PGP 公開鍵 を使用して下さい.

FreeBSD のセキュリティ勧告

FreeBSD セキュリティ担当者は, FreeBSD の以下のリリースに対して セキュリティ勧告を提供しています:

• FreeBSD の最新の公式リリース
• FreeBSD-current
• FreeBSD-stable (このブランチから 2 つ以上リリースされている場合)
• 以前の FreeBSD-stable (最新の stable ブランチからのリリース がまだ 2 つに満たない場合)

• FreeBSD 3.3
• FreeBSD 3.4
• FreeBSD-current
• FreeBSD-stable

これ以前の古いリリースについては, 積極的にメンテナンスされることは ありませんので, 上記のサポートされているのいずれかへのアップグレードを 強く推奨します.

全ての開発の努力と同様に, セキュリティに関する修正はまず FreeBSD-current ブランチに導入されます. 数日間のテストを経て, 我々のカバーしている FreeBSD-stable ブランチに対応するように, 修正内容が持ち込まれ, 勧告が公表 されることになります.

勧告は, 以下の FreeBSD メーリングリストを通じて公表されます.

• FreeBSD-security-notifications@FreeBSD.org
• FreeBSD-security@FreeBSD.org
• FreeBSD-announce@FreeBSD.org (訳注: この内容は announce-jp@jp.FreeBSD.org にも配送されます)

勧告は, 常に FreeBSD セキュリティ担当者の PGP 鍵 で署名され, FTP CERT リポジトリ に関連パッチとともにアーカイブされます. これ (訳注: 原文のこと) を書いている 時点では, 以下の勧告が公開されています.

• FreeBSD-SA-96:01.sliplogin.asc
• FreeBSD-SA-96:02.apache.asc
• FreeBSD-SA-96:03.sendmail-suggestion.asc
• FreeBSD-SA-96:08.syslog.asc
• FreeBSD-SA-96:09.vfsload.asc
• FreeBSD-SA-96:10.mount_union.asc
• FreeBSD-SA-96:11.man.asc
• FreeBSD-SA-96:12.perl.asc
• FreeBSD-SA-96:13.comsat.asc
• FreeBSD-SA-96:14.ipfw.asc
• FreeBSD-SA-96:15.ppp.asc
• FreeBSD-SA-96:16.rdist.asc
• FreeBSD-SA-96:17.rzsz.asc
• FreeBSD-SA-96:18.lpr.asc
• FreeBSD-SA-96:19.modstat.asc
• FreeBSD-SA-96:20.stack-overflow.asc
• FreeBSD-SA-96:21.talkd.asc
• FreeBSD-SA-97:01.setlocale
• FreeBSD-SA-97:02.lpd.asc
• FreeBSD-SA-97:03.sysinstall.asc
• FreeBSD-SA-97:04.procfs.asc
• FreeBSD-SA-97:05.open.asc
• FreeBSD-SA-97:06.f00f.asc
• FreeBSD-SA-98:01.land.asc
• FreeBSD-SA-98:02.mmap.asc
• FreeBSD-SA-98:03.ttcp.asc
• FreeBSD-SA-98:04.mmap.asc
• FreeBSD-SA-98:05.nfs.asc
• FreeBSD-SA-98:06.icmp.asc
• FreeBSD-SA-98:07.rst.asc
• FreeBSD-SA-98:08.fragment.asc
• FreeBSD-SA-99:01.chflags.asc
• FreeBSD-SA-99:02.profil.asc
• FreeBSD-SA-99:03.ftpd.asc
• FreeBSD-SA-99:04.core.asc
• FreeBSD-SA-99:05.fts.asc
• FreeBSD-SA-99:06.amd .asc
• FreeBSD-SA-00:01.make.asc
• FreeBSD-SA-00:02.procfs.asc

FreeBSD のセキュリティメーリングリストについて

もしいくつかの FreeBSD システムを管理/利用しているのなら, 以下のメーリングリストのうち少なくとも一つに参加するべきです:

freebsd-security		セキュリティ一般に関する議論
freebsd-security-notification	セキュリティ告知 (モデレートメーリングリスト)

     subscribe <リスト名>  [<メールアドレス (オプション)>]

% 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_EXECL でファイルをオープンする
    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" するようにしてください.

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にも, システムに侵入された際に取るべき手順について 詳細が 載っています.

その他の関連するセキュリティ情報

• The COAST archiveには, セキュリティに関する豊富なコレクション があります.
• The COAST Security Hotlistは, セキュリティ情報を探す際に最初に目を通すとよいでしょう. 役立つセキュリティリンクが多数あります. あなたがセキュリティについて知りたいと思っていることすべてが ……いや, それ以上のことが載っています.
• http://www.cert.orgや http://www.auscert.org.au のような様々なCERTチーム
• Bugtraqや Firewall Wizardsのようなメーリングリスト