<chapt>まえがき
<p>
セキュリティ関連の文書を書くときに最もむずかしいのはどの事例も唯一であると
いうことです。あなたが注意しなければならないのは脅威となる環境とそれぞれの
サイト、ホスト、ネットワークのセキュリティの必要性です。たとえば、家庭の
ユーザのセキュリティの必要性は銀行のネットワークとは全く異なります。家庭の
ユーザが直面する必要がある主要な脅威は script kiddie タイプの
クラッカーですが、銀行のネットワークはねらいうちの攻撃について心配しなければ
なりません。さらに、銀行は顧客の情報を数学的な正確さで守らなければ
なりません。要するに、どのユーザも有用性と安全性 (またはパラノイア) との
かねあいを考えなければならないのです。
<!--
Is this metaphor really appropriate? Sounds like rounding errors to me, era
-->
<p>
このマニュアルはソフトウェア関連の問題しか扱っていないことに注意してください。
だれかが物理的にマシンに接触できるなら世界最良のソフトウェアでもあなたを
守ることができません。マシンを机の下に置くこともできますし、軍隊が守っている
強化された掩蔽壕に設置することもできます。それにもかかわらず、ある
デスクトップマシンが適切に設定されていて、物理的に保護されているあるマシンが
セキュリティホールだらけだとしたら、デスクトップマシンのほうが物理的に
保護されているマシンより (ソフトウェアの観点では) はるかに安全ということも
ありえます。明らかに、どちらの問題についても考えなければなりません。

<p>
この文書はあなたの Debian GNU/Linux システムのセキュリティを高める
ためにできることの概略を述べるだけです。Linux のセキュリティに関する
ほかの文書を読んだことがあるなら、この文書と重なる共通の問題があるのに
気づくでしょう。しかし、この文書はあなたが使う情報源の決定版たることを
めざしているわけではありません。その同じ情報を Debian GNU/Linux システムに
とって意味があるように適応させようとしているだけです。ディストリビューション
ごとにあつかい方が異なる物事もあります。(デーモンの起動法がよくある例です。)
ここには Debian のやり方や道具に適した資料があります。
<!-- 
# Does this approximate the intent of the original author? (FIXME: check)
# Original text said: "you will find here [sic] a different approach,
# using Debian's tools, regarding security." era
-->
<!-- IMHO yes, jfs -->

<p>
感想、追加点や提案がありましたら、
<!--
<url name="Alexander Reelsen" id="mailto:ar@rhwd.de"> や
-->
<url name="Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a" id="mailto:jfs@computer.org">
(または: jfs@debian.org) に
電子メールで送ってください。そうすればそれをこのマニュアルの中に取り入れる
でしょう。

<sect>このマニュアルをダウンロードする
<p>
Debian セキュリティマニュアルの最新版は
<url name="Debian Documentation Project"
id="http://www.debian.org/doc/manuals/securing-debian-howto/"> で
ダウンロードしたり閲覧したりすることができます。<url name="CVS server"
id="http://cvs.debian.org/ddp/manuals.sgml/securing-howto/?cvsroot=debian-doc">
からバージョン管理システムをチェックアウトすることもできます。

<p>
Debian Documentation's Project のウェブサイトからはこの文書の別の形式
(PDF やテキスト) をダウンロードすることはできません。しかし、HTML、テキスト
および PDF 形式のこの文書を含む <url id="http://packages.debian.org/harden-doc"
name="harden-doc"> をダウンロードしたりインストールしたりすることができます。

<!-- 
<p>
Previous (out of date) versions of this HOWTO can be found here:

<list>
<item><url name="Text-only"
id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Securing-Debian-HOWTO.txt">
<item><url name="HTML"
id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Securing-Debian-HOWTO.html">
<item><url name="HTML, tarred and gzipped"
id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/
Securing-Debian-HOWTO.tar.gz">
<item><url name="SGML"
id="http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Securing-Debian-HOWTO.sgml">
</list>
-->
<!-- TODO: remove these stale links rather than leave references to -->
<!-- the old versions hanging around? era -->


<sect>組織化についてのメモおよび感想
<p>
公的な話にうつります。現時点では私 (Alexander Reelsen) がこのマニュアルの
大部分を書いています。でも私の考えではこのままでいるべきではありません。
私はフリーソフトウェアとともに成長し生活しています。フリーソフトウェアは
私が毎日使うものの一部ですし、あなたが毎日使うものの一部でもあると思います。
だれでも感想、追加のヒントやその他の提案があればぜひ私に送ってください。

<p>
ある章や段落をよりうまく開発することができると思うなら、この文書のメンテナに
メールを書いていただければ、そうしていただいてかまいません。特に FIXME と
印のついている章があれば、それは著者に時間がないか、著者がその話題について
必要とされる知識を持っていないということです。すぐに著者にメールを送って
ください。

<p>
このマニュアルの話題から明らかなように、このマニュアルを最新の状態に保つのは
重要です。あなたも協力できます。貢献してください。

<sect>前提となる知識
<p>
Debian GNU/Linux のインストールはそれほどむずかしくありませんし、あなたは
きっとインストールできているはずです。Linux やその他の Unix の知識があって、
セキュリティの基礎を知っていれば、このマニュアルを理解するのはより
容易でしょう。というのも、この文書で物事のあらゆる細部を説明することは
不可能だからです。
(そうでないとこれはマニュアルではなく一冊の本になってしまうでしょう。)
しかし、もしそれほどくわしくなければ、より深い情報をどこで見つけたらいいか
知るために <ref id="references"> を見たくなるかもしれません。

<sect>書くべきこと (FIXME/TODO)
<p>
<list>

<item>
Debian GNU/Linux を使ってファイアウォールを構築する方法に
ついての情報を加える。ファイアウォールについての章は今のところ
一台だけのシステム向けだ (他のマシンを守るわけではない...)

<item>どのパッケージがプロキシサービスを提供するかを明記しつつ
Debian GNU/Linux でプロキシファイアウォールを構築することに
ついての情報を加える
(<package>xfwp</package>、
<package>xproxy</package>、<package>ftp-proxy</package>、 
<package>redir</package>、
<package>smtpd</package>、<package>nntp-cache</package>、
<package>dnrd</package>、
<package>jftpgw</package>、<package>oops</package>、<package>pdnsd</package>、
<package>perdition</package>、<package>transproxy</package>、
<package>tsocks</package>など)。他の情報についてはそのマニュアルを
示すべきだ。zorp は (まだ) Debian パッケージとして入手可能ではないが、
これはプロキシファイアウォール<em>である</em>ことも述べるべきだ
(上流は Debian パッケージを提供している)。

<item>file-rc でのサービス設定についての情報

<item>参照している URL をすべて調べて、もう有効でないものを削除するなり
修正するなりする

<item>
一般的なサーバについて、限定された機能に役立つ (Debian で) 利用可能な代替物に
ついての情報を加える。たとえば:
  <list>
  <item>ローカル lpr のかわりに cups (パッケージ)?

  <item>リモート lrp のかわりに lpr

  <item>bind のかわりに dnrd/maradns

  <item>apache のかわりに dhttpd/thttpd/wn (tux?)

  <item>exim/sendmail のかわりに ssmtpd/smtpd/postfix

  <item>squid のかわりに tinyproxy

  <item>ftpd のかわりに oftpd/vsftp

  <item>...

  </list>

<item>Debian のセキュリティ関連のカーネルパッチについて、それを紹介すると
ともにそれらのパッチを Debian システムでどう有効にするかを特に述べた情報を
さらに多く。

<list>

<item>Linux Intrusion Detection (<package>lids-2.2.19</package>)

<item>Linux Trustees (<package>trustees</package>パッケージ中)

<item><url name="NSA Enhanced Linux"
id="http://www.coker.com.au/selinux/">

<item><url name="kernel-patch-2.2.18-openwall"
id="http://packages.debian.org/kernel-patch-2.2.18-openwall">

<item><package>kernel-patch-2.2.19-harden</package>

<item>Linux capabilities (<package>lcap</package> パッケージ中)

<item><package>kernel-patch-freeswan、kernel-patch-int</package>

</list>

<item>不要なネットワークサービスを切ることの詳細 (inetd のほかに)。
強化過程の一部だがすこし広くできるかも。

<item>ポリシーと密接に関連したパスワード回転についての情報。

<item>ポリシー、そしてユーザに対するポリシー教育。

<item>tcpwrappers についてさらに、そして wrapper 一般?

<item><file>hosts.equiv</file> そしてその他のセキュリティホール。

<item>suidmanager/dpkg-statoverrides。

<item>lpr と lprng。

<item>gnome の IP 関連を停止すること。

<item>pam_chroot (<url id="http://lists.debian.org/debian-security/2002/debian-security-200205/msg00011.html">
を参照) およびそれがユーザを制限するのに役に立つことについて述べる。
<url id="http://online.securityfocus.com/infocus/1575"> に関連する情報を
紹介する。たとえば <package>Pdmenu</package> は Debian で利用可能だ
(flash はまだだが)。

<item>サービスを chroot することについて述べる。
<url id="http://www.linuxfocus.org/English/January2002/aritcle225.shtml">、
<url id="http://www.networkdweebs.com/chroot.html"> そして
<url id="http://www.linuxsecurity.com/feature_stories/feature_story-99.html">
についてより多くの情報を。

<item>chroot の檻を作るためのプログラムについて述べる。
<package>Compartment</package> と <package>chrootuid</package> が
incoming に入っている。他にもいくつか (makejail、jailer) 紹介できるだろう。

<item>Karl Hegbloom さんによって提供された、Bind 9 を chroot することに
関する情報を追加する。
<url id="http://people.pdxlinux.org/~karlheg/Secure_Bind9_uHOWTO/Secure_Bind_9_uHOWTO.xhtml">
参照。

