この章はセキュリティメーリングリストにしばしば現れる最もよく聞かれる質問の いくつかを紹介します。メーリングリストに投稿する前にこれを読むべきです。 そうしないと単にマニュアルを読めと言われるでしょう。
システムは管理者がシステムを安全にする能力と同じくらい安全です。 Debian はデフォルトで安全な方法でサービスをインストールしようと して、すべてのサービスをデフォルトで停止された状態でインストールする 他のオペレーティングシステムのようにパラノイアであろうとはしないかも しれません。しかし、システム管理者はローカルのセキュリティポリシーに システムのセキュリティを適応される必要があります。
Debian はとても多くのパッケージそして異なるソフトウェアを含みます。たぶん 商用オペレーティングシステムのいくつかによって提供されるものより多いでしょう。 これはソフトウェアがよりすくないシステムより多くの潜在的なセキュリティ問題が ひそんでいるということです。
しかし、Debian を含む大手ソフトウェアコンポーネントに対してなされた ソースコード監査に関連する多くの勧告があります。このようなソースコード監査で 大きな欠陥が見つかるたびに、それは修正され、勧告が bugtraq などのメーリング リストに送られます。
Debian ディストリビューションにあるバグはふつう他のベンダや他の ディストリビューションにも影響します。各勧告 (DSA) の最初にある「Debian 特有か (Debian specific): yes/no」の部分を調べてください。もし「yes」ならば、 それは Debian にのみ影響します。「no」ならばたぶん他のディストリビューション にも影響するでしょう。
単純な答え: いいえ。
長い答え: 証明書には金がかかります。そしてだれも Debian GNU/Linux ディストリビューションを、たとえば the Common Criteria のいずれかのレベルで あると証明するために資源をささげてはいません。もし証明書つきの GNU/Linux ディストリビューションを作るのに興味があるならそれを可能にするために 資源を提供してください。
あります。もともと他の Linux ディストリビューション (RedHat と Mandrake)
向けだった Bastille
Linux
は 現在では Debian
で動きます。加えられた変更を上流のバージョンに統合するために
作業が行われています。いずれにせよ Debian のパッケージはもちろん
bastille
という名前です。
しかし、強化ツールを使ってもよい管理の必要性がなくなるわけではないと信じる 人もいます。
いくつかのサービス (FTP、Bind) を Debian GNU/Linux でより安全にするための 情報がこの文書中にあります。しかし、ここで扱われていないサービスについては、 そのプログラムの文書か Linux 一般の文書を見ましょう。Unix システムへの セキュリティ関連のガイドラインのほとんどは Debian にもあてはまります。よって、 Debian のサービス X を安全にするのは、ほとんどの場合、ほかの Linux ディストリビューション (または、それを言うなら Unix) でそのサービスを 安全にするのと同様です。
Debian security team は Debian に含まれるすべてのパッケージについて潜在的な
セキュリティ上の脆弱性を調べることはできません。なぜならプロジェクト全体の
ソースコード監査を行うために十分な資源がないからです。しかし、 Debian は
上流開発者または Linux
Kernel Security Audit Project
や Linux Security-Audit Project
などのプロジェクトによって行われるソースコード監査の恩恵を受けています。
実際、Debian 開発者がパッケージ中にトロイの木馬を含めて配布する可能性は ありますし、それを調べるための可能な方法もありません。そのような調査が Debian に導入されるとしてもトロイの木馬が実行されるすべての考えられる状況を 扱うことは不可能でしょう。
これは無保証ライセンス条項に頼ることになります。いずれにせよ、 Debian ユーザは安定版のコードには多くのユーザがいて問題の大部分は使用中に 発見されると確信することができます。どんな場合でも (必要なソースコード監査を 提供できないならば) 価値あるシステムにテストされていないソフトを インストールすることは推奨されていません。そして、いずれにせよ、 ディストリビューションに仕組まれたセキュリティ上の脆弱性があるとすれば、 それを含めるために使われた過程 (電子署名を使うこと) は問題が究極的には 特定の開発者までたどれることを保証します。そして Debian プロジェクトが この問題を軽く見たことはありません。
はいといいえの両方です。新サービスのインストールが簡単になるように
(これらはすでに適切なユーザで動いています)、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 でどう扱われるかについてより多くの
情報があります。
デフォルトのユーザ (対応するグループがあるもの) のリストがこれです:
/var/spool/cups
は sys
グループによって所有されています。
/bin/sync
です。したがって、
もしそのパスワードが 推測しやすいもの (「」とか)
に設定されていれば、だれでもたとえその
システムにアカウントを持っていなくてもコンソールでシステムの同期を
取ることができます。
/var/cache/man
に
書きこめるように man ユーザとして動きます。
/var/mail
の中のメールボックスはポリシーで説明されているように mail
グループによって所有されています。このユーザやグループはさまざまな MTA
で他の目的にも利用されています。
/var/lib/postgresql
の中のすべてのファイルは適切な
セキュリティを実施するためにこのユーザによって所有されています。
対応するユーザを持たない他のグループ:
/var/log
の中の多くのログを読むことができますし、 xconsole
を使うことが できます。歴史的には、/var/log
は
/usr/adm
でした (そのあと /var/adm
に
なりました)。これがこのグループの名前の由来です。
ppp
、dip
、
wvdial
などの道具を使うことができます。このグループのユーザは
モデムを設定することはできません。モデムを利用するプログラムを実行できる
だけです。
/usr/share/doc/sudo/OPTIONS
をごらんください。
/usr/src
の中のファイルを含むソースコードを
所有しています。src はユーザにシステムのソースコードを管理する能力を
与えるのにローカルで使えます。
/etc/shadow
を読むことができます。この
ファイルにアクセスできる必要があるプログラムは shadow に set gid されて
います。
/var/run/utmp
および同様のファイルに書きこむ
ことができます。これに書きこめる必要があるプログラムは utmp に sgid
されています。
「adm」は管理者です。主に su
せずにログファイルを読めるように
するのに便利です。「staff」はよりヘルプデスクや格下のシステム管理者の
ような人たちに便利で、/usr/local
関連の作業を行ったり
/home
にディレクトリを作ったりできるようにします。
これは一方ではセキュリティに気をつけること、他方ではユーザにやさしいことという 問題に対する取り組み方のひとつにすぎません。管理者によって起動されるまで すべてのサービスを停止する OpenBSD とは異なり、Debian GNU/Linux は停止されない かぎりすべてのインストールずみのサービスを起動します (くわしくは デーモンサービスを停止する, 第 3.6.1 節 をごらんください)。結局、そのサービスをインストール したのはあなたでしょう?
Debian のメーリングリスト (debian-devel と debian-security の両方) で このどちらを標準的な設定にするべきかについて多くの議論がなされてきました。 しかし、これを書いている時点 (2002 年 3 月 10 日) ではこの問題にどう 取り組むべきか合意が得られていません。
Inetd を削除することは簡単ではありません。なぜなら netbase
がそれを提供するパッケージ (netkit-inetd
)
に依存するからです。inetd を削除したいなら それを停止することもできますし (デーモンサービスを停止する, 第 3.6.1 節
をごらんください)、 equivs
パッケージを使ってそのパッケージを削除する こともできます。
111 番ポートは sunrpc の portmapper です。これは Debian システムのすべての base インストールでデフォルトでインストールされます。なぜならユーザの プログラムが正しく動くのにいつ RPC が必要か知る必要はないからです。 いずれにせよ、こえは主に NFS に使われます。もし必要ないのなら、 RPC サービスを無効にする, 第 5.14 節 で説明されているようにそれを削除してください。
Identd は管理者が userid の詳細をだれがあなたのシステムからの接続に責任が あるか知りたい、リモートのシステムに提供するために使われます。特に これにはメール、FTP および IRC サーバが含まれます。しかし、これはあなたの ローカルシステムのどのユーザがリモートのシステムを攻撃しているのか追跡するの にも使えます。
これに関しては広範囲にわたる議論があります。 mailing
list archives
をごらんください。基本的にそれを何に使うか
知らないなら、起動しないようにしてください。しかしそれをファイアウォールで
遮断するならば、どうかそれを deny ルールではなく reject ルールに
してください。そうしないと timeout 時間がつきるまでやりとりが止まるかも
しれません (reject or
deny issues
をごらんください)。
もちろん閉じていいです。開いたままのポートは他のシステムが利用可能な 公開サービスに関するあなたのサイトのポリシーに沿ったものであるべきです。 それが inetd (inetd サービスを停止する, 第 3.6.2 節 をごらんください) によって開いているのか、 他のインストールされているパッケージによって開いているのかを調べて、 適切な手段 (inetd を設定するとか、パッケージを削除するとか、ブート時に 起動するのを避けるとか) を取ってください。
/etc/services
からサービスを削除しました、これで いいですか?
いいえ、/etc/services
は仮想名から特定のポート番号への
写像を提供するだけです。そこから名前を削除しても (ふつうは) サービスが
起動するのを防ぐことはできません。デーモンには /etc/services
が
変更されていると動かないものもあるかもしれませんが、これは基準では
ありませんし、推奨されている方法でもありません。デーモンサービスを停止する, 第 3.6.1 節 を
ごらんください。
ここから回復するために必要な手段は Lilo や BIOS を制限するためにここで 提案された手続きを適用したかどうかに依存します。
もし両方を制限したなら、先に進む前に BIOS の機能 (ハードディスクだけから ブートできるようにする) を停止する必要があります。もし BIOS のパスワードも 忘れたなら、システムの箱を開いて BIOS のバッテリーを手作業で取りはずす 必要があるでしょう。
CD-ROM またはディスケットからのブートを有効にしていたら、このようにできます:
/etc/shadow
を編集して (Debian 2.2 のレスキューディスクには
ae
がついてきます。Debian 3.0 には vi
に似た
nano-tiny
がついてきます) この行を:
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X はどんな番号でもいいです)
こう変更します:
root::XXXX:X:XXXX:X:::
これは root のパスワードを削除します。システムを起動して login: プロンプトから root として (空のパスワードで) ログインすることができます。これはシステムを よりきつく設定していないかぎり、すなわちユーザに空のパスワードを許していて root がコンソールからログインできるならばうまくいきます。
もしこの機能も導入していたならばシングルモードに入る必要があります。LILO が
制限されていない必要があります。もしこれも行っていたならば上記の root の
リセットの直後に lilo
を再実行する必要があります。
実物のハードディスクではなく ramdisk である / ファイルシステムのせいで
/etc/lilo.conf
をいじる必要があるのでこれはとても複雑です。
もし LILO が制限されていないならば、こうできます:
mount -o remount,rw /
passwd
で変更します
(あなたはスーパユーザなので以前のパスワードは聞かれません)
この文書を読んでここで述べられている適切な手段を取りましょう。 助けが必要ならシステムを修復したり修正したりする方法について助言を求めるのに debian-security@lists.debian.org を使ってもいいです。
ログを見ること (もしそれが変更されていないなら)、侵入検知システムを 使うこと
(侵入検知を設定する, 第 9.1 節
をごらんください)、 traceroute
、whois
その他の道具
(科学捜査を 含みます)
を使うことによって、攻撃を発生源まで追跡できます。この情報に
どう反応するべきかはあなたのセキュリティポリシーに、そして あなたが
何を攻撃と考えるかにのみ依存します。リモートスキャンは攻撃でしょうか?
脆弱性探査は攻撃でしょうか?
まずその脆弱性が公開のセキュリティ関係のメーリングリスト (Bugtraq など) か
他のフォーラムで発表されているか確かめましょう。Debian Security Team は
このメーリングリストについていっているので、すでにこの問題に気づいて
いるかもしれません。発表が http://security.debian.org
にあれば それ以上何もしないでください。
もしこのどれもなければ、関連するパッケージおよび脆弱性の説明について できるだけ詳しく (考えのためし書きの段階でもかまいません) 書いて security@debian.org にメールで送ってください。security team に接触できる はずです。
新しいリリースにアップグレードするかわりに私たちはセキュリティ関連の修正を 安定版リリースで出荷されたバージョンに逆移植しています。こうする理由は リリースの変更をできるだけ小さくして、セキュリティ関連の修正の結果物事が 思いがけず変わったり壊れたりしないようにするためです。安全なバージョンの パッケージを使っているかどうかはそのパッケージの変更履歴を見るか、その 正確な (上流のバージョン - 斜線 - Debian リリース) バージョン番号を Debian Security Advisory が示すバージョンと比較することによって調べることが できます。
ログの中にこのような行があるかもしれません:
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/find
か logrotate
です) によるものか
確かめてください:
$ 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
DenyFilter \*.*/ を設定ファイルに加えてください。くわしくは
http://www.proftpd.org/critbugs.html
をごらんください。
これはセキュリティ関連の脆弱性の修正が Debian オペレーティングシステムで
利用可能であることを知らせるために Debian Security Team (下記参照) によって
送られる情報です。署名された DSA は公開のメーリングリストに送られ、 Debian
のウェブサイト (トップページと security area
の両方) に
投稿されます。
DSA には影響するパッケージ、発見されたバグおよび更新されたパッケージを どこから入手できるか (そしてそのパッケージの MD5 sum) についての情報が 含まれます。
これはたぶんあなたの側の問題です。debian-security-announce メーリングリストは security team メンバーの正しい署名のあるメッセージだけが投稿できるような フィルタを持っています。
たぶんあなたの側のメールソフトウェアの一部がメッセージをすこし変更していて、 それが署名を壊しています。あなたのメールソフトが MIME のエンコーディングや デコーディング、タブと空白の変換などを一切行わないようにしてください。
既知の原因には fetchmail (mimedecode オプションが有効になっているとき) や formail (procmail 3.14 のみ) があります。
いったん Security Team が事件の通知を受けとると、ひとりまたは複数の メンバーがそれを再調査して Debian/stable が脆弱かどうか考えます。もし 私たちのシステムが脆弱なら、問題の修正についての作業が行われます。 もしまだ Security Team に連絡していないなら、パッケージのメンテナにも 連絡されます。最後に修正がテストされ新しいパッケージが準備されます。 これはすべての安定版のアーキテクチャでコンパイルされそのあとアップロード されます。これらすべての作業が終わったあと Debian Security Advisory (DSA) が 公開のメーリングリストに送られます。
いったん脆弱性がわかったときに Debian security team が勧告を送って 修正ずみのパッケージを作るのにかかる時間の分析によると脆弱性が安定版で 修正されるのにはそれほど時間はかかりません。
報告 published
in the debian-security mailinglist
によると 2001 年には Debian
Security Team がセキュリティ関連の脆弱性を 修正するのに平均で 35
日かかりました。しかし、 50% 以上の脆弱性は 10 日以内に修正され、 15%
以上が勧告が発表されたその日に 修正されています。
しかし、この質問をするときには以下のことを忘れがちです:
短い答えは: 扱われていません。Testing や unstableは急速に変化していて、 security team はこれらを適切にサポートするのに必要な資源を持っていません。 もし安全な (そして安定した) サーバがほしいなら安定版にとどまることを 強く推奨します。
しかし、実を言うと、開発版はふつうは非常にはやく修正されます。 なぜならセキュリティ上の更新 (ふつうは上流で得られます) がときどきよりはやく 行われるからです (安定版などの他のバージョンはふつう逆移植する必要があります)。
回答: security.debian.org の目的はセキュリティ関連の更新をできるだけはやく そして簡単に利用可能にすることです。ミラーは不要な複雑さを追加するでしょうし、 ミラーが更新されていなければ失敗の原因になり得ます。
回答: セキュリティ関連の情報は security@debian.org に送ることができます。 これはすべての Debian 開発者に読まれています。秘密の情報があるなら team@security.debian.org を使ってください。これは security team のメンバー だけが読むことができます。もし望むなら電子メールを Debian Security Contact key (鍵 ID 363CCD95) で暗号化することもできます。
security@debian.org にメッセージを送るとそれはすべての Debian 開発者が 講読している開発者メーリングリスト (debian-private) に送られます。この メーリングリストへの投稿は非公開にされます (すなわち、公開のウェブサイトでは 保存されません)。debian-security@lists.debian.org は公開のメーリング リストです。講読したい人すべてに対して開かれており、ウェブサイトには 検索可能なアーカイブがあります。
WNPP bug
を提出して、役に立つと思っていて
まだ提供されていないソフトウェアを要求しましょう。
Linux Kernel Security Audit
Project
や Linux Security-Audit
Project
のような他のプロジェクトの仕事は Debian GNU/Linux
のセキュリティを向上させます。なぜならこのような貢献は いずれは Debian
をも助けることになるからです。
いずれにせよ、security@debian.org に報告する前にそれぞれの問題を見なおして ください。もしパッチを提供できるなら、セキュリティを向上させる過程を はやくすることができるでしょう。bugtraq のメールを単に転送することは やめてください。なぜならこれをすでに受けとっているからです。しかし、 追加の情報を提供するのはいつでもよい考えです。
Debian Security Team は現在 5 名のメンバーと 2 人の秘書によって 構成されています。Security Team 自体が参加する人を任命します。
いいえ。Debian security team はすべての新パッケージを調べはしませんし、 悪意のある新パッケージを検知するための自動 (lintian) チェックもありません。 なぜならこれらのチェックは自動的に検知するのがほぼ不可能だからです。 しかし、メンテナは Debian に導入されるソフトウェアについて完全に 責任がありますし、公認の開発者によって最初に署名されることなくソフトウェアが 導入されることはありません。メンテナには自分が開発しているソフトウェアを 解析する責任がありますし、メンテナはセキュリティ意識を持っています。
いいえ、残念ながら、Debian Security Team は安定版リリース (非公式には開発版も) および他の古いリリースの両方を扱うことができません。しかし、新しい Debian ディストリビューションがリリースされた直後の一定期間はセキュリティ上の更新が あると期待することができます。
Debian セキュリティマニュアル
v2.4 Tue, 30 Apr 2002 15:41:13 +0200 (翻訳: Thu, 6 Jun 2002)jfs@computer.org
oohara@libra.interq.or.jp