[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ 次のページ ]

Debian セキュリティマニュアル
第 11 章 - よく聞かれる質問 (Frequently asked Questions、FAQ)


この章はセキュリティメーリングリストにしばしば現れる最もよく聞かれる質問の いくつかを紹介します。メーリングリストに投稿する前にこれを読むべきです。 そうしないと単にマニュアルを読めと言われるでしょう。


11.1 Debian オペレーティングシステムでのセキュリティ


11.1.1 Debian は X より安全ですか?

システムは管理者がシステムを安全にする能力と同じくらい安全です。 Debian はデフォルトで安全な方法でサービスをインストールしようと して、すべてのサービスをデフォルトで停止された状態でインストールする 他のオペレーティングシステムのようにパラノイアであろうとはしないかも しれません。しかし、システム管理者はローカルのセキュリティポリシーに システムのセキュリティを適応される必要があります。


11.1.2 bugtraq には多くの Debian のバグがありますが、これは Debian がとても 脆弱ということですか?

Debian はとても多くのパッケージそして異なるソフトウェアを含みます。たぶん 商用オペレーティングシステムのいくつかによって提供されるものより多いでしょう。 これはソフトウェアがよりすくないシステムより多くの潜在的なセキュリティ問題が ひそんでいるということです。

しかし、Debian を含む大手ソフトウェアコンポーネントに対してなされた ソースコード監査に関連する多くの勧告があります。このようなソースコード監査で 大きな欠陥が見つかるたびに、それは修正され、勧告が bugtraq などのメーリング リストに送られます。

Debian ディストリビューションにあるバグはふつう他のベンダや他の ディストリビューションにも影響します。各勧告 (DSA) の最初にある「Debian 特有か (Debian specific): yes/no」の部分を調べてください。もし「yes」ならば、 それは Debian にのみ影響します。「no」ならばたぶん他のディストリビューション にも影響するでしょう。


11.1.3 Debian にはセキュリティ関連の証明書がありますか?

単純な答え: いいえ。

長い答え: 証明書には金がかかります。そしてだれも Debian GNU/Linux ディストリビューションを、たとえば the Common Criteria のいずれかのレベルで あると証明するために資源をささげてはいません。もし証明書つきの GNU/Linux ディストリビューションを作るのに興味があるならそれを可能にするために 資源を提供してください。


11.1.4 Debian に強化用プログラムはありますか?

あります。もともと他の Linux ディストリビューション (RedHat と Mandrake) 向けだった Bastille Linux は 現在では Debian で動きます。加えられた変更を上流のバージョンに統合するために 作業が行われています。いずれにせよ Debian のパッケージはもちろん bastille という名前です。

しかし、強化ツールを使ってもよい管理の必要性がなくなるわけではないと信じる 人もいます。


11.1.5 どうすれば XYZ サービスをより安全にできますか?

いくつかのサービス (FTP、Bind) を Debian GNU/Linux でより安全にするための 情報がこの文書中にあります。しかし、ここで扱われていないサービスについては、 そのプログラムの文書か Linux 一般の文書を見ましょう。Unix システムへの セキュリティ関連のガイドラインのほとんどは Debian にもあてはまります。よって、 Debian のサービス X を安全にするのは、ほとんどの場合、ほかの Linux ディストリビューション (または、それを言うなら Unix) でそのサービスを 安全にするのと同様です。


11.1.6 Debian のすべてのパッケージは安全ですか?

Debian security team は Debian に含まれるすべてのパッケージについて潜在的な セキュリティ上の脆弱性を調べることはできません。なぜならプロジェクト全体の ソースコード監査を行うために十分な資源がないからです。しかし、 Debian は 上流開発者または Linux Kernel Security Audit ProjectLinux Security-Audit Project などのプロジェクトによって行われるソースコード監査の恩恵を受けています。

実際、Debian 開発者がパッケージ中にトロイの木馬を含めて配布する可能性は ありますし、それを調べるための可能な方法もありません。そのような調査が Debian に導入されるとしてもトロイの木馬が実行されるすべての考えられる状況を 扱うことは不可能でしょう。