<item>
Pedro Zornenon さんによって提供された、Bind 8 を chroot することに
関する情報を追加する。potato 用限定だけれど :(。
<url id="http://people.debian.org/~pzn/howto/chroot-bind.sh.txt"> 参照
(スクリプト全体を含める?)。

<item>ログ解析ソフトウェアに関するより多くの情報 (すなわち、logcheck や
logcolorise)。
</list>

<sect>Changelog/History
 <p>

<sect1>dated Thu,  6 Jun 2002
<p>Changes by Oohara Yuuma
<list>
<item>New upstream version (version 2.4, cvs revision 1.57).
</list>

<sect1>Version 2.3
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>
<item>Wrapped most file locations with the file tag.
<item>Fixed typo noticed by Edi Stojicevi.
<item>Slightly changed the remote audit tools section.
<item>Added some todo items.
<item>Added more information regarding printers and cups config file
(taken from a thread on debian-security).
<item>Added a patch submitted by Jesus Climent regarding access of
valid system users to Proftpd when configured as anonymous server.
<item>Small change on partition schemes for the special case of mail
servers.
<item>Added Hacking Linux Exposed to the books section.
<item>Fixed directory typo noticed by Eduardo P&eacute;rez Ureta.
<item>Fixed /etc/ssh typo in checklist noticed by Edi Stojicevi.
</list>

<sect1>Version 2.3
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>
<item>Fixed location of dpkg conffile.
<item>Remove Alexander from contact information.
<item>Added alternate mail address.
<item>Fixed Alexander mail address (even if commented out).
<item>Fixed location of release keys (thanks to Pedro Zorzenon for pointing this out).
</list>

<sect1>dated Sat, 27 Apr 2002
<p>Changes by Oohara Yuuma
<list>
<item>New upstream version (version 2.2, cvs revision 1.53).
<item>The changelog for "dated Fri, 26 Apr 2002" had a typo ---
it was based on cvs revision 1.51, not 1.31 .
</list>

<sect1>dated Fri, 26 Apr 2002
<p>Changes by Oohara Yuuma
<list>
<item>New upstream version (version 2.1, cvs revision 1.31).
<item>Fixed a broken tag.
</list>

<sect1>Version 2.2
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>
<item>Fixed typos, thanks to Jamin W. Collins.
<item>Added a reference to apt-extracttemplate manpage
(documents the APT::ExtracTemplate config).
<item>Added section about restricted SSH. Information based on that
posted by  Mark Janssen, Christian G. Warden and Emmanuel Lacour on
the debian-security mailing list.
<item>Added information on antivirus software.
<item>Added a FAQ: su logs due to the cron running as root.
</list>

<sect1>Version 2.1
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>
<item>Changed FIXME from lshell thanks to Oohara Yuuma.
<item>Added package to sXid and removed comment since it *is* available.
<item>Fixed a number of typos discovered by Oohara Yuuma.
<item>ACID is now available in Debian (in the acidlab package)
 thanks to Oohara Yuuma for noticing.
<item>Fixed LinuxSecurity links (thanks to Dave Wreski for telling).
</list>

<sect1>dated Sat, 23 Mar 2002
<p>Changes by Oohara Yuuma
<list>
<item>New upstream version (version 2.0, cvs revision 1.49).
<item>Fixed broken tags.
</list>

<sect1>Version 2.0
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a. I wanted to 
change to 2.0 when all the FIXMEs were, er, fixed but I run out
of 1.9X numbers :(
<list>
<item>Converted the HOWTO into a Manual (now I can properly say RTFM)

<item>Added more information regarding tcp wrappers and Debian (now
many services are compiled with support for them so it's no longer
an inetd issue).

<item>Clarified the information on disabling services to make it more
consistent (rpc info still refered to update-rc.d)

<item>Added small note on lprng.

<item>Added some more info on compromised servers (still very rough)

<item>Fixed typos reported by Mark Bucciarelli.

<item>Added some more steps in password recovery to cover the cases
when the admin has set paranoid-mode=on.

<item>Added some information to set paranoid-mode=on when login in
console.

<item>New paragraph to introduce service configuration.

<item>Reorganised the <em>After installation</em> section so it is
more broken up into several issues and it's easier to read.

<item>Written information on howto setup firewalls with the standard
Debian 3.0 setup (iptables package).

<item>Small paragraph explaining why installing connected to the
Internet is not a good idea and how to avoid this using Debian tools.

<item>Small paragraph on timely patching referencing to IEEE paper.

<item>Appendix on how to setup a Debian snort box, based on what Vladimir
sent to the debian-security mailing list (september 3rd 2001)

<item>Information on how logcheck is setup in Debian and how it can be
used to setup HIDS.

<item>Information on user accounting and profile analysis.

<item>Included apt.conf configuration for read-only /usr copied from Olaf
Meeuwissen's post to the debian-security mailing list

<item>New section on VPN with some pointers and the packages available
in Debian (needs content on how to setup the VPNs and Debian-specific
issues), based on Jaroslaw Tabor's and Samuli Suonpaa's post to
debian-security.

<item>Small note regarding some programs to automatically build chroot jails

<item>New FAQ item regarding identd based on a discussion in the
debian-security mailing list (februrary 2002, started by Johannes Weiss).

<item>New FAQ item regarding inetd based on a discussion in the
debian-security mailing list (february 2002).

<item>Introduced note on rcconf in the "disabling services" section.

<item>Varied the approach regarding LKM, thanks to Philipe Gaspar 

<item>Added pointers to CERT documents and Couterpane resources
</list>

<sect1>dated Tue, 26 Feb 2002
<p>Changes by Oohara Yuuma
<list>
<item>New upstream version (version 1.99, cvs revision 1.45).
</list>

<sect1>dated Sat, 16 Feb 2002
<p>Changes by Oohara Yuuma
<list>
<item>New upstream version (version 1.99, cvs revision 1.41).
</list>

<sect1>dated Tue, 29 Jan 2002
<p>Changes by Oohara Yuuma
<list>
<item>New upstream version (version 1.99, cvs revision 1.39).
<item>Now this translation uses the same title as the original
(I have a permission to do so --- see the sgml source for details)
<item>Replaced the author's name with the correct diacritics.
</list>

<sect1>dated Tue, 15 Jan 2002
<p>Changes by Oohara Yuuma
<list>

<item>New upstream version (version 1.99, cvs revision 1.36).
<item>Fixed a typo.
</list>

<sect1>Version 1.99
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>
<item>Added a new FAQ item regarding time to fix security vulnerabilities.
<item>Reorganised FAQ sections.
<item>Started writing a section regarding firewalling in Debian GNU/Linux
(could be broadened a bit)
<item>Fixed typos sent by Matt Kraai
<item>Fixed DNS information
<item>Added information on whisker and nbtscan to the auditing section.
<item>Fixed some wrong URLs
</list>

<sect1>Version 1.98
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>
<item>Added a new section regarding auditing using Debian GNU/Linux.
<item>Added info regarding finger daemon taken from the security mailing list.
</list>

<sect1>dated Thu, 10 Jan 2002
<p>Changes by Oohara Yuuma
<list>

<item>New upstream version (version 1.97, cvs revision 1.33).

<item>Changed the Japanese word for &quot;Securing&quot; in the title to
clarify its meaning.

<item>Changed the name of the section &quot;History&quot; to
&quot;Changelog/History&quot;, which the upstream uses.

<item>Fixed many typos.

</list>

<sect1>Version 1.97
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>
<item>Fixed link for Linux Trustees
<item>Fixed typos (patches from Oohara Yuuma and Pedro Zorzenon)
</list>

<sect1>dated Thu,  3 Jan 2002
<p>Changes by Oohara Yuuma
<list>

<item>Translated into Japanese.

</list>

<sect1>Version 1.96
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>

<item>Reorganized service installation and removal and added some new notes.

<item>Added some notes regarding using integrity checkers as intrusion
detection tools.

<item>Added a chapter regarding package signatures.

</list>

<sect1>Version 1.95
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>

<item>Added notes regarding Squid security sent by Philipe Gaspar.

<item>Fixed rookit links thanks to Philipe Gaspar.

</list>

<sect1>Version 1.94
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>

<item>Added some notes regarding Apache and Lpr/lpng.

<item>Added some information regarding noexec and readonly partitions.

<item>Rewritten how can users help in Debian security issues (FAQ item).
</list>

<sect1>Version 1.93
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>

<item>Fixed location of mail program.

<item>Added some new items to the FAQ.
</list>

<sect1>Version 1.92
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>

<item>Added a small section on how Debian handles security

<item>Clarified MD5 passwords (thanks to `rocky')

<item>Added some more information regarding harden-X from Stephen van Egmond

<item>Added some new items to the FAQ

</list>

<sect1>Version 1.91
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>

<item>Added some forensics information sent by Yotam Rubin.

<item>Added information on how to build a honeynet using Debian GNU/Linux.

<item>Added some more TODOS.

<item>Fixed more typos (thanks Yotam!)

</list>

<sect1>Version 1.9
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>

<item>Added patch to fix mispellings and some new information (contributed
by Yotam Rubin)

<item>Added references to other online (and offline) documentation both in a section (see <ref id="references">) by itself and inline in some sections.

<item>Added some information on configuring Bind options to restrict
access to the DNS server.

<item>Added information on how to automatically harden a Debian system
(regarding the harden package and bastille).

<item>Removed some done TODOs and added some new ones.

</list>

<sect1>Version 1.8
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>

<item>Added the default user/group list provided by Joey Hess to the
debian-security mailing list.

<item>Added information on  LKM  rootkits (<ref id="LKM">)
 contributed by Philipe Gaspar.

<item>Added information on Proftp contributed by Emmanuel Lacour. 

<item>Recovered the checklist Appendix from Era Eriksson.

<item>Added some new TODO items and removed other fixed ones.

<item>Manually included Era's patches since they were not all included in 
the previous version.

</list>

<sect1>Version 1.7
<p>Changes by Era Eriksson.
<list>
<item>Typo fixes and wording changes <!-- FIXME: new checklist has not
been included yet, era, please send it back -->
</list>
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>
<item>Minor changes to tags in order to keep on removing the tt tags
and substitute them for prgn/package tags.
</list>

<sect1>Version 1.6 
<p>Changes by Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.
<list>
<item>Added pointer to document as published in the DDP (should
supersede the original in the near future) 
<item>Started a mini-FAQ
(should be expanded) with some questions recovered from my mailbox.
<item>Added general information to consider while securing.
<item>Added a paragraph regarding local (incoming) mail delivery.
<item>Added some pointers to more information.  
<item>Added information regarding the printing service.  
<item>Added a security hardening checklist.  
<item>Reorganized NIS and RPC information.
<item>Added some notes taken while reading this document on my new
Visor :) 
<item>Fixed some badly formatted lines.  
<item>Fixed some typos.  
<item>Added a Genius/Paranoia idea contributed by Gaby
Schilders.
</list>

<sect1>Version 1.5

<p>Changes by Josip Rodin and Javier Fern&aacute;ndez-Sanguino Pe&ntilde;a.

<list>
<item>Added paragraphs related to BIND and some FIXMEs.  <!-- Removed
this because I found no evidence for it in the diffs. // era Rewrote
style in order to make it more formal.  -->
</list>

<sect1>Version 1.4
    <p>
    <list>
    <item>Small setuid check paragraph <item>Various minor cleanups
    <item>Found out how to use <tt>sgml2txt -f</tt> for the txt
    version</item>
    </list>
<sect1>Version 1.3
    <p>
    <list>
    <item>Added a security update after installation paragraph
    <item>Added a proftpd paragraph <item>This time really wrote
    something about XDM, sorry for last time
    </list>
<sect1>Version 1.2
    <p>
    <list>
    <item>Lots of grammar corrections by James Treacy, new XDM
    paragraph
    </list>
<sect1>Version 1.1
    <p>
    <list>
    <item>Typo fixes, miscellaneous additions
    </list>
<sect1>Version 1.0
    <p>
    <list>
    <item>Initial release
    </list>

<sect>Credits
<p>
<list>
<item>Alexander Reelsen が原作を書きました。 

<item>Javier Fern&aacute;ndez-Sanguino が原作に情報を追加しました。

<item>Robert van der Meulen が quota の記事と多くのよいアイデアを
提供しました。

<item>Ethan Benson が PAM の記事を訂正して、いくつかのよいアイデアを
提供しました。

<item>Dariusz Puchalak がいくつかの章に情報を提供しました。

<item>Gaby Schilders がすてきな「天才的な (またはパラノイアの)」アイデアを
提供しました。

<item>Era Eriksson が多くの場所で言葉づかいをよくして、付録のチェックリストを
提供しました。

<item>Philipe Gaspar が LKM の情報を書きました。

<item>Yotam Rubin が多くの誤植の修正に貢献するとともに、bind のバージョンや
md5 パスワードについての情報を提供しました。

<item>この文書に (とうとう) 取りいれられた改善を提案したすべての人々。

<item>私 (Alexander) にこの HOWTO (のちにマニュアルへと変更されました) を
書くようすすめたすべての人々。

<item>Debian プロジェクト全体。
</list>

<chapt>はじめる前に

<sect>このシステムの目的は何ですか?
<p>
Debian を安全にするのは他のシステムを安全にするのとそれほどちがいは
ありません。正しく行なうためには、まずそれについて何をするつもりなのかまず
決めなければなりません。そのあとで、もし本当に安全なシステムがほしいなら
以下の作業が必要だということを考えなければならないでしょう。

<p>
このマニュアルはボトムアップで書かれていることに気がつくでしょう。つまり、
Debian システムのインストールが行われる前、インストール中そして
インストール後に行う作業についての情報があるのがわかるでしょう。この作業は
次のように考えられます:

<list>
<item>どのサービスがほしいのか決め、システムをそれに限定しましょう。
これには不要なサービスを止めたりアンインストールしたりすることや、
ファイアウォールのようなフィルタ、tcpwrapper を加えることが含まれます。

<item>提供するサービスを強化して、サービスが破られたとき、システムへの
影響が最小になるようにしましょう。

<item>適切な対策がとれるように、許可されていない使用が発見されることを
確実にするため適切な道具を使いましょう。

</list>

<sect id="references">一般的なセキュリティ問題について知る
<p>
以下のマニュアルではある物事がなぜセキュリティ上のリスクと考えられるかの
詳細には (ふつう) 立ち入りません。しかし、 UNIX 一般や Linux (に特有) の
セキュリティについての背景知識をもっとほしくなるかもしれません。選択肢が
いくつかあるときに知識にもとづいて決定できるようにいくらか時間をかけて
セキュリティ関連の文書を読みましょう。 Debian GNU/Linux は Linux カーネルに
もとづいているので、Linux に関する情報の多くや、他のディストリビューション
そして UNIX 一般のセキュリティの情報が Debian GNU/Linux にもあてはまります。
(使われる道具や利用できるプログラムが異なっていても。)

<p>
役に立つ文書に次のようなものがあります:

<list>

<item> <url name="Linux Security HOWTO"
id="http://www.linuxdoc.org/HOWTO/Security-HOWTO.html">
(<url id="http://www.linuxsecurity.com/docs/LDP/Security-HOWTO.html"
name="LinuxSecurity"> からも入手できます) は Linux の
セキュリティ一般についての最高の参考資料のひとつです。

<item> <url name="Security Quick-Start HOWTO for Linux" 
id="http://www.linuxsecurity.com/docs/LDP/Security-Quickstart-HOWTO/">
も初心者がはじめるにはとてもよいです (Linux 初心者でも、セキュリティ
初心者でも)。

<item> <url id="http://www.seifried.org/lasg" name="Linux Security
  Administrator's Guide"> (Debian では <package>lasg</package> パッケージで
提供されています) は カーネルのセキュリティから VPN まで、Linux の
セキュリティに関するあらゆる問題について触れる完全なガイドです。
これはやや古いですし (1999 年以降更新されていません)、Linux Security
Knowledge Base (現時点ではオンライン上では入手できません。以前は
<url id="http://www.securityportal.com/lskb/"> で可能でした。) にとって
かわられています。これも Debian で <package>lksb</package> パッケージとして
提供されています。

<item>
<url name="Securing and Optimizing Linux: RedHat Edition"
id="http://www.linuxdoc.org/links/p_books.html#securing_linux"> の中には
これと似ているが RedHat 関連の文書があります。その記事のいくつかは
ディストリビューション特有ではなく、 Debian にもあてはまります。

<item>
IntersectAlliance は linux サーバを強化する方法のレファレンスカードとして
使える文書をいくつか公表しました。これは
<url id="http://www.intersectalliance.com/projects/index.html"
name="their site"> で入手できます。

<item>
ネットワーク管理者にとって、安全なネットワークを構築するのによい参考資料は
<url name="Securing your Domain HOWTO"
 id="http://www.linuxsecurity.com/docs/LDP/Securing-Domain-HOWTO/"> です。

<item>あなたが使おうとしているプログラムを評価したいならば (または、
新しいプログラムを作りたいならば)、
<url name="Secure Programs HOWTO"
id="http://www.linuxdoc.org/HOWTO/Secure-Programs-HOWTO.html"> を読むべきです。

<!-- FIXME: check URLs --> 

<item>ファイアウォール機能をインストールすることを考えているなら、
<url name="Firewall HOWTO"
id="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html"> と
<url name="IPCHAINS HOWTO"
id="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html">
を読むべきです。

<item>
最後に、<url name="Linux Security RefenceCard"
id="http://www.linuxsecurity.com/docs/QuickRefCard.pdf"> は
携帯するのによいカードです。

</list>

<p>
どの場合も、ここで説明されているサービス (NFS, NIS, SMB...) に関する
さらなる情報が <url name="Linuxdoc Project" id="http://www.linuxdoc.org/">
の HOWTO の多くの中にあります。これらの文書にはそのサービスのセキュリティ面に
ついて述べているので、そこも見てください。

<p>
Debian GNU/Linux では Linux Documentation Proyect の HOWTO 文書は
<package>doc-linux-text</package> (テキスト版) または
<package>doc-linux-html</package> (html 版) をインストールすることによって
利用可能です。インストール後にこれらの文書はそれぞれ
<file>/usr/share/doc/HOWTO/en-txt</file> および
<file>/usr/share/doc/HOWTO/en-html</file> ディレクトリで利用できます。

<p>
ほかのおすすめの Linux の本:

<list>

<item>Maximum Linux Security : A Hacker's Guide to Protecting Your Linux
  Server and Network.  Anonymous. Paperback - 829 pages. Sams Publishing.
  ISBN: 0672313413. July 1999.

<item>Linux Security By John S. Flowers. New Riders; ISBN: 0735700354
March 1999

<item><url id="http://www.linux.org/books/ISBN_0072127732.html"
name="Hacking Linux Exposed"> By Brian Hatch. McGraw-Hill Higher Education.
ISBN 0072127732. April, 2001

</list>

<p>
他の本 (UNIX やセキュリティの一般的な問題関連で、Linux 特有では
ないかもしれませんが):

<list>

<item><url id="http://www.ora.com/catalog/puis/noframes.html"
        name="Practical Unix and Internet Security (2nd Edition)">
        Garfinkel, Simpson, and Spafford, Gene; O'Reilly Associates;
        ISBN 0-56592-148-8; 1004pp; 1996.

<item>Firewalls and Internet Security Cheswick, William R. and Bellovin,
        Steven M.; Addison-Wesley; 1994; ISBN 0-201-63357-4; 320pp.

</list>

<p>
セキュリティ関連の最新情報を追いかけるのに役にたつウェブサイト:
<list>

<item><url name="Security Focus" id="http://www.securityfocus.com"> は
Bugtraq 脆弱性データベースおよびメーリングリストを運営するサーバです。
セキュリティの一般的な情報、ニュース、報告を提供します。

<item> <url name="Linux Security"
        id="http://www.linuxsecurity.com/">。
Linux のセキュリティ (ツール、ニュース...)  に関する一般的な情報です。
最も役に立つのは <url name="main documentation"
id="http://www.linuxsecurity.com/resources/documentation-1.html">
のページです。

<item> <url name="Linux firewall and security site"
        id="http://www.linux-firewall-tools.com/linux/">。
Linux のファイアウォールやそれをコントルールし管理するための道具に関する
一般的な情報です。

</list>

<sect>Debian はセキュリティをどう扱っていますか?
<p>
Debian GNU/Linux でのセキュリティを概観すれば、全体として安全なシステムを
提供するために Debian が取りくむいろいろな問題に気がつくでしょう。

<list>

<item>Debian の問題はたとえセキュリティに関連していてもつねに公開で
取り組まれます。
<!--
this translation is "official" (that is, quoted from the URL below)
-->
<url name="Debian Social Contract" id="http://www.debian.org/social_conract">
が述べるように、
<em>
私たちは問題を隠しません
バグ報告のデータベース全体を常に一般に公開します。ユーザーが
オンラインで書き込んだバグの報告は、即座に他の人から見えるように
なります。
</em>
セキュリティ問題は debian-security メーリングリストで公開で議論されます。
勧告は (内部および外部の) メーリングリストに投稿され、公開のサーバで
発行されます。

<item>Debian はセキュリティ問題を綿密に調査しています。セキュリティ問題が
あるパッケージが Debian にないかさがすのに security team は
セキュリティ関連の多くの情報を調べています。その中で最も重要なのは
<url name="Bugtraq" id="http://www.securityfocus.com/cgi-bin/vulns.pl">
です。

<item>セキュリティ関連の更新は最優先されます。セキュリティ問題が Debian
パッケージで発生すると、セキュリティ関連の更新が可能なかぎりはやく準備され、
すべてのアーキテクチャで stable および unstable リリース用に配布されます。

<item>セキュリティ関連の情報は一か所に、つまり
<url id="http://security.debian.org/"> に集められています。

<item>Debian はディストリビューション全体のセキュリティを高めようとして、
パッケージの署名を自動的に検証するしくみのような新しいプロジェクトを
いつもはじめています。

<item>Debian はシステム管理や監視のためにセキュリティ関連の道具を十分に
提供しようとしています。ローカルのセキュリティポリシーを守らせるための
よりよい道具にするために開発者はこれらの道具をディストリビューションに
しっかりと統合しようとしています。この道具には次のようなものが含まれます:
完全性のチェッカー、監査ツール、強化用ツール、ファイアウォールツール、
侵入検知ツールなどです。

<item>パッケージメンテナはセキュリティ問題を知っています。そのため
通常の使用に制限をもうけることもあるような「デフォルトで安全な」サービスの
インストールが多くみられることになります。しかし、Debian はセキュリティ問題と
管理のしやすさのバランスを取ろうとしています。システムは他の BSD 系の
ディストリビューションのように停止された状態でインストールされるわけでは
ありません。いずれにせよ、setuid プログラムのような特別なセキュリティ問題は
<url id="http://www.debian.org/doc/debian-policy" name="Debian Policy"> の
一部です。

</list>

<p>
この文書は他の情報 --- Debian で使われている道具やオペレーティングシステム
自体についてのセキュリティ関連の文書 (<ref id="references"> をごらんください )
--- を補完する Debian 特有のセキュリティ情報を公にすることによって
セキュリティの面でよりよいディストリビューションにしようとしています。

<chapt>インストール前およびインストール中

<sect>BIOS のパスワードを選ぶ
<p>
あなたのコンピュータにオペレーティングシステムをインストールする前に、
BIOS のパスワードを設定し、ブートの順番を変更してフロッピーや cdrom などの
ブートするべきではないデバイスからのブートを
禁止しましょう。そうしないとクラッカーはあなたのシステム全体にアクセス
するために物理的に接触できてブートディスクを持っていさえすればいいことに
なります。

<p>
パスワードなしでのブートを禁止するのはよりよいです。サーバを動かすなら
これはとても有効でしょう。なぜならサーバが再起動することはそれほど多く
ないからです。この方策の欠点は再起動に人がかかわる必要があるということです。
マシンに簡単に接触できるわけではないときはこれは問題をおこすかもしれません。

<sect>かしこいパーティション構造を選ぶ
<p>
かしこいパーティション構造はマシンがどう使われるかに依存します。一般に
よい規則はパーティションを切るのに偏見を持たず、以下の点に注意することです:

<list>
<item>たとえば <file>/home</file> や <file>/tmp</file> のような、
ユーザが書きこみ権限を持つ
ディレクトリ木は別個のパーティションであるべきです。これは 「/」 の
マウントポイントをいっぱいにしてシステムを利用できなくするユーザ DoS の
リスクを減らします。(注: これは厳密には正しくありません。というのも、
一般のユーザが書きこめないスペースが root 用にいつも予約されているからです。)

<item><file>/var</file> (とくに <file>/var/log</file>) のような
変動しやすいパーティションも別個の
パーティションであるべきです。 Debian システムでは、 /var をいつもより
やや広く作るべきです。なぜなら、ダウンロードされたパッケージ (apt の
キャッシュ) が <file>/var/apt/cache/archives</file> に保存されるからです。
これはメールサーバではより重要です (<file>/var/mail</file> および / または
<file>/var/spool/mail</file>)。なぜならリモートのユーザがメールスプールを
(知っているにせよ、知らないにせよ) 故意にいっぱいにする可能性があるからです。

<item>ディストリビューションに含まれないソフトウェアをインストールする
パーティションは別個のパーティションであるべきです。File Hierarchy
Standard によると、これは <file>/opt</file> または
<file>/usr/local</file> です。もしこれらが別個の
パーティションならば、Debian 自体を再インストールする (しなければならない)
ときに消去されずにすみます。

<item>セキュリティの観点からは、変化しない情報を独自のパーティションに
動かして、そのパーティションを読みとり専用でマウントしようとするのは意味が
あります。よりよいのは、その情報を読みとり専用のメディア上に置くことです。
くわしくは以下をごらんください。
</list>

<sect>準備ができるまでインターネットに接続しない
<p>
インストールしようとしているシステムをインストール中にすぐにインターネットに
接続するべきではありません。これはばかげているように聞こえるかもしれませんが、
普通に行われていることです。システムはサービスをインストールするとすぐに
それを有効にするので、もしそのシステムがインターネットに接続されていて、
サービスが適切に設定されていなければ、システムを攻撃にさらしていることに
なります。

<p>
サービスにはインストールに使おうとしているパッケージではまだ修正されて
いないセキュリティ上の脆弱性があるかもしれないことにも注意してください。
(CD-ROM のような) 古いメディアからインストールしようとしているときに
これがよくあてはまります。この場合、インストールを終える前にシステムを
破られることさえあり得ます!

<p>
Debian のインストールやアップグレードはインターネット経由でも可能なので、
インストール時にこの機能を使うのはよい考えに思えるかもしれません。
システムをインターネットに直接接続する予定なら (そしてファイアウォールや
NAT で保護しないなら)、インターネットに接続せずに、Debian パッケージソースや
セキュリティ上の更新のローカルミラーを使ってインストールするのが最善です。
パッケージミラーはインターネットに接続された他のシステムを使い、(もし
Debian システムであれば) <package>apt-move</package> や
<package>apt-proxy</package> などの Debian 特有の道具か、またはシステムに
アーカイブを提供する他の一般的なミラーツールを用いて設置することができます。

<sect>root のパスワードを設定する
<p>
root のよいパスワードを設定することは安全なシステムを得る上で最も
基礎的な必要事項です。

<sect>shadow パスワードと MD5 を有効にする
<p>
インストールの最後に、shadow パスワードを有効にするべきか聞かれます。
パスワードを <file>/etc/shadow</file> というファイルに保存するために。
この質問にはいと答えましょう。root ユーザと shadow グループだけが
このファイルを読むことができるので、どのユーザもパスワードクラッカーを
ためすためにこのファイルを入手することができません。shadow パスワードと
通常のパスワードは <tt>shadowconfig</tt> を使うことによっていつでも
切りかえることができます。さらにインストール中 MD5 でハッシュされた
パスワードを使いたいか聞かれます。MD5 ではより長いパスワードを使うことができ、
暗号化がよりすぐれているので、これはふつうとてもよい考えです。

<p>
Shadow パスワードについてさらに知るには <url
name="Shadow Password"
id="http://www.linuxdoc.org/HOWTO/Shadow-Password-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/Shadow-Password.txt.gz</file>)
を読みましょう。

<sect>必要最小限のサービスを走らせる
<p>
サービスとは ftp サーバや web サーバなどのプログラムのことです。これらは
サービスを要求する外部からの接続を<em>待ちうけ</em>なければならないので、
外部のコンピュータがあなたのコンピュータに接続することができます。サービスが
脆弱なことがあるので (すなわち、攻撃で破られる可能性があるので)、
セキュリティリスクになります。

<p>
必要のないサービスをあなたのマシンにインストールするべきではありません。
インストールされたどのサービスもあなたのマシンに新しい、明らかでは
ないかもしれないが確かなセキュリティホールを作るかもしれません。

<p>
すでにごぞんじのように、あるサービスをインストールするとそれを起動するのが
デフォルトです。サービスがインストールされていない、 Debian の
デフォルトのインストールでは、動いているサービスの形跡はきわめてすくないです。
ネットワークで提供されているサービスについて言えばさらにすくないです。
Debian 2.1 での形跡は Debian 2.2 ほどはしっかりしていませんでしたし(inetd
サービスのいくつかがデフォルトで有効になっていました。)、Debian 2.2 では
rpc portmapper がインストール時に有効です。rpc は NFS などの多くのサービスを
システム上で動かすのに必要なのでデフォルトでインストールされます。しかし、
それは簡単に削除できます。それを停止する方法については <ref
id="disableserv"> をごらんください。

<p>
ネットワーク関連の新サービス (デーモン) を Debian GNU/Linux にインストール
するときに、2 通りの方法で有効にすることができます。inetd スーパーデーモンを
通して有効にするか (つまり、<file>/etc/inetd.conf</file> に一行加える
わけです)、自分自身をネットワークインターフェイスにバインドする独立した
プログラムとして有効にするかです。独立型のプログラムは
<file>/etc/init.d</file> 中のファイルを通じて制御されます。これはブート時に
SysV 機構 (またはその代替物) を通じて <file>/etc/rc?.d/*</file> 中の
シンボリックリンクを使って 呼びだされます (これがどのように行われるかに
ついてくわしくは <file>/usr/share/doc/sysvinit/README.runlevels.gz</file>
をごらんください)。

<p>
もしあるサービスがほしいがそれをめったに使わないならば、それを
起動プロセスから削除するために「update-inetd」や「update-rc.d」のような
update コマンドを使いましょう。

<sect1 id="disableserv">デーモンサービスを停止する
<p>
デーモンサービスを停止するのはとても簡単です。いくつかの方法があります:
<list>
<item><file>/etc/rc${runlevel}.d/</file> からリンクを削除するか、または
リンクの名前を (「S」ではじまらないように) 変える

<item>スクリプトファイル (<file>/etc/init.d/_service_name_</file>) を
他の名前 (たとえば <file>/etc/init.d/OFF._service_name_</file>) に変える

<item><file>/etc/init.d/_service_name_</file> ファイルから実行ビットを
取りのぞく

<item><file>/etc/init.d/_service_name_</file> スクリプトを編集して
ただちに終了するようにする

</list>

<p>
<file>/etc/rc${runlevel}.d/</file> からリンクを削除するのは手動でもできますし、
<tt>update-rc.d</tt> を使って行うこともできます
(<manref section="8" name="update-rc.d"> をごらんください)。たとえば、
マルチユーザランレベルであるサービスが実行されるのを停止するには
<example>
update-rc.d stop XX 2 3 4 5 .
</example>
とします。

<p>
<package>file-rc</package> を使って<em>いない</em>なら、
<tt>update-rc.d -f _service_ remove</tt> はうまくいかないことに
注意してください。<em>すべての</em>リンクが削除されるので、その
パッケージを再インストールまたはアップグレードするときにリンクが再度
生成されます (これはたぶんあなたが望んでいることではないでしょう)。
これが直観的でないと思うなら、それはたぶん正しいでしょう
(<url id="http://bugs.debian.org/67095" name="Bug 67095"> をごらんください)。
マニュアルページによると:

<example>
ファイル /etc/rcrunlevel.d/[SK]??name がすでに存在する場合には、
update-rc.d は何もしない。これは、システム管理者が
ひとつでもリンクを残していた場合に、その設定を上書きされる
ことがなく、別の場所に移動させることができるようにするためである。
</example>

<p>
<package>file-rc</package> を使っているなら、サービス起動に関するすべての
情報は共通の設定ファイルで扱われ、たとえパッケージがシステムから削除されても
維持されます。

<p>
<package>rcconf</package> によって提供される TUI (Text User Interface) を
使うことによってこれらの変更すべてを容易に行うことができます
(<prgn>rcconf</prgn> は file-rc と普通の System V runlevel の両方で使えます)。

<p>
(おすすめはできませんが) サービスを停止する他の方法は:
<tt>chmod 644 /etc/init.d/daemon</tt> (でもこれはブート時にエラーメッセージを
出します) か、または <file>/etc/init.d/daemon</file> スクリプトを
(先頭に <prgn>exit 0</prgn> の行を加えるか、<tt>start-stop-daemon</tt> の
部分をコメントアウトするかして) 変更することです。init.d ファイルは
設定ファイルなので、アップグレード時に上書きされません。

<p>
残念ながら、他の (UNIX) オペレーティングシステムとは異なり、Debian の
サービスを <file>/etc/default/_servicename_</file> 中のファイルを変更する
ことによって停止することはできません。

<p>
FIXME: file-rc を使ってデーモンを制御することについてさらに多くの
情報を加える。

<sect1 id="inetd">inetd サービスを停止する
<p>
あなたのシステム上の echo、chargen、discard、daytime、time、talk、ntalk
そして「非常に」危険だと考えられている r サービス群 (rsh、rlogin と rcp。
かわりに ssh を使いましょう) などのような不要なサービスをすべて停止する
べきです。これらを停止したあとで、inetd デーモンが本当に必要なのか
確かめるべきです。多くの人は inetd 経由でサービスを呼びだすよりデーモンを
使うほうを好みます。inetd にはサービス否定攻撃の可能性がありますし、
サービス否定攻撃はマシンの負荷を非常に増加させます。それでも inetd
サービスを動かしたいならば、xinetd や rlinetd のようなよりくわしく設定できる
inet デーモンに移行しましょう。

<p>
<file>/etc/inetd.conf</file> を直接編集することによってサービスを停止する
ことができますが、Debian にはこれを行うよりよい他の方法があります:
<tt>update-inetd</tt> です (これはサービスを再び有効にしやすい形でコメントに
します)。たとえば、設定ファイルを変更するためにこの
コマンドを実行して telnet デーモンを削除し、inet デーモンを再起動する
ことができます。(この場合、telnet サービスが停止されます。)
<example>
/usr/sbin/update-inetd --disable telnet
</example>
<!-- # /etc/init.d/inetd restart Not needed since the manpage says update-inetd
sends a SIGHUP, commented out as suggested by Dariusz Puchalak -->

<p>
サービスが要求を受けつけるようにはしたいが、すべての IP アドレスからの
要求を受けつけることは望まない場合は、文書に書かれていない inetd の機能を
使いたくなるかもしれません。
<!-- FIXME write the information sent
by Alexander to the debian-security mailing list -->
あるいは、<prgn>xinetd</prgn> のようなかわりの inetd デーモンを使いましょう。

<sect>Debian のセキュリティメーリングリストを読む
<p>
勧告やリリースされたパッケージへの修正が Debian security team によって
発表される debian-security-announce メーリングリストや、Debian の
セキュリティ関連についての議論に参加できる debian-security@lists.debian.org を
のぞいてみるのは決して悪いことではありません。

<p>
重要なセキュリティ上の更新についての警告を受けとるためには、subject 行に
「subscribe」と書いた電子メールを
<url name="debian-security-announce-request@lists.debian.org"
id="mailto:debian-security-announce-request@lists.debian.org"> に
送りましょう。この査読されているメーリングリストは
<url name="http://www.debian.org/MailingLists/subscribe"
id="http://www.debian.org/MailingLists/subscribe"> のウェブページからも
講読することができます。

<p>
このメーリングリストは非常に量がすくないです。そしてこれを講読することにより
Debian ディストリビューション のセキュリティ上の更新についてただちに警告を
受けることができます。これによりセキュリティ上のバグが修正された
新パッケージをすぐにダウンロードできます。これは安全なシステムを維持するのに
非常に重要なことです。(これを行う方法の詳細については <ref id="update">を
ごらんください。)

<chapt>インストール後

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

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

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

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

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

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

<example>
timeout 3
password hackme
</example>

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

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

<sect>カーネルから root プロンプトを削除する
<p>
Linux 2.4 カーネルは cramfs ファイルシステムをロードした直後に提示される、
ブート時に root のシェルにアクセスする方法を提供します。管理者が root
権限を持つ実行可能なシェルに入ることを可能にするメッセージが表示されます。
このシェルは自動検出が失敗したときにモジュールを手動でロードするのに
使えます。この動作は initrd の linuxrc のデフォルトの動作です。以下の
メッセージが表示されます:
<example>
Press ENTER to obtain a shell (waits 5 seconds)
</example>

<p>
この動作をやめさせるには <file>/etc/mkinitrd/mkinitrd.conf</file> を変更して
こう設定する必要があります:
<example>
# 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
</example>

<p>
そして ramdisk イメージを再生成します。これはたとえばこのようにして行えます:
<example>
# cd /boot
# mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
</example>

<p>
あるいは (推奨):
<example>
# dpkg-reconfigure kernel-image-2.4.x-yz
</example>

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

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

<list>
<item>ブート時にシフトを押します。すると MBR のプロンプトが現れます。

<item>そして F を押します。するとシステムはフロッピーディスクから起動します。
これはシステムの root アクセスを得るのに使えます。
</list>

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

<example>
lilo -b /dev/hda
</example>

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

<example>
install-mbr -i n /dev/hda
</example>

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

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

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

<list>
<item><file>login.defs</file> では、root でのログインが許可されている
ファイルまたは端末のリストを定義する CONSOLE 変数を編集します。

<item><file>securetty</file> では、root でのアクセスが許可される端末を
追加したり削除したりします。

</list>

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

<example>
auth       required   pam_unix.so nullok
</example>

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

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

<p>
オプションの項目にちがいがあるのがわかるでしょう。<tt>nosuid</tt> オプションは
setuid と setgid ビットを完全に無視します。<tt>noexec</tt> はその
マウントポイントでのどんなプログラムの実行も禁止します。そして
<tt>nodev</tt> はデバイスを無視します。これはよさそうですが、しかしこれは
<list>
<item>ext2 ファイルシステムにしか適用できません
<item>簡単に回避できます
</list>

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

<example>
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
</example>

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

<p>
<file>/tmp</file> が実行可能であることに依存するスクリプトが
あるかもしれないことにも
注意してください。特筆するべきは Debconf にこれに関する問題がある (あった?)
ということです。くわしくは Bug <url
id="http://bugs.debian.org/116448" name="116448"> をごらんください。

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

<!--
some spaces are deleted to fit this into the 80-char column
-->
<example>
/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
</example>

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

<p>
noexec については、これはそれほどセキュリティを提供するわけではないことに
注意してください。これを考えてください:
<!--
second mention of ld.so trick
-->
<example>
$ 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)
</example>

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

<p>
これを行うには <file>/etc/apt/apt.conf</file> を変更して以下を
追加してください:
<example>
  DPkg
  {
      Pre-Invoke  { "mount /usr -o remount,rw" };
      Post-Invoke { "mount /usr -o remount,ro" };
  };
</example>

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

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

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

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

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

<p>
もし望むなら、apt に deb-src の行も加えることができます。くわしくは
<manref name="apt" section="8"> をごらんください。

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

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

<sect>ユーザアクセスを設定する

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

<p>
PAM はユーザに知られることなくいくつかの認証の段階を一度に行うことを
可能にします。Berkeley データベースと通常の passwd ファイルで認証することが
できます。両方で正しく認証された場合のみユーザはログインします。PAM で
きつく制限することもできますし、システムを非常に広く開放することもできます。
だから注意してください。典型的な設定行にはコントロールフィールドが
2 番目の要素としてあります。
<!-- Second in mine (old Debian v2.0 though), check this! (FIXME) (era) -->
一般的にこれは「requisite」に設定するべきです。これはモジュールがひとつでも
失敗すればログイン失敗を返します。
<!-- Lots of fields in mine are "required", please elaborate? (FIXME) (era) -->

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

<example>
# 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
</example>

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

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

<example>
auth     requisite  pam_securetty.so
</example>

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

<!-- FIXME: This is pam.d/login you're talking about, still? Elaborate? era -->
<example>
session  required   pam_limits.so
</example>

<p>
これはユーザが使えるシステム資源を制限します。以下にある
<ref id="user-limits"> をごらんください。
たとえば、(あるユーザグループの、またはシステム全体の) 同時に行える
ログインの個数、プロセスの個数、メモリの大きさなどを制限できます。

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

<example>
password   required   pam_unix.so nullok obscure min=6 max=11 md5
</example>

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

<example>
auth        requisite   pam_wheel.so group=wheel debug
</example>

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

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

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

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

<example>
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
</example>

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

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

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

<sect1>/etc/login.defs を編集する
<p>
次の段階はユーザログインに際しての基本的な設定や行動を編集することです。

<example>
FAIL_DELAY          10
</example>

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

<example>
FAILLOG_ENAB        yes
</example>

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

<example>
LOG_UNKFAIL_ENAB    yes
</example>

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

<example>
SYSLOG_SU_ENAB      yes
</example>

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

<example>
SYSLOG_SG_ENAB      yes
</example>

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

<example>
MD5_CRYPT_ENAB      yes
</example>

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

<example>
PASS_MAX_LEN        50
</example>

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

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

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

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

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

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

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

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

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

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

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

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

<example>
./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
</example>

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

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

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

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

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

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

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

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

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

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

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

<p>
Debian でインストールされるサービスの多くは:
<list>
<item>tcp wrapper サービス (<file>tcpd</file>) を通して起動されるか、
<item>libwrapper をコンパイル時に組みこまれています。
</list>

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

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

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

<example>
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) &
</example>

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

<!--
# Could this example be more interesting? 
# It also relates to the next section (jfs)
#
# era: cf hosts_access(5) manual page,
# and why are you not using logger(1) here? (FIXME?)
#
#&lt;example&gt;
#ALL: ALL: SPAWN ( \
#  /usr/local/sbin/send_syslog %u %c %d )
#&lt;example&gt;

#  With send_syslog as:
##!/usr/bin/perl -w
#
#use Sys::Syslog qw(:DEFAULT setlogsock);
#
#$user=shift(@ARGV) || 'unkown';
#$host=shift(@ARGV) || 'unkown';
#$service=shift(@ARGV) || 'unkown';
#setlogsock('unix');
#openlog("alert",'', 'user');
#syslog('warning', 'Connection from %s at %s to %s blocked.', ($user, $host, $service) );
#closelog();
#
#exit 0;
-->

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

<p>
Debian GNU/Linux はログ解析を行う道具をいくつか提供します。最も注目するべきは
<package>logcheck</package> です。しかし、
ログの解析についてはここで扱いきれないことがらが多くあります。
<url name="Couterpane's Log Analysis Resources"
id="http://www.counterpane.com/log-analysis.html"> はこの情報についての
よい供給源です。

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

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

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

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

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

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

<example>
SYSLOGD=""
</example>
という行を
<example>
SYSLOGD="-r"
</example>
に変えてください。

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

<example>
facility.level            @your_loghost
</example>

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

<example>
*.*                       @your_loghost
</example>

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

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

<!--  It should be explained why after installation this is not
 already done, jfs -->

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

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

<!--
# This is quite personal, IMHO, since this is due to the fact that 
# root priviledges are dropped on startup. I prefer an attacker to erase
# a service's logfiles than to erase all of my system's logs. Anyhow, this
# can be improved by changing user permissions after rotation
-->

<sect>setuid チェックを設定する
<p>
Debian は 毎日実行される cron job を <file>/etc/cron.daily/standard</file> で
提供しています。この cron job は setuid の変化を保存する
<prgn>/usr/sbin/checksecurity</prgn> スクリプトを実行します。

<!-- TODO What is the defaul for this in cron package? jfs -->

このチェックを行うためには <file>/etc/checksecurity.conf</file> で
<tt>CHECKSECURITY_DISABLE="FALSE"</tt> を設定しなければなりません。
これはデフォルトなので、何も変更していなければ、このオプションはすでに
「FALSE」に設定されていることに注意してください。

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

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

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

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

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

<!-- FIXME: this information should be checked when woody gets released -->
<p>
つけくわえますが、Debian のデフォルトの BIND (インターネットネームサービス) は
デフォルトでは chroot されていません。実際、どのデーモンも chroot されて
いません。これは woody (3.0) リリースで変わるかもしれません。

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

<sect>カーネルの設定

<sect1 id="kernel-conf">カーネルのネットワーク機能を設定する
<p>FIXME: 中身が足りない

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

<!-- FIXME: Should the prefix on all of these be /proc/sys/? era -->

<example>
net/ipv4/icmp_echo_ignore_broadcasts = 1
</example>

これは「windows エミュレータ」です。なぜならこれが 1 に設定されていれば
ブロードキャスト ping に windows のように反応するからです。
<!-- Which means what exactly? Simply that it ignores broadcasts? FIXME -->
それ以外なら何もしません。

<example>
net/ipv4/icmp_echo_ignore_all = 0
</example>

<p>
ファイアウォールで ICMP をブロックしたくないなら、これを有効にしてください。
<!--
Does this mean, if you want to block ICMP but not in your firewall? FIXME
-->

<example>
net/ipv4/tcp_syncookies = 1
</example>

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

<example>
/proc/sys/net/ipv4/conf/all/log_martians = 1
</example>

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

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

<example>
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

</example>

<example>
# 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
</example>

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

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

<p>
Debian でのファイアウォール構築は <ref id="firewall-setup"> でよりくわしく
論じられています。

<sect id="kernel-patch">カーネルパッチを追加する
<p>
FIXME: もっと内容を

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

<list>

<item>Linux Intrusion Detection (<package>lids-2.2.19</package> パッケージ中)

<item>Linux Capabilities (<package>lcap</package> パッケージ中)

<item>Linux Trustees (<package>trustees</package> パッケージ中)

<item>NSA Enhanced Linux (<package>selinux</package> パッケージ中。 
<url id="http://www.coker.com.au/selinux/"
name="the developer's website"> からも入手できます。)

<item><url name="kernel-patch-2.2.18-openwall"
id="http://packages.debian.org/kernel-patch-2.2.18-openwall">

<item><package>kernel-patch-2.2.19-harden</package>

<item>Linux capabilities (<package>lcap</package> パッケージ中)

<item>IPSEC kernel support (<package>kernel-patch-freeswan</package>
パッケージ中)
 
<item><package>kernel-patch-int</package>
 
</list>

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

<sect>ファイルシステムの制限と制御
<sect1>quota を使う
<p>
よい quota ポリシーを持つことは重要です。なぜならそれはユーザがハード
ディスクをいっぱいにするのを防ぐからです。

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

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

<list>
<item>quota を十分に小さくして、ユーザがディスクスペースを食いつくさない
ようにしましょう。
<item>quota を十分に大きくして、ユーザが文句を言ったりメール quota の
せいでユーザが長期間メールを受けとれなくなったりしないようにしましょう。
<item>ユーザが書きこめる領域すべてで quota を使いましょう。
<file>/home</file> とともに
<file>/tmp</file> でも。
</list>

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

<p>
それで、quota を使いたいわけです。最初にあなたのカーネルで quota サポートが
有効になっているか調べる必要があります。もしそうなっていないなら、カーネルを
再コンパイルする必要があるでしょう。
<!-- FIXME: how to check for quota support? What to tweak when recompiling? -->
そのあとで、「quota」パッケージがインストールされているか制御してください。 
もしインストールされていないならこれも必要です。

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

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

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

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

<p>
<package>lshell</package> をすきになるかどうかは人それぞれでしょう。
なぜならこれは FHS に違反しているからです。pam_limits.so が同じ機能を
提供するかもしれないこと、<package>lshell</package> が現在
<url id="http://bugs.debian.org/93894" name="orphaned"> であることも
考慮に入れてください。
<!-- Duplicated section "Logfile permissions" removed (era) -->
<!-- Duplicated section "Setting up setuid check" removed (era) -->

<sect1>chattr および lsattr
<p>
この 2 種類のコマンドはとても便利ですが、ext2 ファイルシステムでしか
働きません。「lsattr」でファイルの属性を表示させることができます。そして
「chattr」で属性を変更できます。この属性はパーミッションとは異なることに
注意してください。属性はたくさんありますが、セキュリティを向上させるのに
最も重要なものだけがここで言及されています。スーパーユーザだけが設定できる
フラグが 2 種類あります。
<p>
まず「a」フラグがあります。ファイルにこれが設定されていると、そのファイルは
追加するためだけにしか開けなくなります。これは
<file>/var/log/</file> 中のファイルの
いくつかには便利ですが、それらのファイルはログ回転スクリプトによってときどき
移動されることを考えるべきです。

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

<!--
second mentioning to "available on only ext2"
-->
<p>
lsattr と chattr は ext2 ファイルシステムでのみ利用可能なことに
注意してください。

<sect1 id="check-integ">ファイルシステムの完全性を確かめる
<p>
あなたのハードドライブにある <file>/bin/login</file> は
本当に数か月前にインストールした
バイナリと同じですか? もしそれが入力されたパスワードを隠しファイルに
保存したり平文でインターネットじゅうにメールで送る、ハックされたバージョンなら
どうでしょうか?

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

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

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

<sect>setuid チェックを設定する
<p>
Debian は 毎日実行される cron job を <file>/etc/cron.daily/standard</file> で
提供しています。この cron job は setuid の変化を保存する
<prgn>/usr/sbin/checksecurity</prgn> スクリプトを実行します。

<!-- TODO What is the defaul for this in cron package? jfs -->

このチェックを行うためには <file>/etc/checksecurity.conf</file> で
<tt>CHECKSECURITY_DISABLE="FALSE"</tt> を設定しなければなりません。
これはデフォルトなので、何も変更していなければ、このオプションはすでに
「FALSE」に設定されていることに注意してください。

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

<sect>推奨されている他の事項

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

<!-- TODO: move this to policy section if there ever is one? -->

<chapt id="sec-services">システム上で動いているサービスを安全にする

<p>
すでに動いているシステム上でサービスを安全にする方法は 2 通りあります:

<list>
<item>必要とされるアクセスポイント (インターフェイス) でのみアクセス
できるようにする。

<item>適切に設定して正当なユーザだけが認められているやり方でのみ
使えるようにする。

</list>

<p>
ある場所からのみアクセスできるようにサービスを制限するのはカーネルレベルで
(すなわち、ファイアウォールで) アクセスを制限すること、あるインターフェイスに
だけ応答するように設定すること (この機能を提供しないサービスもあります)
またはその他の方法を使うことによって可能です。たとえば linux vserver パッチは
プロセスがインターフェイスをひとつしか使わないように強制するのに使えます。

<p>
<prgn>inetd</prgn> から起動されるサービス (telnet、ftp、finger、pop3...) に
ついて言えば、inetd はサービスがあるインターフェイスにだけ応答するように
設定することはできないことには言及する価値があります。しかし、その代用品で
ある <prgn>xinetd</prgn> メタデーモンはちょうどこれに使える <tt>bind</tt> を
含んでいます。<manref name="xinetd.conf" section="5"> をごらんください。

<example>
service nntp
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = news
        group           = news
        server          = /usr/bin/env
        server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
+/usr/sbin/snntpd logger -p news.info
        bind            = 127.0.0.1
} 
</example>

<p>
以下の章は特定のサービスを意図されている用途にしたがってどのように適切に
設定できるかの詳細を論じます。

<sect>ssh を使う
<p>
もし ssh のかわりにまだ telnet を動かしているなら、このマニュアルを読むのを
やめてそれを変更するべきです。リモートログインにはすべて telnet のかわりに
Ssh を用いるべきです。インターネットのトラフィックを盗聴して平文の
パスワードを得ることが簡単にできる時代には、暗号を使うプロトコルだけを
使うべきです。よって、あなたのシステムでただちに
<tt>apt-get install ssh</tt> を実行しましょう。

<p>
あなたのシステムのすべてのユーザに telnet のかわりに ssh を使うことを
すすめましょう。よりよいのは telnet や telnetd をアンインスールすることです。
さらに
ssh を使って root としてシステムにログインすることを避け、<tt>su</tt> や
<tt>sudo</tt> のような、root になるためのかわりの手段を使いましょう。
最後に、セキュリティを向上させるために <file>/etc/ssh</file> 中のファイル
<file>sshd_config</file> を
変更するべきです:

<list>
<item><tt>ListenAddress 192.168.0.1</tt>
<p>
ふたつ以上のインターフェイスがあるかもしれないので (そこで ssh を利用
可能にはしたくないなら)、または将来新しいネットワークカードを追加するのに
そなえて (そしてそこからの ssh 接続を望まないなら)、ssh をある
インターフェイスにだけ応答するようにしましょう。

<item><tt>PermitRootLogin No</tt>

<p>
可能なら Root のログインをいつでも禁止するべきです。ssh 経由で root に
なりたいなら、こうすると 2 回のログインが必要になり、root のパスワードを
SSH 経由で力まかせに推測することができなくなります。

<item><tt>Listen 666</tt>
<p>
要求を受けつけるポートを変更し、ssh デーモンが動いているのか侵入者には
はっきりわからないようにしましょう。

<item><tt>PermitEmptyPasswords no</tt>
<p>
空のパスワードはシステムのセキュリティをだいなしにします。

<item><tt>AllowUsers alex ref</tt>
<p>
特定のユーザだけが ssh 経由でこのマシンにアクセスできるようにしましょう。

<item><tt>AllowGroups wheel admin</tt>
<p>
特定のグループのメンバーだけが ssh 経由でこのマシンにアクセスできるように
しましょう。AllowGroups と AllowUsers にはアクセスを拒否するための同様の
ディレクティブがあります。驚くべきことでもなく、それは「DenyUsers」や
「DenyGroups」と呼ばれています。

<item><tt>PasswordAuthentication yes</tt>
<p>
何をしたいかは完全にあなたが選べます。ssh の鍵をファイル
~/.ssh/authorized_keys に置いているユーザからのマシンへのアクセスだけを
許可するほうがより安全です。もしそうしたいなら、これを「no」に設定して
ください。
<!-- FIXME: what does this mean? Is it "more secure" to set this to
"no"? (era) --> <!-- jfs, IMHO yes since you place the key of the
incoming host in your server and the authentication is done against
the key -->

</list>

<p>
最後に、これらのディレクティブは OpenSSH のものであることに注意してください。
現時点では、広く使われている SSH デーモンは 3 種類あります。ssh1、ssh2
そして OpenBSD の人たちによる OpenSSH です。Ssh1 は利用できる最初の ssh
デーモンでした。そして依然として最も広く使われています (windows への
移植版さえあるといううわさです)。Ssh2 はソース非公開のライセンスで
リリースされていることを除けば ssh1 より多くの長所があります。OpenSSH は
「ssh」が選択されたとき Debian にインストールされるバージョンです。

<p>
SSH を PAM サポートとともに設置する方法についてくわしくは
<url
id="http://lists.debian.org/debian-security/2001/debian-security-200111/msg00395.html"
name="security mailing list archives"> をごらんください。

<sect>Squid を安全にする
<p>
Squid は最も有名なプロキシおよびキャッシュサーバです。そして考えるべき
セキュリティ問題がいくつかあります。Squid のデフォルトの設定はユーザからの
すべての要求を拒否します。<file>/etc/squid.conf</file> の
Access Control List を定義して信用できるユーザ、ホストまたはネットワークからの
アクセスを許可するように Squid を設定するべきです。ACL 規則を定義することに
ついてくわしくは
<url
name="Squid User's Guide"
id="http://squid-docs.sourceforge.net/latest/html/book1.htm">
をごらんください。

<p>
さらに、適切に設定されていなければ、だれもがメールを Squid を通じてリレーする
ことができます。なぜなら、HTTP プロトコルと SMTP プロトコルは同じように
設計されているからです。Squid のデフォルトの設定ファイルでは 25 番ポートへの
アクセスは禁止されています。もし 25 番ポートへの接続を許可したいなら
それを Safe_ports リストに追加するだけです。しかし、これは推奨されて
<em>「いません」</em>。

<p>
プロキシおよびキャッシュサーバを適切に設置して設定することはあなたのサイトを
安全に保つことの一部にすぎません。他に必要な仕事には何事もそうあるべきように
動いていることを確実にするため Squid のログを解析することがあります。
Debian GNU/Linux には管理者がこれを行うのを助けるパッケージがいくつかあります。
以下のパッケージが woody (Debian 3.0) で利用可能です:

<list>
<item><package>calamaris</package> - Log analyzer for Squid or Oops proxy log files.
<item><package>modlogan</package>  - A modular logfile analyzer.
<item><package>sarg</package> - Squid Analysis Report Generator.
</list>

<p>FIXME: Squid Accelerator Mode のセキュリティについての情報をさらに追加する。

<sect>FTP を安全にする
<p>
本当に FTP を (sslwrap でラップしたり、SSL や SSH のトンネルを通さずに)
使わなければいけないならば、
ユーザが自分のディレクトリ以外のどんなものも見ることができないように ftp を
ftp ユーザのホームディレクトリの内部へ chroot するべきです。そうしないと
ユーザはシェルを持っているかのようにあなたのルートファイルシステムをうろつく
ことができます。この chroot 機能を有効にするには
<file>proftpd.conf</file> のグローバル
セクションに以下の行を追加することができます:

<example>
DefaultRoot ~
</example>

<p>
<tt>/etc/init.d/proftpd restart</tt> で proftpd を再起動して
ホームディレクトリから逃げだせるか確かめてください。

<p>
../../.. を使った Proftp DoS 攻撃を防ぐには、以下の行を
<file>/etc/proftpd.conf</file> に追加してください。

<!--
<tt>DenyFilter \*.*/</tt>
-->
<example>
DenyFilter \*.*/
</example>

<p>
FTP はログインや認証のパスワードを平文で送っていること (これは匿名の公共
サービスを提供しているのなら問題ではありません) および Debian にはよりよい
代用品があることをいつもおぼえておいてください。たとえば、<prgn>sftp</prgn>
(<package>ssh</package> パッケージによって提供されます)。他の
オペレーティングシステムのためのフリーな SSH 実装もあります: たとえば
<url id="http://www.chiark.greenend.org.uk/~sgtatham/putty/" name="putty"> や
<url id="http://www.cygwin.com" name="cygwin"> です。

<!-- contributed by Jesus Climent -->
<p>
しかし、ユーザに SSH 経由でアクセスさせようとしながら FTP サーバも維持するなら
典型的な問題にでくわすかもしれません。SSH で安全にされたシステムの内部にある
匿名 FTP サーバにアクセスするユーザはその <em>FTP サーバ</em>にログイン
しようとするかもしれません。このアクセスは拒否されるでしょうが、それでも
パスワードが平文でネット上を流れることになります。これを避けるために、
ProFTPd の開発者である TJ Saunders さんはユーザが匿名 FTP サーバに有効な
SSH アカウントを送ることを防ぐパッチを作りました。より多くの情報およびその
パッチがここで入手できます:
<url id="http://www.castaglia.org/proftpd/#Patches" name="ProFTPD Patches">

<sect>X Window System へのアクセスを安全にする
<p>
今日では、X 端末はひとつのサーバが多くのワークステーションで必要とされる
多くの企業で使われています。これは危険かもしれません。なぜならファイルサーバに
クライアント (X の観点からは X サーバです。X はクライアントとサーバの定義を
入れかえています) への接続を許可する必要があるからです。もし多くの文書に
ある (非常に悪い) 提案にしたがうなら、あなたのマシンで <tt>xhost +</tt> と
入力することになります。これはすべての X クライアントにあなたのシステムへの
接続を許可します。すこしだけセキュリティをよくするには、特定のホストからの
アクセスだけを許可するためにかわりに <tt>xhost +hostname</tt> コマンドを
使うことができます。

<p>
しかし、さらに安全な解決法は X をトンネル化してセッション全体を暗号化する
ために ssh を使うことです。これは他のマシンに ssh すると自動的に行われます。
これは
<file>/etc/ssh/ssh_config</file> で <tt>X11Forwarding</tt> を <tt>yes</tt> に
設定することによって有効にしておく必要があります。SSH の時代では
xhost にもとづくアクセス制御を完全に廃止するべきです。
<!-- FIXME: check. The text said "has to be disabled" [sic] -->

<p>
最高のセキュリティのためには、他のマシンからの X アクセスが必要ないなら、
こう入力して tcp の 6000 番ポートをバインドすることを停止することです:

<tt>startx -- -nolisten tcp</tt>

<p>
注意: これは Xfree 4.0 (Debian 3.0 で提供される X サーバです) の
デフォルトのふるまいです。もし Xfree 3.3.6 を動かしているなら (すなわち、
Debian 2.2 をインストールしているなら)、<file>/etc/X11/xinit/xserverrcc</file>
を編集してこのような行を追加できます:

<example>
#!/bin/sh
exec /usr/bin/X11/X -dpi 100 -nolisten tcp
</example>

<p>
XDM を使っているなら <file>/etc/X11/xdm/Xservers</file> を次のように
してください:
<tt>:0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp</tt>

<p>
X Window のセキュリティについてくわしくは
<url
name="XWindow-User-HOWTO"
id="http://www.linuxdoc.org/HOWTO/XWindow-User-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz</file>)
をごらんください。

<p>
FIXME: これを行うために XFree 3.3.6 の設定ファイルをどう変更するべきかに
ついての debian-security スレッドの情報を追加する。

<sect1>ディスプレイマネージャを調べる
<p>
もしローカルで使うためだけに (つまり、きれいなグラフィカルログインのために)
ディスプレイマネージャをインストールしたいなら、XDMCP (X Display Manager
Control Protocol) 関連を停止しましょう。XDM ではこれは
<tt>/etc/X11/xdm/xdm-config</tt> のこういう行で行うことができます。

<example>
DisplayManager.requestPort:     0
</example>

<p>
ふつう、Debian ではすべてのディスプレイマネージャはデフォルトでは XDMCP
サービスを開始しないよう設定されています。

<sect>プリントサービスを安全にする (lpd と lprng の問題)
<p>
職場に着いたとき、だれかがあなたのラインプリンタデーモンに DoS しているせいで
プリンタが紙を際限なくはきだしているとしましょう。いやでしょう? 

<!-- Info based on Dale Southard's post to debian-security april 11th 2002-->
<p>
unix の印刷アーキテクチャでは、クライアントのデータをホストの印刷サーバに
送る方法がなければなりませんでした。伝統的な <prgn>lpr</prgn> と
<prgn>lp</prgn> では、クライアントコマンドはデータをスプールディレクトリに
コピーするか、データへの symlink を作ります (だからこれらのプログラムは
ふつう SUID または SGID になっているわけです)。

<p>
問題がなにもないようにするにはプリンタサーバを特に安全にするべきです。
これは信用されているサーバからの
接続のみを許可するようプリンタサービスを設定する必要があるということです。
これを行うには、印刷を許可したいサーバを <file>/etc/hosts.lpd</file> に
追加してください。

<p>
しかし、これを行っても、<prgn>lpr</prgn> デーモンは
515 番ポートへの外部からの接続をどの
インターフェイスからでも受けつけます。印刷を許可されていないネットワーク
(またはホスト) からの接続をファイアウォールで防ぐことを検討するべきです
(<prgn>lpr</prgn> デーモンは特定の IP アドレスにのみ応答するようには
制限できません)。

<!-- FIXME
<p>Of course, you could also take the lpr/lprng sources
and change them so that the connect function is only done to "127.0.0.1".
apt-get source lpr
and patch the bind (finet) call
-->

<p>
<prgn>lpr</prgn> より <prgn>Lprng</prgn> を優先するべきです。
なぜなら IP アクセス制御を行うように
設定できるからです。そしてどのインターフェイスをバインドするか (やや奇妙な
やり方ですが) 指定できます。

<!-- FIXME: ask Craig Small about his post in debian-private 19th october 2001 
-->

<p>
もしあなたのシステムでプリンタを使っているが、ローカルでのみ使っているなら、
そのサービスをネットワークで共有したくはないでしょう。<file>/dev/lp0</file>
デバイスのユーザパーミッションにもとづく <package>cups</package>
とか <url name="PDQ"
id="http://pdq.sourceforge.net/"> によって提供されるような他の印刷
システムを使うことを検討することができます。

<p>
<package>cups</package> では、印刷データは http プロトコルでサーバに
送られます。これはクライアントプログラムは特権を何も必要としないが、
サーバがどこかのポートで応答する必要があるということです。

<p>
しかし、<prgn>cups</prgn> を使いたいが、ローカル専用にしたいなら、
<file>/etc/cups/cupsd.conf</file> をこのように
変更することによってループバックインターフェイスをバインドするように
設定できます:

<example>
Listen 127.0.0.1:631
</example>

<p>
この設定ファイルにはネットワークやホストを受けつけたり拒否したりするなどの
多くの他のセキュリティオプションがあります。しかし、必要がないなら
応答するポートを制限するだけのほうがよいでしょう。<prgn>Cups</prgn> は
HTTP ポートを通じて文書も提供します。外部の攻撃者に役に立つかもしれない
情報を明らかにしたくないなら (そしてポートをあけておきたいなら)、これ
追加しましょう:

<example>
&lt;Location /&gt;
  Order Deny,Allow
   Deny From All
    Allow From 127.0.0.1
&lt;/Locationi&gt;
</example>

<p>
この設定ファイルは SSL/TLS 証明書や暗号を含むより多くの機能を追加するように
変更できます。http://localhost:631/ または cups.org にマニュアルがあります。

<p>
FIXME: 内容をさらに追加する (<url name="Amateur Fortress
Building" id="http://www.rootprompt.org"> の記事は非常に興味深い意見を
提供している)。

<p>
FIXME: PDG が Debian で利用可能か調べて、もしそうなら、これをよりよい
印刷システムとして提案する。

<p>
FIXME: Farmer/Wietse がプリンタデーモンのかわりになるものを持っているか、
それが Debian で利用可能か調べる。

<sect>メールデーモンを安全にする
<p>
あなたのサーバがメールシステムでなければ、メールデーモンが外部からの接続に
応答する必要は本当はありませんが、たとえば設置している警告システムからの
root ユーザへのメールを受けとるなどのために、ローカルのメールが配達される
ようにしたいかもしれません。

<p>
Debian システムでこれを行うには、smtp デーモンを inetd から除かなければ
ならないでしょう:
<example>
$ update-inetd --disable smtp
</example>

<p>
そして loopback インターフェイスにのみ応答するようにメーラデーモンを
設定します。exim (デフォルトの MTA) ではこれは <file>/etc/exim.conf</file>
ファイルを編集して以下の行を追加することによって行えます:

<example>
local_interfaces = "127.0.0.1"
</example>

<p>
両方のデーモン (inetd と exim) を再起動すると exim は 127.0.0.1:25 ソケットに
のみ応答するようになります。注意してください、最初に inetd を停止しましょう。
そうしないと exim は起動しません。なぜなら inetd デーモンがすでに外部からの
接続を扱っているからです。

<p>
postfix については <file>/etc/postfix/main.conf</file> をこう編集しましょう:

<example>
inet_interfaces = localhost
</example>

<p>
もしローカルのメールだけが望みなら、この方法はメーラデーモンに tcp wrapper を
使ったりファイアウォールの規則を追加してアクセスを制限したりするのより
よいです。しかし、他のインターフェイスにも応答させる必要があるなら、inetd から
起動して、外部からの接続を <file>/etc/hosts.allow</file> と
<file>/etc/hosts.deny</file> でチェックできるよう tcp wrapper を追加することを
検討してもいいです。そして、上で述べたような方法のどれかで記録するように
正しく設定していれば、許可されていないアクセスがメーラデーモンに対して
いつ行われようとしたかわかるでしょう。

<sect>メールを安全に受けとる
<p>
メールを読んだり受けとったりするのは最も一般的な平文のプロトコルです。
メールを受けとるのに POP3 か IMAP を使っていれば、平文のパスワードを
ネット経由で送っているので、今後ほとんどだれでもあなたのメールを読むことが
できることになります。かわりに、メールを受けとるのに SSL (Secure Sockets
Layer) を使いましょう。POP または IMAP サーバとして働いているマシンに
シェルアカウントを持っていれば、ほかの選択肢は ssh です。これををやって
みせる基本的な fetchmailrc がこれです:

<example>
poll my-imap-mailserver.org via "localhost"
  with proto IMAP port 1236
      user "ref" there with password "hackme" is alex here warnings 3600
    folders
      .Mail/debian
    preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
     my-imap-mailserver.org sleep 15 &lt;/dev/null &gt; /dev/null'
</example>

preconnect が重要な行です。これは ssh セッションを開始して必要なトンネルを
作ります。それが自動的に localhost の 1236 番ポートから IMAP メールサーバへの
接続を暗号化して転送します。ほかの可能性は ssl 機能つきの fetchmail を
使うことです。

<p>
POP や IMAP のような暗号化されたメールサービスを提供したいなら、
<tt>apt-get install stunnel</tt> してデーモンをこのように起動してください:

<example>
stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd
</example>

これは与えられたデーモン (-l) を指定されたポート (-d) へラップして、指定された
ssl cert (-p) を使います。

<sect id="sec-bind">BIND を安全にする
<p>
Domain サーバデーモンを安全にするために取り組まなければならない問題がいくつか
あります。これは他のどのサービスを安全にするときも検討されることです:

<list>

<item>外部から乱用されないようにデーモン自体を適切に設定しましょう。
これにはクライアントから可能な問いあわせの個数を制限すること (zone
transfers や逆引きの問いあわせ) が含まれます。

<item>サーバへ侵入するのに使われたときシステムへの損害が限られるように
デーモンからサーバそのものへのアクセスを制限しましょう。これにはデーモンを
非特権ユーザで動かすことや chroot することが含まれます。

</list>
<p>
あなたの組織のもらしたくない貴重な情報を引きだすのに使えないように DNS
サーバから外部のクライアントへ提供される情報を制限するべきです。これには
以下のオプションを追加することが含まれます:
<em>allow-transfer</em>、<em>allow-query</em>、
<em>allow-recursive</em>、そして <em>version</em> です。これを (提供される
すべてのゾーンに適用されるように) グローバルセクションで制限することも
できますし、ゾーンごとに制限することもできます。この情報は 
<package>bind-doc</package> で文書化されています。このことについて
くわしくはそのパッケージをインストールしたあと
<file>/usr/share/doc/bind/html/index.html</file> をごらんください。

<p>
あなたのサーバがインターネットと内部の (あなたの内部 IP は 192.168.1.2 だと
します) ネットワークに接続されていて (基本的なマルチホームのサーバです)、
インターネットにはサービスを何も提供したくはなく、内部のホストからだけ
DNS 参照ができるようにしたいとしましょう。
<file>/etc/bind/named.conf</file> にこれを追加することによって DNS 参照を
制限できます:

<example>
options {
           allow-query { 192.168.1/24; } ;
           allow-transfer { none; } ; 
           allow-recursive { 192.168.1/24; } ;
           listen-on { 192.168.1.2; } ;
           forward { only; } ;
           forwarders { A.B.C.D; } ;
};
</example>

<p>
<em>listen-on</em> オプションは DNS が内部アドレスを持つインターフェイスだけを
バインドするようにしますが、このインターフェイスがインターネットに接続されて
いるインターフェイスと同じでも (たとえば NAT を使っているときなど)、
問いあわせは内部のホストから来たときのみ受けいれられます。システムに
インターフェイスが複数あって、<em>listen-on</em> がないときは、内部ユーザ
だけが問いあわせることができますが、このポートは外部の攻撃者からもアクセス
できるので、攻撃者は DNS サーバをクラッシュさせようと (またはバッファ
オーバーフロー攻撃を行おうと) するかもしれません。自分自身以外のどの
システムにも DNS サービスを提供しないなら 127.0.0.1 にだけ応答するように
することさえできます。

<p>
chaos クラスの version.bind レコードは現在動いている bind プロセスの
バージョンを含みます。この情報はしばしば自動スキャナや、bind が特定の攻撃に
対して脆弱であるか調べたい、悪意ある人に利用されます。version.bind
レコードでうその情報を提供したり、情報を何も提供しないことによって、
公開されているバージョンにもとづいてサーバが攻撃される確率を制限することが
できます。独自のバージョンを提供するには、<em>version</em> ディレクティブを
次のように使ってください:
<example>
options {
        ... various options here ...
        version "Not available.";
};
</example>

<p>
version.bind レコードを変更することは攻撃に対する実際の保護にはなりませんが、
役に立つ防御策と考えられるべきです。
</p>

<p>
BIND の権限を制限することについては、もし root でないユーザが BIND を
動かしたら、BIND は新しいインターフェイスを自動的に検知できなくなるという
ことを知っておかなければなりません。たとえば、PCMCIA カードをラップトップに
さしこんだときです。このことについてくわしくは named 文書ディレクトリの
README.Debian (<file>/usr/share/doc/bind/README.Debian</file>) を
ごらんください。BIND に関するセキュリティ問題が最近多くあります。よって
ユーザを切りかえることは可能ならば役に立ちます。

<p>
BIND を異なるユーザで動かすには、まずそのために別個のユーザおよびグループを
作ってください (root として動いていないサービスすべてに nobody または
nogroup を使うのはよい考えでは<em>ありません</em>)。この例では、
<tt>named</tt> というユーザおよびグループが使われます。これはこう入力する
ことによって可能です:
<example>
addgroup named
adduser --system --ingroup named named
</example>

<p>
そこであなたのすきなエディタで <tt>/etc/init.d/bind</tt> を編集し、
<example>
start-stop-daemon --start
</example>
ではじまる行を

<example>
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
</example>

に変更してください。

<p>
あと必要なのは「/etc/init.d/bind restart」で bind を再起動し、こういう
2 行が syslog にないかさがすだけです。
<p>
<example>
Sep  4 15:11:08 nexus named[13439]: group = named
Sep  4 15:11:08 nexus named[13439]: user = named
</example>
<p>
やった! named はもう root では動いていません。BIND について最高の
セキュリティを実現するには、デーモンのまわりに chroot の檻
(<ref id="chroot"> をごらんください) を構築しましょう。
これを行う簡単な方法があります: <tt>-t</tt> オプションです
(<manref name="named" section="8"> マニュアルページをごらんください)。
これは Bind が自分自身を指定されたディレクトリの中へ chroot するように
します。chroot の檻を設置したり動的なライブラリについて心配したりする
必要はありません。この chroot の檻の中に必要なファイルは以下のファイルのみです:

<example>
dev/null
etc/bind/       - named.conf やすべてのサーバゾーンを含むべき
sbin/named-xfer - name transfer を行うなら
var/run/named/  - pid およびネームサーバキャッシュ (もしあれば) を保持します。
                  このディレクトリは named ユーザによって書きこみ可能で
                  ある必要があります。
var/log/named   - ファイルへのログを設定するなら、 named ユーザによって
                  書きこみ可能である必要があります
dev/log         - named が syslogd を通じてログを取るように設定されているなら
                  syslogd がここで応答する必要があります
</example>

<p>
Bind デーモンが適切に動くためには named ファイルのパーミッションが必要です。
設定ファイルがいつも <tt>/etc/named/</tt> にあるのでこれは容易な作業です。
セカンダリまたはキャッシュネームサーバでなければ、zone ファイルへは
読みとり専用のアクセスだけでいいことを考慮してください、セカンダリまたは
キャッシュネームサーバの場合は、(プライマリサーバからの zone transfer が
うまくいくように) 必要な zone への読み書き許可を与える必要があります。

<p>
BIND が Debian システムでなぜ root 以外のユーザとして動いていないのかに
ついて知りたければ、Bind に関するバグ追跡システム、特に
<url name="Bug #50013: bind should not run as root"
id="http://bugs.debian.org/50013">
をごらんください。

<p>
さらに、Bind を chroot することについては <url name="Chroot-Bind-HOWTO"
id="http://www.linuxdoc.org/HOWTO/Chroot-Bind-HOWTO.html">
(Bind 9 について) と <url name="Chroot-Bind8-HOWTO"
id="http://www.linuxdoc.org/HOWTO/Chroot-Bind8-HOWTO.html">
(Bind 8 について) にくわしい情報があります。この文書は
<package>doc-linux-text</package> (テキスト版) または
<package>doc-linux-html</package> (html 版) をインストールすることに
よっても利用できます。

<p>
もし Debian (potato) の Bind 8.2.3 の完全な chroot の檻を設置しようと
しているなら (すなわち、<tt>-t</tt> だけではないなら)、以下のファイルが
その中に含まれるようにしてください:

<example>
dev/log - syslogd がここで応答するべき
dev/null
etc/bind/named.conf 
etc/localtime
etc/group - 中身は 1 行だけ: "named:x:GID:"
etc/ld.so.cache - ldconfig で生成される
lib/ld-2.1.3.so
lib/libc-2.1.3.so
lib/ld-linux.so.2 - ld-2.1.3.so への symlink
lib/libc.so.6 - libc-2.1.3.so への symlink
sbin/ldconfig - chroot 設置後は削除可能
sbin/named-xfer - name transfers を行うなら
var/run/
</example>

<p>
FIXME、
<url id="http://www.cryptio.net/~ferlatte/config/"> (Debian 特有)
および 
<url id="http://www.psionic.com/papers/whitep01.html">
の情報を統合する。

<sect>Apache を安全にする
<p>
FIXME。内容を追加する。

<p>
内部でのみ使用したいのであって、外部の人にアクセスしてもらいたくないならば
(試験用であるとか、<package>doc-central</package> アーカイブにアクセス
したいためであるとか...)、
Apache サーバへのアクセスを制限できます。これを行うには
<file>/etc/apache/http.conf</file> で <tt>Listen</tt> または
<tt>BindAddress</tt> ディレクティブを使います。

<p>
Listen を使うなら:
<example>
Listen 127.0.0.1:80
</example>

<p>BindAddress を使うなら:
<example>
BindAddress 127.0.0.1
</example>

<p>
そして <tt>/etc/init.d/apache restart</tt> で apache を再起動してください。
すると apache が loopback インターフェイスにしか応答しないことが
わかるでしょう。

<p>
いずれの場合も、Apache によって提供される機能をすべて使っているのでなければ、
<package>dhttpd</package> のような Debian で提供されている他のウェブサーバを
見てみたくなるかもしれません。

<p>
<url name="Apache Documentation"
id="http://httpd.apache.org/docs/misc/security_tips.html"> は Apache
ウェブサーバについて行われるべきセキュリティ対策に関する情報を提供しています
(Debian では同じ情報が <package>apache-doc</package> パッケージで提供されて
います)。

<sect>finger を安全にする
<p>
もし finger サービスを動かしたいならまずそうするのが必要かどうか考えて
ください。もし必要なら、 Debian は多くの finger デーモンを提供しているのが
わかるでしょう (<prgn>apt-cache search fingerd</prgn> の出力です):
<list>
<item>cfingerd - Configurable finger daemon
<item>efingerd - Another finger daemon for unix capable of fine-tuning your out
put.
<item>ffingerd - a secure finger daemon
<item>fingerd - Remote user information server.
<item>BSD-like finger daemon with qmail support.
</list>

<p>
公開のサービスに finger デーモンを使うなら <package>ffingerd</package> が
推奨されています。いずれにせよ、inetd、xinetd または tcpserver を通じて
finger デーモンを設置するときにはこうすることをおすすめします:
同時に動くことができるプロセスの個数を制限し、(tcp wrapper を使って)
あるホストからの finger デーモンへのアクセスを制限し、必要なインターフェイス
だけに応答するようにしましょう。

<sect>一般的な chroot および suid のパラノイア
<p>
BIND がここ数年多くの攻撃にさらされてきた理由はその複雑さだといってもたぶん
妥当でしょう (<ref id="sec-bind"> をごらんください)。

<p>
複雑な機能を持ちインストールしているユーザの基盤が大きな他の
プログラムには Sendmail やいくつかの ftp デーモン (たとえば WUftpd) が
あります。(もちろん、機能がなく満足しているユーザもいないプログラムも
役に立たないだけでなく同じくらい危険かもしれません)。

<p>
いずれにせよ、これらのどれかを動かすなら、同様の配置
&mdash; root 特権を破棄して、chroot された檻の中で動かす &mdash; にするか
より安全な代替物に置きかえることを検討してください。

<sect>一般的な平文パスワードのパラノイア
<p>
FTP、Telnet、NIS、RPC のような、ネット上でパスワードを平文で送ったり
受けとったりするネットワークサービスをすべて避けるべきです。この HOWTO の
著者は telnet や ftp のかわりに ssh を使うことを全員にすすめます。

<p>
telnet から ssh に移行しても、他の平文プロトコルを使うのではセキュリティは
「すこしも」向上しないことに気をつけてください。最善なのは ftp、telnet、
pop、imap、http を取りのぞいて対応する暗号化サービスで置きかえることでしょう。
これらのサービスから ftp-ssl、telnet-ssl、pop-ssl、https などのような SSL
バージョンに移行することを検討するべきです。

<p>
上にあげたヒントの多くはすべての Unix システムにあてはまります (Linux や
その他の Unixes についての強化関連の文書をほかに読んでいればそれに気が
つくでしょう)。

<sect>NIS を無効にする
<p>
もし可能なら、NIS、すなわち Network Information Service を使うべきでは
ありません。なぜならそれはパスワードの共有を可能にするからです。設定が
まちがっていたらこれはきわめて危険になります。

<p>
複数のマシン間でパスワードの共有が必要なら、他の選択肢を使うことを考えたく
なるかもしれません。たとえば、LDAP サーバを設置してユーザ認証用にその
LDAP サーバに接触するためにあなたのシステムの PAM を設定することができます。
設定の詳細は
<url
name="LDAP-HOWTO" id="http://www.linuxdoc.org/HOWTO/LDAP-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz</file>)
をごらんください。

<p>
NIS のセキュリティについてくわしくは
<url
name="NIS-HOWTO" id="http://www.linuxdoc.org/HOWTO/NIS-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz</file>) を
ごらんください。

<p>
FIXME (jfs): これを Debian で設定する方法についての情報を加える

<sect id="rpc">RPC サービスを無効にする
<p>
可能なら RPC をいつでも停止するべきです。
<!-- FIXME: explain when RPC is necessary. -->
このサービスには多くのセキュリティホールが知られていて、簡単に攻撃できます。
一方で NFS サービスはネットワークでとても重要です。よってあなたの
ネットワークでセキュリティと有用性のバランスを取らなければなりません。
多くの DDoS (distributed denial of service) 攻撃はシステムに侵入して
いわゆるエージェントまたはハンドラーとしてふるまうのに rpc 攻撃を利用します。
NFS のセキュリティについてくわしくは
<url
name="NFS-HOWTO" id="http://www.linuxdoc.org/HOWTO/NFS-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz</file>) を
ごらんください。

<p>
portmap を停止することは非常に簡単です。いくつかの方法があります。Debian 3.0
システムで最も簡単なのは <package>portmap</package> パッケージを
アンイントールすることです。他のバージョンを使っているなら
<ref id="disableserv"> にあるようにしてサービスを無効にする必要があるでしょう。
これは portmap が <package>net-base</package> パッケージ (システムを壊すこと
なくこれをアンインストールすることはできません) の一部であるためです。

<p>
これは実際には <tt>/etc/rc${runlevel}.d/</tt> にある portmap 関連のすべての
symlink を削除します。これは手動でも行うことができます。ほかの可能性は
<tt>chmod 644 /etc/init.d/portmap</tt> ですが、これはブート時にエラー
メッセージを出します。シェルスクリプト <file>/etc/init.d/portmap</file> の
<tt>start-stop-daemon</tt> の部分をはずすこともできます。

<sect id="firewall-setup">ファイアウォール機能を追加する
<p>
Debian GNU/Linux オペレーティングシステムには Linux カーネルによって
提供される内蔵されたファイアウォール機能があります。つまり potato (Debian 2.2
リリース) システム (デフォルトのカーネルは 2.2 です) をインストールしたら
<prgn>ipchains</prgn> ファイアウォールがカーネルで利用できるということです。
<package>ipchains</package> をインストールする必要がありますが、これは
きっと (その優先度ゆえに) すでにインストールされているでしょう。woody 
(Debian 3.0 リリース) システム (デフォルトのカーネルは 2.4 です) を
インストールしたら、<prgn>netfilter</prgn> ファイアウォールが利用できます。

<p>
このスクリプトでファイアウォールの規則を設定したいユーザもいるでしょう。
しかし、自分がどのファイアウォールプログラムまたは機能を使っているのか
調べてください。なぜならこれらのプログラムや機能が他のファイルをいじったり
起動時に追加した定義を変更したりする可能性があるからです。たとえば、
<package>firewalk</package> はファイアウォール設定に別の設定ファイルを
使います。

<sect1>Iptables の規則
<p>
Debian 3.0 を使っているなら、<package>iptables</package> パッケージが
インストールされているのに気がつくでしょう。これは 2.4.4 以降のカーネルの
netfilter 実装をサポートします。インストール直後にはシステムはファイアウォール
規則を<em>知る</em>ことができないので (ファイアウォール規則はあまりにシステム
特有です)、あなたが iptables を有効にする必要があります。

<p>
そのためにはこのようにしなければなりません:
<list>

<item><file>/etc/default/iptables</file> を編集して
<tt>enable_iptables_initd</tt> を <em>true</em> に設定します

<item>iptables を使ってファイアウォールの設定を作る。コマンドラインも
使えますし (<manref name="iptables" section="8"> をごらんください)、
Debian ファイアウォールパッケージによって提供される道具も使えます
(<ref id="firewall-pack"> をごらんください)。ファイアウォールが
<em>有効な</em>ときに使われる規則と<em>有効でない</em>ときに使われる
規則 (これは空の規則でもかまいません) を作る必要があります。

<item>あなたが望むファイアウォール規則が有効になっているときに
<tt>/etc/init.d/iptables save_active</tt> や
<tt>/etc/init.d/iptables save_active</tt> を実行することによってあなたが
作った規則を保存します。

</list>

<p>
これが終わったらファイアウォールの設定は <file>/var/lib/iptables/</file>
ディレクトリに保存されシステム起動時 (または initd スクリプトを 引数
<em>start</em> および <em>stop</em> とともに実行するとき) に実行されます。
デフォルトの Debian の設定ではファイアウォールコードはマルチユーザランレベル
(2 から 5) の極めてはやい段階 (10) に実行されることに注意してください。
また、このコードはシングルユーザランレベル (1) で停止されます。これがあなたの
ポリシーにあわないなら変更してください。

<p>
以下で概説されるパッケージはシステムが起動するときに実行される
ファイアウォールスクリプトを導入するかもしれないことに注意してください。
これは一般的な設定とはまちがいなく対立し、望ましくない影響をもたらします。
パッケージの文書を読んでどちらか一方の設定を使ってください。

<p>
ファイアウォール規則をどうやって設定するべきかわからないなら
<em>Packet Filtering HOWTO</em> を読んでください。これは
<package>iptables</package> をインストールすると
<file>/usr/share/doc/iptables/html/</file> でオフラインで読めます。

<sect1>ローカルシステムをファイアウォールで守る
<p>
ファイアウォール規則をローカルシステムへのアクセスを安全にし、さらにそこで
行われる外向きのやりとりを制限する方法として使うことができます。
ファイアウォール規則はサービスをあるネットワーク、IP アドレスなどにだけ
提供するように適切に設定<em>できない</em>プロセスを守るのにも使えます。

<p>
しかし、主にシステムを守るためにファイアウォール機能だけに頼らないほうが
<em>ずっと</em>よいという理由により、この段階はこのマニュアルの最後に
書かれています。システムのセキュリティは層によって構成されています。
ファイアウォールは最後に、すべてのサービスが強化されたあとで取りいれる
べきです。システムが組みこみのファイアウォールでしか守られていない設定なのに
管理者が喜んでファイアウォール規則を何らかの理由で (設定に問題があるとか、
気にくわないとか、まちがえてとか...) 削除してしまうことが容易に想像できます。
このようなシステムは攻撃にさらされることになるでしょう。

<sect1>他のシステムを守るのにファイアウォールを使う
<p>
Debian のファイアウォールはフィルタリング規則でその<em>背後</em>にある
システムへのアクセスを守り、インターネットへの接触を制限するのにも使えます。

<p>
Debian GNU/Linux マシンをブリッジファイアウォールとして、すなわち完全に
ネットワーク透過的で IP アドレスを持たず、それゆえに直接攻撃できない
フィルタリングファイアウォールとして設定することさえできます。

<p>
ファイアウォールについてよく知らないなら、<package>doc-linux-text</package>
パッケージの中にある Firewalling-HOWTO を読みましょう (他の文書形式も
利用できます)。くわしくは <ref id="references"> をごらんください。

<sect1 id="firewall-pack">ファイアウォールパッケージ

<p>
Debian システムでファイアウォール規則を設定するのに使える
ソフトウェアはいろいろあります:
<list>
<item><package>fwbuilder</package>
<item><package>mason</package>、これはあなたのシステムが「見た」ネットワーク
トラフィックにもとづいてファイアウォール規則を提案できます。
<item><package>bastille</package> (新バージョンの bastille に追加される
かもしれない強化過程には起動時に実行されるファイアウォール規則をシステムに
加える能力があります)
<item><package>ferm</package>
<item><package>fwctl</package>
<item><package>easyfw</package>
<item><package>firewall-easy</package>
<item><package>ipac-ng</package>
<item><package>gfcc</package>
<item><package>knetfilter</package>
<item><package>firestarter</package>
</list>

<p>
最後にあげたパッケージ、つまり gfcc、firestarter と knetfilter は
GNOME (はじめの 2 個) または KDE (最後の 1 個) を使う管理用の GUI です。
これはリスト中の管理者向けの他のパッケージよりずっとユーザ向け
(つまり、家庭ユーザ向け) です。

<p>
FIXME: これのパッケージについての情報をもっと加える

<p>
FIXME: Debian のファイアウォールについての情報と、それが他の
ディストリビューションとどこがどうちがうのか調べる

<p>
FIXME: 自家製のファイアウォールコードはどこで有効にされるべきか
(debian-firewall の一般的な FAQ か?)

<chapt>Debian システムを自動的に強化する
<p>
これまでの章にある情報を全部読んだら、「自分のシステムを強化するにはとても
多くのことをしなければならない、これを自動化できないか?」と思うかもしれません。
この質問への答えははいですが、自動化された道具には注意してください。
強化ツールを使ってもよい管理への必要性はなくならないと信じる人もいます。
この過程をすべて自動化して関連する問題をすべて修正できるとは考えないで
ください。セキュリティは管理者も遠くにいて道具にすべての仕事をさせるわけには
いかず、参加しなければならない進行中の過程です。なぜならどの道具もすべての
考えられるセキュリティポリシーの導入やすべての攻撃そしてすべての環境に対応する
ことはできないからです。

<p>
woody (Debian 3.0) 以降にはセキュリティ強化に役立つ特定のパッケージが 2 個
あります。<package>harden</package> はパッケージの依存にもとづいてすばやく
セキュリティ関連の価値あるパッケージをインストールし欠陥のあるパッケージを
削除する方法をとります。パッケージの設定は管理者が行わなければなりません。
<package>bastille</package> は管理者の以前の設定にもとづいてローカルシステムの
セキュリティポリシーを導入します (設定を構築することは簡単な yes/no の
質問にそって行うこともできます)。

<sect>Harden
<p>
<package>harden</package> パッケージはよいセキュリティを必要とするホストの
インストールや管理をより簡単にしようとします。このパッケージはシステムの
セキュリティを高めるのにすばやい助けがほしい人に用いられるべきです。これを
行うためにこのパッケージは既知の欠陥があるパッケージと対立します。欠陥には
(これだけではありませんが) 以下が含まれます: 既知のセキュリティ関連のバグ
(バッファオーバーフローなど)、平文パスワードの使用、アクセス制御の
欠如などです。またこのパッケージはセキュリティを何らかの方法で高める道具を
自動的にインストールします: 侵入検知ツール、セキュリティ解析ツールなどです。
Harden は以下の<em>仮想</em>パッケージ (つまり、中身がなくて、他の
パッケージへの依存関係だけのもの) をインストールします:

<list>

<item><package>harden-tools</package>: システムのセキュリティを高める
道具 (完全性チェッカー、侵入検知、カーネルパッチ...)

<item><package>harden-doc</package>: このマニュアルおよびその他の
セキュリティ関連の文書パッケージを提供します。

<item><package>harden-environment</package>: 強化された環境を設定するのを
助けます (現時点では空です)。

<item><package>harden-servers</package>: 何らかの理由で危険と考えられて
いるサーバを削除します。

<item><package>harden-clients</package>: 何らかの理由で危険と考えられて
いるクライアントを削除します。

<item><package>harden-remoteflaws</package>: リモートの攻撃者によって
システムを攻撃するのに利用され得る既知のセキュリティホールのあるパッケージを
削除します (バージョンつきの <em>Conflicts:</em> を使っています)。

<item><package>harden-localflaws</package>: ローカルの攻撃者によって
システムを攻撃するのに利用され得る既知のセキュリティホールのあるパッケージを
削除します (バージョンつきの <em>Conflicts:</em> を使っています)。

<item><package>harden-remoteaudit</package>: リモートからシステムを監査する
道具。

</list>

<p>
必要なソフトウェアがあって (そして何らかの理由でアンインストールしたくは
なくて)、それが上記のパッケージのどれかと対立していたら、
<package>harden</package> を完全に利用することはできないので注意してください。

harden パッケージは (直接には) 何もしません。しかし harden パッケージは
既知の安全でないパッケージと意図的に対立します。このようにすると、Debian の
パッケージシステムはこれらのパッケージをインストールすることを承認しなく
なります。たとえば、telnet デーモンを <package>harden-servers</package> と
ともにインストールしようとすると、apt はこう言うでしょう:

<example>
# apt-get install telnetd 
The following packages will be REMOVED:
        harden-servers
The following NEW packages will be installed:
telnetd 
Do you want to continue (Y/n)
</example>

<p>
これは管理者の頭の中で警告を目立たせるはずですし、管理者は自分の行動を
考えなおすでしょう。

<sect>Bastille Linux
<p>
<url name="Bastille Linux" id="http://www.bastille-unix.org"> はもともと
RedHat や Mandrake Linux ディストリビューション向けの自動強化ツールです。
しかし、Debian で (woody 以降) 提供される <package>bastille</package>
パッケージは同じ機能を Debian GNU/Linux システムで提供するためにパッチが
当てられています。

<p>
Bastille はいくつかのフロントエンドから使うことができます (Debian
パッケージではどれも独自のマニュアルページで文書化されています)。これは
管理者が以下のことをするのを可能にします:

<list>

<item>あなたのシステムで望むセキュリティについて段階ごとの質問に
答える (<manref name="InteractiveBastille" section="8"> を使って)

<item>与えられたセットアップ (サーバまたはワークステーション) における
セキュリティ (Lax、Moderate または Paranoia の 3 種類から選ぶ) に
対するデフォルトの設定を使って Bastille にどのセキュリティポリシーを
導入するか決めさせる (<manref name="BastilleChooser" section="8"> を使って)

<item>あらかじめ定義された設定ファイル (Bastille が提供するものでも、
管理者が作ったものでもよい) を使って与えられたセキュリティポリシーを
導入する (<manref name="AutomatedBastille" section="8"> を使って)

</list>

<chapt>Debian におけるパッケージへの署名
<p>
この章は「あなたの Debian GNU/Linyx システムを安全にアップグレード/更新する
方法」と名づけることもできます。これは独自の章にするに値します。主は理由は
これが他のどの章にもあてはまらないからです。

<p>
現時点 (2001 年 12 月) では Debian ディストリビューションには署名された
パッケージがありませんし、woody リリース (3.0) にもこの機能を統合する予定は
ありません。きっと次のリリースには署名されたパッケージへの解決策が
あるでしょう。

<sect>パッケージの署名チェックについての提案中のしくみ
<p>
現在の (実装されていない) apt を使ったパッケージの署名チェックのしくみは:

<list>
<item>Release ファイルは Packages.gz (パッケージの md5sum を含む) の
md5sum を含んでいて、署名されます。この署名は信用されているソースのひとつです。

<item>署名されている Release ファイルは「apt-get update」でダウンロードされ
Packages.gz とともにハードディスクに保存されます。

<item>パッケージがインストールされるときには、まずダウンロードされ、そして
md5sum が生成されます。

<item>署名された Release ファイルが (署名が正しいか) 調べられ、apt は
それから Packages.gz ファイルの md5sum を取りだします。Packages.gz の
チェックサムが生成され、(もし正しければ) ダウンロードされたパッケージの
md5sum がそこから取りだされます。

<item>ダウンロードされたパッケージの md5sum が Packages.gz にあるものと
等しければパッケージがインストールされ、そうでなければ管理者に警告が出され
パッケージはキャッシュに放置されます (よって管理者はそれをインストールするか
どうか決めることができます)。パッケージが Packages.gz になく、
チェックされたパッケージだけをインストールするように管理者が設定していたら
やはりインストールされません。
</list>

<p>
MD5 の鎖をたどることによって <prgn>apt</prgn> はパッケージが特定のリリースに
由来するものかどうか検証することができます。これは各パッケージにひとつずつ
署名するのより柔軟ではないですが、このしくみに組みあわせることができます
(以下をごらんください)。

<p>
パッケージへの署名は Debian で長い間議論されてきました。くわしくは以下を
ごらんください:
<!--
"ulink" will wcause errors
-->
<!--
<ulink url="http://www.debian.org/News/weekly/2001/8/"> と
<ulink url="http://www.debian.org/News/weekly/2000/11/"> です。
-->
<url id="http://www.debian.org/News/weekly/2001/8/"> と
<url id="http://www.debian.org/News/weekly/2000/11/"> です。

<sect>ほかのパッケージごとの署名のしくみ
<p>
パッケージのそれぞれに署名するしくみを追加すると残っている Packages ファイルで
もはや言及されていないパッケージを調べることが可能になります。また、
Packages が存在しない第三者のパッケージを  Debian で使うことも可能ですが、
これはデフォルトのしくみではないでしょう。

<p>
このパッケージへの署名のしくみは <package>debsig-verify</package> と
<package>debsigs</package> を使うことによって実装されます。この 2 個の
パッケージは .deb 自体にうめこまれた署名をしたり検証したりすることができます。
Debian にはすでにこれを行う能力があります。しかしポリシーや道具の実装は
(リリース周期をおくらせないようにするため) woody リリースのあとにしか
はじまらないでしょう。

<p>
注意: 現時点では <file>/etc/dpkg/dpkg.cfg</file> は「no-debsig」が
デフォルトになっています。

<sect>パッケージリリースを調べる
<p>
このセキュリティチェックをいま追加したいならば、Anthony Thown さんによっ
提供された以下のスクリプトを使うことができます。
このスクリプトは自動的に新しいセキュリティチェックを行って、自分が
ダウンロードしているソフトウェアが Debian が配布しているものと一致しているか
確かめることができます。
これは main アーカイブへアップロードすることによって提供される説明責任なしに
Debian の開発者がシステムをハックしたり、ミラーが Debian のパッケージと
似てはいるがそっくり同じではないものをミラーしたり、ミラーが既知のセキュリティ
問題のある時代おくれの unstable を提供したりすることを防ぎます。

<p>
このサンプルコードは名前を <prgn>apt-release-check</prgn> に変更されています。
以下のように使うべきです:
<example>
# apt-get update
# apt-release-check
(...results...)
# apt-get dist-upgrade
</example>

<p>
まず必要なのは:
<list>
<item>アーカイブのソフトウェアが Release ファイルに署名するのに使っている鍵、
つまり
<url id="
http://ftp-master.debian.org/ziyi_key_2002.asc">
を入手し、これを <file>~/.gnupg/trustedkeys.gpg</file> (これは
<prgn>gpgv</prgn> がデフォルトで使用します) に追加します。

<item>通常の「dists」構造を使わない行を <file>/etc/apt/sources.list</file> から
除くか、スクリプトを変更してそれらの行があってもうまくいくようにします。

<item>Debian のセキュリティ上の更新には署名された Release ファイルがないこと、
Release ファイルには Sources ファイルの適切なチェックサムが (まだ) ないことを
無視するようにします。

<item>適切なソースが適切な鍵によって署名されていることを確かめるようにします。

</list>


<example>
#!/bin/bash
# This script is copyright (c) 2001, Anthony Towns
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

rm -rf /tmp/apt-release-check
mkdir /tmp/apt-release-check || exit 1
cd /tmp/apt-release-check

>OK
>MISSING
>NOCHECK
>BAD

arch=`dpkg --print-installation-architecture`

am_root () {
        [ `id -u` -eq 0 ]
}

get_md5sumsize () {
        cat "$1" | awk '/^MD5Sum:/,/^SHA1:/' | 
          MYARG="$2" perl -ne '@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) { print "$f[1] $f[2]\n"; exit(0); }'
}
checkit () {
        local FILE="$1"
        local LOOKUP="$2"

        Y="`get_md5sumsize Release "$LOOKUP"`"
        Y="`echo "$Y" | sed 's/^ *//;s/  */ /g'`"

        if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
                if [ "$Y" = "" ]; then
                        # No file, but not needed anyway
                        echo "OK"
                        return
                fi
                echo "$FILE" >>MISSING
                echo "MISSING $Y"
                return
        fi
        if [ "$Y" = "" ]; then
                echo "$FILE" >>NOCHECK
                echo "NOCHECK"
                return
        fi
        X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`"
        X="`echo "$X" | sed 's/^ *//;s/  */ /g'`"
        if [ "$X" != "$Y" ]; then
                echo "$FILE" >>BAD
                echo "BAD"
                return
        fi
        echo "$FILE" >>OK
        echo "OK"
}

echo
echo "Checking sources in /etc/apt/sources.list:"
echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
echo
(echo "You should take care to ensure that the distributions you're downloading"
echo "are the ones you think you are downloading, and that they are as up to"
echo "date as you would expect (testing and unstable should be no more than"
echo "two or three days out of date, stable-updates no more than a few weeks"
echo "or a month)."
) | fmt
echo

cat /etc/apt/sources.list | 
  sed 's/^ *//' | grep '^[^#]' |
  while read ty url dist comps; do
        if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then
                baseurl="${url#*://}"
        else
                continue
        fi
        echo "Source: ${ty} ${url} ${dist} ${comps}"
        
        rm -f Release Release.gpg
        wget -q -O Release "${url}/dists/${dist}/Release"

        if ! grep -q '^' Release; then
                echo "  * NO TOP-LEVEL Release FILE"
        else
                origline=`sed -n 's/^Origin: *//p' Release | head -1`
                lablline=`sed -n 's/^Label: *//p' Release | head -1`
                suitline=`sed -n 's/^Suite: *//p' Release | head -1`
                codeline=`sed -n 's/^Codename: *//p' Release | head -1`
                dateline=`grep "^Date:" Release | head -1`
                dscrline=`grep "^Description:" Release | head -1`
                echo "  o Origin: $origline/$lablline"
                echo "  o Suite: $suitline/$codeline"
                echo "  o $dateline"
                echo "  o $dscrline"

                if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then
                        echo "  * WARNING: asked for $dist, got $suitline/$codeline"
                fi

                wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg"
                sigline="`gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] GOODSIG [0-9A-Fa-f]* //p"`"
                if [ "$sigline" ]; then
                        echo "  o Signed by: $sigline"
                else
                        echo "  * NO VALID SIGNATURE"
                        >Release
                fi
        fi
        okaycomps=""
        for comp in $comps; do
                if [ "$ty" = "deb" ]; then
                        X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Release" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Release")
                        Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Packages" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Packages")
                        if [ "$X $Y" = "OK OK" ]; then
                                okaycomps="$okaycomps $comp"
                        else
                                echo "  * PROBLEMS WITH $comp ($X, $Y)"
                        fi
                elif [ "$ty" = "deb-src" ]; then
                        X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Release" | sed 's,//*,_,g'`" "${comp}/source/Release")
                        Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Sources" | sed 's,//*,_,g'`" "${comp}/source/Sources")
                        if [ "$X $Y" = "OK OK" ]; then
                                okaycomps="$okaycomps $comp"
                        else
                                echo "  * PROBLEMS WITH component $comp ($X, $Y)"
                        fi
                fi
        done
        [ "$okaycomps" = "" ] || echo "  o Okay:$okaycomps"
        echo
  done

echo "Results"
echo "~~~~~~~"
echo

allokay=true

cd /tmp/apt-release-check
diff <(cat BAD MISSING NOCHECK OK | sort) <(cd /var/lib/apt/lists && find . -typ
e f -maxdepth 1 | sed 's,^\./,,g' | grep '_' | sort) | sed -n 's/^> //p' >UNVALIDATED

cd /tmp/apt-release-check
if grep -q ^ UNVALIDATED; then
    allokay=false
    (echo "The following files in /var/lib/apt/lists have not been validated."
    echo "This could turn out to be a harmless indication that this script"
    echo "is buggy or out of date, or it could let trojaned packages get onto"
    echo "your system."
    ) | fmt
    echo
    sed 's/^/    /' < UNVALIDATED
    echo
fi

if grep -q ^ BAD; then
    allokay=false
    (echo "The contents of the following files in /var/lib/apt/lists does not"
    echo "match what was expected. This may mean these sources are out of date,"
    echo "that the archive is having problems, or that someone is actively"
    echo "using your mirror to distribute trojans."
    if am_root; then 
        echo "The files have been renamed to have the extension .FAILED and"
        echo "will be ignored by apt."
        cat BAD | while read a; do
            mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
        done
    fi) | fmt
    echo
    sed 's/^/    /' < BAD
    echo
fi

if grep -q ^ MISSING; then
    allokay=false
    (echo "The following files from /var/lib/apt/lists were missing. This"
    echo "may cause you to miss out on updates to some vulnerable packages."
    ) | fmt
    echo
    sed 's/^/    /' < MISSING
    echo
fi

if grep -q ^ NOCHECK; then
    allokay=false
    (echo "The contents of the following files in /var/lib/apt/lists could not"
    echo "be validated due to the lack of a signed Release file, or the lack"
    echo "of an appropriate entry in a signed Release file. This probably"
    echo "means that the maintainers of these sources are slack, but may mean"
    echo "these sources are being actively used to distribute trojans."
    if am_root; then 
        echo "The files have been renamed to have the extension .FAILED and"
        echo "will be ignored by apt."
        cat NOCHECK | while read a; do
            mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
        done
    fi) | fmt
    echo
    sed 's/^/    /' < NOCHECK
    echo
fi

if $allokay; then
    echo 'Everything seems okay!'
    echo
fi

rm -rf /tmp/apt-release-check
</example>

<chapt>Debian でのセキュリティ関連の道具
<p>
FIXME: 内容がもっと必要。

<p>
Debian は Debian マシンをセキュリティ調査用にすることができるセキュリティ
関連の道具もいくつか提供しています。このうちのいくつかは
<package>harden-remoteaudit</package> パッケージをインストールすると
提供されます。

<sect>リモートの脆弱性を評価する道具
<p>
Debian によって提供される、リモートの脆弱性を評価するための道具は:
<list>
<item>nessus
<item>raccess
<item>whisker
<item>nikto (whisker の代替品)
<item>bass (non-free)
<item>satan (non-free)
<!-- currently uploaded but not included
<item>saint (non-free)
-->
</list>

<p>
断然、最も複雑で最新の道具は <package>nessus</package> です。これは
GUI として使われるクライアント (<package>nessus</package>) とプログラムされた
攻撃を行うサーバ (<package>nessusd</package>) で構成されています。
Nessus はネットワーク器具、ftp サーバ、www サーバなどの多くのシステムの
脆弱性の調査を含みます。最新のリリースはウェブサイトを解析してどの対話的な
ページが攻撃できるか発見しようすることさえできます。管理サーバに接触するのに
使える Java や Win32 クライアントも (Debian には含まれていませんが)
存在します。

<p>
<package>Whisker</package> は anti-IDS tactics (その多くはもはや
<em>anti-IDS</em> ではありませんが) を含むウェブの脆弱性だけを評価するスキャナ
です。これは利用可能な最高の CGI スキャナのひとつで、WWW サーバを検知して
指定された攻撃だけを行うことができます。スキャンに使われるデータベースは
新しい情報を提供するために容易に変更できます。

<p>
<package>Bass</package> (Bulk Auditing Security Scanner) と
<package>Satan</package> (Security Auditing Tool for Analysing Networks) は
監査を行うのに使う道具というよりむしろ「概念を証明する」プログラムと
考えるべきです。どちらも非常に古くて更新されていません。しかし、SATAN は
簡単な方法 (GUI) で脆弱性の調査を提供したはじめての道具ですし、Bass は
依然として非常に高性能の調査ツールです。

<sect>ネットワークをスキャンする道具
<p>
Debian はホストのリモートスキャンに使う (でも脆弱性の調査用ではない) 道具を
いくつか提供しています。場合によっては、利用できるリモートサービスを
知るてめにリモートのホストに対して行う最初の「攻撃」としてこれらの道具が
脆弱性を調査するスキャナによって使われます。現在 Debian が提供しているのは:
<list>
<item>nmap
<item>xprobe
<item>queso
<item>knocker
<item>hping2
<item>isic
<item>icmpush
<item>nbtscan
</list>

<p>
<package>queso</package> と <package>xprobe</package> が (TCP/IP 指紋を
使った) リモートのオペレーティングシステムの検知だけを提供するのに対して、
<package>nmap</package> と <package>knocker</package> はオペレーティング
システムの検知とリモートホストのポートスキャンの両方を行います。一方、
<package>hping2</package> と <package>icmpush</package> はリモートの
ICMP 攻撃技術に使えます。

<p>
Netbios ネットワークのために特に設計された <package>nbtscan</package> は
IP ネットワークをスキャンして SMB が有効になっているサーバからユーザ名、
ネットワーク名、MAC アドレス等の情報を引きだすことができます。

<sect>内部監査
<p>
現在、Debian で使われている <package>tiger</package> ツールだけが
ファイルシステムが適切に設定されているか、どのプロセスがそのホストで応答して
いるかなどを知るためにホストの内部の (white box とも呼ばれています) 監査を
行うのに利用できます。

<sect>ソースコードを監査する
<p>
C/C++ ソースコードプログラムを監査して潜在的なセキュリティ上の欠陥に
つながるかもしれないプログラム上のまちがいを見つけるのに利用できる
2 個のパッケージを Debian は提供しています:
<list>
<item>flawfinder
<item>rats
</list>

<sect>バーチャルプライベートネットワーク
<p>FIXME: 中身が必要

<p>
Debian は暗号化されたバーチャルプライベートネットワークを設置するための
パッケージを多く提供しています。

<list>

<item><package>vtun</package>
<item><package>tunnelv</package>
<item><package>cipe</package>
<item><package>vpnd</package>
<item><package>tinc</package>
<item><package>secvpn</package>
<item><package>pptp</package>
<item><package>freeswan</package>

</list>

<p>
この中では IPsec (すなわち、FreeSWAN) が最もよいでしょう。なぜなら IPsec を
動かしているほとんどすべてのマシンとともに動くことができるからです。しかし
他のパッケージも急いでいるときに安全なトンネルを得るのに役立ちます。PPTP は
VPN のための Microsoft プロトコルです。これは Linux でもサポートされて
いますが、深刻なセキュリティ問題があることがわかっています。

<p>
くわしくは
<url id="http://www.linuxdoc.org/HOWTO/VPN-Masquerade-HOWTO.html"
name="VPN-Masquerade HOWTO"> (IPsec と PPTP を扱っています)、
<url id="http://www.linuxdoc.org/HOWTO/VPN-HOWTO.html" name="VPN HOWTO">
(SSH 経由の PPP を扱っています) そして
<url id="http://www.linuxdoc.org/HOWTO/mini/Cipe+Masq.html"
name="Cipe mini-HOWTO">、
<url id="http://www.linuxdoc.org/HOWTO/mini/ppp-ssh/index.html"
name="PPP and SSH mini-HOWTO"> をごらんください。

<sect>公開鍵インフラストラクチャー (Public Key Infrastructure、PKI)
<p>
PKI について検討すると広範囲の道具に直面することになります:

<list>
<item>証明書を配布したり指定された序列のもとで働くことができる
証明書機関 (Certificate Authority)

<item>ユーザの公開証明書を保存するディレクトリ

<item>証明書破棄リストを維持するデータベース (?)

<item>安全に証明書を保存する目的でスマートカード、usb トークンなどに
出力するために CA と共同で動くことができるデバイス

<item>
暗号化されたコミュニケーションで登録したり、証明書を CRL に対して調べる
(認証や full Single Sign On solutions のために) 目的で CA によって
配布された証明書を使うことができる、証明書対応のアプリケーション

<item>文書に電子的に署名するための消印機関

<item>これらすべてを適切に使える (証明書の発行、破棄リスト制御など)
管理コンソール

</list>

<p>
これらの道具のいくつかをカバーするために Debian GNU/Linux で利用可能な
ソフトウェアを使うことができます。これには openSSL (証明書生成のために)、
OpenLDAP (証明書を保存するディレクトリとして)、gnupg および freeswan
(X.509 とともに) サポートです。しかし、Debian オペレーティングシステムは
(woody リリース、3.0 の時点では) pyCA, <url id="http://www.openca.org"
name="OpenCA"> または OpenSSL の CA サンプルのようなフリーに入手できる
証明書機関を提供していません。くわしくは <url
id="http://ospkibook.sourceforge.net/" name="Open PKI book"> を
ごらんください。

<sect>対ウイルスツール
<p>
Debian には対ウイルスツールはそれほど多くありません。たぶん GNU/Linux が
現在のところあまりウイルスに感染していないからでしょう。しかし、Debian
ディストリビューション全体に広まったウイルスが (幸運にもまだ) ないにも
かかわらず、GNU/Linux のワームやウイルスは存在しています。いずれにせよ、
管理者は対ウイルスゲートウェイを構築するか、自分自身をウイスルから守ろうと
したいでしょう。

<p>
Debian は対ウイルス環境を構築するために現在以下のような道具を提供しています。
<list>
<item><url id="http://packages.debian.org/sanitizer" name="sanitizer">、
procmail から呼び出して電子メールをフィルタリングし、ウイルスを
除去する道具です。
<item><url id="http://packages.debian.org/amavis-postfix"
name="amavis-postfix">、メールトランスポートエージェントからひとつまたは
複数のウイルススキャナへのインターフェイスを提供するスクリプトです
(このパッケージは postfix 版を提供します)。
</list>

<p>
ごらんのとおり、Debian は現時点では対ウイルスソフトウェア自体は提供して
いません。しかし、Debian に (将来) 入るかもしれないフリーソフトウェア
対ウイルスプロジェクトが存在します。
<url id="http://sourceforge.net/projects/openantivirus/" name="openantivirus">
および 
<url id="http://sourceforge.net/projects/jvirus/" name="jvirus">
(こちらは可能性が低いかもしれません。というのもこれは完全に Java にもとづいて
いるからです) です。また、Debian は以下のような商用対ウイルスソフトウェアを
提供することは決してしないでしょう:
<url id="http://www.pandasoftware.com/com/linux/linux.asp"
name="Panda Antivirus">、
<url id="http://www.nai.com/naicommon/buy-try/try/products-evals.asp"
name="NAI Netshield (uvscan)">、
<url id="http://www.sophos.com/" name="Sophos Sweep">、
<url id="http://www.antivirus.com/products/" name="TrendMicro Interscan">、
<url id="http://www.ravantivirus.com" name="RAV"> などです。
くわしくは
<url id="http://www.computer-networking.de/~link/security/av-linux_e.txt"
name="Linux antivirus software mini-FAQ"> をごらんください。

<p>
ウイルス検知システムを設定する方法についてくわしくは Dave Jones さんの記事
<url id="http://www.linuxjournal.com/article.php?sid=4882"
name="Building an E-mail Virus Detection System for Your Network"> を
ごらんください。

<chapt>システムを破られる前

<sect id="intrusion-detect">侵入検知を設定する
<p>
FIXME: これについてさらに書く。

<p>
Debian には侵入検知のための道具がいくつか含まれています。あなたはローカル
システムを守るために (あなたが本当にパラノイアだったり、あなたの
システムが本当に重要だったりするなら)、または同じネットワークの他の
システムを守るためにこれを設置したくなるかもしれません。

<p>
これらの道具を導入することによってシステムのセキュリティを本当に
向上させるためには、警告と応答を組みあわせたしくみが必要であることにいつも
注意してください。よってだれにも警告する気がないなら侵入検知を使わないように
しましょう (つまり、あとで使う予定のないものを設定するのに時間をむだに
使わないようにしましょう)。

<p>
侵入検知ツールの大部分は検知された特定の攻撃に関して syslog にログを残すか
root ユーザに電子メールを送るか (大部分はかわりに他のユーザにメールを
送るように設定できます) します。管理者は false positive が警告を
送らないように、そして警告が適切に扱われるように適切に侵入検知ツールを
設定しなければなりません。警告は進行中の攻撃を示すかもしれませんし、
たとえば 1 日後には役に立たないかもしれません。なぜなら攻撃がすでに成功して
いるかもしれないからです。したがって警告を扱うのに関して適切なポリシーを
持つように、またそれを実施するための技術的なしくみが適切な場所にあるように
してください。

<p>
<url id="http://www.cert.org/tech_tips/intruder_detection_checklist.html"
name="CERT's Intrusion Detection Checklist"> は
興味深い情報源です。

<sect1>ネットワークベースでの侵入検知
<p>
<package>snort</package> は攻撃署名辞書を使って攻撃を検知する柔軟な
パケット盗聴ソフトであるとともに記録ソフトでもあります。snort は
バッファオーバーフロー、ステルスポートスキャン、CGI 攻撃、SMB 攻撃、そして
その他多くのさまざまな攻撃や探知を検知します。Snort はリアルタイムでの
警告能力を持っています。これはネットワークを監視するためにすべてのルータに
インストールするべき道具です。<tt>apt-get install snort</tt> で
インストールし、質問に答えて snort がログを取るのをみはりましょう。

<p>
Debian の Snort は必要かもしれない多くのセキュリティチェックが有効になって
います。しかし、あなたのシステムで動いている特定のサービスを考慮して
設定をカスタマイズするべきです。これらのサービスに特有の追加のチェックを
検索したいかもしれません。

<p>
あなたのネットワークのホストのためのネットワーク侵入検知設置するために
<prgn>snort</prgn> を使うこともできますし、あなた自身のホストへの
ネットワーク攻撃を検知するために使うこともできます。

<p>
(より単純ではありますが) ネットワーク攻撃を検知するのに使える他の道具も
あります。<package>Portsentry</package> はあなたのサイトに対してスキャンが
行われたときに警告してくれる興味深いパッケージのひとつです。
<package>ippl</package> や <package>iplogger</package> のような他の道具も
(snort のように) ネットワーク攻撃の検知などの進んだ技術は提供しないものの
いくつかの IP (TCP および ICMP) 攻撃を検知します。

<p>
<prgn>idswakeup</prgn> プログラムを使ってこれらの道具のどれでもためすことが
できます。これは Debian で利用可能な多くの一般的な攻撃署名を使って NIDS に
警告する false-positive 生成器です。

<sect1>ホストベースでの検知
<p>
<package>Tiger</package> は woody ディストリビューション以降 Debian に
移植された古い侵入検知ツールです。Tiger はセキュリティ破りに関係する
一般的なチェックを提供し、パスワードの強度、ファイルシステムの問題、
やりとりしているプロセスなどを調べます。Debian 版は Debian 特有の新しい
セキュリティチェックを含みます: 与えられたバイナリの MD5sum、インストール
されている脆弱なパッケージのチェックです。デフォルトのインストールでは
<prgn>tiger</prgn> は毎日動き、スーパユーザに送られる報告を生成します。
生成された報告はシステムへの成功した攻撃についての情報を与えることもできます。

<p>
<package>logcheck</package> のようなサイト上のログ監査ツールもいくつか
あります。このツールはもし管理者にローカルファイルシステムでの異常な
できごとについて警告するように適切に設定されていればとても便利です。
<prgn>Logcheck</prgn> はログから回収された注目する価値のあるできごとに
もとづいてメールを送るように完全に設定できます。デフォルトのインストールでは
3 種類 (workstation、server そして paranoid) の無視するできごとおよび
ポリシー違反のファイルを含みます。logcheck の Debian パッケージは logcheck
プログラムによって読みこまれる設定ファイル
<file>/etc/logcheck/logcheck.conf</file> を含みます。
これはチェックの結果がどのユーザに送られるかを定義します。また logcheck の
Debian パッケージはサービスを提供するパッケージが以下のディレクトリに
新しいポリシーを導入する方法を提供します:
<file>/etc/logcheck/hacking.d/_packagename_</file>、
<file>/etc/logcheck/violations.d/_packagename_</file>、
<file>/etc/logcheck/violations.ignore.d/_packagename_</file>、
<file>/etc/logcheck/ignore.d.paranoid/_packagename_</file>、
<file>/etc/logcheck/ignore.d.server/_packagename_</file> そして
<file>/etc/logcheck/ignore.d.workstation/_packagename_</file>です。しかし、
現時点ではそれほど多くのパッケージがそうするわけではありません。他のユーザに
とって便利なポリシーを持っているなら、適切なパッケージにバグ報告として
送ってください。くわしくは <file>/usr/share/doc/logcheck/README.Debian</file>
をごらんください。

<p>
ファイルシステムの完全性チェッカー (<ref id="check-integ"> をごらんください)の
ようなサイト上の監査ツールも安全な環境での異常を検知するのにとても
便利でしょう。有効な侵入はローカルのセキュリティポリシーを出し抜く、トロイの
木馬をインストールする、ユーザを作るなどの目的でほぼ確実にローカルの
ファイルシステム中のファイルを変更します。これらのできごとは完全性チェッカーで
検知できます。

<package>logcheck</package>、<package>portsentry</package> や
ファイルシステムの完全性チェッカー (<ref id="check-integ"> をごらんください)の
ようなサイト上の監査ツールも安全な環境での異常を検知するのにとても
便利でしょう。

<sect id="kernel-patches">役に立つカーネルパッチ
<p>
FIXME: この章は kernel-2.x.x-patch-XXX パッケージを使ってこれらの特定の
パッチを Debian でインストールする方法を扱う必要がある。

<p>
システムのセキュリティをとても高めるカーネルパッチがいくつかあります。
そのうちのいくつかをあげると:
<list>

<item>Solar Designer による OpenWall パッチ。これは制限つきのリンク、
<file>/tmp</file> 中の FIFO、制限つきの <file>/proc</file>、
file descriptor の特別な扱い、
実行不可能なユーザスタック領域などのカーネルの制限の便利なセットです。
ホームページ:
<url name="http://www.openwall.com/linux/" id="http://www.openwall.com/linux/">

<item><em>Huagang Xie &amp; Philippe Biondi による LIDS &mdash;
Linux intrusion detection system</em>。このパッチは強化された Linux
システムを作る過程をより簡単にします。どのプロセスを制限することも
できますし、プロセスにファイルを読んだり書きこんだりする権利を与えたり、
デフォルトでファイルを読む能力を取りのぞいたりできます。さらに特定の
プロセスの能力を設定することもできます。まだベータ版であるにもかかわらず、
パラノイアのシステム管理者にはほとんど必須です。ホームページ:
<url
name="http://www.lids.org" id="http://www.lids.org">

<item><em>POSIX Access Control Lists (ACLs) for Linux</em>
このパッチはファイルへのアクセスを制限する進んだ方法であるアクセス
制御リストを linux カーネルにを追加します。ホームページ:
<url
name="http://acl.bestbits.at/" id="http://acl.bestbits.at/">

<item><em>Linux trustees</em>。このパッチは Linux カーネルによくできた
進んだパーミッションシステムを提供します。オブジェクトはすべてカーネル
メモリに保存されるので、すべてのパーミッションをすばやく参照できます。
ホームページ: <url name="http://trustees.sourceforge.net/" 
id="http://trustees.sourceforge.net/">

<item><em>International kernel patch</em>。これは暗号関連のカーネルパッチ
なので、暗号使用についてのあなたの地元の法律に注意しなければなりません。
これはだいたい暗号化されたファイルシステムを使う能力を追加します。
ホームページ: <url
name="http://www.kerneli.org" id="http://www.kerneli.org">

<item><em>SubDomain</em>。より安全で設定しやすい chroot 環境を作るための
カーネルの拡張です。chroot されたサービスに必要なファイルを手動で指定する
ことができ、そのサービスを静的にコンパイルする必要がありません。
ホームページ:
<url
name="http://www.immunix.org/subdomain.html"
id="http://www.immunix.org/subdomain.html">

<item><em>UserIPAcct</em>。これは本当はセキュリティ関連のパッチでは
ありませんが、サーバのトラフィックにユーザごとに quota をもうけることを
可能にします。そしてユーザのトラフィックについての統計を得ることができます。
ホームページ: <url name="http://ramses.rsmeyers.be/useripacct"
id="http://ramses.smeyers.be/useripacct">

<item><em>FreeS/WAN</em>. IPSec を Linux で使いたいならば、このパッチが
必要です。これを使うと VPN を Windows マシンに対してさえきわめて簡単に
作ることができます。というのも IPSec は共通の規格だからです。ホームページ:
<url
name="http://www.freeswan.org" id="http://www.freeswan.org">

</list>


<sect>rootkits を避ける
<p>

<sect1 id="LKM">LKM - Loadable Kernel Modules
<p>
LKM (Loadable Kernel Modules) は動的にロードできるカーネルの部品を含む
ファイルです。これは指示されたタスクを実行するためにカーネルに動的に
ロードすることができます。GNU/Linux ではカーネルの機能を拡張するために
使われます。LKM を使うといくつかの利点が得られます。カーネル全体を
再コンパイルすることなく動的にロードできる、デバイスドライバ (または
ファイルシステム) やサウンドカード、ネットワークカードなどのその他の
ハードウェアドライバを指定するのに使えるなどです。しかしクラッカーは
GNU/Linux システムに裏口をインストールするために LKM を rootkit
(knark や adore) に使うかもしれません。

<p>
LKM rootkits はソースコードやバイナリを変更することなくプロセス、ファイル、
ディレクトリそして接続さえも隠すことができます。たとえば、<prgn>ps</prgn> は
プロセス情報を <file>/proc</file> から取得していたかもしれません。悪意のある
LKM はカーネルを破って、バイナリ <prgn>ps</prgn> の健全なコピーでさえも
正しいプロセス情報をすべて表示できないように procfs から特定のプロセスを
隠すことができます。

<sect1>rootkits を発見する
<p>
この発見作業はあなたが選ぶ対策しだいで単純かつ楽にもなり得ますし、困難かつ
退屈にもなり得ます。LKM セキュリティに関する防御には 2 種類の対策があります。
事前の対策と事後の対策です。

<sect2>事前の対策
<p>
この防御の利点は lkm rootkit のいくつかがシステムに被害を与えるのを防ぐ点です。
最もよく使われる事前の対策は「先まわりする」、すなわち悪意のある LKM によって
システムが被害を受ける前にシステムを保護するために特定の LKM をロードする
方法です。他の対策はカーネルから機能を取り除き、システムをより安全にする
ことです。たとえば、機能を取り除くことによってカーネルモジュールをロードしたり
アンロードしたりするのを停止することができます。

<p>
Debian システムには事前対策の道具であるパッケージがいくつかあります:
<list>
<item> <package>kernel-patch-2.4-lsm</package> - LSM is the Linux Security
Modules framework.

<item> <package>lcap</package> - Removes 'capabilities' in the kernel, making
the system more secure
</list>

<p>
あなたの GNU/Linux システムで多くのカーネル機能を本当に必要としてはいないなら、
カーネル設定のときにロード可能なモジュールのサポートを無効にしたいかも
しれません。これは LKM rootkit を防ぎますが、あなたの GNU/Linux でカーネル
モジュール機能を使うことができなくなります。ロード可能なモジュールを停止する
ことによってカーネルを過負荷にする可能性があります。これが必要でないときも
あります。

<p>
ロード可能なモジュールのサポートを停止するには、単に <file>.config</file> で
CONFIG_MODULES=n と設定してください。

<sect2>事後の防御
<p>
事後の防御の利点はシステムの資源に対する負荷がすくないことです。これは
システムコールテーブルをディスクファイル中の既知のきれいなコピー
(System.map) と比較することによって働きます。最も明白な欠点はこの方法は
管理者にシステムが破られた後にしか報告しない点です。

<p>
Debian では rootkit の検知は <package>chkrootkit</package> で行えます。これは
ローカルファイルシステムの rootkit の印を調べて対象のコンピュータが rootkit に
感染しているかを示します。

<p>
<url name="SKAT" id="http://s0ftpj.org/en/site.html"> を使うこともできます。
SKAT はカーネルメモリ領域 (<file>/dev/kmem</file>) を調べて対象のホストに
ついての情報を調べます。この情報には Loadable Kernel Modules のインストール
情報が含まれます。

<p>
FIXME: lkm サポートなしのカーネルをコンパイルする方法についての情報を
追加する?

<sect>天才的な、またはパラノイアのアイデア &mdash; 何ができるか
<p>
これはたぶん最も不安定で楽しい章でしょう。なぜなら私はこの「お、これは
狂ってる」的な考えが実現してほしいからです。以下にはセキュリティを急速に
向上させるいくつかの考え &mdash; これを天才的、パラノイア、狂っている、
安全なのどれというかはあなたの考えかたしだいです &mdash; がありますが、
無事ではすまないかもしれません。

<list>
<item>PAM で遊ぶ。
phrack 56 号の PAM についての記事で述べられているように、PAM のよいところは
「何を思いつけるかだけにしか制限されない」ことです。これは本当です。root の
ログインが指紋確認または眼底検査または暗号カードでしかできないとしたら
どうでしょうか。(なぜここで「かつ」ではなく「または」という接続詞を
使ったのでしょうか?)

<item>ファシストのログ。
上でログについて述べたことはすべて「ソフト的な記録」だといえます。本物の記録を
行いたいならば、fanfold paper つきのプリンタを入手し、印刷することによって
何もかもハード的に記録しましょう。ばかげているように聞こえるでしょうが、
これは信頼できますし、削除することができません。

<item>CD ディストリビューション。
この考えは実現するのがとても簡単ですし、とてもよいセキュリティを提供します。
適切なファイアウォール規則をそなえた強化された Debian ディストリビューションを
作り、その ISO イメージを作って CD に焼きましょう。それをブート可能に
しましょう。これはサービス用に約 600 MB のスペースを持つ読みとり専用の
ディストリビューションです。そして侵入者はこのシステム上では読み書きの
アクセスを得ることができません。書きこまれるべきデータはすべてネットごしに
書きこまれるようにだけ気をつけてください。ともかく、侵入者はファイアウォールの
規則や経路制御のエントリを変更することができませんし、新しいデーモンを起動する
こともできません (可能ではありますが、再起動すれば侵入者はシステムを変更する
ためにまた侵入しなければなりません)。

<item>モジュール能力を停止する。
カーネルのコンパイル時にカーネルモジュールの使用を停止すると、カーネルベースの
裏口の多くは導入することができなくなります。なぜならその多くは変更された
カーネルモジュールをインストールすることにもとづいているからです。

<item>シリアルケーブルを通じてのログ (Gaby Schilders さんによって
提供されました)。
サーバにシリアルポートがあるならば、serial-port multiplexer (cyclades または
同様のもの) をそなえた、ネットから切断された専用のログマシンを中央に
置くことを考えましょう。そしてすべてのサーバがシリアルポートへログを出力する
ようにしましょう。書きこむだけです。ログマシンはシリアルポートでプレイン
テキストだけを入力として受けつけ、それをログファイルに書きこむだけです。
cd または dvd ライタを接続しましょう。ログファイルが 600 MB 近くになったら、
それを cd-rom に書きこみます。ここで cd ライタにオートチェンジャを取りつけ
さえすれば... プリンタほどのハードコピーではありませんが、より大容量を
扱えますし、 cd は保管場所をそれほど取りません。

<item>何もかも immutable に設定 (Jim Dennis さんによって書かれた
Tips-HOWTO から取られました)。
システムをインストールして設定したらすぐ <file>/bin</file>、
<file>/sbin/</file>、<file>/usr/bin</file>、<file>/usr/sbin</file> そして
<file>/usr/lib</file> (さらに他のいつも気になるところ) に移動して思いきって
<prgn>chattr +i command</prgn> しましょう。さらにルートにあるカーネル
ファイルにもそれを追加しましょう。そして <prgn>mkdir /etc/.dist/</prgn> して、
<file>/etc/</file> の中身全部をそのディレクトリにコピーしましょう (私は
再帰を避けるためこれを <file>/tmp/etcdist.tar</file> を
使って 2 段階に分けて行っています)。
(単に <file>/etc/.dist.tar.gz</file> を作ってもいいです。) -- そして
それを immutable にしましょう。

<p>
これらすべてを行う理由は root としてログインしたときにありえる被害を制限する
ためです。迷子のリダイレクト演算子でファイルを上書きすることもありませんし、
<prgn>rm -fr</prgn> コマンドにまちがった空白を入れてシステムを使用不能に
することもありません (データに多大な被害をもたらすことはできます &mdash;
しかしライブラリとバイナリはより安全でしょう)。

<p>
これはまたさまざまなセキュリティをもたらし、サービス拒否攻撃を不可能にするか
よりむずかしくします (なぜならその多くは <em>任意のシェルコマンドを提供して
いるわけではない</em> SUID されたプログラムの行動によってファイルを上書き
することに依存するからです)。

<p>
これによってただひとつ不便になるのはシステムのさまざまなバイナリを構築して
<prgn>make install</prgn> するときです。一方でこれは
<prgn>make install</prgn> がファイルを上書きすることも防ぎます。Makefile を
読むのを忘れて上書きされるべきファイル (およびファイルを追加したい
ディレクトリ) に chattr -i しないでいると
<!--
&dash; doesn't work
-->
&mdash; make は失敗します。
chattr コマンドを使って再度実行しなければなりません。この機会に古いバイナリや
ライブラリその他を .old/ ディレクトリに移動させるなり名前を変えるなり
tar するなりすることもできます。

<p>
これはシステムのパッケージをアップグレードすることもさまたげることに注意して
ください。そのパッケージが提供するファイルを上書きすることはできないので、
<prgn>apt-get update</prgn> する直前にすべてのバイナリから immutable flag を
はずすしくみがほしくなるかもしれません。

</list>

<sect1>honeypot を構築する
<p>
FIXME。Debian 特有の内容がさらに必要。

<p>
もし望むなら (そしてそれを実装することができて、それに時間を使えるなら)
Debian GNU/Linux システムを使って完全な honeypot を設置することができます。
honeynet (つまりネットワークのことです。honeypot は偽のサーバだけを指します)
を設置するのに必要な道具はすべてあります。ファイアウォール、
ネットワーク侵入検知ソフトそして偽のサーバです。しかし、注意してください。
十分に見終わったらすぐに適切な手段を取って攻撃を終わらせることができるように
間にあううちに警告を受けられるようにしなければなりません
(<ref id="log-alerts"> をごらんください)。

<list>

<item>必要なファイアウォール技術 (Linux カーネルで提供されます)。

<item>honeypot からリモートの syslog サーバマシンへログを送るのに
<package>syslog-ng</package>。

<item>外部から honeypot へのネットワークトラフィックをすべてとらえて
攻撃を検知するために <package>snort</package>。

<item><package>osh</package>、これは記録機能つきの制限されたシェルを
設定するのに使えます (下にある Lance Spitzner さんの記事をごらんください)。

<item>もちろん、偽のサーバである honeypot のための思いつくかぎりのサーバ
(ただし honeypot を強化<em>しない</em>ように)。

<item>そして honeypot を侵入検知サービスとしても使いたいのならば、
<package>dtk</package> で提供される偽のサービスも。

<item>攻撃後の監査のために完全性チェッカ (<ref id="check-integ">を
ごらんください) および The Coroner's Toolkit (<package>tct</package>)。

</list>

<p>
honeypot を構築することについてくわしくは Lanze Spitzner さんのすばらしい記事
<url id="http://www.net-security.org/text/articles/spitzner/honeypot.shtml"
name="To Build a Honeypot"> (Know your Enemy シリーズより)、または
David Raikow さんの <url
id="http://www.zdnetindia.com/techzone/resources/security/stories/7601.htm"
name="Building your own honeypot">
をごらんください。
また、<url id="http://project.honeynet.org/" name="Honeynet Project"> は
honeypot を構築したりそれに対して行われた攻撃を監査したりするための専門
プロジェクトです。ここには honeypot を設置する方法や攻撃の結果を監査する
方法についての価値ある情報があります (コンテストをごらんください)。

<chapt>システムを破られた後

<sect>一般的な行動
<p>
攻撃が行われている現場に物理的にいあわせたならば、そしてもしこうしても
商取引に悪影響をもたらさないならば、侵入者が何をしたか調べてシステムを
安全にするまで NIC を単にはずしましょう。ネットワークを layer 1 の段階で
停止することは攻撃者を破られたシステムから締め出すただひとつの本当の方法です。
(Phillip Hofmeister さんの賢明な助言です。)

<p>
侵入から本当にはやく復旧したいならば、破られたホストをネットワークから
取りのぞいてはじめから OS を再インストールするべきです。侵入者がどうやって
root を手に入れたのかわからなければこれにはたぶん何の効果もないかもしれません。
この場合は何もかも調べなければなりません: ファイアウォール、ファイルの完全性、
ログホストのログファイルなどです。侵入のあとで何をするべきかについてくわしくは
<url name="Sans' Incident Handling Guide"
id="http://www.sans.org/y2k/DDoS.htm"> または
<url id="http://www.cert.org/tech_tips/root_compromise.html"
name="CERT's Steps for Recovering from a UNIX or NT System Compromise">
をごらんください。

<sect>システムのバックアップを取る
<p>
システムが破られたことがわかっているならその中のソフトウェアもそれが返す
どんな情報も信用できないことに注意してください。アプリケーションがトロイの
木馬化されたかもしれませんし、カーネルモジュールがインストールされている
かもしれません、などなど。

<p>
最もよいのは安全なメディアからブートしたあと (<prgn>dd</prgn> を使って)
ファイルシステムの完全なバックアップコピーを取ることです。Debian GNU/Linux
CD はこのために便利に使えます。なぜならそれはインストールがはじまったとき
コンソール 2 でシェルを提供するからです (Alt+2 を使い、Enter を押して移動して
ください)。このシェルはシステムがオフラインである間に (または、再インストール
中に) 解析するために情報を他の場所へ (NFS/FTP 経由でネットワークファイル
サーバへ、など) バックアップするのに使うことができます。

<p>
トロイの木馬化されたカーネルモジュールしかないとわかっているなら、CD の
カーネルイメージを <em>rescue</em> モードで動かしてみることができます。
カーネルのあとで他のトロイの木馬プロセスが動かないように<em>シングル</em>
モードで起動するようにしてください。

<sect>科学捜査
<p>
さらに多くの情報を集めたいならば、<package>tct</package> (Dan Farmer と
Wietse Venema による The Coroner's Toolkit) パッケージにはシステムの
「検死解剖」を行うユーティリティが含まれています。
<package>tct</package> はユーザが削除されたファイル、動いているプロセスなどに
ついての情報を集めることを可能にします。くわしくは付属文書をごらんください。

<p>
科学捜査は常にデータのバックアップコピーに対して行うべきです。データ
そのものに対して行っては<em>いけません</em>。なぜならデータが解析中に
変更されるかも (そして失われるかも) しれないからです。

<p>
FIXME。この段落には将来の Debian システムでの科学捜査についての情報を
もっと提供できたらと思う。

<p>
FIXME: CD 上の md5sum に対して、そして別のパーティションに復旧された
ファイルシステムに対して安定版システム上で debsums をどう使うか述べる。

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

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

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

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

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

<sect1>Debian にはセキュリティ関連の証明書がありますか?
<p>
単純な答え: いいえ。

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

<sect1>Debian に強化用プログラムはありますか?
<p>
あります。もともと他の Linux ディストリビューション (RedHat と Mandrake)
向けだった <url name="Bastille Linux" id="http://www.bastille-unix.org"> は
現在では Debian で動きます。加えられた変更を上流のバージョンに統合するために
作業が行われています。いずれにせよ Debian のパッケージはもちろん
<package>bastille</package> という名前です。

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

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

<sect1>Debian のすべてのパッケージは安全ですか?
<p>
Debian security team は Debian に含まれるすべてのパッケージについて潜在的な
セキュリティ上の脆弱性を調べることはできません。なぜならプロジェクト全体の
ソースコード監査を行うために十分な資源がないからです。しかし、 Debian は
上流開発者または
<url name="Linux Kernel Security Audit Project"
id="http://kernel-audit.sourceforge.net/"> や
<url name="Linux Security-Audit Project" 
id="http://www.lsap.org/">
などのプロジェクトによって行われるソースコード監査の恩恵を受けています。

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

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

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

<sect2>システムユーザはすべて必要ですか?
<p>
はいといいえの両方です。新サービスのインストールが簡単になるように
(これらはすでに適切なユーザで動いています)、Debian にはいくつかのサービスの
ためにはじめから定義されたユーザ (<url name="Debian Policy"
id="http://www.debian.org/doc/debian-policy/"> に説明されて
いるように、id が 99 以下です) があります。もしこれらの新しいサービスを
インストールするつもりがないなら、あなたのシステムでどのファイルも所有して
おらずどのサービスも動かしていないユーザを安全に削除することができます。

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

<!-- Took the liberty to make this script more secure ... >:^) // era -->
<example>
cut -f 1 -d : /etc/passwd |
while read i; do find / -user "$i" | grep -q . && echo "$i"; done
</example>

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

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

<list>

<item>root:
  Root は (典型的には) スーパユーザです。

<item>daemon:
  ディスク上のあるファイルに書きこむことができる必要がある非特権デーモンの
  中には daemon.daemon として動くものがあります (portmap、atd そして他にも
  あるでしょう)。どのファイルも所有する必要がないデーモンはかわりに
  nobody.nogroup として動かすことができます。そしてより複雑かまたはより
  セキュリティに気をつけるべきデーモンは専用のユーザで動きます。
  daemon ユーザはたぶんローカルでインストールしたデーモンにも便利でしょう。

<item>bin: 
  歴史的な理由から維持されています。

<item>sys:
  bin と同様です。しかし、/dev/vcs* と <file>/var/spool/cups</file> は
  sys グループによって所有されています。

<item>sync:
  sync ユーザのシェルは <file>/bin/sync</file> です。したがって、
  もしそのパスワードが
  推測しやすいもの (「」とか) に設定されていれば、だれでもたとえその
  システムにアカウントを持っていなくてもコンソールでシステムの同期を
  取ることができます。

<item>games:
  ゲームの多くはハイスコアファイルに書きこむことができるように games に
  sgid されています。これはポリシーで説明されています。

<item>man:
  man プログラムは (ときどき) cat ページを <file>/var/cache/man</file> に
  書きこめるように man ユーザとして動きます。

<item>lp:
  プリンタデーモンによって利用されます。

<item>mail:
  <file>/var/mail</file> の中のメールボックスはポリシーで説明されているように
  mail グループによって所有されています。このユーザやグループはさまざまな
  MTA で他の目的にも利用されています。

<item>news:
  さまざまなニュースサーバや (suck のような) その他の関連するプログラムは
  news ユーザおよびグループをさまざまな方法で使います。ニューススプールの
  中のファイルはしばしば news ユーザおよび グループによって所有されます。
  ニュースに投稿するのに使える inews などのプログラムは典型的には news に
  sgid されます。

<item>uucp:
  uucp ユーザおよびグループは UUCP サブシステムで使われます。uucp は
  スプールおよび設定ファイルを所有しています。uucp グループのユーザは
  uucico を実行できます。

<item>proxy:
  daemon と同様に、このユーザおよびグループは専用のユーザ id がなくて
  ファイルを所有する必要のあるいくつかのデーモン (特に、プロキシデーモン) に
  利用されます。たとえば、proxy グループは pdnsd に利用されていますし、
  squid は proxy ユーザとして動きます。

<item>majordom:
  Majordomo は歴史的な理由から Debian システムで静的な uid を割りあてられて
  います。これは新しいシステムにはインストールされません。

<item>postgres:
  Postgresql データベースはこのユーザおよびグループに所有されています。
  <file>/var/lib/postgresql</file> の中のすべてのファイルは適切な
  セキュリティを実施するためにこのユーザによって所有されています。

<item>www-data:
  ウェブブラウザの中には www-data として動くものがあります。ウェブの内容は
  このユーザに所有されるべきでは「ありません」。そうでないと破られた
  ウェブサーバがウェブサイトを書きかえることができてしまうでしょう。
  ウェブサーバによって書かれたデータはログファイルも含めて www-data に
  所有されます。

<item>backup:
  バックアップや修復の責任を完全な root 権限を持たない人にローカルで
  まかせられるように。

<item>list:
  メーリングリストのアーカイブとデータはこのユーザおよびグループによって
  所有されます。いくつかのメーリングリストプログラムもこのユーザで動きます。

<item>irc:
  irc デーモンに利用されます。静的に割りあてられたユーザが必要なのは
  単に ircd のバグのせいです -- ircd は起動時に与えられた UID に自分自身を
  setuid() します。

<item>gnats。

<item>nobody, nogroup:
  どのファイルも所有する必要がないデーモンはユーザ nobody、グループ
  nogroup として動きます。したがって、システムのどのファイルもこのユーザ
  またはグループに所有されるべきではありません。

</list>

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

<list>

<item>adm:
  adm グループはシステム監視の仕事に使われます。このグループのメンバーは
  <file>/var/log</file> の中の多くのログを読むことができますし、
  xconsole を使うことが
  できます。歴史的には、<file>/var/log</file> は
  <file>/usr/adm</file> でした (そのあと <file>/var/adm</file> に
  なりました)。これがこのグループの名前の由来です。

<item>tty:
  Tty デバイスがこのグループに所有されています。これは他の人の tty に
  書きこめるようにするために write や wall に使われています。

<item>disk:
  ディスクへの生アクセスです。root アクセスとほぼ等価です。

<item>kmem:
  /dev/kmem および同様のファイルをこのグループは読むことができます。
  これはだいたい BSD の歴史の遺物ですが、システムメモリを直接読みこむ
  必要があるプログラムは kmem に sgid することができます。

<item>dialout:
  シリアルポートへの直接かつ完全なアクセスです。このグループのメンバーは
  モデムを再設定したりすきな場所に電話したりといったことができます。

<item>dip:
  このグループの名前は「Dialup IP」を表します。このグループに所属していると
  ダイヤルアップ接続のために <prgn>ppp</prgn>、<prgn>dip</prgn>、
  <prgn>wvdial</prgn> などの道具を使うことができます。このグループのユーザは
  モデムを設定することはできません。モデムを利用するプログラムを実行できる
  だけです。

<item>fax:
  メンバーがファックスを送ったり受けとったりするためのソフトウェアを
  使えるようにします。

<item>voice:
  Voicemail です。モデムを留守番電話として利用するシステムにとって
  便利です。

<item>cdrom:
  このグループは何人かのユーザに cdrom ドライブへアクセスさせるのに
  ローカルで使えます。

<item>floppy:
  このグループは何人かのユーザにフロッピードライブへアクセスさせるのに
  ローカルで使えます。

<item>tape:
  このグループは何人かのユーザにテープドライブへアクセスさせるのに
  ローカルで使えます。

<item>sudo:
  このグループのメンバーは sudo を使うときにパスワードを入力する必要が
  ありません。<file>/usr/share/doc/sudo/OPTIONS</file> をごらんください。

<item>audio:
  このグループは何人かのユーザにオーディオデバイスへアクセスさせるのに
  ローカルで使えます。

<item>src:
  このグループは <file>/usr/src</file> の中のファイルを含むソースコードを
  所有しています。src はユーザにシステムのソースコードを管理する能力を
  与えるのにローカルで使えます。

<item>shadow:
  このグループは <file>/etc/shadow</file> を読むことができます。この
  ファイルにアクセスできる必要があるプログラムは shadow に set gid されて
  います。

<item>utmp:
  このグループは <file>/var/run/utmp</file> および同様のファイルに書きこむ
  ことができます。これに書きこめる必要があるプログラムは utmp に
   sgid されています。
 
<item>video:
  このグループは何人かのユーザにビデオデバイスへアクセスさせるのに
  ローカルで使えます。

<item>staff:
  ユーザがシステムに root の特権なしでローカルの変更を加えることが
  できるようにします。これをより監視やセキュリティに関連した「adm」
  グループと比較してください。

<item>users:
  Debian システムはユーザグループシステム (それぞれのユーザが自分のグループを
  持つ) をデフォルトで使いますが、より伝統的なグループシステムを使いたい人が
  いるかもしれません。そのようなシステムでは、各ユーザは「users」グループの
  メンバーです。

</list>

<sect2>adm グループと staff グループのちがいは何ですか?
<p>

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

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

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

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

<sect2>inetd を削除することはできますか?
<p>
Inetd を削除することは簡単ではありません。なぜなら
<package>netbase</package> がそれを提供するパッケージ
(<package>netkit-inetd</package>) に依存するからです。inetd を削除したいなら
それを停止することもできますし (<ref id="disableserv"> をごらんください)、
<package>equivs</package> パッケージを使ってそのパッケージを削除する
こともできます。

<sect2>なぜ 111 番ポートは開いていますか?
<p>
111 番ポートは sunrpc の portmapper です。これは Debian システムのすべての
base インストールでデフォルトでインストールされます。なぜならユーザの
プログラムが正しく動くのにいつ RPC が必要か知る必要はないからです。
いずれにせよ、こえは主に NFS に使われます。もし必要ないのなら、
<ref id="rpc"> で説明されているようにそれを削除してください。

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

<p>
これに関しては広範囲にわたる議論があります。
<url id="http://lists.debian.org/debian-security/2001/debian-security-200108/msg00297.html"
name="mailing list archives"> をごらんください。基本的にそれを何に使うか
知らないなら、起動しないようにしてください。しかしそれをファイアウォールで
遮断するならば、<em>どうか</em>それを deny ルールではなく reject ルールに
してください。そうしないと timeout 時間がつきるまでやりとりが止まるかも
しれません  (<url id="http://logi.cc/linux/reject_or_deny.php3"
name="reject or deny issues"> をごらんください)。

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

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

<sect1>パスワードがわからなくなって、システムにアクセスできません!
<p>
ここから回復するために必要な手段は Lilo や BIOS を制限するためにここで
提案された手続きを適用したかどうかに依存します。

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

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

<item>レスキューディスクからブートしてカーネルを起動します

<item>仮想コンソールへ移動します (Alt + F2)

<item>/root のあるハードディスクをマウントします

<item><file>/etc/shadow</file> を編集して (Debian 2.2 のレスキューディスクには
<prgn>ae</prgn> がついてきます。Debian 3.0 には <prgn>vi</prgn> に似た
<prgn>nano-tiny</prgn> がついてきます) この行を:

<example>
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X はどんな番号でもいいです)
</example>

