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

Debian セキュリティマニュアル
第 4 章 - インストール後


4.1 LILO または GRUB パスワードを設定する

ブートプロンプトに 「<name-of-your-bootimage> init=/bin/sh」と 入力することによってだれでも簡単に root のシェルを得てあなたのパスワードを 変更することができます。パスワードを変更してシステムを再起動すれば、 その人は root で無制限にアクセスでき、そのシステムでしたいことが何でも できます。これが行われたあとではあなたは自分のシステムに root でアクセス できないでしょう。というのもあなたには root のパスワードがわからないからです。

これがおこらないようにするには、ブートローダにパスワードを設定するべきです。 グローバルパスワードか、あるイメージに対するパスワードかを選択できます。

LILO では設定ファイル /etc/lilo.conf を 編集して以下の例のように「password」と 「restricted」の行を加える必要があります。

     image=/boot/2.2.14-vmlinuz
        label=Linux
        read-only
        password=hackme
        restricted

これを行ったら、lilo をふたたび実行してください。「restricted」の行をはぶくと LILO に引数が渡されたかどうかにかかわらず lilo がパスワードを要求するように なります。/etc/lilo.conf のデフォルトのパーミッションでは root に読み書きの 許可があり、lilo.conf のグループ、つまり root が読みとりだけ行うことが できます。

LILO のかわりに GRUB を使っていれば、/boot/grub/menu.lst を 編集して次の 2 行を先頭に加えてください。(もちろん「hackme」はお望みの パスワードに置きかえてください。) こうするとユーザがブートアイテムを変更 できなくなります。「timeout 3」は grub がデフォルトのイメージをブートする までの待ち時間を 3 秒に指定します。

     timeout 3
     password hackme

パスワードの完全性をさらに強化するためには、パスワードを暗号化された形で 保存することができます。grub-md5-crypt というユーティリティは grub の 暗号化パスワードアルゴリズム (md5) と互換性のあるハッシュされたパスワードを 生成します。grub で md5 形式のパスワードを使うことを指定するには、以下の ディレクティブを使ってください:

     timeout 3
     password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0

grub に md5 認証手続きを行うよう指示するために --md5 が追加されています。 与えられているパスワードは hackme の md5 で暗号化されたパスワードです。 平文バージョンを選ぶのより md5 パスワードを使うほうがよりよいです。 grub のパスワードについては grub-doc パッケージにより多くの情報があります。


4.2 カーネルから root プロンプトを削除する

Linux 2.4 カーネルは cramfs ファイルシステムをロードした直後に提示される、 ブート時に root のシェルにアクセスする方法を提供します。管理者が root 権限を持つ実行可能なシェルに入ることを可能にするメッセージが表示されます。 このシェルは自動検出が失敗したときにモジュールを手動でロードするのに 使えます。この動作は initrd の linuxrc のデフォルトの動作です。以下の メッセージが表示されます:

     Press ENTER to obtain a shell (waits 5 seconds)

この動作をやめさせるには /etc/mkinitrd/mkinitrd.conf を変更して こう設定する必要があります:

     # DELAY  The  number  of seconds the linuxrc script should wait to
     # allow the user to interrupt it before the system is brought up
     DELAY=0

そして ramdisk イメージを再生成します。これはたとえばこのようにして行えます:

     # cd /boot
     # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7

あるいは (推奨):

     # dpkg-reconfigure kernel-image-2.4.x-yz

Debian 3.0 woody ではユーザが 2.4 カーネルを (flavors を選んで) インストールできますが、しかしデフォルトのカーネルは (カーネル 2.2 が 移植されていないいくつかのアーキテクチャをのぞいて) 2.2 であることに 注意してください。これをバグと考えるなら、バグ報告の前に Bug 145244 をごらんください。


4.3 フロッピーでのブートを禁止する

バージョン 2.2 より前の Debian でのデフォルトの MBR はふつうのマスター ブートレコードとして働かず、システムに簡単に侵入するための方法を残しています。

このふるまいは次のように入力することで変更できます:

     lilo -b /dev/hda

すると LILO が MBR に置かれます。これは lilo.conf に「boot=/dev/hda」を 加えることによっても行うことができます。MBR プロンプトを完全に停止する ほかの解決策もあります:

     install-mbr -i n /dev/hda

一方で、ほどんどの人が知らないこの「裏口」は何らかの理由ににより インストールで深刻な問題が起きたときにあなたを救うかもしれません。

FIXME これが 2.2 で本当に正しいのか調べる。それともこれは 2.1 なのか? INFO: Debian 2.2 のブートディスクは mbr をインストール「しません」。 LILO だけです。


4.4 コンソールログインのアクセスを制限する

セキュリティポリシーによっては管理者がコンソールから自分のユーザおよび パスワードでシステムにログインして、それから (susudo で) スーパーユーザになることを強制したいかもしれません。 Debian ではこのポリシーは /etc/login.defs ファイル または PAM を使うときは /etc/securetty を編集することによって 実施できます。

PAM を使うときはある時刻でのユーザやグループの制限を含むログイン過程の 変更は /etc/pam.d/login で設定できます。停止できる 興味深い機能は空の (空白の) パスワードでログインできる機能です。 この機能は次の行から nullok を削除することによって制限できます:

     auth       required   pam_unix.so nullok

4.5 パーティションを正しくマウントする

ext2 パーティションをマウントするとき、マウントの呼びだしまたは /etc/fstab に適用できる追加のオプションがいくつかあります。 たとえば、/tmp についての私の fstab の行は:

     /dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2

オプションの項目にちがいがあるのがわかるでしょう。nosuid オプションは setuid と setgid ビットを完全に無視します。noexec はその マウントポイントでのどんなプログラムの実行も禁止します。そして nodev はデバイスを無視します。これはよさそうですが、しかしこれは

noexecオプションはバイナリが直接実行されるのを防ぎますが、簡単に 回避されます:

     alex@joker:/tmp# mount | grep tmp
     /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
     alex@joker:/tmp# ./date
     bash: ./date: Permission denied
     alex@joker:/tmp# /lib/ld-linux.so.2 ./date
     Sun Dec  3 17:49:23 CET 2000

しかし、多くの script kiddie は /tmp にファイルを 作って実行しようとする 攻撃を行います。script kiddie に知識がなければ、この落とし穴に落ちるでしょう。 言いかえれば、たとえば偶然 /tmp を PATH に加えてしまったとき、 ユーザが だまされて /tmp にあるトロイの木馬化されたバイナリを 実行してしまうことが ありえなくなります。