これは無保証ライセンス条項に頼ることになります。いずれにせよ、 Debian ユーザは安定版のコードには多くのユーザがいて問題の大部分は使用中に 発見されると確信することができます。どんな場合でも (必要なソースコード監査を 提供できないならば) 価値あるシステムにテストされていないソフトを インストールすることは推奨されていません。そして、いずれにせよ、 ディストリビューションに仕組まれたセキュリティ上の脆弱性があるとすれば、 それを含めるために使われた過程 (電子署名を使うこと) は問題が究極的には 特定の開発者までたどれることを保証します。そして Debian プロジェクトが この問題を軽く見たことはありません。


11.1.7 オペレーティングシステムのユーザやグループ


11.1.7.1 システムユーザはすべて必要ですか?

はいといいえの両方です。新サービスのインストールが簡単になるように (これらはすでに適切なユーザで動いています)、Debian にはいくつかのサービスの ためにはじめから定義されたユーザ (Debian Policy に説明されて いるように、id が 99 以下です) があります。もしこれらの新しいサービスを インストールするつもりがないなら、あなたのシステムでどのファイルも所有して おらずどのサービスも動かしていないユーザを安全に削除することができます。

どのファイルも所有していないユーザは以下のコマンドを実行することで簡単に 発見できます (root として実行してください、なぜなら一般ユーザはいくつかの 秘密のディレクトリに入るのに十分な許可を持っていないかもしれないからです):

     cut -f 1 -d : /etc/passwd |
     while read i; do find / -user "$i" | grep -q . && echo "$i"; done

これらのユーザは base-passwd で提供されます。 その文書にはこれらのユーザが Debian でどう扱われるかについてより多くの 情報があります。

デフォルトのユーザ (対応するグループがあるもの) のリストがこれです:

対応するユーザを持たない他のグループ:


11.1.7.2 adm グループと staff グループのちがいは何ですか?

「adm」は管理者です。主に su せずにログファイルを読めるように するのに便利です。「staff」はよりヘルプデスクや格下のシステム管理者の ような人たちに便利で、/usr/local 関連の作業を行ったり /home にディレクトリを作ったりできるようにします。


11.1.8 サービスおよび開いているポートに関する質問


11.1.8.1 なぜすべてのサービスがインストール時に起動されるのですか

これは一方ではセキュリティに気をつけること、他方ではユーザにやさしいことという 問題に対する取り組み方のひとつにすぎません。管理者によって起動されるまで すべてのサービスを停止する OpenBSD とは異なり、Debian GNU/Linux は停止されない かぎりすべてのインストールずみのサービスを起動します (くわしくは デーモンサービスを停止する, 第 3.6.1 節 をごらんください)。結局、そのサービスをインストール したのはあなたでしょう?

Debian のメーリングリスト (debian-devel と debian-security の両方) で このどちらを標準的な設定にするべきかについて多くの議論がなされてきました。 しかし、これを書いている時点 (2002 年 3 月 10 日) ではこの問題にどう 取り組むべきか合意が得られていません。


11.1.8.2 inetd を削除することはできますか?

Inetd を削除することは簡単ではありません。なぜなら netbase がそれを提供するパッケージ (netkit-inetd) に依存するからです。inetd を削除したいなら それを停止することもできますし (デーモンサービスを停止する, 第 3.6.1 節 をごらんください)、 equivs パッケージを使ってそのパッケージを削除する こともできます。


11.1.8.3 なぜ 111 番ポートは開いていますか?

111 番ポートは sunrpc の portmapper です。これは Debian システムのすべての base インストールでデフォルトでインストールされます。なぜならユーザの プログラムが正しく動くのにいつ RPC が必要か知る必要はないからです。 いずれにせよ、こえは主に NFS に使われます。もし必要ないのなら、 RPC サービスを無効にする, 第 5.14 節 で説明されているようにそれを削除してください。


11.1.8.4 identd (113) は何の役に立ちますか?