<p>
こう変更します:

<example>
root::XXXX:X:XXXX:X:::
</example>

</list>

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

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

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

<item>システムの BIOS が終わる直前に Alt キー、シフトキーまたは
コントロールキーを押す。LILO プロンプトが出るはずです。

<item>プロンプトで「linux single」、「linux init=/bin/sh」または「linux 1」と
入力します。

<item>シングルユーザモードでシェルプロンプトが出るはずです
(パスワードを聞かれますが、すでにそれを知っているはずです)

<item>/ パーティションを読み書き両用で再マウントします
<example>
mount -o remount,rw /
</example>

<item>スーパユーザのパスワードを <prgn>passwd</prgn> で変更します
(あなたはスーパユーザなので以前のパスワードは聞かれません)

</list>

<sect>私のシステムは脆弱です!
<p>

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

<sect1>どうやったら攻撃を追跡できますか?
<p>
ログを見ること (もしそれが変更されていないなら)、侵入検知システムを
使うこと (<ref id="intrusion-detect"> をごらんください)、
<prgn>traceroute</prgn>、<prgn>whois</prgn> その他の道具 (科学捜査を
含みます) を使うことによって、攻撃を発生源まで追跡できます。この情報に
どう反応するべきかはあなたのセキュリティポリシーに、そして <em>あなたが</em>
何を攻撃と考えるかにのみ依存します。リモートスキャンは攻撃でしょうか?
脆弱性探査は攻撃でしょうか?

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

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

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

