あなたのコンピュータにオペレーティングシステムをインストールする前に、 BIOS のパスワードを設定し、ブートの順番を変更してフロッピーや cdrom などの ブートするべきではないデバイスからのブートを 禁止しましょう。そうしないとクラッカーはあなたのシステム全体にアクセス するために物理的に接触できてブートディスクを持っていさえすればいいことに なります。
パスワードなしでのブートを禁止するのはよりよいです。サーバを動かすなら これはとても有効でしょう。なぜならサーバが再起動することはそれほど多く ないからです。この方策の欠点は再起動に人がかかわる必要があるということです。 マシンに簡単に接触できるわけではないときはこれは問題をおこすかもしれません。
かしこいパーティション構造はマシンがどう使われるかに依存します。一般に よい規則はパーティションを切るのに偏見を持たず、以下の点に注意することです:
/home
や /tmp
のような、
ユーザが書きこみ権限を持つ
ディレクトリ木は別個のパーティションであるべきです。これは 「/」 の
マウントポイントをいっぱいにしてシステムを利用できなくするユーザ DoS の
リスクを減らします。(注: これは厳密には正しくありません。というのも、
一般のユーザが書きこめないスペースが root 用にいつも予約されているからです。)
/var
(とくに /var/log
) のような
変動しやすいパーティションも別個の パーティションであるべきです。 Debian
システムでは、 /var をいつもより
やや広く作るべきです。なぜなら、ダウンロードされたパッケージ (apt の
キャッシュ) が /var/apt/cache/archives
に保存されるからです。
これはメールサーバではより重要です (/var/mail
および / または
/var/spool/mail
)。なぜならリモートのユーザがメールスプールを
(知っているにせよ、知らないにせよ) 故意にいっぱいにする可能性があるからです。
/opt
または /usr/local
です。もしこれらが別個の パーティションならば、Debian 自体を再インストールする
(しなければならない) ときに消去されずにすみます。
インストールしようとしているシステムをインストール中にすぐにインターネットに 接続するべきではありません。これはばかげているように聞こえるかもしれませんが、 普通に行われていることです。システムはサービスをインストールするとすぐに それを有効にするので、もしそのシステムがインターネットに接続されていて、 サービスが適切に設定されていなければ、システムを攻撃にさらしていることに なります。
サービスにはインストールに使おうとしているパッケージではまだ修正されて いないセキュリティ上の脆弱性があるかもしれないことにも注意してください。 (CD-ROM のような) 古いメディアからインストールしようとしているときに これがよくあてはまります。この場合、インストールを終える前にシステムを 破られることさえあり得ます!
Debian のインストールやアップグレードはインターネット経由でも可能なので、
インストール時にこの機能を使うのはよい考えに思えるかもしれません。
システムをインターネットに直接接続する予定なら (そしてファイアウォールや NAT
で保護しないなら)、インターネットに接続せずに、Debian パッケージソースや
セキュリティ上の更新のローカルミラーを使ってインストールするのが最善です。
パッケージミラーはインターネットに接続された他のシステムを使い、(もし Debian
システムであれば) apt-move
や apt-proxy
などの Debian
特有の道具か、またはシステムに
アーカイブを提供する他の一般的なミラーツールを用いて設置することができます。
root のよいパスワードを設定することは安全なシステムを得る上で最も 基礎的な必要事項です。
インストールの最後に、shadow パスワードを有効にするべきか聞かれます。
パスワードを /etc/shadow
というファイルに保存するために。
この質問にはいと答えましょう。root ユーザと shadow グループだけが
このファイルを読むことができるので、どのユーザもパスワードクラッカーを
ためすためにこのファイルを入手することができません。shadow パスワードと
通常のパスワードは shadowconfig を使うことによっていつでも
切りかえることができます。さらにインストール中 MD5 でハッシュされた
パスワードを使いたいか聞かれます。MD5 ではより長いパスワードを使うことができ、
暗号化がよりすぐれているので、これはふつうとてもよい考えです。
Shadow パスワードについてさらに知るには Shadow
Password
(/usr/share/doc/HOWTO/en-txt/Shadow-Password.txt.gz
)
を読みましょう。
サービスとは ftp サーバや web サーバなどのプログラムのことです。これらは サービスを要求する外部からの接続を待ちうけなければならないので、 外部のコンピュータがあなたのコンピュータに接続することができます。サービスが 脆弱なことがあるので (すなわち、攻撃で破られる可能性があるので)、 セキュリティリスクになります。
必要のないサービスをあなたのマシンにインストールするべきではありません。 インストールされたどのサービスもあなたのマシンに新しい、明らかでは ないかもしれないが確かなセキュリティホールを作るかもしれません。
すでにごぞんじのように、あるサービスをインストールするとそれを起動するのが デフォルトです。サービスがインストールされていない、 Debian の デフォルトのインストールでは、動いているサービスの形跡はきわめてすくないです。 ネットワークで提供されているサービスについて言えばさらにすくないです。 Debian 2.1 での形跡は Debian 2.2 ほどはしっかりしていませんでしたし(inetd サービスのいくつかがデフォルトで有効になっていました。)、Debian 2.2 では rpc portmapper がインストール時に有効です。rpc は NFS などの多くのサービスを システム上で動かすのに必要なのでデフォルトでインストールされます。しかし、 それは簡単に削除できます。それを停止する方法については デーモンサービスを停止する, 第 3.6.1 節 をごらんください。
ネットワーク関連の新サービス (デーモン) を Debian GNU/Linux にインストール
するときに、2 通りの方法で有効にすることができます。inetd スーパーデーモンを
通して有効にするか (つまり、/etc/inetd.conf
に一行加える
わけです)、自分自身をネットワークインターフェイスにバインドする独立した
プログラムとして有効にするかです。独立型のプログラムは /etc/init.d
中のファイルを通じて制御されます。これはブート時に SysV 機構 (またはその代替物)
を通じて /etc/rc?.d/*
中の シンボリックリンクを使って
呼びだされます (これがどのように行われるかに ついてくわしくは
/usr/share/doc/sysvinit/README.runlevels.gz
をごらんください)。
もしあるサービスがほしいがそれをめったに使わないならば、それを 起動プロセスから削除するために「update-inetd」や「update-rc.d」のような update コマンドを使いましょう。
デーモンサービスを停止するのはとても簡単です。いくつかの方法があります:
/etc/rc${runlevel}.d/
からリンクを削除するか、または
リンクの名前を (「S」ではじまらないように) 変える
/etc/init.d/_service_name_
) を 他の名前
(たとえば /etc/init.d/OFF._service_name_
) に変える
/etc/init.d/_service_name_
ファイルから実行ビットを 取りのぞく
/etc/init.d/_service_name_
スクリプトを編集して
ただちに終了するようにする
/etc/rc${runlevel}.d/
からリンクを削除するのは手動でもできますし、
update-rc.d を使って行うこともできます
(update-rc.d(8)
をごらんください)。たとえば、
マルチユーザランレベルであるサービスが実行されるのを停止するには
update-rc.d stop XX 2 3 4 5 .
とします。
file-rc
を使っていないなら、 update-rc.d -f
_service_ remove はうまくいかないことに
注意してください。すべてのリンクが削除されるので、その
パッケージを再インストールまたはアップグレードするときにリンクが再度
生成されます (これはたぶんあなたが望んでいることではないでしょう)。
これが直観的でないと思うなら、それはたぶん正しいでしょう (Bug 67095
をごらんください)。
マニュアルページによると:
ファイル /etc/rcrunlevel.d/[SK]??name がすでに存在する場合には、 update-rc.d は何もしない。これは、システム管理者が ひとつでもリンクを残していた場合に、その設定を上書きされる ことがなく、別の場所に移動させることができるようにするためである。
file-rc
を使っているなら、サービス起動に関するすべての
情報は共通の設定ファイルで扱われ、たとえパッケージがシステムから削除されても
維持されます。
rcconf
によって提供される TUI (Text User Interface) を
使うことによってこれらの変更すべてを容易に行うことができます
(rcconf
は file-rc と普通の System V runlevel の両方で使えます)。
(おすすめはできませんが) サービスを停止する他の方法は: chmod 644
/etc/init.d/daemon (でもこれはブート時にエラーメッセージを 出します)
か、または /etc/init.d/daemon
スクリプトを (先頭に exit
0
の行を加えるか、start-stop-daemon の
部分をコメントアウトするかして) 変更することです。init.d ファイルは
設定ファイルなので、アップグレード時に上書きされません。
残念ながら、他の (UNIX) オペレーティングシステムとは異なり、Debian の
サービスを /etc/default/_servicename_
中のファイルを変更する
ことによって停止することはできません。
FIXME: file-rc を使ってデーモンを制御することについてさらに多くの 情報を加える。
あなたのシステム上の echo、chargen、discard、daytime、time、talk、ntalk そして「非常に」危険だと考えられている r サービス群 (rsh、rlogin と rcp。 かわりに ssh を使いましょう) などのような不要なサービスをすべて停止する べきです。これらを停止したあとで、inetd デーモンが本当に必要なのか 確かめるべきです。多くの人は inetd 経由でサービスを呼びだすよりデーモンを 使うほうを好みます。inetd にはサービス否定攻撃の可能性がありますし、 サービス否定攻撃はマシンの負荷を非常に増加させます。それでも inetd サービスを動かしたいならば、xinetd や rlinetd のようなよりくわしく設定できる inet デーモンに移行しましょう。
/etc/inetd.conf
を直接編集することによってサービスを停止する
ことができますが、Debian にはこれを行うよりよい他の方法があります:
update-inetd です
(これはサービスを再び有効にしやすい形でコメントに
します)。たとえば、設定ファイルを変更するためにこの コマンドを実行して telnet
デーモンを削除し、inet デーモンを再起動する ことができます。(この場合、telnet
サービスが停止されます。)
/usr/sbin/update-inetd --disable telnet
サービスが要求を受けつけるようにはしたいが、すべての IP アドレスからの
要求を受けつけることは望まない場合は、文書に書かれていない inetd の機能を
使いたくなるかもしれません。 あるいは、xinetd
のようなかわりの
inetd デーモンを使いましょう。
勧告やリリースされたパッケージへの修正が Debian security team によって 発表される debian-security-announce メーリングリストや、Debian の セキュリティ関連についての議論に参加できる debian-security@lists.debian.org を のぞいてみるのは決して悪いことではありません。
重要なセキュリティ上の更新についての警告を受けとるためには、subject 行に
「subscribe」と書いた電子メールを debian-security-announce-request@lists.debian.org
に 送りましょう。この査読されているメーリングリストは http://www.debian.org/MailingLists/subscribe
のウェブページからも 講読することができます。
このメーリングリストは非常に量がすくないです。そしてこれを講読することにより Debian ディストリビューション のセキュリティ上の更新についてただちに警告を 受けることができます。これによりセキュリティ上のバグが修正された 新パッケージをすぐにダウンロードできます。これは安全なシステムを維持するのに 非常に重要なことです。(これを行う方法の詳細については セキュリティ上の更新を実行する, 第 4.6 節を ごらんください。)
Debian セキュリティマニュアル
v2.4 Tue, 30 Apr 2002 15:41:13 +0200 (翻訳: Thu, 6 Jun 2002)jfs@computer.org
oohara@libra.interq.or.jp