Identd は管理者が userid の詳細をだれがあなたのシステムからの接続に責任が あるか知りたい、リモートのシステムに提供するために使われます。特に これにはメール、FTP および IRC サーバが含まれます。しかし、これはあなたの ローカルシステムのどのユーザがリモートのシステムを攻撃しているのか追跡するの にも使えます。

これに関しては広範囲にわたる議論があります。 mailing list archives をごらんください。基本的にそれを何に使うか 知らないなら、起動しないようにしてください。しかしそれをファイアウォールで 遮断するならば、どうかそれを deny ルールではなく reject ルールに してください。そうしないと timeout 時間がつきるまでやりとりが止まるかも しれません (reject or deny issues をごらんください)。


11.1.8.5 このポート (XYZ) が開いているのがわかりました、閉じていいですか?

もちろん閉じていいです。開いたままのポートは他のシステムが利用可能な 公開サービスに関するあなたのサイトのポリシーに沿ったものであるべきです。 それが inetd (inetd サービスを停止する, 第 3.6.2 節 をごらんください) によって開いているのか、 他のインストールされているパッケージによって開いているのかを調べて、 適切な手段 (inetd を設定するとか、パッケージを削除するとか、ブート時に 起動するのを避けるとか) を取ってください。


11.1.8.6 /etc/services からサービスを削除しました、これで いいですか?

いいえ/etc/services は仮想名から特定のポート番号への 写像を提供するだけです。そこから名前を削除しても (ふつうは) サービスが 起動するのを防ぐことはできません。デーモンには /etc/services が 変更されていると動かないものもあるかもしれませんが、これは基準では ありませんし、推奨されている方法でもありません。デーモンサービスを停止する, 第 3.6.1 節 を ごらんください。


11.1.9 パスワードがわからなくなって、システムにアクセスできません!

ここから回復するために必要な手段は Lilo や BIOS を制限するためにここで 提案された手続きを適用したかどうかに依存します。

もし両方を制限したなら、先に進む前に BIOS の機能 (ハードディスクだけから ブートできるようにする) を停止する必要があります。もし BIOS のパスワードも 忘れたなら、システムの箱を開いて BIOS のバッテリーを手作業で取りはずす 必要があるでしょう。

CD-ROM またはディスケットからのブートを有効にしていたら、このようにできます:

これは root のパスワードを削除します。システムを起動して login: プロンプトから root として (空のパスワードで) ログインすることができます。これはシステムを よりきつく設定していないかぎり、すなわちユーザに空のパスワードを許していて root がコンソールからログインできるならばうまくいきます。

もしこの機能も導入していたならばシングルモードに入る必要があります。LILO が 制限されていない必要があります。もしこれも行っていたならば上記の root の リセットの直後に lilo を再実行する必要があります。 実物のハードディスクではなく ramdisk である / ファイルシステムのせいで /etc/lilo.conf をいじる必要があるのでこれはとても複雑です。

もし LILO が制限されていないならば、こうできます:


11.2 私のシステムは脆弱です!


11.2.1 侵入されました、どうしましょう?

この文書を読んでここで述べられている適切な手段を取りましょう。 助けが必要ならシステムを修復したり修正したりする方法について助言を求めるのに debian-security@lists.debian.org を使ってもいいです。


11.2.2 どうやったら攻撃を追跡できますか?

ログを見ること (もしそれが変更されていないなら)、侵入検知システムを 使うこと (侵入検知を設定する, 第 9.1 節 をごらんください)、 traceroutewhois その他の道具 (科学捜査を 含みます) を使うことによって、攻撃を発生源まで追跡できます。この情報に どう反応するべきかはあなたのセキュリティポリシーに、そして あなたが 何を攻撃と考えるかにのみ依存します。リモートスキャンは攻撃でしょうか? 脆弱性探査は攻撃でしょうか?


11.2.3 Debian のプログラム X は脆弱です、どうしましょう?

まずその脆弱性が公開のセキュリティ関係のメーリングリスト (Bugtraq など) か 他のフォーラムで発表されているか確かめましょう。Debian Security Team は このメーリングリストについていっているので、すでにこの問題に気づいて いるかもしれません。発表が http://security.debian.org にあれば それ以上何もしないでください。