<sect1>ログの中でユーザが「su」しているのを発見しました。
<p>
ログの中にこのような行があるかもしれません:
<example>
 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)
</example>

<p>
あまり気にしないでください。これが cron 経由で実行されるジョブ (ふつうは
<file>/etc/cron.daily/find</file> か <prgn>logrotate</prgn> です) によるものか
確かめてください:
<!--
yes, the upstream uses newline in the middle of crontab without backslash
-->
<example>
$ 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
</example>

<sect1>特定のソフトウェア

<sect2>Proftpd はサービス否定攻撃に脆弱です
<p>
<tt>DenyFilter \*.*/</tt> を設定ファイルに加えてください。くわしくは
<url id="http://www.proftpd.org/critbugs.html"> をごらんください。

<sect>Debian security team に関する質問

<!-- FIXME: update from web page -->

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

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

<sect1>Debianの勧告についている署名が正しく検証されません!
<p>
これはたぶんあなたの側の問題です。debian-security-announce メーリングリストは
security team メンバーの正しい署名のあるメッセージだけが投稿できるような
フィルタを持っています。

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

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

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

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

<p>
報告
<url id="http://lists.debian.org/debian-security/2001/debian-security-200
112/msg00257.html" name="published in the debian-security mailinglist">
によると 2001 年には Debian Security Team がセキュリティ関連の脆弱性を
修正するのに平均で 35 日かかりました。しかし、 50% 以上の脆弱性は
10 日以内に修正され、 15% 以上が勧告が発表された<em>その日</em>に
修正されています。