/tmp が実行可能であることに依存するスクリプトが あるかもしれないことにも 注意してください。特筆するべきは Debconf にこれに関する問題がある (あった?) ということです。くわしくは Bug 116448 をごらんください。

以下はより完全な例です。しかし、注意があります: /var は noexec に 設定できますが、Smartlist などのソフトウェアはそのプログラムを /var に 保存します。これは nosuid オプションにもあてはまります。

     /dev/sda6       /usr            ext2    defaults,ro,nodev       0       2
     /dev/sda12      /usr/share      ext2    defaults,ro,nodev,nosuid        0     2
     /dev/sda7       /var            ext2    defaults,nodev,usrquota,grpquota 0    2
     /dev/sda8       /tmp            ext2    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
     /dev/sda9       /var/tmp        ext2    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
     /dev/sda10      /var/log        ext2    defaults,nodev,nosuid,noexec    0     2
     /dev/sda11      /var/account    ext2    defaults,nodev,nosuid,noexec    0     2
     /dev/sda13      /home           ext2    rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota                0       2
     /dev/fd0        /mnt/fd0        ext2    defaults,users,nodev,nosuid,noexec 0  0
     /dev/fd0        /mnt/floppy     vfat    defaults,users,nodev.nosuid,noexec 0  0
     /dev/hda        /mnt/cdrom      iso9660 ro,users,nodev.nosuid,noexec  0       0

4.5.1 /tmp を noexec に設定する