もしこのどれもなければ、関連するパッケージおよび脆弱性の説明について できるだけ詳しく (考えのためし書きの段階でもかまいません) 書いて security@debian.org にメールで送ってください。security team に接触できる はずです。


11.2.4 パッケージのバージョン番号によると依然として脆弱なバージョンを使って いることになります!

新しいリリースにアップグレードするかわりに私たちはセキュリティ関連の修正を 安定版リリースで出荷されたバージョンに逆移植しています。こうする理由は リリースの変更をできるだけ小さくして、セキュリティ関連の修正の結果物事が 思いがけず変わったり壊れたりしないようにするためです。安全なバージョンの パッケージを使っているかどうかはそのパッケージの変更履歴を見るか、その 正確な (上流のバージョン - 斜線 - Debian リリース) バージョン番号を Debian Security Advisory が示すバージョンと比較することによって調べることが できます。


11.2.5 ログの中でユーザが「su」しているのを発見しました。

ログの中にこのような行があるかもしれません:

      Apr  1 09:25:01 server su[30315]: + ??? root-nobody
      Apr  1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (uid=0)

あまり気にしないでください。これが cron 経由で実行されるジョブ (ふつうは /etc/cron.daily/findlogrotate です) によるものか 確かめてください:

     $ grep 25 /etc/crontab
     25 6    * * *   root    test -e /usr/sbin/anacron || run-parts --report
     /etc/cron.daily
     $ grep nobody /etc/cron.daily/*
     find:cd / && updatedb --localuser=nobody 2>/dev/null

11.2.6 特定のソフトウェア


11.2.6.1 Proftpd はサービス否定攻撃に脆弱です

DenyFilter \*.*/ を設定ファイルに加えてください。くわしくは http://www.proftpd.org/critbugs.html をごらんください。


11.3 Debian security team に関する質問


11.3.1 Debian Security Advisory (DSA) とは何ですか

これはセキュリティ関連の脆弱性の修正が Debian オペレーティングシステムで 利用可能であることを知らせるために Debian Security Team (下記参照) によって 送られる情報です。署名された DSA は公開のメーリングリストに送られ、 Debian のウェブサイト (トップページと security area の両方) に 投稿されます。

DSA には影響するパッケージ、発見されたバグおよび更新されたパッケージを どこから入手できるか (そしてそのパッケージの MD5 sum) についての情報が 含まれます。


11.3.2 Debianの勧告についている署名が正しく検証されません!

これはたぶんあなたの側の問題です。debian-security-announce メーリングリストは security team メンバーの正しい署名のあるメッセージだけが投稿できるような フィルタを持っています。

たぶんあなたの側のメールソフトウェアの一部がメッセージをすこし変更していて、 それが署名を壊しています。あなたのメールソフトが MIME のエンコーディングや デコーディング、タブと空白の変換などを一切行わないようにしてください。

既知の原因には fetchmail (mimedecode オプションが有効になっているとき) や formail (procmail 3.14 のみ) があります。


11.3.3 セキュリティ関連の事件は Debian でどう扱われていますか?

いったん Security Team が事件の通知を受けとると、ひとりまたは複数の メンバーがそれを再調査して Debian/stable が脆弱かどうか考えます。もし 私たちのシステムが脆弱なら、問題の修正についての作業が行われます。 もしまだ Security Team に連絡していないなら、パッケージのメンテナにも 連絡されます。最後に修正がテストされ新しいパッケージが準備されます。 これはすべての安定版のアーキテクチャでコンパイルされそのあとアップロード されます。これらすべての作業が終わったあと Debian Security Advisory (DSA) が 公開のメーリングリストに送られます。


11.3.4 Debian が XXXX という脆弱性を修正するのにどのくらい時間がかかりますか?

いったん脆弱性がわかったときに Debian security team が勧告を送って 修正ずみのパッケージを作るのにかかる時間の分析によると脆弱性が安定版で 修正されるのにはそれほど時間はかかりません。