<p>
しかし、この質問をするときには以下のことを忘れがちです:
<list>
<item>DSA は以下が終わるまで送られません:
<list>
<item>Debian でサポートされている<em>すべての</em>アーキテクチャで
パッケージが利用可能になる (システムの中核の一部であるパッケージでは
これにはいくらか時間がかかります。特に安定版リリースでサポートされている
アーキテクチャの数を考えると)
<item>バグが全く導入されないことを確実にするために新パッケージは徹底的に
テストされます
</list>
<item>DSA が送られる前にパッケージが利用可能かもしれません (imcoming queue で、
またはミラーで)。
<item>Debian はボランティアベースのプロジェクトです。
<item>Debian に与えられたライセンスの一部である「無保証」条項があります。
</list>

<sect1><tt>testing</tt> や <tt>unstable</tt> のセキュリティはどう扱われて
いますか?
<p>
短い答えは: 扱われていません。Testing や unstableは急速に変化していて、
security team はこれらを適切にサポートするのに必要な資源を持っていません。
もし安全な (そして安定した) サーバがほしいなら安定版にとどまることを
強く推奨します。

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

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

<!-- FIXME:
Q: I've seen DSA 100 and DSA 102, now where is DSA 101?
A: Several vendors (mostly of GNU/Linux, but also of BSD
   deriviates) coordinate security advisories for some incidents and
   agree to a particular timeline so that all vendors are able to

   advisory could be released, and hence temporarily leaving out one or
   more advisories by number.