/tmp を noexec に設定して新しいソフトウェアを実行したいときは 注意してください。なぜなら、ソフトウェアの中には /tmp を インストールに使うものがあるかもしれないからです。適切に APT::ExtractTemplates::TempDir (apt-extracttemplates(1) をごらんください) が設定されていなければ、apt は そのようなプログラムのひとつです (http://bugs.debian.org/116448 を ごらんください)。/etc/apt/apt.conf 中のこの変数を /tmp 以外の実行権限がついた他のディレクトリに設定することが できます。

noexec については、これはそれほどセキュリティを提供するわけではないことに 注意してください。これを考えてください:

     $ cp /bin/date /tmp
     $ /tmp/date
     (does not execute due to noexec)
     $/lib/ld-linux.so.2 /tmp/date
     (works since date is not executed directly)

4.5.2 /usr を読みとり専用に設定する

/usr を読みとり専用に設定するとあなたの Debian GNU/Linux システムに新パッケージをインストールすることができなくなります。まずそれを 読み書き両用で再マウントし、パッケージをインストールして読みとり専用で 再マウントする必要があるでしょう。apt の (Debian 3.0 「woody」にある) 最新版は パッケージのインストール前後にコマンドを実行するように設定できます。 したがってこれを適切に設定したくなるかもしれません。

これを行うには /etc/apt/apt.conf を変更して以下を 追加してください:

       DPkg
       {
           Pre-Invoke  { "mount /usr -o remount,rw" };
           Post-Invoke { "mount /usr -o remount,ro" };
       };

Post-Invoke が 「/usr busy」エラーメッセージとともに失敗するかもしれない ことに注意してください。これは主に更新されるファイルを更新中に使っている ときにおこります。いらいらしますが大した問題ではありません。そのファイルが 使われていないようにして Post-Invoke を手動で実行してください。


4.6 セキュリティ上の更新を実行する

パッケージにあるセキュリティ関連の新しいバグが明らかになるとすぐに、 Debian のメンテナと上流開発者はふつうそれを数日あるいは数時間以内に 修正します。バグが修正されると、新パッケージが http://security.debian.org で提供されます。sources.list に次の 行を加えるとシステムを更新するたびにセキュリティ関連の更新を自動的に 行えます。

     deb http://security.debian.org/debian-security stable/updates main contrib non-free

強力な暗号を輸入したり使用したりすることを禁止する国には住んでいない人たちは 次の行も加えるべきです:

     deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free

もし望むなら、apt に deb-src の行も加えることができます。くわしくは apt(8) をごらんください。

セキュリティ上の更新はひんぱんに行うべきです。攻撃の大部分はパッチを あてていない既知の脆弱性によるものです。これは http://www.cs.umd.edu/~waa/vulnerability.html name="paper by Bill Arbaugh"> (presented on the 2001 IEEE Symposium on Security and Privacy) で説明されている通りです。

FIXME: これを cron job で自動的に行えるように、パッケージの署名が どうやって行われているかについての情報を加える。(大きな警告: DNS のまね)


4.7 ユーザアクセスを設定する


4.7.1 ユーザ認証: PAM

PAM (Pluggable Authentication Modules) は アプリケーションがユーザをどうやって認証するかをシステム管理者が 選ぶことを可能にします。アプリケーションが PAM をサポートするように コンパイルされていないと PAM は何もできないことに注意してください。 Debian 2.2 で出荷されているアプリケーションの大半はこのサポートが組みこまれて います。さらに Debian は 2.2 以前には PAM のサポートがありませんでした。 各アプリケーションに対して /etc/pam.d/ の中に設定ファイルが あります。これを使って動作を変えることができます。以下の説明は完全には ほど遠いものです。くわしくは The Linux-PAM System Administrator's Guide (primary PAM distribution site にあります) をごらんください。

PAM はユーザに知られることなくいくつかの認証の段階を一度に行うことを 可能にします。Berkeley データベースと通常の passwd ファイルで認証することが できます。両方で正しく認証された場合のみユーザはログインします。PAM で きつく制限することもできますし、システムを非常に広く開放することもできます。 だから注意してください。典型的な設定行にはコントロールフィールドが 2 番目の要素としてあります。 一般的にこれは「requisite」に設定するべきです。これはモジュールがひとつでも 失敗すればログイン失敗を返します。

最初に行いたいことは PAM アプリケーションに MD5 サポートを加えることです。 なぜならこれは辞書攻撃を防ぐのを助けるからです。以下の 2 行を /etc/pam.d/ の 中の loginssh のような、マシンへのアクセスを認める すべてのファイルに加えるべきです。

     # Be sure to install libpam-cracklib first or you will not be able to log in
     password   required     pam_cracklib.so retry=3 minlen=12 difok=3
     password   required     pam_unix.so use_authtok nullok md5

それで、この呪文は何をするのでしょうか? 最初の行は cracklib PAM モジュールを ロードします。これはパスワードの強度のチェックを行えるようにし、 新パスワードは長さが 12 文字以上でかつ古いパスワードとすくなくとも 3 文字以上 異なっていることを要求します。2 番目の行は MD5 パスワードの標準的な認証 モジュールを導入して長さ 0 文字のパスワードを許可します。use_authtok ディレクティブはパスワードを前のモジュールに渡すのに必要です。

root ユーザはローカル端末からしかログインできないようにするには、 /etc/pam.d/login で以下の行を有効にするべきです。

     auth     requisite  pam_securetty.so

そして root ユーザがシステムにログインできる端末を /etc/security/access.conf に加えるべきです。最後だからといって 重要でないというわけではありませんが、もしユーザ制限を設定したいなら 以下の行を有効にするべきです。

     session  required   pam_limits.so

これはユーザが使えるシステム資源を制限します。以下にある limits.conf ファイル, 第 4.7.2 節 をごらんください。 たとえば、(あるユーザグループの、またはシステム全体の) 同時に行える ログインの個数、プロセスの個数、メモリの大きさなどを制限できます。

ここで /etc/pam.d/passwd を編集して最初の行を変更しましょう。 MD5 パスワードを使うために「md5」オプションを加え、パスワードの長さの 最小値を 4 から 6 (あるいはそれ以上) に変更し、もし望むなら長さの最大値を 設定するべきです。するとその行はこのようになります。

     password   required   pam_unix.so nullok obscure min=6 max=11 md5

あなたのシステム上である人たちだけが su を使って root になれるように su を 守りたいならば、「wheel」グループをあなたのシステムに加える必要があります (これが最もきれいなやり方です。というのもまだどのファイルもそのような グループのパーミッションを持っていないからです)。root やその他の root ユーザに 「su できる」べきユーザをこのグループに加えてください。 そして以下の行を /etc/pam.d/su に加えます:

     auth        requisite   pam_wheel.so group=wheel debug

これは wheel グループの人だけが root になるために su を 使えるようにします。他のユーザは root になることができません。実際、 もしその人たちが root になろうとすると拒否のメッセージを受けとることに なります。

特定のユーザだけを PAM サービスで認証したいならば、これはログインすることが 許可されている (もしくは許可されていない) ユーザが記録されているファイルを 使うことで簡単に達成できます。ユーザ「ref」だけが ssh 経由でログインできる ようにしたいとしましょう。そこで ref を /etc/sshusers-allowed に 加え、以下の内容を /etc/pam.d/ssh に書くわけです:

     auth        required    pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail

最後だからといって重要でないというわけではありませんが、 /etc/pam.d/other を作成して以下の行を入力しましょう:

     auth     required       pam_securetty.so
     auth     required       pam_unix_auth.so
     auth     required       pam_warn.so
     auth     required       pam_deny.so
     account  required       pam_unix_acct.so
     account  required       pam_warn.so
     account  required       pam_deny.so
     password required       pam_unix_passwd.so
     password required       pam_warn.so
     password required       pam_deny.so
     session  required       pam_unix_session.so
     session  required       pam_warn.so
     session  required       pam_deny.so

これらの行は PAM をサポートするすべてのアプリケーションに対しよい デフォルトの設定を提供します (デフォルトではアクセスは拒否されます)。


4.7.2 limits.conf ファイル

このファイルは本当に真剣に調べるべきです。ここでユーザの資源の制限を 定義することができます。もし PAM を使うならば、 /etc/limits.conf は無視されるので、かわりに /etc/security/limits.conf を使うべきです。

FIXME: ここでよい limits.conf をしあげる


4.7.3 /etc/login.defs を編集する

次の段階はユーザログインに際しての基本的な設定や行動を編集することです。

     FAIL_DELAY          10

力まかせでログインするのに端末を使うのをむずかしくするためこの変数は 大きな値に設定するべきです。もしまちがったパスワードが入力されると、 攻撃者 (あるいは一般ユーザ!) は次のログインプロンプトを受けるのに 10 秒 待たなければなりません。パスワードをためしているときにはこれは非常に時間を 消費するでしょう。たとえば mingetty などの、getty 以外のプログラムを 使用しているときにはこの設定は役に立たないという事実に注意してください。

     FAILLOG_ENAB        yes

この変数が設定されていると、ログインの失敗がログに記録されます。力まかせの 攻撃をためしている人をつかまえるために失敗を追跡することは重要です。

     LOG_UNKFAIL_ENAB    yes

変数「FAILLOG_ENAB」を yes に設定したら、この変数も yes に設定するべきです。 これはログインが失敗したとき未知のユーザ名を記録します。これを行うなら、 ログが適切なパーミッション (たとえば 640 で、adm などの適切なグループ設定を 行っているもの) を持っているようにしてください。なぜならユーザはしばしば まちがってパスワードをユーザ名として入力しますし、あなたはそれを他の人に 見られたくないからです。

     SYSLOG_SU_ENAB      yes

これは su の試みを syslog に記録するようにします。重要なマシン上では 非常に大切ですが、これはプライバシー問題をひきおこすかもしれないことに 注意してください。

     SYSLOG_SG_ENAB      yes

SYSLOG_SU_ENAB と同じですが sg プログラムに適用されます。

     MD5_CRYPT_ENAB      yes

上で述べたように、MD5 sum のパスワードは辞書攻撃の問題を非常に減らします。 なぜならより長いパスワードを使えるからです。 もし slink を使っているなら、このオプションを有効にする前に MD5 についての 文書を読んでください。そうでないなら、これは PAM で設定されています。

     PASS_MAX_LEN        50

もし PAM の設定で MD5 パスワードが有効になっているなら、この変数をそこで 用いたのと同じ値に設定するべきです。


4.7.4 /etc/ftpusers を編集する

このファイルは ftp を使ってホストにログインすることが許可されていない ユーザのリストを含みます。ftp を本当に許可したいときだけこのファイルを 使ってください (一般に ftp は推奨されていません。なぜならこれは平文の パスワードを使うからです)。あなたのデーモンが PAM をサポートしているなら、 特定のサービスをユーザに許可したり拒否したりするのにそれを使うことも できます。


4.7.5 su を使う

パッケージをインストールするとかユーザを追加するとかのためにあなたの システムで本当にスーパーユーザになる必要があるなら、身分を変更するために su コマンドを使うことができます。root ユーザでのログインを 避けてかわりに su を使うべきです。実際、最良の解決法は su を削除して sudo に移行することです。なぜならこれは su より多くの機能を 持つからです。しかし、su は他の多くの Unixes でより一般的です。


4.7.6 sudo を使う

sudo はユーザが root を含む他のユーザの身分で定義されたコマンドを 実行することを可能にします。もしユーザが /etc/sudoers に 追加されていて、認証が正しく行われれば、/etc/sudoers で定義された コマンドを実行することができます。パスワードをまちがえたり許可のない プログラムを実行しようとしたりといった違反は記録され root にメールで 送られます。


4.7.7 ユーザを制限する

サービス (pop3 メールサービスや ftp) を提供するためにローカルシステムに ユーザを作成する必要があると思うことがあるかもしれません。そうする前に、 Debian GNU/Linux での PAM の実装は libpam パッケージによって提供される いろいろな外部のディレクトリサービス (radius や ldap など) でユーザを 認証することができることを思い出してください。

ユーザを作成する必要があって、リモートからシステムにアクセスできるなら、 そのユーザがシステムにログインできるかもしれないことを考慮してください。 そのユーザに空の (/dev/null) シェル (/etc/shells 中に記載されている必要があります) を与えることによってこれを修正できます。 ユーザがシステムにアクセスできるようにしたいがその行動を制限したいならば、 /bin/rbash を使うことができます。これは bash で -r オプション (RESTRICTED SHELL bash(1) を ごらんください) を追加するのと等価です。制限されたシェルでも、対話的な プログラム (これはサブシェルの実行を許すかもしれません) にアクセスする ユーザはこの制限をかいくぐることができるかもしれないことに注意してください。

Debian は現時点では pam_chroot モジュールを提供していません (将来は提供されるかもしれません)。かわりにリモートログインを提供する サービス (ssh や telnet) を chroot してください。

ユーザがシステムにアクセスできる時刻を制限したいなら /etc/security/access.conf を必要にあわぜて設定する必要が あるかもしれません。


4.7.7.1 ユーザのための ssh を制限する

Debian の sshd ではユーザの移動をサーバを通して制限することはできません。 なぜなら商用のプログラム (sshd2) が持っている Chroot 機能 (「ChrootGroups」 または 「ChrootUsers」を使います。sshd2_config(5) を ごらんください) がないからです。しかし、これを可能にするパッチがあります。 このパッチは Bug report 139047 または http://www.cag.lcs.mit.edu/~raoul/ から入手できます (そして 将来は OpenSSH パッケージにこれが適用されるかもしれません)。Emmanuel Lacour さんはこの機能つきの ssh パッケージを http://debian.home-dn.net/woody/ssh/ に置いていますが、自分で コンパイルすることが推奨されています。必要なすべての手続きの説明が http://mail.incredimail.com/howto/openssh/ にあります (これは RedHat 7.2 について述べていますが、ほどんどすべてが Debian にも 適用可能です)。このパッチを適用したらあとは /etc/passwd を 修正してユーザのホームのパスを変更するだけです (特別な /./ トークンを使います):

     joeuser:x:1099:1099:Joe Random User:/home/joe/./:/bin/bash

これはリモートシェルアクセスおよび ssh チャンネル経由のリモートコピーの 両方を制限します。

必要なバイナリおよびライブラリがすべてユーザの chroot パスの中にあるように してください。これらのファイルはユーザに (chroot の檻から脱出するなどの 目的で) 改ざんされないように root によって所有されるべきです。たとえば 以下が含まるでしょう:

     ./bin:
     total 660
     drwxr-xr-x    2 root     root         4096 Mar 18 13:36 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     -r-xr-xr-x    1 root     root       531160 Feb  6 22:36 bash
     -r-xr-xr-x    1 root     root        43916 Nov 29 13:19 ls
     -r-xr-xr-x    1 root     root        16684 Nov 29 13:19 mkdir
     -rwxr-xr-x    1 root     root        23960 Mar 18 13:36 more
     -r-xr-xr-x    1 root     root         9916 Jul 26  2001 pwd
     -r-xr-xr-x    1 root     root        24780 Nov 29 13:19 rm
     lrwxrwxrwx    1 root     root            4 Mar 30 16:29 sh -> bash
     
     ./etc:
     total 24
     drwxr-xr-x    2 root     root         4096 Mar 15 16:13 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     -rw-r--r--    1 root     root           54 Mar 15 13:23 group
     -rw-r--r--    1 root     root          428 Mar 15 15:56 hosts
     -rw-r--r--    1 root     root           44 Mar 15 15:53 passwd
     -rw-r--r--    1 root     root           52 Mar 15 13:23 shells
     
     ./lib:
     total 1848
     drwxr-xr-x    2 root     root         4096 Mar 18 13:37 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     -rwxr-xr-x    1 root     root        92511 Mar 15 12:49 ld-linux.so.2
     -rwxr-xr-x    1 root     root      1170812 Mar 15 12:49 libc.so.6
     -rw-r--r--    1 root     root        20900 Mar 15 13:01 libcrypt.so.1
     -rw-r--r--    1 root     root         9436 Mar 15 12:49 libdl.so.2
     -rw-r--r--    1 root     root       248132 Mar 15 12:48 libncurses.so.5
     -rw-r--r--    1 root     root        71332 Mar 15 13:00 libnsl.so.1
     -rw-r--r--    1 root     root        34144 Mar 15 16:10
     libnss_files.so.2
     -rw-r--r--    1 root     root        29420 Mar 15 12:57 libpam.so.0
     -rw-r--r--    1 root     root       105498 Mar 15 12:51 libpthread.so.0
     -rw-r--r--    1 root     root        25596 Mar 15 12:51 librt.so.1
     -rw-r--r--    1 root     root         7760 Mar 15 12:59 libutil.so.1
     -rw-r--r--    1 root     root        24328 Mar 15 12:57 libwrap.so.0
     
     ./usr:
     total 16
     drwxr-xr-x    4 root     root         4096 Mar 15 13:00 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     drwxr-xr-x    2 root     root         4096 Mar 15 15:55 bin
     drwxr-xr-x    2 root     root         4096 Mar 15 15:37 lib
     
     ./usr/bin:
     total 340
     drwxr-xr-x    2 root     root         4096 Mar 15 15:55 .
     drwxr-xr-x    4 root     root         4096 Mar 15 13:00 ..
     -rwxr-xr-x    1 root     root        10332 Mar 15 15:55 env
     -rwxr-xr-x    1 root     root        13052 Mar 15 13:13 id
     -r-xr-xr-x    1 root     root        25432 Mar 15 12:40 scp
     -rwxr-xr-x    1 root     root        43768 Mar 15 15:15 sftp
     -r-sr-xr-x    1 root     root       218456 Mar 15 12:40 ssh
     -rwxr-xr-x    1 root     root         9692 Mar 15 13:17 tty
     
     ./usr/lib:
     total 852
     drwxr-xr-x    2 root     root         4096 Mar 15 15:37 .
     drwxr-xr-x    4 root     root         4096 Mar 15 13:00 ..
     -rw-r--r--    1 root     root       771088 Mar 15 13:01
     libcrypto.so.0.9.6
     -rw-r--r--    1 root     root        54548 Mar 15 13:00 libz.so.1
     -rwxr-xr-x    1 root     root        23096 Mar 15 15:37 sftp-server

4.7.8 手製のユーザ監査

もしあなたがパラノイドならシェルから監査機能を削除できないように環境を 設定する .profile をユーザに追加したいかもしれません。 コマンドは $HISTFILE にダンプされます。このような .profile は以下のように設定できます:

     HISTFILE=/home/_user_/.bash_history
     HISTSIZE=100000000000000000
     HISTFILESIZE=10000000000000000
     set -o HISTFILE
     set -o HISTSIZE
     set -o HISTFILESIZE
     export HISTFILE HISTSIZE HISTFILESIZE

注: -o 属性は bash において変数を読みとり専用にします。

これがうまいくいくためにはユーザが .profile または .bash_history を変更できてはいけませんが、 .profile を読むことおよび .bash_history に 書きこむことが可能でなければなりません。これらのファイルおよび これらのファイルがあるディレクトリを他のユーザ (root) が所有するようにして、 そのユーザのグループに history ファイルへの書きこみ許可を与えることによって これを簡単に行えます。他の選択肢は chattr プログラムを使う ことです。

もしあなたが本当にパラノイドですべてのユーザのコマンドを監査したいなら、 bash のソースコードを入手し、それを編集してユーザが打ちこんだものすべてを 他のファイルに送るようにすることができます。または ttysnoop が新しい tty すべてを監視して出力をファイルにダンプするようにするように しましょう。他の役に立つプログラムは Snoopy です。これはユーザ透過性を持つプログラムで、execve() システムコールの ラッパーを提供するライブラリとして働きます。実行されるどのコマンドも authpriv facility (ふつうは /var/log/auth.log に 保存されます)で syslogd を使って記録されます。 !-- FIXME: Debian package for snoopy??? -->

この目的に script コマンドを使うことはできないことに注意して ください。なぜなら script は (たとえ /etc/shells に 追加しても) シェルとしては働かないからです。


4.7.9 ユーザ全体の監査

前の例はユーザ監査を設定する単純な例です。これは複雑なシステムでは役に 立たないかもしれません。もしあなたのシステムがそうなら、アカウント ユーティリティである acctパッケージを検討する必要が あります。これはシステム中のユーザまたはプロセスが実行するすべてのコマンドを ディスクスペースとひきかえに記録します。

アカウンティングを有効にすると、プロセスやユーザのすべての情報は /var/account/ 以下に、特に pacct 中に保存されます。 acctパッケージにはこの情報を解析する道具 (saac) を含みます。


4.7.10 ユーザのプロファイルを調べる

ユーザがふだん何をしているのか見たいなら、そのユーザが接続して いるときに wtmp データベースを使うことができます。これは すべてのログイン情報を含みます。このファイルはいくつかのユーティリティに よって処理できますが、中でも sac は各ユーザごとにシステムに いつログインしているか表示することができます。

アカウンティングを有効にしている場合は、ユーザがシステムにいつアクセスし 何を実行しているか知るためにそれによって提供される道具を使うことができます。


4.8 tcpwrappers を使う

TCP wrapper は本当のパケットフィルタが利用できずアクセス制御が必要だったときに 開発されました。TCP wrapper はサービスをあるホストまたはあるドメインに 許可したり拒否したりし、デフォルトの許可または拒否の規則を定義することを 可能にします。よりくわしく知りたければ hosts_access(5) をごらんください。

Debian でインストールされるサービスの多くは:

/etc/inetd.conf で設定されるサービスがあります。これには telnet、ftp、netbios、swat そして finger が含まれます (この設定ファイルが まず /usr/sbin/tcpd を実行するのがわかるでしょう)。一方で、 サービスが inetd スーパーデーモンを通じて起動されるのでなくても、 tcp wrapper 規則のサポートが組みこまれているとその規則に従います。tcp wrapper が組みこまれている、Debian の サービスは ssh、portmap、in.talk、 rpc.statd、rpc.mountd、gdm、oaf (GNOME 起動デーモン)、nessus その他 いろいろです。

tcpchk を走らせるときはこのことを考慮してください。wrapper ライブラリにリンクされているサービスを host.denyhosts.allow ファイルに追加することができますが、 tcpchk はこれらのサービスを発見できないと警告するでしょう。 というのも tcpchk/etc/inetd.conf を見て これらのサービスをさがすからです (マニュアルページはここでは完全に正確と いうわけではありません)。

ここで、小さなトリックがあります。たぶん利用可能なもののうち最小の侵入検知 システムでしょう。一般に、最初の抵抗線としてよいファイアウォールポリシーを、 2 番目の抵抗線として TCP wrapper を持つべきです。小さなトリックとは 拒否されているサービスが wrapper を呼ぶたびに root にメールを送る SPAWN [1] コマンドを /etc/hosts.deny に設定することです。

     ALL: ALL: SPAWN ( \
       echo -e "\n\
       TCP Wrappers\: Connection refused\n\
       By\: $(uname -n)\n\
       Process\: %d (pid %p)\n\
       User\: %u\n\
       Host\: %c\n\
       Date\: $(date)\n\
     " | /usr/bin/mail -s "Connection to %d blocked" root) &

注意: 上記の例は短時間に大量の接続を行うことによって簡単に DoS されます。大量の電子メールが送られるということはわずか数パケットを 送ることによって大量のファイル入出力を発生させられるということです。


4.9 ログや警告の重要性

ログや警告がどう扱われるかは安全なシステムでは重要な問題です。システムが 完璧に設定されていて、たとえば 99% 安全だとしても、これを理解するのは 簡単です。もし残りの 1% が発生したとき、まずそれを検知し、次に警告を出すような セキュリティ対策があるべき場所になければ、そのシステムは全く安全でない ことになります。

Debian GNU/Linux はログ解析を行う道具をいくつか提供します。最も注目するべきは logcheck です。しかし、 ログの解析についてはここで扱いきれないことがらが多くあります。 Couterpane's Log Analysis Resources はこの情報についての よい供給源です。


4.9.1 警告の送り先を設定する

Debian ではシステムの機能に応じて適切なファイルにメッセージを記録する 標準的な syslog の設定が (/etc/syslog.conf で) 行われています。これらに 詳しくなるべきです。ファイル syslog.conf を見るか、そうしないなら 文書を見てください。もし安全なシステムを維持したいならばメッセージを 見のがさないようそれがどこに送られるかについて知っておくべきです。

たとえば、メッセージをコンソールにも送ることは多くの実用レベルのシステムで 役立つ興味深い設定です。しかしそのような多くのシステムではログホスト (すなわち、他のすべてのシステムからログを受けとるマシン) として働く 新しいマシンを追加することも重要です。

root へのメールも検討するべきです。(snort のような) 多くのセキュリティ制御ソフトは警告を root のメールボックスに送ります。 このメールボックスはふつうシステムで最初に作られたユーザを指しています (/etc/aliases を調べてください)。 root のメールをちゃんと読まれる場所 (ローカルでもリモートでも) に送るように注意してください。

他にも役割のあるアカウントやエイリアスがシステムにはあります。小さな システムでは、これらのエイリアス全てが root アカウントをさすようにし、 root へのメールがシステム管理者の個人メールボックスに転送されるように するのがたぶん最も簡単でしょう。

FIXME: Debian システムがセキュリティ問題に関する SNMP トラップを送ったり 受けとったりする方法を述べるのは興味深いだろう (jfs)。 snmptraglogdsnmp そして snmpd 参照。


4.9.2 ログホストを使う

ログホストは syslog のデータをリモートからネットワーク経由で集めるホストです。 もしあなたのマシンのひとつがクラックされたら、ログホストもクラックしない かぎり侵入者は痕跡を隠すことができません。したがって、ログホストは特に安全で ある必要があります。マシンをログホストにするのは簡単です。syslogd を 「syslogd -r」で開始するだけで新しいログホストのできあがりです。 これを Debian 上で永続的に行うためには、/etc/init.d/sysklogd を 編集して

     SYSLOGD=""

という行を

     SYSLOGD="-r"

に変えてください。 次に、他のマシンをログホストにデータを送るように設定します。 /etc/syslog.conf に以下のような項目を加えます:

     facility.level            @your_loghost

facilitylevel のかわりに何を使うべきかは文書を 見てください (これらを文字どおりこのまま入力するべきではありません。) 何もかもリモートで記録したいならば、単に syslog.conf にこう書くだけです:

     *.*                       @your_loghost

ローカルとともにリモートでも記録することが最良の解決策です (攻撃者は ローカルのログファイルを削除したあとで痕跡を隠したと思うかもしれません)。 よりくわしくは syslog(3), syslogd(8) そして syslog.conf(5) をごらんください。


4.9.3 ログファイルのパーミッション

警告がどう使われるかを決めることだけでなく、だれがそれにアクセスできるか、 すなわちログファイルを読んだり (もしリモートのログファイルを使っていないなら) 変更したりできるかを決めるのも重要です。攻撃者が変更したり停止したり できるようなセキュリティ上の警告は侵入の際にはそれほど役に立ちません。

ログファイルの中にはインストール後にパーミッションが完璧ではないものが あります。最初に /var/log/lastlog/var/log/faillog が一般ユーザに読める必要はありません。 lastlog ファイルではだれが最近ログインしたかわかります。そして faillog では 失敗したログインの要約を見ることができます。このマニュアルの著者はこの両方を 660 に chmod することを推奨します。ログファイルをすこしながめて、 どのログファイルを UID が 0 でないユーザや「adm」でも「root」でもない グループが読んだり書きこんだりできるようにするか非常に注意深く決めてください。

apache のユーザが apache のログファイルを所有しているという事実によって apache のログファイルのパーミッションが本当に変になっていることを強調して おきます。ユーザが apache の裏口でシェルを入手したら、簡単にログファイルを 削除することができます。


4.10 setuid チェックを設定する

Debian は 毎日実行される cron job を /etc/cron.daily/standard で 提供しています。この cron job は setuid の変化を保存する /usr/sbin/checksecurity スクリプトを実行します。 このチェックを行うためには /etc/checksecurity.confCHECKSECURITY_DISABLE="FALSE" を設定しなければなりません。 これはデフォルトなので、何も変更していなければ、このオプションはすでに 「FALSE」に設定されていることに注意してください。

デフォルトのふるまいではこの情報をスーパーユーザに送りはしませんが、 この変化の毎日の記録を /var/log/setuid.changes に保存します。 この情報を root に送るために (/etc/checksecurity.conf 中の) CHECKSECURITY_EMAIL を「root」に設定するべきです。設定についてくわしくは checksecurity(8) をごらんください。


4.11 chroot を使う

chroot はデーモンやユーザやその他のサービスを制限するための 最も強力な可能性のひとつです。対象のまわりに檻があると考えてください。 対象はここから逃げることができません (ふつうはできませんが、このような 檻がら逃げだすことを可能にする条件はいくつもあります)。もしユーザを信用 しないのであれば、そのユーザのために chroot された環境を作ることができます。 檻の中にライブラリとともに必要な実行ファイルをすべてコピーしなければ ならないので、これはディスクスペースを大量に消費するかもしれません。 たとえそのユーザが何か悪事をはたらいても、被害の範囲はその檻に限定されます。

このような場合のよい例には /etc/passwd ではなくかわりに LDAP または MySQL で認証する場合です。すると ftp デーモンにはバイナリと もしかしたらいくつかのライブラリだけが必要です。chroot された環境は 非常にセキュリティを向上させるでしょう。もしこの ftp デーモンに新しい攻撃が 発見されても、攻撃者は ftp デーモンのユーザの UID だけしか攻撃できません。

もちろん、他の多くのデーモンにもこの種の設定が役に立つでしょう。

しかし、chroot はそこで動いているユーザがスーパーユーザなら 破られる可能性があることに注意してください。だから、サービスは非特権ユーザと して動かす必要があります。環境を制限することによってそのサービスが アクセスできる、世界中から読める (または実行できる) ファイルを制限して いることになります。こうしてあなたのシステムにあるローカルのセキュリティ上の 脆弱性を使った、権限の昇進の可能性を制限するわけです。この場合でも、 かしこい攻撃者がこの檻を破る方法が全くないとは言えません。安全だという 評判があるサーバプログラムだけを使うのは安全のための追加の手段としてよいです。 オープンファイルハンドルのような非常に小さなセキュリティホールでも 熟練した攻撃者によってシステムを破るのに使われる可能性があります。 結局、chroot はセキュリティ関連の道具としてではなく試験用の 道具として設計されたのです。

つけくわえますが、Debian のデフォルトの BIND (インターネットネームサービス) は デフォルトでは chroot されていません。実際、どのデーモンも chroot されて いません。これは woody (3.0) リリースで変わるかもしれません。

chroot 環境を設定するのを助けるソフトも存在します (現時点では Debian には 入っていませんが、将来はパッケージ化されるかもしれません)。たとえば、 makejail は chroot の檻を短い設定ファイルを使って作ったり 更新したりできます。またこれはデーモンに必要なファイルをすべて推測して 檻の中へインストールしようとします。くわしくは http://www.floc.net/makejail/ をごらんください。 Jailerhttp://www.balabit.hu/downloads/jailer/ で 入手できる似たような道具です。


4.12 カーネルの設定


4.12.1 カーネルのネットワーク機能を設定する

FIXME: 中身が足りない

カーネルの機能の多くは /proc ファイルシステムの中に 何かを echo で入力するか sysctl を使うかすることによって稼働中に変更することができます。 sysctl -A と入力することにより何が設定できてオプションは何なのかを 知ることができます。ここで何かを編集する必要はめったにありませんが、 このようにしてセキュリティを向上させることもできます。

     net/ipv4/icmp_echo_ignore_broadcasts = 1

これは「windows エミュレータ」です。なぜならこれが 1 に設定されていれば ブロードキャスト ping に windows のように反応するからです。 それ以外なら何もしません。

     net/ipv4/icmp_echo_ignore_all = 0

ファイアウォールで ICMP をブロックしたくないなら、これを有効にしてください。

     net/ipv4/tcp_syncookies = 1

これは両刃の剣です。一方でこれは syn flooding からあなたのシステムを 守ります。一方でこれは定義された規格 (RFC) に違反します。このオプションは あなたの側と同じように反対側にも洪水を送り、反対側もビジー状態にするので とても頭が悪いです。もしこのオプションを変更したいのであれば、 /etc/network/optionssyncookies=yes を設定することに よってこれを変更することもできます。

     /proc/sys/net/ipv4/conf/all/log_martians = 1

あなたのネットワーク上の (まちがった経路のせいで) ありえないアドレスを 持ったパケットが記録されます。

これやその他の役に立つものを設定するための例がこれです。これを /etc/network/interface-secure (この名前は例としてあげられて います) 中のスクリプトに追加し、それを /etc/network/interfaces からこのように呼び出すべきです:

     auto eth0
     iface eth0 inet static
             address xxx.xxx.xxx.xxx
             netmask 255.255.255.xxx
             broadcast xxx.xxx.xxx.xxx
             gateway xxx.xxx.xxx.xxx
             pre-up /etc/network/interface-secure
     # Script-name: /etc/network/interface-secure
     # Modifies some default behaviour in order to secure against 
     # some TCP/IP spoofing & attacks
     #
     # Contributed by Dariusz Puchalak  
     #
     echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
                                                # broadcast echo protection enabled
     echo 0 > /proc/sys/net/ipv4/ip_forward     # ip forwarding disabled
     echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookie protection enabled
     echo 1 >/proc/sys/net/ipv4/conf/all/log_martians 
                                                # Log packets with impossible addresses
                              # but be careful with this on heavy loaded web servers
     echo 1 > /proc/sys/net/ipv4/ip_always_defrag 
                                                #  defragging protection always enabled
     echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses 
                                                # bad error message protection enabled
     
     # now ip spoofing protection
     for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
             echo 1 > $f
     done
     
     # and finally some more things:
     # Disable ICMP Redirect Acceptance
     for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
             echo 0 > $f
     done
     
     for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
           echo 0 > $f
     done
     
     # Disable Source Routed Packets
     for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
             echo 0 > $f
     done
     
     # Log Spoofed Packets, Source Routed Packets, Redirect Packets
     for f in /proc/sys/net/ipv4/conf/*/log_martians; do
             echo 1 > $f
     done

4.12.2 ファイアウォール機能を設定する

ローカルシステムかそれの背後にあるシステムを守るために ファイアウォール機能を使うためには、カーネルにファイアウォール機能を含めて コンパイルする必要があります。標準の Debian 2.2 カーネル (これも 2.2 です はパケットフィルタ ipchains ファイアウォールを提供します。 Debian 3.0 の標準のカーネル (カーネル 2.4) は状態ごとの (stateful) パケットフィルタ iptables (netfilter) ファイアウォールを 提供します。古い Debian ディストリビューションは適切なカーネルパッチを 必要とするでしょう (Debian 2.1 はカーネル 2.0.34 を使っています)。

いずれの場合も、Debian によって提供されるカーネル以外のカーネルを使うのは とても簡単です。Debian システムに簡単にインストールできるコンパイルずみの カーネルがパッケージとして存在します。kernel-source-X を 使ってカーネルソースをダウンロードし、make-kpkg を 使って特製のカーネルパッケージを作ることもできます。

Debian でのファイアウォール構築は ファイアウォール機能を追加する, 第 5.15 節 でよりくわしく 論じられています。


4.13 カーネルパッチを追加する

FIXME: もっと内容を

Debian GNU/Linux はセキュリティを向上させる Linux カーネルのパッチを いくつか提供しています。これには以下が含まれます。


4.14 ファイルの安全な転送

あるホストから他のホストへファイルを安全な方法でコピーするのは ssh パッケージ中に含まれる「scp」を使うことによって達成できます。これは rcp と 同様に働きますが、完全に暗号化されて働きます。よって悪人には「何を」コピー しているのかさえわかりません。


4.15 ファイルシステムの制限と制御


4.15.1 quota を使う

よい quota ポリシーを持つことは重要です。なぜならそれはユーザがハード ディスクをいっぱいにするのを防ぐからです。

2 種類の異なる quota システムを使うことができます: ユーザ quota とグループ quota です。ご想像のとおり、ユーザ quota はユーザが占めることができる スペースの量を制限し、グループ quota は同じことをグループに対して行います。 quota の大きさを決めるときにはこれに注意してください。

quota システムを設定するときに考えるべき重要な点がいくつかあります:

ユーザが自由に書きこむことができるパーティション (またはディレクトリ) の すべてで quota を有効にするべきです。そういうパーティションやディレクトリを 発見して、有用性とセキュリティを兼ねそなえるような、うまくいく quota の 大きさを計算しましょう。

それで、quota を使いたいわけです。最初にあなたのカーネルで quota サポートが 有効になっているか調べる必要があります。もしそうなっていないなら、カーネルを 再コンパイルする必要があるでしょう。 そのあとで、「quota」パッケージがインストールされているか制御してください。 もしインストールされていないならこれも必要です。

それぞれのファイルシステムで quota を有効にするのは簡単で、ファイル /etc/fstab 中の defaults という設定を defaults,usrquota に変更するだけです。グループ quota が必要なら、 usrquotagrpquota に置きかえてください。両方を使うことも できます。そして quota を使いたいファイルシステムのルートに空の quota.user および quota.group というファイルを作成してください (たとえば、 /home ファイルシステムでは touch /home/quota.user /home/quota.group とするわけです)。

/etc/init.d/quota stop;/etc/init.d/quota start を行うことによって quota を再起動してください。すると quota が動いて、quota の大きさが 設定できるようになるはずです。

特定のユーザ (たとえば「ref」)の quota を編集することは edquota -u ref で可能です。グループ quota は edquota -g <group> で変更できます。そして必要に応じて ソフト quota およびハード quota、そして (または) inode quota を設定して ください。

quota についてくわしくは quota のマニュアルページや quota mini-howto (/usr/share/doc/HOWTO/en-html/mini/Quota.html)をごらんください。

lshell をすきになるかどうかは人それぞれでしょう。 なぜならこれは FHS に違反しているからです。pam_limits.so が同じ機能を 提供するかもしれないこと、lshell が現在 orphaned であることも 考慮に入れてください。


4.15.2 chattr および lsattr

この 2 種類のコマンドはとても便利ですが、ext2 ファイルシステムでしか 働きません。「lsattr」でファイルの属性を表示させることができます。そして 「chattr」で属性を変更できます。この属性はパーミッションとは異なることに 注意してください。属性はたくさんありますが、セキュリティを向上させるのに 最も重要なものだけがここで言及されています。スーパーユーザだけが設定できる フラグが 2 種類あります。

まず「a」フラグがあります。ファイルにこれが設定されていると、そのファイルは 追加するためだけにしか開けなくなります。これは /var/log/ 中のファイルの いくつかには便利ですが、それらのファイルはログ回転スクリプトによってときどき 移動されることを考えるべきです。

2 番目のフラグは「i」フラグです。これは immutable の略です。ファイルにこれが 設定されていると、それは変更することも削除することも名前を変えることも できなくなり、それへのリンクも作れなくなります。ユーザに設定ファイルを 調べられたくなければこのフラグを設定して読みとり許可を取りのぞくことが できます。さらにこれは侵入者に対してすこしだけセキュリティを向上させます。 なぜなら、クラッカーはファイルを削除できないことによって混乱するかも しれないからです。それにもかかわらず、クラッカーの目が節穴であると 考えるべきではありません。結局、そのクラッカーはあなたのシステムに 侵入したのです。

lsattr と chattr は ext2 ファイルシステムでのみ利用可能なことに 注意してください。


4.15.3 ファイルシステムの完全性を確かめる

あなたのハードドライブにある /bin/login は 本当に数か月前にインストールした バイナリと同じですか? もしそれが入力されたパスワードを隠しファイルに 保存したり平文でインターネットじゅうにメールで送る、ハックされたバージョンなら どうでしょうか?

保護のためのただひとつの方法はそのファイルの実際の md5sum と古い md5sum を 比較して毎時間 (または毎日、または毎月) (私は毎日がすきです) ファイルを 調べることです。異なる 2 個のファイルが同じ md5sum を持つことはありえません (MD5 ダイジェストは 128 ビットです。よって 2 個の異なるファイルが同じ md5sum を持つ確率はおよそ 3.4e3803 にひとつです)。よって、 だれかがそのマシンで md5sum を作るアルゴリズムをハックしたのでないかぎり、 あなたは安全な場所にいることになります。これは、まあ、とても困難で、まず ありえないでしょう。このバイナリの監査は非常に重要だと 本当に考えるべきです。なぜならこれはバイナリへの変更を認識する簡単な 方法だからです。これに使われる一般的な道具は sXidAIDE (Advanced Intrusion Detection Environment)、TripWire (non-freeです。新バージョンは GPL になる予定です)、 integrit そして samhainです。

debsums をインストールすることもすべてのファイルの md5sum を Debian パッケージアーカイブで使われる md5sum と比較することによって ファイルシステムの完全性を調べるのに役立ちます。しかし注意してください、 このファイルは簡単に変更できます。

さらに locateslocate で置きかえる こともできます。slocate はセキュリティを向上させた GNU locate です。 slocate を使うと、ユーザは自分がアクセスできるファイルだけしか見ることが できず、システム上の任意のファイルやディレクトリを除外できます。


4.16 setuid チェックを設定する

Debian は 毎日実行される cron job を /etc/cron.daily/standard で 提供しています。この cron job は setuid の変化を保存する /usr/sbin/checksecurity スクリプトを実行します。 このチェックを行うためには /etc/checksecurity.confCHECKSECURITY_DISABLE="FALSE" を設定しなければなりません。 これはデフォルトなので、何も変更していなければ、このオプションはすでに 「FALSE」に設定されていることに注意してください。

デフォルトのふるまいではこの情報をスーパーユーザに送りはしませんが、 この変化の毎日の記録を /var/log/setuid.changes に保存します。 この情報を root に送るために (/etc/checksecurity.conf 中の) CHECKSECURITY_EMAIL を「root」に設定するべきです。設定についてくわしくは checksecurity(8) をごらんください。


4.17 推奨されている他の事項


4.17.1 svgalib に依存するソフトウェアを使わない

私のようにコンソールが好きな人にとっては SVGAlib はとてもよいですが、以前に これは非常に危険であると何回か証明されています。zgv に対する 攻撃が公表されましたし、root になるのは非常に簡単だったのです。可能ならば SVGAlib プログラムを使うのはいつも避けるべきです。


[ 前のページ ] [ 目次 ] [ 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