報告 published in the debian-security mailinglist によると 2001 年には Debian Security Team がセキュリティ関連の脆弱性を 修正するのに平均で 35 日かかりました。しかし、 50% 以上の脆弱性は 10 日以内に修正され、 15% 以上が勧告が発表されたその日に 修正されています。

しかし、この質問をするときには以下のことを忘れがちです:


11.3.5 testingunstable のセキュリティはどう扱われて いますか?

短い答えは: 扱われていません。Testing や unstableは急速に変化していて、 security team はこれらを適切にサポートするのに必要な資源を持っていません。 もし安全な (そして安定した) サーバがほしいなら安定版にとどまることを 強く推奨します。

しかし、実を言うと、開発版はふつうは非常にはやく修正されます。 なぜならセキュリティ上の更新 (ふつうは上流で得られます) がときどきよりはやく 行われるからです (安定版などの他のバージョンはふつう逆移植する必要があります)。


11.3.6 security.debian.org の公式ミラーはなぜないのですか?

回答: security.debian.org の目的はセキュリティ関連の更新をできるだけはやく そして簡単に利用可能にすることです。ミラーは不要な複雑さを追加するでしょうし、 ミラーが更新されていなければ失敗の原因になり得ます。


11.3.7 security team に連絡をとるには?

回答: セキュリティ関連の情報は security@debian.org に送ることができます。 これはすべての Debian 開発者に読まれています。秘密の情報があるなら team@security.debian.org を使ってください。これは security team のメンバー だけが読むことができます。もし望むなら電子メールを Debian Security Contact key (鍵 ID 363CCD95) で暗号化することもできます。


11.3.8 security@debian.org と debian-security@lists.debian.org のちがいは 何ですか?

security@debian.org にメッセージを送るとそれはすべての Debian 開発者が 講読している開発者メーリングリスト (debian-private) に送られます。この メーリングリストへの投稿は非公開にされます (すなわち、公開のウェブサイトでは 保存されません)。debian-security@lists.debian.org は公開のメーリング リストです。講読したい人すべてに対して開かれており、ウェブサイトには 検索可能なアーカイブがあります。


11.3.9 どうすれば Debian security team に貢献できますか?

いずれにせよ、security@debian.org に報告する前にそれぞれの問題を見なおして ください。もしパッチを提供できるなら、セキュリティを向上させる過程を はやくすることができるでしょう。bugtraq のメールを単に転送することは やめてください。なぜならこれをすでに受けとっているからです。しかし、 追加の情報を提供するのはいつでもよい考えです。


11.3.10 Security Team にいるのはだれですか?

Debian Security Team は現在 5 名のメンバーと 2 人の秘書によって 構成されています。Security Team 自体が参加する人を任命します。


11.3.11 Debian Security team は Debian のすべての新パッケージを調べていますか?

いいえ。Debian security team はすべての新パッケージを調べはしませんし、 悪意のある新パッケージを検知するための自動 (lintian) チェックもありません。 なぜならこれらのチェックは自動的に検知するのがほぼ不可能だからです。 しかし、メンテナは Debian に導入されるソフトウェアについて完全に 責任がありますし、公認の開発者によって最初に署名されることなくソフトウェアが 導入されることはありません。メンテナには自分が開発しているソフトウェアを 解析する責任がありますし、メンテナはセキュリティ意識を持っています。


11.3.12 私は古いバージョンの Debian を持っています。これはセキュリティサポートは なされていますか?

いいえ、残念ながら、Debian Security Team は安定版リリース (非公式には開発版も) および他の古いリリースの両方を扱うことができません。しかし、新しい Debian ディストリビューションがリリースされた直後の一定期間はセキュリティ上の更新が あると期待することができます。


[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ 次のページ ]

Debian セキュリティマニュアル

v2.4 Tue, 30 Apr 2002 15:41:13 +0200 (翻訳: Thu, 6 Jun 2002)

Javier Fernández-Sanguino Peña jfs@computer.org
翻訳: 大原雄馬 oohara@libra.interq.or.jp