-->

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

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

<sect1>どうすれば Debian security team に貢献できますか?
<p>
<list>
<item>FIXME を修正するなり新しい内容を提供するなりして、この文書に貢献する
ことによって。文書は重要ですし、一般的な問題に答える負荷を減らします。
この文書を他の言語に翻訳することも大きな助けになります。

<item>Debian システム上で、または Debian システムを使ううえでセキュリティを
提供したりセキュリティを調べたりするのに役に立つアプリケーションを
パッケージ化することによって。もし開発者でないなら、<url name="WNPP bug"
id="http://www.debian.org/devel/wnpp/"> を提出して、役に立つと思っていて
まだ提供されていないソフトウェアを要求しましょう。

<item>Debian のアプリケーションを監査するか、セキュリティ関連のバグを
解決するのを助けて問題を security@debian.org に報告しましょう。
<url name="Linux Kernel Security Audit Project"
id="http://kernel-audit.sourceforge.net/"> や
<url name="Linux Security-Audit Project"
id="http://www.lsap.org/"> のような他のプロジェクトの仕事は
Debian GNU/Linux のセキュリティを向上させます。なぜならこのような貢献は
いずれは Debian をも助けることになるからです。

</list>

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

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

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

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

<appendix>段階ごとの強化過程

<!--
# I took the liberty to change this from "checklist" to
# "process step by step" because this doesn't really have the
# form of a checklist, and I had added a different sort of
# checklist. The renaming is more to avoid confusion than
# anything else. // era
-->

