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


Fernández-Sanguino Peña Javier [FAMILY Given]

<jfs@debian.org>

Copyright © 2012 The Debian Project

GNU General Public License Notice: This work is free documentation: 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 work 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.

You should have received a copy of the GNU General Public License along
with this program. If not, see http://www.gnu.org/licenses/.

概要

この文書では Debian のデフォルトのインストールを安全にし強化する 過程について述べます。Debian GNU/Linux
を使って安全なネットワーク環境を 構築するための一般的な作業を扱います。セキュリティ関連の道具や、Debian security team
によって行われるセキュリティ関連の作業についての情報もあります。

------------------------------------------------------------------------



第1章 まえがき
========

セキュリティ関連の文書を書くときに最もむずかしいのはどの事例も唯一であると
いうことです。あなたが注意しなければならないのは脅威となる環境とそれぞれの
サイト、ホスト、ネットワークのセキュリティの必要性です。たとえば、家庭の
ユーザのセキュリティの必要性は銀行のネットワークとは全く異なります。家庭の ユーザが直面する必要がある主要な脅威は script kiddie
タイプの クラッカーですが、銀行のネットワークはねらいうちの攻撃について心配しなければ
なりません。さらに、銀行は顧客の情報を数学的な正確さで守らなければ なりません。要するに、どのユーザも有用性と安全性 (またはパラノイア) との
かねあいを考えなければならないのです。

このマニュアルはソフトウェア関連の問題しか扱っていないことに注意してください。
だれかが物理的にマシンに接触できるなら世界最良のソフトウェアでもあなたを
守ることができません。マシンを机の下に置くこともできますし、軍隊が守っている 強化された掩蔽壕に設置することもできます。それにもかかわらず、ある
デスクトップマシンが適切に設定されていて、物理的に保護されているあるマシンが
セキュリティホールだらけだとしたら、デスクトップマシンのほうが物理的に 保護されているマシンより (ソフトウェアの観点では)
はるかに安全ということも ありえます。明らかに、どちらの問題についても考えなければなりません。

この文書はあなたの Debian GNU/Linux システムのセキュリティを高める ためにできることの概略を述べるだけです。Linux
のセキュリティに関する ほかの文書を読んだことがあるなら、この文書と重なる共通の問題があるのに
気づくでしょう。しかし、この文書はあなたが使う情報源の決定版たることを めざしているわけではありません。その同じ情報を Debian
GNU/Linux システムに とって意味があるように適応させようとしているだけです。ディストリビューション
ごとにあつかい方が異なる物事もあります。(デーモンの起動法がよくある例です。) ここには Debian のやり方や道具に適した資料があります。


1.1. Authors
------------

The current maintainer of this document is Javier Fernández-Sanguino
Peña. Please forward him any comments, additions or suggestions, and they
will be considered for inclusion in future releases of this manual.

This manual was started as a HOWTO by Alexander Reelsen. After it was
published on the Internet, Javier Fernández-Sanguino Peña incorporated it
into the Debian Documentation Project. A number of people have
contributed to this manual (all contributions are listed in the
changelog) but the following deserve special mention since they have
provided significant contributions (full sections, chapters or
appendices):

  * 

    Stefano Canepa

  * 

    Era Eriksson

  * 

    Carlo Perassi

  * 

    Alexandre Ratti

  * 

    Jaime Robles

  * 

    Yotam Rubin

  * 

    Frederic Schutz

  * 

    Pedro Zorzenon Neto

  * 

    Oohara Yuuma

  * 

    Davor Ocelic


1.2. Where to get the manual (and available formats)
----------------------------------------------------

You can download or view the latest version of the Securing Debian Manual
from the Debian Documentation Project. If you are reading a copy from
another site, please check the primary copy in case it provides new
information. If you are reading a translation, please review the version
the translation refers to to the latest version available. If you find
that the version is behind please consider using the original copy or
review the to see what has changed.

If you want a full copy of the manual you can either download the text
version or the PDF version from the Debian Documentation Project's site.
These versions might be more useful if you intend to copy the document
over to a portable device for offline reading or you want to print it
out. Be forewarned, the manual is over two hundred pages long and some of
the code fragments, due to the formatting tools used, are not wrapped in
the PDF version and might be printed incomplete.

The document is also provided in text, html and PDF formats in the
harden-doc package. Notice, however, that the package maybe not be
completely up to date with the document provided on the Debian site (but
you can always use the source package to build an updated version
yourself).

This document is part of the documents distributed by the Debian
Documentation Project. You can review the changes introduced in the
document using a web browser and obtaining information from the version
control logs online. You can also checkout the code using Git with the
following call in the command line:

$ git clone https://salsa.debian.org/ddp-team/securing-debian-manual.git


1.3. 組織化についてのメモおよび感想
--------------------

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

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

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


1.4. 前提となる知識
------------

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


1.5. 書くべきこと (FIXME/TODO)
------------------------

This section describes all the things that need to be fixed in this
manual. Some paragraphs include FIXME or TODO tags describing what
content is missing (or what kind of work needs to be done). The purpose
of this section is to describe all the things that could be included in
the future in the manual, or enhancements that need to be done (or would
be interesting to add).

If you feel you can provide help in contributing content fixing any
element of this list (or the inline annotations), contact the main author
(「Authors」).

  * 

    This document has yet to be updated based on the latest Debian
    releases. The default configuration of some packages need to be
    adapted as they have been modified since this document was written.

  * 

    Expand the incident response information, maybe add some ideas
    derived from Red Hat's Security Guide's chapter on incident response.

  * 

    Write about remote monitoring tools (to check for system
    availability) such as monit, daemontools and mon. See Sysamin Guide.

  * 

    Consider writing a section on how to build Debian-based network
    appliances (with information such as the base system, equivs and
    FAI).

  * 

    Check if this site has relevant info not yet covered here.

  * 

    Add information on how to set up a laptop with Debian, look here.

  * 

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

  * 

    Add information on setting up a proxy firewall with Debian GNU/Linux
    stating specifically which packages provide proxy services (like xfwp,
    ftp-proxy, redir, smtpd, dnrd, jftpgw, oops, pdnsd, perdition,
    transproxy, tsocks). Should point to the manual for any other info.
    Note that zorp is now available as a Debian package and is a proxy
    firewall (they also provide Debian packages upstream).

  * 

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

  * 

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

  * 

    一般的なサーバについて、限定された機能に役立つ (Debian で) 利用可能な代替物に ついての情報を加える。たとえば:

      * 

        ローカル lpr のかわりに cups (パッケージ)?

      * 

        リモート lrp のかわりに lpr

      * 

        bind のかわりに dnrd/maradns

      * 

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

      * 

        exim/sendmail のかわりに ssmtpd/smtpd/postfix

      * 

        squid のかわりに tinyproxy

      * 

        ftpd のかわりに oftpd/vsftp

      * 

        ...

  * 

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

      * 

        Linux Intrusion Detection (kernel-patch-2.4-lids)

      * 

        Linux Trustees (trusteesパッケージ中)

      * 

        NSA Enhanced Linux

      * 

        linux-patch-openswan

      * 

        ...

  * 

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

  * 

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

  * 

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

  * 

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

  * 

    hosts.equiv そしてその他のセキュリティホール。

  * 

    Issues with file sharing servers such as Samba and NFS?

  * 

    suidmanager/dpkg-statoverrides。

  * 

    lpr と lprng。

  * 

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

  * 

    Talk about pam_chroot (see
    http://lists.debian.org/debian-security/2002/05/msg00011.html) and
    its usefulness to limit users. Introduce information related to
    https://web.archive.org/web/20031204060940/http://www.securityfocus.com/infocus/1575.
    pdmenu, for example is available in Debian (whereas flash is not).

  * 

    Talk about chrooting services, some more info on this Linux Focus
    article.

  * 

    Talk about programs to make chroot jails. compartment and chrootuid
    are waiting in incoming. Some others (makejail, jailer) could also be
    introduced.

  * 

    More information regarding log analysis software (i.e. logcheck and
    logcolorise).

  * 

    'advanced' routing (traffic policing is security related).

  * 

    limiting ssh access to running certain commands.

  * 

    using dpkg-statoverride.

  * 

    secure ways to share a CD burner among users.

  * 

    secure ways of providing networked sound in addition to network
    display capabilities (so that X clients' sounds are played on the X
    server's sound hardware).

  * 

    securing web browsers.

  * 

    setting up ftp over ssh.

  * 

    using crypto loopback file systems.

  * 

    encrypting the entire file system.

  * 

    steganographic tools.

  * 

    setting up a PKA for an organization.

  * 

    using LDAP to manage users. There is a HOWTO of ldap+kerberos for
    Debian at http://www.bayour.com written by Turbo Fredrikson.

  * 

    How to remove information of reduced utility in production systems
    such as /usr/share/doc, /usr/share/man (yes, security by obscurity).

  * 

    More information on lcap based on the packages README file (well, not
    there yet, see
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=169465) and from the
    article from LWN: http://lwn.net/1999/1202/kernel.php3.

  * 

    Add Colin's article on how to setup a chroot environment for a full
    sid system (https://web.archive.org/web/20030204012846/https://people.debian.org/~walters/chroot.html).

  * 

    Add information on running multiple snort sensors in a given system
    (check bug reports sent to snort).

  * 

    Add information on setting up a honeypot (honeyd).

  * 

    Describe situation wrt to FreeSwan (orphaned) and OpenSwan. VPN
    section needs to be rewritten.

  * 

    Add a specific section about databases, current installation defaults
    and how to secure access.

  * 

    Add a section about the usefulness of virtual servers (Xen et al).

  * 

    Explain how to use some integrity checkers (AIDE, integrit or
    samhain). The basics are simple and could even explain some
    configuration improvements.


1.6. Credits and thanks!
------------------------

  * 

    Alexander Reelsen が原作を書きました。

  * 

    added more info to the original doc.

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

    Francois Bayart provided the appendix describing how to set up a
    bridge firewall.

  * 

    Joey Hess wrote the section describing how Secure Apt works on the
    Debian Wiki.

  * 

    Martin F. Krafft wrote some information on his blog regarding
    fingerprint verification which was also reused for the Secure Apt
    section.

  * 

    Francesco Poli did an extensive review of the manual and provided
    quite a lot of bug reports and typo fixes which improved and helped
    update the document.

  * 

    All the people who made suggestions for improvements that
    (eventually) were included here (see 「Where to get the manual (and
    available formats)」).

  * 

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

  * 

    Debian プロジェクト全体。



第2章 はじめる前に
==========


2.1. このシステムの目的は何ですか?
--------------------

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

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

  * 

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

  * 

    Limit users and permissions in your system.

  * 

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

  * 

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


2.2. 一般的なセキュリティ問題について知る
-----------------------

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

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

  * 

    The http://www.tldp.org/HOWTO/Security-HOWTO/ is one of the best
    references regarding general Linux security.

  * 

    The http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO/ is also a
    very good starting point for novice users (both to Linux and
    security).

  * 

    The http://seifried.org/lasg/ is a complete guide that touches all
    the issues related to security in Linux, from kernel security to
    VPNs. Note that it has not been updated since 2001, but some
    information is still relevant. [1]

  * 

    Kurt Seifried's
    http://seifried.org/security/os/linux/20020324-securing-linux-step-by-step.html.

  * 

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

  * 

    Another Red Hat related document is
    https://web.archive.org/web/20050520170309/https://ltp.sourceforge.net/docs/RHEL-EAL3-Configuration-Guide.pdf.

  * 

    IntersectAlliance has published some documents that can be used as
    reference cards on how to harden Linux servers (and their services),
    the documents are available at
    https://web.archive.org/web/20030210231943/http://www.intersectalliance.com/projects/index.html.

  * 

    For network administrators, a good reference for building a secure
    network is the
    https://web.archive.org/web/20030418093551/http://www.linuxsecurity.com/docs/LDP/Securing-Domain-HOWTO/.

  * 

    If you want to evaluate the programs you are going to use (or want to
    build up some new ones) you should read the
    http://www.tldp.org/HOWTO/Secure-Programs-HOWTO/ (master copy is
    available at http://www.dwheeler.com/secure-programs/, it includes
    slides and talks from the author, David Wheeler)

  * 

    If you are considering installing firewall capabilities, you should
    read the http://www.tldp.org/HOWTO/Firewall-HOWTO.html and the
    http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html (for kernels previous
    to 2.4).

  * 

    Finally, a good card to keep handy is the
    https://web.archive.org/web/20030308013020/http://www.linuxsecurity.com/docs/QuickRefCard.pdf.

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

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

ほかのおすすめの Linux の本:

  * 

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

  * 

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

  * 

    https://web.archive.org/web/20030202131658/https://www.linux.org/books/ISBN_0072127732.html
    By Brian Hatch. McGraw-Hill Higher Education. ISBN 0072127732. April,
    2001

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

  * 

    https://web.archive.org/web/20030206231652/http://www.oreilly.com/catalog/puis/
    Garfinkel, Simpson, and Spafford, Gene; O'Reilly Associates; ISBN
    0-56592-148-8; 1004pp; 1996.

  * 

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

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

  * 

    http://csrc.nist.gov/.

  * 

    https://cve.mitre.org/data/refs/refmap/source-BUGTRAQ.html CVE
    Reference Map for Source BUGTRAQ

  * 

    http://www.linuxsecurity.com/. General information regarding Linux
    security (tools, news...). Most useful is the
    https://linuxsecurity.com/howtos page.


2.3. Debian はセキュリティをどう扱っていますか?
------------------------------

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

  * 

    Debian problems are always handled openly, even security related.
    Security issues are discussed openly on the debian-security mailing
    list. Debian Security Advisories (DSAs) are sent to public mailing
    lists (both internal and external) and are published on the public
    server. As the http://www.debian.org/social_contract states: We will
    not hide problems. We will keep our entire bug report database open
    for public view at all times. Reports that people file online will
    promptly become visible to others.

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

    Package maintainers are aware of security issues. This leads to many
    "secure by default" service installations which could impose certain
    restrictions on their normal use. Debian does, however, try to
    balance security and ease of administration - the programs are not
    de-activated when you install them (as it is the case with say, the
    BSD family of operating systems). In any case, prominent security
    issues (such as setuid programs) are part of the
    http://www.debian.org/doc/debian-policy/.

By publishing security information specific to Debian and complementing
other information-security documents related to Debian (see 「前提となる知識」),
this document aims to produce better system installations security-wise.


------------------------------------------------------------------------

[1] At a given time it was superseded by the "Linux Security Knowledge
Base". This documentation is also provided in Debian through the lskb
package. Now it's back as the Lasg again.



第3章 インストール前およびインストール中
=====================


3.1. BIOS のパスワードを選ぶ
-------------------

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

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

Note: many BIOSes have well known default master passwords, and
applications also exist to retrieve the passwords from the BIOS.
Corollary: don't depend on this measure to secure console access to
system.


3.2. Partitioning the system
----------------------------


3.2.1. かしこいパーティション構造を選ぶ

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

  * 

    Any directory tree which a user has write permissions to, such as
    e.g. /home, /tmp and /var/tmp/, should be on a separate partition.
    This reduces the risk of a user DoS by filling up your "/" mount
    point and rendering the system unusable (Note: this is not strictly
    true, since there is always some space reserved for root which a
    normal user cannot fill), and it also prevents hardlink attacks. [2]

  * 

    /var (とくに /var/log ) のような変動しやすいパーティションも別個の パーティションであるべきです。 Debian
    システムでは、 /var をいつもより やや広く作るべきです。なぜなら、ダウンロードされたパッケージ (apt の キャッシュ) が
    /var/apt/cache/archives に保存されるからです。

  * 

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

  * 

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

In the case of a mail server it is important to have a separate partition
for the mail spool. Remote users (either knowingly or unknowingly) can
fill the mail spool (/var/mail and/or /var/spool/mail). If the spool is
on a separate partition, this situation will not render the system
unusable. Otherwise (if the spool directory is on the same partition as
/var) the system might have important problems: log entries will not be
created, packages cannot be installed, and some programs might even have
problems starting up (if they use /var/run).

Also, for partitions in which you cannot be sure of the needed space,
installing Logical Volume Manager (lvm-common and the needed binaries for
your kernel, this might be either lvm10, lvm6, or lvm5). Using lvm, you
can create volume groups that expand multiple physical volumes.


3.2.2. Selecting the appropriate file systems

During the system partitioning you also have to decide which file system
you want to use. The default file system[3] selected in the Debian
installation for Linux partitions is ext3, a journaling file system. It
is recommended that you always use a journaling file system, such as ext3,
reiserfs, jfs or xfs, to minimize the problems derived from a system
crash in the following cases:

  * 

    for laptops in all the file systems installed. That way if you run
    out of battery unexpectedly or the system freezes due to a hardware
    issue (such as X configuration which is somewhat common) you will be
    less likely to lose data during a hardware reboot.

  * 

    for production systems which store large amounts of data (like mail
    servers, ftp servers, network file systems...) it is recommended on
    these partitions. That way, in the event of a system crash, the
    server will take less time to recover and check the file systems, and
    data loss will be less likely.

Leaving aside the performance issues regarding journalling file systems
(since this can sometimes turn into a religious war), it is usually
better to use the ext3 file system. The reason for this is that it is
backwards compatible with ext2, so if there are any issues with the
journalling you can disable it and still have a working file system.
Also, if you need to recover the system with a bootdisk (or CD-ROM) you
do not need a custom kernel. If the kernel is 2.4 or 2.6 ext3 support is
already available, if it is a 2.2 kernel you will be able to boot the
file system even if you lose journalling capabilities. If you are using
other journalling file systems you will find that you might not be able
to recover unless you have a 2.4 or 2.6 kernel with the needed modules
built-in. If you are stuck with a 2.2 kernel on the rescue disk, it might
be even more difficult to have it access reiserfs or xfs.

In any case, data integrity might be better under ext3 since it does
file-data journalling while others do only meta-data journalling, see
http://lwn.net/2001/0802/a/ext3-modes.php3.

Notice, however, that there are some partitions that might not benefit
from using a journaling filesystem. For example, if you are using a
separate partition for /tmp/ you might be better off using a standard
ext2 filesystem as it will be cleaned up when the system boots.


3.3. 準備ができるまでインターネットに接続しない
--------------------------

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

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

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


3.4. root のパスワードを設定する
---------------------

Setting a good root password is the most basic requirement for having a
secure system. See passwd(1) for some hints on how to create good
passwords. You can also use an automatic password generation program to
do this for you (see 「Generating user passwords」).

Plenty of information on choosing good passwords can be found on the
Internet; two that provide a decent summary and rationale are Eric
Wolfram's http://wolfram.org/writing/howto/password.html and Walter
Belgers'
https://web.archive.org/web/20030218000949/http://www.belgers.com/write/pwseceng.txt


3.5. 必要最小限のサービスを走らせる
--------------------

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

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

As you may already know, when you install a given service the default
behavior is to activate it. In a default Debian installation, with no
services installed, the number of running services is quite low and the
number of network-oriented services is even lower. In a default Debian
3.1 standard installation you will end up with OpenSSH, Exim (depending
on how you configured it) and the RPC portmapper available as network
services[4]. If you did not go through a standard installation but
selected an expert installation you can end up with no active network
services. The RPC portmapper is installed by default because it is needed
for many services, for example NFS, to run on a given system. However, it
can be easily removed, see 「Securing RPC services」 for more information
on how to secure or disable RPC services.

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

If you want to keep some services but use them rarely, use the update-*
commands, e.g. update-inetd and update-rc.d to remove them from the
startup process. For more information on how to disable network services
read 「デーモンサービスを停止する」. If you want to change the default behaviour of
starting up services on installation of their associated packages[5] use
policy-rc.d, please read /usr/share/doc/sysv-rc/README.policy-rc.d.gz for
more information.

invoke-rc.d support is mandatory in Debian, which means that for Debian
4.0 etch and later releases you can write a policy-rc.d file that forbids
starting new daemons before you configure them. Although no such scripts
are packaged yet, they are quite simple to write. See
policyrcd-script-zg2.


3.5.1. デーモンサービスを停止する

Disabling a daemon service is quite simple. You either remove the package
providing the program for that service or you remove or rename the
startup links under /etc/rc${runlevel}.d/. If you rename them make sure
they do not begin with 'S' so that they don't get started by
/etc/init.d/rc. Do not remove all the available links or the package
management system will regenerate them on package upgrades, make sure you
leave at least one link (typically a 'K', i.e. kill, link). For more
information read
http://www.debian.org/doc/manuals/reference/ch-system.en.html#s-custombootscripts
section of the Debian Reference (Chapter 2 - Debian fundamentals).

You can remove these links manually or using update-rc.d (see update-rc.d(8)).
For example, you can disable a service from executing in the multi-user
runlevels by doing:

  # update-rc.d name stop XX 2 3 4 5 .

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

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

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

You can use the TUI (Text User Interface) provided by sysv-rc-conf to do
all these changes easily (sysv-rc-conf works both for file-rc and normal
System V runlevels). You will also find similar GUIs for desktop systems.
You can also use the command line interface of sysv-rc-conf:

  # sysv-rc-conf foobar off

The advantage of using this utility is that the rc.d links are returned
to the status they had before the 'off' call if you re-enable the service
with:

  # sysv-rc-conf foobar on

Other (less recommended) methods of disabling services are:

  * 

    Removing the /etc/init.d/service_name script and removing the startup
    links using:

      # update-rc.d     name     remove  

  * 

    Move the script file (/etc/init.d/service_name) to another name (for
    example /etc/init.d/OFF.service_name). This will leave dangling
    symlinks under /etc/rc${runlevel}.d/ and will generate error messages
    when booting up the system.

  * 

    Remove the execute permission from the /etc/init.d/service_name file.
    That will also generate error messages when booting.

  * 

    Edit the /etc/init.d/service_name script to have it stop immediately
    once it is executed (by adding an exit 0 line at the beginning or
    commenting out the start-stop-daemon part in it). If you do this, you
    will not be able to use the script to startup the service manually
    later on.

Nevertheless, the files under /etc/init.d are configuration files and
should not get overwritten due to package upgrades if you have made local
changes to them.

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

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


3.5.2. Disabling inetd or its services

You should check if you really need the inetd daemon nowadays. Inetd was
always a way to compensate for kernel deficiencies, but those have been
taken care of in modern Linux kernels. Denial of Service possibilities
exist against inetd (which can increase the machine's load tremendously),
and many people always preferred using stand-alone daemons instead of
calling services via inetd. If you still want to run some kind of inetd
service, then at least switch to a more configurable Inet daemon like
xinetd, rlinetd or openbsd-inetd.

You should stop all unneeded Inetd services on your system, like echo,
chargen, discard, daytime, time, talk, ntalk and r-services (rsh, rlogin
and rcp) which are considered HIGHLY insecure (use ssh instead).

/etc/inetd.conf を直接編集することによってサービスを停止する ことができますが、Debian
にはこれを行うよりよい他の方法があります: update-inetd です (これはサービスを再び有効にしやすい形でコメントに
します)。たとえば、設定ファイルを変更するためにこの コマンドを実行して telnet デーモンを削除し、inet デーモンを再起動する
ことができます。(この場合、telnet サービスが停止されます。)

  /usr/sbin/update-inetd --disable telnet

サービスが要求を受けつけるようにはしたいが、すべての IP アドレスからの 要求を受けつけることは望まない場合は、文書に書かれていない inetd
の機能を 使いたくなるかもしれません。 あるいは、xinetd のようなかわりの inetd デーモンを使いましょう。


3.6. Install the minimum amount of software required
----------------------------------------------------

Debian comes with a lot of software, for example the Debian 3.0 woody
release includes 6 or 7 (depending on architecture) CD-ROMs of software
and thousands of packages, and the Debian 3.1 sarge release ships with
around 13 CD-ROMs of software. With so much software, and even if the
base system installation is quite reduced [6] you might get carried away
and install more than is really needed for your system.

Since you already know what the system is for (don't you?) you should
only install software that is really needed for it to work. Any
unnecessary tool that is installed might be used by a user that wants to
compromise the system or by an external intruder that has gotten shell
access (or remote code execution through an exploitable service).

The presence, for example, of development utilities (a C compiler) or
interpreted languages (such as perl - but see below -, python, tcl...)
may help an attacker compromise the system even further:

  * 

    allowing him to do privilege escalation. It's easier, for example, to
    run local exploits in the system if there is a debugger and compiler
    ready to compile and test them!

  * 

    providing tools that could help the attacker to use the compromised
    system as a base of attack against other systems. [7]

Of course, an intruder with local shell access can download his own set
of tools and execute them, and even the shell itself can be used to make
complex programs. Removing unnecessary software will not help prevent the
problem but will make it slightly more difficult for an attacker to
proceed (and some might give up in this situation looking for easier
targets). So, if you leave tools in a production system that could be
used to remotely attack systems (see 「リモートの脆弱性を評価する道具」) you can expect an
intruder to use them too if available.

Please notice that a default installation of Debian sarge (i.e. an
installation where no individual packages are selected) will install a
number of development packages that are not usually needed. This is
because some development packages are of Standard priority. If you are
not going to do any development you can safely remove the following
packages from your system, which will also help free up some space:

Package                    Size
------------------------+--------
gdb                     2,766,822
gcc-3.3                 1,570,284
dpkg-dev                  166,800
libc6-dev               2,531,564
cpp-3.3                 1,391,346
manpages-dev            1,081,408
flex                      257,678
g++                         1,384 (Note: virtual package)
linux-kernel-headers    1,377,022
bin86                      82,090
cpp                        29,446
gcc                         4,896 (Note: virtual package)
g++-3.3                 1,778,880
bison                     702,830
make                      366,138
libstdc++5-3.3-dev        774,982

This is something that is fixed in releases post-sarge, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301273 and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301138. Due to a bug in
the installation system this did not happen when installing with the
installation system of the Debian 3.0 woody release.


3.6.1. Removing Perl

You must take into account that removing perl might not be too easy (as a
matter of fact it can be quite difficult) in a Debian system since it is
used by many system utilities. Also, the perl-base is Priority: required
(that about says it all). It's still doable, but you will not be able to
run any perl application in the system; you will also have to fool the
package management system to think that the perl-base is installed even
if it's not. [8]

Which utilities use perl? You can see for yourself:

  $ for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/*; do [ -f $i ] && {
  type=`file $i | grep -il perl`; [ -n "$type" ] && echo $i; }; done

These include the following utilities in packages with priority required
or important:

  * 

    /usr/bin/chkdupexe of package util-linux.

  * 

    /usr/bin/replay of package bsdutils.

  * 

    /usr/sbin/cleanup-info of package dpkg.

  * 

    /usr/sbin/dpkg-divert of package dpkg.

  * 

    /usr/sbin/dpkg-statoverride of package dpkg.

  * 

    /usr/sbin/install-info of package dpkg.

  * 

    /usr/sbin/update-alternatives of package dpkg.

  * 

    /usr/sbin/update-rc.d of package sysvinit.

  * 

    /usr/bin/grog of package groff-base.

  * 

    /usr/sbin/adduser of package adduser.

  * 

    /usr/sbin/debconf-show of package debconf.

  * 

    /usr/sbin/deluser of package adduser.

  * 

    /usr/sbin/dpkg-preconfigure of package debconf.

  * 

    /usr/sbin/dpkg-reconfigure of package debconf.

  * 

    /usr/sbin/exigrep of package exim.

  * 

    /usr/sbin/eximconfig of package exim.

  * 

    /usr/sbin/eximstats of package exim.

  * 

    /usr/sbin/exim-upgrade-to-r3 of package exim.

  * 

    /usr/sbin/exiqsumm of package exim.

  * 

    /usr/sbin/keytab-lilo of package lilo.

  * 

    /usr/sbin/liloconfig of package lilo.

  * 

    /usr/sbin/lilo_find_mbr of package lilo.

  * 

    /usr/sbin/syslogd-listfiles of package sysklogd.

  * 

    /usr/sbin/syslog-facility of package sysklogd.

  * 

    /usr/sbin/update-inetd of package netbase.

So, without Perl and, unless you remake these utilities in shell script,
you will probably not be able to manage any packages (so you will not be
able to upgrade the system, which is not a Good Thing).

If you are determined to remove Perl from the Debian base system, and you
have spare time, submit bug reports to the previous packages including
(as a patch) replacements for the utilities above written in shell
script.

If you wish to check out which Debian packages depend on Perl you can use

$ grep-available -s Package,Priority -F Depends perl

or

$ apt-cache rdepends perl


3.7. Debian のセキュリティメーリングリストを読む
------------------------------

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

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

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


------------------------------------------------------------------------

[2] A very good example of this kind of attacks using /tmp is detailed in
http://www.hackinglinuxexposed.com/articles/20031111.html and
http://www.hackinglinuxexposed.com/articles/20031214.html (notice that
the incident is Debian-related). It is basicly an attack in which a local
user stashes away a vulnerable setuid application by making a hard link
to it, effectively avoiding any updates (or removal) of the binary itself
made by the system administrator. Dpkg was recently fixed to prevent this
(see http://bugs.debian.org/225692) but other setuid binaries (not
controlled by the package manager) are at risk if partitions are not
setup correctly.

[3] Since Debian GNU/Linux 4.0, codename etch

[4] The footprint in Debian 3.0 and earlier releases wasn't as tight,
since some inetd services were enabled by default. Also standard
installations of Debian 2.2 installed the NFS server as well as the
telnet server.

[5] This is desirable if you are setting up a development chroot, for
example.

[6] For example, in Debian woody it is around 400-500 Mbs, try this:

  $ size=0
  $ for i in `grep -A 1 -B 1 "^Section: base" /var/lib/dpkg/available |
  grep -A 2 "^Priority: required" |grep "^Installed-Size" |cut -d : -f 2
  `; do size=$(($size+$i)); done
  $ echo $size
  47762

[7] Many intrusions are made just to get access to resources to do
illegitimate activity (denial of service attacks, spam, rogue ftp
servers, dns pollution...) rather than to obtain confidential data from
the compromised system.

[8] You can make (on another system) a dummy package with equivs.



第4章 インストール後
===========

Once the system is installed you can still do more to secure the system;
some of the steps described in this chapter can be taken. Of course this
really depends on your setup but for physical access prevention you
should read 「Change the BIOS (again)」,「LILO または GRUB パスワードを設定する」, 「Remove
root prompt on the kernel」, 「コンソールログインのアクセスを制限する」, and 「Restricting
system reboots through the console」.

Before connecting to any network, especially if it's a public one you
should, at the very least, execute a security update (see
「セキュリティ上の更新を実行する」). Optionally, you could take a snapshot of your system
(see 「Taking a snapshot of the system」).


4.1. Subscribe to the Debian Security Announce mailing list
-----------------------------------------------------------

In order to receive information on available security updates you should
subscribe yourself to the debian-security-announce mailing list in order
to receive the Debian Security Advisories (DSAs). See 「The Debian
Security Team」 for more information on how the Debian security team
works. For information on how to subscribe to the Debian mailing lists
read http://lists.debian.org.

DSAs are signed with the Debian Security Team's signature which can be
retrieved from http://security.debian.org.

You should consider, also, subscribing to the
http://lists.debian.org/debian-security for general discussion on
security issues in the Debian operating system. You will be able to
contact other fellow system administrators in the list as well as Debian
developers and upstream developers of security tools who can answer your
questions and offer advice.

FIXME: Add the key here too?


4.2. セキュリティ上の更新を実行する
--------------------

As soon as new security bugs are detected in packages, Debian maintainers
and upstream authors generally patch them within days or even hours.
After the bug is fixed, a new package is provided on
http://security.debian.org.

If you are installing a Debian release you must take into account that
since the release was made there might have been security updates after
it has been determined that a given package is vulnerable. Also, there
might have been minor releases (there have been four for the Debian 3.0
sarge release) which include these package updates.

During installation security updates are configured for your system and
pending updates downloaded and applied, unless you specifically opt out
of this or the system was not connected to the Internet. The updates are
applied even before the first boot, so the new system starts its life as
up to date as possible.

To manually update the system, put the following line in your
sources.list and you will get security updates automatically, whenever
you update your system. Replace [CODENAME] with the release codename,
e.g. squeeze.

  deb http://security.debian.org/ [CODENAME]/updates main contrib non-free

Note: If you are using the testing branch use the security testing mirror
sources as described in 「Security support for the testing branch」.

Once you've done this you can use multiple tools to upgrade your system.
If you are running a desktop system you will have[9] an application
called update-notifier that will make it easy to check if new updates are
available, by selecting it you can make a system upgrade from the desktop
(using update-manager). For more information see 「Checking for updates at
the Desktop」. In desktop environments you can also use synaptic (GNOME),
kpackage or adept (KDE) for more advanced interfaces. If you are running
a text-only terminal you can use aptitude, apt or dselect (deprecated) to
upgrade:

  * 

    If you want to use aptitude's text interface you just have to press u
    (update) followed by g (to upgrade). Or just do the following from
    the command line (as root):

    # aptitude update
    # aptitude upgrade  

  * 

    If you want to use apt do just like with aptitude but substitute the
    aptitude lines above with apt-get.

  * 

    If you want to use dselect then first [U]pdate, then [I]nstall and
    finally, [C]onfigure the installed/upgraded packages.

If you like, you can add the deb-src lines to /etc/apt/sources.list as
well. See apt(8) for further details.


4.2.1. Security update of libraries

Once you have executed a security update you might need to restart some
of the system services. If you do not do this, some services might still
be vulnerable after a security upgrade. The reason for this is that
daemons that are running before an upgrade might still be using the old
libraries before the upgrade [10].

From Debian Jessie and up, you can install the needrestart package, which
will run automatically after each APT upgrade and prompt you to restart
services that are affected by the just-installed updates. In earlier
releases, you can run the checkrestart program (available in the
debian-goodies package) manually after your APT upgrade.

Some packages (like libc6) will do this check in the postinst phase for a
limited set of services specially since an upgrade of essential libraries
might break some applications (until restarted)[11].

Bringing the system to run level 1 (single user) and then back to run
level 3 (multi user) should take care of the restart of most (if not all)
system services. But this is not an option if you are executing the
security upgrade from a remote connection (like ssh) since it will be
severed.

Excercise caution when dealing with security upgrades if you are doing
them over a remote connection like ssh. A suggested procedure for a
security upgrade that involves a service restart is to restart the SSH
daemon and then, immediately, attempt a new ssh connection without
breaking the previous one. If the connection fails, revert the upgrade
and investigate the issue.


4.2.2. Security update of the kernel

First, make sure your kernel is being managed through the packaging
system. If you have installed using the installation system from Debian
3.0 or previous releases, your kernel is not integrated into the
packaging system and might be out of date. You can easily confirm this by
running:

$ dpkg -S `readlink -f /vmlinuz`
linux-image-2.6.18-4-686: /boot/vmlinuz-2.6.18-4-686

If your kernel is not being managed you will see a message saying that
the package manager did not find the file associated to any package
instead of the message above, which says that the file associated to the
current running kernel is being provided by the linux-image-2.6.18-4-686.
So first, you will need to manually install a kernel image package. The
exact kernel image you need to install depends on your architecture and
your prefered kernel version. Once this is done, you will be able to
manage the security updates of the kernel just like those of any other
package. In any case, notice that the kernel updates will only be done
for kernel updates of the same kernel version you are using, that is, apt
will not automatically upgrade your kernel from the 2.4 release to the
2.6 release (or from the 2.4.26 release to the 2.4.27 release[12]).

The installation system of recent Debian releases will handle the
selected kernel as part of the package system. You can review which
kernels you have installed by running:

$ COLUMNS=150 dpkg -l 'linux-image*' | awk '$1 ~ /ii/ { print $0 }'

To see if your kernel needs to be updated run:

$ kernfile=`readlink -f /vmlinuz`
$ kernel=`dpkg -S $kernfile | awk -F : '{print $1}'`
$ apt-cache policy $kernel
linux-image-2.6.18-4-686:
  Installed: 2.6.18.dfsg.1-12
  Candidate: 2.6.18.dfsg.1-12
  Version table:
 *** 2.6.18.dfsg.1-12 0
        100 /var/lib/dpkg/status

If you are doing a security update which includes the kernel image you
need to reboot the system in order for the security update to be useful.
Otherwise, you will still be running the old (and vulnerable) kernel
image.

If you need to do a system reboot (because of a kernel upgrade) you
should make sure that the kernel will boot up correctly and network
connectivity will be restored, specially if the security upgrade is done
over a remote connection like ssh. For the former you can configure your
boot loader to reboot to the original kernel in the event of a failure
(for more detailed information read Remotely rebooting Debian GNU/Linux
machines). For the latter you have to introduce a network connectivity
test script that will check if the kernel has started up the network
subsystem properly and reboot the system if it did not[13]. This should
prevent nasty surprises like updating the kernel and then realizing,
after a reboot, that it did not detect or configure the network hardware
properly and you need to travel a long distance to bring the system up
again. Of course, having the system serial console [14] in the system
connected to a console or terminal server should also help debug reboot
issues remotely.


4.3. Change the BIOS (again)
----------------------------

Remember 「BIOS のパスワードを選ぶ」? Well, then you should now, once you do not
need to boot from removable media, to change the default BIOS setup so
that it only boots from the hard drive. Make sure you will not lose the
BIOS password, otherwise, in the event of a hard disk failure you will
not be able to return to the BIOS and change the setup so you can recover
it using, for example, a CD-ROM.

Another less secure but more convenient way is to change the setup to
have the system boot up from the hard disk and, if it fails, try
removable media. By the way, this is often done because most people don't
use the BIOS password that often; it's easily forgotten.


4.4. LILO または GRUB パスワードを設定する
-----------------------------

Anybody can easily get a root-shell and change your passwords by entering

<name-of-your-bootimage> init=/bin/sh

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

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

For LILO you need to edit the config file /etc/lilo.conf and add a
password and restricted line as in the example below.

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

Then, make sure that the configuration file is not world readable to
prevent local users from reading the password. When done, rerun lilo.
Omitting the restricted line causes lilo to always prompt for a password,
regardless of whether LILO was passed parameters. The default permissions
for /etc/lilo.conf grant read and write permissions to root, and enable
read-only access for lilo.conf's group, root.

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

  timeout 3
  password hackme

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

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

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


4.5. Disable root prompt on the initramfs
-----------------------------------------

Note: This applies to the default kernels provided for releases after
Debian 3.1

Linux 2.6 kernels provide a way to access a root shell while booting
which will be presented during loading the initramfs on error. This is
helpful to permit the administrator to enter a rescue shell with root
permissions. This shell can be used to manually load modules when
autodetection fails. This behavior is the default for initramfs-tools
generated initramfs. The following message will appear:

  "ALERT!  /dev/sda1 does not exist.  Dropping to a shell!

In order to remove this behavior you need to set the following boot
argument:panic=0. Add this to the variable GRUB_CMDLINE_LINUX in
/etc/default/grub and issue update-grub or to the append section of
/etc/lilo.conf.


4.6. Remove root prompt on the kernel
-------------------------------------

Note: This does not apply to the kernels provided for Debian 3.1 as the
timeout for the kernel delay has been changed to 0.

Linux 2.4 kernels provide a way to access a root shell while booting
which will be presented just after loading the cramfs file system. A
message will appear to permit the administrator to enter an executable
shell with root permissions, this shell can be used to manually load
modules when autodetection fails. This behavior is the default for initrd's
linuxrc. The following message will appear:

  Press ENTER to obtain a shell (waits 5 seconds)

In order to remove this behavior you need to change
/etc/mkinitrd/mkinitrd.conf and set:

  # 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

Then regenerate your ramdisk image. You can do this for example with:

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

or (preferred):

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


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

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

/etc/pam.d/login In older Debian releases you would need to edit
login.defs, and use the CONSOLE variable which defines a file or list of
terminals on which root logins are allowed. enables the pam_securetty.so
module. This module, when properly configured will not ask for a password
when the root user tries to login on an insecure console, rejecting
access as this user.

securetty The /etc/securetty is a configuration file that belongs to the
login package. by adding/removing the terminals to which root access will
be allowed. If you wish to allow only local console access then you need
console, ttyX Or ttyvX in GNU/FreeBSD, and ttyE0 in GNU/KNetBSD. and vc/X
(if using devfs devices), you might want to add also ttySX Or comX in
GNU/Hurd, cuaaX in GNU/FreeBSD, and ttyXX in GNU/KNetBSD. if you are
using a serial console for local access (where X is an integer, you might
want to have multiple instances. The default configuration for Wheezy The
default configuration in woody includes 12 local tty and vc consoles, as
well as the console device but does not allow remote logins. In sarge the
default configuration provides 64 consoles for tty and vc consoles.
includes many tty devices, serial ports, vc consoles as well as the X
server and the console device. You can safely adjust this if you are not
using that many consoles. You can confirm the virtual consoles and the
tty devices you have by reviewing /etc/inittab Look for the getty calls.
. For more information on terminal devices read the Text-Terminal-HOWTO

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

  auth       required   pam_unix.so nullok


4.8. Restricting system reboots through the console
---------------------------------------------------

If your system has a keyboard attached to it anyone (yes anyone) with
physical access to the system can reboot the system through it without
login in just pressing the Ctrl+Alt+Delete keyboard combination, also
known as the three finger salute. This might, or might not, adhere to
your security policy.

This is aggravated in environments in which the operating system is
running virtualised. In these environments, the possibility extends to
users that have access to the virtual console (which might be accessed
over the network). Also note that, in these environments, this keyboard
combination is used constantly (to open a login shell in some GUI
operating systems) and an administrator might virtually send it and force
a system reboot.

There are two ways to restrict this:

  * 

    configure it so that only allowed users can reboot the system,

  * 

    disable this feature completely.

If you want to restrict this, you must check the /etc/inittab so that the
line that includes ctrlaltdel calls shutdown with the -a switch.

The default in Debian includes this switch:

  ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

The -a switch, as the shutdown(8) manpage describes,makes it possible to
allow some users to shutdown the system. For this the file
/etc/shutdown.allow must be created and the administrator has to include
there the name of users which can boot the system. When the three finger
salute combination is pressed in a console the program will check if any
of the users listed in the file are logged in. If none of them is,
shutdown will not reboot the system.

If you want to disable the Ctrl+Alt+Del combination you just need to
comment the line with the ctrlaltdel definition in the /etc/inittab.

Remember to run init q after making any changes to the /etc/inittab file
for the changes to take effect.


4.9. Restricting the use of the Magic SysRq key
-----------------------------------------------

The Magic SysRq key is a key combination that allows users connected to
the system console of a Linux kernel to perform some low-level commands.
These low-level commands are sent by pressing simultaneously Alt+SysRq
and a command key. The SysRq key in many keyboards is labeled as the
Print Screen key.

Since the Etch release, the Magic SysRq key feature is enabled in the
Linux kernel to allow console users certain privileges. You can confirm
this by checking if the /proc/sys/kernel/sysrq exists and reviewing its
value:

$ cat /proc/sys/kernel/sysrq 
438

The default value shown above allows all of the SysRq functions except
for the possibility of sending signals to processes. For example, it
allow users connected to the console to remount all systems read-only,
reboot the system or cause a kernel panic. In all the features are
enabled, or in older kernels (earlier than 2.6.12) the value will be just
1.

You should disable this functionality ifaccess to the console is not
restricted to authorised users: the console is connected to a modem line,
there is easy physical access to the system or it is running in a
virtualised environment and other users access the console. To do this
edit the /etc/sysctl.conf and add the following lines:

# Disables the magic SysRq key
kernel.sysrq = 0

For more information, read security chapter in the Remote Serial Console
HOWTO, Kernel SysRQ documentation. and the Magic_SysRq_key wikipedia
entry.


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

When mounting an Ext file system (ext2, ext3 or ext4), there are several
additional options you can apply to the mount call or to /etc/fstab. For
instance, this is my fstab entry for the /tmp partition:

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

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

  * 

    only applies to ext2 or ext3 file systems

  * 

    簡単に回避できます

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

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

Newer versions of the kernel do however handle the noexec flag properly:

  angrist:/tmp# mount | grep /tmp
  /dev/hda3 on /tmp type ext3 (rw,noexec,nosuid,nodev)
  angrist:/tmp# ./date
  bash: ./tmp: Permission denied 
  angrist:/tmp# /lib/ld-linux.so.2 ./date 
  ./date: error while loading shared libraries: ./date: failed to map segment 
  from shared object: Operation not permitted

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

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

The following is a more thorough example. A note, though: /var could be
set noexec, but some software [15] keeps its programs under in /var. The
same applies to the nosuid option.

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


4.10.1. Setting /tmp noexec

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


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

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

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

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

Note that the Post-Invoke may fail with a "/usr busy" error message. This
happens mainly when you are using files during the update that got
updated. You can find these programs by running

# lsof +L1

Stop or restart these programs and run the Post-Invoke manually. Beware!
This means you'll likely need to restart your X session (if you're
running one) every time you do a major upgrade of your system. You might
want to reconsider whether a read-only /usr is suitable for your system.
See also this discussion on debian-devel about read-only.


4.11. Providing secure user access
----------------------------------


4.11.1. ユーザ認証: PAM

PAM (Pluggable Authentication Modules) allows system administrators to
choose how applications authenticate users. Note that PAM can do nothing
unless an application is compiled with support for PAM. Most of the
applications that are shipped with Debian have this support built in
(Debian did not have PAM support before 2.2). The current default
configuration for any PAM-enabled service is to emulate UNIX
authentication (read /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz for
more information on how PAM services should work in Debian).

Each application with PAM support provides a configuration file in
/etc/pam.d/ which can be used to modify its behavior:

  * 

    what backend is used for authentication.

  * 

    what backend is used for sessions.

  * 

    how do password checks behave.

The following description is far from complete, for more information you
might want to read the Linux-PAM Guides as a reference. This
documentation is available in the system if you install the libpam-doc at
/usr/share/doc/libpam-doc/html/.

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


4.11.2. Password security in PAM

Review the /etc/pam.d/common-password, included by /etc/pam.d/passwd[16]
This file is included by other files in /etc/pam.d/ to define the
behaviour of password use in subsystems that grant access to services in
the machine, like the console login (login), graphical login managers
(such as gdm or lightdm), and remote login (such as sshd). This
definition is

You have to make sure that the pam_unix.so module uses the "sha512"
option to use encrypted passwords. This is the default in Debian Squeeze.

The line with the definition of the pam_unix module will look something
like:

  password   [success=1 default=ignore]      pam_unix.so nullok obscure minlen=8 sha512 

This definition:

  * 

    Enforces password encryption when storing passwords, using the
    SHA-512 hash function (option sha512),

  * 

    Enables password complexity checks (option obscure) as defined in the
    pam_unix(8) manpage,

  * 

    Imposes a minimum password length (option min) of 8.

You have to ensure that encrypted passwords are used in PAM applications,
since this helps protect against dictionary cracks. Using encryption also
makes it possible to use passwords longer than 8 characters.

Since this module is also used to define how passwords are changed (it is
included by chpasswd) you can strengthen the password security in the
system by installing libpam-cracklib and introducing this definition in
the /etc/pam.d/common-password configuration file:

  # 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   [success=1 default=ignore]      pam_unix.so obscure minlen=8 sha512 use_authok

So, what does this incantation do? The first line loads the cracklib PAM
module, which provides password strength-checking, prompts for a new
password with a minimum size [17] of 12 characters, and difference of at
least 3 characters from the old password, and allows 3 retries. Cracklib
depends on a wordlist package (such as wenglish, wspanish, wbritish,
...), so make sure you install one that is appropriate for your language
or cracklib might not be useful to you at all.

The second line (using the pam_unix.so module) is the default
configuration in Debian, as described above, save for the use_authok
option. The use_authok option is required if pam_unix.so is stacked after
pam_cracklib.so, and is used to hand over the password from the previous
module. Otherwise, the user would be prompted for the password twice.

For more information about setting up Cracklib, read the pam_cracklib(8)
manpage and the article Linux Password Security with pam_cracklib by Hal
Pomeranz.

By enabling the cracklib PAM module you setup a policy that forces uses
to use strong passwords.

Alternatively, you can setup and configure PAM modules to use double
factor authentication such as: libpam-barada, libpam-google-authenticator,
libpam-oath, libpam-otpw, libpam-poldi, libpam-usb or libpam-yubico. The
configuration of these modules would make it possible to access the
system using external authentication mechanisms such as smartcards,
external USB keys, or One-Time-Passwords generated by external
applications running, for example, in the user's mobile phone.

Please note that these restrictions apply to all users but not to the
password changes done by the root user. The root user will be able to set
up any password (any length or complexity) for personal use or others
regardless of the restrictions defined here.


4.11.3. User access control in PAM

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

auth     requisite  pam_securetty.so

Then you should modify the list of terminals on which direct root login
is allowed in /etc/securetty (as described in 「コンソールログインのアクセスを制限する」).
Alternatively, you could enable the pam_access module and modify
/etc/security/access.conf which allows for a more general and fine-tuned
access control, but (unfortunately) lacks decent log messages (logging
within PAM is not standardized and is particularly unrewarding problem to
deal with). We'll return to access.conf a little later.


4.11.4. User limits in PAM

The following line should be enabled in /etc/pam.d/login to set up user
resource limits.

  session  required   pam_limits.so

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


4.11.5. Control of su in PAM

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

auth        requisite   pam_wheel.so group=wheel debug

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

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

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


4.11.6. Temporary directories in PAM

Since there have been a number of so called insecure tempfile
vulnerabilities, thttpd is one example (see DSA-883-1), the libpam-tmpdir
is a good package to install. All you have to do is add the following to
/etc/pam.d/common-session:

 session    optional     pam_tmpdir.so

There has also been a discussion about adding this by default in Debian
configuration, but it s. See
http://lists.debian.org/debian-devel/2005/11/msg00297.html for more
information.


4.11.7. Configuration for undefined PAM applications

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

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

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


4.11.8. Limiting resource usage: the limits.conf file

You should really take a serious look into this file. Here you can define
user resource limits. In old releases this configuration file was
/etc/limits.conf, but in newer releases (with PAM) the
/etc/security/limits.conf configuration file should be used instead.

If you do not restrict resource usage, any user with a valid shell in
your system (or even an intruder who compromised the system through a
service or a daemon going awry) can use up as much CPU, memory, stack,
etc. as the system can provide. This resource exhaustion problem can be
fixed by the use of PAM.

There is a way to add resource limits to some shells (for example, bash
has ulimit, see bash(1)), but since not all of them provide the same
limits and since the user can change shells (see chsh(1)) it is better to
place the limits on the PAM modules as they will apply regardless of the
shell used and will also apply to PAM modules that are not
shell-oriented.

Resource limits are imposed by the kernel, but they need to be configured
through the limits.conf and the PAM configuration of the different
services need to load the appropriate PAM. You can check which services
are enforcing limits by running:

$ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"

Commonly, login, ssh and the graphic session managers (gdm, kdm or xdm)
should enforce user limits but you might want to do this in other PAM
configuration files, such as cron, to prevent system daemons from taking
over all system resources.

The specific limits settings you might want to enforce depend on your
system's resources, that's one of the main reasons why no limits are
enforced in the default installation.

For example, the configuration example below enforces a 100 process limit
for all users (to prevent fork bombs) as well as a limit of 10MB of
memory per process and a limit of 10 simultaneous logins. Users in the
adm group have higher limits and can produce core files if they want to
(there is only a soft limit).

*              soft    core            0
*              hard    core            0
*              hard    rss             1000
*              hard    memlock         1000
*              hard    nproc           100
*              -       maxlogins       1
*              hard    data            102400
*              hard    fsize           2048
@adm           hard    core            100000
@adm           hard    rss             100000
@adm           soft    nproc           2000
@adm           hard    nproc           3000
@adm           hard    fsize           100000
@adm           -       maxlogins       10

These would be the limits a default user (including system daemons) would
have:

$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 2048
max locked memory     (kbytes, -l) 10000
max memory size       (kbytes, -m) 10000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 100
virtual memory        (kbytes, -v) unlimited

And these are the limits for an administrative user:

$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 100000
max locked memory     (kbytes, -l) 100000
max memory size       (kbytes, -m) 100000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 2000
virtual memory        (kbytes, -v) unlimited

For more information read:

  * 

    PAM reference guide for available modules

  * 

    PAM configuration article.

  * 

    Seifried's Securing Linux Step by Step on the Limiting users overview
    section.

  * 

    LASG in the Limiting and monitoring users section.


4.11.9. User login actions: edit /etc/login.defs

The next step is to edit the basic configuration and action upon user
login. Note that this file is not part of the PAM configuration, it's a
configuration file honored by login and su programs, so it doesn't make
sense tuning it for cases where neither of the two programs are at least
indirectly called (the getty program which sits on the consoles and
offers the initial login prompt does invoke login).

  FAILLOG_ENAB        yes

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

  LOG_UNKFAIL_ENAB    yes

If you set this variable to 'yes' it will record unknown usernames if the
login failed. It is best if you use 'no' (the default) since, otherwise,
user passwords might be inadvertenly logged here (if a user mistypes and
they enter their password as the username). If you set it to 'yes', make
sure the logs have the proper permissions (640 for example, with an
appropriate group setting such as adm).

  SYSLOG_SU_ENAB      yes

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

  SYSLOG_SG_ENAB      yes

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

  ENCRYPT_METHOD  SHA512

As stated above, encrypted passwords greatly reduce the problem of
dictionary attacks, since you can use longer passwords. This definition
has to be consistent with the value defined in /etc/pam.d/common-password.


4.11.10. User login actions: edit /etc/pam.d/login

You can adjust the login configuration file to implement an stricter
policy. For example, you can change the default configuration and
increase the delay time between login prompts. The default configuration
sets a 3 seconds delay:

auth       optional   pam_faildelay.so  delay=3000000

Increasing the delay value to a higher value to make it harder to use the
terminal to log in using brute force. If a wrong password is typed in,
the possible attacker (or normal user!) has to wait longer seconds to get
a new login prompt, which is quite time consuming when you test
passwords. For example, if you set delay=10000000, users will have to
wait 10 seconds if they type a wrong password.

In this file you can also set the system to present a message to users
before a user logs in. The default is disabled, as shown below:

# auth       required   pam_issue.so issue=/etc/issue

If required by your security policy, this file can be used to show a
standard message indicating that access to the system is restricted and
user acess is logged. This kind of disclaimer might be required in some
environments and jurisdictions. To enable it, just include the relevant
information in the /etc/issue[18] file and uncomment the line enabling
the pam_issue.so module in /etc/pam.d/login. In this file you can also
enable additional features which might be relevant to apply local
security policies such as:

  * 

    setting rules for which users can access at which times, by enabling
    the pam_time.so module and configuring /etc/security/time.conf
    accordingly (disabled by default),

  * 

    setup login sessions to use user limits as defined in
    /etc/security/limits.conf (enabled by default),

  * 

    present the user with the information of previous login information
    (enabled by default),

  * 

    print a message (/etc/motd and /run/motd.dynamic) to users after
    login in (enabled by default),


4.11.11. Restricting ftp: editing /etc/ftpusers

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

FIXME (BUG): Is it a bug that the default ftpusers in Debian does not
include all the administrative users (in base-passwd).

A convenient way to add all system accounts to the /etc/ftpusers is to
run

$ awk -F : '{if ($3<1000) print $1}' /etc/passwd > /etc/ftpusers


4.11.12. su を使う

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


4.11.13. sudo を使う

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


4.11.14. Disallow remote administrative access

You should also modify /etc/security/access.conf to disallow remote
logins to administrative accounts. This way users need to invoke su (or
sudo) to use any administrative powers and the appropriate audit trace
will always be generated.

You need to add the following line to /etc/security/access.conf, the
default Debian configuration file has a sample line commented out:

   -:wheel:ALL EXCEPT LOCAL

Remember to enable the pam_access module for every service (or default
configuration) in /etc/pam.d/ if you want your changes to
/etc/security/access.conf honored.


4.11.15. ユーザを制限する

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

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

Debian currently provides in the unstable release (and might be included
in the next stable releases) the pam_chroot module (in the libpam-chroot).
An alternative to it is to chroot the service that provides remote
logging (ssh, telnet). [19]

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

Information on how to chroot users accessing the system through the ssh
service is described in 「Chroot environment for SSH」.


4.11.16. User auditing

If you are really paranoid you might want to add a system-wide
configuration to audit what the users are doing in your system. This
sections presents some tips using diverse utilities you can use.

4.11.16.1. Input and output audit with script

You can use the script command to audit both what the users run and what
are the results of those commands. You cannot setup script as a shell
(even if you add it to /etc/shells). But you can have the shell
initialization file run the following:

umask 077
exec script -q -a "/var/log/sessions/$USER"

Of course, if you do this system wide it means that the shell would not
continue reading personal initialization files (since the shell gets
overwritten by script). An alternative is to do this in the user's
initialization files (but then the user could remove this, see the
comments about this below)

You also need to setup the files in the audit directory (in the example
/var/log/sessions/) so that users can write to it but cannot remove the
file. This could be done, for example, by creating the user session files
in advance and setting them with the append-only flag using chattr.

A useful alternative for sysadmins, which includes date information would
be:

umask 077
exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"

4.11.16.2. Using the shell history file

If you want to review what does the user type in the shell (but not what
the result of that is) you can setup a system-wide /etc/profile that
configures the environment so that all commands are saved into a history
file. The system-wide configuration needs to be setup in such a way that
users cannot remove audit capabilities from their shell. This is somewhat
shell specific so make sure that all users are using a shell that
supports this.

For example, for bash, the /etc/profile could be set as follows [20] :

  HISTFILE=~/.bash_history
  HISTSIZE=10000
  HISTFILESIZE=999999
  # Don't let the users enter commands that are ignored
  # in the history file
  HISTIGNORE=""
  HISTCONTROL=""
  readonly HISTFILE
  readonly HISTSIZE
  readonly HISTFILESIZE
  readonly HISTIGNORE
  readonly HISTCONTROL
  export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL

For this to work, the user can only append information to .bash_history
file. You need also to set the append-only option using chattr program
for .bash_history for all users. [21].

Note that you could introduce the configuration above in the user's
.profile. But then you would need to setup permissions properly in such a
way that prevents the user from modifying this file. This includes:
having the user's home directories not belong to the user (since the user
would be able to remove the file otherwise) but at the same time allow
the user to read the .profile configuration file and write on the
.bash_history. It would be good to set the immutable flag (also using
chattr) for .profile too if you do it this way.

4.11.16.3. Complete user audit with accounting utilities

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

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

4.11.16.4. Other user auditing methods

If you are completely paranoid and want to audit every user's command,
you could take bash source code, edit it and have it send all that the
user typed into another file. Or have ttysnoop constantly monitor any new
ttys [22] and dump the output into a file. Other useful program is snoopy
(see also github: https://github.com/a2o/snoopy) which is a
user-transparent program that hooks in as a library providing a wrapper
around execve() calls, any command executed is logged to syslogd using
the authpriv facility (usually stored at /var/log/auth.log).


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

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

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


4.11.18. Setting users umasks

Depending on your user policy you might want to change how information is
shared between users, that is, what the default permissions of new files
created by users are.

Debian's default umask setting is 022 this means that files (and
directories) can be read and accessed by the user's group and by any
other users in the system. This definition is set in the standard
configuration file /etc/profile which is used by all shells.

If Debian's default value is too permissive for your system you will have
to change the umask setting for all the shells. More restrictive umask
settings include 027 (no access is allowed to new files for the other
group, i.e. to other users in the system) or 077 (no access is allowed to
new files to the members the user's group). Debian (by default[23])
creates one group per user so that only the user is included in its
group. Consequently 027 and 077 are equivalent as the user's group
contains only the user.

This change is set by defining a proper umask setting for all users. You
can change this by introducing an umask call in the shell configuration
files: /etc/profile (source by all Bourne-compatible shells),
/etc/csh.cshrc, /etc/csh.login, /etc/zshrc and probably some others
(depending on the shells you have installed on your system). You can also
change the UMASK setting in /etc/login.defs, Of all of these the last one
that gets loaded by the shell takes precedence. The order is: the default
system configuration for the user's shell (i.e. /etc/profile and other
system-wide configuration files) and then the user's shell (his
~/.profile, ~/.bash_profile, etc...). Some shells, however, can be
executed with a nologin value which might skip sourcing some of those
files. See your shell's manpage for additional information.

For connections that make use of login the UMASK definition in
/etc/login.defs is used before any of the others. However, that value
does not apply to user executed programs that do not use login such as
those run through su, cron or ssh.

Don't forget to review and maybe modify the dotfiles under /etc/skel/
since these will be new user's defaults when created with the adduser
command. Debian default dotfiles do not include any umask call but if
there is any in the dotfiles newly created users might a different value.

Note, however that users can modify their own umask setting if they want
to, making it more permissive or more restricted, by changing their own
dotfiles.

The libpam-umask package adjusts the users' default umask using PAM. Add
the following, after installing the package, to /etc/pam.d/common-session:

session    optional     pam_umask.so umask=077

Finally, you should consider changing root's default 022 umask (as
defined in /root/.bashrc) to a more strict umask. That will prevent the
system administrator from inadvertenly dropping sensitive files when
working as root to world-readable directories (such as /tmp) and having
them available for your average user.


4.11.19. Limiting what users can see/access

FIXME: Content needed. Describe the consequences of changing packages
permissions when upgrading (an admin this paranoid should chroot his
users BTW) if not using dpkg-statoverride.

If you need to grant users access to the system with a shell think about
it very carefully. A user can, by default unless in a severely restricted
environment (like a chroot jail), retrieve quite a lot of information
from your system including:

  * 

    some configuration files in /etc. However, Debian's default
    permissions for some sensitive files (which might, for example,
    contain passwords), will prevent access to critical information. To
    see which files are only accessible by the root user for example

    find /etc -type f -a -perm 600 -a -uid 0

    as superuser.

  * 

    your installed packages, either by looking at the package database,
    at the /usr/share/doc directory or by guessing by looking at the
    binaries and libraries installed in your system.

  * 

    some log files at /var/log. Note also that some log files are only
    accessible to root and the adm group (try

    find /var/log -type f -a -perm 640

    ) and some are even only available to the root user (try

    find /var/log -type f -a -perm
        600 -a -uid 0

    ).

What can a user see in your system? Probably quite a lot of things, try
this (take a deep breath):

  find / -type f -a -perm +006 2>/dev/null  
  find / -type d -a -perm +007 2>/dev/null

The output is the list of files that a user can see and the accessable
directories.

4.11.19.1. Limiting access to other user's information

If you still grant shell access to users you might want to limit what
information they can view from other users. Users with shell access have
a tendency to create quite a number of files under their $HOMEs:
mailboxes, personal documents, configuration of X/GNOME/KDE
applications...

In Debian each user is created with one associated group, and no two
users belong to the same group. This is the default behavior: when an
user account is created, a group of the same name is created too, and the
user is assigned to it. This avoids the concept of a common users group
which might make it more difficult for users to hide information from
other users.

However, users' $HOME directories are created with 0755 permissions
(group-readable and world-readable). The group permissions is not an
issue since only the user belongs to the group, however the world
permissions might (or might not) be an issue depending on your local
policy.

You can change this behavior so that user creation provides different
$HOME permissions. To change the behavior for new users when they get
created, change DIR_MODE in the configuration file /etc/adduser.conf to
0750 (no world-readable access).

Users can still share information, but not directly in their $HOME
directories unless they change its permissions.

Note that disabling world-readable home directories will prevent users
from creating their personal web pages in the ~/public_html directory,
since the web server will not be able to read one component in the path -
namely their $HOME directory. If you want to permit users to publish HTML
pages in their ~/public_html, then change DIR_MODE to 0751. This will
allow the web server to access the final public_html directory (which
itself should have a mode of 0755) and provide the content published by
users. Of course, we are only talking about a default configuration here;
users can generally tune modes of their own files completely to their
liking, or you could keep content intended for the web in a separate
location which is not a subdirectory of user's $HOME directory.


4.11.20. Generating user passwords

There are many cases when an administrator needs to create many user
accounts and provide passwords for all of them. Of course, the
administrator could easily just set the password to be the same as the
user's account name, but that would not be very sensitive security-wise.
A better approach is to use a password generating program. Debian
provides makepasswd, apg and pwgen packages which provide programs (the
name is the same as the package) that can be used for this purpose.
Makepasswd will generate true random passwords with an emphasis on
security over pronounceability while pwgen will try to make meaningless
but pronounceable passwords (of course this might depend on your mother
language). Apg has algorithms to provide for both (there is a
client/server version for this program but it is not included in the
Debian package).

Passwd does not allow non-interactive assignation of passwords (since it
uses direct tty access). If you want to change passwords when creating a
large number of users you can create them using adduser with the
--disabled-login option and then use usermod or chpasswd[24] (both from
the passwd package so you already have them installed). If you want to
use a file with all the information to make users as a batch process you
might be better off using newusers.


4.11.21. Checking user passwords

User passwords can sometimes become the weakest link in the security of a
given system. This is due to some users choosing weak passwords for their
accounts (and the more of them that have access to it the greater the
chances of this happening). Even if you established checks with the
cracklib PAM module and password limits as described in 「ユーザ認証: PAM」
users will still be able to use weak passwords. Since user access might
include remote shell access (over ssh, hopefully) it's important to make
password guessing as hard as possible for the remote attackers,
especially if they were somehow able to collect important information
such as usernames or even the passwd and shadow files themselves.

A system administrator must, given a big number of users, check if the
passwords they have are consistent with the local security policy. How to
check? Try to crack them as an attacker would if having access to the
hashed passwords (the /etc/shadow file).

An administrator can use john or crack (both are brute force password
crackers) together with an appropriate wordlist to check users' passwords
and take appropriate action when a weak password is detected. You can
search for Debian GNU packages that contain word lists using apt-cache
search wordlist, or visit some Internet wordlist sites.


4.11.22. Logging off idle users

Idle users are usually a security problem, a user might be idle maybe
because he's out to lunch or because a remote connection hung and was not
re-established. For whatever the reason, idle users might lead to a
compromise:

  * 

    because the user's console might be unlocked and can be accessed by
    an intruder.

  * 

    because an attacker might be able to re-attach to a closed network
    connection and send commands to the remote shell (this is fairly easy
    if the remote shell is not encrypted as in the case of telnet).

Some remote systems have even been compromised through an idle (and
detached) screen.

Automatic disconnection of idle users is usually a part of the local
security policy that must be enforced. There are several ways to do this:

  * 

    If bash is the user shell, a system administrator can set a default
    TMOUT value (see bash(1)) which will make the shell automatically log
    off remote idle users. Note that it must be set with the -o option or
    users will be able to change (or unset) it.

  * 

    Install timeoutd and configure /etc/timeouts according to your local
    security policy. The daemon will watch for idle users and time out
    their shells accordingly.

  * 

    Install autolog and configure it to remove idle users.

The timeoutd or autolog daemons are the preferred method since, after
all, users can change their default shell or can, after running their
default shell, switch to another (uncontrolled) shell.


4.12. tcpwrappers を使う
---------------------

TCP wrappers were developed when there were no real packet filters
available and access control was needed. Nevertheless, they're still very
interesting and useful. The TCP wrappers allow you to allow or deny a
service for a host or a domain and define a default allow or deny rule
(all performed on the application level). If you want more information
take a look at hosts_access(5) manual page.

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

  * 

    tcp wrapper サービス (tcpd) を通して起動されるか、

  * 

    libwrapper をコンパイル時に組みこまれています。

On the one hand, for services configured in /etc/inetd.conf (this
includes telnet, ftp, netbios, swat and finger) you will see that the
configuration file executes /usr/sbin/tcpd first. On the other hand, even
if a service is not launched by the inetd superdaemon, support for the
tcp wrappers rules can be compiled into it. Services compiled with tcp
wrappers in Debian include ssh, portmap, in.talk, rpc.statd, rpc.mountd,
gdm, oaf (the GNOME activator daemon), nessus and many others.

To see which packages use tcpwrappers [25] try:

  $ apt-cache rdepends libwrap0

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

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

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

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


4.13. ログや警告の重要性
---------------

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

Debian GNU/Linux provides some tools to perform log analysis, most
notably swatch, [27] logcheck or log-analysis (all will need some
customisation to remove unnecessary things from the report). It might
also be useful, if the system is nearby, to have the system logs printed
on a virtual console. This is useful since you can (from a distance) see
if the system is behaving properly. Debian's /etc/syslog.conf comes with
a commented default configuration; to enable it uncomment the lines and
restart syslogd (/etc/init.d/syslogd restart):

  daemon,mail.*;\
        news.=crit;news.=err;news.=notice;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       /dev/tty8

To colorize the logs, you could take a look at colorize, ccze or glark.
There is a lot to log analysis that cannot be fully covered here, so a
good information resource would be books should as
http://books.google.com/books?id=UyktqN6GnWEC. In any case, even
automated tools are no match for the best analysis tool: your brain.


4.13.1. Using and customizing logcheck

The logcheck package in Debian is divided into the three packages
logcheck (the main program), logcheck-database (a database of regular
expressions for the program) and logtail (prints loglines that have not
yet been read). The Debian default (in /etc/cron.d/logcheck) is that
logcheck is run every hour and after reboots.

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

The best way to configure logcheck is to edit its main configuration file
/etc/logcheck/logcheck.conf after installation. Change the default user
(root) to whom reports should be mailed. You should set the reportlevel
in there, too. logcheck-database has three report levels of increasing
verbosity: workstation, server, paranoid. "server" being the default
level, paranoid is only recommended for high-security machines running as
few services as possible and workstation for relatively sheltered,
non-critical machines. If you wish to add new log files just add them to
/etc/logcheck/logcheck.logfiles. It is tuned for default syslog install.

Once this is done you might want to check the mails that are sent, for
the first few days/weeks/months. If you find you are sent messages you do
not wish to receive, just add the regular expressions (see regex(7) and
egrep(1)) that correspond to these messages to the
/etc/logcheck/ignore.d.reportlevel/local. Try to match the whole logline.
Details on howto write rules are explained in
/usr/share/doc/logcheck-database/README.logcheck-database.gz. It's an
ongoing tuning process; once the messages that are sent are always
relevant you can consider the tuning finished. Note that if logcheck does
not find anything relevant in your system it will not mail you even if it
does run (so you might get a mail only once a week, if you are lucky).


4.13.2. 警告の送り先を設定する

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

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

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

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

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


4.13.3. ログホストを使う

A loghost is a host which collects syslog data remotely over the network.
If one of your machines is cracked, the intruder is not able to cover the
tracks, unless hacking the loghost as well. So, the loghost should be
especially secure. Making a machine a loghost is simple. Just start the
syslogd with

syslogd -r

and a new loghost is born. In order to do this permanently in Debian,
edit /etc/default/syslogd and change the line

SYSLOGD=""

to

SYSLOGD="-r"

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

  facility.level            @your_loghost

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

  *.*                       @your_loghost

into your syslog.conf. Logging remotely as well as locally is the best
solution (the attacker might presume to have covered his tracks after
deleting the local log files). See the syslog(3), syslogd(8) and
syslog.conf(5) manpages for additional information.


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

It is not only important to decide how alerts are used, but also who has
read/modify access to the log files (if not using a remote loghost).
Security alerts which the attacker can change or disable are not worth
much in the event of an intrusion. Also, you have to take into account
that log files might reveal quite a lot of information about your system
to an intruder who has access to them.

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

  #  find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
  (see to what users do files in /var/log belong)
  #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
  (see to what groups do files in /var/log belong)
  # find /var/log -perm +004
  (files which are readable by any user)
  #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
  (files which belong to groups not root or adm)

To customize how log files are created you will probably have to
customize the program that generates them. If the log file gets rotated,
however, you can customize the behavior of creation and rotation.


4.14. カーネルパッチを追加する
------------------

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

  * 

    Linux Intrusion Detection provided in the kernel-patch-2.4-lids
    package. This kernel patch makes the process of hardening your Linux
    system easier by allowing you to restrict, hide and protect
    processes, even from root. It implements mandatory access control
    capabilities.

  * 

    Linux Trustees, provided in package trustees. This patch adds a
    decent advanced permissions management system to your Linux kernel.
    Special objects (called trustees) are bound to every file or
    directory, and are stored in kernel memory, which allows fast lookup
    of all permissions.

  * 

    NSA Enhanced Linux (in package selinux). Backports of the
    SElinux-enabled packages are available at
    https://salsa.debian.org/selinux-team. More information available at
    SElinux in Debian Wiki page, at Manoj Srivastava's and Russell
    Cookers's SElinux websites.

  * 

    The kernel patch http://people.redhat.com/mingo/exec-shield provided
    in the kernel-patch-exec-shield package. This patch provides
    protection against some buffer overflows (stack smashing attacks).

  * 

    The Grsecurity patch, provided by the kernel-patch-2.4-grsecurity and
    kernel-patch-grsecurity2 packages [28] implements Mandatory Access
    Control through RBAC, provides buffer overflow protection through
    PaX, ACLs, network randomness (to make OS fingerprinting more
    difficult) and many more features.

  * 

    The kernel-patch-adamantix provides the patches developed for
    Adamantix, a Debian-based distribution. This kernel patch for the
    2.4.x kernel releases introduces some security features such as a
    non-executable stack through the use of
    http://pageexec.virtualave.net/ and mandatory access control based on
    http://www.rsbac.org/. Other features include:
    http://www.vanheusden.com/Linux/sp/, AES encrypted loop device, MPPE
    support and an IPSEC v2.6 backport.

  * 

    cryptoloop-source. This patches allows you to use the functions of
    the kernel crypto API to create encrypted filesystems using the
    loopback device.

  * 

    IPSEC kernel support (in package linux-patch-openswan). If you want
    to use the IPsec protocol with Linux, you need this patch. You can
    create VPNs with this quite easily, even to Windows machines, as
    IPsec is a common standard. IPsec capabilities have been added to the
    2.5 development kernel, so this feature will be present by default in
    the future Linux Kernel 2.6. Homepage: http://www.openswan.org. FIXME:
    The latest 2.4 kernels provided in Debian include a backport of the
    IPSEC code from 2.5. Comment on this.

The following security kernel patches are only available for old kernel
versions in woody and are deprecated:

  * 

    http://acl.bestbits.at/ (ACLs) for Linux provided in the package
    kernel-patch-acl. This kernel patch adds access control lists, an
    advanced method for restricting access to files. It allows you to
    control fine-grain access to files and directory.

  * 

    The http://www.openwall.com/linux/ linux kernel patch by Solar
    Designer, provided in the kernel-patch-2.2.18-openwall package. This
    is a useful set of kernel restrictions, like restricted links, FIFOs
    in /tmp, a restricted /proc file system, special file descriptor
    handling, non-executable user stack area and other features. Note:
    This package applies to the 2.2 release, no packages are available
    for the 2.4 release patches provided by Solar.

  * 

    kernel-patch-int. This patch also adds cryptographic capabilities to
    the Linux kernel, and was useful with Debian releases up to Potato.
    It doesn't work with Woody, and if you are using Sarge or a newer
    version, you should use a more recent kernel which includes these
    features already.

However, some patches have not been provided in Debian yet. If you feel
that some of these should be included please ask for it at the
http://www.debian.org/devel/wnpp/.


4.15. Protecting against buffer overflows
-----------------------------------------

Buffer overflow is the name of a common attack to software [29] which
makes use of insufficient boundary checking (a programming error, most
commonly in the C language) in order to execute machine code through
program inputs. These attacks, against server software which listen to
connections remotely and against local software which grant higher
privileges to users (setuid or setgid) can result in the compromise of
any given system.

There are mainly four methods to protect against buffer overflows:

  * 

    patch the kernel to prevent stack execution. You can use either:
    Exec-shield, OpenWall or PaX (included in the Grsecurity and
    Adamantix patches).

  * 

    fix the source code by using tools to find fragments of it that might
    introduce this vulnerability.

  * 

    recompile the source code to introduce proper checks that prevent
    overflows, using the
    http://www.research.ibm.com/trl/projects/security/ssp/ patch for GCC
    (which is used by http://www.adamantix.org)

Debian GNU/Linux, as of the 3.0 release, provides software to introduce
all of these methods except for the protection on source code compilation
(but this has been requested in http://bugs.debian.org/213994).

Notice that even if Debian provided a compiler which featured
stack/buffer overflow protection all packages would need to be recompiled
in order to introduce this feature. This is, in fact, what the Adamantix
distribution does (among other features). The effect of this new feature
on the stability of software is yet to be determined (some programs or
some processor architectures might break due to it).

In any case, be aware that even these workarounds might not prevent
buffer overflows since there are ways to circumvent these, as described
in phrack's magazine
http://packetstorm.linuxsecurity.com/mag/phrack/phrack58.tar.gz or in
CORE's Advisory http://online.securityfocus.com/archive/1/269246.

If you want to test out your buffer overflow protection once you have
implemented it (regardless of the method) you might want to install the
paxtest and run the tests it provides.


4.15.1. Kernel patch protection for buffer overflows

Kernel patches related to buffer overflows include the Openwall patch
provides protection against buffer overflows in 2.2 linux kernels. For
2.4 or newer kernels, you need to use the Exec-shield implementation, or
the PaX implementation (provided in the grsecurity patch,
kernel-patch-2.4-grsecurity, and in the Adamantix patch,
kernel-patch-adamantix). For more information on using these patches read
the the section 「カーネルパッチを追加する」.


4.15.2. Testing programs for overflows

The use of tools to detect buffer overflows requires, in any case, of
programming experience in order to fix (and recompile) the code. Debian
provides, for example: bfbtester (a buffer overflow tester that
brute-forces binaries through command line and environment overflows).
Other packages of interest would also be rats, pscan, flawfinder and
splint.


4.16. ファイルの安全な転送
----------------

During normal system administration one usually needs to transfer files
in and out from the installed system. Copying files in a secure manner
from a host to another can be achieved by using the ssh server package.
Another possibility is the use of ftpd-ssl, a ftp server which uses the
Secure Socket Layer to encrypt the transmissions.

Any of these methods need special clients. Debian does provide client
software, such as scp from the ssh package, which works like rcp but is
encrypted completely, so the bad guys cannot even find out WHAT you copy.
There is also a ftp-ssl package for the equivalent server. You can find
clients for these software even for other operating systems (non-UNIX),
putty and winscp provide secure copy implementations for any version of
Microsoft's operating system.

Note that using scp provides access to the users to all the file system
unless chroot'ed as described in 「Chrooting ssh」. FTP access can be
chroot'ed, probably easier depending on you chosen daemon, as described
in 「FTP を安全にする」. If you are worried about users browsing your local files
and want to have encrypted communication you can either use an ftp daemon
with SSL support or combine clear-text ftp and a VPN setup (see
「バーチャルプライベートネットワーク」).


4.17. ファイルシステムの制限と制御
--------------------


4.17.1. quota を使う

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

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

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

  * 

    quota を十分に小さくして、ユーザがディスクスペースを食いつくさない ようにしましょう。

  * 

    quota を十分に大きくして、ユーザが文句を言ったりメール quota の
    せいでユーザが長期間メールを受けとれなくなったりしないようにしましょう。

  * 

    Use quotas on all user-writable areas, on /home as well as on /tmp.

Every partition or directory to which users have full write access should
be quota enabled. Calculate and assign a workable quota size for those
partitions and directories which combines usability and security.

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

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

touch
/home/quota.user /home/quota.group

for a /home file system).

Restart quota by doing

/etc/init.d/quota stop;/etc/init.d/quota
        start

. Now quota should be running, and quota sizes can be set.

Editing quotas for a specific user can be done by

edquota -u <user>

. Group quotas can be modified with

edquota -g <group>

. Then set the soft and hard quota and/or inode quotas as needed.

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


4.17.2. The ext2 filesystem specific attributes (chattr/lsattr)

In addition to the usual Unix permissions, the ext2 and ext3 filesystems
offer a set of specific attributes that give you more control over the
files on your system. Unlike the basic permissions, these attributes are
not displayed by the usual ls -l command or changed using chmod, and you
need two other utilities, lsattr and chattr (in package e2fsprogs) to
manage them. Note that this means that these attributes will usually not
be saved when you backup your system, so if you change any of them, it
may be worth saving the successive chattr commands in a script so that
you can set them again later if you have to restore a backup.

Among all available attributes, the two that are most important for
increasing security are referenced by the letters 'i' and 'a', and they
can only be set (or removed) by the superuser:

  * 

    The 'i' attribute ('immutable'): a file with this attribute can
    neither be modified nor deleted or renamed and no link can be created
    to it, even by the superuser.

  * 

    The 'a' attribute ('append'): this attribute has the same effect that
    the immutable attribute, except that you can still open the file in
    append mode. This means that you can still add more content to it but
    it is impossible to modify previous content. This attribute is
    especially useful for the log files stored in /var/log/, though you
    should consider that they get moved sometimes due to the log rotation
    scripts.

These attributes can also be set for directories, in which case everyone
is denied the right to modify the contents of a directory list (e.g.
rename or remove a file, ...). When applied to a directory, the append
attribute only allows file creation.

It is easy to see how the 'a' attribute improves security, by giving to
programs that are not running as the superuser the ability to add data to
a file without modifying its previous content. On the other hand, the 'i'
attribute seems less interesting: after all, the superuser can already
use the basic Unix permissions to restrict access to a file, and an
intruder that would get access to the superuser account could always use
the chattr program to remove the attribute. Such an intruder may first be
confused when noticing not being able to remove a file, but you should
not assume blindness - after all, the intruder got into your system! Some
manuals (including a previous version of this document) suggest to simply
remove the chattr and lsattr programs from the system to increase
security, but this kind of strategy, also known as "security by
obscurity", is to be absolutely avoided, since it provides a false sense
of security.

A secure way to solve this problem is to use the capabilities of the
Linux kernel, as described in 「事前の対策」. The capability of interest here is
called CAP_LINUX_IMMUTABLE: if you remove it from the capabilities
bounding set (using for example the command lcap CAP_LINUX_IMMUTABLE) it
won't be possible to change any 'a' or 'i' attribute on your system
anymore, even by the superuser ! A complete strategy could be as follows:

  * 

    Set the attributes 'a' and 'i' on any file you want;

  * 

    Add the command lcap CAP_LINUX_IMMUTABLE (as well as lcap
    CAP_SYS_MODULE, as suggested in 「事前の対策」) to one of the startup
    scripts;

  * 

    Set the 'i' attribute on this script and other startup files, as well
    as on the lcap binary itself;

  * 

    Execute the above command manually (or reboot your system to make
    sure everything works as planned).

Now that the capability has been removed from the system, an intruder
cannot change any attribute on the protected files, and thus cannot
change or remove the files. If the machine is forced to reboot (which is
the only way to restore the capabilities bounding set), it will easily be
detected, and the capability will be removed again as soon as the system
restarts anyway. The only way to change a protected file would be to boot
the system in single-user mode or using another bootdisk, two operations
that require physical access to the machine !


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

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

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

Common tools used for this are sxid, aide (Advanced Intrusion Detection
Environment), tripwire, integrit and samhain. Installing debsums will
also help you to check the file system integrity, by comparing the
md5sums of every file against the md5sums used in the Debian package
archive. But beware: those files can easily be changed by an attacker and
not all packages provide md5sums listings for the binaries they provided.
For more information please read 「Do periodic integrity checks」 and
「Taking a snapshot of the system」.

You might want to use locate to index the whole filesystem, if so,
consider the implications of that. The Debian findutils package contains
locate which runs as user nobody, and so it only indexes files which are
visible to everybody. However, if you change it's behaviour you will make
all file locations visible to all users. If you want to index all the
filesystem (not the bits that the user nobody can see) you can replace
locate with the package slocate. slocate is labeled as a security
enhanced version of GNU locate, but it actually provides additional
file-locating functionality. When using slocate, the user only sees the
actually accessible files and you can exclude any files or directories on
the system. The slocate package runs its update process with higher
privledges than locate, and indexes every file. Users are then able to
quickly search for every file which they are able to see. slocate doesn't
let them see new files; it filters the output based on your UID.

You might want to use bsign or elfsign. elfsign provides an utility to
add a digital signature to an ELF binary and a second utility to verify
that signature. The current implementation uses PKI to sign the checksum
of the binary. The benefits of doing this are that it enables one to
determine if a binary has been modified and who created it. bsign uses
GPG, elfsign uses PKI (X.509) certificates (OpenSSL).


4.17.4. setuid チェックを設定する

The Debian checksecurity package provides a cron job that runs daily in
/etc/cron.daily/checksecurity[30]. This cron job will run the
/usr/sbin/checksecurity script that will store information of this
changes.

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


4.18. Securing network access
-----------------------------

FIXME: More (Debian-specific) content needed.


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

Many features of the kernel can be modified while running by echoing
something into the /proc file system or by using sysctl. By entering
/sbin/sysctl -A you can see what you can configure and what the options
are, and it can be modified running

/sbin/sysctl -w variable=value

(see sysctl(8)). Only in rare cases do you need to edit something here,
but you can increase security that way as well. For example:

net/ipv4/icmp_echo_ignore_broadcasts = 1

This is a Windows emulator because it acts like Windows on broadcast ping
if this option is set to 1. That is, ICMP echo requests sent to the
broadcast address will be ignored. Otherwise, it does nothing.

If you want to prevent you system from answering ICMP echo requests, just
enable this configuration option:

net/ipv4/icmp_echo_ignore_all = 1

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

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

For more information on what things can be done with /proc/sys/net/ipv4/*
read /usr/src/linux/Documentation/filesystems/proc.txt. All the options
are described thoroughly under
/usr/src/linux/Documentation/networking/ip-sysctl.txt[31].


4.18.2. Configuring syncookies

This option is a double-edged sword. On the one hand it protects your
system against syn packet flooding; on the other hand it violates defined
standards (RFCs).

net/ipv4/tcp_syncookies = 1

If you want to change this option each time the kernel is working you
need to change it in /etc/network/options by setting syncookies=yes. This
will take effect when ever /etc/init.d/networking is run (which is
typically done at boot time) while the following will have a one-time
effect until the reboot:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

This option will only be available if the kernel is compiled with the
CONFIG_SYNCOOKIES. All Debian kernels are compiled with this option
builtin but you can verify it running:

$ sysctl -A |grep syncookies
net/ipv4/tcp_syncookies = 1

For more information on TCP syncookies read
http://cr.yp.to/syncookies.html.


4.18.3. Securing the network on boot-time

When setting configuration options for the kernel networking you need
configure it so that it's loaded every time the system is restarted. The
following example enables many of the previous options as well as other
useful options.

There are actually two ways to configure your network at boot time. You
can configure /etc/sysctl.conf (see: sysctl.conf(5)) or introduce a
script that is called when the interface is enabled. The first option
will be applied to all interfaces, whileas the second option allows you
to configure this on a per-interface basis.

An example of a /etc/sysctl.conf configuration that will secure some
network options at the kernel level is shown below. Notice the comment in
it, /etc/network/options might override some values if they contradict
those in this file when the /etc/init.d/networking is run (which is later
than procps on the startup sequence).

#
# /etc/sysctl.conf - Configuration file for setting system variables
# See sysctl.conf (5) for information. Also see the files under
# Documentation/sysctl/, Documentation/filesystems/proc.txt, and
# Documentation/networking/ip-sysctl.txt in the kernel sources 
# (/usr/src/kernel-$version if you have a kernel-package installed)
# for more information of the values that can be defined here.

#
# Be warned that /etc/init.d/procps is executed to set the following
# variables.  However, after that, /etc/init.d/networking sets some
# network options with builtin values.  These values may be overridden
# using /etc/network/options.
#
#kernel.domainname = example.com

# Additional settings - adapted from the script contributed
# by Dariusz Puchala (see below)
# Ignore ICMP broadcasts
net/ipv4/icmp_echo_ignore_broadcasts = 1
#
# Ignore bogus ICMP errors
net/ipv4/icmp_ignore_bogus_error_responses = 1
# 
# Do not accept ICMP redirects (prevent MITM attacks)
net/ipv4/conf/all/accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net/ipv4/conf/all/secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
net/ipv4/conf/all/send_redirects = 0
#
# Do not forward IP packets (we are not a router)
# Note: Make sure that /etc/network/options has 'ip_forward=no'
net/ipv4/conf/all/forwarding = 0
#
# Enable TCP Syn Cookies
# Note: Make sure that /etc/network/options has 'syncookies=yes'
net/ipv4/tcp_syncookies = 1
#
# Log Martian Packets
net/ipv4/conf/all/log_martians = 1
#
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
# Note: Make sure that /etc/network/options has 'spoofprotect=yes'
net/ipv4/conf/all/rp_filter = 1
#
# Do not accept IP source route packets (we are not a router)
net/ipv4/conf/all/accept_source_route = 0

To use the script you need to first create the script, for example, in
/etc/network/interface-secure (the name is given as an example) and call
it from /etc/network/interfaces like this:

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

In this example, before the interface eth0 is enabled the script will be
called to secure all network interfaces as shown below.

#!/bin/sh -e
# Script-name: /etc/network/interface-secure
#
# Modifies some default behavior in order to secure against 
# some TCP/IP spoofing & attacks for all interfaces.
#
# Contributed by Dariusz Puchalak.
#
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
                                           # Broadcast echo protection enabled.
echo 0 > /proc/sys/net/ipv4/conf/all/forwarding
                                           # IP forwarding disabled.
echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookies protection enabled.
echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Log strange packets.
# (this includes spoofed packets, source routed packets, redirect packets)
# but be careful with this on heavy loaded web servers.
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses 
                                           # Bad error message protection enabled.

# IP spoofing protection.
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# Disable ICMP redirect acceptance.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

# Disable source routed packets.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

exit 0

Notice that you can actually have per-interface scripts that will enable
different network options for different interfaces (if you have more than
one), just change the pre-up line to:

pre-up /etc/network/interface-secure $IFACE

And use a script which will only apply changes to a specific interface,
not to all of the interfaces available. Notice that some networking
options can only be enabled globally, however. A sample script is this
one:

#!/bin/sh -e
# Script-name: /etc/network/interface-secure
#
# Modifies some default behavior in order to secure against 
# some TCP/IP spoofing & attacks for a given interface.
#
# Contributed by Dariusz Puchalak.
#

IFACE=$1
if [ -z "$IFACE" ] ; then
   echo "$0: Must give an interface name as argument!"
   echo "Usage: $0 <interface>"
   exit 1
fi

if [ ! -e /proc/sys/net/ipv4/conf/$IFACE/ ]; then
   echo "$0: Interface $IFACE does not exit (cannot find /proc/sys/net/ipv4/conf/)"
   exit 1
fi

echo 0 > /proc/sys/net/ipv4/conf/$IFACE/forwarding  # IP forwarding disabled.
echo 1 >/proc/sys/net/ipv4/conf/$IFACE/log_martians # Log strange packets.
# (this includes spoofed packets, source routed packets, redirect packets)
# but be careful with this on heavy loaded web servers.

# IP spoofing protection.
echo 1 > /proc/sys/net/ipv4/conf/$IFACE/rp_filter

# Disable ICMP redirect acceptance.
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/send_redirects

# Disable source routed packets.
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_source_route

exit 0

An alternative solution is to create an init.d script and have it run on
bootup (using update-rc.d to create the appropriate rc.d links).


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

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

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

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


4.18.5. Disabling weak-end hosts issues

Systems with more than one interface on different networks can have
services configured so that they will bind only to a given IP address.
This usually prevents access to services when requested through any other
address. However, this does not mean (although it is a common
misconception) that the service is bound to a given hardware address
(interface card). [32]

It seems, however, not to work with services bound to 127.0.0.1, you
might need to write the tests using raw sockets.

This is not an ARP issue and it's not an RFC violation (it's called weak
end host in RFC1122, (in the section 3.3.4.2). Remember, IP addresses
have nothing to do with physical interfaces.

On 2.2 (and previous) kernels this can be fixed with:

# echo 1 > /proc/sys/net/ipv4/conf/all/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
.....

On later kernels this can be fixed either with:

  * 

    Iptables の規則

  * 

    properly configured routing. [33]

  * 

    kernel patching. [34]

Along this text there will be many occasions in which it is shown how to
configure some services (sshd server, apache, printer service...) in
order to have them listening on any given address, the reader should take
into account that, without the fixes given here, the fix would not
prevent accesses from within the same (local) network. [35]

FIXME: Comments on Bugtraq indicate there is a Linux specific method to
bind to a given interface.

FIXME: Submit a bug against netbase so that the routing fix is standard
behavior in Debian?


4.18.6. Protecting against ARP attacks

When you don't trust the other boxes on your LAN (which should always be
the case, because it's the safest attitude) you should protect yourself
from the various existing ARP attacks.

As you know the ARP protocol is used to link IP addresses to MAC
addresses (see ftp://ftp.isi.edu/in-notes/rfc826.txt for all the
details). Every time you send a packet to an IP address an ARP resolution
is done (first by looking into the local ARP cache then if the IP isn't
present in the cache by broadcasting an ARP query) to find the target's
hardware address. All the ARP attacks aim to fool your box into thinking
that box B's IP address is associated to the intruder's box's MAC
address; Then every packet that you want to send to the IP associated to
box B will be send to the intruder's box...

Those attacks (ARP cache poisoning, ARP spoofing...) allow the attacker
to sniff the traffic even on switched networks, to easily hijack
connections, to disconnect any host from the network... ARP attacks are
powerful and simple to implement, and several tools exists, such as
arpspoof from the dsniff package or http://arpoison.sourceforge.net/.

However, there is always a solution:

  * 

    Use a static ARP cache. You can set up "static" entries in your ARP
    cache with:

      arp -s host_name hdwr_addr 

    By setting static entries for each important host in your network you
    ensure that nobody will create/modify a (fake) entry for these hosts
    (static entries don't expire and can't be modified) and spoofed ARP
    replies will be ignored.

  * 

    Detect suspicious ARP traffic. You can use arpwatch, karpski or more
    general IDS that can also detect suspicious ARP traffic (snort,
    http://www.prelude-ids.org...).

  * 

    Implement IP traffic filtering validating the MAC address.


4.19. Taking a snapshot of the system
-------------------------------------

Before putting the system into production system you could take a
snapshot of the whole system. This snapshot could be used in the event of
a compromise (see 11ç« After the compromise (incident response)). You
should remake this upgrade whenever the system is upgraded, especially if
you upgrade to a new Debian release.

For this you can use a writable removable-media that can be set up
read-only, this could be a floppy disk (read protected after use), a CD
on a CD-ROM unit (you could use a rewritable CD-ROM so you could even
keep backups of md5sums in different dates), or a USB disk or MMC card
(if your system can access those and they can be write protected).

The following script creates such a snapshot:

#!/bin/bash
/bin/mount /dev/fd0 /mnt/floppy
trap "/bin/umount /dev/fd0" 0 1 2 3 9 13 15
if [ ! -f /usr/bin/md5sum ] ; then
        echo "Cannot find md5sum. Aborting."
        exit 1
fi
/bin/cp /usr/bin/md5sum /mnt/floppy
echo "Calculating md5 database"
>/mnt/floppy/md5checksums.txt
for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
do
   find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt
done
echo "post installation md5 database calculated"
if [ ! -f /usr/bin/sha1sum ] ; then
        echo "Cannot find sha1sum"
        echo "WARNING: Only md5 database will be stored"
else
        /bin/cp /usr/bin/sha1sum /mnt/floppy
        echo "Calculating SHA-1 database"
        >/mnt/floppy/sha1checksums.txt
        for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
        do
           find $dir -type f | xargs /usr/bin/sha1sum >>/mnt/floppy/sha1checksums-lib.txt
        done
        echo "post installation sha1 database calculated"
fi
exit 0

Note that the md5sum binary (and sha1sum, if available) is placed on the
floppy drive so it can be used later on to check the binaries of the
system (just in case it gets trojaned). However, if you want to make sure
that you are running a legitimate binary, you might want to either
compile a static copy of the md5sum binary and use that one (to prevent a
trojaned libc library from interfering with the binary) or to use the
snapshot of md5sums only from a clean environment such as a rescue CD-ROM
or a Live-CD (to prevent a trojaned kernel from interfering). I cannot
stress this enough: if you are on a compromised system you cannot trust
its output, see 11ç« After the compromise (incident response).

The snapshot does not include the files under /var/lib/dpkg/info which
includes the MD5 hashes of installed packages (in files ending with
.md5sums). You could copy this information along too, however you should
notice:

  * 

    the md5sums files include the md5sum of all files provided by the
    Debian packages, not just system binaries. As a consequence, that
    database is bigger (5 Mb versus 600 Kb in a Debian GNU/Linux system
    with a graphical system and around 2.5 Gb of software installed) and
    will not fit in small removable media (like a single floppy disk, but
    would probably fit in a removable USB memory).

  * 

    not all Debian packages provide md5sums for the files installed since
    it is not (currently) mandated policy. Notice, however, that you can
    generate the md5sums for all packages using debsums after you've
    finished the system installation:

    # debsums --generate=missing,keep  

Once the snapshot is done you should make sure to set the medium
read-only. You can then store it for backup or place it in the drive and
use it to drive a cron check nightly comparing the original md5sums
against those on the snapshot.

If you do not want to setup a manual check you can always use any of the
integrity systems available that will do this and more, for more
information please read 「Do periodic integrity checks」.


4.20. 推奨されている他の事項
-----------------


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

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


------------------------------------------------------------------------

[9] In Etch and later releases

[10] Even though the libraries have been removed from the filesystem the
inodes will not be cleared up until no program has an open file
descriptor pointing to them.

[11] This happened, for example, in the upgrade from libc6 2.2.x to 2.3.x
due to NSS authentication issues, see
http://lists.debian.org/debian-glibc/2003/03/msg00276.html.

[12] Unless you have installed a kernel metapackage like
linux-image-2.6-686 which will always pull in the latest kernel minor
revision for a kernel release and a given architecture.

[13] A sample script called testnet is available in the Remotely
rebooting Debian GNU/Linux machines article. A more elaborate network
connectivity testing script is available in this Testing network
connectivity article.

[14] Setting up a serial console is beyond the scope of this document,
for more information read the Serial HOWTO and the Remote Serial Console
HOWTO.

[15] Some of this includes the package manager dpkg since the
installation (post,pre) and removal (post,pre) scripts are at
/var/lib/dpkg/ and Smartlist

[16] In old Debian releases the configuration of the modules was defined
directly in /etc/pam.d/passwd.

[17] The minlen option is not entirely straightforward and is not exactly
the number of characters in the password. A tradeoff can be defined
between complexity and length by adjusting the "credit" parameters of
different character classes. For more information read the pam_cracklib(8)
manpage.

[18] The default content of this file provides information about the
operating system and version run by the system, which you might not want
to provide to anonymous users.

[19] libpam-chroot has not been yet thoroughly tested, it does work for
login but it might not be easy to set up the environment for other
programs

[20] Setting HISTSIZE to a very large number can cause issues under some
shells since the history is kept in memory for every user session. You
might be safer if you set this to a high-enough value and backup user's
history files (if you need all of the user's history for some reason)

[21] Without the append-only flag users would be able to empty the
contents of the history file running > .bash_history

[22] Ttys are spawned for local logins and remote logins through ssh and
telnet

[23] As defined in /etc/adduser.conf (USERGROUPS=yes). You can change
this behaviour if you set this value to no, although it is not
recommended

[24] Chpasswd cannot handle MD5 password generation so it needs to be
given the password in encrypted form before using it, with the

-e

option.

[25] On older Debian releases you might need to do this:

  $ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \
        sed 's/,libwrap0$//;s/^[[:space:]]\+//'

[26] ここで大文字に注意してください。というのも、spawn では うまくいかないからです。

[27] there's a very good article on it written by
http://www.spitzner.net/swatch.html

[28] Notice that this patch conflicts with patches already included in
Debian's 2.4 kernel source package. You will need to use the stock
vanilla kernel. You can do this with the following steps:

# apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
# tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
# cd kernel-source-2.4.22
# /usr/src/kernel-patches/all/2.4.22/unpatch/debian

For more information see http://bugs.debian.org/194225,
http://bugs.debian.org/199519, http://bugs.debian.org/206458,
http://bugs.debian.org/203759, http://bugs.debian.org/204424,
http://bugs.debian.org/210762, http://bugs.debian.org/211213, and the
http://lists.debian.org/debian-devel/2003/09/msg01133.html

[29] So common, in fact, that they have been the basis of 20% of the
reported security vulnerabilities every year, as determined by
http://icat.nist.gov/icat.cfm?function=statistics

[30] In previous releases, checksecurity was integrated into cron and the
file was /etc/cron.daily/standard

[31] In Debian the kernel-source-version packages copy the sources to
/usr/src/kernel-source-version.tar.bz2, just substitute version to
whatever kernel version sources you have installed

[32] To reproduce this (example provided by Felix von Leitner on the
Bugtraq mailing list):

   host a (eth0 connected to eth0 of host b):
     ifconfig eth0 10.0.0.1
     ifconfig eth1 23.0.0.1
     tcpserver -RHl localhost 23.0.0.1 8000 echo fnord

   host b:
     ifconfig eth0 10.0.0.2
     route add 23.0.0.1 gw 10.0.0.1
     telnet 23.0.0.1 8000

[33] The fact that this behavior can be changed through routing was
described by Matthew G. Marsh in the Bugtraq thread:

eth0 = 1.1.1.1/24
eth1 = 2.2.2.2/24

ip rule add from 1.1.1.1/32 dev lo table 1 prio 15000
ip rule add from 2.2.2.2/32 dev lo table 2 prio 16000

ip route add default dev eth0 table 1
ip route add default dev eth1 table 2

[34] There are some patches available for this behavior as described in
Bugtraq's thread at http://www.linuxvirtualserver.org/~julian/#hidden and
http://www.fefe.de/linux-eth-forwarding.diff.

[35] An attacker might have many problems pulling the access through
after configuring the IP-address binding while not being on the same
broadcast domain (same network) as the attacked host. If the attack goes
through a router it might be quite difficult for the answers to return
somewhere.



第5章 システム上で動いているサービスを安全にする
=========================

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

  * 

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

  * 

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

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

Regarding the services running from inetd (telnet, ftp, finger, pop3...)
it is worth noting that inetd can be configured so that services only
listen on a given interface (using service@ip syntax) but that's an
undocumented feature. One of its substitutes, the xinetd meta-daemon
includes a bind option just for this matter. See ixnetd.conf(5) manual
page.

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
}

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


5.1. ssh を使う
------------

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

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

  * 

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

  * 

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

  * 

    Port 666 or ListenAddress 192.168.0.1:666 Change the listen port, so
    the intruder cannot be completely sure whether a sshd daemon runs (be
    forewarned, this is security by obscurity).

  * 

    PermitEmptyPasswords no Empty passwords make a mockery of system
    security.

  * 

    AllowUsers alex ref me@somewhere Allow only certain users to have
    access via ssh to this machine. user@host can also be used to
    restrict a given user from accessing only at a given host.

  * 

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

  * 

    何をしたいかは完全にあなたが選べます。ssh の鍵をファイル ~/.ssh/authorized_keys
    に置いているユーザからのマシンへのアクセスだけを 許可するほうがより安全です。もしそうしたいなら、これを「no」に設定して ください。

  * 

    Disable any form of authentication you do not really need, if you do
    not use, for example RhostsRSAAuthentication, HostbasedAuthentication,
    KerberosAuthentication or RhostsAuthentication you should disable
    them, even if they are already by default (see the manpage
    sshd_config(5) manual page).

  * 

    Protocol 2 Disable the protocol version 1, since it has some design
    flaws that make it easier to crack passwords. For more information
    read http://earthops.net/ssh-timing.pdf or the
    http://xforce.iss.net/static/6449.php.

  * 

    Banner /etc/some_file Add a banner (it will be retrieved from the
    file) to users connecting to the ssh server. In some countries
    sending a warning before access to a given system about unauthorized
    access or user monitoring should be added to have legal protection.

You can also restrict access to the ssh server using pam_listfile or
pam_wheel in the PAM control file. For example, you could keep anyone not
listed in /etc/loginusers away by adding this line to /etc/pam.d/ssh:

auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers

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

You can read more information on how to set up SSH with PAM support in
the http://lists.debian.org/debian-security/2001/11/msg00395.html.


5.1.1. Chrooting ssh

Currently OpenSSH does not provide a way to chroot automatically users
upon connection (the commercial version does provide this functionality).
However there is a project to provide this functionality for OpenSSH too,
see http://chrootssh.sourceforge.net, it is not currently packaged for
Debian, though. You could use, however, the pam_chroot module as
described in 「ユーザを制限する」.

In 「Chroot environment for SSH」 you can find several options to make a
chroot environment for SSH.


5.1.2. Ssh clients

If you are using an SSH client against the SSH server you must make sure
that it supports the same protocols that are enforced on the server. For
example, if you use the mindterm package, it only supports protocol
version 1. However, the sshd server is, by default, configured to only
accept version 2 (for security reasons).


5.1.3. Disallowing file transfers

If you do not want users to transfer files to and from the ssh server you
need to restrict access to the sftp-serverand the scp access. You can
restrict sftp-server by configuring the proper Subsystem in the
/etc/ssh/sshd_config.

You can also chroot users (using libpam-chroot so that, even if file
transfer is allowed, they are limited to an environment which does not
include any system files.


5.1.4. Restricing access to file transfer only

You might want to restrict access to users so that they can only do file
transfers and cannot have interactive shells. In order to do this you can
either:

  * 

    disallow users from login to the ssh server (as described above
    either through the configuration file or PAM configuration).

  * 

    give users a restricted shell such as scponly or rssh. These shells
    restrict the commands available to the users so that they are not
    provided any remote execution priviledges.


5.2. Squid を安全にする
-----------------

Squid is one of the most popular proxy/cache server, and there are some
security issues that should be taken into account. Squid's default
configuration file denies all users requests. However the Debian package
allows access from 'localhost', you just need to configure your browser
properly. You should configure Squid to allow access to trusted users,
hosts or networks defining an Access Control List on
/etc/squid/squid.conf, see the
https://web.archive.org/web/20061206052115/http://www.deckle.co.za/squid-users-guide/Main_Page
for more information about defining ACLs rules. Notice that Debian
provides a minimum configuration for Squid that will prevent anything,
except from localhost to connect to your proxy server (which will run in
the default port 3128). You will need to customize your
/etc/squid/squid.conf as needed.

The recommended minimum configuration (provided with the package) is
shown below:

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443 563     # https, snews
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl Safe_ports port 901         # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
(...)
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
# Only allow purge requests from localhost
http_access allow purge localhost
http_access deny purge
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
http_access allow localhost
# And finally deny all other access to this proxy
http_access deny all
#Default:
# icp_access deny all
#
#Allow ICP queries from everyone
icp_access allow all

You should also configure Squid based on your system resources, including
cache memory (option cache_mem), location of the cached files and the
amount of space they will take up on disk (option cache_dir).

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

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

  * 

    calamaris - Log analyzer for Squid or Oops proxy log files.

  * 

    modlogan - A modular logfile analyzer.

  * 

    sarg - Squid Analysis Report Generator.

  * 

    squidtaild - Squid log monitoring program.

When using Squid in Accelerator Mode it acts as a web server too. Turning
on this option increases code complexity, making it less reliable. By
default Squid is not configured to act as a web server, so you don't need
to worry about this. Note that if you want to use this feature be sure
that it is really necessary. To find more information about Accelerator
Mode on Squid see the
https://web.archive.org/web/20070104164802/http://www.deckle.co.za/squid-users-guide/Accelerator_Mode


5.3. FTP を安全にする
---------------

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

DefaultRoot ~

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

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

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

However, if you still maintain the FTP server while making users access
through SSH you might encounter a typical problem. Users accessing
anonymous FTP servers inside SSH-secured systems might try to log in the
FTP server. While the access will be refused, the password will
nevertheless be sent through the net in clear form. To avoid that,
ProFTPd developer TJ Saunders has created a patch that prevents users
feeding the anonymous FTP server with valid SSH accounts. More
information and patch available at:
http://www.castaglia.org/proftpd/#Patches. This patch has been reported
to Debian too, see http://bugs.debian.org/145669.


5.4. X Window System へのアクセスを安全にする
---------------------------------

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

A much more secure solution, though, is to use ssh to tunnel X and
encrypt the whole session. This is done automatically when you ssh to
another machine. For this to work, you have to configure both the ssh
client and the ssh server. On the ssh client, ForwardX11 should be set to
yes in /etc/ssh/ssh_config. On the ssh server, X11Forwarding should be
set to yes in /etc/ssh/sshd_config and the package xbase-clients should
be installed because the ssh server uses /usr/X11R6/bin/xauth (/usr/bin/xauth
on Debian unstable) when setting up the pseudo X display. In times of
SSH, you should drop the xhost based access control completely.

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

$ startx -- -nolisten tcp

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

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

If you are using XDM set /etc/X11/xdm/Xservers to: :0 local
/usr/bin/X11/X vt7 -dpi 100 -nolisten tcp. If you are using Gdm make sure
that the DisallowTCP=true option is set in the /etc/gdm/gdm.conf (which
is the default in Debian). This will basically append -nolisten tcp to
every X command line [36].

You can also set the default's system timeout for xscreensaver locks.
Even if the user can override it, you should edit the
/etc/X11/app-defaults/XScreenSaver configuration file and change the lock
line:

*lock:                  False

(which is the default in Debian) to:

*lock:                  True

FIXME: Add information on how to disable the screensavers which show the
user desktop (which might have sensitive information).

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

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


5.4.1. ディスプレイマネージャを調べる

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

DisplayManager.requestPort:     0

For GDM there should be in your gdm.conf:

[xdmcp]
Enable=false

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


5.5. プリントサービスを安全にする (lpd と lprng の問題)
-------------------------------------

Imagine, you arrive at work, and the printer is spitting out endless
amounts of paper because someone is DoSing your line printer daemon.
Nasty, isn't it?

In any UNIX printing architecture, there has to be a way to get the
client's data to the host's print server. In traditional lpr and lp, the
client command copies or symlinks the data into the spool directory
(which is why these programs are usually SUID or SGID).

職場に着いたとき、だれかがあなたのラインプリンタデーモンに DoS しているせいで
プリンタが紙を際限なくはきだしているとしましょう。いやでしょう? だから プリンタサーバを特に安全にしましょう。これは信用されているサーバからの
接続のみを許可するようプリンタサービスを設定する必要があるということです。 これを行うには、印刷を許可したいサーバを /etc/hosts.lpd
に 追加してください。

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

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

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

In cups, the print data is transferred to the server via the HTTP
protocol. This means the client program doesn't need any special
privileges, but does require that the server is listening on a port
somewhere.

また、cups は /etc/cups/cupsd.conf をこのように 変更することによってループバックインターフェイスをバインドするように
設定できます:

Listen 127.0.0.1:631

There are many other security options like allowing or denying networks
and hosts in this config file. However, if you do not need them you might
be better off just limiting the listening port. Cups also serves
documentation through the HTTP port, if you do not want to disclose
potential useful information to outside attackers (and the port is open)
add also:

<Location />
 Order Deny,Allow
 Deny From All
 Allow From 127.0.0.1
</Location>

This configuration file can be modified to add some more features
including SSL/TLS certificates and crypto. The manuals are available at
http://localhost:631/ or at http://cups.org.

FIXME: Add more content (the article on http://www.rootprompt.org
provides some very interesting views).

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

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


5.6. Securing the mail service
------------------------------

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

If you have exim you do not need the daemon to be working in order to do
this since the standard cron job flushes the mail queue. See
「デーモンサービスを停止する」 on how to do this.


5.6.1. Configuring a Nullmailer

You might want to have a local mailer daemon so that it can relay the
mails sent locally to another system. This is common when you have to
administer a number of systems and do not want to connect to each of them
to read the mail sent locally. Just as all logging of each individual
system can be centralized by using a central syslog server, mail can be
sent to a central mailserver.

Such a relay-only system should be configured properly for this. The
daemon could, as well, be configured to only listen on the loopback
address.

The following configuration steps only need to be taken to configure the
exim package in the Debian 3.0 release. If you are using a later release
(such as 3.1 which uses exim4) the installation system has been improved
so that if the mail transport agent is configured to only deliver local
mail it will automatically only allow connections from the local host and
will not permit remote connections.

In a Debian 3.0 system using exim, you will have to remove the SMTP
daemon from inetd:

$ update-inetd --disable smtp

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

local_interfaces = "127.0.0.1"

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

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

inet_interfaces = localhost

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

In any case, to reject mail relay attempts at the SMTP level, you can
change /etc/exim/exim.conf to include:

receiver_verify = true

Even if your mail server will not relay the message, this kind of
configuration is needed for the relay tester at
http://www.abuse.net/relay.html to determine that your server is not
relay capable.

If you want a relay-only setup, however, you can consider changing the
mailer daemon to programs that can only be configured to forward the mail
to a remote mail server. Debian provides currently both ssmtp and
nullmailer for this purpose. In any case, you can evaluate for yourself
any of the mail transport agents [37] provided by Debian and see which
one suits best to the system's purposes.


5.6.2. Providing secure access to mailboxes

If you want to give remote access to mailboxes there are a number of POP3
and IMAP daemons available.[38] However, if you provide IMAP access note
that it is a general file access protocol, it can become the equivalent
of a shell access because users might be able to retrieve any file that
they can through it.

Try, for example, to configure as your inbox path {server.com}/etc/passwd
if it succeeds your IMAP daemon is not properly configured to prevent
this kind of access.

Of the IMAP servers in Debian the cyrus server (in the cyrus-imapd
package) gets around this by having all access to a database in a
restricted part of the file system. Also, uw-imapd (either install the
uw-imapd or better, if your IMAP clients support it, uw-imapd-ssl) can be
configured to chroot the users mail directory but this is not enabled by
default. The documentation provided gives more information on how to
configure it.

Also, you might want to run an IMAP server that does not need valid users
to be created on the local system (which would grant shell access too),
courier-imap (for IMAP) and courier-pop, teapop (for POP3) and
cyrus-imapd (for both POP3 and IMAP) provide servers with authentication
methods beside the local user accounts. cyrus can use any authentication
method that can be configured through PAM while teapop might use
databases (such as postgresql and mysql) for user authentication.

FIXME: Check: uw-imapd might be configured with user authentication
through PAM too.


5.6.3. メールを安全に受けとる

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

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 </dev/null > /dev/null'

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

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

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

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


5.7. BIND を安全にする
----------------

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

  * 

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

  * 

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


5.7.1. Bind configuration to avoid misuse

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

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

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

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

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

options {
        ... various options here ...
        version "Not available.";
};

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

A sample named.conf configuration file might be the following:

acl internal {
        127.0.0.1/32;           // localhost
        10.0.0.0/8;             // internal
        aa.bb.cc.dd;            // eth0 IP
};

acl friendly {
        ee.ff.gg.hh;            // slave DNS
        aa.bb.cc.dd;            // eth0 IP
        127.0.0.1/32;           // localhost
        10.0.0.0/8;             // internal
};

options {
        directory "/var/cache/bind";
        allow-query { internal; };
        allow-recursion { internal; };
        allow-transfer { none; };
};
// From here to the mysite.bogus zone 
// is basically unmodified from the debian default
logging {
        category lame-servers { null; };
        category cname { null; };   
};

zone "." {
        type hint;
        file "/etc/bind/db.root";
};

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

// zones I added myself
zone "mysite.bogus" {
        type master;
        file "/etc/bind/named.mysite";
        allow-query { any; };
        allow-transfer { friendly; };
};

Please (again) check the Bug Tracking System regarding Bind, specifically
http://bugs.debian.org/94760. Feel free to contribute to the bug report
if you think you can add useful information.


5.7.2. Changing BIND's user

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

Notice, in any case, that this only applies to BIND version 8. In the
Debian packages for BIND version 9 (since the 9.2.1-5 version, available
since sarge) the bind user is created and used by setting the OPTIONS
variable in /etc/default/bind9. If you are using BIND version 9 and your
name server daemon is not running as the bind user verify the settings on
that file.

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

addgroup named
adduser --system --home /home/named --no-create-home --ingroup named \
      --disabled-password --disabled-login named

Notice that the user named will be quite restricted. If you want, for
whatever reason, to have a less restrictive setup use:

adduser --system --ingroup named named

そこであなたのすきなエディタで /etc/init.d/bind を編集し、

start-stop-daemon --start

to[39]

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

Or you can change (create it if it does not exit) the default
configuration file (/etc/default/bind for BIND version 8) and introduce
the following:

OPTIONS="-u named -g named"

Change the permissions of files that are used by Bind, including
/etc/bind/rndc.key:

-rw-r-----    1 root     named          77 Jan  4 01:02 rndc.key

and where bind creates its pidfile, using, for example, /var/run/named
instead of /var/run:

$ mkdir /var/run/named
$ chown named.named /var/run/named
$ vi /etc/named.conf
[ ... update the configuration file to use this new location ...]
options { ...
        pid-file "/var/run/named/named.pid";
};
[ ... ]

Also, in order to avoid running anything as root, change the reload line
in the init.d script by substituting:

reload)
       /usr/sbin/ndc reload

こう変更します:

reload)
        $0 stop
        sleep 1
        $0 start

Note: Depending on your Debian version you might have to change the
restart line too. This was fixed in Debian's bind version 1:8.3.1-2.

あと必要なのは「/etc/init.d/bind restart」で bind を再起動し、こういう 2 行が syslog
にないかさがすだけです。

Sep  4 15:11:08 nexus named[13439]: group = named
Sep  4 15:11:08 nexus named[13439]: user = named

Voilà! Your named now does not run as root. If you want to read more
information on why BIND does not run as non-root user on Debian systems,
please check the Bug Tracking System regarding Bind, specifically
http://bugs.debian.org/50013 and http://bugs.debian.org/132582,
http://bugs.debian.org/53550, http://bugs.debian.org/52745, and
http://bugs.debian.org/128129. Feel free to contribute to the bug reports
if you think you can add useful information.


5.7.3. Chrooting the name server

To achieve maximum BIND security, now build a chroot jail (see 「一般的な
chroot および suid のパラノイア」) around your daemon. There is an easy way to do
this: the -t option (see the named(8) manual page or page 100 of
http://www.nominum.com/content/documents/bind9arm.pdf). This will make
Bind chroot itself into the given directory without you needing to set up
a chroot jail and worry about dynamic libraries. The only files that need
to be in the chroot jail are:

dev/null
etc/bind/       - should hold named.conf and all the server zones
sbin/named-xfer - if you do name transfers
var/run/named/  - should hold the PID and the name server cache (if
                  any) this directory needs to be writable by named user
var/log/named   - if you set up logging to a file, needs to be writable
                  for the named user
dev/log         - syslogd should be listening here if named is configured to
                  log through it

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

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

If you are setting up a full chroot jail (i.e. not just -t) for Bind in
Debian, make sure you have the following files in it[40]:

dev/log - syslogd should be listening here
dev/null
etc/bind/named.conf 
etc/localtime
etc/group - with only a single line: "named:x:GID:"
etc/ld.so.cache - generated with ldconfig 
lib/ld-2.3.6.so
lib/libc-2.3.6.so
lib/ld-linux.so.2 - symlinked to ld-2.3.6.so
lib/libc.so.6 - symlinked to libc-2.3.6.so
sbin/ldconfig - may be deleted after setting up the chroot
sbin/named-xfer - if you do name transfers
var/run/

And modify also syslogd listen on $CHROOT/dev/log so the named server can
write syslog entries into the local system log.

If you want to avoid problems with dynamic libraries, you can compile
bind statically. You can use apt-get for this, with the source option. It
can even download the packages you need to properly compile it. You would
need to do something similar to:

$ apt-get source bind
# apt-get build-dep bind
$ cd bind-8.2.5-2
  (edit src/port/linux/Makefile so CFLAGS includes the '-static'
   option)
$ dpkg-buildpackage -rfakeroot -uc -us
$ cd ..
# dpkg -i bind-8.2.5-2*deb

After installation, you will need to move around the files to the chroot
jail[41] you can keep the init.d scripts in /etc/init.d so that the
system will automatically start the name server, but edit them to add
--chroot /location_of_chroot in the calls to start-stop-daemon in those
scripts or use the -t option for BIND by setting it in the OPTIONS
argument at the /etc/default/bind (for version 8) or /etc/default/bind9
(for version 9) configuration file.

For more information on how to set up chroots see 「一般的な chroot および suid
のパラノイア」.

FIXME: Merge info from
http://people.debian.org/~pzn/howto/chroot-bind.sh.txt,
http://www.cryptio.net/~ferlatte/config/ (Debian-specific),
http://web.archive.org/web/20021216104548/http://www.psionic.com/papers/whitep01.html
and http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm.


5.8. Apache を安全にする
------------------

FIXME: Add content: modules provided with the normal Apache installation
(under /usr/lib/apache/X.X/mod_*) and modules that can be installed
separately in libapache-mod-XXX packages.

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

Listen を使うなら:

Listen 127.0.0.1:80

BindAddress を使うなら:

BindAddress 127.0.0.1

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

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

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

More information on further restricting Apache by setting up a chroot
jail is provided in 「Chroot environment for Apache」.


5.8.1. Disabling users from publishing web contents

The default Apache installation in Debian permits users to publish
content under the $HOME/public_html. This content can be retrieved
remotely using an URL such as: http://your_apache_server/~user.

If you do not want to permit this you must change the
/etc/apache/http.conf configuration file commenting out (in Apache 1.3)
the following module:

LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so

If you are using Apache 2.0 you must remove the file
/etc/apache2/mods-enabled/userdir.load or restrict the default
configuration by modifying /etc/apache2/mods-enabled/userdir.conf.

However, if the module was linked statically (you can list the modules
that are compiled in running apache -l) you must add the following to the
Apache configuration file:

Userdir disabled

An attacker might still do user enumeration, since the answer of the web
server will be a 403 Permission Denied and not a 404 Not available. You
can avoid this if you use the Rewrite module.


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

Apache logfiles, since 1.3.22-1, are owned by user 'root' and group 'adm'
with permissions 640. These permissions are changed after rotation. An
intruder that accessed the system through the web server would not be
able (without privilege escalation) to remove old log file entries.


5.8.3. Published web files

Apache files are located under /var/www. Just after installation the
default file provides some information on the system (mainly that it's a
Debian system running Apache). The default webpages are owned by user
root and group root by default, while the Apache process runs as user
www-data and group www-data. This should make attackers that compromise
the system through the web server harder to deface the site. You should,
of course, substitute the default web pages (which might provide
information you do not want to show to outsiders) with your own.


5.9. finger を安全にする
------------------

もし finger サービスを動かしたいならまずそうするのが必要かどうか考えて ください。もし必要なら、 Debian は多くの finger
デーモンを提供しているのが わかるでしょう (apt-cache search fingerd の出力です):

  * 

    cfingerd - Configurable finger daemon

  * 

    efingerd - Another finger daemon for unix capable of fine-tuning your
    out put.

  * 

    ffingerd - a secure finger daemon

  * 

    fingerd - Remote user information server.

  * 

    BSD-like finger daemon with qmail support.

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


5.10. 一般的な chroot および suid のパラノイア
---------------------------------

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

Many services running as daemons could benefit from this sort of
arrangement. The daemons that you install with your Debian distribution
will not come, however, chrooted[42] per default.

This includes: name servers (such as bind), web servers (such as apache),
mail servers (such as sendmail) and ftp servers (such as wu-ftpd). It is
probably fair to say that the complexity of BIND is the reason why it has
been exposed to a lot of attacks in recent years (see 「BIND を安全にする」).

However, Debian does provide some software that can help set up chroot
environments. See 「Making chrooted environments automatically」.

Anyway, if you run any service on your system, you should consider
running them as secure as possible. This includes: revoking root
privileges, running in a restricted environment (such as a chroot jail)
or replacing them with a more secure equivalent.

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


5.10.1. Making chrooted environments automatically

There are several programs to chroot automatically servers and services.
Debian currently (accepted in May 2002) provides Wietse Venema's
chrootuid in the chrootuid package, as well as compartment and makejail.
These programs can be used to set up a restricted environment for
executing any program (chrootuid enables you to even run it as a
restricted user).

Some of these tools can be used to set up the chroot environment easily.
The makejail program for example, can create and update a chroot jail
with short configuration files (it provides sample configuration files
for bind, apache, postgresql and mysql). It attempts to guess and install
into the jail all files required by the daemon using strace, stat and
Debian's package dependencies. More information at
http://www.floc.net/makejail/. Jailer is a similar tool which can be
retrieved from http://www.balabit.hu/downloads/jailer/ and is also
available as a Debian package.


5.11. 一般的な平文パスワードのパラノイア
-----------------------

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

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

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


5.12. NIS を無効にする
----------------

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

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

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

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


5.13. Securing RPC services
---------------------------

You should disable RPC if you do not need it.

Remote Procedure Call (RPC) is a protocol that programs can use to
request services from other programs located on different computers. The
portmap service controls RPC services by mapping RPC program numbers into
DARPA protocol port numbers; it must be running in order to make RPC
calls.

RPC-based services have had a bad record of security holes, although the
portmapper itself hasn't (but still provides information to a remote
attacker). Notice that some of the DDoS (distributed denial of service)
attacks use RPC exploits to get into the system and act as a so called
agent/handler.

You only need RPC if you are using an RPC-based service. The most common
RPC-based services are NFS (Network File System) and NIS (Network
Information System). See the previous section for more information about
NIS. The File Alteration Monitor (FAM) provided by the package fam is
also an RPC service, and thus depends on portmap.

NFS services are quite important in some networks. If that is the case
for you, then you will need to find a balance of security and usability
for your network (you can read more about NFS security in the
http://www.tldp.org/HOWTO/NFS-HOWTO.html (/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz)).


5.13.1. RPC サービスを無効にする

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

Notice that some desktop environments (notably, GNOME) use RPC services
and need the portmapper for some of the file management features. If this
is your case, you can limit the access to RPC services as described
below.


5.13.2. Limiting access to RPC services

Unfortunately, in some cases removing RPC services from the system is not
an option. Some local desktop services (notably SGI's fam) are RPC based
and thus need a local portmapper. This means that under some situations,
users installing a desktop environment (like GNOME) will install the
portmapper too.

There are several ways to limit access to the portmapper and to RPC
services:

  * 

    Block access to the ports used by these services with a local
    firewall (see 「ファイアウォール機能を追加する」).

  * 

    Block access to these services using tcp wrappers, since the
    portmapper (and some RPC services) are compiled with libwrap (see
    「tcpwrappers を使う」). This means that you can block access to them
    through the hosts.allow and hosts.deny tcp wrappers configuration.

  * 

    Since version 5-5, the portmap package can be configured to listen
    only on the loopback interface. To do this, modify
    /etc/default/portmap, uncomment the following line: #OPTIONS="-i
    127.0.0.1" and restart the portmapper. This is sufficient to allow
    local RPC services to work while at the same time prevents remote
    systems from accessing them (see, however, 「Disabling weak-end hosts
    issues」).


5.14. ファイアウォール機能を追加する
---------------------

The Debian GNU/Linux operating system has the built-in capabilities
provided by the Linux kernel. If you install a recent Debian release
(default kernel installed is 2.6) you will have iptables (netfilter)
firewalling available[43].


5.14.1. ローカルシステムをファイアウォールで守る

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

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

On the other hand, having firewall rules on the local system also
prevents some bad things from happening. Even if the services provided
are configured securely, a firewall can protect from misconfigurations or
from fresh installed services that have not yet been properly configured.
Also, a tight configuration will prevent trojans calling home from
working unless the firewalling code is removed. Note that an intruder
does not need superuser access to install a trojan locally that could be
remotely controlled (since binding on ports is allowed if they are not
priviledged ports and capabilities have not been removed).

Thus, a proper firewall setup would be one with a default deny policy,
that is:

  * 

    incoming connections are allowed only to local services by allowed
    machines.

  * 

    outgoing connections are only allowed to services used by your system
    (DNS, web browsing, POP, email...).[44]

  * 

    the forward rule denies everything (unless you are protecting other
    systems, see below).

  * 

    all other incoming or outgoing connections are denied.


5.14.2. 他のシステムを守るのにファイアウォールを使う

A Debian firewall can also be installed in order to protect, with
filtering rules, access to systems behind it, limiting their exposure to
the Internet. A firewall can be configured to prevent access from systems
outside of the local network to internal services (ports) that are not
public. For example, on a mail server, only port 25 (where the mail
service is being given) needs to be accessible from the outside. A
firewall can be configured to, even if there are other network services
besides the public ones running in the mail server, throw away packets
(this is known as filtering) directed towards them.

You can even set up a Debian GNU/Linux box as a bridge firewall, i.e. a
filtering firewall completely transparent to the network that lacks an IP
address and thus cannot be attacked directly. Depending on the kernel you
have installed, you might need to install the bridge firewall patch and
then go to 802.1d Ethernet Bridging when configuring the kernel and a new
option netfilter ( firewalling ) support. See the 「Setting up a bridge
firewall 」 for more information on how to set this up in a Debian
GNU/Linux system.


5.14.3. Setting up a firewall

The default Debian installation, unlike other Linux distributions, does
not yet provide a way for the administrator to setup a firewall
configuration throughout the default installation but you can install a
number of firewall configuration packages (see 「ファイアウォールパッケージ」).

Of course, the configuration of the firewall is always system and network
dependant. An administrator must know beforehand what is the network
layout and the systems to protect, the services that need to be accessed,
and whether or not other network considerations (like NAT or routing)
need to be taken into account. Be careful when configuring your firewall,
as Laurence J. Lane says in the iptables package:

The tools can easily be misused, causing enormous amounts of grief by
completely crippling network access to a system. It is not terribly
uncommon for a remote system administrator to accidentally get locked out
of a system hundreds or thousands of miles away. You can even manage to
get locked out of a computer who's keyboard is under your own fingers.
Please, use due caution.

Remember this: just installing the iptables (or the older firewalling
code) does not give you any protection, just provides the software. In
order to have a firewall you need to configure it!

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

If you do not know much about firewalling you should start by reading the
http://www.tldp.org/HOWTO/Firewall-HOWTO.html, install the doc-linux-text
package if you want to read it offline. If you want to ask questions or
need help setting up a firewall you can use the debian-firewall mailing
list, see http://lists.debian.org/debian-firewall. Also see 「前提となる知識」 for
more (general) pointers on firewalls. Another good iptables tutorial is
http://iptables-tutorial.frozentux.net/iptables-tutorial.html.

5.14.3.1. ファイアウォールパッケージ

Setting up manually a firewall can be complicated for novice (and
sometimes even expert) administrators. However, the free software
community has created a number of tools that can be used to easily
configure a local firewall. Be forewarned that some of these tools are
oriented more towards local-only protection (also known as personal
firewall) and some are more versatile and can be used to configure
complex rules to protect whole networks.

Debian システムでファイアウォール規則を設定するのに使える ソフトウェアはいろいろあります:

  * 

    For desktop systems:

      * 

        firestarter, a GNOME application oriented towards end-users that
        includes a wizard useful to quickly setup firewall rules. The
        application includes a GUI to be able to monitor when a firewall
        rule blocks traffic.

      * 

        guarddog, a KDE based firewall configuration package oriented
        both to novice and advanced users.

      * 

        knetfilter, a KDE GUI to manage firewall and NAT rules for
        iptables (alternative/competitor to the guarddog tool although
        slightly oriented towards advanced users).

      * 

        fireflier, an interactive tool to create iptables rules based on
        traffic seen on the system and applications. It has a
        server-client model so you have to install both the server (fireflier-server)
        and one of the available clients, with one client available for
        different desktop environments: fireflier-client-gtk (Gtk+
        client), fireflier-client-kde (KDE client) and
        fireflier-client-qt (QT client).

  * 

    For servers (headless) systems:

      * 

        fwbuilder, an object oriented GUI which includes policy compilers
        for various firewall platforms including Linux' netfilter, BSD's
        pf (used in OpenBSD, NetBSD, FreeBSD and MacOS X) as well as
        router's access-lists. It is similar to enterprise firewall
        management software. Complete fwbuilder's functionality is also
        available from the command line.

      * 

        shorewall, a firewall configuration tool which provides support
        for IPsec as well as limited support for traffic shaping as well
        as the definition of the firewall rules. Configuration is done
        through a simple set of files that are used to generate the
        iptables rules.

      * 

        bastille, this hardening application is described in 6ç« Debian
        システムを自動的に強化する. One of the hardening steps that the administrator
        can configure is a definition of the allowed and disallowed
        network traffic that is used to generate a set of firewall rules
        that the system will execute on startup.

Lots of other iptables frontends come with Debian; an extensive list
comparing the different packages in Debian is maintained at the
http://wiki.debian.org/Firewalls.

Notice that some of the packages outlined previously will introduce
firewalling scripts to be run when the system boots. Test them
extensively before rebooting or you might find yourself locked from the
box. If you mix different firewalling packages you can have undesired
effects, usually, the firewalling script that runs last will be the one
that configures the system (which might not be what you intend). Consult
the package documentation and use either one of these setups.

As mentioned before, some programs, like firestarter, guarddog and
knetfilter, are administration GUIs using either GNOME or KDE (last two).
These applications are much more user-oriented (i.e. for home users) than
some of the other packages in the list which might be more
administrator-oriented. Some of the programs mentioned before (like
bastille) are focused at setting up firewall rules to protect the host
they run in but are not necessarily designed to setup firewall rules for
firewall hosts that protect a network (like shorewall or fwbuilder).

There is yet another type of firewall application: application proxies.
If you are looking into setting up an enterprise-level firewall that does
packet filtering and provides a number of transparent proxies that can do
fine-grain traffic analysis you should consider using zorp, which
provides this in a single program. You can also manually setup this type
of firewall host using the proxies available in Debian for different
services like for DNS using bind (properly configured), dnsmasq, pdnsd or
totd for FTP using frox or ftp-proxy, for X11 using xfwp, for IMAP using
imapproxy, for mail using smtpd, or for POP3 using p3scan. For other
protocols you can either use a generic TCP proxy like simpleproxy or a
generic SOCKS proxy like dante-server, tsocks or socks4-server.
Typically, you will also use a web caching system (like squid) and a web
filtering system (like squidguard or dansguardian).

5.14.3.2. Manual init.d configuration

Another possibility is to manually configure your firewall rules through
an init.d script that will run all the iptables commands. Take the
following steps:

  * 

    Review the script below and adapt it to your needs.

  * 

    Test the script and review the syslog messages to see which traffic
    is being dropped. If you are testing from the network you will want
    to either run the sample shell snippet to remove the firewall (if you
    don't type anything in 20 seconds) or you might want to comment out
    the default deny policy definitions (-P INPUT DROP and -P OUTPUT DROP)
    and check that the system will not drop any legitimate traffic.

  * 

    Move the script to /etc/init.d/myfirewall

  * 

    The below script takes advantage of Debian's use (since Squeeze) of
    dependency based boot sequencing. For more information see:
    https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot and
    https://wiki.debian.org/LSBInitScripts. With the LSB headers set as
    they are in the script, insserv will automatically configure the
    system to start the firewall before any network is brought up, and
    stop the firewall after any network is brought down.

    # insserv myfirewall  

This is the sample firewall script:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          myfirewall
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     S
# Default-Stop:      0 6
# X-Start-Before:    $network
# X-Stop-After:      $network
# Short-Description: My custom firewall.
### END INIT INFO
#
# Simple example firewall configuration.
#
# Caveats:
# - This configuration applies to all network interfaces
#   if you want to restrict this to only a given interface use
#   '-i INTERFACE' in the iptables calls.
# - Remote access for TCP/UDP services is granted to any host, 
#   you probably will want to restrict this using '--source'.
#
# chkconfig: 2345 9 91
# description: Activates/Deactivates the firewall at boot time
#
# You can test this script before applying with the following shell
# snippet, if you do not type anything in 10 seconds the firewall
# rules will be cleared.
#---------------------------------------------------------------
#  while true; do test=""; read  -t 20 -p "OK? " test ; \
#  [ -z "$test" ] && /etc/init.d/myfirewall clear ; done
#---------------------------------------------------------------

PATH=/bin:/sbin:/usr/bin:/usr/sbin

# Services that the system will offer to the network
TCP_SERVICES="22" # SSH only
UDP_SERVICES=""
# Services the system will use from the network
REMOTE_TCP_SERVICES="80" # web browsing
REMOTE_UDP_SERVICES="53" # DNS
# Network that will be used for remote mgmt
# (if undefined, no rules will be setup)
# NETWORK_MGMT=192.168.0.0/24
# If you want to setup a management network (i.e. you've uncommented
# the above line) you will need to define the SSH port as well (i.e.
# uncomment the below line.) Remember to remove the SSH port from the
# TCP_SERVICES string.
# SSH_PORT="22"

if ! [ -x /sbin/iptables ]; then  
    exit 0
fi

fw_start () {

  # Input traffic:
  /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
  # Services
  if [ -n "$TCP_SERVICES" ] ; then
  for PORT in $TCP_SERVICES; do
    /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT
  done
  fi
  if [ -n "$UDP_SERVICES" ] ; then
  for PORT in $UDP_SERVICES; do
    /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT
  done
  fi
  # Remote management
  if [ -n "$NETWORK_MGMT" ] ; then
    /sbin/iptables -A INPUT -p tcp --src ${NETWORK_MGMT} --dport ${SSH_PORT} -j ACCEPT
  fi
  # Remote testing
  /sbin/iptables -A INPUT -p icmp -j ACCEPT
  /sbin/iptables -A INPUT -i lo -j ACCEPT
  /sbin/iptables -P INPUT DROP
  /sbin/iptables -A INPUT -j LOG

  # Output:
  /sbin/iptables -A OUTPUT -j ACCEPT -o lo 
  /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
  # ICMP is permitted:
  /sbin/iptables -A OUTPUT -p icmp -j ACCEPT
  # So are security package updates:
  # Note: You can hardcode the IP address here to prevent DNS spoofing
  # and to setup the rules even if DNS does not work but then you 
  # will not "see" IP changes for this service:
  /sbin/iptables -A OUTPUT -p tcp -d security.debian.org --dport 80 -j ACCEPT 
  # As well as the services we have defined:
  if [ -n "$REMOTE_TCP_SERVICES" ] ; then
  for PORT in $REMOTE_TCP_SERVICES; do
    /sbin/iptables -A OUTPUT -p tcp --dport ${PORT} -j ACCEPT
  done
  fi
  if [ -n "$REMOTE_UDP_SERVICES" ] ; then
  for PORT in $REMOTE_UDP_SERVICES; do
    /sbin/iptables -A OUTPUT -p udp --dport ${PORT} -j ACCEPT
  done
  fi
  # All other connections are registered in syslog
  /sbin/iptables -A OUTPUT -j LOG
  /sbin/iptables -A OUTPUT -j REJECT 
  /sbin/iptables -P OUTPUT DROP
  # Other network protections
  # (some will only work with some kernel versions)
  echo 1 > /proc/sys/net/ipv4/tcp_syncookies
  echo 0 > /proc/sys/net/ipv4/ip_forward 
  echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
  echo 1 > /proc/sys/net/ipv4/conf/all/log_martians 
  echo 1 > /proc/sys/net/ipv4/ip_always_defrag
  echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
  echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
  echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
  echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

}

fw_stop () {
  /sbin/iptables -F
  /sbin/iptables -t nat -F
  /sbin/iptables -t mangle -F
  /sbin/iptables -P INPUT DROP
  /sbin/iptables -P FORWARD DROP
  /sbin/iptables -P OUTPUT ACCEPT
}

fw_clear () {
  /sbin/iptables -F
  /sbin/iptables -t nat -F
  /sbin/iptables -t mangle -F
  /sbin/iptables -P INPUT ACCEPT
  /sbin/iptables -P FORWARD ACCEPT
  /sbin/iptables -P OUTPUT ACCEPT
}


case "$1" in
  start|restart)
    echo -n "Starting firewall.."
    fw_stop 
    fw_start
    echo "done."
    ;;
  stop)
    echo -n "Stopping firewall.."
    fw_stop
    echo "done."
    ;;
  clear)
    echo -n "Clearing firewall rules.."
    fw_clear
    echo "done."
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|clear}"
    exit 1
    ;;
  esac
exit 0

Instead of including all of the iptables rules in the init.d script you
can use the iptables-restore program to restore the rules saved using
iptables-save. In order to do this you need to setup your rules, save the
ruleset under a static location (such as /etc/default/firewall)

5.14.3.3. Configuring firewall rules through ifup

You can use also the network configuration in /etc/network/interfaces to
setup your firewall rules. For this you will need to:

  * 

    Create your firewalling ruleset for when the interface is active.

  * 

    Save your ruleset with iptables-save to a file in /etc, for example
    /etc/iptables.up.rules

  * 

    Configure /etc/network/interfaces to use the configured ruleset:

    iface eth0 inet static
            address x.x.x.x
            [.. interface configuration ..]
            pre-up iptables-restore < /etc/iptables.up.rules  

You can optionally also setup a set of rules to be applied when the
network interface is down creating a set of rules, saving it in
/etc/iptables.down.rules and adding this directive to the interface
configuration:

    post-down iptables-restore < /etc/iptables.down.rules

For more advanced firewall configuration scripts through ifupdown you can
use the hooks available to each interface as in the *.d/ directories
called with run-parts (see run-parts(8) manual page).

5.14.3.4. Testing your firewall configuration

Testing your firewall configuration is as easy, and as dangerous, as just
running your firewall script (or enabling the configuration you defined
in your firewall configuration application). However, if you are not
careful enough and you are configuring your firewall remotely (like
through an SSH connection) you could lock yourself out.

There are several ways to prevent this. One is running a script in a
separate terminal that will remove the firewall configuration if you
don't feed it input. An example of this is:

$  while true; do test=""; read  -t 20 -p "OK? " test ; \
  [ -z "$test" ] && /etc/init.d/firewall clear ; done

Another one is to introduce a backdoor in your system through an
alternate mechanism that allows you to either clear the firewall system
or punch a hole in it if something goes awry. For this you can use knockd
and configure it so that a certain port connection attempt sequence will
clear the firewall (or add a temporary rule). Even though the packets
will be dropped by the firewall, since knockd binds to the interface and
sees you will be able to work around the problem.

Testing a firewall that is protecting an internal network is a different
issue, you will want to look at some of the tools used for remote
vulnerability assessment (see 「リモートの脆弱性を評価する道具」) to probe the network
from the outside in (or from any other direction) to test the
effectiveness of the firewall configuation.


------------------------------------------------------------------------

[36] Gdm will not append -nolisten tcp if it finds a -query or -indirect
on the command line since the query wouldn't work.

[37] To retrieve the list of mailer daemons available in Debian try:

$ apt-cache search mail-transport-agent

The list will not include qmail, which is distributed only as source code
in the qmail-src package.

[38] A list of servers/daemons which support these protocols in Debian
can be retrieved with:

$ apt-cache search pop3-server
$ apt-cache search imap-server

[39] Note that depending on your bind version you might not have the -g
option, most notably if you are using bind9 in sarge (9.2.4 version).

[40] This setup has not been tested for new release of Bind yet.

[41] Unless you use the instdir option when calling dpkg but then the
chroot jail might be a little more complex.

[42] It does try to run them under minimum priviledge which includes
running daemons with their own users instead of having them run as root.

[43] Available since the kernel version 2.4 (which was the default kernel
in Debian 3.0). Previous kernel versions (2.2, available in even older
Debian releases) used ipchains. The main difference between ipchains and
iptables is that the latter is based on stateful packet inspection which
provides for more secure (and easier to build) filtering configurations.
Older (and now unsupported) Debian distributions using the 2.0 kernel
series needed the appropriate kernel patch.

[44] Unlike personal firewalls in other operating systems, Debian
GNU/Linux does not (yet) provide firewall generation interfaces that can
make rules limiting them per process or user. However, the iptables code
can be configured to do this (see the owner module in the iptables(8)
manual page).



第6章 Debian システムを自動的に強化する
========================

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

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


6.1. Harden
-----------

The harden package tries to make it more easy to install and administer
hosts that need good security. This package should be used by people that
want some quick help to enhance the security of the system. It
automatically installs some tools that should enhance security in some
way: intrusion detection tools, security analysis tools, etc. Harden
installs the following virtual packages (i.e. no contents, just
dependencies or recommendations on others):

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

    harden-nids: helps to install a network intrusion detection system.

  * 

    harden-surveillance: helps to install tools for monitoring of
    networks and services.

Useful packages which are not a dependence:

  * 

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

  * 

    harden-development: development tools for creating more secure
    programs.

必要なソフトウェアがあって (そして何らかの理由でアンインストールしたくは なくて)、それが上記のパッケージのどれかと対立していたら、
harden を完全に利用することはできないので注意してください。 harden パッケージは (直接には) 何もしません。しかし harden
パッケージは 既知の安全でないパッケージと意図的に対立します。このようにすると、Debian の
パッケージシステムはこれらのパッケージをインストールすることを承認しなく なります。たとえば、telnet デーモンを
harden-servers と ともにインストールしようとすると、apt はこう言うでしょう:

# 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]

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


6.2. Bastille Linux
-------------------

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

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

  * 

    Answer questions step by step regarding the desired security of your
    system (using InteractuveBastille(8)

  * 

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

  * 

    Take a predefined configuration file (could be provided by Bastille
    or made by the administrator) and implement a given security policy
    (using AutomatedBastille(8)).



第7章 Debian Security Infrastructure
==================================


7.1. The Debian Security Team
-----------------------------

Debian has a Security Team, that handles security in the stable
distribution. Handling security means they keep track of vulnerabilities
that arise in software (watching forums such as Bugtraq, or vuln-dev) and
determine if the stable distribution is affected by it.

Also, the Debian Security Team is the contact point for problems that are
coordinated by upstream developers or organizations such as
http://www.cert.org which might affect multiple vendors. That is, when
problems are not Debian-specific. The contact point of the Security Team
is mailto:team@security.debian.org which only the members of the security
team read.

Sensitive information should be sent to the first address and, in some
cases, should be encrypted with the Debian Security Contact key (as found
in the Debian keyring).

Once a probable problem is received by the Security Team it will
investigate if the stable distribution is affected and if it is, a fix is
made for the source code base. This fix will sometimes include
backporting the patch made upstream (which usually is some versions ahead
of the one distributed by Debian). After testing of the fix is done, new
packages are prepared and published in the http://security.debian.org
site so they can be retrieved through apt (see 「セキュリティ上の更新を実行する」). At the
same time a Debian Security Advisory (DSA) is published on the web site
and sent to public mailing lists including
http://lists.debian.org/debian-security-announce and Bugtraq.

Some other frequently asked questions on the Debian Security Team can be
found at 「Debian security team に関する質問」.


7.2. Debian Security Advisories
-------------------------------

Debian Security Advisories (DSAs) are made whenever a security
vulnerability is discovered that affects a Debian package. These
advisories, signed by one of the Security Team members, include
information of the versions affected as well as the location of the
updates. This information is:

  * 

    version number for the fix.

  * 

    problem type.

  * 

    whether it is remote or locally exploitable.

  * 

    short description of the package.

  * 

    description of the problem.

  * 

    description of the exploit.

  * 

    description of the fix.

DSAs are published both on http://www.debian.org/ and in the
http://www.debian.org/security/. Usually this does not happen until the
website is rebuilt (every four hours) so they might not be present
immediately. The preferred channel is the debian-security-announce
mailing list.

Interested users can, however (and this is done in some Debian-related
portals) use the RDF channel to download automatically the DSAs to their
desktop. Some applications, such as Evolution (an email client and
personal information assistant) and Multiticker (a GNOME applet), can be
used to retrieve the advisories automatically. The RDF channel is
available at http://www.debian.org/security/dsa.rdf.

DSAs published on the website might be updated after being sent to the
public-mailing lists. A common update is adding cross references to
security vulnerability databases. Also, translations[45] of DSAs are not
sent to the security mailing lists but are directly included in the
website.


7.2.1. Vulnerability cross references

Debian provides a fully http://www.debian.org/security/crossreferences
including all the references available for all the advisories published
since 1998. This table is provided to complement the
http://cve.mitre.org/cve/refs/refmap/source-DEBIAN.html.

You will notice that this table provides references to security databases
such as http://www.securityfocus.com/bid, http://www.cert.org/advisories/
and http://www.kb.cert.org/vuls as well as CVE names (see below). These
references are provided for convenience use, but only CVE references are
periodically reviewed and included.

Advantages of adding cross references to these vulnerability databases
are:

  * 

    it makes it easier for Debian users to see and track which general
    (published) advisories have already been covered by Debian.

  * 

    system administrators can learn more about the vulnerability and its
    impact by following the cross references.

  * 

    this information can be used to cross-check output from vulnerability
    scanners that include references to CVE to remove false positives
    (see 「Vulnerability assessment scanner X says my Debian system is
    vulnerable!」).


7.2.2. CVE compatibility

Debian Security Advisories were
http://www.debian.org/security/CVE-certificate.jpg[46] in February 24,
2004.

Debian developers understand the need to provide accurate and up to date
information of the security status of the Debian distribution, allowing
users to manage the risk associated with new security vulnerabilities.
CVE enables us to provide standardized references that allow users to
develop a https://cve.mitre.org/compatible/enterprise.html.

The http://cve.mitre.org project is maintained by the MITRE Corporation
and provides a list of standardized names for vulnerabilities and
security exposures.

Debian believes that providing users with additional information related
to security issues that affect the Debian distribution is extremely
important. The inclusion of CVE names in advisories help users associate
generic vulnerabilities with specific Debian updates, which reduces the
time spent handling vulnerabilities that affect our users. Also, it eases
the management of security in an environment where CVE-enabled security
tools -such as network or host intrusion detection systems, or
vulnerability assessment tools- are already deployed regardless of
whether or not they are based on the Debian distribution.

Debian provides CVE names for all DSAs released since September 1998. All
of the advisories can be retrieved on the Debian web site, and
announcements related to new vulnerabilities include CVE names if
available at the time of their release. Advisories associated with a
given CVE name can be searched directly through the Debian Security
Tracker (see below).

In some cases you might not find a given CVE name in published
advisories, for example because:

  * 

    No Debian products are affected by that vulnerability.

  * 

    There is not yet an advisory covering that vulnerability (the
    security issue might have been reported as a
    http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security but a fix
    has not been tested and uploaded).

  * 

    An advisory was published before a CVE name was assigned to a given
    vulnerability (look for an update at the web site).


7.3. Security Tracker
---------------------

The central database of what the Debian security teams know about
vulnerabilities is the http://security-tracker.debian.org. It cross
references packages, vulnerable and fixed versions for different suites,
CVE names, Debian bug numbers, DSA's and miscellaneous notes. It can be
searched, e.g. by CVE name to see which Debian packages are affected or
fixed, or by package to show unresolved security issues. The only
information missing from the tracker is confidential information that the
security team received under embargo.

The package debsecan uses the information in the tracker to report to the
administrator of a system which of the installed packages are vulnerable,
and for which updates are available to fix security issues.


7.4. Debian Security Build Infrastructure
-----------------------------------------

Since Debian is currently supported in a large number of architectures,
administrators sometimes wonder if a given architecture might take more
time to receive security updates than another. As a matter of fact,
except for rare circumstances, updates are available to all architectures
at the same time.

Packages in the security archive are autobuilt, just like the regular
archive. However, security updates are a little more different than
normal uploads sent by package maintainers since, in some cases, before
being published they need to wait until they can be tested further, an
advisory written, or need to wait for a week or more to avoid publicizing
the flaw until all vendors have had a reasonable chance to fix it.

Thus, the security upload archive works with the following procedure:

  * 

    Someone finds a security problem.

  * 

    Someone fixes the problem, and makes an upload to
    security-master.debian.org's incoming (this someone is usually a
    Security Team member but can be also a package maintainer with an
    appropriate fix that has contacted the Security Team previously). The
    Changelog includes a testing-security or stable-security as target
    distribution.

  * 

    The upload gets checked and processed by a Debian system and moved
    into queue/accepted, and the buildds are notified. Files in here can
    be accessed by the security team and (somewhat indirectly) by the
    buildds.

  * 

    Security-enabled buildds pick up the source package (prioritized over
    normal builds), build it, and send the logs to the security team.

  * 

    The security team reply to the logs, and the newly built packages are
    uploaded to queue/unchecked, where they're processed by a Debian
    system, and moved into queue/accepted.

  * 

    When the security team find the source package acceptable (i.e., that
    it's been correctly built for all applicable architectures and that
    it fixes the security hole and doesn't introduce new problems of its
    own) they run a script which:

      * 

        installs the package into the security archive.

      * 

        updates the Packages, Sources and Release files of
        security.debian.org in the usual way (dpkg-scanpackages,
        dpkg-scansources, ...).

      * 

        sets up a template advisory that the security team can finish
        off.

      * 

        forwards the packages to the appropriate proposed-updates so that
        it can be included in the real archive as soon as possible.

This procedure, previously done by hand, was tested and put through
during the freezing stage of Debian 3.0 woody (July 2002). Thanks to this
infrastructure the Security Team was able to have updated packages ready
for the apache and OpenSSH issues for all the supported (almost twenty)
architectures in less than a day.


7.4.1. Developer's guide to security updates

Debian developers that need to coordinate with the security team on
fixing in issue in their packages, can refer to the Developer's Reference
section
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security.


7.5. Debian におけるパッケージへの署名
-------------------------

This section could also be titled "how to upgrade/update safely your
Debian GNU/Linux system" and it deserves its own section basically
because it is an important part of the Security Infrastructure. Package
signing is an important issue since it avoids tampering of packages
distributed in mirrors and of downloads with man-in-the-middle attacks.
Automatic software update is an important feature but it's also important
to remove security threats that could help the distribution of trojans
and the compromise of systems during updates [47]

FIXME: probably the Internet Explorer vulnerability handling. certificate
chains has an impact on security updates on Microsoft Windows.

Debian does not provide signed packages but provides a mechanism
available since Debian 4.0 (codename etch) to check for downloaded
package's integrity[48]. For more information, see 「Secure apt」.

This issue is better described in the
http://www.cryptnet.net/fdp/crypto/strong_distro.html by V. Alex Brennen.


7.5.1. パッケージの署名チェックについての提案中のしくみ

The current scheme for package signature checking using apt is:

  * 

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

  * 

    This signed Release file is downloaded by 'apt-get update' and stored
    along with Packages.gz.

  * 

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

  * 

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

  * 

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

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

This scheme is http://lists.debian.org/debian-devel/2003/12/msg01986.html
in apt 0.6 and is available since the Debian 4.0 release. For more
information see 「Secure apt」. Packages that provide a front-end to apt
need to be modified to adapt to this new feature; this is the case of
aptitude which was
http://lists.debian.org/debian-devel/2005/03/msg02641.html to adapt to
this scheme. Front-ends currently known to work properly with this
feature include aptitude and synaptic.

パッケージへの署名は Debian で長い間議論されてきました。くわしくは以下を ごらんください:
http://www.debian.org/News/weekly/2001/8/ と
http://www.debian.org/News/weekly/2000/11/ です。


7.5.2. Secure apt

The apt 0.6 release, available since Debian 4.0 etch and later releases,
includes apt-secure (also known as secure apt) which is a tool that will
allow a system administrator to test the integrity of the packages
downloaded through the above scheme. This release includes the tool
apt-key for adding new keys to apt's keyring, which by default includes
only the current Debian archive signing key.

These changes are based on the patch for apt (available in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203741) which provides
this implementation.

Secure apt works by checking the distribution through the Release file,
as discussed in 「Per distribution release check」. Typically, this process
will be transparent to the administrator although you will need to
intervene every year[49] to add the new archive key when it is rotated,
for more information on the steps an administrator needs to take a look
at 「Safely adding a key」.

This feature is still under development, if you believe you find bugs in
it, please, make first sure you are using the latest version (as this
package might change quite a bit before it is finally released) and, if
running the latest version, submit a bug against the apt package.

You can find more information at http://wiki.debian.org/SecureApt and the
official documentation: http://www.enyo.de/fw/software/apt-secure/ and
https://web.archive.org/web/20070206063141/http://www.syntaxpolice.org/apt-secure/.


7.5.3. Per distribution release check

This section describes how the distribution release check mechanism
works, it was written by Joey Hess and is also available at the
http://wiki.debian.org/SecureApt.

7.5.3.1. Basic concepts

Here are a few basic concepts that you'll need to understand for the rest
of this section.

A checksum is a method of taking a file and boiling it down to a
reasonably short number that uniquely identifies the content of the file.
This is a lot harder to do well than it might seem, and the most commonly
used type of checksum, the MD5 sum, is in the process of being broken.

Public key cryptography is based on pairs of keys, a public key and a
private key. The public key is given out to the world; the private key
must be kept a secret. Anyone possessing the public key can encrypt a
message so that it can only be read by someone possessing the private
key. It's also possible to use a private key to sign a file, not encrypt
it. If a private key is used to sign a file, then anyone who has the
public key can check that the file was signed by that key. No one who
doesn't have the private key can forge such a signature.

These keys are quite long numbers (1024 to 2048 digits or longer), and to
make them easier to work with they have a key id, which is a shorter, 8
or 16 digit number that can be used to refer to them.

gpg is the tool used in secure apt to sign files and check their
signatures.

apt-key is a program that is used to manage a keyring of gpg keys for
secure apt. The keyring is kept in the file /etc/apt/trusted.gpg (not to
be confused with the related but not very interesting
/etc/apt/trustdb.gpg). apt-key can be used to show the keys in the
keyring, and to add or remove a key.

7.5.3.2. Release checksums

A Debian archive contains a Release file, which is updated each time any
of the packages in the archive change. Among other things, the Release
file contains some MD5 sums of other files in the archive. An excerpt of
an example Release file:

MD5Sum:
 6b05b392f792ba5a436d590c129de21f            3453 Packages
 1356479a23edda7a69f24eb8d6f4a14b            1131 Packages.gz
 2a5167881adc9ad1a8864f281b1eb959            1715 Sources
 88de3533bf6e054d1799f8e49b6aed8b             658 Sources.gz

The Release files also include SHA-1 checksums, which will be useful once
MD5 sums become fully broken, however apt doesn't use them yet.

Now if we look inside a Packages file, we'll find more MD5 sums, one for
each package listed in it. For example:

    Package: uqm
    Priority: optional
    ...
    Filename: unstable/uqm_0.4.0-1_i386.deb
    Size: 580558
    MD5sum: 864ec6157c1eea88acfef44d0f34d219

These two checksums can be used to verify that you have downloaded a
correct copy of the Packages file, with a md5sum that matches the one in
the Release file. And when it downloads an individual package, it can
also check its md5sum against the content of the Packages file. If apt
fails at either of these steps, it will abort.

None of this is new in secure apt, but it does provide the foundation.
Notice that so far there is one file that apt doesn't have a way to
check: The Release file. Secure apt is all about making apt verify the
Release file before it does anything else with it, and plugging this
hole, so that there is a chain of verification from the package that you
are going to install all the way back to the provider of the package.

7.5.3.3. Verification of the Release file

To verify the Release file, a gpg signature is added for the Release
file. This is put in a file named Release.gpg that is shipped alongside
the Release file. It looks something like this [50] , although only gpg
actually looks at its contents normally:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCqKO1nukh8wJbxY8RAsfHAJ9hu8oGNRAl2MSmP5+z2RZb6FJ8kACfWvEx
UBGPVc7jbHHsg78EhMBlV/U=
=x6og
-----END PGP SIGNATURE-----

7.5.3.4. Check of Release.gpg by apt

Secure apt always downloads Release.gpg files when it's downloading
Release files, and if it cannot download the Release.gpg, or if the
signature is bad, it will complain, and will make note that the Packages
files that the Release file points to, and all the packages listed
therein, are from an untrusted source. Here's how it looks during an
apt-get update:

W: GPG error: http://ftp.us.debian.org testing Release: The following signatures
 couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F

Note that the second half of the long number is the key id of the key
that apt doesn't know about, in this case that's 2D230C5F.

If you ignore that warning and try to install a package later, apt will
warn again:

WARNING: The following packages cannot be authenticated!
  libglib-perl libgtk2-perl
Install these packages without verification [y/N]?

If you say Y here you have no way to know if the file you're getting is
the package you're supposed to install, or if it's something else
entirely that somebody that can intercept the communication against the
server[51] has arranged for you, containing a nasty suprise.

Note that you can disable these checks by running apt with
--allow-unauthenticated.

It's also worth noting that newer versions of the Debian installer use
the same signed Release file mechanism during their debootstrap of the
Debian base system, before apt is available, and that the installer even
uses this system to verify pieces of itself that it downloads from the
net. Also, Debian does not currently sign the Release files on its CDs;
apt can be configured to always trust packages from CDs so this is not a
large problem.

7.5.3.5. How to tell apt what to trust

So the security of the whole system depends on there being a Release.gpg
file, which signs a Release file, and of apt checking that signature
using gpg. To check the signature, it has to know the public key of the
person who signed the file. These keys are kept in apt's own keyring (/etc/apt/trusted.gpg),
and managing the keys is where secure apt comes in.

By default, Debian systems come preconfigured with the Debian archive key
in the keyring.

# apt-key list
/etc/apt/trusted.gpg
--------------------
pub   1024D/4F368D5D 2005-01-31 [expires: 2006-01-31]
uid                  Debian Archive Automatic Signing Key (2005) <ftpmaster@debian.org>

Here 4F368D5D is the key id, and notice that this key was only valid for
a one year period. Debian rotates these keys as a last line of defense
against some sort of security breach breaking a key.

That will make apt trust the official Debian archive, but if you add some
other apt repository to /etc/apt/sources.list, you'll also have to give
apt its key if you want apt to trust it. Once you have the key and have
verified it, it's a simple matter of running apt-key add file to add it.
Getting the key and verifying it are the trickier parts.

7.5.3.6. Finding the key for a repository

The debian-archive-keyring package is used to distribute keys to apt.
Upgrades to this package can add (or remove) gpg keys for the main Debian
archive.

For other archives, there is not yet a standard location where you can
find the key for a given apt repository. There's a rough standard of
putting the key up on the web page for the repository or as a file in the
repository itself, but no real standard, so you might have to hunt for
it.

The Debian archive signing key is available at
https://ftp-master.debian.org/keys.html.[52]

gpg itself has a standard way to distribute keys, using a keyserver that
gpg can download a key from and add it to its keyring. For example:

$ gpg --keyserver pgpkeys.mit.edu --recv-key 2D230C5F
gpg: requesting key 2D230C5F from hkp server pgpkeys.mit.edu
gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006) <ftpm
aster@debian.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

You can then export that key from your own keyring and feed it to apt-key:

$ gpg -a --export 2D230C5F | sudo apt-key add -
gpg: no ultimately trusted keys found
OK

The "gpg: no ultimately trusted keys found" warning means that gpg was
not configured to ultimately trust a specific key. Trust settings are
part of OpenPGPs Web-of-Trust which does not apply here. So there is no
problem with this warning. In typical setups the user's own key is
ultimately trusted.

7.5.3.7. Safely adding a key

By adding a key to apt's keyring, you're telling apt to trust everything
signed by the key, and this lets you know for sure that apt won't install
anything not signed by the person who possesses the private key. But if
you're sufficiently paranoid, you can see that this just pushes things up
a level, now instead of having to worry if a package, or a Release file
is valid, you can worry about whether you've actually gotten the right
key. Is the key file from https://ftp-master.debian.org/keys.html
mentioned above really Debian's archive signing key, or has it been
modified (or this document lies).

It's good to be paranoid in security, but verifying things from here is
harder. gpg has the concept of a chain of trust, which can start at
someone you're sure of, who signs someone's key, who signs some other
key, etc., until you get to the archive key. If you're sufficiently
paranoid you'll want to check that your archive key is signed by a key
that you can trust, with a trust chain that goes back to someone you know
personally. If you want to do this, visit a Debian conference or perhaps
a local LUG for a key signing [53].

If you can't afford this level of paranoia, do whatever feels appropriate
to you when adding a new apt source and a new key. Maybe you'll want to
mail the person providing the key and verify it, or maybe you're willing
to take your chances with downloading it and assuming you got the real
thing. The important thing is that by reducing the problem to what
archive keys to trust, secure apt lets you be as careful and secure as it
suits you to be.

7.5.3.8. Verifying key integrity

You can verify the fingerprint as well as the signatures on the key.
Retrieving the fingerprint can be done for multiple sources, you can talk
to Debian Developers on IRC, read the mailing list where the key change
will be announced or any other additional means to verify the
fingerprint. For example you can do this:

$ GET http://ftp-master.debian.org/ziyi_key_2006.asc | gpg --import
gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006)
  <ftpmaster&debian.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
$ gpg --check-sigs --fingerprint 2D230C5F
pub   1024D/2D230C5F 2006-01-03 [expires: 2007-02-07]
      Key fingerprint = 0847 50FC 01A6 D388 A643  D869 0109 0831 2D23 0C5F
uid   Debian Archive Automatic Signing Key (2006) <ftpmaster@debian.org>
sig!3        2D230C5F 2006-01-03  Debian Archive Automatic Signing Key
                                  (2006) <ftpmaster@debian.org>
sig!         2A4E3EAA 2006-01-03  Anthony Towns <aj@azure.humbug.org.au>
sig!         4F368D5D 2006-01-03  Debian Archive Automatic Signing Key
                                  (2005) <ftpmaster@debian.org>
sig!         29982E5A 2006-01-04  Steve Langasek <vorlon@dodds.net>
sig!         FD6645AB 2006-01-04  Ryan Murray <rmurray@cyberhqz.com>
sig!         AB2A91F5 2006-01-04  James Troup <james@nocrew.org>

and then as in 「Debian におけるパッケージへの署名」 check the trust path from your key
(or a key you trust) to at least one of the keys used to sign the archive
key. If you are sufficiently paranoid you will tell apt to trust the key
only if you find an acceptable path:

$ gpg --export -a 2D230C5F | sudo apt-key add -
Ok

Note that the key is signed with the previous archive key, so
theoretically you can just build on your previous trust.

7.5.3.9. Debian archive key yearly rotation

As mentioned above, the Debian archive signing key is changed each year,
in January. Since secure apt is young, we don't have a great deal of
experience with changing the key and there are still rough spots.

In January 2006, a new key for 2006 was made and the Release file began
to be signed by it, but to try to avoid breaking systems that had the old
2005 key, the Release file was signed by that as well. The intent was
that apt would accept one signature or the other depending on the key it
had, but apt turned out to be buggy and refused to trust the file unless
it had both keys and was able to check both signatures. This was fixed in
apt version 0.6.43.1. There was also confusion about how the key was
distributed to users who already had systems using secure apt; initially
it was uploaded to the web site with no announcement and no real way to
verify it and users were forced to download it by hand.

In January 2006, a new key for 2006 was made and the Release file began
to be signed by it, but to try to avoid breaking systems that had the old
2005 key, the Release file was signed by that as well. In order to
prevent confusion on the best distribution mechanism for users who
already have systems using secure apt, the debian-archive-keyring package
was introduced, which manages apt keyring updates.

7.5.3.10. Known release checking problems

One not so obvious problem is that if your clock is very far off, secure
apt will not work. If it's set to a date in the past, such as 1999, apt
will fail with an unhelpful message such as this:

W: GPG error: http://archive.progeny.com sid Release: Unknown error executing gpg

Although apt-key list will make the problem plain:

gpg: key 2D230C5F was created 192324901 seconds in the future (time warp or clock problem)
gpg: key 2D230C5F was created 192324901 seconds in the future (time warp or clock problem)
pub   1024D/2D230C5F 2006-01-03
uid                  Debian Archive Automatic Signing Key (2006) <ftpmaster@debian.org>

If it's set to a date too far in the future, apt will treat the keys as
expired.

Another problem you may encouter if using testing or unstable is that if
you have not run apt-get update lately and apt-get install a package, apt
might complain that it cannot be authenticated (why does it do this?).
apt-get update will fix this.

7.5.3.11. Manual per distribution release check

In case you want to add now the additional security checks and don't want
or cannot run the latest apt version[54] you can use the script below,
provided by Anthony Towns. This script can automatically do some new
security checks to allow the user to be sure that the software s/he's
downloading matches the software Debian's distributing. This stops Debian
developers from hacking into someone's system without the accountability
provided by uploading to the main archive, or mirrors mirroring something
almost, but not quite like Debian, or mirrors providing out of date
copies of unstable with known security problems.

このサンプルコードは名前を apt-release-check に変更されています。 以下のように使うべきです:

# apt-get update
# apt-check-sigs
(...results...)
# apt-get dist-upgrade

まず必要なのは:

  * 

    get the keys the archive software uses to sign Release files from
    https://ftp-master.debian.org/keys.html and add them to
    ~/.gnupg/trustedkeys.gpg (which is what gpgv uses by default).

      gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2006.asc  

  * 

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

  * 

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

  * 

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

This is the example code for apt-check-sigs, the latest version can be
retrieved from http://people.debian.org/~ajt/apt-check-sigs. This code is
currently in beta, for more information read
http://lists.debian.org/debian-devel/2002/07/msg00421.html.

#!/bin/bash

# Copyright (c) 2001 Anthony Towns <ajt@debian.org>
#
# 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 | cut -d\  -f1` `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
        lynx -reload -dump "${url}/dists/${dist}/Release" >/dev/null 2>&1
        wget -q -O Release "${url}/dists/${dist}/Release"

        if ! grep -q '^' Release; then
                echo "  * NO TOP-LEVEL Release FILE"
                >Release
        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

                lynx -reload -dump "${url}/dists/${dist}/Release.gpg" >/dev/null 2>&1
                wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg"

                gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] //p" | (okay=0; err=""; while read gpgcode rest; do
                        if [ "$gpgcode" = "GOODSIG" ]; then
                            if [ "$err" != "" ]; then
                                echo "  * Signed by ${err# } key: ${rest#* }"
                            else
                                echo "  o Signed by: ${rest#* }"
                                okay=1
                            fi
                            err=""
                        elif [ "$gpgcode" = "BADSIG" ]; then
                            echo "  * BAD SIGNATURE BY: ${rest#* }"
                            err=""
                        elif [ "$gpgcode" = "ERRSIG" ]; then
                            echo "  * COULDN'T CHECK SIGNATURE BY KEYID: ${rest %% *}"
                            err=""
                        elif [ "$gpgcode" = "SIGREVOKED" ]; then
                            err="$err REVOKED"
                        elif [ "$gpgcode" = "SIGEXPIRED" ]; then
                            err="$err EXPIRED"
                        fi
                    done
                    if [ "$okay" != 1 ]; then
                        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 . -type 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

You might need to apply the following patch for sid since md5sum adds an
'-' after the sum when the input is stdin:

@@ -37,7 +37,7 @@
        local LOOKUP="$2"

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

        if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
                if [ "$Y" = "" ]; then
@@ -55,7 +55,7 @@
                return
        fi
        X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`"
-       X="`echo "$X" | sed 's/^ *//;s/  */ /g'`"
+       X="`echo "$X" | sed 's/-//;s/^ *//;s/  */ /g'`"
        if [ "$X" != "$Y" ]; then
                echo "$FILE" >>BAD
                echo "BAD"


7.5.4. Release check of non Debian sources

Notice that, when using the latest apt version (with secure apt) no extra
effort should be required on your part unless you use non-Debian sources,
in which case an extra confirmation step will be required by apt-get.
This is avoided by providing Release and Release.gpg files in the
non-Debian sources. The Release file can be generated with apt-ftparchive
(available in apt-utils 0.5.0 and later), the Release.gpg is just a
detached signature. To generate both follow this simple procedure:

$ rm -f dists/unstable/Release
$ apt-ftparchive release dists/unstable > dists/unstable/Release
$ gpg --sign -ba -o dists/unstable/Release.gpg dists/unstable/Release


7.5.5. ほかのパッケージごとの署名のしくみ

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

This package signing scheme can be implemented using debsig-verify and
debsigs. These two packages can sign and verify embedded signatures in
the .deb itself. Debian already has the capability to do this now, but
there is no feature plan to implement the policy or other tools since the
archive signing scheme is prefered. These tools are available for users
and archive administrators that would rather use this scheme instead.

Latest dpkg versions (since 1.9.21) incorporate a
http://lists.debian.org/debian-dpkg/2001/03/msg00024.html that provides
this functionality as soon as debsig-verify is installed.

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

NOTE2: Signatures from developers are currently stripped when they enter
off the package archive since the currently preferred method is release
checks as described previously.


------------------------------------------------------------------------

[45] Translations are available in up to ten different languages.

[46] The full http://cve.mitre.org/compatible/phase2/SPI_Debian.html is
available at CVE

[47] Some operating systems have already been plagued with
automatic-updates problems such as the
http://www.cunap.com/~hardingr/projects/osx/exploit.html.

[48] Older releases, such as Debian 3.1 sarge can use this feature by
using backported versions of this package management tool

[49] Until an automatic mechanism is developed.

[50] Technically speaking, this is an ASCII-armored detached gpg
signature.

[51] Or has poisoned your DNS, or is spoofing the server, or has replaced
the file in the mirror you are using, etc.

[52] "ziyi" is the name of the tool used for signing on the Debian
servers, the name is based on the name of a
http://en.wikipedia.org/wiki/Zhang_Ziyi.

[53] Not all apt repository keys are signed at all by another key. Maybe
the person setting up the repository doesn't have another key, or maybe
they don't feel comfortable signing such a role key with their main key.
For information on setting up a key for a repository see 「Release check
of non Debian sources」.

[54] Either because you are using the stable, sarge, release or an older
release or because you don't want to use the latest apt version, although
we would really appreciate testing of it.



第8章 Debian でのセキュリティ関連の道具
========================

FIXME: 内容がもっと必要。

Debian provides also a number of security tools that can make a Debian
box suited for security purposes. These purposes include protection of
information systems through firewalls (either packet or
application-level), intrusion detection (both network and host based),
vulnerability assessment, antivirus, private networks, etc.

Since Debian 3.0 (woody), the distribution features cryptographic
software integrated into the main distribution. OpenSSH and GNU Privacy
Guard are included in the default install, and strong encryption is now
present in web browsers and web servers, databases, and so forth. Further
integration of cryptography is planned for future releases. This
software, due to export restrictions in the US, was not distributed along
with the main distribution but included only in non-US sites.


8.1. リモートの脆弱性を評価する道具
--------------------

The tools provided by Debian to perform remote vulnerability assessment
are: [55]

  * 

    nessus

  * 

    raccess

  * 

    nikto (whisker's replacement)

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

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


8.2. ネットワークをスキャンする道具
--------------------

Debian はホストのリモートスキャンに使う (でも脆弱性の調査用ではない) 道具を
いくつか提供しています。場合によっては、利用できるリモートサービスを 知るてめにリモートのホストに対して行う最初の「攻撃」としてこれらの道具が
脆弱性を調査するスキャナによって使われます。現在 Debian が提供しているのは:

  * 

    nmap

  * 

    xprobe

  * 

    p0f

  * 

    knocker

  * 

    isic

  * 

    hping2

  * 

    icmpush

  * 

    nbtscan (for SMB /NetBIOS audits)

  * 

    fragrouter

  * 

    strobe (in the netdiag package)

  * 

    irpas

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

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

On the other hand, fragrouter can be used to test network intrusion
detection systems and see if the NIDS can be eluded by fragmentation
attacks.

FIXME: Check http://bugs.debian.org/153117 (ITP fragrouter) to see if
it's included.

FIXME add information based on
https://web.archive.org/web/20040725013857/http://www.giac.org/practical/gcux/Stephanie_Thomas_GCUX.pdf
which describes how to use Debian and a laptop to scan for wireless
(803.1) networks (link not there any more).


8.3. 内部監査
---------

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


8.4. ソースコードを監査する
----------------

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

  * 

    flawfinder

  * 

    rats

  * 

    splint

  * 

    pscan


8.5. バーチャルプライベートネットワーク
----------------------

A virtual private network (VPN) is a group of two or more computer
systems, typically connected to a private network with limited public
network access, that communicate securely over a public network. VPNs may
connect a single computer to a private network (client-server), or a
remote LAN to a private network (server-server). VPNs often include the
use of encryption, strong authentication of remote users or hosts, and
methods for hiding the private network's topology.

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

  * 

    vtun

  * 

    tunnelv (non-US section)

  * 

    cipe-source, cipe-common

  * 

    tinc

  * 

    secvpn

  * 

    pptpd

  * 

    openvpn

  * 

    openswan (http://www.openswan.org/)

FIXME: Update the information here since it was written with FreeSWAN in
mind. Check Bug #237764 and Message-Id:
<200412101215.04040.rmayr@debian.org>.

The OpenSWAN package is probably the best choice overall, since it
promises to interoperate with almost anything that uses the IP security
protocol, IPsec (RFC 2411). However, the other packages listed above can
also help you get a secure tunnel up in a hurry. The point to point
tunneling protocol (PPTP) is a proprietary Microsoft protocol for VPN. It
is supported under Linux, but is known to have serious security issues.

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

Also worth checking out is http://yavipin.sourceforge.net/, but no Debian
packages seem to be available yet.


8.5.1. Point to Point tunneling

If you want to provide a tunneling server for a mixed environment (both
Microsoft operating systems and Linux clients) and IPsec is not an option
(since it's only provided for Windows 2000 and Windows XP), you can use
PoPToP (Point to Point Tunneling Server), provided in the pptpd package.

If you want to use Microsoft's authentication and encryption with the
server provided in the ppp package, note the following from the FAQ:

It is only necessary to use PPP 2.3.8 if you want Microsoft compatible
MSCHAPv2/MPPE authentication and encryption. The reason for this is that
the MSCHAPv2/MPPE patch currently supplied (19990813) is against PPP
2.3.8. If you don't need Microsoft compatible authentication/encryption
any 2.3.x PPP source will be fine.

However, you also have to apply the kernel patch provided by the
kernel-patch-mppe package, which provides the pp_mppe module for pppd.

Take into account that the encryption in ppptp forces you to store user
passwords in clear text, and that the MS-CHAPv2 protocol contains
http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/.


8.6. 公開鍵インフラストラクチャー (Public Key Infraestructure、PKI)
----------------------------------------------------

Public Key Infrastructure (PKI) is a security architecture introduced to
provide an increased level of confidence for exchanging information over
insecure networks. It makes use of the concept of public and private
cryptographic keys to verify the identity of the sender (signing) and to
ensure privacy (encryption).

PKI について検討すると広範囲の道具に直面することになります:

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

Debian GNU/Linux has software packages to help you with some of these PKI
issues. They include OpenSSL (for certificate generation), OpenLDAP (as a
directory to hold the certificates), gnupg and openswan (with X.509
standard support). However, as of the Woody release (Debian 3.0), Debian
does not have any of the freely available Certificate Authorities such as
pyCA, http://www.openca.org or the CA samples from OpenSSL. For more
information read the http://ospkibook.sourceforge.net/.


8.7. SSL Infrastructure
-----------------------

Debian does provide some SSL certificates with the distribution so that
they can be installed locally. They are found in the ca-certificates
package. This package provides a central repository of certificates that
have been submitted to Debian and approved (that is, verified) by the
package maintainer, useful for any OpenSSL applications which verify SSL
connections.

FIXME: read debian-devel to see if there was something added to this.


8.8. 対ウイルスツール
-------------

There are not many anti-virus tools included with Debian GNU/Linux,
probably because GNU/Linux users are not plagued by viruses. The Unix
security model makes a distinction between privileged (root) processes
and user-owned processes, therefore a "hostile" executable that a
non-root user receives or creates and then executes cannot "infect" or
otherwise manipulate the whole system. However, GNU/Linux worms and
viruses do exist, although there has not (yet, hopefully) been any that
has spread in the wild over any Debian distribution. In any case,
administrators might want to build up anti-virus gateways that protect
against viruses arising on other, more vulnerable systems in their
network.

Debian は対ウイルス環境を構築するために現在以下のような道具を提供しています。

  * 

    http://www.clamav.net, provided since Debian sarge (3.1 release).
    Packages are provided both for the virus scanner (clamav) for the
    scanner daemon (clamav-daemon) and for the data files needed for the
    scanner. Since keeping an antivirus up-to-date is critical for it to
    work properly there are two different ways to get this data:
    clamav-freshclam provides a way to update the database through the
    Internet automatically and clamav-data which provides the data files
    directly. [56]

  * 

    mailscanner an e-mail gateway virus scanner and spam detector. Using
    sendmail or exim as its basis, it can use more than 17 different
    virus scanning engines (including clamav).

  * 

    libfile-scan-perl which provides File::Scan, a Perl extension for
    scanning files for viruses. This modules can be used to make platform
    independent virus scanners.

  * 

    http://www.sourceforge.net/projects/amavis, provided in the package
    amavis-ng and available in sarge, which is a mail virus scanner which
    integrates with different MTA (Exim, Sendmail, Postfix, or Qmail) and
    supports over 15 virus scanning engines (including clamav, File::Scan
    and openantivirus).

  * 

    http://packages.debian.org/sanitizer, a tool that uses the procmail
    package, which can scan email attachments for viruses, block
    attachments based on their filenames, and more.

  * 

    http://packages.debian.org/amavis-postfix、メールトランスポートエージェントからひとつまたは
    複数のウイルススキャナへのインターフェイスを提供するスクリプトです (このパッケージは postfix 版を提供します)。

  * 

    exiscan, an e-mail virus scanner written in Perl that works with
    Exim.

  * 

    blackhole-qmail a spam filter for Qmail with built-in support for
    Clamav.

Some gateway daemons support already tools extensions to build antivirus
environments including exim4-daemon-heavy (the heavy version of the Exim
MTA), frox (a transparent caching ftp proxy server), messagewall (an SMTP
proxy daemon) and pop3vscan (a transparent POP3 proxy).

Debian currently provide clamav as the only antivirus scanning software
in the main official distribution and it also provides multiple
interfaces to build gateways with antivirus capabilities for different
protocols.

Some other free software antivirus projects which might be included in
future Debian GNU/Linux releases:http://sourceforge.net/projects/openantivirus/
(see http://bugs.debian.org/150698 and http://bugs.debian.org/150695 ).

FIXME: Is there a package that provides a script to download the latest
virus signatures from http://www.openantivirus.org/latest.php?

FIXME: Check if scannerdaemon is the same as the open antivirus scanner
daemon (read ITPs).

However, Debian will never provide propietary (non-free and
undistributable) antivirus software such as: Panda Antivirus, NAI
Netshield, http://www.sophos.com/, http://www.antivirus.com, or
http://www.ravantivirus.com. For more pointers see the
http://www.computer-networking.de/~link/security/av-linux_e.txt. This
does not mean that this software cannot be installed properly in a Debian
system[57].

For more information on how to set up a virus detection system read Dave
Jones' article
https://web.archive.org/web/20120509212938/http://www.linuxjournal.com/article/4882.


8.9. GPG agent
--------------

It is very common nowadays to digitally sign (and sometimes encrypt)
e-mail. You might, for example, find that many people participating on
mailing lists sign their list e-mail. Public key signatures are currently
the only means to verify that an e-mail was sent by the sender and not by
some other person.

Debian GNU/Linux provides a number of e-mail clients with built-in e-mail
signing capabilities that interoperate either with gnupg or pgp:

  * 

    evolution.

  * 

    mutt.

  * 

    kmail.

  * 

    icedove (rebranded version of Mozilla's Thunderbird) through the
    http://enigmail.mozdev.org/ plugin. This plugin is provided by the
    enigmail package.

  * 

    sylpheed. Depending on how the stable version of this package
    evolves, you may need to use the bleeding edge version,
    sylpheed-claws.

  * 

    gnus, which when installed with the mailcrypt package, is an emacs
    interface to gnupg.

  * 

    kuvert, which provides this functionality independently of your
    chosen mail user agent (MUA) by interacting with the mail transport
    agent (MTA).

Key servers allow you to download published public keys so that you may
verify signatures. One such key server is http://wwwkeys.pgp.net. gnupg
can automatically fetch public keys that are not already in your public
keyring. For example, to configure gnupg to use the above key server,
edit the file ~/.gnupg/options and add the following line: [58]

keyserver wwwkeys.pgp.net

Most key servers are linked, so that when your public key is added to one
server, the addition is propagated to all the other public key servers.
There is also a Debian GNU/Linux package debian-keyring, that provides
all the public keys of the Debian developers. The gnupg keyrings are
installed in /usr/share/keyrings/.

For more information:

  * 

    http://www.gnupg.org/faq.html.

  * 

    http://www.gnupg.org/gph/en/manual.html.

  * 

    https://web.archive.org/web/20080201103530/http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.html.

  * 

    https://web.archive.org/web/20080513095235/http://www.uk.pgp.net/pgpnet/pgp-faq/.

  * 

    https://web.archive.org/web/20060222110131/http://www.cryptnet.net/fdp/crypto/gpg-party.html.


------------------------------------------------------------------------

[55] Some of them are provided when installing the harden-remoteaudit
package.

[56] If you use this last package and are running an official Debian, the
database will not be updated with security updates. You should either use
clamav-freshclam, clamav-getfiles to generate new clamav-data packages or
update from the maintainers location:

  deb http://people.debian.org/~zugschlus/clamav-data/ /
  deb-src http://people.debian.org/~zugschlus/clamav-data/ /

[57] Actually, there is an installer package for the F-prot antivirus,
which is non-free but gratis for home users, called f-prot-installer.
This installer, however, just downloads
http://www.f-prot.com/products/home_use/linux/ and installs it in the
system.

[58] For more examples of how to configure gnupg check
/usr/share/doc/mutt/examples/gpg.rc.



第9章 Developer's Best Practices for OS Security
==============================================

This chapter introduces some best secure coding practices for developers
writing Debian packages. If you are really interested in secure coding I
recommend you read David Wheeler's
http://www.dwheeler.com/secure-programs/ and http://www.securecoding.org
by Mark G. Graff and Kenneth R. van Wyk (O'Reilly, 2003).


9.1. Best practices for security review and design
--------------------------------------------------

Developers that are packaging software should make a best effort to
ensure that the installation of the software, or its use, does not
introduce security risks to either the system it is installed on or its
users.

In order to do so, they should make their best to review the source code
of the package and detect any flaws that might introduce security bugs
before releasing the software or distributing a new version. It is
acknowledged that the cost of fixing bugs grows for different stages of
its development, so it is easier (and cheaper) to fix bugs when designing
than when the software has been deployed and is in maintenance mode (some
studies say that the cost in this later phase is sixty times higher).
Although there are some tools that try to automatically detect these
flaws, developers should strive to learn about the different kind of
security flaws in order to understand them and be able to spot them in
the code they (or others) have written.

The programming bugs which lead to security bugs typically include:
http://en.wikipedia.org/wiki/Buffer_overflow, format string overflows,
heap overflows and integer overflows (in C/C++ programs), temporary
http://en.wikipedia.org/wiki/Symlink_race (in scripts),
http://en.wikipedia.org/wiki/Directory_traversal and command injection
(in servers) and http://en.wikipedia.org/wiki/Cross_site_scripting, and
http://en.wikipedia.org/wiki/SQL_injection (in the case of web-oriented
applications). For a more complete information on security bugs review
Fortify's http://vulncat.fortifysoftware.com/.

Some of these issues might not be easy to spot unless you are an expert
in the programming language the software uses, but some security problems
are easy to detect and fix. For example, finding temporary race
conditions due to misuse of temporary directories can easily be done just
by running grep -r "/tmp/" .. Those calls can be reviewed and replace the
hardcoded filenames using temporary directories to calls to either mktemp
or tempfile in shell scripts, File::Temp(3perl) in Perl scripts, or
tmpfile(3) in C/C++.

There are a set of tools available to assist to the security code review
phase. These include rats, flawfinder and pscan. For more information,
read the http://www.debian.org/security/audit/tools.

When packaging software developers have to make sure that they follow
common security principles, including:

  * 

    The software runs with the minimum privileges it needs:

      * 

        The package does install binaries setuid or setgid. Lintian will
        warn of http://lintian.debian.org/reports/Tsetuid-binary.html,
        http://lintian.debian.org/reports/Tsetgid-binary.html and
        http://lintian.debian.org/reports/Tsetuid-gid-binary.html
        binaries.

      * 

        The daemons the package provide run with a low privilege user
        (see 「Creating users and groups for software daemons」)

  * 

    Programmed (i.e., cron) tasks running in the system do NOT run as
    root or, if they do, do not implement complex tasks.

If you have to do any of the above make sure the programs that might run
with higher privileges have been audited for security bugs. If you are
unsure, or need help, contact the http://www.debian.org/security/audit/.
In the case of setuid/setgid binaries, follow the Debian policy section
regarding http://www.debian.org/doc/debian-policy/ch-files.html#s10.9

For more information, specific to secure programming, make sure you read
(or point your upstream to) http://www.dwheeler.com/secure-programs/ and
the https://buildsecurityin.us-cert.gov/portal/ portal.


9.2. Creating users and groups for software daemons
---------------------------------------------------

If your software runs a daemon that does not need root privileges, you
need to create a user for it. There are two kind of Debian users that can
be used by packages: static uids (assigned by base-passwd, for a list of
static users in Debian see 「オペレーティングシステムのユーザやグループ」) and dynamic uids in
the range assigned to system users.

In the first case, you need to ask for a user or group id to the
base-passwd. Once the user is available there the package needs to be
distributed including a proper versioned depends to the base-passwd
package.

In the second case, you need to create the system user either in the
preinst or in the postinst and make the package depend on adduser (>=
3.11).

The following example code creates the user and group the daemon will run
as when the package is installed or upgraded:

[...]
case "$1" in
  install|upgrade)

  # If the package has default file it could be sourced, so that
  # the local admin can overwrite the defaults

  [ -f "/etc/default/packagename" ] && . /etc/default/packagename
  # Sane defaults:

  [ -z "$SERVER_HOME" ] && SERVER_HOME=server_dir  [ -z "$SERVER_USER" ] && SERVER_USER=server_user  [ -z "$SERVER_NAME" ] && SERVER_NAME="Server description"
  [ -z "$SERVER_GROUP" ] && SERVER_GROUP=server_group
  # Groups that the user will be added to, if undefined, then none.
  ADDGROUP=""

  # create user to avoid running server as root
  # 1. create group if not existing
  if ! getent group | grep -q "^$SERVER_GROUP:" ; then
     echo -n "Adding group $SERVER_GROUP.."
     addgroup --quiet --system $SERVER_GROUP 2>/dev/null ||true
     echo "..done"
  fi
  # 2. create homedir if not existing
  test -d $SERVER_HOME || mkdir $SERVER_HOME
  # 3. create user if not existing
  if ! getent passwd | grep -q "^$SERVER_USER:"; then
    echo -n "Adding system user $SERVER_USER.."
    adduser --quiet \
            --system \
            --ingroup $SERVER_GROUP \
            --no-create-home \
            --disabled-password \
            $SERVER_USER 2>/dev/null || true
    echo "..done"
  fi
  # 4. adjust passwd entry
  usermod -c "$SERVER_NAME" \
          -d $SERVER_HOME   \
          -g $SERVER_GROUP  \
             $SERVER_USER
  # 5. adjust file and directory permissions
  if ! dpkg-statoverride --list $SERVER_HOME >/dev/null
  then
      chown -R $SERVER_USER:adm $SERVER_HOME
      chmod u=rwx,g=rxs,o= $SERVER_HOME
  fi
  # 6. Add the user to the ADDGROUP group
  if test -n $ADDGROUP
  then
      if ! groups $SERVER_USER | cut -d: -f2 | \
         grep -qw $ADDGROUP; then
           adduser $SERVER_USER $ADDGROUP
      fi
  fi
  ;;
  configure)

[...]

You have to make sure that the init.d script file:

  * 

    Starts the daemon dropping privileges: if the software does not do
    the setuid(2) or seteuid(2) call itself, you can use the --chuid call
    of start-stop-daemon.

  * 

    Stops the daemon only if the user id matches, you can use the
    start-stop-daemon --user option for this.

  * 

    Does not run if either the user or the group do not exist:

      if ! getent passwd | grep -q "^    server_user    :"; then
         echo "Server user does not exist. Aborting" >&2
         exit 1
      fi
      if ! getent group | grep -q "^    server_group    :" ; then
         echo "Server group does not exist. Aborting" >&2
         exit 1
      fi  

If the package creates the system user it can remove it when it is purged
in its postrm. This has some drawbacks, however. For example, files
created by it will be orphaned and might be taken over by a new system
user in the future if it is assigned the same uid[59]. Consequently,
removing system users on purge is not yet mandatory and depends on the
package needs. If unsure, this action could be handled by asking the
administrator for the prefered action when the package is installed (i.e.
through debconf).

Maintainers that want to remove users in their postrm scripts are
referred to the deluser/deluser --system option.

Running programs with a user with limited privileges makes sure that any
security issue will not be able to damage the full system. It also
follows the principle of least privilege. Also consider you can limit
privileges in programs through other mechanisms besides running as
non-root[60]. For more information, read the
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/minimize-privileges.html
chapter of the Secure Programming for Linux and Unix HOWTO book.


------------------------------------------------------------------------

[59] Some relevant threads discussing these drawbacks include
http://lists.debian.org/debian-mentors/2004/10/msg00338.html and
http://lists.debian.org/debian-devel/2004/05/msg01156.html

[60] You can even provide a SELinux policy for it



第10章 システムを破られる前
===============


10.1. Keep your system secure
-----------------------------

You should strive to keep your system secure by monitoring its usage and
also the vulnerabilities that might affect it, patching them as soon as
patches are available. Even though you might have installed a really
secure system initially you have to remember that security in a system
degrades with time, security vulnerabilities might be found for exposed
system services and users might expose the system security either because
of lack of understanding (e.g. accessing a system remotely with a
clear-text protocol or using easy to guess passwords) or because they are
actively trying to subvert the system's security (e.g. install additional
services locally on their accounts).


10.1.1. Tracking security vulnerabilities

Although most administrators are aware of security vulnerabilities
affecting their systems when they see a patch that is made available you
can strive to keep ahead of attacks and introduce temporary
countermeasures for security vulnerabilities by detecting when your
system is vulnerable. This is specially true when running an exposed
system (i.e. connected to the Internet) and providing a service. In such
case the system's administrators should take care to monitor known
information sources to be the first to know when a vulnerability is
detected that might affect a critical service.

This typically includes subscribing to the announcement mailing lists,
project websites or bug tracking systems provided by the software
developers for a specific piece of code. For example, Apache users should
regularly review Apache's http://httpd.apache.org/security_report.html
and subscribe to the http://httpd.apache.org/lists.html#http-announce
mailing list.

In order to track known vulnerabilities affecting the Debian
distribution, the Debian Testing Security Team provides a
https://security-tracker.debian.org/ that lists all the known
vulnerabilities which have not been yet fixed in Debian packages. The
information in that tracker is obtained through different public channels
and includes known vulnerabilities which are available either through
security vulnerability databases or http://www.debian.org/Bugs/.
Administrators can search for the known security issues being tracked for
https://security-tracker.debian.org/tracker/status/release/stable,
https://security-tracker.debian.org/tracker/status/release/oldstable,
https://security-tracker.debian.org/tracker/status/release/testing, or
https://security-tracker.debian.org/tracker/status/release/unstable.

The tracker has searchable interfaces (by http://cve.mitre.org/ name and
package name) and some tools (such as debsecan, see 「Automatically
checking for security issues with debsecan」) use that database to provide
information of vulnerabilities affecting a given system which have not
yet been addressed (i.e. those who are pending a fix).

Concious administrators can use that information to determine which
security bugs might affect the system they are managing, determine the
severity of the bug and apply (if available) temporary countermeasures
before a patch is available fixing this issue.

Security issues tracked for releases supported by the Debian Security
Team should eventually be handled through Debian Security Advisories
(DSA) and will be available for all users (see 「Continuously update the
system」). Once security issues are fixed through an advisory they will
not be available in the tracker, but you will be able to search security
vulnerabilities (by CVE name) using the
http://www.debian.org/security/crossreferences available for published
DSAs.

Notice, however, that the information tracked by the Debian Testing
Security Team only involves disclosed vulnerabilities (i.e. those already
public). In some occasions the Debian Security Team might be handling and
preparing DSAs for packages based on undisclosed information provided to
them (for example, through closed vendor mailing lists or by upstream
maintainers of software). So do not be surprised to find security issues
that only show up as an advisory but never get to show up in the security
tracker.


10.1.2. Continuously update the system

You should conduct security updates frequently. The vast majority of
exploits result from known vulnerabilities that have not been patched in
time, as this http://www.cs.umd.edu/~waa/vulnerability.html (presented at
the 2001 IEEE Symposium on Security and Privacy) explains. Updates are
described under 「セキュリティ上の更新を実行する」.

10.1.2.1. Manually checking which security updates are available

Debian does have a specific tool to check if a system needs to be updated
but many users will just want to manually check if any security updates
are available for their system.

If you have configured your system as described in 「セキュリティ上の更新を実行する」 you
just need to do:

# apt-get update
# apt-get upgrade -s
[ ... review packages to be upgraded ... ]
# apt-get upgrade 
# checkrestart
[ ... restart services that need to be restarted ... ]

And restart those services whose libraries have been updated if any.
Note: Read 「セキュリティ上の更新を実行する」 for more information on library (and kernel)
upgrades.

The first line will download the list of packages available from your
configured package sources. The -s will do a simulation run, that is, it
will not download or install the packages but rather tell you which ones
should be downloaded/installed. From the output you can derive which
packages have been fixed by Debian and are available as a security
update. Sample:

# apt-get upgrade -s
Reading Package Lists... Done
Building Dependency Tree... Done
2 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)

In this example, you can see that the system needs to be updated with new
cvs and cupsys packages which are being retrieved from woody's security
update archive. If you want to understand why these packages are needed,
you should go to http://security.debian.org and check which recent Debian
Security Advisories have been published related to these packages. In
this case, the related DSAs are
https://lists.debian.org/debian-security-announce/2003/msg00014.html (for
cvs) and
https://lists.debian.org/debian-security-announce/2003/msg00013.html (for
cupsys).

Notice that you will need to reboot your system if there has been a
kernel upgrade.

10.1.2.2. Checking for updates at the Desktop

Since Debian 4.0 lenny Debian provides and installs in a default
installation update-notifier. This is a GNOME application that will
startup when you enter your Desktop and can be used to keep track of
updates available for your system and install them. It uses
update-manager for this.

In a stable system updates are only available when a security patch is
available or at point releases. Consequently, if the system is properly
configured to receive security updates as described in 「セキュリティ上の更新を実行する」
and you have a cron task running to update the package information you
will be notified through an icon in the desktop notifcation area.

The notification is not intrusive and users are not forced to install
updates. From the notification icon a desktop user (with the
administrator's password) can access a simple GUI to show available
updates and install them.

This application works by checking the package database and comparing the
system with its contents. If the package database is updated periodically
through a cron task then the contents of the database will be newer than
the packages installed in the system and the application will notify you.

Apt installs such a task (/etc/cron.d/apt) which will run based on Apt's
configuration (more specifically APT::Periodic). In the GNOME environment
this configuration value can be adjusted by going to System > Admin >
Software origins > Updates, or running /usr/bin/software-properties.

If the system is set to download the packages list daily but not download
the packages themselves your /etc/apt/apt.conf.d/10periodic should look
like this:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";

You can use a different cron task, such as the one installed by cron-apt
(see 「Automatically checking for updates with cron-apt」). You can also
just manually check for upgrades using this application.

Users of the KDE desktop environment will probably prefer to install
adept and adept-notifier instead which offers a similar functionality but
is not part of the standard installation.

10.1.2.3. Automatically checking for updates with cron-apt

Another method for automatic security updates is the use of cron-apt.
This package provides a tool to update the system at regular intervals
(using a cron job), and can also be configured to send mails to the
system administrator using the local mail transport agent. It will just
update the package list and download new packages by default but it can
be configured to automatically install new updates.

Notice that you might want to check the distribution release, as
described in 「Per distribution release check」, if you intend to
automatically updated your system (even if only downloading the
packages). Otherwise, you cannot be sure that the downloaded packages
really come from a trusted source.

More information is available at the
http://www.debian-administration.org/articles/162.

10.1.2.4. Automatically checking for security issues with debsecan

The debsecan program evaluates the security status of by reporting both
missing security updates and security vulnerabilities. Unlike cron-apt,
which only provides information related to security updates available,
but this tool obtains information from the security vulnerability
database maintained by the Debian Security Team which includes also
information on vulnerabilities which are not yet fixed through a security
update. Consequently, it is more efficient at helping administrators
track security vulnerabilities (as described in 「Tracking security
vulnerabilities」).

Upon installing the Debian package debsecan, and if the administrator
consents to it, it will generate a cron task that will make it run and
send the output to a specific user whenever it finds a vulnerable
package. It will also download the information from the Internet. The
location of the security database is also part of the questions ask on
installation and are later defined /etc/default/debsecan, it can be
easily adjusted for systems that do not have Internet access so that they
all pull from a local mirror so that there is a single point that access
the vulnerability database.

Notice, however, that the Security Team tracks many vulnerabilities
including low-risk issues which might not be fixed through a security
update and some vulnerabilities initially reported as affecting Debian
might, later on, upon investigation, be dismissed. Debsecan will report
on all the vulnerabilities, which makes it a quite more verbose than the
other tools described above.

More information is available at the
http://www.enyo.de/fw/software/debsecan/.

10.1.2.5. Other methods for security updates

There is also the apticron, which, similarly to cron-apt will check for
updates and send mails to the administrator. More information on apticron
is available at the http://www.debian-administration.org/articles/491.

You might also want to take a look at
http://clemens.endorphin.org/secpack/ which is an unofficial program to
do security updates from security.debian.org with signature checking
written by Fruhwirth Clemens. Or to the Nagios Plugin
http://www.unixdaemon.net/nagios_plugins.html#check_debian_packages
written by Dean Wilson.


10.1.3. Avoid using the unstable branch

Unless you want to dedicate time to patch packages yourself when a
vulnerability arises, you should not use Debian's unstable branch for
production-level systems. The main reason for this is that there are no
security updates for unstable.

The fact is that some security issues might appear in unstable and not in
the stable distribution. This is due to new functionality constantly
being added to the applications provided there, as well as new
applications being included which might not yet have been thoroughly
tested.

In order to do security upgrades in the unstable branch, you might have
to do full upgrades to new versions (which might update much more than
just the affected package). Although there have been some exceptions,
security patches are usually only back ported into the stable branch. The
main idea being that between updates, no new code should be added, just
fixes for important issues.

Notice, however, that you can use the security tracker (as described in
「Tracking security vulnerabilities」) to track known security
vulnerabilities affecting this branch.


10.1.4. Security support for the testing branch

If you are using the testing branch, there are some issues that you must
take into account regarding the availability of security updates:

  * 

    When a security fix is prepared, the Security Team backports the
    patch to stable (since stable is usually some minor or major versions
    behind). Package maintainers are responsible for preparing packages
    for the unstable branch, usually based on a new upstream release.
    Sometimes the changes happen at nearly the same time and sometimes
    one of the releases gets the security fix before. Packages for the
    stable distribution are more thoroughly tested than unstable, since
    the latter will in most cases provide the latest upstream release
    (which might include new, unknown bugs).

  * 

    Security updates are available for the unstable branch usually when
    the package maintainer makes a new package and for the stable branch
    when the Security Team make a new upload and publish a DSA. Notice
    that neither of these change the testing branch.

  * 

    If no (new) bugs are detected in the unstable version of the package,
    it moves to testing after several days. The time this takes is
    usually ten days, although that depends on the upload priority of the
    change and whether the package is blocked from entering testing by
    its dependency relationships. Note that if the package is blocked
    from entering testing the upload priority will not change the time it
    takes to enter.

This behavior might change based on the release state of the
distribution. When a release is almost imminent, the Security Team or
package maintainers might provide updates directly to testing.

Additionally, the http://secure-testing-master.debian.net can issue
Debian Testing Security Advisories (DTSAs) for packages in the testing
branch if there is an immediate need to fix a security issue in that
branch and cannot wait for the normal procedure (or the normal procedure
is being blocked by some other packages).

Users willing to take advantage of this support should add the following
lines to their /etc/apt/sources.list (instead of the lines described in
「セキュリティ上の更新を実行する」):

    deb http://security.debian.org testing/updates main contrib non-free
# This line makes it possible to donwload source packages too
    deb-src  http://security.debian.org testing/updates main contrib non-free

For additional information on this support please read the
http://lists.debian.org/debian-devel-announce/2006/05/msg00006.html. This
support officially started in
http://lists.debian.org/debian-devel-announce/2005/09/msg00006.html in a
separate repository and was later integrated into the main security
archive.


10.1.5. Automatic updates in a Debian GNU/Linux system

First of all, automatic updates are not fully recommended, since
administrators should review the DSAs and understand the impact of any
given security update.

If you want to update your system automatically you should:

  * 

    Configure apt so that those packages that you do not want to update
    stay at their current version, either with apt's pinning feature or
    marking them as hold with aptitude or dpkg.

    To pin the packages under a given release, you must edit
    /etc/apt/preferences (see apt_preferences(5)) and add:

      Package: *
      Pin: release a=stable
      Pin-Priority: 100

    FIXME: verify if this configuration is OK.

  * 

    Either use cron-apt as described in 「Automatically checking for
    updates with cron-apt」 and enable it to install downloaded packages
    or add a cron entry yourself so that the update is run daily, for
    example:

      apt-get update && apt-get -y upgrade

    The -y option will have apt assume 'yes' for all the prompts that
    might arise during the update. In some cases, you might want to use
    the --trivial-only option instead of the --assume-yes (equivalent to
    -y).[61]

  * 

    Configure debconf so no questions will be asked during upgrades, so
    that they can be done non-interactively. [62]

  * 

    Check the results of the cron execution, which will be mailed to the
    superuser (unless changed with MAILTO environment variable in the
    script).

A safer alternative might be to use the -d (or --download-only) option,
which will download but not install the necessary packages. Then if the
cron execution shows that the system needs to be updated, it can be done
manually.

In order to accomplish any of these tasks, the system must be properly
configured to download security updates as discussed in 「セキュリティ上の更新を実行する」.

However, this is not recommended for unstable without careful analysis,
since you might bring your system into an unusable state if some serious
bug creeps into an important package and gets installed in your system.
Testing is slightly more secure with regard to this issue, since serious
bugs have a better chance of being detected before the package is moved
into the testing branch (although, you may have no security updates
available whatsoever).

If you have a mixed distribution, that is, a stable installation with
some packages updated to testing or unstable, you can fiddle with the
pinning preferences as well as the --target-release option in apt-get to
update only those packages that you have updated.[63]


10.2. Do periodic integrity checks
----------------------------------

Based on the baseline information you generated after installation (i.e.
the snapshot described in 「Taking a snapshot of the system」), you should
be able to do an integrity check from time to time. An integrity check
will be able to detect filesystem modifications made by an intruder or
due to a system administrators mistake.

Integrity checks should be, if possible, done offline.[64] That is,
without using the operating system of the system to review, in order to
avoid a false sense of security (i.e. false negatives) produced by, for
example, installed rootkits. The integrity database that the system is
checked against should also be used from read-only media.

You can consider doing integrity checks online using any of the
filesystem integrity tools available (described in 「ファイルシステムの完全性を確かめる」)
if taking offline the system is not an option. However, precaution should
be taken to use a read-only integrity database and also assure that the
integrity checking tool (and the operating system kernel) has not been
tampered with.

Some of the tools mentioned in the integrity tools section, such as aide,
integrit or samhain are already prepared to do periodic reviews (through
the crontab in the first two cases and through a standalone daemon in
samhain) and can warn the administrator through different channels
(usually e-mail, but samhain can also send pages, SNMP traps or syslog
alerts) when the filesystem changes.

Of course, if you execute a security update of the system, the snapshot
taken for the system should be re-taken to accommodate the changes done
by the security update.


10.3. 侵入検知を設定する
---------------

Debian GNU/Linux includes tools for intrusion detection, which is the
practice of detecting inappropriate or malicious activity on your local
system, or other systems in your private network. This kind of defense is
important if the system is very critical or you are truly paranoid. The
most common approaches to intrusion detection are statistical anomaly
detection and pattern-matching detection.

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

When a particular attack has been detected, most intrusion detection
tools will either log the event with syslogd or send e-mail to the root
user (the mail recipient is usually configurable). An administrator has
to properly configure the tools so that false positives do not trigger
alerts. Alerts may also indicate an ongoing attack and might not be
useful, say, one day later, since the attack might have already
succeeded. So be sure that there is a proper policy on handling alerts
and that the technical mechanisms to implement this policy are in place.

http://www.cert.org/tech_tips/intruder_detection_checklist.html は
興味深い情報源です。


10.3.1. ネットワークベースでの侵入検知

Network based intrusion detection tools monitor the traffic on a network
segment and use this information as a data source. Specifically, the
packets on the network are examined, and they are checked to see if they
match a certain signature.

snort is a flexible packet sniffer or logger that detects attacks using
an attack signature dictionary. It detects a variety of attacks and
probes, such as buffer overflows, stealth port scans, CGI attacks, SMB
probes, and much more. snort also has real-time alerting capability. You
can use snort for a range of hosts on your network as well as for your
own host. This is a tool which should be installed on every router to
keep an eye on your network. Just install it with apt-get install snort,
follow the questions, and watch it log. For a little broader security
framework, see http://www.prelude-ids.org.

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

There are other, simpler tools that can be used to detect network
attacks. portsentry is an interesting package that can tip you off to
port scans against your hosts. Other tools like ippl or iplogger will
also detect some IP (TCP and ICMP) attacks, even if they do not provide
the kind of advanced techniques snort does.

You can test any of these tools with the Debian package idswakeup, a
shell script which generates false alarms, and includes many common
attack signatures.


10.3.2. ネットワークベースでの侵入検知

Host based intrusion detection involves loading software on the system to
be monitored which uses log files and/or the systems auditing programs as
a data source. It looks for suspicious processes, monitors host access,
and may even monitor changes to critical system files.

tiger is an older intrusion detection tool which has been ported to
Debian since the Woody branch. tiger provides checks of common issues
related to security break-ins, like password strength, file system
problems, communicating processes, and other ways root might be
compromised. This package includes new Debian-specific security checks
including: MD5sums checks of installed files, locations of files not
belonging to packages, and analysis of local listening processes. The
default installation sets up tiger to run each day, generating a report
that is sent to the superuser about possible compromises of the system.

Log analysis tools, such as logcheck can also be used to detect intrusion
attempts. See 「Using and customizing logcheck」.

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


10.4. rootkits を避ける
-------------------


10.4.1. LKM - Loadable Kernel Modules

Loadable kernel modules are files containing dynamically loadable kernel
components used to expand the functionality of the kernel. The main
benefit of using modules is the ability to add additional devices, like
an Ethernet or sound card, without patching the kernel source and
recompiling the entire kernel. However, crackers are now using LKMs for
root-kits (knark and adore), opening up back doors in GNU/Linux systems.

LKM back doors are more sophisticated and less detectable than
traditional root-kits. They can hide processes, files, directories and
even connections without modifying the source code of binaries. For
example, a malicious LKM can force the kernel into hiding specific
processes from procfs, so that even a known good copy of the binary ps
would not list accurate information about the current processes on the
system.


10.4.2. rootkits を発見する

There are two approaches to defending your system against LKM root-kits,
a proactive defense and a reactive defense. The detection work can be
simple and painless, or difficult and tiring, depending on the approach
taken.

10.4.2.1. 事前の対策

The advantage of this kind of defense is that it prevents damage to the
system in the first place. One such strategy is getting there first, that
is, loading an LKM designed to protect the system from other malicious
LKMs. A second strategy is to remove capabilities from the kernel itself.
For example, you can remove the capability of loadable kernel modules
entirely. Note, however, that there are rootkits which might work even in
this case, there are some that tamper with /dev/kmem (kernel memory)
directly to make themselves undetectable.

Debian GNU/Linux has a few packages that can be used to mount a proactive
defense:

lcap - A user friendly interface to remove capabilities (kernel-based
access control) in the kernel, making the system more secure. For
example, executing lcap CAP_SYS_MODULE[65] will remove module loading
capabilities (even for the root user).[66] There is some (old)
information on capabilities at Jon Corbet's
http://lwn.net/1999/1202/kernel.php3 section on LWN (dated December
1999).

If you don't really need many kernel features on your GNU/Linux system,
you may want to disable loadable modules support during kernel
configuration. To disable loadable module support, just set
CONFIG_MODULES=n during the configuration stage of building your kernel,
or in the .config file. This will prevent LKM root-kits, but you lose
this powerful feature of the Linux kernel. Also, disabling loadable
modules can sometimes overload the kernel, making loadable support
necessary.

10.4.2.2. 事後の防御

The advantage of a reactive defense is that it does not overload system
resources. It works by comparing the system call table with a known clean
copy in a disk file, System.map. Of course, a reactive defense will only
notify the system administrator after the system has already been
compromised.

Detection of some root-kits in Debian can be accomplished with the
chkrootkit package. The http://www.chkrootkit.org program checks for
signs of several known root-kits on the target system, but is not a
definitive test.


10.5. 天才的な、またはパラノイアのアイデア — 何ができるか
---------------------------------

This is probably the most unstable and funny section, since I hope that
some of the "duh, that sounds crazy" ideas might be realized. The
following are just some ideas for increasing security - maybe genius,
paranoid, crazy or inspired depending on your point of view.

  * 

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

  * 

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

  * 

    CD distribution. This idea is very easy to realize and offers pretty
    good security. Create a hardened Debian distribution, with proper
    firewall rules. Turn it into a boot-able ISO image, and burn it on a
    CDROM. Now you have a read-only distribution, with about 600 MB space
    for services. Just make sure all data that should get written is done
    over the network. It is impossible for intruders to get read/write
    access on this system, and any changes an intruder does make can be
    disabled with a reboot of the system.

  * 

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

  * 

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

  * 

    Change file attributes using chattr (taken from the Tips-HOWTO,
    written by Jim Dennis). After a clean install and initial
    configuration, use the chattr program with the +i attribute to make
    files unmodifiable (the file cannot be deleted, renamed, linked or
    written to). Consider setting this attribute on all the files in /bin,
    /sbin/, /usr/bin, /usr/sbin, /usr/lib and the kernel files in root.
    You can also make a copy of all files in /etc/, using tar or the
    like, and mark the archive as immutable.

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

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

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

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

  * 

    Play with UTP cabling in a way that you cut 2 or 4 wires and make the
    cable one-way traffic only. Then use UDP packets to send information
    to the destination machine which can act as a secure log server or a
    credit card storage system.


10.5.1. honeypot を構築する

A honeypot is a system designed to teach system administrators how
crackers probe for and exploit a system. It is a system setup with the
expectation and goal that the system will be probed, attacked and
potentially exploited. By learning the tools and methods employed by the
cracker, a system administrator can learn to better protect their own
systems and network.

Debian GNU/Linux systems can easily be used to setup a honeynet, if you
dedicate the time to implement and monitor it. You can easily setup the
fake honeypot server as well as the firewall[67] that controls the
honeynet and some sort of network intrusion detector, put it on the
Internet, and wait. Do take care that if the system is exploited, you are
alerted in time (see 「ログや警告の重要性」) so that you can take appropriate
measures and terminate the compromise when you've seen enough. Here are
some of the packages and issues to consider when setting up your
honeypot:

  * 

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

  * 

    syslog-ng, useful for sending logs from the honeypot to a remote
    syslog server.

  * 

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

  * 

    osh, a SETUID root, security enhanced, restricted shell with logging
    (see Lance Spitzner's article below).

  * 

    Of course, all the daemons you will be using for your fake server
    honeypot. Depending on what type of attacker you want to analyse you
    will or will not harden the honeypot and keep it up to date with
    security patches.

  * 

    攻撃後の監査のために完全性チェッカ (「ファイルシステムの完全性を確かめる」を ごらんください) および The Coroner's
    Toolkit (tct)。

  * 

    honeyd and farpd to setup a honeypot that will listen to connections
    to unused IP addresses and forward them to scripts simulating live
    services. Also check out iisemulator.

  * 

    tinyhoneypot to setup a simple honeypot server with fake services.

If you cannot use spare systems to build up the honeypots and the network
systems to protect and control it you can use the virtualisation
technology available in xen or uml (User-Mode-Linux). If you take this
route you will need to patch your kernel with either kernel-patch-xen or
kernel-patch-uml.

You can read more about building honeypots in Lanze Spitzner's excellent
article http://www.net-security.org/text/articles/spitzner/honeypot.shtml
(from the Know your Enemy series). Also, the http://project.honeynet.org/
provides valuable information about building honeypots and auditing the
attacks made on them.


------------------------------------------------------------------------

[61] You may also want to use the --quiet (-q) option to reduce the
output of apt-get, which will stop the generation of any output if no
packages are installed.

[62] Note that some packages might not use debconf and updates will stall
due to packages asking for user input during configuration.

[63] This is a common issue since many users want to maintain a stable
system while updating some packages to unstable to gain the latest
functionality. This need arises due to some projects evolving faster than
the time between Debian's stable releases.

[64] An easy way to do this is using a Live CD, such as
http://www.knoppix-std.org/ which includes both the file integrity tools
and the integrity database for your system.

[65] There are over 28 capabilities including: CAP_BSET, CAP_CHOWN,
CAP_FOWNER, CAP_FSETID, CAP_FS_MASK, CAP_FULL_SET, CAP_INIT_EFF_SET,
CAP_INIT_INH_SET, CAP_IPC_LOCK, CAP_IPC_OWNER, CAP_KILL, CAP_LEASE,
CAP_LINUX_IMMUTABLE, CAP_MKNOD, CAP_NET_ADMIN, CAP_NET_BIND_SERVICE,
CAP_NET_RAW, CAP_SETGID, CAP_SETPCAP, CAP_SETUID, CAP_SYS_ADMIN,
CAP_SYS_BOOT, CAP_SYS_CHROOT, CAP_SYS_MODULE, CAP_SYS_NICE, CAP_SYS_PACCT,
CAP_SYS_PTRACE, CAP_SYS_RAWIO, CAP_SYS_RESOURCE, CAP_SYS_TIME, and
CAP_SYS_TTY_CONFIG. All of them can be de-activated to harden your
kernel.

[66] You don't need to install lcap to do this, but it's easier than
setting /proc/sys/kernel/cap-bound by hand.

[67] You will typically use a bridge firewall so that the firewall itself
is not detectable, see 「Setting up a bridge firewall 」.



第11章 After the compromise (incident response)
=============================================


11.1. 一般的な行動
------------

If you are physically present when an attack is happening, your first
response should be to remove the machine from the network by unplugging
the network card (if this will not adversely affect any business
transactions). Disabling the network at layer 1 is the only true way to
keep the attacker out of the compromised box (Phillip Hofmeister's wise
advice).

However, some tools installed by rootkits, trojans and, even, a rogue
user connected through a back door, might be capable of detecting this
event and react to it. Seeing a rm -rf / executed when you unplug the
network from the system is not really much fun. If you are unwilling to
take the risk, and you are sure that the system is compromised, you
should unplug the power cable (all of them if more than one) and cross
your fingers. This may be extreme but, in fact, will avoid any logic-bomb
that the intruder might have programmed. In this case, the compromised
system should not be re-booted. Either the hard disks should be moved to
another system for analysis, or you should use other media (a CD-ROM) to
boot the system and analyze it. You should not use Debian's rescue disks
to boot the system, but you can use the shell provided by the
installation disks (remember, Alt+F2 will take you to it) to analyze [68]
the system.

The most recommended method for recovering a compromised system is to use
a live-filesystem on CD-ROM with all the tools (and kernel modules) you
might need to access the compromised system. You can use the mkinitrd-cd
package to build such a CD-ROM[69]. You might find the
http://www.caine-live.net/ (Computer Aided Investigative Environment)
CD-ROM useful here too, since it's also a live CD-ROM under active
development with forensic tools useful in these situations. There is not
(yet) a Debian-based tool such as this, nor an easy way to build the
CD-ROM using your own selection of Debian packages and mkinitrd-cd (so
you'll have to read the documentation provided with it to make your own
CD-ROMs).

If you really want to fix the compromise quickly, you should remove the
compromised host from your network and re-install the operating system
from scratch. Of course, this may not be effective because you will not
learn how the intruder got root in the first place. For that case, you
must check everything: firewall, file integrity, log host, log files and
so on. For more information on what to do following a break-in, see
http://www.cert.org/tech_tips/root_compromise.html or SANS's
https://www.sans.org/white-papers/.

Some common questions on how to handle a compromised Debian GNU/Linux
system are also available in.


11.2. システムのバックアップを取る
--------------------

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

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

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


11.3. Contact your local CERT
-----------------------------

The CERT (Computer and Emergency Response Team) is an organization that
can help you recover from a system compromise. There are CERTs worldwide
[70] and you should contact your local CERT in the event of a security
incident which has lead to a system compromise. The people at your local
CERT can help you recover from it.

Providing your local CERT (or the CERT coordination center) with
information on the compromise even if you do not seek assistance can also
help others since the aggregate information of reported incidents is used
in order to determine if a given vulnerability is in wide spread use, if
there is a new worm aloft, which new attack tools are being used. This
information is used in order to provide the Internet community with
information on the http://www.cert.org/current/, and to publish
http://www.cert.org/incident_notes/ and even
http://www.cert.org/advisories/. For more detailed information read on
how (and why) to report an incident read
http://www.cert.org/tech_tips/incident_reporting.html.

You can also use less formal mechanisms if you need help for recovering
from a compromise or want to discuss incident information. This includes
the http://marc.theaimsgroup.com/?l=incidents and the
http://marc.theaimsgroup.com/?l=intrusions.


11.4. 科学捜査
----------

If you wish to gather more information, the tct (The Coroner's Toolkit
from Dan Farmer and Wietse Venema) package contains utilities which
perform a post mortem analysis of a system. tct allows the user to
collect information about deleted files, running processes and more. See
the included documentation for more information. These same utilities and
some others can be found in http://www.sleuthkit.org/ by Brian Carrier,
which provides a web front-end for forensic analysis of disk images. In
Debian you can find both sleuthkit (the tools) and autopsy (the graphical
front-end).

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

You will find more information on forensic analysis in Dan Farmer's and
Wietse Venema's http://www.porcupine.org/forensics/forensic-discovery/
book (available online), as well as in their
http://www.porcupine.org/forensics/column.html and their
http://www.porcupine.org/forensics/handouts.html. Brian Carrier's
newsletter http://www.sleuthkit.org/informer/index.php is also a very
good resource on forensic analysis tips. Finally, the
http://www.honeynet.org/misc/chall.html are an excellent way to hone your
forensic analysis skills as they include real attacks against honeypot
systems and provide challenges that vary from forensic analysis of disks
to firewall logs and packet captures. For information about available
forensics packages in Debian visit https://salsa.debian.org and search
for forensic.

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

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

FIXME: Add pointers to forensic analysis papers (like the Honeynet's
reverse challenge or http://staff.washington.edu/dittrich/).


11.5. Analysis of malware
-------------------------

Some other tools that can be used for forensic analysis provided in the
Debian distribution are: strace and ltrace

Any of these packages can be used to analyze rogue binaries (such as back
doors), in order to determine how they work and what they do to the
system. Some other common tools include ldd (in libc6), strings and
objdump (both in binutils).

If you try to do forensic analysis with back doors or suspected binaries
retrieved from compromised systems, you should do so in a secure
environment (for example in a bochs or xen image or a chroot'ed
environment using a user with low privileges[71]). Otherwise your own
system can be back doored/r00ted too!

If you are interested in malware analysis then you should read the
http://www.porcupine.org/forensics/forensic-discovery/chapter6.html
chapter of Dan Farmer's and Wietse Venema's forensics book.


------------------------------------------------------------------------

[68] >If you are adventurous, you can login to the system and save
information on all running processes (you'll get a lot from /proc/nnn/).
It is possible to get the whole executable code from memory, even if the
attacker has deleted the executable files from disk. Then pull the power
cord.

[69] >In fact, this is the tool used to build the CD-ROMs for the
http://www.gibraltar.at/ project (a firewall on a live CD-ROM based on
the Debian distribution).

[70] > This is a list of some CERTs, for a full list look at the
http://www.first.org/about/organization/teams/index.html (FIRST is the
Forum of Incident Response and Security Teams): http://www.auscert.org.au
(Australia), http://www.unam-cert.unam.mx/ (Mexico)
http://www.cert.funet.fi (Finland), http://www.dfn-cert.de (Germany),
http://cert.uni-stuttgart.de/ (Germany), http://security.dico.unimi.it/
(Italy), http://www.jpcert.or.jp/ (Japan), http://cert.uninett.no
(Norway), http://www.cert.hr (Croatia) http://www.cert.pl (Poland),
http://www.cert.ru (Russia), http://www.arnes.si/si-cert/ (Slovenia)
http://www.rediris.es/cert/ (Spain), http://www.switch.ch/cert/
(Switzerland), http://www.cert.org.tw (Taiwan), and http://www.cert.org
(US).

[71] >Be very careful if using chroots, since if the binary uses a
kernel-level exploit to increase its privileges it might still be able to
infect your system



第12章 よく聞かれる質問 (Frequently asked Questions、FAQ)
==============================================

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


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


12.1.1. Debian は X より安全ですか?

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

For a collection of data regarding security vulnerabilities for many
operating systems, see the http://www.cert.org/stats/cert_stats.html or
generate stats using the http://nvd.nist.gov/statistics.cfm (formerly
ICAT) Is this data useful? There are several factors to consider when
interpreting the data, and it is worth noticing that the data cannot be
used to compare the vulnerabilities of one operating system versus
another.[72] Also, keep in mind that some reported vulnerabilities
regarding Debian apply only to the unstable (i.e. unreleased) branch.

12.1.1.1. Is Debian more secure than other Linux distributions (such as
Red Hat, SuSE...)?

There are not really many differences between Linux distributions, with
exceptions to the base installation and package management system. Most
distributions share many of the same applications, with differences
mainly in the versions of these applications that are shipped with the
distribution's stable release. For example, the kernel, Bind, Apache,
OpenSSH, Xorg, gcc, zlib, etc. are all common across Linux distributions.

For example, Red Hat was unlucky and shipped when foo 1.2.3 was current,
which was then later found to have a security hole. Debian, on the other
hand, was lucky enough to ship foo 1.2.4, which incorporated the bug fix.
That was the case in the big
http://www.cert.org/advisories/CA-2000-17.html problem from a couple
years ago.

There is a lot of collaboration between the respective security teams for
the major Linux distributions. Known security updates are rarely, if
ever, left unfixed by a distribution vendor. Knowledge of a security
vulnerability is never kept from another distribution vendor, as fixes
are usually coordinated upstream, or by http://www.cert.org. As a result,
necessary security updates are usually released at the same time, and the
relative security of the different distributions is very similar.

One of Debian's main advantages with regards to security is the ease of
system updates through the use of apt. Here are some other aspects of
security in Debian to consider:

  * 

    Debian provides more security tools than other distributions, see 8ç« Debian
    でのセキュリティ関連の道具.

  * 

    Debian's standard installation is smaller (less functionality), and
    thus more secure. Other distributions, in the name of usability, tend
    to install many services by default, and sometimes they are not
    properly configured (remember the
    http://www.sophos.com/virusinfo/analyses/linuxlion.html
    http://www.sophos.com/virusinfo/analyses/linuxramen.html). Debian's
    installation is not as limited as OpenBSD (no daemons are active per
    default), but it's a good compromise. [73]

  * 

    Debian documents best security practices in documents like this one.

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

The Debian distribution boasts a large and growing number of software
packages, probably more than provided by many proprietary operating
systems. The more packages installed, the greater the potential for
security issues in any given system.

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

Bugs that are present in the Debian distribution usually affect other
vendors and distributions as well. Check the "Debian specific: yes/no"
section at the top of each advisory (DSA).

12.1.1.3. Does Debian have any certification related to security?

Short answer: no.

Long answer: certification costs money (specially a serious security
certification), nobody has dedicated the resources in order to certify
Debian GNU/Linux to any level of, for example, the
http://niap.nist.gov/cc-scheme/st/. If you are interested in having a
security-certified GNU/Linux distribution, try to provide the resources
needed to make it possible.

There are currently at least two linux distributions certified at
different http://en.wikipedia.org/wiki/Evaluation_Assurance_Level levels.
Notice that some of the CC tests are being integrated into the
http://ltp.sourceforge.net which is available in Debian in the ltp.

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

Yes. http://bastille-linux.sourceforge.net/, originally oriented toward
other Linux distributions (Red Hat and Mandrake), it currently works also
for Debian. Steps are being taken to integrate the changes made to the
upstream version into the Debian package, named bastille.

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

12.1.1.5. I want to run XYZ service, which one should I choose?

One of Debian's great strengths is the wide variety of choice available
between packages that provide the same functionality (DNS servers, mail
servers, ftp servers, web servers, etc.). This can be confusing to the
novice administrator when trying to determine which package is right for
you. The best match for a given situation depends on a balance between
your feature and security needs. Here are some questions to ask yourself
when deciding between similar packages:

  * 

    Is the software maintained upstream? When was the last release?

  * 

    Is the package mature? The version number really does not tell you
    about its maturity. Try to trace the software's history.

  * 

    Is the software bug-ridden? Have there been security advisories
    related to it?

  * 

    Does the software provide all the functionality you need? Does it
    provide more than you really need?

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

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

12.1.1.7. How can I remove all the banners for services?

If you do not like users connecting to your POP3 daemon, for example, and
retrieving information about your system, you might want to remove (or
change) the banner the service shows to users. [74] Doing so depends on
the software you are running for a given service. For example, in postfix,
you can set your SMTP banner in /etc/postfix/main.cf:

 
  smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

Other software is not as easy to change. ssh will need to be recompiled
in order to change the version that it prints. Take care not to remove
the first part (SSH-2.0) of the banner, which clients use to identify
which protocol(s) is supported by your package.

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

The Debian security team cannot possibly analyze all the packages
included in Debian for potential security vulnerabilities, since there
are just not enough resources to source code audit the whole project.
However, Debian does benefit from the source code audits made by upstream
developers.

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

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

12.1.1.9. Why are some log files/configuration files world-readable,
isn't this insecure?

Of course, you can change the default Debian permissions on your system.
The current policy regarding log files and configuration files is that
they are world readable unless they provide sensitive information.

Be careful if you do make changes since:

  * 

    Processes might not be able to write to log files if you restrict
    their permissions.

  * 

    Some applications may not work if the configuration file they depend
    on cannot be read. For example, if you remove the world-readable
    permission from /etc/samba/smb.conf, the smbclient program will not
    work when run by a normal user.

FIXME: Check if this is written in the Policy. Some packages (i.e. ftp
daemons) seem to enforce different permissions.

12.1.1.10. Why does /root/ (or UserX) have 755 permissions?

As a matter of fact, the same questions stand for any other user. Since
Debian's installation does not place any file under that directory,
there's no sensitive information to protect there. If you feel these
permissions are too broad for your system, consider tightening them to
750. For users, read 「Limiting access to other user's information」.

This Debian security mailing list
http://lists.debian.org/debian-devel/2000/11/msg00783.html has more on
this issue.

12.1.1.11. After installing a grsec/firewall, I started receiving many
console messages! How do I remove them?

If you are receiving console messages, and have configured
/etc/syslog.conf to redirect them to either files or a special TTY, you
might be seeing messages sent directly to the console.

The default console log level for any given kernel is 7, which means that
any message with lower priority will appear in the console. Usually,
firewalls (the LOG rule) and some other security tools log lower that
this priority, and thus, are sent directly to the console.

To reduce messages sent to the console, you can use dmesg (-n option, see
dmseg(8)), which examines and controls the kernel ring buffer. To fix
this after the next reboot, change /etc/init.d/klogd from:

  KLOGD=""

こう変更します:

  KLOGD="-c 4"

Use a lower number for -c if you are still seeing them. A description of
the different log levels can be found in /usr/include/sys/syslog.h:

  #define LOG_EMERG       0       /* system is unusable */
  #define LOG_ALERT       1       /* action must be taken immediately */
  #define LOG_CRIT        2       /* critical conditions */
  #define LOG_ERR         3       /* error conditions */
  #define LOG_WARNING     4       /* warning conditions */
  #define LOG_NOTICE      5       /* normal but significant condition */
  #define LOG_INFO        6       /* informational */
  #define LOG_DEBUG       7       /* debug-level messages */

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

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

Yes and no. Debian comes with some predefined users (user id (UID) < 99
as described in http://www.debian.org/doc/debian-policy/ or
/usr/share/doc/base-passwd/README) to ease the installation of some
services that require that they run under an appropriate user/UID. If you
do not intend to install new services, you can safely remove those users
who do not own any files in your system and do not run any services. In
any case, the default behavior is that UID's from 0 to 99 are reserved in
Debian, and UID's from 100 to 999 are created by packages on install (and
deleted when the package is purged).

To easily find users who don't own any files, execute the following
command[75] (run it as root, since a common user might not have enough
permissions to go through some sensitive directories):

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

These users are provided by base-passwd. Look in its documentation for
more information on how these users are handled in Debian. The list of
default users (with a corresponding group) follows:

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

    operator: Operator is historically (and practically) the only 'user'
    account that can login remotely, and doesn't depend on NIS/NFS.

  * 

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

  * 

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

  * 

    gnats。

  * 

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

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

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

  * 

    utmp: このグループは /var/run/utmp および同様のファイルに書きこむ
    ことができます。これに書きこめる必要があるプログラムは utmp に sgid されています。

  * 

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

  * 

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

  * 

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

12.1.1.12.2. I removed a system user! How can I recover?

If you have removed a system user and have not made a backup of your
password and group files you can try recovering from this issue using
update-passwd (see update-passwd(8)).

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

The 'adm' group are usually administrators, and this group permission
allows them to read log files without having to su. The 'staff' group are
usually help-desk/junior sysadmins, allowing them to work in /usr/local
and create directories in /home.

12.1.1.13. Why is there a new group when I add a new user? (or Why does
Debian give each user one group?)

The default behavior in Debian is that each user has its own, private
group. The traditional UN*X scheme assigned all users to the users group.
Additional groups were created and used to restrict access to shared
files associated with different project directories. Managing files
became difficult when a single user worked on multiple projects because
when someone created a file, it was associated with the primary group to
which they belong (e.g. 'users').

Debian's scheme solves this problem by assigning each user to their own
group; so that with a proper umask (0002) and the SETGID bit set on a
given project directory, the correct group is automatically assigned to
files created in that directory. This makes it easier for people who work
on multiple projects, because they will not have to change groups or
umasks when working on shared files.

You can, however, change this behavior by modifying /etc/adduser.conf.
Change the USERGROUPS variable to 'no', so that a new group is not
created when a new user is created. Also, set USERS_GID to the GID of the
users group which all users will belong to.

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

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

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

There has been much discussion on Debian mailing lists (both at
debian-devel and at debian-security) regarding which is the better
approach for a standard installation. However, as of this writing (March
2002), there still isn't a consensus.

12.1.1.14.2. Can I remove inetd?

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

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

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

In versions of the portmap package later than 5-5 you can actually have
the portmapper installed but listening only on localhost (by modifying
/etc/default/portmap)

12.1.1.14.4. What use is identd (port 113) for?

Identd service is an authentication service that identifies the owner of
a specific TCP/IP connection to the remote server accepting the
connection. Typically, when a user connects to a remote host, inetd on
the remote host sends back a query to port 113 to find the owner
information. It is often used by mail, FTP and IRC servers, and can also
be used to track down which user in your local system is attacking a
remote system.

There has been extensive discussion on the security of identd (See
http://lists.debian.org/debian-security/2001/08/msg00297.html). In
general, identd is more helpful on a multi-user system than on a single
user workstation. If you don't have a use for it, disable it, so that you
are not leaving a service open to the outside world. If you decide to
firewall the identd port, please use a reject policy and not a deny
policy, otherwise a connection to a server utilizing identd will hang
until a timeout expires (see http://logi.cc/linux/reject_or_deny.php3).

12.1.1.14.5. I have services using port 1 and 6, what are they and how
can I remove them?

If you have run the command netstat -an and receive:

  Active Internet connections (servers and established)
  Proto Recv-Q Send-Q Local Address           Foreign Address         State
  PID/Program name
  raw        0      0 0.0.0.0:1               0.0.0.0:*               7
  -
  raw        0      0 0.0.0.0:6               0.0.0.0:*               7
  -

You are not seeing processes listening on TCP/UDP port 1 and 6. In fact,
you are seeing a process listening on a raw socket for protocols 1 (ICMP)
and 6 (TCP). Such behavior is common to both legitimate software like
intrustion detection systems, such as iplogger and portsentry, but some
trojans have also been known yo use them. If you have the mentioned
packages simply remove them to close the port. If you do not, try
netstat's -p (process) option to see which process is running these
listeners.

12.1.1.14.6. I found the port XYZ open, can I close it?

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

12.1.1.14.7. Will removing services from /etc/services help secure my
box?

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

12.1.1.15. Common security issues

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

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

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

Once you have enabled booting from a CD-ROM or diskette enable, try the
following:

  * 

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

  * 

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

  * 

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

  * 

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

      root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=any number)

    こう変更します:

      root::XXXX:X:XXXX:X:::  

This will remove the forgotten root password, contained in the first
colon separated field after the user name. Save the file, reboot the
system and login with root using an empty password. Remember to reset the
password. This will work unless you have configured the system more
tightly, i.e. if you have not allowed users to have null passwords or not
allowed root to login from the console.

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

Once LILO is unrestricted, try the following:

  * 

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

  * 

    Type linux single, linux init=/bin/sh or linux 1 at the prompt.

  * 

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

  * 

    Re-mount read/write the root (/) partition, using the mount command.

      # mount -o remount,rw /  

  * 

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

12.1.1.16. How do I accomplish setting up a service for my users without
giving out shell accounts?

For example, if you want to set up a POP service, you don't need to set
up a user account for each user accessing it. It's best to set up
directory-based authentication through an external service (like Radius,
LDAP or an SQL database). Just install the appropriate PAM library (libpam-radius-auth,
libpam-ldap, libpam-pgsql or libpam-mysql), read the documentation (for
starters, see 「ユーザ認証: PAM」) and configure the PAM-enabled service to use
the back end you have chosen. This is done by editing the files under
/etc/pam.d/ for your service and modifying the

 
  auth   required    pam_unix_auth.so shadow nullok use_first_pass

to, for example, ldap:

  auth   required    pam_ldap.so

In the case of LDAP directories, some services provide LDAP schemas to be
included in your directory that are required in order to use LDAP
authentication. If you are using a relational database, a useful trick is
to use the where clause when configuring the PAM modules. For example, if
you have a database with the following table attributes:

  (user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)

By making the services attributes boolean fields, you can use them to
enable or disable access to the different services just by inserting the
appropriate lines in the following files:

  * 

    /etc/pam.d/imap:where=imap=1.

  * 

    /etc/pam.d/qpopper:where=pop=1.

  * 

    /etc/nss-mysql*.conf:users.where_clause = user.sys = 1;.

  * 

    /etc/proftpd.conf: SQLWhereClause "ftp=1".


12.1.2. My system is vulnerable! (Are you sure?)

12.1.2.1. Vulnerability assessment scanner X says my Debian system is
vulnerable!

Many vulnerability assessment scanners give false positives when used on
Debian systems, since they only use version checks to determine if a
given software package is vulnerable, but do not really test the security
vulnerability itself. Since Debian does not change software versions when
fixing a package (many times the fix made for newer releases is back
ported), some tools tend to think that an updated Debian system is
vulnerable when it is not.

If you think your system is up to date with security patches, you might
want to use the cross references to security vulnerability databases
published with the DSAs (see 「Debian Security Advisories」) to weed out
false positives, if the tool you are using includes CVE references.

12.1.2.2. I've seen an attack in my system's logs. Is my system
compromised?

A trace of an attack does not always mean that your system has been
compromised, and you should take the usual steps to determine if the
system is indeed compromised (see 11ç« After the compromise (incident
response)). Even if your system was not vulnerable to the attack that was
logged, a determined attacker might have used some other vulnerability
besides the ones you have detected.

12.1.2.3. I have found strange 'MARK' lines in my logs: Am I compromised?

You might find the following lines in your system logs:

  Dec 30 07:33:36 debian -- MARK --
  Dec 30 07:53:36 debian -- MARK --
  Dec 30 08:13:36 debian -- MARK --

This does not indicate any kind of compromise, and users changing between
Debian releases might find it strange. If your system does not have high
loads (or many active services), these lines might appear throughout your
logs. This is an indication that your syslogd daemon is running properly.
From syslogd(8):

       -m interval
              The syslogd logs a mark timestamp  regularly.   The
              default interval between two -- MARK -- lines is 20
              minutes.  This can be  changed  with  this  option.
              Setting the interval to zero turns it off entirely.

12.1.2.4. I found users using 'su' in my logs: Am I compromised?

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

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

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

  $ grep 25 /etc/crontab
  25 9    * * *   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

12.1.2.5. I have found 'possible SYN flooding' in my logs: Am I under
attack?

If you see entries like these in your logs:

  May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
  May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.

Check if there is a high number of connections to the server using
netstat, for example:

  linux:~# netstat -ant | grep SYN_RECV | wc -l
     9000

This is an indication of a denial of service (DoS) attack against your
system's X port (most likely against a public service such as a web
server or mail server). You should activate TCP syncookies in your
kernel, see 「Configuring syncookies」. Note, however, that a DoS attack
might flood your network even if you can stop it from crashing your
systems (due to file descriptors being depleted, the system might become
unresponsive until the TCP connections timeout). The only effective way
to stop this attack is to contact your network provider.

12.1.2.6. I have found strange root sessions in my logs: Am I
compromised?

You might see these kind of entries in your /var/log/auth.log file:

  May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
  May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
  May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
  (UID=0)
  May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root

These are due to a cron job being executed (in this example, every five
minutes). To determine which program is responsible for these jobs, check
entries under: /etc/crontab, /etc/cron.d, /etc/crond.daily and root's
crontab under /var/spool/cron/crontabs.

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

There are several steps you might want to take in case of a break-in:

  * 

    Check if your system is up to date with security patches for
    published vulnerabilities. If your system is vulnerable, the chances
    that the system is in fact compromised are increased. The chances
    increase further if the vulnerability has been known for a while,
    since there is usually more activity related to older
    vulnerabilities. Here is a link to http://www.sans.org/top20/.

  * 

    Read this document, especially the 11ç« After the compromise (incident
    response) section.

  * 

    Ask for assistance. You might use the debian-security mailing list
    and ask for advice on how to recover/patch your system.

  * 

    Notify your local http://www.cert.org (if it exists, otherwise you
    may want to consider contacting CERT directly). This might or might
    not help you, but, at the very least, it will inform CERT of ongoing
    attacks. This information is very valuable in determining which tools
    and attacks are being used by the blackhat community.

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

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

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

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

If no information seems to be published, please send e-mail about the
affected package(s), as well as a detailed description of the
vulnerability (proof of concept code is also OK), to
mailto:team@security.debian.org. This will get you in touch with Debian's
security team.

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

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


12.2. 特定のソフトウェア
---------------


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

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


12.2.2. After installing portsentry, there are a lot of ports open.

That's just the way portsentry works. It opens about twenty unused ports
to try to detect port scans.


12.3. Debian security team に関する質問
---------------------------------

The security team keeps its list of Frequently Asked Questions at the
http://www.debian.org/security/faq. Please refer to that web page for up
to date information.


------------------------------------------------------------------------

[72] For example, based on some data, it might seem that Windows NT is
more secure than Linux, which is a questionable assertion. After all,
Linux distributions usually provide many more applications compared to
Microsoft's Windows NT. This counting vulnerabilities issues are better
described in http://www.dwheeler.com/oss_fs_why.html#security by David A.
Wheeler

[73] >Without diminishing the fact that some distributions, such as Red
Hat or Mandrake, are also taking into account security in their standard
installations by having the user select security profiles, or using
wizards to help with configuration of personal firewalls.

[74] >Note that this is 'security by obscurity', and will probably not be
worth the effort in the long term.

[75] Be careful, as this will traverse your whole system. If you have a
lot of disk and partitions you might want to reduce it in scope.



付録A 改訂履歴
========

改訂履歴

改訂 3-19.2

Sun May 19 2024

Wansing Holger [FAMILY Given]

Translation files synchronised with XML sources 3-19

改訂 3-19.1

Mon May 1 2017

Fouces Marcos [FAMILY Given]

Translation files synchronised with XML sources 3-19

改訂 3-19

April 2017

Fouces Marcos [FAMILY Given]

Migrate to Docbook XML.

Build with Publican. No longer use custom Makefile.

Migrate svn repository to git.

Import chinese, italian, spanish, portuguese, japanese, russian, french
and german translations to PO format.

改訂 3-18

February 2015

Kinkhorst Thijs [FAMILY Given]

Clarify FAQ on raw sockets.

Update section 4.5 on GRUB2.

Replace example postrm user removal code with advice to use
deluser/delgroup --system

改訂 3-17

January 2015

Kinkhorst Thijs [FAMILY Given]

Remove mention of MD5 shadow passwords.

Do not recommend dselect for holding packages.

No longer include the Security Team FAQ verbatim, because it duplicates
information documented elsewhere and is hence perpetually out of date.

Update section on restart after library upgrades to mention needrestart.

Avoid gender-specific language. Patch by Myriam.

Use LSB headers for firewall script. Patch by Dominic Walden.

改訂 3-16

January 2013

Fernández-Sanguino Peña. Javier [FAMILY Given]

Indicate that the document is not updated with latest versions.

Update pointers to current location of sources.

Update information on security updates for newer releases.

Point information for Developers to online sources instead of keeping the
information in the document, to prevent duplication.

Extend the information regarding securing console access, including
limiting the Magic SysRq key.

Update the information related to PAM modules including how to restrict
console logins, use cracklib and use the features avialable in
/etc/pam.d/login. Remove the references to obsolete variables in
/etc/login.defs.

Reference some of the PAM modules available to use double factor
authentication, for administrators that want to stop using passwords
altogether.

Fix shell script example in Appendix.

Fix reference errors.

Point to the Basille sourceforge project instead of the bastille-unix.org
site as it is not responding.

改訂 3-15

December 2010

Fernández-Sanguino Peña Javier [FAMILY Given]

Change reference to Log Analysis' website as this is no longer available.

改訂 3-14

March 2009

Fernández-Sanguino Peña Javier [FAMILY Given]

Change the section related to choosing a filesystem: note that ext3 is
now the default.

Change the name of the packages related to enigmail to reflect naming
changes introduced in Debian.

改訂 3-13

February 2008

Fernández-Sanguino Peña Javier [FAMILY Given]

Change URLs pointing to Bastille Linux to www.Bastille-UNIX.org since the
domain has been
http://bastille-linux.sourceforge.net/press-release-newname.html.

Fix pointers to Linux Ramen and Lion worms.

Use linux-image in the examples instead of the (old) kernel-image
packages.

Fix typos spotted by Francesco Poli.

改訂 3-12

August 2007

Fernández-Sanguino Peña Javier [FAMILY Given]

Update the information related to security updates. Drop the text talking
about Tiger and include information on the update-notifier and adept
tools (for Desktops) as well as debsecan. Also include some pointers to
other tools available.

Divide the firewall applications based on target users and add fireflier
to the Desktop firewall applications list.

Remove references to libsafe, it's not in the archive any longer (was
removed January 2006).

Fix the location of syslog's configuration, thanks to John Talbut.

改訂 3-11

January 2007

Fernández-Sanguino Peña Javier [FAMILY Given]

Thanks go to Francesco Poli for his extensive review of the document.

Remove most references to the woody release as it is no longer available
(in the archive) and security support for it is no longer available.

Describe how to restrict users so that they can only do file transfers.

Added a note regarding the debian-private declasiffication decision.

Updated link of incident handling guides.

Added a note saying that development tools (compilers, etc.) are not
installed now in the default 'etch' installation.

Added a note saying that development tools (compilers, etc.) are not
installed now in the default 'etch' installation.

Fix references to the master security server.

Add pointers to additional APT-secure documentation.

Improve the description of APT signatures.

Comment out some things which are not yet final related to the mirror's
official public keys.

Fixed name of the Debian Testing Security Team.

Remove reference to sarge in an example.

Update the antivirus section, clamav is now available on the release.
Also mention the f-prot installer.

Removes all references to freeswan as it is obsolete.

Describe issues related to ruleset changes to the firewall if done
remotely and provide some tips (in footnotes).

Update the information related to the IDS installation, mention BASE and
the need to setup a logging database.

Rewrite the "running bind as a non-root user" section as this no longer
applies to Bind9. Also remove the reference to the init.d script since
the changes need to be done through /etc/default.

Remove the obsolete way to setup iptables rulesets as woody is no longer
supported.

Revert the advice regarding LOG_UNKFAIL_ENAB it should be set to 'no' (as
per default).

Added more information related to updating the system with desktop tools
(including update-notifier) and describe aptitude usage to update the
system. Also note that dselect is deprecated.

Updated the contents of the FAQ and remove redundant paragraphs.

Review and update the section related to forensic analysis of malware.

Remove or fix some dead links.

Fix many typos and gramatical errors reported by Francesco Poli.

改訂 3-10

November 2006

Fernández-Sanguino Peña Javier [FAMILY Given]

Provide examples using apt-cache's rdepends as suggested by Ozer Sarilar.

Fix location of Squid's user's manual because of its relocation as
notified by Oskar Pearson (its maintainer).

Fix information regarding umask, it's logins.defs (and not limits.conf)
where this can be configured for all login connections. Also state what
is Debian's default and what would be a more restrictive value for both
users and root. Thanks to Reinhard Tartler for spotting the bug.

改訂 3-9

October 2006

Fernández-Sanguino Peña Javier [FAMILY Given]

Add information on how to track security vulnerabilities and add
references to the Debian Testing Security Tracker.

Add more information on the security support for testing.

Fix a large number of typos with a patch provided by Simon Brandmair.

Added section on how to disable root prompt on initramfs provided by Max
Attems.

Remove references to queso.

Note that testing is now security-supported in the introduction.

改訂 3-8

July 2006

Fernández-Sanguino Peña Javier [FAMILY Given]

Rewrote the information on how to setup ssh chroots to clarify the
different options available, thank to Bruce Park for bringing up the
different mistakes in this appendix.

Fix lsof call as suggested by Christophe Sahut.

Include patches for typo fixes from Uwe Hermann.

Fix typo in reference spotted by Moritz Naumann.

改訂 3-7

April 2006

Fernández-Sanguino Peña Javier [FAMILY Given]

Add a section on Debian Developer's best practices for security.

Ammended firewall script with comments from WhiteGhost.

改訂 3-6

March 2006

Fernández-Sanguino Peña Javier [FAMILY Given]

Included a patch from Thomas Sjögren which describes that noexec works as
expected with "new" kernels, adds information regarding tempfile
handling, and some new pointers to external documentation.

Add a pointer to Dan Farmer's and Wietse Venema's forensic discovery web
site, as suggested by Freek Dijkstra, and expanded a little bit the
forensic analysis section with more pointers.

Fixed URL of Italy's CERT, thanks to Christoph Auer.

Reuse Joey Hess' information at the wiki on secure apt and introduce it
in the infrastructure section.

Review sections referring to old versions (woody or potato).

Fix some cosmetic issues with patch from Simon Brandmair.

Included patches from Carlo Perassi: acl patches are obsolete, openwall
patches are obsolete too, removed fixme notes about 2.2 and 2.4 series
kernels, hap is obsolete (and not present in WNPP), remove references to
Immunix (StackGuard is now in Novell's hands), and fix a FIXME about the
use of bsign or elfsign.

Updated references to SElinux web pages to point to the Wiki (currently
the most up to date source of information).

Include file tags and make a more consistent use of "MD5 sum" with a
patch from Jens Seidel.

Patch from Joost van Baal improving the information on the firewall
section (pointing to the wiki instead of listing all firewall packages
available) (Closes: #339865).

Review the FAQ section on vulnerability stats, thanks to Carlos Galisteo
de Cabo for pointing out that it was out of date.

Use the quote from the Social Contract 1.1 instead of 1.0 as suggested by
Francesco Poli.

改訂 3-5

November 2005

Fernández-Sanguino Peña Javier [FAMILY Given]

Note on the SSH section that the chroot will not work if using the nodev
option in the partition and point to the latest ssh packages with the
chroot patch, thanks to Lutz Broedel for pointing these issues out.

Fix typo spotted by Marcos Roberto Greiner (md5sum should be sha1sum in
code snippet).

Included Jens Seidel's patch fixing a number of package names and typos.

Slightly update of the tools section, removed tools no longer available
and added some new ones.

Rewrite parts of the section related to where to find this document and
what formats are available (the website does provide a PDF version). Also
note that copies on other sites and translations might be obsolete (many
of the Google hits for the manual in other sites are actually out of
date).

改訂 3-4

August-September 2005

Fernández-Sanguino Peña Javier [FAMILY Given]

Improved the after installation security enhancements related to kernel
configuration for network level protection with a sysctl.conf file
provided by Will Moy.

Improved the gdm section, thanks to Simon Brandmair.

Typo fixes from Frédéric Bothamy and Simon Brandmair.

Improvements in the after installation sections related to how to
generate the MD5 (or SHA-1) sums of binaries for periodic review.

Updated the after installation sections regarding checksecurity
configuration (was out of date).

改訂 3-3

June 2005

Fernández-Sanguino Peña Javier [FAMILY Given]

Added a code snippet to use grep-available to generate the list of
packages depending on Perl. As requested in #302470.

Rewrite of the section on network services (which ones are installed and
how to disable them).

Added more information to the honeypot deployment section mentioning
useful Debian packages.

改訂 3-2

March 2005

Fernández-Sanguino Peña Javier [FAMILY Given]

Expanded the PAM configuration limits section.

Added information on how to use pam_chroot for openssh (based on
pam_chroot's README).

Fixed some minor issues reported by Dan Jacobson.

Updated the kernel patches information partially based on a patch from
Carlo Perassi and also by adding deprecation notes and new kernel patches
available (adamantix).

Included patch from Simon Brandmair that fixes a sentence related to
login failures in terminal.

Added Mozilla/Thunderbird to the valid GPG agents as suggested by
Kapolnai Richard.

Expanded the section on security updates mentioning library and kernel
updates and how to detect when services need to be restarted.

Rewrote the firewall section, moved the information that applies to woody
down and expand the other sections including some information on how to
manually set the firewall (with a sample script) and how to test the
firewall configuration.

Added some information preparing for the 3.1 release.

Added more detailed information on kernel upgrades, specifically targeted
at those that used the old installation system.

Added a small section on the experimental apt 0.6 release which provides
package signing checks. Moved old content to the section and also added a
pointer to changes made in aptitude.

Typo fixes spotted by Frédéric Bothamy.

改訂 3-1

January 2005

Fernández-Sanguino Peña Javier [FAMILY Given]

Added clarification to ro /usr with patch from Joost van Baal.

Apply patch from Jens Seidel fixing many typos.

FreeSWAN is dead, long live OpenSWAN.

Added information on restricting access to RPC services (when they cannot
be disabled) also included patch provided by Aarre Laakso.

Update aj's apt-check-sigs script.

Apply patch Carlo Perassi fixing URLs.

Apply patch from Davor Ocelic fixing many errors, typos, urls, grammar
and FIXMEs. Also adds some additional information to some sections.

Rewrote the section on user auditing, highlight the usage of script which
does not have some of the issues associated to shell history.

改訂 3-0

December 2004

Fernández-Sanguino Peña Javier [FAMILY Given]

Rewrote the user-auditing information and include examples on how to use
script.

改訂 2-99

March 2004

Fernández-Sanguino Peña Javier [FAMILY Given]

Added information on references in DSAs and CVE-Compatibility.

Added information on apt 0.6 (apt-secure merge in experimental).

Fixed location of Chroot daemons HOWTO as suggested by Shuying Wang.

Changed APACHECTL line in the Apache chroot example (even if its not used
at all) as suggested by Leonard Norrgard.

Added a footnote regarding hardlink attacks if partitions are not setup
properly.

Added some missing steps in order to run bind as named as provided by
Jeffrey Prosa.

Added notes about Nessus and Snort out-of-dateness in woody and
availability of backported packages.

Added a chapter regarding periodic integrity test checks.

Clarified the status of testing regarding security updates (Debian bug
233955).

Added more information regarding expected contents in securetty (since
it's kernel specific).

Added pointer to snoopylogger (Debian bug 179409).

Added reference to guarddog (Debian bug 170710).

apt-ftparchive is in apt-utils, not in apt (thanks to Emmanuel Chantreau
for pointing this out).

Removed jvirus from AV list.

改訂 2-98

Fernández-Sanguino Peña Javier [FAMILY Given]

Fixed URL as suggested by Frank Lichtenheld.

Fixed PermitRootLogin typo as suggested by Stefan Lindenau.

改訂 2-97

September 2003

Fernández-Sanguino Peña Javier [FAMILY Given]

Added those that have made the most significant contributions to this
manual (please mail me if you think you should be in the list and are
not).

Added some blurb about FIXME/TODOs.

Moved the information on security updates to the beginning of the section
as suggested by Elliott Mitchell.

Added grsecurity to the list of kernel-patches for security but added a
footnote on the current issues with it as suggested by Elliott Mitchell.

Removed loops (echo to 'all') in the kernel's network security script as
suggested by Elliott Mitchell.

Added more (up-to-date) information in the antivirus section.

Rewrote the buffer overflow protection section and added more information
on patches to the compiler to enable this kind of protection.

改訂 2-96

August 2003

Fernández-Sanguino Peña Javier [FAMILY Given]

Removed (and then re-added) appendix on chrooting Apache. The appendix is
now dual-licensed.

改訂 2-95

June 2003

Fernández-Sanguino Peña Javier [FAMILY Given]

Fixed typos spotted by Leonard Norrgard.

Added a section on how to contact CERT for incident handling (11ç« After
the compromise (incident response)).

More information on setting up a Squid proxy.

Added a pointer and removed a FIXME thanks to Helge H. F.

Fixed a typo (save_inactive) spotted by Philippe Faes.

Fixed several typos spotted by Jaime Robles.

改訂 2-94

April 2003

Fernández-Sanguino Peña Javier [FAMILY Given]

Following Maciej Stachura's suggestions I've expanded the section on
limiting users.

Fixed typo spotted by Wolfgang Nolte.

Fixed links with patch contributed by Ruben Leote Mendes

Added a link to David Wheeler's excellent document on the footnote about
counting security vulnerabilities.

改訂 2-93

March 2003

Schütz Frédéric [FAMILY Given]

rewrote entirely the section of ext2 attributes (lsattr/chattr)

改訂 2-92

February 2003

Fernández-Sanguino Peña Javier [FAMILY Given], Schütz Frédéric [FAMILY
Given]

Merge section 9.3 ("useful kernel patches") into section 4.13 ("Adding
kernel patches"), and added some content.

Added a few more TODOs.

Added information on how to manually check for updates and also about
cron-apt. That way Tiger is not perceived as the only way to do automatic
update checks.

Slightly rewrite of the section on executing a security updates due to
Jean-Marc Ranger comments.

Added a note on Debian's installation (which will suggest the user to
execute a security update right after installation).

改訂 2-91

January/February 2003

Fernández-Sanguino Peña Javier [FAMILY Given]

Added a patch contributed by Frédéric Schütz.

Added a few more references on capabilities thanks to Frédéric.

Slight changes in the bind section adding a reference to BIND's 9 online
documentation and proper references in the first area (Hi Pedro!).

Fixed the changelog date - new year :-).

Added a reference to Colin's articles for the TODOs.

Removed reference to old ssh+chroot patches.

More patches from Carlo Perassi.

Typo fixes (recursive in Bind is recursion), pointed out by Maik
Holtkamp.

改訂 2-9

December 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Reorganized the information on chroot (merged two sections, it didn't
make much sense to have them separated).

Added the notes on chrooting Apache provided by Alexandre Ratti.

Applied patches contributed by Guillermo Jover.

改訂 2-8

Fernández-Sanguino Peña Javier [FAMILY Given]

Applied patches from Carlo Perassi, fixes include: re-wrapping the lines,
URL fixes, and fixed some FIXMEs.

Updated the contents of the Debian security team FAQ.

Added a link to the Debian security team FAQ and the Debian Developer's
reference, the duplicated sections might (just might) be removed in the
future.

Fixed the hand-made auditing section with comments from Michal Zielinski.

Added links to wordlists (contributed by Carlo Perassi).

Fixed some typos (still many around).

Fixed TDP links as suggested by John Summerfield.

改訂 2-7

Fernández-Sanguino Peña Javier [FAMILY Given]

Some typo fixes contributed by Tuyen Dinh, Bartek Golenko and Daniel K.
Gebhart.

Note regarding /dev/kmem rootkits contributed by Laurent Bonnaud.

Fixed typos and FIXMEs contributed by Carlo Perassi.

改訂 2-6

September 2002

Tillman Cris [FAMILY Given]

Changed around to improve grammar/spelling.

s/host.deny/hosts.deny/ (1 place).

Applied Larry Holish's patch (quite big, fixes a lot of FIXMEs).

改訂 2-5.1

September 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Fixed minor typos submitted by Thiemo Nagel.

Added a footnote suggested by Thiemo Nagel.

Fixed an URL link.

改訂 2-5.0

August 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Applied a patch contributed by Philipe Gaspar regarding the Squid which
also kills a FIXME.

Yet another FAQ item regarding service banners taken from the
debian-security mailing list (thread "Telnet information" started 26th
July 2002).

Added a note regarding use of CVE cross references in the How much time
does the Debian security team... FAQ item.

Added a new section regarding ARP attacks contributed by Arnaud "Arhuman"
Assad.

New FAQ item regarding dmesg and console login by the kernel.

Small tidbits of information to the signature-checking issues in packages
(it seems to not have gotten past beta release).

New FAQ item regarding vulnerability assessment tools false positives.

Added new sections to the chapter that contains information on package
signatures and reorganized it as a new Debian Security Infrastructure
chapter.

New FAQ item regarding Debian vs. other Linux distributions.

New section on mail user agents with GPG/PGP functionality in the
security tools chapter.

Clarified how to enable MD5 passwords in woody, added a pointer to PAM as
well as a note regarding the max definition in PAM.

Added a new appendix on how to create chroot environments (after fiddling
a bit with makejail and fixing, as well, some of its bugs), integrated
duplicate information in all the appendix.

Added some more information regarding SSH chrooting and its impact on
secure file transfers. Some information has been retrieved from the
debian-security mailing list (June 2002 thread: secure file transfers).

New sections on how to do automatic updates on Debian systems as well as
the caveats of using testing or unstable regarding security updates.

New section regarding keeping up to date with security patches in the
Before compromise section as well as a new section about the
debian-security-announce mailing list.

Added information on how to automatically generate strong passwords.

New section regarding login of idle users.

Reorganized the securing mail server section based on the
Secure/hardened/minimal Debian (or "Why is the base system the way it
is?") thread on the debian-security mailing list (May 2002).

Reorganized the section on kernel network parameters, with information
provided in the debian-security mailing list (May 2002, syn flood
attacked? thread) and added a new FAQ item as well.

New section on how to check users passwords and which packages to install
for this.

New section on PPTP encryption with Microsoft clients discussed in the
debian-security mailing list (April 2002).

Added a new section describing what problems are there when binding any
given service to a specific IP address, this information was written
based on the Bugtraq mailing list in the thread: Linux kernel 2.4 "weak
end host" issue (previously discussed on debian-security as "arp
problem") (started on May 9th 2002 by Felix von Leitner).

Added information on ssh protocol version 2.

Added two subsections related to Apache secure configuration (the things
specific to Debian, that is).

Added a new FAQ related to raw sockets, one related to /root, an item
related to users' groups and another one related to log and configuration
files permissions.

Added a pointer to a bug in libpam-cracklib that might still be open...
(need to check).

Added more information regarding forensics analysis (pending more
information on packet inspection tools such as tcpflow).

Changed the "what should I do regarding compromise" into a bullet list
and included some more stuff.

Added some information on how to set up the Xscreensaver to lock the
screen automatically after the configured timeout.

Added a note related to the utilities you should not install in the
system. Included a note regarding Perl and why it cannot be easily
removed in Debian. The idea came after reading Intersect's documents
regarding Linux hardening.

Added information on lvm and journalling file systems, ext3 recommended.
The information there might be too generic, however.

Added a link to the online text version (check).

Added some more stuff to the information on firewalling the local system,
triggered by a comment made by Hubert Chan in the mailing list.

Added more information on PAM limits and pointers to Kurt Seifried's
documents (related to a post by him to Bugtraq on April 4th 2002
answering a person that had ``discovered'' a vulnerability in Debian
GNU/Linux related to resource starvation).

As suggested by Julián Muñoz, provided more information on the default
Debian umask and what a user can access if given a shell in the system
(scary, huh?).

Included a note in the BIOS password section due to a comment from
Andreas Wohlfeld.

Included patches provided by Alfred E. Heggestad fixing many of the typos
still present in the document.

Added a pointer to the changelog in the Credits section since most people
who contribute are listed here (and not there).

Added a few more notes to the chattr section and a new section after
installation talking about system snapshots. Both ideas were contributed
by Kurt Pomeroy.

Added a new section after installation just to remind users to change the
boot-up sequence.

Added some more TODO items provided by Korn Andras.

Added a pointer to the NIST's guidelines on how to secure DNS provided by
Daniel Quinlan.

Added a small paragraph regarding Debian's SSL certificates
infrastructure.

Added Daniel Quinlan's suggestions regarding ssh authentication and
exim's relay configuration.

Added more information regarding securing bind including changes
suggested by Daniel Quinlan and an appendix with a script to make some of
the changes commented on in that section.

Added a pointer to another item regarding Bind chrooting (needs to be
merged).

Added a one liner contributed by Cristian Ionescu-Idbohrn to retrieve
packages with tcpwrappers support.

Added a little bit more info on Debian's default PAM setup.

Included a FAQ question about using PAM to provide services without shell
accounts.

Moved two FAQ items to another section and added a new FAQ regarding
attack detection (and compromised systems).

Included information on how to set up a bridge firewall (including a
sample Appendix). Thanks to Francois Bayart who sent this to me in March.

Added a FAQ regarding the syslogd's MARK heartbeat from a question
answered by Noah Meyerhans and Alain Tesio in December 2001.

Included information on buffer overflow protection as well as some
information on kernel patches.

Added more information (and reorganized) the firewall section. Updated
the information regarding the iptables package and the firewall
generators available.

Reorganized the information regarding log checking, moved logcheck
information from host intrusion detection to that section.

Added some information on how to prepare a static package for bind for
chrooting (untested).

Added a FAQ item regarding some specific servers/services (could be
expanded with some of the recommendations from the debian-security list).

Added some information on RPC services (and when it's necessary).

Added some more information on capabilities (and what lcap does). Is
there any good documentation on this? I haven't found any documentation
on my 2.4 kernel.

Fixed some typos.

改訂 2-4

June 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Rewritten part of the BIOS section.

改訂 2-3.1

April 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Wrapped most file locations with the file tag.

Fixed typo noticed by Edi Stojicevi.

Slightly changed the remote audit tools section.

Added some todo items.

Added more information regarding printers and cups config file (taken
from a thread on debian-security).

Added a patch submitted by Jesus Climent regarding access of valid system
users to Proftpd when configured as anonymous server.

Small change on partition schemes for the special case of mail servers.

Added Hacking Linux Exposed to the books section.

Fixed directory typo noticed by Eduardo Pérez Ureta.

Fixed /etc/ssh typo in checklist noticed by Edi Stojicevi.

改訂 2-3.0

April 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Fixed location of dpkg conffile.

Remove Alexander from contact information.

Added alternate mail address.

Fixed Alexander mail address (even if commented out).

Fixed location of release keys (thanks to Pedro Zorzenon for pointing
this out).

改訂 2-2

April 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Fixed typos, thanks to Jamin W. Collins.

Added a reference to apt-extracttemplate manpage (documents the
APT::ExtractTemplate config).

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.

Added information on antivirus software.

Added a FAQ: su logs due to the cron running as root.

改訂 2-1

April 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Changed FIXME from lshell thanks to Oohara Yuuma.

Added package to sXid and removed comment since it *is* available.

Fixed a number of typos discovered by Oohara Yuuma.

ACID is now available in Debian (in the acidlab package) thanks to Oohara
Yuuma for noticing.

Fixed LinuxSecurity links (thanks to Dave Wreski for telling).

改訂 2-0

March 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Converted the HOWTO into a Manual (now I can properly say RTFM).

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).

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

Added small note on lprng.

Added some more info on compromised servers (still very rough).

Fixed typos reported by Mark Bucciarelli.

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

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

New paragraph to introduce service configuration.

Reorganized the After installation section so it is more broken up into
several issues and it's easier to read.

Wrote information on how to set up firewalls with the standard Debian 3.0
setup (iptables package).

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

Small paragraph on timely patching referencing to IEEE paper.

Appendix on how to set up a Debian snort box, based on what Vladimir sent
to the debian-security mailing list (September 3rd 2001).

Information on how logcheck is set up in Debian and how it can be used to
set up HIDS.

Information on user accounting and profile analysis.

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

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

Small note regarding some programs to automatically build chroot jails.

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

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

Introduced note on rcconf in the "disabling services" section.

Varied the approach regarding LKM, thanks to Philipe Gaspar.

Added pointers to CERT documents and Counterpane resources.

改訂 1-99

January 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Added a new FAQ item regarding time to fix security vulnerabilities.

Reorganized FAQ sections.

Started writing a section regarding firewalling in Debian GNU/Linux
(could be broadened a bit).

Fixed typos sent by Matt Kraai.

Fixed DNS information.

Added information on whisker and nbtscan to the auditing section.

Fixed some wrong URLs.

改訂 1-98

January 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Added a new section regarding auditing using Debian GNU/Linux.

Added info regarding finger daemon taken from the security mailing list.

改訂 1-97

January 2002

Fernández-Sanguino Peña Javier [FAMILY Given]

Fixed link for Linux Trustees.

Fixed typos (patches from Oohara Yuuma and Pedro Zorzenon).

改訂 1-96

December 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

Reorganized service installation and removal and added some new notes.

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

Added a chapter regarding package signatures.

改訂 1-95

December 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

Added notes regarding Squid security sent by Philipe Gaspar.

Fixed rootkit links thanks to Philipe Gaspar.

改訂 1-94

November 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

Added some notes regarding Apache and Lpr/lpng.

Added some information regarding noexec and read-only partitions.

Rewrote how users can help in Debian security issues (FAQ item).

改訂 1-93

November 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

Fixed location of mail program.

Added some new items to the FAQ.

改訂 1-92

October 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

Added a small section on how Debian handles security.

Clarified MD5 passwords (thanks to `rocky').

Added some more information regarding harden-X from Stephen van Egmond.

Added some new items to the FAQ.

改訂 1-91

October 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

Added some forensics information sent by Yotam Rubin.

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

Added some more TODOS.

Fixed more typos (thanks Yotam!).

改訂 1-9

October 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

Added patch to fix misspellings and some new information (contributed by
Yotam Rubin).

Added references to other online (and offline) documentation both in a
section (see 「一般的なセキュリティ問題について知る」) by itself and inline in some sections.

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

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

Removed some done TODOs and added some new ones.

改訂 1-8

October 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

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

Added information on LKM root-kits (「LKM - Loadable Kernel Modules」)
contributed by Philipe Gaspar.

Added information on Proftp contributed by Emmanuel Lacour.

Recovered the checklist Appendix from Era Eriksson.

Added some new TODO items and removed other fixed ones.

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

改訂 1-7

September 2001

Fernández-Sanguino Peña Javier [FAMILY Given], Eriksson Era [FAMILY
Given]

Typo fixes and wording changes.

Minor changes to tags in order to keep on removing the tt tags and
substitute prgn/package tags for them.

改訂 1-6

August 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

Added pointer to document as published in the DDP (should supersede the
original in the near future).

Started a mini-FAQ (should be expanded) with some questions recovered
from my mailbox.

Added general information to consider while securing.

Added a paragraph regarding local (incoming) mail delivery.

Added some pointers to more information.

Added information regarding the printing service.

Added a security hardening checklist.

Reorganized NIS and RPC information.

Added some notes taken while reading this document on my new Visor :).

Fixed some badly formatted lines.

Fixed some typos.

Added a Genius/Paranoia idea contributed by Gaby Schilders.

改訂 1-5

May 2001

Fernández-Sanguino Peña Javier [FAMILY Given], Rodin Josip [FAMILY Given]

Added paragraphs related to BIND and some FIXMEs.

改訂 1-4

May 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

Small setuid check paragraph

Various minor cleanups.

Found out how to use sgml2txt -f for the txt version.

改訂 1-3

March 2001

Fernández-Sanguino Peña Javier [FAMILY Given]

Added a security update after installation paragraph.

Added a proftpd paragraph.

This time really wrote something about XDM, sorry for last time.

改訂 1-2

December 2000

Fernández-Sanguino Peña Javier [FAMILY Given]

Lots of grammar corrections by James Treacy, new XDM paragraph.

改訂 1-1

December 2000

Fernández-Sanguino Peña Javier [FAMILY Given]

Typo fixes, miscellaneous additions.

改訂 1-0

December 2000

Fernández-Sanguino Peña Javier [FAMILY Given]

Initial release.



付録B Appendix
============


B.1. 段階ごとの強化過程
--------------

Below is a post-installation, step-by-step procedure for hardening a
Debian 2.2 GNU/Linux system. This is one possible approach to such a
procedure and is oriented toward the hardening of network services. It is
included to show the entire process you might use during configuration.
Also, see 「設定チェックリスト」.

  * 

    Install the system, taking into account the information regarding
    partitioning included earlier in this document. After base
    installation, go into custom install. Do not select task packages.

  * 

    dselect を行い、[I]nstall の前に不要だが選択されている
    パッケージを削除しましょう。本当に最小限のソフトウェアだけをサーバに 残しましょう。

  * 

    「セキュリティ上の更新を実行する」 ですでに説明されているように security.debian.org で
    利用できる最新のパッケージすべてを更新しましょう。

  * 

    ユーザ quota、ログインの定義や lilo など、このマニュアルで示されて いる提案を導入しましょう。

  * 

    Make a list of services currently running on your system. Try:

      $ ps aux
      $ netstat -pn -l -A inet 
      # /usr/sbin/lsof -i | grep LISTEN

    3 番目のコマンドがうまくいくためには lsof-2.2 をインストール する必要があるでしょう (root
    として実行してください)。lsof は LISTEN という 単語をあなたのロケールの設定にあわせて翻訳するかもしれないことに注意する
    べきです。

  * 

    In order to remove unnecessary services, first determine what package
    provides the service and how it is started. This can be accomplished
    by checking the program that listens in the socket. The following
    shell script, which uses the programs lsof and dpkg, does just that:

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

  * 

    Once you find any unwanted services, remove the associated package
    (with dpkg --purge), or disable the service from starting
    automatically at boot time using update-rc.d (see 「デーモンサービスを停止する」).

  * 

    For inetd services (launched by the superdaemon), check which
    services are enabled in /etc/inetd.conf using:

      $ grep -v "^#" /etc/inetd.conf | sort -u

    Then disable those services that are not needed by commenting out the
    line that includes them in /etc/inetd.conf, removing the package, or
    using update-inetd.

  * 

    ラップされたサービス (/usr/sbin/tcpd を使うもの) が あれば、/etc/hosts.allow と
    /etc/hosts.deny が あなたのサービスポリシーにしたがって設定されていることを確かめましょう。

  * 

    If the server uses more than one external interface, depending on the
    service, you may want to limit the service to listen on a specific
    interface. For example, if you want internal FTP access only, make
    the FTP daemon listen only on your management interface, not on all
    interfaces (i.e, 0.0.0.0:21).

  * 

    マシンを再起動するか、シングルユーザに移行してこのようにして マルチユーザに戻りましょう。

      # init 1
      (....)
      # init 2  

  * 

    サービスがいまでも利用可能か調べて、もし必要ならば、上記の手順を くりかえしましょう。

  * 

    そしてまだインストールしていないなら必要なサービスをインストールし、 適切に設定しましょう。

  * 

    Use the following shell command to determine what user each available
    service is running as:

      # 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

    Consider changing these services to a specific user/group and maybe
    chroot'ing them for increased security. You can do this by changing
    the /etc/init.d scripts which start the service. Most services in
    Debian use start-stop-daemon, which has options (--change-uid and
    --chroot) for accomplishing this. A word of warning regarding the
    chroot'ing of services: you may need to put all the files installed
    by the package (use dpkg -L) providing the service, as well as any
    packages it depends on, in the chroot'ed environment. Information
    about setting up a chroot environment for the ssh program can be
    found in 「Chroot environment for SSH」.

  * 

    望むサービスだけが動いていて、それも望むユーザやグループの組みあわせで 動いているのを確かめるため上記の手順をくりかえしましょう。

  * 

    期待どおりに動いていることを確かめるためインストールされている サービスをテストしましょう。

  * 

    システムの脆弱性 (設定ミス、古いサービスまたは不要なサービス) を 調べるために (nessus のような) 脆弱性評価スキャナを使って
    システムを調べましょう。

  * 

    Install network and host intrusion measures like snort and logcheck.

  * 

    ネットワークスキャナの手順をくりかえして侵入検知システムがきちんと 動いているかどうか検証しましょう。

本物のパラノイアのためには、以下も考慮しましょう:

  * 

    ファイアウォール能力をシステムに追加して、外部からの接続を 提供されているサービスへのみ受けいれ、外部への接続を公認のものだけに
    制限しましょう。

  * 

    Re-check the installation with a new vulnerability assessment using a
    network scanner.

  * 

    Using a network scanner, check outbound connections from the system
    to an outside host and verify that unwanted connections do not find
    their way out.

FIXME: this procedure considers service hardening but not system
hardening at the user level, include information regarding checking user
permissions, SETUID files and freezing changes in the system using the
ext2 file system.


B.2. 設定チェックリスト
--------------

This appendix briefly reiterates points from other sections in this
manual in a condensed checklist format. This is intended as a quick
summary for someone who has already read the manual. There are other good
checklists available, including Kurt Seifried's
http://seifried.org/security/os/linux/20020324-securing-linux-step-by-step.html
and http://www.cert.org/tech_tips/usc20_full.html.

FIXME: This is based on v1.4 of the manual and might need to be updated.

  * 

    物理的なアクセスやブートの能力を制限する

      * 

        Enable a password in the BIOS.

      * 

        Disable floppy/cdrom/... booting in the system's BIOS.

      * 

        LILO か GRUB のパスワードを設定する (それぞれ /etc/lilo.conf か
        /boot/grub/menu.lst)。 LILO か GRUB の設定が読みとり保護されているか調べる。

  * 

    パーティションの分割

      * 

        ユーザが書きこめるデータ、Debian システムでないデータそして 急速に変化するランタイムのデータを独自のパーティションに分ける

      * 

        Set nosuid,noexec,nodev mount options in /etc/fstab on ext2/3
        partitions that should not hold binaries such as /home or /tmp.

  * 

    パスワードの衛生およびログインのセキュリティ

      * 

        よい root パスワードを設定する

      * 

        PAM をインストールして使う

          * 

            PAM に MD5 サポートを追加して (一般的に言って) /etc/pam.d/ ファイルのマシンへのアクセスを
            認める項目についてその pam.d で 2 番目の フィールドが
            「requisite」か「required」に設定されているようにする

          * 

            ローカルからだけ root のログインを許可するように /etc/pam.d/login をいじる

          * 

            さらに /etc/security/access.conf に 公認されている tty を記して一般的に root
            ログインをできるだけ 制限するようこのファイルを設定する

          * 

            ユーザごとの制限を設定したいなら pam_limits.so を追加する

          * 

            /etc/pam.d/passwd をいじる: パスワードの最小の 長さを大きくし (6 文字かも) md5 を有効にする

          * 

            望むなら /etc/group に wheel を追加する。 pam_wheel.so group=wheel の項目を
            /etc/pam.d/su に 追加する

          * 

            独自のユーザごとの制御には、pam_listfile.so の項目を適切な 場所で使う

          * 

            /etc/pam.d/other ファイルを作り、セキュリティを きつく設定する

      * 

        /etc/security/limits.conf で制限を設定する (PAM を 使っているなら /etc/limits
        は使われないことに注意)

      * 

        /etc/login.defs をきつくする。さらに、もし MD5 または PAM
        またはその両方を有効にしているなら、ここでも対応する 変更を行う

      * 

        Tighten up /etc/pam.d/login

      * 

        root での ftp アクセスを /etc/ftpusers で禁止する

      * 

        Disable network root login; use su(1) or sudo(1). (consider
        installing sudo)

      * 

        ログインをさらに制限するのに PAM を使う?

  * 

    その他のローカルのセキュリティ問題

      * 

        カーネルをいじる (「カーネルのネットワーク機能を設定する」 参照)

      * 

        カーネルパッチ (「カーネルパッチを追加する」 参照)

      * 

        ログファイルのパーミッションをきつくする (/var/log/{last,fail}log、Apache logs)

      * 

        /etc/checksecurity.conf で setuid チェックが 有効になっていることを検証する

      * 

        chattr でログファイルを追加専用にして設定ファイルを immutable に することを検討する (ext2
        ファイルシステム専用)

      * 

        ファイルの完全性を設定する (「ファイルシステムの完全性を確かめる」 参照)。 debsums をインストールする

      * 

        何もかもローカルのプリンタで記録する?

      * 

        設定を CD に焼いてそこからブートする?

      * 

        カーネルモジュールを無効にする?

  * 

    ネットワークアクセスを制限する

      * 

        ssh をインストールして設定する (/etc/ssh で PermitRootLogin No、
        PermitEmptyPasswords No にすることを提案。本文中の他の 提案も参照)

      * 

        Disable or remove in.telnetd, if installed

      * 

        一般的に、update-inetd --disable を使って /etc/inetd.conf 中の不要なサービスを停止する
        (または、inetd も停止するか、xinetd や rlinetd などの 代用品を使う)

      * 

        Disable other gratuitous network services; ftp, DNS, WWW etc
        should not be running if you do not need them and monitor them
        regularly. In most cases mail should be running but configured
        for local delivery only.

      * 

        必要なサービスに対しては、単に最も一般的なプログラムを 使うのではなく、Debian から (またはその他のところから)
        入手できるより安全なバージョンを調べる。何を動かすにせよ、 リスクを理解するようにする

      * 

        外部のユーザやデーモンに檻を設定する

      * 

        Configure firewall and tcpwrappers (i.e. hosts_access(5)); note
        trick for /etc/hosts.deny in text.

      * 

        ftp を動かすなら、つねにユーザのホームディレクトリに chroot された状態で動くように ftpd サーバを設定する

      * 

        X を動かすなら、xhost 認証を禁止してかわりに ssh を使う。 よりよいのは、もし可能ならリモートの X を禁止することだ
        (-nolisten tcp を X のコマンドラインに加え、 /etc/X11/xdm/xdm-config 中で
        requestPort を 0 に設定して XDMCP を無効にする)

      * 

        外部からプリンタへのアクセスを禁止する

      * 

        IMAP または POP のセッションをすべて SSL または ssh を 通じて行う。このサービスをリモートのメールユーザに
        提供したいなら stunnel をインストールする

      * 

        ログホストを設置して他のマシンがログをそのホストに送るように 設定する (/etc/syslog.conf)

      * 

        BIND、Sendmail などの複雑なデーモンを安全にする (chroot の檻の中で動かす。root でない仮ユーザで動かす)

      * 

        Install tiger or a similar network intrusion detection tool.

      * 

        Install snort or a similar network intrusion detection tool.v

      * 

        もし可能なら NIS や RPC なしですます (portmap を停止する)。

  * 

    ポリシーの問題

      * 

        ポリシーがなぜあるか、どんなポリシーかについてユーザを 教育する。他のシステムでふつう利用可能なものを禁止するときは、
        他のより安全な手段を使って同様の結果を達成する方法を説明する 文書を提供する

      * 

        平文パスワードを使うプロトコル (telnet、rsh およびその一族。 ftp、imap、http など) を禁止する

      * 

        SVGAlib を使うプログラムを禁止する

      * 

        ディスク quota を使う

  * 

    セキュリティ問題についての情報を得る

      * 

        セキュリティ関連のメーリングリストを講読する

      * 

        セキュリティの更新を講読する -- /etc/apt/sources.list に
        http://security.debian.org/debian-security への項目 (複数かも) を追加する

      * 

        さらに apt-get update ; apt-get upgrade を 「セキュリティ上の更新を実行する」
        で説明されているように周期的に 実行するようにする (もしかしたら cron job として インストールする?)


B.3. 独立の IDS を設置する
------------------

You can easily set up a dedicated Debian system as a stand-alone
Intrusion Detection System using snort and a web-based interface to
analyse the intrusion detection alerts:

  * 

    ベース Debian システムをインストールし、他にパッケージを追加しないように しましょう。

  * 

    Install one of the Snort versions with database support and configure
    the IDS to log alerts into the database.

  * 

    Download and install BASE (Basic Analysis and Security Engine), or
    ACID (Analysis Console for Intrusion Databases). Configure it to use
    the same database than Snort.

  * 

    Download and install the necessary packages[76].

BASE is currently packaged for Debian in acidbase and ACID is packaged as
acidlab[77]. Both provide a graphical WWW interface to Snort's output.

Besides the base installation you will also need a web server (such as
apache), a PHP interpreter and a relational database (such postgresql or
mysql) where Snort will store its alerts.

This system should be set up with at least two interfaces: one interface
connected to a management LAN (for accessing the results and maintaining
the system), and one interface with no IP address attached to the network
segment being analyzed. You should configure the web server to listen
only on the interface connected to the management LAN.

You should configure both interfaces in the standard Debian
/etc/network/interfaces configuration file. One (the management LAN)
address can be configured as you would normally do. The other interface
needs to be configured so that it is started up when the system boots,
but with no interface address. You can use the following interface
definition:

auto eth0
iface eth0 inet manual
      up ifconfig $IFACE 0.0.0.0 up
      up ip link set $IFACE promisc on
      down ip link set $IFACE promisc off
      down ifconfig $IFACE down

The above configures an interface to read all the traffic on the network
in a stealth-type configuration. This prevents the NIDS system to be a
direct target in a hostile network since the sensors have no IP address
on the network. Notice, however, that there have been known bugs over
time in sensors part of NIDS (for example see
https://lists.debian.org/debian-security-announce/2003/msg00087.html
related to Snort) and remote buffer overflows might even be triggered by
network packet processing.

You might also want to read the
http://www.faqs.org/docs/Linux-HOWTO/Snort-Statistics-HOWTO.html and the
documentation available at the https://www.snort.org/#documents.


B.4. Setting up a bridge firewall
---------------------------------

This information was contributed by Francois Bayart in order to help
users set up a Linux bridge/firewall with the 2.4.x kernel and iptables.
Kernel patches are no more needed as the code was made standard part of
the Linux kernel distribution.

To configure the kernel with necessary support, run make menuconfig or
make xconfig. In the section Networking options, enable the following
options:

[*] Network packet filtering (replaces ipchains)
[ ]   Network packet filtering debugging (NEW)
<*> 802.1d Ethernet Bridging
[*]   netfilter (firewalling) support (NEW)

Caution: you must disable this if you want to apply some firewalling
rules or else iptables will not work:

[ ]   Network packet filtering debugging (NEW)

Next, add the correct options in the section IP: Netfilter Configuration.
Then, compile and install the kernel. If you want to do it the Debian way,
install kernel-package and run make-kpkg to create a custom Debian kernel
package you can install on your server using dpkg. Once the new kernel is
compiled and installed, install the bridge-utils package.

Once these steps are complete, you can complete the configuration of your
bridge. The next section presents two different possible configurations
for the bridge, each with a hypothetical network map and the necessary
commands.


B.4.1. A bridge providing NAT and firewall capabilities

The first configuration uses the bridge as a firewall with network
address translation (NAT) that protects a server and internal LAN
clients. A diagram of the network configuration is shown below:

Internet ---- router ( 62.3.3.25 ) ---- bridge (62.3.3.26 gw 62.3.3.25 / 192.168.0.1)
                                          |
                                          |
                                          |---- WWW Server (62.3.3.27 gw 62.3.3.25)
                                          |
                                          |
                                         LAN --- Zipowz (192.168.0.2 gw 192.168.0.1)

The following commands show how this bridge can be configured.

# Create the interface br0
/usr/sbin/brctl addbr br0

# Add the Ethernet interface to use with the bridge
/usr/sbin/brctl addif br0 eth0
/usr/sbin/brctl addif br0 eth1

# Start up the Ethernet interface
/sbin/ifconfig eth0 0.0.0.0
/sbin/ifconfig eth1 0.0.0.0

# Configure the bridge ethernet
# The bridge will be correct and invisible ( transparent firewall ).
# It's hidden in a traceroute and you keep your real gateway on the 
# other computers. Now if you want you can config a gateway on your 
# bridge and choose it as your new gateway for the other computers.

/sbin/ifconfig br0 62.3.3.26 netmask 255.255.255.248 broadcast 62.3.3.31

# I have added this internal IP to create my NAT 
ip addr add 192.168.0.1/24 dev br0
/sbin/route add default gw 62.3.3.25


B.4.2. ファイアウォール機能を追加する

A second possible configuration is a system that is set up as a
transparent firewall for a LAN with a public IP address space.

Internet ---- router (62.3.3.25) ---- bridge (62.3.3.26)
                                        |
                                        |
                                        |---- WWW Server (62.3.3.28 gw 62.3.3.25)
                                        |
                                        |
                                        |---- Mail Server (62.3.3.27 gw 62.3.3.25)

The following commands show how this bridge can be configured.

# Create the interface br0
/usr/sbin/brctl addbr br0

# Add the Ethernet interface to use with the bridge
/usr/sbin/brctl addif br0 eth0
/usr/sbin/brctl addif br0 eth1

# Start up the Ethernet interface
/sbin/ifconfig eth0 0.0.0.0
/sbin/ifconfig eth1 0.0.0.0

# Configure the bridge Ethernet
# The bridge will be correct and invisible ( transparent firewall ).
# It's hidden in a traceroute and you keep your real gateway on the 
# other computers. Now if you want you can config a gateway on your
# bridge and choose it as your new gateway for the other computers.

/sbin/ifconfig br0 62.3.3.26 netmask 255.255.255.248 broadcast 62.3.3.31

If you traceroute the Linux Mail Server, you won't see the bridge. If you
want access to the bridge with ssh, you must have a gateway or you must
first connect to another server, such as the "Mail Server", and then
connect to the bridge through the internal network card.


B.4.3. Basic IPtables rules

This is an example of the basic rules that could be used for either of
these setups.

例B.1 Iptables の規則

iptables -F FORWARD
iptables -P FORWARD DROP
iptables -A FORWARD -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Some funny rules but not in a classic Iptables sorry ...
# Limit ICMP 
# iptables -A FORWARD -p icmp -m limit --limit 4/s -j ACCEPT
# Match string, a good simple method to block some VIRUS very quickly
# iptables -I FORWARD -j DROP -p tcp -s 0.0.0.0/0 -m string --string "cmd.exe"

# Block all MySQL connection just to be sure
iptables -A FORWARD -p tcp -s 0/0 -d 62.3.3.0/24 --dport 3306 -j DROP

# Linux Mail Server Rules

# Allow FTP-DATA (20), FTP (21), SSH (22) 
iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 62.3.3.27/32 --dport 20:22 -j ACCEPT

# Allow the Mail Server to connect to the outside
# Note: This is *not* needed for the previous connections 
# (remember: stateful filtering) and could be removed.
iptables -A FORWARD -p tcp -s 62.3.3.27/32 -d 0/0 -j ACCEPT

# WWW Server Rules

# Allow HTTP ( 80 ) connections with the WWW server
iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 62.3.3.28/32 --dport 80 -j ACCEPT

# Allow HTTPS ( 443 ) connections with the WWW server
iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 62.3.3.28/32 --dport 443 -j ACCEPT

# Allow the WWW server to go out
# Note: This is *not* needed for the previous connections 
# (remember: stateful filtering) and could be removed.
iptables -A FORWARD -p tcp -s 62.3.3.28/32 -d 0/0 -j ACCEPT


B.5. Sample script to change the default Bind installation.
-----------------------------------------------------------

This script automates the procedure for changing the bind version 8 name
server's default installation so that it does not run as the superuser.
Notice that bind version 9 in Debian already does this by default [78] ,
and you are much better using that version than bind version 8.

This script is here for historical purposes and to show how you can
automate this kind of changes system-wide. The script will create the
user and groups defined for the name server and will modify both
/etc/default/bind and /etc/init.d/bind so that the program will run with
that user. Use with extreme care since it has not been tested thoroughly.

You can also create the users manually and use the patch available for
the default init.d script attached to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=157245.

  #!/bin/sh
  # Change the default Debian bind v8 configuration to have it run
  # with a non-root user and group.
  # 
  # DO NOT USER this with version 9, use debconf for configure this instead
  #
  # WARN: This script has not been tested thoroughly, please
  # verify the changes made to the INITD script

  # (c) 2002 Javier Fernandez-Sanguino Pena
  #
  #    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 1, 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.
  #
  #     Please see the file `COPYING' for the complete copyright notice.
  #

  restore() {
  # Just in case, restore the system if the changes fail
    echo "WARN: Restoring to the previous setup since I'm unable to properly change it."
    echo "WARN: Please check the $INITDERR script."
    mv $INITD $INITDERR
    cp $INITDBAK $INITD
  }


  USER=named
  GROUP=named
  INITD=/etc/init.d/bind
  DEFAULT=/etc/default/bind
  INITDBAK=$INITD.preuserchange
  INITDERR=$INITD.changeerror
  AWKS="awk ' /\/usr\/sbin\/ndc reload/ { print \"stop; sleep 2; start;\"; noprint = 1; } /\\\\$/ { if ( noprint != 0 ) { noprint = noprint + 1;} } /^.*$/ { if ( noprint != 0 ) { noprint = noprint - 1; } else { print \$0; } } '"

  [ `id -u` -ne 0 ] && {
    echo "This program must be run by the root user"
    exit 1
  }

  RUNUSER=`ps eo user,fname |grep named |cut -f 1 -d " "`

  if [ "$RUNUSER" = "$USER" ] 
  then
    echo "WARN: The name server running daemon is already running as $USER"
    echo "ERR:  This script will not do any changes to your setup."
    exit 1
  fi
  if [ ! -f "$INITD" ]
  then
    echo "ERR:  This system does not have $INITD (which this script tries to change)"
    RUNNING=`ps eo fname |grep named`
    [ -z "$RUNNING" ] && \
      echo "ERR:  In fact the name server daemon is not even running (is it installed?)"
    echo "ERR:  No changes will be made to your system"
    exit 1
  fi

  # Check if there are options already setup 
  if [ -e "$DEFAULT" ]
  then
    if grep -q ^OPTIONS $DEFAULT; then
      echo "ERR: The $DEFAULT file already has options set."
      echo "ERR:  No changes will be made to your system"
    fi
  fi

  # Check if named group exists
  if [ -z "`grep $GROUP /etc/group`" ] 
  then
    echo "Creating group $GROUP:"
    addgroup $GROUP
  else
    echo "WARN: Group $GROUP already exists. Will not create it"
  fi
  # Same for the user
  if [ -z "`grep $USER /etc/passwd`" ] 
  then
    echo "Creating user $USER:"
    adduser --system --home /home/$USER \
      --no-create-home --ingroup $GROUP \
      --disabled-password --disabled-login $USER
  else
    echo "WARN: The user $USER already exists. Will not create it"
  fi

  # Change the init.d script

  # First make a backup (check that there is not already
  # one there first)
  if [ ! -f $INITDBAK ] 
  then
    cp $INITD $INITDBAK
  fi

  # Then use it to change it
  cat $INITDBAK |
  eval $AWKS > $INITD

  # Now put the options in the /etc/default/bind file:
  cat >>$DEFAULT <<EOF
# Make bind run with the user we defined
OPTIONS="-u $USER -g $GROUP"
EOF

  echo "WARN: The script $INITD has been changed, trying to test the changes."
  echo "Restarting the named daemon (check for errors here)."

  $INITD restart
  if [ $? -ne 0 ] 
  then
    echo "ERR:  Failed to restart the daemon."
    restore
    exit 1
  fi

  RUNNING=`ps eo fname |grep named`
  if [ -z "$RUNNING" ] 
  then
    echo "ERR:  Named is not running, probably due to a problem with the changes."
    restore
    exit 1
  fi

  # Check if it's running as expected
  RUNUSER=`ps eo user,fname |grep named |cut -f 1 -d " "`

  if [ "$RUNUSER" = "$USER" ] 
  then
    echo "All has gone well, named seems to be running now as $USER."
  else
    echo "ERR:  The script failed to automatically change the system."
    echo "ERR:  Named is currently running as $RUNUSER."
    restore
    exit 1
  fi

  exit 0

The previous script, run on Woody's (Debian 3.0) custom bind (version 8),
will modify the initd file after creating the 'named' user and group and
will


B.6. Security update protected by a firewall
--------------------------------------------

After a standard installation, a system may still have some security
vulnerabilities. Unless you can download updates for the vulnerable
packages on another system (or you have mirrored security.debian.org for
local use), the system will have to be connected to the Internet for the
downloads.

However, as soon as you connect to the Internet you are exposing this
system. If one of your local services is vulnerable, you might be
compromised even before the update is finished! This may seem paranoid
but, in fact, analysis from the http://www.honeynet.org has shown that
systems can be compromised in less than three days, even if the system is
not publicly known (i.e., not published in DNS records).

When doing an update on a system not protected by an external system like
a firewall, it is possible to properly configure your local firewall to
restrict connections involving only the security update itself. The
example below shows how to set up such local firewall capabilities, which
allow connections from security.debian.org only, logging all others.

The following example can be use to setup a restricted firewall ruleset.
Run this commands from a local console (not a remote one) to reduce the
chances of locking yourself out of the system.

  # iptables -F
  # iptables -L
  Chain INPUT (policy ACCEPT)
  target     prot opt source               destination

  Chain FORWARD (policy ACCEPT)
  target     prot opt source               destination

  Chain OUTPUT (policy ACCEPT)
  target     prot opt source               destination
  # iptables -A OUTPUT -d security.debian.org --dport 80 -j ACCEPT
  # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
  # iptables -A INPUT -p icmp -j ACCEPT
  # iptables -A INPUT -j LOG
  # iptables -A OUTPUT -j LOG
  # iptables -P INPUT DROP
  # iptables -P FORWARD DROP
  # iptables -P OUTPUT DROP
  # iptables -L
  Chain INPUT (policy DROP)
  target     prot opt source               destination
  ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
  ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
  LOG        all  --  anywhere             anywhere           LOG level warning

  Chain FORWARD (policy DROP)
  target     prot opt source               destination

  Chain OUTPUT (policy DROP)
  target     prot opt source               destination
  ACCEPT     80   --  anywhere             security.debian.org
  LOG        all  --  anywhere             anywhere           LOG level warning

Note: Using a DROP policy in the INPUT chain is the most correct thing to
do, but be very careful when doing this after flushing the chain from a
remote connection. When testing firewall rulesets from a remote location
it is best if you run a script with the firewall ruleset (instead of
introducing the ruleset line by line through the command line) and, as a
precaution, keep a backdoor[79]

Of course, you should disable any backdoors before getting the system
into production. configured so that you can re-enable access to the
system if you make a mistake. That way there would be no need to go to a
remote location to fix a firewall ruleset that blocks you.

FIXME: This needs DNS to be working properly since it is required for
security.debian.org to work. You can add security.debian.org to
/etc/hosts but now it is a CNAME to several hosts (there is more than one
security mirror)

FIXME: this will only work with HTTP URLs since ftp might need the
ip_conntrack_ftp module, or use passive mode.


B.7. Chroot environment for SSH
-------------------------------

Creating a restricted environment for SSH is a tough job due to its
dependencies and the fact that, unlike other servers, SSH provides a
remote shell to users. Thus, you will also have to consider the
applications users will be allowed to use in the environment.

You have two options to setup a restricted remote shell:

  * 

    Chrooting the ssh users, by properly configuring the ssh daemon you
    can ask it to chroot a user after authentication just before it is
    provided a shell. Each user can have their own environment.

  * 

    Chrooting the ssh server, since you chroot the ssh application itself
    all users are chrooted to the defined environment.

The first option has the advantage of making it possible to have both
non-chrooted and chrooted users, if you don't introduce any setuid
application in the user's chroots it is more difficult to break out of
it. However, you might need to setup individual chroots for each user and
it is more difficult to setup (as it requires cooperation from the SSH
server). The second option is more easy to setup, and protects from an
exploitation of the ssh server itself (since it's also in the chroot) but
it will have the limitation that all users will share the same chroot
environment (you cannot setup a per-user chroot environment).


B.7.1. Chrooting the ssh users

You can setup the ssh server so that it will chroot a set of defined
users into a shell with a limited set of applications available.

B.7.1.1. Using libpam-chroot

Probably the easiest way is to use the libpam-chroot package provided in
Debian. Once you install it you need to:

  * 

    Modify /etc/pam.d/ssh to use this PAM module, add as its last line[80]:

    session    required   pam_chroot.so  

  * 

    set a proper chroot environment for the user. You can try using the
    scripts available at /usr/share/doc/libpam-chroot/examples/, use the
    makejail[81] program or setup a minimum Debian environment with
    debootstrap. Make sure the environment includes the needed devices
    [82].

  * 

    Configure /etc/security/chroot.conf so that the users you determine
    are chrooted to the directory you setup previously. You might want to
    have independent directories for different users so that they will
    not be able to see neither the whole system nor each other's.

  * 

    Configure SSH: Depending on your OpenSSH version the chroot
    environment might work straight of the box or not. Since 3.6.1p2 the
    do_pam_session() function is called after sshd has dropped
    privileges, since chroot() needs root priviledges it will not work
    with Privilege separation on. In newer OpenSSH versions, however, the
    PAM code has been modified and do_pam_session is called before
    dropping priviledges so it will work even with Privilege separation
    is on. If you have to disable it modify /etc/ssh/sshd_config like
    this:

    UsePrivilegeSeparation no

    Notice that this will lower the security of your system since the
    OpenSSH server will then run as root user. This means that if a
    remote attack is found against OpenSSH an attacker will get root
    privileges instead of sshd, thus compromising the whole system. [83]

If you don't disable Privilege Separation you will need an /etc/passwd
which includes the user's UID inside the chroot for Privilege Separation
to work properly.

If you have Privilege Separation set to yes and your OpenSSH version does
not behave properly you will need to disable it. If you don't, users that
try to connect to your server and would be chrooted by this module will
see this:

$ ssh -l user server
user@server's password:
Connection to server closed by remote host.
Connection to server closed.

This is because the ssh daemon, which is running as 'sshd', is not be
able to make the chroot() system call. To disable Privilege separation
you have to modify the /etc/ssh/sshd_config configuration file as
described above.

Notice that if any of the following is missing the users will not be able
to logon to the chroot:

  * 

    The /proc filesystem needs to be mounted in the users' chroot.

  * 

    The necessary /dev/pts/ devices need to exist. If the files are
    generated by your running kernel automatically then you have to
    manually create them on the chroot's /dev/.

  * 

    The user's home directory has to exist in the chroot, otherwise the
    ssh daemon will not continue.

You can debug all these issues if you use the debug keyword in the
/etc/pam.d/ssh PAM definition. If you encounter issues you might find it
useful to enable the debugging mode on the ssh client too.

Note: This information is also available (and maybe more up to date) in
/usr/share/doc/libpam-chroot/README.Debian.gz, please review it for
updated information before taking the above steps.

B.7.1.2. Patching the ssh server

Debian's sshd does not allow restriction of a user's movement through the
server, since it lacks the chroot function that the commercial program
sshd2 includes (using 'ChrootGroups' or 'ChrootUsers', see sshd2_config(5)).
However, there is a patch available to add this functionality available
from http://chrootssh.sourceforge.net (requested and available in
http://bugs.debian.org/139047 in Debian). The patch may be included in
future releases of the OpenSSH package. Emmanuel Lacour has ssh deb
packages for sarge with this feature. They are available at
http://debian.home-dn.net/sarge/ssh/. Notice that those might not be up
to date so completing the compilation step is recommended.

After applying the patch, modify /etc/passwd by changing the home path of
the users (with the special /./ token):

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

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

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

./bin:
total 660
drwxr-xr-x    2 root     root         4096 Mar 18 13:36 .
drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
-r-xr-xr-x    1 root     root       531160 Feb  6 22:36 bash
-r-xr-xr-x    1 root     root        43916 Nov 29 13:19 ls
-r-xr-xr-x    1 root     root        16684 Nov 29 13:19 mkdir
-rwxr-xr-x    1 root     root        23960 Mar 18 13:36 more
-r-xr-xr-x    1 root     root         9916 Jul 26  2001 pwd
-r-xr-xr-x    1 root     root        24780 Nov 29 13:19 rm
lrwxrwxrwx    1 root     root            4 Mar 30 16:29 sh -> bash

./etc:
total 24
drwxr-xr-x    2 root     root         4096 Mar 15 16:13 .
drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
-rw-r--r--    1 root     root           54 Mar 15 13:23 group
-rw-r--r--    1 root     root          428 Mar 15 15:56 hosts
-rw-r--r--    1 root     root           44 Mar 15 15:53 passwd
-rw-r--r--    1 root     root           52 Mar 15 13:23 shells

./lib:
total 1848
drwxr-xr-x    2 root     root         4096 Mar 18 13:37 .
drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
-rwxr-xr-x    1 root     root        92511 Mar 15 12:49 ld-linux.so.2
-rwxr-xr-x    1 root     root      1170812 Mar 15 12:49 libc.so.6
-rw-r--r--    1 root     root        20900 Mar 15 13:01 libcrypt.so.1
-rw-r--r--    1 root     root         9436 Mar 15 12:49 libdl.so.2
-rw-r--r--    1 root     root       248132 Mar 15 12:48 libncurses.so.5
-rw-r--r--    1 root     root        71332 Mar 15 13:00 libnsl.so.1
-rw-r--r--    1 root     root        34144 Mar 15 16:10
libnss_files.so.2
-rw-r--r--    1 root     root        29420 Mar 15 12:57 libpam.so.0
-rw-r--r--    1 root     root       105498 Mar 15 12:51 libpthread.so.0
-rw-r--r--    1 root     root        25596 Mar 15 12:51 librt.so.1
-rw-r--r--    1 root     root         7760 Mar 15 12:59 libutil.so.1
-rw-r--r--    1 root     root        24328 Mar 15 12:57 libwrap.so.0

./usr:
total 16
drwxr-xr-x    4 root     root         4096 Mar 15 13:00 .
drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
drwxr-xr-x    2 root     root         4096 Mar 15 15:55 bin
drwxr-xr-x    2 root     root         4096 Mar 15 15:37 lib

./usr/bin:
total 340
drwxr-xr-x    2 root     root         4096 Mar 15 15:55 .
drwxr-xr-x    4 root     root         4096 Mar 15 13:00 ..
-rwxr-xr-x    1 root     root        10332 Mar 15 15:55 env
-rwxr-xr-x    1 root     root        13052 Mar 15 13:13 id
-r-xr-xr-x    1 root     root        25432 Mar 15 12:40 scp
-rwxr-xr-x    1 root     root        43768 Mar 15 15:15 sftp
-r-sr-xr-x    1 root     root       218456 Mar 15 12:40 ssh
-rwxr-xr-x    1 root     root         9692 Mar 15 13:17 tty

./usr/lib:
total 852
drwxr-xr-x    2 root     root         4096 Mar 15 15:37 .
drwxr-xr-x    4 root     root         4096 Mar 15 13:00 ..
-rw-r--r--    1 root     root       771088 Mar 15 13:01
libcrypto.so.0.9.6
-rw-r--r--    1 root     root        54548 Mar 15 13:00 libz.so.1
-rwxr-xr-x    1 root     root        23096 Mar 15 15:37 sftp-server


B.7.2. Chrooting the ssh server

If you create a chroot which includes the SSH server files in, for
example /var/chroot/ssh, you would start the ssh server chroot'ed with
this command:

  # chroot /var/chroot/ssh /sbin/sshd -f /etc/sshd_config

That would make startup the sshd daemon inside the chroot. In order to do
that you have to first prepare the contents of the /var/chroot/ssh
directory so that it includes both the SSH server and all the utilities
that the users connecting to that server might need. If you are doing
this you should make certain that OpenSSH uses Privilege Separation
(which is the default) having the following line in the configuration
file /etc/ssh/sshd_config:

UsePrivilegeSeparation yes

That way the remote daemon will do as few things as possible as the root
user so even if there is a bug in it it will not compromise the chroot.
Notice that, unlike the case in which you setup a per-user chroot, the
ssh daemon is running in the same chroot as the users so there is at
least one potential process running as root which could break out of the
chroot.

Notice, also, that in order for SSH to work in that location, the
partition where the chroot directory resides cannot be mounted with the
nodev option. If you use that option, then you will get the following
error: PRNG is not seeded, because /dev/urandom does not work in the
chroot.

B.7.2.1. Setup a minimal system (the really easy way)

You can use debootstrap to setup a minimal environment that just includes
the ssh server. In order to do this you just have to create a chroot as
described in the
http://www.debian.org/doc/manuals/reference/ch09#_chroot_system document.
This method is bound to work (you will get all the necessary componentes
for the chroot) but at the cost of disk space (a minimal installation of
Debian will amount to several hundred megabytes). This minimal system
might also include setuid files that a user in the chroot could use to
break out of the chroot if any of those could be use for a privilege
escalation.

B.7.2.2. Automatically making the environment (the easy way)

You can easily create a restricted environment with the makejail package,
since it automatically takes care of tracing the server daemon (with
strace), and makes it run under the restricted environment.

The advantage of programs that automatically generate chroot environments
is that they are capable of copying any package to the chroot environment
(even following the package's dependencies and making sure it's
complete). Thus, providing user applications is easier.

To set up the environment using makejail's provided examples, just create
/var/chroot/sshd and use the command:

  # makejail /usr/share/doc/makejail/examples/sshd.py

This will setup the chroot in the /var/chroot/sshd directory. Notice that
this chroot will not fully work unless you:

  * 

    Mount the procfs filesystem in /var/chroot/sshd/proc. Makejail will
    mount it for you but if the system reboots you need to remount it
    running:

    # mount -t proc proc /var/chroot/sshd/proc

    You can also have it be mounted automatically by editing /etc/fstab
    and including this line:

    proc-ssh /var/chroot/sshd/proc  proc none 0 0  

  * 

    Have syslog listen to the device /dev/log inside the chroot. In order
    to do this you have modify /etc/default/syslogd and add -a
    /var/chroot/sshd/dev/log to the SYSLOGD variable definition.

Read the sample file to see what other changes need to be made to the
environment. Some of these changes, such as copying user's home
directories, cannot be done automatically. Also, limit the exposure of
sensitive information by only copying the data from a given number of
users from the files /etc/shadow or /etc/group. Notice that if you are
using Privilege Separation the sshd user needs to exist in those files.

The following sample environment has been (slightly) tested in Debian 3.0
and is built with the configuration file provided in the package and
includes the fileutils package:

.
|-- bin
|   |-- ash
|   |-- bash
|   |-- chgrp
|   |-- chmod
|   |-- chown
|   |-- cp
|   |-- csh -> /etc/alternatives/csh
|   |-- dd
|   |-- df
|   |-- dir
|   |-- fdflush
|   |-- ksh
|   |-- ln
|   |-- ls
|   |-- mkdir
|   |-- mknod
|   |-- mv
|   |-- rbash -> bash
|   |-- rm
|   |-- rmdir
|   |-- sh -> bash
|   |-- sync
|   |-- tcsh
|   |-- touch
|   |-- vdir
|   |-- zsh -> /etc/alternatives/zsh
|   `-- zsh4
|-- dev
|   |-- null
|   |-- ptmx
|   |-- pts
|   |-- ptya0
(...)
|   |-- tty
|   |-- tty0
(...)
|   `-- urandom
|-- etc
|   |-- alternatives
|   |   |-- csh -> /bin/tcsh
|   |   `-- zsh -> /bin/zsh4
|   |-- environment
|   |-- hosts
|   |-- hosts.allow
|   |-- hosts.deny
|   |-- ld.so.conf
|   |-- localtime -> /usr/share/zoneinfo/Europe/Madrid
|   |-- motd
|   |-- nsswitch.conf
|   |-- pam.conf
|   |-- pam.d
|   |   |-- other
|   |   `-- ssh
|   |-- passwd
|   |-- resolv.conf
|   |-- security
|   |   |-- access.conf
|   |   |-- chroot.conf
|   |   |-- group.conf
|   |   |-- limits.conf
|   |   |-- pam_env.conf
|   |   `-- time.conf
|   |-- shadow
|   |-- shells
|   `-- ssh
|       |-- moduli
|       |-- ssh_host_dsa_key
|       |-- ssh_host_dsa_key.pub
|       |-- ssh_host_rsa_key
|       |-- ssh_host_rsa_key.pub
|       `-- sshd_config
|-- home
|   `-- userX
|-- lib
|   |-- ld-2.2.5.so
|   |-- ld-linux.so.2 -> ld-2.2.5.so
|   |-- libc-2.2.5.so
|   |-- libc.so.6 -> libc-2.2.5.so
|   |-- libcap.so.1 -> libcap.so.1.10
|   |-- libcap.so.1.10
|   |-- libcrypt-2.2.5.so
|   |-- libcrypt.so.1 -> libcrypt-2.2.5.so
|   |-- libdl-2.2.5.so
|   |-- libdl.so.2 -> libdl-2.2.5.so
|   |-- libm-2.2.5.so
|   |-- libm.so.6 -> libm-2.2.5.so
|   |-- libncurses.so.5 -> libncurses.so.5.2
|   |-- libncurses.so.5.2
|   |-- libnsl-2.2.5.so
|   |-- libnsl.so.1 -> libnsl-2.2.5.so
|   |-- libnss_compat-2.2.5.so
|   |-- libnss_compat.so.2 -> libnss_compat-2.2.5.so
|   |-- libnss_db-2.2.so
|   |-- libnss_db.so.2 -> libnss_db-2.2.so
|   |-- libnss_dns-2.2.5.so
|   |-- libnss_dns.so.2 -> libnss_dns-2.2.5.so
|   |-- libnss_files-2.2.5.so
|   |-- libnss_files.so.2 -> libnss_files-2.2.5.so
|   |-- libnss_hesiod-2.2.5.so
|   |-- libnss_hesiod.so.2 -> libnss_hesiod-2.2.5.so
|   |-- libnss_nis-2.2.5.so
|   |-- libnss_nis.so.2 -> libnss_nis-2.2.5.so
|   |-- libnss_nisplus-2.2.5.so
|   |-- libnss_nisplus.so.2 -> libnss_nisplus-2.2.5.so
|   |-- libpam.so.0 -> libpam.so.0.72
|   |-- libpam.so.0.72
|   |-- libpthread-0.9.so
|   |-- libpthread.so.0 -> libpthread-0.9.so
|   |-- libresolv-2.2.5.so
|   |-- libresolv.so.2 -> libresolv-2.2.5.so
|   |-- librt-2.2.5.so
|   |-- librt.so.1 -> librt-2.2.5.so
|   |-- libutil-2.2.5.so
|   |-- libutil.so.1 -> libutil-2.2.5.so
|   |-- libwrap.so.0 -> libwrap.so.0.7.6
|   |-- libwrap.so.0.7.6
|   `-- security
|       |-- pam_access.so
|       |-- pam_chroot.so
|       |-- pam_deny.so
|       |-- pam_env.so
|       |-- pam_filter.so
|       |-- pam_ftp.so
|       |-- pam_group.so
|       |-- pam_issue.so
|       |-- pam_lastlog.so
|       |-- pam_limits.so
|       |-- pam_listfile.so
|       |-- pam_mail.so
|       |-- pam_mkhomedir.so
|       |-- pam_motd.so
|       |-- pam_nologin.so
|       |-- pam_permit.so
|       |-- pam_rhosts_auth.so
|       |-- pam_rootok.so
|       |-- pam_securetty.so
|       |-- pam_shells.so
|       |-- pam_stress.so
|       |-- pam_tally.so
|       |-- pam_time.so
|       |-- pam_unix.so
|       |-- pam_unix_acct.so -> pam_unix.so
|       |-- pam_unix_auth.so -> pam_unix.so
|       |-- pam_unix_passwd.so -> pam_unix.so
|       |-- pam_unix_session.so -> pam_unix.so
|       |-- pam_userdb.so
|       |-- pam_warn.so
|       `-- pam_wheel.so
|-- sbin
|   `-- start-stop-daemon
|-- usr
|   |-- bin
|   |   |-- dircolors
|   |   |-- du
|   |   |-- install
|   |   |-- link
|   |   |-- mkfifo
|   |   |-- shred
|   |   |-- touch -> /bin/touch
|   |   `-- unlink
|   |-- lib
|   |   |-- libcrypto.so.0.9.6
|   |   |-- libdb3.so.3 -> libdb3.so.3.0.2
|   |   |-- libdb3.so.3.0.2
|   |   |-- libz.so.1 -> libz.so.1.1.4
|   |   `-- libz.so.1.1.4
|   |-- sbin
|   |   `-- sshd
|   `-- share
|       |-- locale
|       |   `-- es
|       |       |-- LC_MESSAGES
|       |       |   |-- fileutils.mo
|       |       |   |-- libc.mo
|       |       |   `-- sh-utils.mo
|       |       `-- LC_TIME -> LC_MESSAGES
|       `-- zoneinfo
|           `-- Europe
|               `-- Madrid
`-- var
    `-- run
        |-- sshd
        `-- sshd.pid

27 directories, 733 files

For Debian release 3.1 you have to make sure that the environment
includes also the common files for PAM. The following files need to be
copied over to the chroot if makejail did not do it for you:

$ ls /etc/pam.d/common-*
/etc/pam.d/common-account  /etc/pam.d/common-password
/etc/pam.d/common-auth     /etc/pam.d/common-session

B.7.2.3. Manually creating the environment (the hard way)

It is possible to create an environment, using a trial-and-error method,
by monitoring the sshd server traces and log files in order to determine
the necessary files. The following environment, contributed by José Luis
Ledesma, is a sample listing of files in a chroot environment for ssh in
Debian woody (3.0): [84]

.:
total 36
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ./
drwxr-xr-x 11 root root 4096 Jun 3 13:43 ../
drwxr-xr-x 2 root root 4096 Jun 4 12:13 bin/
drwxr-xr-x 2 root root 4096 Jun 4 12:16 dev/
drwxr-xr-x 4 root root 4096 Jun 4 12:35 etc/
drwxr-xr-x 3 root root 4096 Jun 4 12:13 lib/
drwxr-xr-x 2 root root 4096 Jun 4 12:35 sbin/
drwxr-xr-x 2 root root 4096 Jun 4 12:32 tmp/
drwxr-xr-x 2 root root 4096 Jun 4 12:16 usr/
./bin:
total 8368
drwxr-xr-x 2 root root 4096 Jun 4 12:13 ./
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
-rwxr-xr-x 1 root root 109855 Jun 3 13:45 a2p*
-rwxr-xr-x 1 root root 387764 Jun 3 13:45 bash*
-rwxr-xr-x 1 root root 36365 Jun 3 13:45 c2ph*
-rwxr-xr-x 1 root root 20629 Jun 3 13:45 dprofpp*
-rwxr-xr-x 1 root root 6956 Jun 3 13:46 env*
-rwxr-xr-x 1 root root 158116 Jun 3 13:45 fax2ps*
-rwxr-xr-x 1 root root 104008 Jun 3 13:45 faxalter*
-rwxr-xr-x 1 root root 89340 Jun 3 13:45 faxcover*
-rwxr-xr-x 1 root root 441584 Jun 3 13:45 faxmail*
-rwxr-xr-x 1 root root 96036 Jun 3 13:45 faxrm*
-rwxr-xr-x 1 root root 107000 Jun 3 13:45 faxstat*
-rwxr-xr-x 1 root root 77832 Jun 4 11:46 grep*
-rwxr-xr-x 1 root root 19597 Jun 3 13:45 h2ph*
-rwxr-xr-x 1 root root 46979 Jun 3 13:45 h2xs*
-rwxr-xr-x 1 root root 10420 Jun 3 13:46 id*
-rwxr-xr-x 1 root root 4528 Jun 3 13:46 ldd*
-rwxr-xr-x 1 root root 111386 Jun 4 11:46 less*
-r-xr-xr-x 1 root root 26168 Jun 3 13:45 login*
-rwxr-xr-x 1 root root 49164 Jun 3 13:45 ls*
-rwxr-xr-x 1 root root 11600 Jun 3 13:45 mkdir*
-rwxr-xr-x 1 root root 24780 Jun 3 13:45 more*
-rwxr-xr-x 1 root root 154980 Jun 3 13:45 pal2rgb*
-rwxr-xr-x 1 root root 27920 Jun 3 13:46 passwd*
-rwxr-xr-x 1 root root 4241 Jun 3 13:45 pl2pm*
-rwxr-xr-x 1 root root 2350 Jun 3 13:45 pod2html*
-rwxr-xr-x 1 root root 7875 Jun 3 13:45 pod2latex*
-rwxr-xr-x 1 root root 17587 Jun 3 13:45 pod2man*
-rwxr-xr-x 1 root root 6877 Jun 3 13:45 pod2text*
-rwxr-xr-x 1 root root 3300 Jun 3 13:45 pod2usage*
-rwxr-xr-x 1 root root 3341 Jun 3 13:45 podchecker*
-rwxr-xr-x 1 root root 2483 Jun 3 13:45 podselect*
-r-xr-xr-x 1 root root 82412 Jun 4 11:46 ps*
-rwxr-xr-x 1 root root 36365 Jun 3 13:45 pstruct*
-rwxr-xr-x 1 root root 7120 Jun 3 13:45 pwd*
-rwxr-xr-x 1 root root 179884 Jun 3 13:45 rgb2ycbcr*
-rwxr-xr-x 1 root root 20532 Jun 3 13:45 rm*
-rwxr-xr-x 1 root root 6720 Jun 4 10:15 rmdir*
-rwxr-xr-x 1 root root 14705 Jun 3 13:45 s2p*
-rwxr-xr-x 1 root root 28764 Jun 3 13:46 scp*
-rwxr-xr-x 1 root root 385000 Jun 3 13:45 sendfax*
-rwxr-xr-x 1 root root 67548 Jun 3 13:45 sendpage*
-rwxr-xr-x 1 root root 88632 Jun 3 13:46 sftp*
-rwxr-xr-x 1 root root 387764 Jun 3 13:45 sh*
-rws--x--x 1 root root 744500 Jun 3 13:46 slogin*
-rwxr-xr-x 1 root root 14523 Jun 3 13:46 splain*
-rws--x--x 1 root root 744500 Jun 3 13:46 ssh*
-rwxr-xr-x 1 root root 570960 Jun 3 13:46 ssh-add*
-rwxr-xr-x 1 root root 502952 Jun 3 13:46 ssh-agent*
-rwxr-xr-x 1 root root 575740 Jun 3 13:46 ssh-keygen*
-rwxr-xr-x 1 root root 383480 Jun 3 13:46 ssh-keyscan*
-rwxr-xr-x 1 root root 39 Jun 3 13:46 ssh_europa*
-rwxr-xr-x 1 root root 107252 Jun 4 10:14 strace*
-rwxr-xr-x 1 root root 8323 Jun 4 10:14 strace-graph*
-rwxr-xr-x 1 root root 158088 Jun 3 13:46 thumbnail*
-rwxr-xr-x 1 root root 6312 Jun 3 13:46 tty*
-rwxr-xr-x 1 root root 55904 Jun 4 11:46 useradd*
-rwxr-xr-x 1 root root 585656 Jun 4 11:47 vi*
-rwxr-xr-x 1 root root 6444 Jun 4 11:45 whoami*
./dev:
total 8
drwxr-xr-x 2 root root 4096 Jun 4 12:16 ./
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
crw-r--r-- 1 root root 1, 9 Jun 3 13:43 urandom
./etc:
total 208
drwxr-xr-x 4 root root 4096 Jun 4 12:35 ./
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
-rw------- 1 root root 0 Jun 4 11:46 .pwd.lock
-rw-r--r-- 1 root root 653 Jun 3 13:46 group
-rw-r--r-- 1 root root 242 Jun 4 11:33 host.conf
-rw-r--r-- 1 root root 857 Jun 4 12:04 hosts
-rw-r--r-- 1 root root 1050 Jun 4 11:29 ld.so.cache
-rw-r--r-- 1 root root 304 Jun 4 11:28 ld.so.conf
-rw-r--r-- 1 root root 235 Jun 4 11:27 ld.so.conf~
-rw-r--r-- 1 root root 88039 Jun 3 13:46 moduli
-rw-r--r-- 1 root root 1342 Jun 4 11:34 nsswitch.conf
drwxr-xr-x 2 root root 4096 Jun 4 12:02 pam.d/
-rw-r--r-- 1 root root 28 Jun 4 12:00 pam_smb.conf
-rw-r--r-- 1 root root 2520 Jun 4 11:57 passwd
-rw-r--r-- 1 root root 7228 Jun 3 13:48 profile
-rw-r--r-- 1 root root 1339 Jun 4 11:33 protocols
-rw-r--r-- 1 root root 274 Jun 4 11:44 resolv.conf
drwxr-xr-x 2 root root 4096 Jun 3 13:43 security/
-rw-r----- 1 root root 1178 Jun 4 11:51 shadow
-rw------- 1 root root 80 Jun 4 11:45 shadow-
-rw-r----- 1 root root 1178 Jun 4 11:48 shadow.old
-rw-r--r-- 1 root root 161 Jun 3 13:46 shells
-rw-r--r-- 1 root root 1144 Jun 3 13:46 ssh_config
-rw------- 1 root root 668 Jun 3 13:46 ssh_host_dsa_key
-rw-r--r-- 1 root root 602 Jun 3 13:46 ssh_host_dsa_key.pub
-rw------- 1 root root 527 Jun 3 13:46 ssh_host_key
-rw-r--r-- 1 root root 331 Jun 3 13:46 ssh_host_key.pub
-rw------- 1 root root 883 Jun 3 13:46 ssh_host_rsa_key
-rw-r--r-- 1 root root 222 Jun 3 13:46 ssh_host_rsa_key.pub
-rw-r--r-- 1 root root 2471 Jun 4 12:15 sshd_config
./etc/pam.d:
total 24
drwxr-xr-x 2 root root 4096 Jun 4 12:02 ./
drwxr-xr-x 4 root root 4096 Jun 4 12:35 ../
lrwxrwxrwx 1 root root 4 Jun 4 12:02 other -> sshd
-rw-r--r-- 1 root root 318 Jun 3 13:46 passwd
-rw-r--r-- 1 root root 546 Jun 4 11:36 ssh
-rw-r--r-- 1 root root 479 Jun 4 12:02 sshd
-rw-r--r-- 1 root root 370 Jun 3 13:46 su
./etc/security:
total 32
drwxr-xr-x 2 root root 4096 Jun 3 13:43 ./
drwxr-xr-x 4 root root 4096 Jun 4 12:35 ../
-rw-r--r-- 1 root root 1971 Jun 3 13:46 access.conf
-rw-r--r-- 1 root root 184 Jun 3 13:46 chroot.conf
-rw-r--r-- 1 root root 2145 Jun 3 13:46 group.conf
-rw-r--r-- 1 root root 1356 Jun 3 13:46 limits.conf
-rw-r--r-- 1 root root 2858 Jun 3 13:46 pam_env.conf
-rw-r--r-- 1 root root 2154 Jun 3 13:46 time.conf
./lib:
total 8316
drwxr-xr-x 3 root root 4096 Jun 4 12:13 ./
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
-rw-r--r-- 1 root root 1024 Jun 4 11:51 cracklib_dict.hwm
-rw-r--r-- 1 root root 214324 Jun 4 11:51 cracklib_dict.pwd
-rw-r--r-- 1 root root 11360 Jun 4 11:51 cracklib_dict.pwi
-rwxr-xr-x 1 root root 342427 Jun 3 13:46 ld-linux.so.2*
-rwxr-xr-x 1 root root 4061504 Jun 3 13:46 libc.so.6*
lrwxrwxrwx 1 root root 15 Jun 4 12:11 libcrack.so -> libcrack.so.2.7*
lrwxrwxrwx 1 root root 15 Jun 4 12:11 libcrack.so.2 -> libcrack.so.2.7*
-rwxr-xr-x 1 root root 33291 Jun 4 11:39 libcrack.so.2.7*
-rwxr-xr-x 1 root root 60988 Jun 3 13:46 libcrypt.so.1*
-rwxr-xr-x 1 root root 71846 Jun 3 13:46 libdl.so.2*
-rwxr-xr-x 1 root root 27762 Jun 3 13:46 libhistory.so.4.0*
lrwxrwxrwx 1 root root 17 Jun 4 12:12 libncurses.so.4 -> libncurses.so.4.2*
-rwxr-xr-x 1 root root 503903 Jun 3 13:46 libncurses.so.4.2*
lrwxrwxrwx 1 root root 17 Jun 4 12:12 libncurses.so.5 -> libncurses.so.5.0*
-rwxr-xr-x 1 root root 549429 Jun 3 13:46 libncurses.so.5.0*
-rwxr-xr-x 1 root root 369801 Jun 3 13:46 libnsl.so.1*
-rwxr-xr-x 1 root root 142563 Jun 4 11:49 libnss_compat.so.1*
-rwxr-xr-x 1 root root 215569 Jun 4 11:49 libnss_compat.so.2*
-rwxr-xr-x 1 root root 61648 Jun 4 11:34 libnss_dns.so.1*
-rwxr-xr-x 1 root root 63453 Jun 4 11:34 libnss_dns.so.2*
-rwxr-xr-x 1 root root 63782 Jun 4 11:34 libnss_dns6.so.2*
-rwxr-xr-x 1 root root 205715 Jun 3 13:46 libnss_files.so.1*
-rwxr-xr-x 1 root root 235932 Jun 3 13:49 libnss_files.so.2*
-rwxr-xr-x 1 root root 204383 Jun 4 11:33 libnss_nis.so.1*
-rwxr-xr-x 1 root root 254023 Jun 4 11:33 libnss_nis.so.2*
-rwxr-xr-x 1 root root 256465 Jun 4 11:33 libnss_nisplus.so.2*
lrwxrwxrwx 1 root root 14 Jun 4 12:12 libpam.so.0 -> libpam.so.0.72*
-rwxr-xr-x 1 root root 31449 Jun 3 13:46 libpam.so.0.72*
lrwxrwxrwx 1 root root 19 Jun 4 12:12 libpam_misc.so.0 ->
libpam_misc.so.0.72*
-rwxr-xr-x 1 root root 8125 Jun 3 13:46 libpam_misc.so.0.72*
lrwxrwxrwx 1 root root 15 Jun 4 12:12 libpamc.so.0 -> libpamc.so.0.72*
-rwxr-xr-x 1 root root 10499 Jun 3 13:46 libpamc.so.0.72*
-rwxr-xr-x 1 root root 176427 Jun 3 13:46 libreadline.so.4.0*
-rwxr-xr-x 1 root root 44729 Jun 3 13:46 libutil.so.1*
-rwxr-xr-x 1 root root 70254 Jun 3 13:46 libz.a*
lrwxrwxrwx 1 root root 13 Jun 4 12:13 libz.so -> libz.so.1.1.3*
lrwxrwxrwx 1 root root 13 Jun 4 12:13 libz.so.1 -> libz.so.1.1.3*
-rwxr-xr-x 1 root root 63312 Jun 3 13:46 libz.so.1.1.3*
drwxr-xr-x 2 root root 4096 Jun 4 12:00 security/
./lib/security:
total 668
drwxr-xr-x 2 root root 4096 Jun 4 12:00 ./
drwxr-xr-x 3 root root 4096 Jun 4 12:13 ../
-rwxr-xr-x 1 root root 10067 Jun 3 13:46 pam_access.so*
-rwxr-xr-x 1 root root 8300 Jun 3 13:46 pam_chroot.so*
-rwxr-xr-x 1 root root 14397 Jun 3 13:46 pam_cracklib.so*
-rwxr-xr-x 1 root root 5082 Jun 3 13:46 pam_deny.so*
-rwxr-xr-x 1 root root 13153 Jun 3 13:46 pam_env.so*
-rwxr-xr-x 1 root root 13371 Jun 3 13:46 pam_filter.so*
-rwxr-xr-x 1 root root 7957 Jun 3 13:46 pam_ftp.so*
-rwxr-xr-x 1 root root 12771 Jun 3 13:46 pam_group.so*
-rwxr-xr-x 1 root root 10174 Jun 3 13:46 pam_issue.so*
-rwxr-xr-x 1 root root 9774 Jun 3 13:46 pam_lastlog.so*
-rwxr-xr-x 1 root root 13591 Jun 3 13:46 pam_limits.so*
-rwxr-xr-x 1 root root 11268 Jun 3 13:46 pam_listfile.so*
-rwxr-xr-x 1 root root 11182 Jun 3 13:46 pam_mail.so*
-rwxr-xr-x 1 root root 5923 Jun 3 13:46 pam_nologin.so*
-rwxr-xr-x 1 root root 5460 Jun 3 13:46 pam_permit.so*
-rwxr-xr-x 1 root root 18226 Jun 3 13:46 pam_pwcheck.so*
-rwxr-xr-x 1 root root 12590 Jun 3 13:46 pam_rhosts_auth.so*
-rwxr-xr-x 1 root root 5551 Jun 3 13:46 pam_rootok.so*
-rwxr-xr-x 1 root root 7239 Jun 3 13:46 pam_securetty.so*
-rwxr-xr-x 1 root root 6551 Jun 3 13:46 pam_shells.so*
-rwxr-xr-x 1 root root 55925 Jun 4 12:00 pam_smb_auth.so*
-rwxr-xr-x 1 root root 12678 Jun 3 13:46 pam_stress.so*
-rwxr-xr-x 1 root root 11170 Jun 3 13:46 pam_tally.so*
-rwxr-xr-x 1 root root 11124 Jun 3 13:46 pam_time.so*
-rwxr-xr-x 1 root root 45703 Jun 3 13:46 pam_unix.so*
-rwxr-xr-x 1 root root 45703 Jun 3 13:46 pam_unix2.so*
-rwxr-xr-x 1 root root 45386 Jun 3 13:46 pam_unix_acct.so*
-rwxr-xr-x 1 root root 45386 Jun 3 13:46 pam_unix_auth.so*
-rwxr-xr-x 1 root root 45386 Jun 3 13:46 pam_unix_passwd.so*
-rwxr-xr-x 1 root root 45386 Jun 3 13:46 pam_unix_session.so*
-rwxr-xr-x 1 root root 9726 Jun 3 13:46 pam_userdb.so*
-rwxr-xr-x 1 root root 6424 Jun 3 13:46 pam_warn.so*
-rwxr-xr-x 1 root root 7460 Jun 3 13:46 pam_wheel.so*
./sbin:
total 3132
drwxr-xr-x 2 root root 4096 Jun 4 12:35 ./
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
-rwxr-xr-x 1 root root 178256 Jun 3 13:46 choptest*
-rwxr-xr-x 1 root root 184032 Jun 3 13:46 cqtest*
-rwxr-xr-x 1 root root 81096 Jun 3 13:46 dialtest*
-rwxr-xr-x 1 root root 1142128 Jun 4 11:28 ldconfig*
-rwxr-xr-x 1 root root 2868 Jun 3 13:46 lockname*
-rwxr-xr-x 1 root root 3340 Jun 3 13:46 ondelay*
-rwxr-xr-x 1 root root 376796 Jun 3 13:46 pagesend*
-rwxr-xr-x 1 root root 13950 Jun 3 13:46 probemodem*
-rwxr-xr-x 1 root root 9234 Jun 3 13:46 recvstats*
-rwxr-xr-x 1 root root 64480 Jun 3 13:46 sftp-server*
-rwxr-xr-x 1 root root 744412 Jun 3 13:46 sshd*
-rwxr-xr-x 1 root root 30750 Jun 4 11:46 su*
-rwxr-xr-x 1 root root 194632 Jun 3 13:46 tagtest*
-rwxr-xr-x 1 root root 69892 Jun 3 13:46 tsitest*
-rwxr-xr-x 1 root root 43792 Jun 3 13:46 typetest*
./tmp:
total 8
drwxr-xr-x 2 root root 4096 Jun 4 12:32 ./
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
./usr:
total 8
drwxr-xr-x 2 root root 4096 Jun 4 12:16 ./
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
lrwxrwxrwx 1 root root 7 Jun 4 12:14 bin -> ../bin//
lrwxrwxrwx 1 root root 7 Jun 4 11:33 lib -> ../lib//
lrwxrwxrwx 1 root root 8 Jun 4 12:13 sbin -> ../sbin//


B.7.3. Chroot environment for Apache

B.7.3.1. まえがき

The chroot utility is often used to jail a daemon in a restricted tree.
You can use it to insulate services from one another, so that security
issues in a software package do not jeopardize the whole server. When
using the makejail script, setting up and updating the chrooted tree is
much easier.

FIXME: Apache can also be chrooted using http://www.modsecurity.org which
is available in libapache-mod-security (for Apache 1.x) and
libapache2-mod-security (for Apache 2.x).

B.7.3.1.1. Licensing

This document is copyright 2002 Alexandre Ratti. It has been
dual-licensed and released under the GPL version 2 (GNU General Public
License) the GNU-FDL 1.2 (GNU Free Documentation Licence) and is included
in this manual with his explicit permission.

B.7.3.2. Installing the server

This procedure was tested on Debian GNU/Linux 3.0 (Woody) with makejail
0.0.4-1 (in Debian/testing).

  * 

    Log in as root and create a new jail directory:

    $ mkdir -p /var/chroot/apache  

  * 

    Create a new user and a new group. The chrooted Apache server will
    run as this user/group, which isn't used for anything else on the
    system. In this example, both user and group are called chrapach.

     
     $ adduser --home /var/chroot/apache --shell /bin/false \
     --no-create-home --system --group chrapach

    FIXME: is a new user needed? (Apache already runs as the apache user)

  * 

    Install Apache as usual on Debian: apt-get install apache

  * 

    Set up Apache (e.g. define your subdomains, etc.). In the
    /etc/apache/httpd.conf configuration file, set the Group and User
    options to chrapach. Restart Apache and make sure the server is
    working correctly. Now, stop the Apache daemon.

  * 

    Install makejail (available in Debian/testing for now). You should
    also install wget and lynx as they will be used by makejail to test
    the chrooted server: apt-get install makejail wget lynx

  * 

    Copy the sample configuration file for Apache to the /etc/makejail
    directory:

     
     # cp /usr/share/doc/makejail/examples/apache.py /etc/makejail/   

  * 

    Edit /etc/makejail/apache.py. You need to change the chroot, users
    and groups options. To run this version of makejail, you can also add
    a packages option. See the http://www.floc.net/makejail/current/doc/.
    A sample is shown here:

    chroot="/var/chroot/apache"
    testCommandsInsideJail=["/usr/sbin/apachectl start"]
    processNames=["apache"]
    testCommandsOutsideJail=["wget -r --spider http://localhost/",
                             "lynx --source https://localhost/"]
    preserve=["/var/www",
              "/var/log/apache",
              "/dev/log"]
    users=["chrapach"]
    groups=["chrapach"]
    packages=["apache", "apache-common"]
    userFiles=["/etc/password",
               "/etc/shadow"]
    groupFiles=["/etc/group",
                "/etc/gshadow"]
    forceCopy=["/etc/hosts",
               "/etc/mime.types"]

    FIXME: some options do not seem to work properly. For instance,
    /etc/shadow and /etc/gshadow are not copied, whereas /etc/password
    and /etc/group are fully copied instead of being filtered.

  * 

    Create the chroot tree: makejail /etc/makejail/apache.py

  * 

    If /etc/password and /etc/group were fully copied, type:

          $ grep chrapach /etc/passwd > /var/chroot/apache/etc/passwd
          $ grep chrapach /etc/group > /var/chroot/apache/etc/group

    to replace them with filtered copies.

  * 

    Copy the Web site pages and the logs into the jail. These files are
    not copied automatically (see the preserve option in makejail's
    configuration file).

          # cp -Rp /var/www /var/chroot/apache/var
          # cp -Rp /var/log/apache/*.log /var/chroot/apache/var/log/apache  

  * 

    Edit the startup script for the system logging daemon so that it also
    listen to the /var/chroot/apache/dev/log socket. In
    /etc/default/syslogd, replace: SYSLOGD="" with SYSLOGD=" -a
    /var/chroot/apache/dev/log" and restart the daemon (/etc/init.d/sysklogd
    restart).

  * 

    Edit the Apache startup script (/etc/init.d/apache). You might need
    to make some changes to the default startup script for it to run
    properly with a chrooted tree. Such as:

      * 

        set a new CHRDIR variable at the top of the file;

      * 

        edit the start, stop, reload, etc. sections;

      * 

        add a line to mount and unmount the /proc filesystem within the
        jail.

    #! /bin/bash
    #
    # apache        Start the apache HTTP server.
    #
    
    CHRDIR=/var/chroot/apache
    
    NAME=apache
    PATH=/bin:/usr/bin:/sbin:/usr/sbin
    DAEMON=/usr/sbin/apache
    SUEXEC=/usr/lib/apache/suexec
    PIDFILE=/var/run/$NAME.pid
    CONF=/etc/apache/httpd.conf
    APACHECTL=/usr/sbin/apachectl 
    
    trap "" 1
    export LANG=C
    export PATH
    
    test -f $DAEMON || exit 0
    test -f $APACHECTL || exit 0
    
    # ensure we don't leak environment vars into apachectl
    APACHECTL="env -i LANG=${LANG} PATH=${PATH} chroot $CHRDIR $APACHECTL"
    
    if egrep -q -i "^[[:space:]]*ServerType[[:space:]]+inet" $CONF
    then
        exit 0
    fi
    
    case "$1" in
      start)
        echo -n "Starting web server: $NAME"
        mount -t proc proc /var/chroot/apache/proc
        start-stop-daemon --start --pidfile $PIDFILE --exec $DAEMON \
          --chroot $CHRDIR
        ;;
    
      stop)
        echo -n "Stopping web server: $NAME"
        start-stop-daemon --stop --pidfile "$CHRDIR/$PIDFILE" --oknodo
        umount /var/chroot/apache/proc
        ;;
    
      reload)
        echo -n "Reloading $NAME configuration"
        start-stop-daemon --stop --pidfile "$CHRDIR/$PIDFILE" \
          --signal USR1 --startas $DAEMON --chroot $CHRDIR
        ;;
    
      reload-modules)
        echo -n "Reloading $NAME modules"
        start-stop-daemon --stop --pidfile "$CHRDIR/$PIDFILE" --oknodo \
          --retry 30
        start-stop-daemon --start --pidfile $PIDFILE \
          --exec $DAEMON --chroot $CHRDIR
        ;;
    
      restart)
        $0 reload-modules
        exit $?
        ;;
    
      force-reload)
        $0 reload-modules
        exit $?
        ;;
    
      *)
        echo "Usage: /etc/init.d/$NAME {start|stop|reload|reload-modules|force-reload|restart}"
        exit 1
        ;;
    esac
    
    if [ $? == 0 ]; then
      echo .
      exit 0
    else
      echo failed
      exit 1
    fi

    FIXME: should the first Apache process be run as another user than
    root (i.e. add --chuid chrapach:chrapach)? Cons: chrapach will need
    write access to the logs, which is awkward.

  * 

    Replace in /etc/logrotate.d/apache/var/log/apache/*.log with
    /var/chroot/apache/var/log/apache/*.log

  * 

    Start Apache (/etc/init.d/apache start) and check what is it reported
    in the jail log (/var/chroot/apache/var/log/apache/error.log). If
    your setup is more complex, (e.g. if you also use PHP and MySQL),
    files will probably be missing. if some files are not copied
    automatically by makejail, you can list them in the forceCopy (to
    copy files directly) or packages (to copy full packages and their
    dependencies) option the /etc/makejail/apache.py configuration file.

  * 

    Type ps aux | grep apache to make sure Apache is running. You should
    see something like:

          root 180 0.0 1.1 2936 1436 ? S 04:03 0:00 /usr/sbin/apache
          chrapach 189 0.0 1.1 2960 1456 ? S 04:03 0:00 /usr/sbin/apache
          chrapach 190 0.0 1.1 2960 1456 ? S 04:03 0:00 /usr/sbin/apache
          chrapach 191 0.0 1.1 2960 1456 ? S 04:03 0:00 /usr/sbin/apache
          chrapach 192 0.0 1.1 2960 1456 ? S 04:03 0:00 /usr/sbin/apache
          chrapach 193 0.0 1.1 2960 1456 ? S 04:03 0:00 /usr/sbin/apache  

  * 

    Make sure the Apache processes are running chrooted by looking in the
    /proc filesystem: ls -la /proc/process_number/root/. where
    process_number is one of the PID numbers listed above (2nd column;
    189 for instance). The entries for a restricted tree should be
    listed:

        drwxr-sr-x 10 root staff 240 Dec 2 16:06 .
        drwxrwsr-x 4 root staff 72 Dec 2 08:07 ..
        drwxr-xr-x 2 root root 144 Dec 2 16:05 bin
        drwxr-xr-x 2 root root 120 Dec 3 04:03 dev
        drwxr-xr-x 5 root root 408 Dec 3 04:03 etc
        drwxr-xr-x 2 root root 800 Dec 2 16:06 lib
        dr-xr-xr-x 43 root root 0 Dec 3 05:03 proc
        drwxr-xr-x 2 root root 48 Dec 2 16:06 sbin
        drwxr-xr-x 6 root root 144 Dec 2 16:04 usr
        drwxr-xr-x 7 root root 168 Dec 2 16:06 var

    To automate this test, you can type:ls -la /proc/`cat
    /var/chroot/apache/var/run/apache.pid`/root/.

    FIXME: Add other tests that can be run to make sure the jail is
    closed?

The reason I like this is because setting up the jail is not very
difficult and the server can be updated in just two lines:

 
apt-get update && apt-get install apache
makejail /etc/makejail/apache.py


B.7.4. See also

If you are looking for more information you can consider these sources of
information in which the information presented is based:
http://www.floc.net/makejail/, this program was written by Alain Tesio


------------------------------------------------------------------------

[76] Typically the needed packages will be installed through the
dependencies

[77] It can also be downloaded from http://www.cert.org/kb/acid/,
http://acidlab.sourceforge.net or
http://www.andrew.cmu.edu/~rdanyliw/snort/.

[78] Since version 9.2.1-5. That is, since Debian release sarge.

[79] Such as knockd. Alternatively, you can open a different console and
have the system ask for confirmation that there is somebody on the other
side, and reset the firewall chain if no confirmation is given. The
following test script could be of use:

#!/bin/bash

while true; do
    read -n 1 -p "Are you there? " -t 30 ayt
    if [ -z "$ayt" ] ; then
        break
    fi
done

# Reset the firewall chain, user is not available
echo
echo "Resetting firewall chain!"
iptables -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
exit 1

[80] You can use the debug option to have it send the progress of the
module to the authpriv.notice facility

[81] You can create a very limited bash environment with the following
python definition for makejail, just create the directory
/var/chroots/users/foo and a file with the following contents and call it
bash.py:

chroot="/var/chroots/users/foo"
cleanJailFirst=1
testCommandsInsideJail=["bash ls"]

And then run makejail bash.py to create the user environment at
/var/chroots/users/foo. To test the environment run:

# chroot /var/chroots/users/foo/ ls
bin  dev  etc  lib  proc  sbin  usr

[82] In some occasions you might need the /dev/ptmx and /dev/pty* devices
and the /dev/pts/ subdirectory. Running MAKEDEV in the /dev directory of
the chrooted environment should be sufficient to create them if they do
not exist. If you are using kernels (version 2.6) which dynamically
create device files you will need to create the /dev/pts/ files yourself
and grant them the proper privileges.

[83] If you are using a kernel that implements Mandatory Access Control
(RSBAC/SElinux) you can avoid changing this configuration just by
granting the sshd user privileges to make the chroot() system call.

[84] Notice that there are no SETUID files. This makes it more difficult
for remote users to escape the chroot environment. However, it also
prevents users from changing their passwords, since the passwd program
cannot modify the files /etc/passwd or /etc/shadow.