<p>
きまった手順はいつも役に立ちます。なぜならそれはシステム強化過程全体を
わかるようにするとともにあなたが判断できるようにするからです。
Debian 2.2 GNU/Linux でのこのような手順として可能なもののひとつが
以下に示されています。これはインストール後の手順です。設定中に取るべき
手段についての段階ごとのチュックリストは<ref id="checklist"> をごらんください。
さらに、この手順は (現時点では) ネットワークサービスの強化により向いている
ものです。

<list>

<item>システムのインストールを行いましょう (パーティション分割についての
この howto の情報を考慮してください)。base インストールが終わったら
手動でのインストールに進みましょう。task パッケージを選ばす、shadow
パスワードを選びましょう。

<item><prgn>dselect</prgn> を行い、[I]nstall の前に不要だが選択されている
パッケージを削除しましょう。本当に最小限のソフトウェアだけをサーバに
残しましょう。

<item><ref id="update"> ですでに説明されているように security.debian.org で
利用できる最新のパッケージすべてを更新しましょう。

<item>ユーザ quota、ログインの定義や lilo など、このマニュアルで示されて
いる提案を導入しましょう。

<item>サービス強化のために、いまあなたのシステムで動いているサービスの
リストを作りましょう。
<example>
$ ps -aux
$ netstat -pn -l -A inet 
$ /usr/sbin/lsof -i | grep LISTEN
</example>

3 番目のコマンドがうまくいくためには <package>lsof-2.2</package> をインストール
する必要があるでしょう (root として実行してください)。lsof は LISTEN という
単語をあなたのロケールの設定にあわせて翻訳するかもしれないことに注意する
べきです。

<item>不要なサービスを取りのぞくために、まずそれがどうやって起動されているか、
どのパッケージがそれを提供しているか調べてください。これはソケットに
応答しているプログラムを調べることによって簡単に行うことができます。
以下の例はこの道具と <prgn>dpkg</prgn> を使って調べます

<example>
#!/bin/sh
# FIXME: this is quick and dirty; replace with a more robust script snippet
for i in `sudo lsof -i | grep LISTEN | cut -d " " -f 1 |sort -u` ; do
        pack=`dpkg -S $i |grep bin |cut -f 1 -d : | uniq`
        echo "Service $i is installed by $pack";
        init=`dpkg -L $pack |grep init.d/ `
        if [ ! -z "$init" ]; then
                 echo "and is run by $init"
        fi
done
</example>

<item>望まないサービスを見つけたら、そのパッケージを
(<prgn>dpkg --purge</prgn> で) 削除するか、役には立つが起動時には有効に
なるべきではないならば、それをシステムの起動から取りのぞくのに
<prgn>update-rc.d</prgn> を使いましょう (<ref id="disableserv"> を
ごらんください)。

<item>inetd のサービス (スーパーデーモンから起動されるもの) については
有効なサービスをすぐに調べることができます。たとえばこのようにして:

<example>
$ grep -v "^#" /etc/inetd.conf | sort -u
</example>

そして不要なものをその行をコメントアウトするなりパッケージを削除するなり
<prgn>update-inetd</prgn> を使うなりして停止しましょう。

<item>ラップされたサービス (<prgn>/usr/sbin/tcpd</prgn> を使うもの) が
あれば、<file>/etc/hosts.allow</file> と <file>/etc/hosts.deny</file> が
あなたのサービスポリシーにしたがって設定されていることを確かめましょう。

<item>可能であれば、サービスによっては、外部インターフェイスが複数あるとき
そのうちひとつだけに応答するように制限したいかもしれません。たとえば、
内部で FTP アクセスがほしいならば FTP デーモンを自分の管理インターフェイス
だけに応答するようにして、すべてのインターフェイス (すなわち、
0.0.0.0:21) には応答しないようにしましょう。

<item>マシンを再起動するか、シングルユーザに移行してこのようにして
マルチユーザに戻りましょう。

<example>
$ init 1
(....)
$ init 2
</example>

<item>サービスがいまでも利用可能か調べて、もし必要ならば、上記の手順を
くりかえしましょう。

<item>そしてまだインストールしていないなら必要なサービスをインストールし、
適切に設定しましょう。

<item>利用可能なサービスを動かすのにどのユーザが使われているか
調べましょう。たとえばこのようにして:
<example>
$ for i in `/usr/sbin/lsof -i |grep LISTEN |cut -d " " -f 1 |sort -u`; do user=`ps -ef |grep $i |grep -v grep |cut -f 1 -d " "` ; echo "Service $i is running as user $user"; done
</example>

そしてセキュリティを向上させるためにこれらのサービスを与えられたユーザや
グループに変更したりそしてひょっとしたら chroot することも検討しましょう。
これは <file>/etc/init.d</file> スクリプトを変更することによって可能です。
ここでサービスが起動します。Debian のサービスのほとんどは
<prgn>start-stop-daemon</prgn> を使うのでこれらのサービスを設定するのに
--change-uid オプションや --chroot オプションが使えます。サービスを
chroot するのはこの文書の範囲をこえていますが、警告が一言必要です:
dpkg -L を使ってそのサービスのパッケージによってインストールされたファイル
全部と、それが依存するパッケージを chroot された環境に入れる必要が
あるかもしれません。

<item>望むサービスだけが動いていて、それも望むユーザやグループの組みあわせで
動いているのを確かめるため上記の手順をくりかえしましょう。

<item>期待どおりに動いていることを確かめるためインストールされている
サービスをテストしましょう。

<item>システムの脆弱性 (設定ミス、古いサービスまたは不要なサービス) を
調べるために (<package>nessus</package> のような) 脆弱性評価スキャナを使って
システムを調べましょう。

<item>(<package>snort</package> や <package>logsentry</package> のような)
ネットワーク侵入対策やホスト侵入対策をインストールしましょう。

<item>ネットワークスキャナの手順をくりかえして侵入検知システムがきちんと
動いているかどうか検証しましょう。

</list>

本物のパラノイアのためには、以下も考慮しましょう:

<list>

<item>ファイアウォール能力をシステムに追加して、外部からの接続を
提供されているサービスへのみ受けいれ、外部への接続を公認のものだけに
制限しましょう。

<item>自分のシステムから外部のホストへの接続をネットワークスキャナを
使って調べ、望まない接続が出ていかないことを検証しましょう。

</list>

<p>
FIXME: この手順はサービスの強化は考慮しているがユーザレベルでの
システム強化を考慮していない。ユーザのパーミッションや setuid された
ファイルの確認、それに ext2 ファイルシステムを使ってシステムの変更を凍結する
ことについての情報を含める。

<appendix id="checklist">設定チェックリスト
<p>
この補遺はこのマニュアルの他の章の要点を凝縮されたチェックリスト形式で
簡潔にくりかえします。これはこのマニュアルをすでに読んだ人のための手みじかな
要約のつもりです。他にもよいチェックリストはあります。Kurt Seifried さんは
<url id="http://seifried.org/security/os/linux/20020324-securing-linux-step-by-step.html" name="Securing Linux Step by Step"> に
もとづく設定を持っています。

<!-- FIXME: Add pointer to Unix Security Checklist (CERT) -->

<!-- Order is slightly different from body text. Consider changing text? -->
<!-- (FIXME) -->

<p>
FIXME: これはこのマニュアルの v1.4 にもとづいていて、更新の必要があるかも
しれない。

<list>
  <item>物理的なアクセスやブートの能力を制限する
    <list>
      <item>BIOS パスワードを有効にする
      <item>フロッピーや cdrom などでのブートを無効にする
      <item>LILO か GRUB のパスワードを設定する (それぞれ
            <file>/etc/lilo.conf</file> か <file>/boot/grub/menu.lst</file>)。
            LILO か GRUB の設定が読みとり保護されているか調べる。
      <item>MBR を上書きして MBR のフロッピーでのブートの裏口を禁止する
            (ひょっとしたら禁止しない?)
    </list>
  <item>パーティションの分割
    <list>
      <item>ユーザが書きこめるデータ、Debian システムでないデータそして
            急速に変化するランタイムのデータを独自のパーティションに分ける
      <item><file>/tmp</file> などの ext2 パーティションで
            <tt>nosuid,noexec,nodev</tt> マウントオプションを
            <file>/etc/fstab</file> で設定する
    </list>
  <item>パスワードの衛生およびログインのセキュリティ
    <list>
      <item>よい root パスワードを設定する
      <item>パスワードの shadow 化と MD5 を有効にする
      <item>PAM をインストールして使う
        <list>
          <item>PAM に MD5 サポートを追加して (一般的に言って)
                <file>/etc/pam.d/</file> ファイルのマシンへのアクセスを
                認める項目についてその pam.d で 2 番目の
                フィールドが <!-- or is it third? (FIXME: check) -->
                「requisite」か「required」に設定されているようにする
          <item>ローカルからだけ root のログインを許可するように
                <file>/etc/pam.d/login</file> をいじる
          <item>さらに <file>/etc/security/access.conf</file> に
                公認されている tty を記して一般的に root ログインをできるだけ
                制限するようこのファイルを設定する
          <item>ユーザごとの制限を設定したいなら pam_limits.so を追加する
          <item><file>/etc/pam.d/passwd</file> をいじる: パスワードの最小の
                長さを大きくし (6 文字かも) md5 を有効にする
          <item>望むなら <file>/etc/group</file> に wheel を追加する。
                pam_wheel.so group=wheel の項目を <file>/etc/pam.d/su</file> に
                追加する
          <item>独自のユーザごとの制御には、pam_listfile.so の項目を適切な
                場所で使う
          <item><file>/etc/pam.d/other</file> ファイルを作り、セキュリティを
                きつく設定する
        </list>
      <item><file>/etc/security/limits.conf</file> で制限を設定する (PAM を
            使っているなら <file>/etc/limits</file> は使われないことに注意)
      <item><file>/etc/login.defs</file> をきつくする。さらに、もし MD5
            または PAM またはその両方を有効にしているなら、ここでも対応する
            変更を行う
      <item>root での ftp アクセスを <file>/etc/ftpusers</file> で禁止する
      <item>ネットワーク経由の root ログインを禁止する。<manref
            name="su" section="1"> か <manref name="sudo" section="1"> を
            使う (<package>sudo</package> のインストールを検討する)
      <item>ログインをさらに制限するのに PAM を使う?
    </list>
  <item>その他のローカルのセキュリティ問題
    <list>
      <item>カーネルをいじる (<ref id="kernel-conf"> 参照)
      <item>カーネルパッチ (<ref id="kernel-patches"> 参照)
      <item>ログファイルのパーミッションをきつくする
            (<file>/var/log/{last,fail}log</file>、Apache logs)
      <item><file>/etc/checksecurity.conf</file> で setuid チェックが
            有効になっていることを検証する
      <item>chattr でログファイルを追加専用にして設定ファイルを immutable に
            することを検討する (ext2 ファイルシステム専用)
      <item>ファイルの完全性を設定する (<ref id="check-integ"> 参照)。
            <package>debsums</package> をインストールする
      <item>locate を slocate で置きかえることを検討する
      <item>何もかもローカルのプリンタで記録する?
      <item>設定を CD に焼いてそこからブートする?
      <item>カーネルモジュールを無効にする?
    </list>
  <item>ネットワークアクセスを制限する
    <list>
      <item><prgn>ssh</prgn> をインストールして設定する
            (<file>/etc/ssh/sshd_config</file> で PermitRootLogin No、
            PermitEmptyPasswords No にすることを提案。本文中の他の
            提案も参照)
      <item>in.telnetd を停止するか削除することを検討する
      <item>一般的に、<tt>update-inetd --disable</tt> を使って
            <file>/etc/inetd.conf</file> 中の不要なサービスを停止する
            (または、inetd も停止するか、xinetd や rlinetd などの
            代用品を使う)
      <item>ほかの不要なサービスを停止する。メール、ftp、DNS、www などは
            必要としていないか常時監視しないなら動かすべきではない
      <item>必要なサービスに対しては、単に最も一般的なプログラムを
            使うのではなく、Debian から (またはその他のところから)
            入手できるより安全なバージョンを調べる。何を動かすにせよ、
            リスクを理解するようにする
      <item>外部のユーザやデーモンに檻を設定する
      <item>ファイアウォールや tcpwrapper (すなわち、
            <manref name="hosts_access" section="5">)を設定する。
            本文中の <file>/etc/hosts.deny</file> のトリック参照
      <item>ftp を動かすなら、つねにユーザのホームディレクトリに
            chroot された状態で動くように ftpd サーバを設定する
      <item>X を動かすなら、xhost 認証を禁止してかわりに ssh を使う。
            よりよいのは、もし可能ならリモートの X を禁止することだ
            (-nolisten tcp を X のコマンドラインに加え、
            <file>/etc/X11/xdm/xdm-config</file> 中で requestPort を
            0 に設定して XDMCP を無効にする)
      <item>外部からプリンタへのアクセスを禁止する
      <item>IMAP または POP のセッションをすべて SSL または ssh を
            通じて行う。このサービスをリモートのメールユーザに
            提供したいなら stunnel をインストールする
      <item>ログホストを設置して他のマシンがログをそのホストに送るように
            設定する (<file>/etc/syslog.conf</file>)
      <item>BIND、Sendmail などの複雑なデーモンを安全にする
            (chroot の檻の中で動かす。root でない仮ユーザで動かす)
      <item>snort などの記録ツールをインストールする
      <item>もし可能なら NIS や RPC なしですます (portmap を停止する)。
    </list>
  <item>ポリシーの問題
    <list>
      <item>ポリシーがなぜあるか、どんなポリシーかについてユーザを
            教育する。他のシステムでふつう利用可能なものを禁止するときは、
            他のより安全な手段を使って同様の結果を達成する方法を説明する
            文書を提供する
      <item>平文パスワードを使うプロトコル (telnet、rsh およびその一族。
            ftp、imap、http など) を禁止する
      <item>SVGAlib を使うプログラムを禁止する
      <item>ディスク quota を使う
    </list>
  <item>セキュリティ問題についての情報を得る
    <list>
      <item>セキュリティ関連のメーリングリストを講読する
      <item>セキュリティの更新を講読する --
            <file>/etc/apt/sources.list</file> に
            http://security.debian.org/debian-security への項目
            (複数かも) を追加する
      <item>さらに <prgn>apt-get update ; apt-get upgrade</prgn> を
            <ref id="update"> で説明されているように周期的に
            実行するようにする (もしかしたら cron job として
            インストールする?)
    </list>

</list>

<appendix id="snort-box">独立の IDS を設置する
<p>
独立の侵入検知システム (Intrusion Detection System) として
<package>snort</package> を使って専用の Debian マシンを簡単に設置する
ことができます。

<p>
いくつかのガイドライン:
<list>
<item>ベース Debian システムをインストールし、他にパッケージを追加しないように
しましょう。

<item>必要なパッケージをダウンロードし、手動で (dpkg を使って)
インストールしましょう (以下のインストールずみパッケージリストを
ごらんください)。

<item>ACID (Analysis Console for Intrusion Databases) をダウンロードして
インストールしましょう。

</list>

<p>
ACID は現在 <package>acidlab</package> として Debian パッケージに
なっています。これは snort の出力への
グラフィカル WWW インターフェイスを提供します。これは
<url id="http://www.cert.org/kb/acid">、
<url id="http://acidlab.sourceforge.net"> または
<url id="http://www.andrew.cmu.edu/~rdanyliw/snort/"> からダウンロード
できます。
<url id="http://www.linuxdoc.org/HOWTO/Snort-Statistics-HOWTO/index.html"
name="Snort Statistics HOWTO"> を読みたくなるかもしれません。

<p>
このシステムをすくなくとも 2 種類のインターフェイスで設置できます: 一方の
インターフェイスは (結果にアクセスしシステムを維持するための) 管理 lan に
接続し、もう一方の ip-address なしのインターフェイスは解析するネットワーク
セグメントに接続します。

<p>
ip-address なしのネットワークカードを設定するには標準の Debian の
<file>/etc/network/interfaces</file> は使えません。なぜなら
<prgn>ifup</prgn> と <prgn>ifdown</prgn> はそこに必要以上の情報があることを
期待するからです。単に <tt>ifconfig eth0 up</tt> とする必要があります。

<p>
ACID を動かすためには標準の Debian インストールに加えて、Apache、MySQL
そして PHP4 が必要です。ダウンロードしたパッケージ (注: バージョンはあなたが
どの Debian ディストリビューションを使っているかによって異なります。これは
Debian <em>woody</em> 2001 年 9 月のものです):

+<example>
ACID-0.9.5b9.tar.gz
adduser_3.39_all.deb
apache-common_1.3.20-1_i386.deb
apache_1.3.20-1_i386.deb
debconf_0.9.77_all.deb
dialog_0.9a-20010527-1_i386.deb
fileutils_4.1-2_i386.deb
klogd_1.4.1-2_i386.deb
libbz2-1.0_1.0.1-10_i386.deb
libc6_2.2.3-6_i386.deb
libdb2_2.7.7-8_i386.deb
libdbd-mysql-perl_1.2216-2_i386.deb
libdbi-perl_1.18-1_i386.deb
libexpat1_1.95.1-5_i386.deb
libgdbmg1_1.7.3-27_i386.deb
libmm11_1.1.3-4_i386.deb
libmysqlclient10_3.23.39-3_i386.deb
libncurses5_5.2.20010318-2_i386.deb
libpcap0_0.6.2-1_i386.deb
libpcre3_3.4-1_i386.deb
libreadline4_4.2-3_i386.deb 
libstdc++2.10-glibc2.2_2.95.4-0.010703_i386.deb
logrotate_3.5.4-2_i386.deb
mime-support_3.11-1_all.deb
mysql-client_3.23.39-3_i386.deb
mysql-common_3.23.39-3.1_all.deb
mysql-server_3.23.39-3_i386.deb
perl-base_5.6.1-5_i386.deb
perl-modules_5.6.1-5_all.deb
perl_5.6.1-5_i386.deb
php4-mysql_4.0.6-4_i386.deb
php4_4.0.6-1_i386.deb
php4_4.0.6-4_i386.deb
snort_1.7-9_i386.deb
sysklogd_1.4.1-2_i386.deb
zlib1g_1.1.3-15_i386.deb
</example>

<p>
インストールされているパッケージ (dpkg -l):
<example>
ii  adduser        3.39
ii  ae             962-26
ii  apache         1.3.20-1
ii  apache-common  1.3.20-1
ii  apt            0.3.19
ii  base-config    0.33.2
ii  base-files     2.2.0
ii  base-passwd    3.1.10
ii  bash           2.03-6
ii  bsdutils       2.10f-5.1
ii  console-data   1999.08.29-11.
ii  console-tools  0.2.3-10.3
ii  console-tools- 0.2.3-10.3
ii  cron           3.0pl1-57.2
ii  debconf        0.9.77
ii  debianutils    1.13.3
ii  dialog         0.9a-20010527-
ii  diff           2.7-21
ii  dpkg           1.6.15
ii  e2fsprogs      1.18-3.0
ii  elvis-tiny     1.4-11
ii  fbset          2.1-6
ii  fdflush        1.0.1-5
ii  fdutils        5.3-3   
ii  fileutils      4.1-2   
ii  findutils      4.1-40
ii  ftp            0.10-3.1
ii  gettext-base   0.10.35-13
ii  grep           2.4.2-1
ii  gzip           1.2.4-33
ii  hostname       2.07
ii  isapnptools    1.21-2
ii  joe            2.8-15.2  
ii  klogd          1.4.1-2   
ii  ldso           1.9.11-9   
ii  libbz2-1.0     1.0.1-10
ii  libc6          2.2.3-6
ii  libdb2         2.7.7-8
ii  libdbd-mysql-p 1.2216-2
ii  libdbi-perl    1.18-1
ii  libexpat1      1.95.1-5
ii  libgdbmg1      1.7.3-27
ii  libmm11        1.1.3-4
ii  libmysqlclient 3.23.39-3
ii  libncurses5    5.2.20010318-2
ii  libnewt0       0.50-7  
ii  libpam-modules 0.72-9
ii  libpam-runtime 0.72-9  
ii  libpam0g       0.72-9
ii  libpcap0       0.6.2-1
ii  libpcre3       3.4-1   
ii  libpopt0       1.4-1.1
ii  libreadline4   4.2-3 
ii  libssl09       0.9.4-5   
ii  libstdc++2.10  2.95.2-13 
ii  libstdc++2.10- 2.95.4-0.01070
ii  libwrap0       7.6-4   
ii  lilo           21.4.3-2
ii  locales        2.1.3-18
ii  login          19990827-20
ii  makedev        2.3.1-46.2
ii  mawk           1.3.3-5
ii  mbr            1.1.2-1 
ii  mime-support   3.11-1 
ii  modutils       2.3.11-13.1
ii  mount          2.10f-5.1
ii  mysql-client   3.23.39-3
ii  mysql-common   3.23.39-3.1
ii  mysql-server   3.23.39-3
ii  ncurses-base   5.0-6.0potato1
ii  ncurses-bin    5.0-6.0potato1
ii  netbase        3.18-4  
ii  passwd         19990827-20
ii  pciutils       2.1.2-2
ii  perl           5.6.1-5   
ii  perl-base      5.6.1-5   
ii  perl-modules   5.6.1-5
ii  php4           4.0.6-4   
ii  php4-mysql     4.0.6-4 
ii  ppp            2.3.11-1.4
ii  pppconfig      2.0.5
ii  procps         2.0.6-5   
ii  psmisc         19-2   
ii  pump           0.7.3-2 
ii  sed            3.02-5 
ii  setserial      2.17-16
ii  shellutils     2.0-7
ii  slang1         1.3.9-1  
ii  snort          1.7-9
ii  ssh            1.2.3-9.3
ii  sysklogd       1.4.1-2
ii  syslinux       1.48-2
ii  sysvinit       2.78-4  
ii  tar            1.13.17-2  
ii  tasksel        1.0-10 
ii  tcpd           7.6-4     
ii  telnet         0.16-4potato.1
ii  textutils      2.0-2  
ii  update         2.11-1    
ii  util-linux     2.10f-5.1
ii  zlib1g         1.1.3-15  
</example>

