<!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V3.1//EN" 
[<!entity % redhat "IGNORE"> <!entity % linuxall "INCLUDE">]
>

<!--

Note that this doc can build either a generic Linux version (linuxall), or a
slightly modified Redhat specific version (redhat) by toggling the 'entity' in
the DTD header. The below (poor) Makefile will build both versions with 
'make all'

###########################################################################
# Half-ass Makefile for the Security-Quickstart HOWTO
#
# This builds txt and html versions of this doc for either
# the generic version, the Redhat version, or both (make all).
#
BASE = Security-Quickstart
DIR = QUICKSTART
TMP_DIR = _makefile.tmp
TMP_SGML = _tmp.sgml
TEXT = _tmp.txt
RH = Redhat

## targets 

all: redhat linuxall

redhat:
	perl -pe 's/\[<!entity.*/[<!entity % redhat "INCLUDE"> <!entity % linuxall "IGNORE">]/'  $(BASE).sgml >\
	 $(TMP_SGML)
	[ -d $(DIR)-$(RH) ] && rm -fr $(DIR)-$(RH) || true
	mkdir -p $(DIR)-$(RH) $(TMP_DIR) && mv *.html $(TMP_DIR) || true
	jade -t sgml -ihtml -d /usr/lib/sgml/stylesheets/ldp.dsl\#html $(TMP_SGML) ||\
  	  ( mv -f $(TMP_DIR)/*.html . && rm -rf $(TMP_DIR) $(TMP_SGML) && false)
	mv -f *.html $(DIR)-$(RH)
	mv -f $(TMP_DIR)/*.html . || true
	make txt && mv -f $(TEXT).gz $(BASE)-$(RH).txt.gz
	rm -rf $(TMP_DIR) $(TMP_SGML)

linuxall:
	perl -pe 's/\[<!entity.*/[<!entity % redhat "IGNORE"> <!entity % linuxall "INCLUDE">]/'  $(BASE).sgml >\
	 $(TMP_SGML)
	[ -d $(DIR) ] && rm -fr $(DIR) || true
	mkdir -p $(DIR) $(TMP_DIR) && mv -f *.html $(TMP_DIR) || true
	jade -t sgml -ihtml -d /usr/lib/sgml/stylesheets/ldp.dsl\#html $(TMP_SGML) ||\
	  ( mv -f $(TMP_DIR)/*.html . && rm -rf $(TMP_DIR) $(TMP_SGML) && false)
	mv -f *.html $(DIR)
	mv -f $(TMP_DIR)/*.html . || true
	make txt && mv -f $(TEXT).gz $(BASE).txt.gz
	rm -rf $(TMP_DIR) $(TMP_SGML)

# This is called by Redhat and linuxall...do not invoke directly.
txt:
	jade -t sgml -i html -d /usr/lib/sgml/stylesheets/ldp.dsl\#html -V nochunks $(TMP_SGML) >\
 	  _$(TEXT).html 
	lynx -dump _$(TEXT).html > $(TEXT) && gzip -f $(TEXT) && rm -f _$(TEXT).html

clean:
	rm -rf $(TMP_DIR) $(TMP_SGML) $(DIR)* *~

## eof #############################################################

Hal Burgiss 09/30/01

-->

<article id="index">

<artheader>

<title>Security Quick-Start HOWTO for <![%redhat;[ Red Hat ]]> Linux</title>

<pubdate>v. 1.2, 2002-07-21</pubdate>

<authorgroup>
 <author>
  <firstname>Hal</firstname>
  <surname>Burgiss</surname>
   <affiliation>
    <address>
     <email>hal@foobox.net</email>
    </address>
   </affiliation>
 </author>
</authorgroup>

<!-- Added for Japanese version -->
  <othercredit lang="ja">
    <firstname>原 啓介</firstname>
    <surname></surname>
    <contrib>日本語訳</contrib>
    <affiliation>
      <address>kahara@mars.dti.ne.jp</address>
    </affiliation>
</othercredit>

<revhistory>
  <revision>
    <revnumber>v. 1.2</revnumber>
     <date>2002-07-21</date>
     <authorinitials>hb</authorinitials>
      <revremark>
        A few small additions, and fix the usual broken links.
      </revremark>
    </revision>

  <revision>
    <revnumber>v. 1.1</revnumber>
     <date>2002-02-06</date>
     <authorinitials>hb</authorinitials>
      <revremark>
        A few fixes, some additions and many touch-ups from the original.
      </revremark>
    </revision>

  <revision>
    <revnumber>v. 1.0</revnumber>
     <date>2001-11-07</date>
     <authorinitials>hb</authorinitials>
      <revremark>
        Initial Release.
      </revremark>
    </revision>
</revhistory>

<keywordset>
 <keyword>Secure</keyword>
 <keyword>Security</keyword>
 <keyword>Services</keyword>
 <keyword>Firewall</keyword>
 <keyword>Intrusion</keyword>
 <keyword>Hacker</keyword>
 <keyword>Hacked</keyword>
 <keyword>Cracker</keyword>
 <keyword>Cracked</keyword>
 <keyword>owned</keyword>
 <keyword>Firewall</keyword>
 <keyword>ipchains</keyword>
 <keyword>iptables</keyword>
 <keyword>tcpwrappers</keyword>
 <keyword>portsentry</keyword>
 <keyword>virus</keyword>
 <keyword>trojan</keyword>
</keywordset>

<abstract>

<![%redhat;[
<para>
 <comment>
  This is here to keep vim syntax file from breaking :/
  If I knew enough to fix it, I would.
  DO NOT REMOVE!
 </comment>
</para>
]]>


<para>
 <comment>

 $cvs  get LDP/howto/docbook/Security-Quickstart-HOWTO.sgml

 upload...
 $ cvs commit Security-Quickstart-HOWTO.sgml      !!!!!!!!!!!!!!!!
 (from the LDP/howto/docbook/ dir)

 check here: http://cvs.pld.org.pl/LDP/howto/docbook/Security-Quickstart-HOWTO.sgml


 aspell -H -c Security-Quickstart.sgml
 ldp-review@lupercalia.org
 submit@tldp.org
 http://feenix.burgiss.net/ldp/quickstart/Security-Quickstart.sgml.gz


====================================================================
v1.2pre
 CHANGES
  Minor changes to Have I Been Hacked
  Explicit path for ipchains and iptables (missed in first set of scripts)
  Further note on what is being protected by scripts.
  Add note on ZA type apps in General questions.
  More on chattr, and Bill S's tip for checking immutables.
  MySQL server port added.

 TODO


Submitted v1.1 Wed 02/06/02 07:44:50 PM
 CHANGES
  Various minor corrections per Bill S.  11/12/01
  Fixed Redhat typos. RED HAT, doh!
  rpcinfo blurb.
  A few additional credits.
  Added  suggestions from Jacco de Leeuw (jacco2@dds.nl)
    for smb.conf, cupsd.conf and xdm/inittab.
  chattr mentioned per Bill S.           11/21/01
  Re-check with netstat after updating packages.
  Other doc formats referenced at ldp.org
  Small blurb on tcpwrappers.            12/02/01
  Added note on Bastille/Debian
  A little more on passwords
  rc.inet2 on Slack                      12/17/01
  re-did blacklist in scripts
  cat /proc/*/stat |awk '{print $1,$2}' (PIDs and names)
  ports 1-19, 6010 added to port info section
  note on scripts presented as examples  12/29/01
  Additional explanation on RPC services re: portmap 01/06/02
  Added Remote X Apps HOWTO to links.
  iptables mini-me                       01/27/02
  nmap/udp
  Run servers on non-standard ports 2x
  principles to guide us by (intro)
  note on DSL and cable staying updated! 02/01/02
  fixed netfilter URLs (changed)
  logcheck is now logsentry              02/01/02
  02/06/02 -- end 1.1
  
 
 TODO
  There is no one single thing that constitutes good security....
  ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0.2.txt
  http://www.linuxsecurity.com/feature_stories/kernel-24-security.html
  http://www.cert.org/tech_tips/AUSCERT_checklist2.0.html
 


Version 1.0 submitted 11-7-01

11/01/01 - seawall and shorewall added to Links.
           A few minor changes.


Begin .99 07/10/01

TODO
ls -l /proc/31873/exe (command that started process).

for x in `ls /proc | grep '^[0-9]*$'`; do cat /proc/$x/cmdline; echo; done

perl -pe '' /etc/passwd
perl -pe '' /etc/shadow


 </comment>
</para>

<para>
<!--
 This document is a an overview of the basic steps required to 
 secure a Linux installation from intrusion. It is intended to be an
 introduction. <![%redhat;[ This is a Red Hat specific version of this
 document. ]]>
-->
この文書は Linux を侵入者から守るための基本的なステップを説明するものです。
特にその最初の手引きになることを目指しています。
<![%redhat;[これはこの文書の Redhat 個別版です。]]>

</para>

</abstract>
</artheader>

<!--  ~  End section  ~  -->



<!--   ~~~~~~~~       New section Header    ~~~~~~~~~     -->

<sect1 id="intro">
<title>Introduction</title>

<!--   ~~~~~       New section      ~~~~~     -->
<sect2>
<title><!--Why me?-->どうして私が？</title>
<para>
<!--
 Who should be reading this document and why should the average Linux user
 care about security? Those new to Linux, or unfamiliar with the inherent
 security issues of connecting a Linux system to large networks like Internet
 should be reading. <Quote>Security</Quote> is a broad subject with many
 facets, and is covered in much more depth in other documents, books, and on
 various sites on the Web. This document is intended to be an introduction to
 the most basic concepts as they relate to <![%redhat;[Red Hat]]> Linux, and as
 a starting point only. 
-->
  この文書を読んだ方が良いのはどんな人でしょうか。
そして、ごく普通の Linux ユーザーも、
セキュリティの問題を気にかけておいた方が良いのは何故でしょうか。
まだ Linux 初心者だったり、
Linux システムをインターネットのような大きなネットワークに
繋げる時の基本的なセキュリティの問題に慣れていない人に、
この文書を読んでもらいたいと思っています。
<Quote>セキュリティ</Quote>の問題はたくさんの側面を持つ幅広い課題であり、
他の文書、本やウェッブのいろいろなサイトにあるものなどでは、
はるかに詳細に広くこの問題を扱っています。
一方、この文書は <![%redhat;[Redhat]]> Linux に関係する
その最も基本的な概念を手ほどきするもので、
ほんの最初の一歩に過ぎません。

</para>

<Para>
 <Literal>
  <MSGText> 
   <LiteralLayout>
<!--
Iptables Weekly Log Summary from Jul 15 04:24:13 to Jul 22 04:06:00
Blocked Connection Attempts:
-->
  Jul 15 04:24:13 から Jul 22 04:06:00間のiptables週間ログ報告
ブロックされた接続試行：

<!--
Rejected tcp packets by destination port
-->
目的ポートに拒否された tcp パケット

port                 count
111                  19
53                   12
21                   9
515                  9
27374                8
443                  6
1080                 2
1138                 1

<!--
Rejected udp packets by destination port
-->
目的ポートに拒否された udp パケット

port                 count
137                  34
22                   1

    </LiteralLayout>
  </MSGText>
 </Literal>
</Para>

<para>
<!--
 The above is real, live data from a one week period for my home LAN.
 Much of the above would seem to be specifically targeted at Linux systems.
 Many of the targeted <quote>destination</quote> ports are used by well known
 Linux and Unix services, and all may be installed, and possibly
 even running, on your system. 
-->
  上の表は現実のもので、ある一週間の我が家のLAN の、
まさに今ログにあらわれているデータです。
上の多くは特に Linux システムをターゲットにしたもののようです。
標的にされた<quote>目的</quote>ポートの多くは
よく知られている Linux や Unix のサーヴィスで用いられているものだし、
あなたのシステムではその全部がインストールされているかも知れず、
それどころかその全部が動いてさえいるかも知れません。

</para>
 
<para>
<!--
 The focus here will be on threats that are shared by all Linux users, whether
 a dual boot home user, or large commercial site. And we will take a few,
 relatively quick and easy steps that will make a typical home Desktop system
 or small office system running <![%redhat;[Red Hat]]> Linux reasonably safe
 from the majority of outside threats. For those responsible for Linux systems
 in a larger or more complex environment, you'd be well advised to read this,
 and then follow up with additional reading suitable to your particular
 situation. Actually, this is probably good advice for everybody.
-->
ここでの焦点は全ての Linux ユーザー、つまり、
デュアルブートのホームユーザーにも、
大きな商用サイトにも共通の脅威です。
そこで、ちょっとの、比較的素早くできる簡単なステップを踏むことで、
<![%redhat;[Redhat]]>Linux が動いている典型的な自宅のデスクトップや
小さなオフィスのシステムなどを、
それなりに安全なものにして外部の脅威のほとんどから守りましょう。
たとえ、より大きな、
またはより複雑な環境の Linux システムに対応することになっても、
この文書はなかなか参考になるでしょうし、
その後、さらにそれぞれ固有の状況に応じたものを読んで、
知識を得ることもできます。
実際、この文書は、
おそらく全ての人に役立つだろうと思っています。

</para>

<para>
 <!--
 We will assume the reader knows little about Linux, networking, TCP/IP, 
 and the finer points of running a server Operating System like Linux. We 
 will also assume, for the sake of this document, that all local users are
 <quote>trusted</quote> users, and won't address physical or local network
 security issues in any detail. Again, if this is not the case, further
 reading is strongly recommended. 
-->
  この文書では、読者が Linux, ネットワーク、TCP/IP, 
そして Linux のようなサーバーオペレーティングシステムを
動かすためのより詳細な点については、ほとんど知らないものと仮定します。
また、この文書の目的から、
全てのローカルユーザーを<quote>信用できる</quote>ユーザーであると仮定し、
物理的な、またはローカルなネットワークの
セキュリティの問題の詳細については全く議論しません。
そのような場合でも、
やはり、この文章を続けて読むことを強くお勧めします。

</para>

<para>
<!--
 The principles that will guide us in our quest are:
-->
  この探求を導く原則は以下の通りです。
</para>

<para>
 <itemizedlist>

  <listitem>
   <para>
<!--
     There is no <application>magic bullet</application>. There is no one 
     <emphasis role="bold">single</emphasis> thing we can do to make us secure. It is not that simple. 
-->
  <application>魔弾</application>、
つまり一発で怪物を倒せる魔法などありません。
<emphasis role="bold">一つの</emphasis>手段で我々を守ることはできません。
そんなに単純なことではないのです。

   </para>
  </listitem> 

  <listitem>
   <para>
<!--
    Security is a process that requires maintenance, not an objective to
    be reached.
-->
  セキュリティとは継続が必要なプロセスであって、
達成される目標ではありません。

   </para>
  </listitem> 

  <listitem>
   <para>
<!--
     There is no 100% safe program, package or distribution. Just varying 
     degrees of insecurity. 
-->
  100パーセント安全なプログラム、パッケージ、ディストリビューションと
いったものはありません。危険の程度の大小があるだけです。
   </para>
  </listitem> 

 </itemizedlist>
</para>


<para>
<!--
 The steps we will be taking to get there are:
-->
  そこで取るべきステップは以下のようになります：
</para>

<para>
 <itemizedlist>

  <listitem>
   <para>
<!--
    Step 1: Turn off, and perhaps uninstall, any and all unnecessary services.
-->
  ステップ１：不必要なサーヴィスは全て停止し、
場合によってはアンインストールする。
   </para>
  </listitem> 

  <listitem>
   <para>
<!--
    Step 2: Make sure that any services that are installed are updated and
    patched to the current, safe version &#045;&#045; <emphasis>and then stay that
    way</emphasis>. Every server application has potential exploits. Some have
    just not been found yet.
-->
  ステップ２：インストールされているどのサーヴィスについても、
最新の安全なバージョンにアップデートされパッチをあてられているか確認し、
―<emphasis>しかも、それを続けること</emphasis>。
どのサーバーアプリケーションも食い物にされる可能性を持っていて、
その幾つかはまだ見つかっていないだけである。

   </para>
  </listitem> 

  <listitem>
   <para>
<!--
    Step 3: Limit connections to us from outside sources by implementing a
    firewall and/or other restrictive policies. The goal is to allow only the
    minimum traffic necessary for whatever our individual situation may be.
-->
  ステップ３：ファイアーウォールか他の制限ポリシー、
またはその両方を実装することで、外部からの接続を制限する。
目標は個々の状況が何であれ、
必要最小限のトラフィックのみを許可することである。
   </para>
  </listitem> 

  <listitem>
   <para>
<!--
     Awareness. Know your system, and how to properly maintain and secure it.
     New vulnerabilities are found, and exploited, all the time. Today's
     secure system may have tomorrow's as yet unfound weaknesses. 
-->
  意識すること。自分のシステムを知り、
いかにそれを適切に維持し安全に守るかを知ること。
新たな弱点は常に見つけられ、悪用されている。
今日の安全なシステムも明日には、
まだ見つかっていない弱点を持っているかもしれない。     
   </para>
  </listitem> 

 </itemizedlist>
</para>

<para>
<!--
 If you don't have time to read everything, concentrate on Steps 1, 2, and 3. 
 This is where the meat of the subject matter is. The <link
 linkend="appendix">Appendix</link> has a lot of supporting information, which
 may be helpful, but may not be necessary for all readers.
-->
  もしこの文書全体を読む時間がないなら、
このステップ１、２、３に集中してください。
この３つがこの問題の本質です。
<link linkend="appendix">補遺</link>
にサポート情報が沢山あります。
これらは役に立つかも知れませんが、
全ての読者に必要な情報というわけではないかも知れません。
</para>

</sect2>

<!--  ~  End section  ~  -->



<![%redhat;[ 
<!--   ~~~~~       New section      ~~~~~     -->

<sect2>
<title><!--Notes-->注意</title>
<para>
<!--
 This is a Red Hat specific version of this document. The included examples 
 are compatible with Red Hat 7.0 and later. Actually, most examples should 
 work with earlier versions of Red Hat as well. Also, this document should be
 applicable to other distributions that are Red Hat derivatives, such as
 Mandrake, Conectiva, etc.
-->
  これはこの文書の Redhat に特化したバージョンです。
文書内の例は Redhat 7.0 以降のバージョンでコンパチブルになっています。
実際、ほとんどの例は Redhat のそれ以前のバージョンにおいても
同様にうまく動作するはずです。
また、この文書は Redhat から派生した他のディストリビューション、
例えば Mandrake や Conectiva などについても適用できるはずです。
</para>

<para>
<!--
 Overwhelmingly, the content of this document is not peculiar to Red Hat. The
 same rules and methodologies apply to other Linuxes. And indeed, to other
 Operating Systems as well. But each may have their own way of doing things &#045;&#045; 
 the file names and locations may differ, as may the system utilities that 
 we rely on. It is these differences that make this document a 
 <quote>Red Hat</quote> version.
 -->
  この文書の内容のほとんどは Redhat に固有のものではありません。
同じルールと方法論が他の Linux についても適用できます。
そして、実際の所、
他のオペレーティングシステムについても同様に適用できます。
しかし、各システムにはそれぞれに固有のやり方があります
 ― 例えば、
ファイルの名前やそれらが置いてある場所などが異なるかも知れませんし、
また我々が依存しているシステムユーティリティが異なるかも知れません。
そういった違いで、
この文書は <quote>Redhat</quote> 版になっています。
</para>

</sect2>

<!--  ~  End section  ~  -->
]]>


<!--   ~~~~~       New section      ~~~~~     -->

<sect2>
<title><!--Copyright-->コピーライト（著作権）</title>

<para>
 Security-Quickstart HOWTO for <![%redhat;[Red Hat]]> Linux
</para>

<para>
 Copyright &copy; 2001 Hal Burgiss. 
</para>

<para>
<!--
 This document is free; 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.
-->
  この文書はフリーです。すなわち、
Free Software Foundation によって出版された GNU 一般公用許諾書
 (GNU General Public License) 
（バージョン 2 またはそれ以降の任意のバージョンでも）
の規定の下で、これを再配布すること、および（または）、
改変することが可能です。
</para>

<para>
<!--
 This document 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.
-->
  この文書は役に立つことを期待して配布されていますが、
「何の保証もありません」、つまり、
そこから派生する「市場性」または「特定目的適合性」
についての保証もありません。
詳しくは GNU 一般公用許諾書 (GNU General Public License)
 を参照してください。
</para>

<para>
<!--
 You can get a copy of the GNU GPL at at <ulink
 URL="http://www.gnu.org/copyleft/gpl.html">http://www.gnu.org/copyleft/gpl.html</ulink>.
-->
  GNU GPL 文書は<ulink
 URL="http://www.gnu.org/copyleft/gpl.html">http://www.gnu.org/copyleft/gpl.html</ulink>で手に入れることができます。

</para>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2>
<title><!--Credits-->謝辞</title>

<para>
<!--
 Many thanks to those who helped with the production of this document.
-->
  この文書の作成を助けていただいた以下の方々に感謝します。
</para>

<para>
 <itemizedlist>

  <listitem>
   <para>
<!--
    Bill Staehle, who has done a little bit of everything: ideas, editing, 
    encouragement, and suggestions, many of which have been incorporated. 
    Bill helped greatly with the content of this document.
-->
  Bill Staehle には、アイデア、編集、励まし、提案など、
全ての面で何かしら助けてもらった。その多くはこの文書に含まれている。
Bill は大いに、この文書の内容について助けになってくれた。
   </para>
  </listitem> 
  
  <listitem>
   <para>
<!--
     Others who have contributed in one way or another: Dave Wreski, Ian
     Jones, Jacco de Leeuw, and Indulis Bernsteins.
-->
  何かと手助けしてくれたほかの方々： Dave Wreski, Ian Jones,
Jacco de Leeuw, Indulis Bernsteins に感謝する。
    </para>
  </listitem> 

  <listitem>
   <para>
<!--
    Various posters on comp.os.linux.security, a great place to learn about 
    Linux and security.
-->
  Linux とセキュリティについて学べる偉大な場所、
comp.os.linux.security への数々の投稿者に感謝する。
   </para>
  </listitem>

  <listitem>
   <para>
<!--
    The Netfilter Development team for their work on
    <application>iptables</application> and connection tracking, state of the
    art tools with which to protect our systems. 
-->
  <application>iptables</application> と接続追跡、
システムを守るために役立つ最先端のツールについての、
The Netfilter Development チームの仕事に感謝する。   
   </para>
  </listitem> 

 </itemizedlist>
</para>

</sect2>


<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="disclaimer">
<title><!--Disclaimer-->免責事項</title>

<para>
<!--
 The author accepts no liability for the contents of this document. Use the
 concepts, examples and other content at your own risk. As this is a new
 document, there may be errors and inaccuracies. Hopefully these are few and
 far between. Corrections and suggestions are welcomed.
-->
  著者はこの文書の内容について何ら責任を負いません。
この文書内の概念や実例、その他の内容については読者自身の責任に
おいて使用してください。
これは新しい文書ですので、間違いや不正確な部分があるかもしれません。
ほとんどないと思いますが、訂正や提案を歓迎します。
</para>

<para>
<!--
 This document is intended to give the new user a starting point for securing
 their system while it is connected to the Internet. Please understand that
 there is no intention whatsoever of claiming that the contents of this
 document will necessarily result in an ultimately secure and worry-free
 computing environment. Security is a complex topic. This document just
 addresses some of the most basic issues that inexperienced users should be
 aware of. 
-->
  この文書は新人ユーザに、
自分のシステムをインターネットに接続している時に、
そのシステムを安全に守るための出発点を示そうとしているものです。
この文書の内容が必ずしも、究極的に安全で、何の心配もない、
計算機環境を作るものだと主張するつもりは、
全くないということを理解してください。
セキュリティは複雑な問題です。この文書は経験の浅いユーザが注意すべき
最も基本的な問題の一部を考えるものに過ぎません。
</para>

<para>
<!--
 The reader is encouraged to read other security related documentation and
 articles. And to stay abreast of security issues as they evolve. Security is
 not an objective, but an ongoing process.
 -->
  読者にはセキュリティに関するほかの文書や記事を読むことを勧めます。
そして、発展するにしたがって、
セキュリティの最新事情に遅れないようにしてください。
セキュリティは一つの達成目標ではなくて、継続するプロセスなのです。
</para>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2>
<title><!--New Versions and Changelog-->新しいバージョンと変更ログ</title>

<![%linuxall;[ 
<para>
<!--
 The current official version can always be found at <ulink
 url="http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO/">http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO/</ulink>.
 Pre-release versions can be found at <ulink
 URL="http://feenix.burgiss.net/ldp/quickstart/">http://feenix.burgiss.net/ldp/quickstart/</ulink>.
-->
  現在の公式バージョンはつねに
<ulink
 url="http://www.linuxdoc.org/HOWTO/Security-Quickstart-HOWTO/">http://www.linuxdoc.org/HOWTO/Security-Quickstart-HOWTO/</ulink>
で見つけられます。
プレリリースバージョンは
<ulink
 URL="http://feenix.burgiss.net/ldp/quickstart/">http://feenix.burgiss.net/ldp/quickstart/</ulink>
にあります。
</para>
 ]]>

<![%redhat;[ 
<para>
<!--
 The current official version can always be found at <ulink
 url="http://www.tldp.org/HOWTO/Security-Quickstart-Redhat-HOWTO/">http://www.tldp.org/HOWTO/Security-Quickstart-Redhat-HOWTO/</ulink>.
 Pre-release versions can be found at <ulink
 URL="http://feenix.burgiss.net/ldp/quickstart-rh/">http://feenix.burgiss.net/ldp/quickstart-rh/</ulink>.
-->
  現在の公式バージョンはつねに
<ulink
 url="http://www.linuxdoc.org/HOWTO/Security-Quickstart-Redhat-HOWTO/">http://www.linuxdoc.org/HOWTO/Security-Quickstart-Redhat-HOWTO/</ulink>
で見つけられます。
プレリリースバージョンは
<ulink
 URL="http://feenix.burgiss.net/ldp/quickstart-rh/">http://feenix.burgiss.net/ldp/quickstart-rh/</ulink>
にあります。
</para>
]]>

<para>
<!--
 Other formats, including PDF, PS, single page HTML, may be found at 
 the Linux Documentation HOWTO index page: <ulink
 url="http://tldp.org/docs.html#howto">http://tldp.org/docs.html#howto</ulink>.
-->
  PDF, PS, 一つのファイルにまとまった HTML など、他の形式のファイルは、
Linux Documentation Howto のインデックスページ：
<ulink
 url="http://tldp.org/docs.html#howto">http://tldp.org/docs.html#howto</ulink>
で見つけられるかもしれません。
</para>

<para>
<!--
 Changelog:
-->
  変更ログ
</para>

<para>
<!--
 Version 1.2: Clarifications on example firewall scripts, and small additions
 to 'Have I been Hacked'. Note on Zonealarm type applications. More on the use
 of <quote>chattr</quote> by script kiddies, and how to check for this. Other 
 small additions and clarifications.
-->
  Version 1.2: ファイアーウォールスクリプトの例の説明、
「もうハックされてる？」の章に少し追加。
Zonealarm 型のアプリケーションについての注意。
スクリプトキディ達による <quote>chattr</quote> の使用についてさらに、
そしてこれをどうチェックするか。
その他の小さな追加と説明。
</para>

<para>
<!--
 Version 1.1: Various corrections, amplifications and numerous mostly small
 additions. Too many to list. Oh yea, learn to spell Red Hat correctly ;-)
-->
  Version 1.1: 様々な訂正、拡充とたくさんのほとんどは小さな追加。
たくさんありすぎてリストには出来ません。
ええ、正しい "Red Hat" のつづりも覚えましたとも ;-)
</para>

<para>
<!--
 Version 1.0: This is the initial release of this document. Comments 
 welcomed.
-->
  Version1.0: これはこの文書の最初のリリースです。
コメントを歓迎します。
</para>

</sect2>

<!--  ~  End section  ~  -->




<!--   ~~~~~       New section      ~~~~~     -->

<sect2>
<title><!--Feedback-->フィードバック</title>

<para>
<!--
 Any and all comments on this document are most welcomed. Please make sure you have
 the most current version before submitting corrections or suggestions! These
 can be sent to <email>hal@foobox.net</email>.
-->
  この文書についてのどんなコメントでも全て大いに歓迎します。
訂正や提案を投稿する前にバージョンが最新であることを確認してください！
これらは<email>hal@foobox.net</email>宛にメイルで送れます。
</para>

</sect2>

</sect1>

<!--  ~  End section  ~  -->




<!--   ~~~~~~~~       New section Header    ~~~~~~~~~     -->

<sect1 id="foreword">
<title><!--Foreword-->はじめに</title>

<para>
<!--
 Before getting into specifics, let's try to briefly answer some questions
 about why we need to be concerned about security in the first place. 
-->
  各論に入る前に、
そもそもなぜ、セキュリティに注意を払う必要があるのか、
という問題に簡単に答えてみましょう。
</para>

<para>
<!--
 It is easy to see why an e-commerce site, an on-line bank, or a government 
 agency with sensitive documents would be concerned about security. But what
 about the average user? Why should even a Linux home Desktop user worry about
 security? 
-->
  商用サイトやオンライン銀行、
または扱いに注意を要する文書を持つような政府機関が
セキュリティに関心を持つ理由は容易に理解できます。
しかし、ごく普通のユーザーについてはどうでしょう？
どうして自宅のデスクトップで Linux を使っているユーザーが、
セキュリティについて心配すべきなのでしょうか？
</para>

<para>
<!--
 Anyone connected to the Internet is a target, plain and simple. It
 makes little difference whether you have a part-time dialup connection, or a
 full-time connection, though full-time connections make for bigger targets.
 Larger sites make for bigger targets too, but this does not let small users
 off the hook since the <quote>small user</quote> may be less skilled and thus
 an easier victim. 
 <![%redhat;[ Red Hat, and Red Hat based distributions, tend to make for bigger 
  targets as well, since the installed user base is so large.]]>
-->
  インターネットに接続している誰もが標的なのです。
これは平明、かつ単純なことです。
時間を限ったダイアルアップ接続をしているのか、
常時接続をしているのかは、
後者はより大きな標的になるとは言うものの、
些細な違いに過ぎません。
同様に、より大きなサイトはより大きな標的になりますが、
だからと言って小規模ユーザー達が例外になるわけではありません。
なぜなら、<quote>小規模ユーザー</quote>は技術がより低いかも知れず、
その分、簡単な獲物になりやすいかも知れないのです。
 <![%redhat;[Red Hat と Red Hat に基づくディストリビューションは、
インストールする人々の多さからして、
同様により大きな標的になりがちです。]]>
</para>

<para>
<!--
 There are those out there that are scanning just for easy
 victims all the time. If you start logging unwanted connection attempts, 
 you will see this soon enough. There is little doubt that many of these
 attempts are maliciously motivated and the attacker, in some cases, is
 looking for Linux boxes to crack. Does someone on the other side of the globe
 really want to borrow my printer? 
-->
  まさにその簡単な獲物を探しているような輩が常にあちこちにいるのです。
もしあなたが望まない接続試行の記録を始めたならば、
このことにすぐ気付くことでしょう。
疑いもなく、これらの試行の多くは悪意の動機を持ち、
アタッカー（攻撃者）たちは、時には、
クラックの目標として Linux box を探しているのです。
地球の反対側にいる誰かが、
私のプリンターを本当に借りたがっていると思いますか？
</para>

<para>
<!--
 What do they want? Often, they just may want your computer, your IP
 address, and your bandwidth. Then they use you to either attack others, or
 possibly commit crimes or mischief and are hiding their true identity behind
 you. This is an all too common scenario. Commercial and high-profile sites
 are targeted more directly and have bigger worries, but we all face this type
 of common threat. 
-->
  では、彼らは何を求めているのでしょうか？
しばしば、彼らは単にあなたのコンピューター、IPアドレス、
または帯域が欲しいだけかも知れません。
その場合には、彼らは他の目標を攻撃するために、
または、ひょっとしたら、
犯罪を犯すためか盗みをするためにあなたを利用し、
その背後に自分の正体を隠すのです。
これは全く非常にありふれたシナリオです。
注目されやすい商用サイトはもっと直接的に標的とされ、
より大きな問題を抱えていますが、
我々は皆、この種の共通の脅威に向かい合っているのです。
</para>

<para>
<!--
 With a few reasonable precautions, <![%redhat;[Red Hat ]]>Linux can be very
 secure, and with all the available tools, makes for a fantastically fun and
 powerful Internet connection or server. Most successful break-ins are the
 result of ignorance or carelessness. 
-->
  リーズナブルな二、三の準備をしておけば、
<![%redhat;[Red Hat ]]>Linux は非常に安全になり得ますし、
全て使用可能なツールを用いて、
すばらしく楽しくパワフルなインターネット接続も、
サーバーになることも、可能です。
ほとんどの侵入の成功は無知と不注意の結果なのです。
</para>

<para>
<!--
 The bottom line is:
-->
  結論は ―
</para>

<para>
 <itemizedlist>
  
  <listitem>
   <para>
<!--
    Do you want control of your own system or not?
-->
  自分自身のシステムをコントロールしたいですか、
したくないですか？
   </para>
  </listitem> 

  <listitem>
   <para>
<!--
    Do you want to unwittingly participate in criminal activity?
-->
  知らないうちに犯罪行為の片棒を担ぎたいですか？
   </para>
  </listitem> 

  <listitem>
   <para>
<!--
    Do you want to be used by someone else?
-->
  他の誰かに利用されたいですか？
   </para>
  </listitem> 

  <listitem>
   <para>
<!--
     Do you want to risk losing your Internet connection?
-->
  インターネット接続を失うリスクにさらされたいですか？
   </para>
  </listitem> 

  <listitem>
   <para>
<!--
    Do you want to have to go through the time consuming steps of reclaiming
    your system?
-->
  システムを復旧するためのうんざりするような作業に
時間を費やすはめになりたいですか？
   </para>
  </listitem> 

  <listitem>
   <para>
<!--
    Do you want to chance the loss of data on your system?
-->
  システム上のデータを失う危険を冒したいですか？
   </para>
  </listitem> 

 </itemizedlist>
</para>

<para>
<!--
 These are all real possibilities, unless we take the appropriate
 precautions.
-->
  これらは全て現実的な可能性です。あなたが適切な準備を取らない限り。
</para>

<Warning>
 <Para>
<!--
  If you are reading this because you have already been broken into, or
  suspect that you have, you cannot trust any of your system utilities to
  provide reliable information. And the suggestions made in the next several
  sections will not help you recover your system. Please jump straight to the
  <link linkend="hacked">Have I been Hacked?</link> section, and read that
  first.
 -->
  もしあなたが既に侵入されてしまっているか、または、
そう疑っていることが理由でこの文書を読んでいるのならば、
頼りにする情報を得るためのシステムユーティリティは
全て信用することができません。
そして、以下の章に書かれている提案は、
システムを復旧するための助けにはならないでしょう。
まっすぐに<link linkend="hacked">もうハックされている？</link>
の章に飛んで、まずそこを読んでください。
 </Para>
</Warning>



<!--   ~~~~~       New section      ~~~~~     -->
<!--
<sect2>
<title><!- -Preamble- ->前口上</title>

<para>

 First, there is no such thing as a 100% guaranteed safe Internet connection. 
 No matter how many steps you take, there is always someone willing to do you 
 one better, and undo all your work. The only absolutely safe connection is
 one that is unplugged. That being said, it is not difficult to greatly
 minimize the risk from many of these inherent threats. 

  まず第一に、100% 安全が保証されたインターネット接続といった
ものは存在しません。
あなたがどんなに多くのステップをとろうが、
常にあなたより一歩うまくやってのけて、
あなたの全ての仕事を台無しにしようとする誰かがいるのです。
唯一の絶対安全な接続方法は、そもそも接続しないことです。
ここでの主張は、これら内在する脅威の多くからの
危険を最小限にすることは難しくない、ということなのです。
</para>

<para>

 Secondly, networks are designed explicitly such that computers in different
 locations can connect to each other, and exchange data. Linux is a network
 Operating System from the ground up, and generally comes with a wide array
 of <Quote>server</Quote> applications installed and ready for action. Mail
 servers, web servers, ftp servers, telnet servers, print servers - to name
 just a few. While this is a good thing in many respects, it also makes Linux
 an inviting target for those with less than honorable intentions. A common
 modus operandi for <Quote>hackers</Quote> is to find a weakness in a given
 server (e.g. <application>ftp</application> server), and then let themselves
 in by exploiting that weakness. One step we will take here will be to decide
 which, if any, servers we really need to be running on our own systems. Then,
 we'll make sure that any we do really need to be running, are running the
 latest patched version. 

  第二に、ネットワークはそもそも、異なる場所にあるコンピュータが
互いに接続し、データを交換するように、設計されています。
Linux は産まれたときからネットワーク OS であり、一般的には、
既にインストールされ、いつでも使えるようになっている、
幅広い<Quote>サーバ</Quote>アプリケーションが付いてきます。
少し名前を挙げるだけでも、
メイルサーバ、web サーバ、ftp サーバ、telnet サーバ、
プリントサーバなどがあります。
これは多くの点で良いことではありますが、Linux を好ましからぬ
意図を持つ輩の標的にもしてしまいます。
<Quote>ハッカー達</Quote>の共通のやり口は、
与えられたサーバ（例えば、<application>ftp</application> サーバ）
の弱点を見つけ、そしてその弱点を利用することで侵入するのです。
ここで取ろうとしている一つのステップは、
本当にこのシステムで走らせる必要があるサーバはどれか、
決定することになるでしょう。
そして、本当に走らせる必要のあるものが、
最新のパッチをあてられたバージョンで走っていることを確認するのです。
</para>

<para>

 Contrary to popular opinion, a <Quote>hacker</Quote> does not much
 care about any sensitive or personal data (like bank account number) you may
 have tucked away. Not to say this is not a concern for businesses, commercial
 sites and others with valuable secrets or data. But what he really wants in
 many cases is your IP address, your bandwidth, and the free reign of your
 system. That's all. This way he is hidden, and whatever attacks or mischief
 he may undertake, utilizes your resources, and it looks like it is coming
 from you. So if I wanted to break into CIA Headquarters, I surely wouldn't do
 it from home. Well, not my home anyway. First I break into someone else's
 system, and do it from their home. Anyway, you are a target just because you
 are connected to the Internet - nothing more, nothing less.

  よく聞く意見とは逆に、<Quote>ハッカー</Quote>は、
あなたがしまいこんでいるかもしれない、
扱いに注意を要する、または個人的な（例えば銀行の口座番号のような）
データにそれほど注意を払いません。
これは言うまでもなく、ビジネスや商業用のサイトや、
勝ちある秘密やデータを含むその他のサイトにはあてはまりません。
しかし、多くの場合彼らが本当に欲しがっているものは、
あなたの IP アドレスや帯域、そしてあなたのシステムを
自由に支配することなのです。それだけです。
この方法で彼は姿を隠し、攻撃をするにせよ泥棒をするにせよ、
あなたのリソースを使って、それがあなたの所から来たかのように
見せかけるのです。
ですから、もし私が CIA 本部に侵入したいならば、
私は決してそれを家からは行わないでしょう。
ええ、とにかく私の家からは。
まず私は誰か他のシステムに侵入して、そこから行うでしょう。
とにかく、あなたは単にインターネットに接続しているから、
という理由で獲物になるのです。それ以上でも以下でもなく。
</para>

<para>

 Lastly, is every connection attempt, an attempted break-in? No, of course
 not. There is a number of innocent explanations why you might find someone 
 knocking at your door so to speak. But how to tell the difference? You can't 
 really, but we do know for a fact that many of these attempts are indeed
 either attempts to find out more about your system as a precursor to
 <quote>something</quote>, or possibly are an actual entry attempt. So better
 safe than sorry as they say. 
  最後に、全ての接続の試みが侵入目的なのでしょうか？
いいえ、もちろんそうではありません。
言わば、誰かがあなたの家のドアをノックしているとして、
それが何ら害のないものである理由はいくらでもあるのです。
しかし、その違いがどうして分かりますか？
それは絶対に分かりません。しかし我々は、
それらの試みの多くが実際のところ、
<quote>何かの</quote>前触れとして
より多くのシステム情報を得ようとしているか、
またはひょっとしたら実際の侵入の試みであることを知っているのです。
ですから、言うところの、後悔するより安全第一です。
</para>


</sect2>
-->
<!--  ~  End section  ~  -->


<!--   ~~~~~       New section      ~~~~~     -->
<sect2>
<title><!--The Optimum Configuration-->理想的な設定</title>

<para>
<!--
 Ideally, we would want one computer as a dedicated firewall and router. This 
 would be a bare bones installation, with <emphasis>no</emphasis> servers
 running, and only the required services and components installed. The rest of
 our systems would connect via this dedicated router/firewall system. If we
 wanted publicly accessible servers (web, mail, etc), these would be in a
 <quote>DMZ</quote> (De-militarized Zone). The router/firewall allows
 connections from outside to whatever services are running in the DMZ by
 <quote>forwarding</quote> these requests, but it is segregated from the rest
 of the internal network (aka LAN) otherwise. This leaves the rest of the
 internal network in fairly secure isolation, and relative safety. The
 <quote>danger zone</quote> is confined to the DMZ. 
 -->
  理想的には、
ファイヤーウォールとルーターとして
一台専用のコンピュータがあるのが望ましいでしょう。
これはベアボーン、つまり、
必要なサーヴィスとコンポーネントだけのインストールで、
サーバ類は<emphasis>一切</emphasis>動かさないものです。
システムの残りの部分はこの専用ルーター/ファイアーウォールシステムを
経由して接続します。
もし公けに接続可能なサーバ（ウェブ、メイルなど）が欲しい場合には、
これらは <quote>DMZ</quote> (De-militarized Zone 非武装地帯）
の中におくべきしょう。
このルーター/ファイアーウォールは、
外部から DMZ で動いているどのサーヴィスへの接続要求についても、
これらの要求を<quote>フォーワード</quote>することよって接続を許可しますが、
他の内部ネットワークの残り(LAN と呼ばれている)とは切り離されています。
これによって、
それ以外の内部ネットワークを孤立させ、
比較的安全にしておくことができます。これで、
<quote>危険地帯</quote>は DMZ に制限されます。
</para>

<para>
<!--
 But not everyone has the hardware to dedicate to this kind of installation.
 This would require a minimum of two computers. Or three, if you would be 
 running any publicly available servers (not a good idea initially). Or maybe
 you are just new to Linux, and don't know your way around well enough yet. So
 if we can't do the ideal installation, we will do the next best thing.
-->
  しかし、誰もがこの種のルータ/ファイアーウォール専用
にするためのハードウェアを持っているわけではありません。
これには最低でも二台のコンピュータが必要でしょう。
もし公けに利用可能なサーバを何か動かしたいなら
（いきなり最初からは良い考えとは言えませんが）、三台になります。
または、まったくの Linux 初心者だと、
どうしたらよいのかまだ十分に分かっていないかも知れません。
そこで、もしこの理想的な設定が出来ないなら、
次善の策をとることになります。
</para>

</sect2>


<!--  ~  End section  ~  -->


<!--   ~~~~~       New section      ~~~~~     -->
<sect2>
<title><!--Before We Start-->始める前に</title>

<para>
<!--
 Before we get to the actual configuration sections, a couple of notes. 
 -->
  実際の設定の章に入る前に、二つの注意点を。 
</para>

<para>
<!--
<![%linuxall;[  
 First, one of the interesting aspects of Linux, is the different
 distributions like Caldera, Red Hat, SuSE, and Debian. While these are all 
 <quote>Linux</quote>, and may share certain features, there is surely some
 differences as to what utilities they may install as defaults. Most Linux 
 distributions will write their own system configuration tools as well. And with
 Linux, there is always more than one way to skin a cat. But for the purposes
 of our discussion, we will have to use as generic set of tools as we can.
 Unfortunately, GUI tools don't lend themselves to this type of documentation. 
 We will be using text based, command line tools for the most part. If you 
 are familiar with your distribution's utilities, feel free to substitute
 those in appropriate places. And if not, you should learn them or suitable 
 alternatives.
]]>
<![%redhat;[ With Linux, there is always more than one way to perform any
task. For the purposes of our discussion, we will have to use as generic set
of tools as we can. Unfortunately, GUI tools don't lend themselves to this
type of documentation. So we will be using text based, command line tools for
the most part. Red Hat does provide various GUI utilities, feel free to
substitute those in appropriate places.

]]>
-->
<![%linuxall;[  
  まず第一に、Linux の興味深い側面の一つとして Caldera, Red Hat,
SuSE, Debian と言ったディストリビューションの差異があります。
これらは全て <quote>Linux</quote> であり、共通の特徴を持っていますが、
デフォルトでインストールされるかも知れないユーティリティ群には
いくらかの差が確かに存在します。
同様に、ほとんどの Linux のディストリビューションはそのシステムの
自前の設定ツールを持っているでしょう。
そして Linux においては、
「猫の皮を剥ぐには常に一つより沢山の方法がある」のです。
しかし、我々の議論の目的においては、
出来る限り一般的なツール群で説明するべきでしょう。
残念ながら、GUI ツールはこの種の文書で使うことはできません。
我々はほとんどの場合において、
テキストベースのコマンドラインツールを使うことになるでしょう。
もし、ディストリビューションの
ユーティリティに親しんでいる方なら、
適切な場所でそれらにおきかえても構いません。
しかし、そうでないなら、
上のようなツール群や適切な代用物を学ぶべきでしょう。
]]>
<![%redhat;[Linux においてはどんな仕事をするにしても、
常に一通り以上の方法があります。我々の議論の目的には、
我々は出来る限り一般的なツールのセットで説明するべきでしょう。
残念ながら、GUI ツールはこの種の文書で使うことはできません。
ですから、ほとんどの場合において、
我々はテキストベースのコマンドラインツールを使うことになるでしょう。
Red Hat は色々な GUI ツールを用意していますから、
適切な場所でそれらに置き換えても構いません。]]>
</para>

<para>
<!--
 The next several sections have been written such that you can perform the 
 recommended procedures as you read along. This is the
 <quote>Quick Start</quote> in the document title!
-->
  続くいくつかの章は、
読めばそこで勧めている手続きを実際に実行できるように書かれています。
この文書は、タイトルにあるように
 <quote>Quick Start</quote> なんですから！
</para>

<para>
<!--
 To get ready, what you will need for the configuration sections below:
-->
  準備のために、以下の設定で必要になるものを挙げます：
</para>

<para>
 <ItemizedList> 
  
  <ListItem>
   <para>
<!--
    A text editor. There are many available. If you use a file manager 
    application <![%redhat;[ like <application>gmc</application> or 
    <application>nautilus</application>]]>, it probably has a built in editor.
    This will be fine. <command>pico</command> and <command>mcedit</command>
    are two relatively easy to use editors if you don't already have a
    favorite. There is a quick guide to <link linkend="text">Text
    editors</link> in the Appendix that might help you get started. It is
    always a good idea to make a back up copy, before editing system
    configuration files.
   -->
  テキストエディタ。色々なものが使えます。
もしあなたがファイルマネージャーアプリケーション
<![%redhat;[ <application>gmc</application> や、
<application>nautilus</application>など]]>
を使うなら、組み込みのエディタが含まれているでしょう。
これも結構です。
<command>pico</command> と <command>mcedit</command>
の二つは、
あなたが既にお気に入りのエディタを持っていないなら、
なかなか使いやすいエディタです。
補遺に<link linkend="text">テキストエディタ</link>
への手っ取り早い解説がありますので、
あなたが仕事に取りかかる上で助けになるかもしれません。
システムの設定ファイルを編集する前には、
常にバックアップコピーを取っておくようにすると良いでしょう。
   </para>
  </ListItem> 

  <ListItem>
   <para>
<!--
     For non-GUI editors and some of the commands, you will also need a
     terminal window opened. <command>xterm,</command>
     <command>rxvt,</command> and <command>gnome-terminal</command> all will
     work, as well as others.
-->
  非 GUI エディタやコマンドを使うには、
ターミナルウィンドウを開く必要があります。
<command>xterm,</command> <command>rxvt,</command>
<command>gnome-terminal</command> などは全て使えますし、
その他のものでもかまいません。
    </para>
  </ListItem> 

<![%linuxall;[   
  <ListItem>
   <para>
<!--
    You should also be familiar with your distribution's method of stopping
    services from running on each boot. Also, how they install (and uninstall)
    packages (<command>rpm</command>, <command>deb</command>, etc). And where
    to find the updates for your release. This information is available in
    your release's documentation, or on your vendor's web site. 
-->
  各ブートで動いているサーヴィスを停止するための、
各ディストリビューションでの方法を良く知るべきですし、
またそれらがどうやってパッケージ
（<command>rpm</command>, <command>deb</command> など）
をインストールし、そしてアンインストールするのかも知らなくてはいけません。
そして自分のシステムのリリースのアップデート版を
どこで見つけることができるかも。
この情報はそのリリース文書の中か、
またはベンダのウェブサイトで見つけられます。
   </para>
  </ListItem> 
 ]]>

 </ItemizedList>
</para>

<para>
<!--
 We'll be using a hypothetical system here for examples with the hostname
 <quote>bigcat</quote>. Bigcat is a Linux desktop with a fresh install of the
 latest/greatest <![%linuxall;[ Linux distro ]]> <![%redhat;[ Red Hat
 ]]> running. Bigcat has a full-time, direct Internet connection. Even if your
 installation is not so <quote>fresh</quote>, don't be deterred. Better late
 than never.
-->
  この文書では例として、仮に <quote>bigcat</quote> というホストネームを持つ
システムを用いて説明することにします。
Bigcat は最新かつ最高の
<![%linuxall;[ Linux ディストリビューション]]> <![%redhat;[ Red Hat ]]>
が走っている、真新しくインストールしたばかりのデスクトップマシンです。
Bigcat は常時、直接にインターネット接続しています。
あなたのインストールがそんなに<quote>真新しく</quote>なくても、
ここで思いとどまらないで下さい。遅くとも、せぬには勝る、です。
</para>

</sect2>

</sect1>

<!--  ~  End section  ~  -->



<!--   ~~~~~~~~       New section Header    ~~~~~~~~~     -->

<sect1 id="services">
<title><!--Step 1: Which services do we really need?-->ステップ１：本当に必要なのはどのサーヴィスか？</title>

<para>
<!--
 In this section we will see which services are running on our freshly installed
 system, decide which we really need, and do away with the rest. If you are
 not familiar with how servers and TCP connections work, you may want to read
 the section on <link linkend="serversetc">servers and ports</link> in the
 Appendix first. If not familiar with the <command>netstat</command> utility,
 you may want to read a quick <link linkend="netstat">overview</link> of it
 beforehand. There is also a section in the Appendix on <link
 linkend="ports">ports</link>, and corresponding services. You may want to 
 look that over too.
-->
  この章では、新しくインストールした我々のシステムで、
どのサーヴィスが動いているかを見て、どれが本当に必要なものかを決め、
それ以外のものを切り捨てましょう。
どのようにサーバと TCP 接続が働いているかに詳しくない方は、
まず補遺の<link linkend="serversetc">サーバとポート</link>に
ついての章を読むと良いでしょう。
また <command>netstat</command> ユーティリティに馴染みがないなら、
あらかじめその簡単な<link linkend="netstat">概説</link>
を読むと良いでしょう。
さらに補遺には <link linkend="ports">ポート</link>についての章と、
それに対応するサーヴィスの章がありますので、参考になるかもしれません。
</para>

<!--
<para>
 Historically many Linux distributions either enabled many unnecessary
 services, or perhaps just made it too easy to wind up with services running 
 that might be unnecessary, and even potentially dangerous. And sometimes it
 is not so obvious that these are indeed running. Or that they may be
 potentially security risks.

  かつて多くの Linux ディストリビューションでは、
沢山の不必要なサーヴィスが使えるようになっていました。
または、不必要で危険を招きかねないサーヴィスを走らせておくことが、
安直に行われていたということかも知れません。
そして時に、そのようなサーヴィスが実際に動作中であるかどうかは、
そう明白なことではありません。
潜在的なセキュリティの脅威であるかも知れないことも。
</para>

<para>

 Newer Linux releases seem to be more security conscious, making it less
 likely to have unnecessary services running. This is good. But we can't be
 sure unless we know how to verify this for ourselves.

  より新しい Linux のリリース版はセキュリティの問題により意識的で、
不必要なサーヴィスがあまり走らないようになっています。
これは結構なことです。しかし、
自分自身の手でこれを確かめる方法を知らないことには安心できません。
</para>
-->
<para>
<!--
 Our goal is to turn off as many services as possible. If we can turn them 
 all off, or at least off to outside connections, so much the better. Some
 rules of thumb we will use to guide us:
-->
  ここでの目的は可能な限り多くのサーヴィスを停止することです。
もし、その全部を停止できるなら、
または少なくとも外部に接続しているものを止められるなら、
大変に結構なことです。
以下に手引きにする簡単なルールを挙げましょう：
</para>

<para>
 <itemizedlist>

<listitem>
  <para>
<!--
   It is perfectly possible to have a fully functional Internet connection
   with no servers running that are accessible to outside connections. Not 
   only possible, but desirable in many cases. The principle here is that 
   you will never be successfully broken into via a port that is not opened 
   because no server is listening on it. No server == no port open == not
   vulnerable. At least to outside connections.
-->
  外部からアクセス可能であるようなサーヴィスが一つも走っていなくても、
十分完全なインターネット接続を持つことは完璧に可能です。
可能であるだけでなく、多くの場合それが望ましくもあります。
ここでの原則は、
そもそも開いていないポートを通って首尾よく侵入することは
決して出来ないということです。
なぜなら、開いていなければ、
どのサーバもそこで listen して（耳をすませて）いないからです。
サーバなし、開いているポートなし、弱点もなし、です。
すくなくとも外部からの接続に関してはそうです。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   If you don't recognize a particular service, chances are good you don't 
   really need it. We will assume that and so we'll turn it off. This may 
   sound dangerous, but is a good rule of thumb to go by. 
-->
  もしあなたがあるサーヴィスを認識していないとすると、
本当にはそれを必要としていない可能性はかなりあります。
そう仮定して、それを停止してしまうことにしましょう。
これは危険に聞こえるかもしれませんが、頼るに足るなかなか良いルールです。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Some services are just not intended to be run over the Internet &#045;&#045; even 
   if you decide it is something you really do need. We'll flag these
   as dangerous, and address these in later sections, should you decide 
   you do really need them, and there is no good alternative.
-->
  いくつかのサーヴィスはそもそも、
インターネット上を走らせるように設計されていません。
もしあなたがそれを本当に必要なものだと決定したとしても。
これらについては危険だと旗を立てておいて、後の章で取り組むことにしますので、
それらが本当に必要なサーヴィスで、
他に良い代替策がない場合には、そちらを見てください。
  </para>
 </listitem> 

 </itemizedlist>
</para>



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="audit">
<title><!--System Audit-->システム検査</title>
<para>
<!--
 So what is really running on our system anyway? Let's not take anything for 
 granted about what <quote>should</quote> be running, or what we
 <quote>think</quote> is running.
-->
  それで、結局このシステムでは実際に何が走っているのでしょうか？
動いているに<quote>違いない</quote>ものや、
または、<quote>そう思っている</quote>ものが実際に動いているかどうか、
何もかも当然のことだと思うのはやめましょう。
</para>

<![%linuxall;[ 
<para>
<!--
 Unfortunately, there is no such things as a standard Linux installation. The 
 wide variety of servers available, coupled with each particular distribution's 
 installation options, make providing a ready made list impossible. The best 
 that can be done is show you how to list all running services, and point you 
 in the right general direction.
-->
  残念ながら、標準の Linux インストールといったものは存在しません。
可能なサーヴィスには幅広いバラエティがあり、
各ディストリビューションにはそれぞれのインストールオプションが伴っていて、
前もってそのリストを準備することは不可能です。
最善のことは、動いている全てのサーヴィスを数え上げる方法を示し、
正しい普遍的な方向へ導くことです。
</para>
 ]]>
<![%redhat;[ 
<para>
<!--
  Which services get installed and started will vary greatly depending on
  which version of Red Hat, and which installation options were chosen. 
  Earlier releases were very much prone to start many services and then let 
  the user figure out which ones were needed, and which ones weren't. Recent 
  versions are much more cautious. But this makes providing a ready made list 
  of likely services impossible. Not to worry, as we shouldn't trust what is 
  <emphasis>supposed</emphasis> to be running anyway. What we need to do 
  is list for ourselves all running services. 
-->
  どのサーヴィスがインストールされていて、実際動いているかは、
Red Hat のどのバージョンが選ばれているか、
どのインストールオプションが選択されているかに強く依存します。
初期のリリースでは多くのサーヴィスをスタートさせる傾向が大いにありましたし、
それゆえにユーザにどれが必要でどれがそうでないかを考えさせていました。
最近のバージョンでははるかに用心深くなっています。
しかし、これによって、動いているであろうサーヴィスを事前に数え上げる
ことが不可能になっています。
しかし、ご心配なく。
そもそも、動いている<emphasis>であろう</emphasis>、
などと勝手に決め付けたサーヴィスを信用すべきでないからです。
しなければならないことは、
動作中の全てのサーヴィスのリストを作ることです。
</para>
]]>

<para>
<!--
 Now open an <command>xterm</command>, and <command>su</command> to root.
 You'll need to widen the window wide so the lines do not wrap. Use this
 command: <literal>netstat -tap |grep LISTEN</literal>. This will give us a
 list of all currently running servers as indicated by the keyword
 <literal>LISTEN</literal>, along with the <quote>PID</quote> and
 <quote>Program Name</quote> that started each particular service.
-->
  さあ、<command>xterm</command> を開いて、
<command>su</command> でルートになりましょう。
行が折り返されないようにウィンドウを広げる必要があるでしょう。
コマンド、<literal>netstat -tap |grep LISTEN</literal>
を使ってください。これによって、<literal>LISTEN</literal>
というキーワードが示されている全ての現在動作中のサーバが、
各サーヴィスをスタートさせた <quote>PID</quote> と
<quote>プログラム名</quote> とともに、リストアップされます：
</para>

<para>
 <screen>

# netstat -tap |grep LISTEN
  *:exec               *:*        LISTEN    988/inetd          
  *:login              *:*        LISTEN    988/inetd          
  *:shell              *:*        LISTEN    988/inetd          
  *:printer            *:*        LISTEN    988/inetd          
  *:time               *:*        LISTEN    988/inetd          
  *:x11                *:*        LISTEN    1462/X              
  *:http               *:*        LISTEN    1078/httpd          
  bigcat:domain        *:*        LISTEN    956/named           
  bigcat:domain        *:*        LISTEN    956/named           
  *:ssh                *:*        LISTEN    972/sshd            
  *:auth               *:*        LISTEN    388/in.identd
  *:telnet             *:*        LISTEN    988/inetd          
  *:finger             *:*        LISTEN    988/inetd
  *:sunrpc             *:*        LISTEN    1290/portmap
  *:ftp                *:*        LISTEN    988/inetd
  *:smtp               *:*        LISTEN    1738/sendmail: accepting connections 
  *:1694               *:*        LISTEN    1319/rpc.mountd
  *:netbios-ssn        *:*        LISTEN    422/smbd

 </screen>
</para>

<para>
<!--
 <![%redhat;[ Red Hat 7.x and Mandrake 8.x and later users will have
 <literal>xinetd</literal> in place of <literal>inetd</literal>.]]> Note the
 first three columns are cropped above for readability. If your list is as
 long as the example, you have some work ahead of you! It is highly unlikely
 that you really need anywhere near this number of servers running. 
-->
 <![%redhat;[ Red Hat 7.x と Mandrake 8.x とそれ以降のバージョンの
ユーザは <literal>inetd</literal> のところが
<literal>xinetd</literal> になっているでしょう。]]>
上では、
はじめの三つのコラムは見やすいように省いてあることに注意してください。
もしあなたが得たリストが上の例と同じくらい長いものなら、
これから少なからぬ仕事が待ち構えていますよ！
これに近い数のサーバが実際に動いている必要があることは、
まったくありそうにないことですから。
</para>

<para>
<!--
 Please be aware that the example above is just one of many, many possible
 system configurations. Yours probably does look very different.
-->
  上の例はたくさんのシステム設定のほんの一つの例に過ぎない、
ということに注意してください。
あなたの場合にはずいぶんと違ったものであるかも知れません。
</para>

<para>
<!--
 You don't understand what any of this is telling you? Hopefully then, you've
 read the <command>netstat</command> <link linkend="netstat">tutorial</link>
 in the Appendix, and understand how it works. Understanding exactly what each
 server is in the above example, and what it does, is beyond the scope of this
 document. You will have to check your system's documentation (e.g.
 Installation Guide, man pages, etc) if that service is important to you.  For
 example, does <quote>exec</quote>, <quote>login</quote>, and <quote>shell</quote> 
 sound important? Yes, but these are not what they may sound like. They 
 are actually <command>rexec</command>, <command>rlogin</command>, and
 <command>rsh</command>, the <quote>r</quote> (for remote) commands. These are 
 antiquated, unnecessary, and in fact, are very dangerous if exposed to the
 Internet.
-->
  このどれも何のことやら分らない？
補遺の<command>netstat</command> の
 <link linkend="netstat">チュートリアル</link>を読んで、
その働きを理解してくれていることと思いますが、
上に挙げた例で各サーバが何なのか、何をするものかを、
正確に理解することは、この文書の範囲に含まれません。
もし、そのサーヴィスが実際に重要なものならば、
個々のシステムについての文書（例えば、インストールガイドや、
man ページなど）を調べなければならないでしょう。
例えば、<quote>exec</quote>, <quote>login</quote>, <quote>shell</quote> 
は重要そうに見えますか？もちろんそうです。
しかし、これらは実際はその見かけ通りのものではありません。
実のところ、それらは
<command>rexec</command>, <command>rlogin</command>, 
 <command>rsh</command>  といった<quote>r</quote> コマンド、
つまりリモート用のコマンドです。
これらは古臭くて、不必要で、実際のところ、
インターネットにさらしていると非常に危険です。
</para>

<para>
<!--
 Let's make a few quick assumptions about what is necessary and unnecessary,
 and therefore what goes and what stays on bigcat. Since we are running a
 desktop on bigcat, <application>X11</application> of course needs to stay. If
 bigcat were a dedicated server of some kind, then X11 would be unnecessary. If
 there is a printer physically attached, the printer (lp) daemon should stay.
 Otherwise, it goes. Print servers may sound harmless, but are potential
 targets too since they can hold ports open. If we plan on logging
 <emphasis>in to</emphasis> bigcat <emphasis>from</emphasis> other hosts,
 sshd (Secure SHell Daemon) would be necessary. If we have Microsoft hosts on
 our LAN, we probably want <application>Samba</application>, so
 <application>smbd</application> should stay. Otherwise, it is completely
 unnecessary. Everything else in this example is optional and not required for
 a normally functioning system, and should probably go. See anything that you
 don't recognize? Not sure about? It goes!
-->
  何が必要で何が必要でないか、
そして何を捨てて何をこの bigcat においておくか
について簡単な仮説を二、三、用意しておきましょう。
bigcat はデスクトップで走らせていますから、
もちろん <application>X11</application> は残す必要があります。
もし bigcat が何かのサーバ専門に使われていたなら、
X11 は不要だったでしょう。
もし物理的につながったプリンタがあるなら、
プリンタ (lp) デーモンは残すべきです。そうでないなら要りません。
プリントサーバは無害そうに見えますが、ポートを開いたままに出来るので、
やはり潜在的なターゲットになります。
もし他のホスト<emphasis>から</emphasis> bigcat <emphasis>の中に</emphasis>
ログインする予定があるなら、
sshd （セキュアシェルデーモン）が必要でしょう。
我々の LAN に Microsoft のホストがあるならば、
<application>Samba</application> が欲しいかもしれません。
でしたら、<application>smbd</application> は残さなくてはいけませんが、
そうでなければ全く不必要です。
この例ではその他のものは全部、（選択するのは自由ですが、）
通常の機能のシステムなら不必要で、おそらく切り捨てるべきでしょう。
あなたが認識していないものがある？あやふやなものがある？
それは切りましょう！
</para>

<para>
<!--
 To sum up: since bigcat is a desktop with a printer attached, we will 
 need <quote>x11</quote>, <quote>printer</quote>. bigcat is on a LAN with 
 MS hosts, and shares files and printing with them, so
 <quote>netbios-ssn</quote> (<command>smbd</command>) is desired. We will also
 need <quote>ssh</quote> so we can login from other machines. Everything else
 is unnecessary for this particular case. 
-->
  結論：bigcat はプリンタがつながっているデスクトップマシンですから、
<quote>x11</quote> と <quote>printer</quote> が必要になるでしょう。
bigcat は MS ホストとともに LAN 上にあって、ファイルを共有したり、
それらから印刷したりしますから、
<quote>netbios-ssn</quote> (<command>smbd</command>)
が必要です。また他のマシンからログインできるように、
<quote>ssh</quote> も必要です。
この特定の場合においては、その他のものは全て不必要です。
</para>

<para>
<!--
 Nervous about this? If you want, you can make notes of any changes you make
 or save the list of servers you got from <command>netstat</command>, with
 this command: <literal>netstat -tap |grep LISTEN > ~/services.lst</literal>.
 That will save it your home directory with the name of
 <quote>services.lst</quote> for future reference.
-->
  これが心配ですか？そうなら、
自分が行った変更を書き留めておくか、または、コマンド：
<literal>netstat -tap |grep LISTEN > ~/services.lst</literal>を使って、
<command>netstat</command> から得たサーバのリストを保存して
おくのがよいでしょう。
このコマンドで将来に参照するためのリストが <quote>services.lst</quote>
の名前でホームディレクトリに保存されます。
</para>

<para>
<!--
 This is to not say that the ones we have decided to keep are inherently safe.
 Just that we probably need these. So we will have to deal with these via
 firewalling or other means (addressed below).
-->
ここで残すことに決めたものも、
そもそも安全なものだとは言えません。
単に、これらが必要であろう、というだけです。
ですから、
ファイアーウォールや（以下にあるような）他の方法を通して、
これらを扱わなければいけません。
</para>

<para>
<!--
 It is worth noting that the <command>telnet</command> and
 <command>ftp</command> daemons in the above example are
 <emphasis>servers</emphasis>, aka <quote>listeners</quote>. These accept
 incoming connections to you. You do not need, or want, these just to use
 <command>ftp</command> or <command>telnet</command>
 <emphasis>clients</emphasis>. For instance, you can download files from an
 FTP site with just an <command>ftp</command> client. Running an
 <application>ftp</application> server on your end is not required at all, and
 has serious security implications.
 -->
   上の例の中の <command>telnet</command> と <command>ftp</command>
デーモンは<emphasis>サーバ</emphasis>であり、
<quote>リスナー</quote>（ポートで耳をすませているもの）だということは、
注意しておく価値があるでしょう。
これらはあなたのマシンに入ってくる接続を受け付けます。
あなたが単に <command>ftp</command> または <command>telnet</command>
 <emphasis>クライアント</emphasis>を使うためには、
これらは必要ないし、望んでもいないことです。
例えば、あなたは単に <command>ftp</command> クライアントを用いて、
FTP サイトからファイルをダウンロードすることができます。
あなたの側で <application>ftp</application> 
サーバを走らせる必要はまったくありませんし、
深刻なセキュリティ上の問題を持つことになります。
</para>

<para>
<!--
 There may be individual situations where it is desirable to make exceptions
 to the conclusions reached above. See <link linkend="exceptions">below</link>.
-->
  個々の事情によっては、
上で得た結論に例外を設けた方が良いこともあるでしょう。
<link linkend="exceptions">後の章</link>を参照してください。

</para>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="danger">
<title><!--The Danger Zone (or r00t m3 pl34s3)-->危険地帯（または r00t m3 pl34s3）</title>
<para>
<!--
 The following is a list of services that should <emphasis>not</emphasis> be
 run over the Internet. Either disable these (see below), uninstall, or if you
 really do need these services running locally, make sure they are the
 current, patched versions <emphasis>and</emphasis> that they are effectively
 firewalled. And if you don't have a firewall in place now, turn them off
 until it is up and verified to be working properly. These are potentially
 insecure by their very nature, and as such are prime cracker targets. 
-->
  以下はインターネット上で走らせるべきで<emphasis>ない</emphasis>
サーヴィスのリストです。
これらは動かないようにしておくか（以下を見てください）、
アンインストールしてください。または、
もし本当にこれらのサーヴィスをローカルで走らせたいなら、
それらが最新のパッチを当てたバージョンであり、<emphasis>かつ</emphasis>、
効果的にファイアーウォールで守られていることを確認してください。
そして、今のところファイアーウォールを持っていないというなら、
ファイアーウォールが立ち上がって適切に動いていることが検証されるまで、
それらのサーヴィスを止めておいてください。
これらはその性質からして潜在的に危険であり、
クラッカーの一番の標的になります。
</para>

<para>
 <itemizedlist>
 
 <listitem>
  <para>
<!--
   <application>NFS</application> (Network File System) and related services,
   including <application>nfsd</application>,
   <application>lockd</application>, <application>mountd</application>,
   <application>statd</application>, <application>portmapper</application>,
   etc. NFS is the standard Unix service for sharing file systems across a
   network. Great system for LAN usage, but dangerous over the Internet.
   And its completely unnecessary on a stand alone system.
-->
  <application>NFS</application>
 (Network File System ネットワークファイルシステム)と、
<application>nfsd</application>, <application>lockd</application>,
 <application>mountd</application>, <application>statd</application>,
 <application>portmapper</application> などの、その関連サーヴィス。
NFS はネットワークを経由してファイルシステムを共有する標準の Unix
サーヴィスです。LAN で用いるには素晴らしいシステムですが、
インターネット上では危険です。そして、
スタンドアローンのシステムではまったく不要なものです。
  </para> 
 </listitem> 

 <listitem>
  <para>
<!--
   rpc.* services, Remote Procedure Call.*, typically NFS and NIS related (see
   above). 
-->
  rpc.* サーヴィス、リモートプロシージャ Call.*, など。
典型的なのは NFS と NIS に関係したもの（上を参照）です。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Printer services (<application>lpd</application>).
-->
  プリンタサーヴィス（<application>lpd</application>）
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   The so-called r* (for <quote>remote</quote>, i.e. Remote SHell) services:
   <application>rsh</application>, <application>rlogin</application>,
   <application>rexec</application>, <application>rcp</application> etc.
   Unnecessary, insecure and potentially dangerous, and better utilities are
   available if these capabilities are needed. <application>ssh</application>
   will do everything these command do, and in a much more sane way. See the
   man pages for each if curious.  These will probably show in
   <command>netstat</command> output without the <quote>r</quote>:
   <command>rlogin</command> will be just <quote>login</quote>, etc.
-->
  いわゆる r* サーヴィス
（<quote>remote</quote> つまり、Remote SHell の r ）：
<application>rsh</application>, <application>rlogin</application>,
 <application>rexec</application>, <application>rcp</application> など。
不必要で、安全でなく、潜在的に危険で、
もしこれらの機能が必要なときにはより良いユーティリティがあります。
<application>ssh</application> はこれらのコマンドに出来ることは
何でも出来るでしょうし、しかもはるかに健全な方法でできます。
興味があるならそれぞれの man ページを見てください。
これらは多分、
<quote>r</quote> 抜きで <command>netstat</command> 出力に
示されているでしょう：
例えば、<command>rlogin</command> は単に <quote>login</quote> など。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   <application>telnet</application> server. There is no reason for this
   anymore. Use <application>sshd</application> instead.
-->
  <application>telnet</application> サーバ。
もはやこれを用いる理由はありません。代わりに
<application>sshd</application> を使ってください。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   <application>ftp</application> server. There are better, safer ways for
   most systems to exchange files like <command>scp</command> or 
   via <command>http</command> (see below). <application>ftp</application> is a
   proper protocol only for someone who is running a dedicated ftp server, and
   who has the time and skill to keep it buttoned down. For everyone else, it is
   potentially big trouble. 
-->
  <application>ftp</application> サーバ。ほとんどのシステムには、
<command>scp</command> や、<command>http</command> 経由などの
（以下を参照のこと）、
ファイルを交換するためのより良い、もっと安全な方法があります。
<application>ftp</application> は専用の ftp サーバを走らせていて、
ちゃんとその面倒を見る時間とスキルのある人にとってだけ
適切なプロトコルです。そうでなければ、
潜在的に大きなトラブルの原因になります。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   <application>BIND</application> (<command>named</command>), DNS server
   package. With some work, this can be done without great risk, but is not
   necessary in many situations, and requires special handling no matter
   how you do it. See the sections on <link
   linkend="exceptions">Exceptions</link> and special handling for <link
   linkend="indapps">individual applications</link>. 
-->
  <application>BIND</application> (<command>named</command>),
DNS パッケージ。いくらか手をかければ、
これは大きなリスクなしに使えますが、多くの場合には必要のないものですし、
それをどう使うにせよ特別な扱いが要求されます。
<link linkend="exceptions">例外</link>の章と、
<link linkend="indapps">個別のアプリケーション</link>
の特別な扱い方を参照してください。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Mail Transport Agent, aka <quote>MTA</quote>
   (<application>sendmail</application>, <application>exim</application>,
   <application>postfix</application>, <application>qmail</application>).
   Most installations on single computers will not really need this. If you are not
   going to be directly receiving mail from Internet hosts (as a designated MX
   box), but will rather use the POP server of your ISP, then it is not
   needed. You may however need this if you are receiving mail
   <emphasis>directly</emphasis> from other hosts on your LAN, but initially
   it's safer to disable this. Later, you can enable it over the local
   interface once your firewall and access policies have been implemented.
  -->
  メイル配送エージェント、つまり <quote>MTA</quote>
(<application>sendmail</application>, <application>exim</application>,
 <application>postfix</application>, <application>qmail</application>)。
一台のコンピュータ上のインストールではほとんどの場合、
これらが本当に必要になることはないでしょう。
あなたが、インターネットホストから（指定された MX box として）
直接にメイルを受け取るのではなく、
プロバイダの POP サーバを使うのなら必要ありません。
LAN 上の他のホストから<emphasis>直接</emphasis>
メイルを受け取っているのならば、必要かもしれませんが、
最初はこれを動かさない方が安全です。
後に、ファイアーウォールとアクセスポリシーが設定されてから、
ローカルインターフェース上で動かすことができますから。
  </para>
 </listitem> 
 
 </itemizedlist>
</para>

<para>
<!--
 This is not necessarily a definitive list. Just some common services that 
 are sometimes started on default <![%redhat;[ Red Hat ]]> <![%linuxall;[ Linux
 ]]> installations. And conversely, this does not imply that other
 services are inherently safe. 
-->
  以上は必ずしも完全なリストではありません。
ただ、デフォルトの
<![%redhat;[ Red Hat ]]> <![%linuxall;[ Linux ]]>
インストールでは時々、
最初から動いているサーヴィスとして良く見られるものだということです。
そして逆に言えば、
このリストに出ていない他のサーヴィスがもとより
安全なものだということでもありません。
</para>

</sect2>


<!--  ~  End section  ~  -->


<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="stopservices">
<title><!--Stopping Services-->サーヴィスの停止</title>

<para>
<!--
 The next step is to find where each server on our kill list is being started. 
 If it is not obvious from the <command>netstat</command> output, use
 <command>ps</command>, <command>find</command>, <command>grep</command> or
 <command>locate</command> to find more information from the <quote>Program
 name</quote> or <quote>PID</quote> info in the last column. There is examples
 of this in the <link linkend="pid">Process Owner</link> section in the
 <command>netstat</command> Tutorial of the Appendix. If the service name or
 port number do not look familiar to you, you might get a real brief
 explanation in your <filename>/etc/services</filename> file.
-->
  次のステップは我々の「殺しのリスト」に挙がっている各サーバが
どこで開始されたのかを調べることです。
これが <command>netstat</command> の出力から明らかでないならば、
最後のコラムの <quote>Program name</quote> か <quote>PID</quote> の
情報から、<command>ps</command>, <command>find</command>,
 <command>grep</command>, <command>locate</command> などのコマンドを
使ってさらなる情報を得てください。
この例が補遺の <command>netstat</command> チュートリアルの
<link linkend="pid">プロセスの所有者</link> の章に挙げられています。
もしサーヴィス名かポート番号が馴染みのないものなら、
そのシステムの <filename>/etc/services</filename> ファイルに
簡単な解説があります。
</para>

<![%redhat;[ 
<para>
<!--
 <command>chkconfig</command> is a very useful command for controlling
 services that are started via init scripts (see example below). Also, where
 <application>xinetd</application> is used, it can control those services as
 well. <command>chkconfig</command> can tell us what services the system is
 configured to run, but not necessarily all services that are indeed actually 
 running. Or what services may be started by other means, e.g. from
 <filename>rc.local</filename>. It is a configuration tool, more than a 
 real time system auditing too.
-->
  <command>chkconfig</command> は init スクリプトで
開始されたサーヴィスをコントロールするには非常に便利なコマンドです
（以下の例を見てください）。
また、<application>xinetd</application> が使われているなら、
同様にそのサーヴィスもコントロールできます。
<command>chkconfig</command> は、
どのサーヴィスがそのシステムで走るように設定されているかを教えてくれますが、
これは必ずしも本当に、実際に、動作している全てのサーヴィスではありません。
つまり、他の方法で、例えば <filename>rc.local</filename> から、
開始されているかもしれないサーヴィスもあるからです。
それはリアルタイムのシステム監査ツールというよりも、
設定用のツールなのです。
</para>
]]>

<para>
<!--
 Skeptical that we are going to break your system, and the pieces won't go 
 back together again? If so, take this approach: turn off everything listed 
 above in <quote>The Danger Zone</quote>, and run your system for a while. OK? 
 Try stopping one of the ones we found to be <quote>unnecessary</quote> above. 
 Then, run the system for a while. Keep repeating this process, until you get 
 to the bare minimum. If this works, then make the changes permanent (see
 below).
-->
  今、我々は自分のシステムを壊しつつあって、
覆水盆に返らずなどということにならないか、
と心配しているのではないですか？
もしそうなら、こうしてみてください：
つまり、<quote>危険地帯</quote>で上のリストに挙がった全てを停止し、
そしてしばらくの間システムを走らせてみます。
大丈夫ですか？
上で不必要だと判断したものたちの一つを止めてみましょう。
それでしばらくシステムを走らせてみます。
この手続きを最小の状態になるまで繰り返します。
これがうまくいけば、この変更を採用してそのまま保ちましょう。
（以下を参照してください。）
</para>

<para>
<!--
 The ultimate objective is not just to stop the service now, but to make sure
 it is stopped permanently! So whatever steps you take here, be sure to check
 after your next reboot.
-->
  究極の目的は今そのサーヴィスを停止することではなくて、
それが恒常的に停止されていることをはっきりさせることです！
ですから、あなたがここでどのようなステップをとったにせよ、
次にリブートした後には必ず確認してください。
</para>

<para>
<!--
 There are various places and ways to start system services. Let's look at the
 most common ways this is done, and is probably how your system works. System
 services are typically either started by <quote>init</quote> scripts, or by
 <command>inetd</command> (or its replacement <command>xinetd</command>) on
 most distributions. <![%linuxall;[ (The location of the init scripts may vary
 from distribution to distribution.) ]]>
-->
  システムのサーヴィスは様々の場所で色々な方法で開始されます。
その最も普通の方法を見てみましょう。
あなたのシステムもおそらくそのように動いているだろうと思います。
ほとんどのディストリビューションにおいて、
システムのサーヴィスは典型的には
<quote>init</quote> スクリプト、または <command>inetd</command>
（またはその代替物である <command>xinetd</command>）
のどちらかによって開始されます。
<![%linuxall;[ （init スクリプトの置かれている場所はディストリビューションによって、
様々かもしれません。） ]]>
</para>


<!--    ~~~~~       New section      ~~~~~     -->

<sect3 id="inits">
<title><!--Stopping Init Services-->init サーヴィスを停止する</title>

<para>
<!--
 Init services are typically started automatically during the boot process, or
 during a runlevel change. There is a naming scheme that uses symlinks to
 determine which services are to be started, or stopped, at any given
 runlevel. The scripts themselves should be in
 <filename>/etc/init.d/</filename> (or possibly
 <filename>/etc/rc.d/init.d/</filename> <![%redhat;[ for older versions of
 Red Hat]]>). <![%linuxall;[ This init style is used by Red Hat,
 SuSE, Mandrake, Debian, Conectiva, and most Linuxes. Slackware is one notable
 exception (though recent versions have an option for this)! Typically 
 on Slackware system services are all configured in one file: 
 <filename>/etc/rc.d/rc.inet2</filename>.]]> 
-->
  init サーヴィスは典型的には、ブートプロセス、
またはランレベルの切り替え時に自動的に開始されます。
どのサーヴィスをどのランレベルで開始し、停止するかを決定するためには、
シンボリックリンクを使う方法があります。
スクリプト自身は <filename>/etc/init.d/</filename> の中
（または、 <![%redhat;[ Red Hat の古いバージョンでは
]]><filename>/etc/rc.d/init.d/</filename> の中かもしれません）
に置かれているはずです。
<![%linuxall;[ 
この init の方式は Red Hat, SuSE, Mandrake, Debian, COnectiva
などほとんどの Linux で用いられています。
Slackware は注意すべき例外の一つです！
（最近のバージョンではこのオプションを持っていますが。）
典型的には Slackware ではシステムサーヴィスは一つのファイル
 <filename>/etc/rc.d/rc.inet2</filename> で全て設定されます。]]>
</para>

<para>
<!--
 You can get a listing of these scripts:
-->
  以下のようにすれば、
このスクリプトのリストを得ることができます。
</para>

<para>
 <screen>

<![%linuxall;[  # ls -l /etc/init.d/ | less ]]>
<![%redhat;[  # ls -l /etc/rc.d/init.d/ | less ]]>

 </screen>
</para>

<![%linuxall;[ 
<para>
<!--
 Or use whichever tools your distribution provides for this.
-->
  または各ディストリビューションで用意されている、
このためのツールを使ってください。
</para>
]]>

<para>
<!--
 To stop a running service now, as root<![%linuxall;[ (on SysVinit style systems,
  which is pretty much everybody)]]>:
 -->
<![%linuxall;[
（非常に一般的な SysV init スタイルのシステムでは）]]>
走っているサーヴィスを今、止めるには、
root になって以下のようにします：
</para>

<para>
 <screen>

 # /etc/init.d/&lt;$SERVICE_NAME&gt; stop

 </screen>
</para>

<para>
<!--
 Where <quote>$SERVICE_NAME</quote> is the name of the init script, which is
 often, but not always, the same as the service name itself. <![%linuxall;[
 This should do the trick on <emphasis>most</emphasis> distributions.]]> Older
 Red Hat versions may use the path <filename>/etc/rc.d/init.d/</filename>
 instead. 
-->
  ここで <quote>$SERVICE_NAME</quote> はその init スクリプトの名前で、
常にではありませんが、しばしばそのサーヴィスの名前そのものと同じです。
<![%linuxall;[これは<emphasis>ほとんどの</emphasis>ディストリビューション上で
使える手です。]]>
古い Red Hat バージョンでは代わりに
<filename>/etc/rc.d/init.d/</filename> 
がパスになっているかもしれません。
</para>

<para>
<!--
 This only stops this particular service now. It will restart again on the 
 next reboot, or runlevel change, unless additional steps are taken. So this is 
 really a two step process for init type services.
-->
  これはこの特定のサーヴィスを今、停止することができるだけで、
追加的なステップをとらなければ、
次のリブート時、またはランレベル変更時には再スタートしてしまいます。
ですから、init 型のサーヴィスについては、
この作業は実際二段階のプロセスということになります。
</para>

<![%linuxall;[ 
<para>
<!--
 Your distribution will have utilities available for controlling which services 
 are started at various runlevels. Debian based systems have 
 <command>update-rc.d</command> for this, and Red Hat based systems have 
 <command>chkconfig</command>. If you are familiar with these tools, 
 do it now, and then check again after the next reboot. If you are not 
 familiar with these tools, see the man pages and learn it now! This is
 something that you need to know. For Debian (where
 <literal>$SERVICE_NAME</literal> is the init script name):
-->
  各ディストリビューションでは、
様々なランレベルでどのサーヴィスを開始させるかを
制御するためのユーティリティが使えるようになっているでしょう。
Debian に基づいたシステムではこのための
 <command>update-rc.d</command> がありますし、
Red Hat に基づいたシステムでは <command>chkconfig</command> があります。
これらのツールに慣れ親しんでいるなら、
今それを使って、次のリブートの後に再チェックしてください。
これらのツールに慣れていないのでしたら、
man ページを見て今、勉強しましょう！
これは知っていなくてはならないものです。
Debian では次のようにします
（以下で、<literal>$SERVICE_NAME</literal> は
init スクリプトの名前です）：
</para>

<para>
 <screen>
 
  # update-rc.d -f $SERVICE_NAME remove
 
 </screen>
</para>

<para>
<!--
 And Red Hat:
-->
  Red Hat では：
</para>

<para>
 <screen>
 
 # chkconfig $SERVICE_NAME off
 
 </screen>
</para>

]]>

<![%redhat;[ 
<para>
<!--
 <command>chkconfig</command> can be used to see what services are 
 started at each runlevel, and to turn off any unneeded services. To view 
 <emphasis>all services</emphasis> under its control, type this command
 in an <application>xterm</application>:
-->
  <command>chkconfig</command> は、
どのサーヴィスが各ランレベルで開始されているかを調べるために、
そして不必要なサーヴィスを停止するために使うことができます。
制御下にある<emphasis>全てのサーヴィス</emphasis>を見るには、
 <application>xterm</application> で以下のコマンドをタイプしてください：
</para>

<para>
 <screen>
 
 # chkconfig --list | less
 
 </screen>
</para>

<para>
<!--
 To view only the ones that are <quote>on</quote>:
-->
  <quote>オン</quote>になっているものだけを見るには
次のようにします：
</para>

<para>
 <screen>
 
 # chkconfig --list | grep "\bon\b" | less
 
 </screen>
</para>

<para>
<!--
 The first column is the service name, and the remaining columns are the various 
 runlevels. We need generally only worry about runlevels 3 (boot
 to text console login) and 5 (boot straight to X11 login).
 <application>xinetd</application> services won't have columns, since that 
 aspect would be controlled by <application>xinetd</application> itself.
-->
  最初のコラムはそのサーヴィスの名前で、
残りのコラムは様々なランレベルです。
我々が心配する必要があるのは、
一般的にはランレベル３（テキストコンソールログインのためのブート）
とレベル５（すぐ X11 ログインするためのブート）
についてだけです。
<application>xinetd</application> サーヴィスはコラムを持ちません。
と言うのも、
<application>xinetd</application> 自身によって制御されているからです。
</para>

<para>
<!--
 Examples of commands to turn services <quote>off</quote>:
-->
  サーヴィスを<quote>オフ</quote>にするためのコマンドの例：
</para>

<para>
 <screen>
 
 # chkconfig portmapper off
 # chkconfig nfs off
 # chkconfig telnet off
 # chkconfig rlogin off
 
 </screen>
</para>

<para>
<!--
 Note that the last two are <application>xinetd</application> services.
 A very easy and nifty tool to use! Red Hat also includes <command>ntsysv</command>
 and <command>tksysv</command> (GUI) for runlevel and service configuration.
 See the man pages for additional command line options.
-->
  最後の二つは <application>xinetd</application> サーヴィスである
ことに注意してください。
非常に簡単で素敵なツールがあります！
Red Hat はランレベルとサーヴィスの設定のためのコマンド
<command>ntsysv</command> と <command>tksysv</command> (GUI)
を用意しています。
追加するコマンドラインオプションについては man ページを見てください。
</para>
]]>

<!--
<para>
 If you are not sure how to go about this and are really, really desperate,
 run this command: 

</para>

<screen>

 # rm -frv /etc/init.d/S*

</screen>

WOWSER!!!!!!!!! Killing me softly, with his rm.


<para>
 Warning! This is an extreme approach, but will stop any init services from
 restarting. Please learn your distribution's method of doing this the
 <quote>right way
 </quote>.
 
</para>

-->

<para>
<!--
 Another option here is to uninstall a package if you know you do not need it. 
 This is a pretty sure-fire, permanent fix. This also alleviates the
 potential problem of keeping all installed packages updated and current (Step
 2). <![%linuxall;[ And, package management systems like
 <application>RPM</application> or <application>DEB</application> make it very
 easy to re-install a package should you change your mind.]]><![%redhat;[ 
 <application>RPM</application> makes it very easy to re-install a package 
 should you change your mind.]]>
 -->
  もしあるサーヴィスが必要でないことがわかっているなら、
また一つの手段はそのパッケージをアンインストールしてしまうことです。 
これはなかなか良い、間違いのない方法で、恒常的に停止できます。
またこの方法は、
インストールされているすべてのパッケージをアップデートして
最新のものに保ち続ける（ステップ２）、
という潜在的な問題を解決してくれてもいます。
<![%linuxall;[<application>RPM</application> や
 <application>DEB</application> 
といったパッケージ管理システムを使えば、
気が変わったときに
パッケージを再インストールするのもとても簡単です。]]><![%redhat;[
<application>RPM</application> を使えば、
あなたの気が変わったときに、
パッケージを再インストールするのもとても簡単です。]]>
</para>

<![%redhat;[ 
<para>
<!--
 To uninstall packages with <application>RPM</application>: 
-->
  <application>RPM</application> でパッケージをアンインストールするには
以下のようにします：
</para>

<para>
 <screen>

 # rpm -ev telnet-server  rsh  rsh-server

 </screen>
</para>

<para>
<!--
 The above command would uninstall the <quote>telnet server</quote> package 
 (but not telnet client!), <quote>rsh</quote> client and <quote>rsh
 server</quote> packages in one command. Red Hat also includes
 <application>gnorpm</application>, a GUI <application>RPM</application> 
 management utility which can do this as well.
-->
  上のコマンドはこれ一つで
<quote>telnet サーバ</quote> パッケージ
(telnet クライアントではありません！)、
<quote>rsh</quote> クライアントと <quote>rsh サーバ</quote> 
パッケージをアンインストールしてくれます。
Red Hat には <application>gnorpm</application> という
GUI による<application>RPM</application> 管理ユーティリティも含まれていて、
同じことが可能です。
</para>
]]>

</sect3>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect3 id="inetd">
<title><!--Inetd-->inetd</title>

<para>
<!--
 <application>Inetd</application> is called a <quote>super-daemon</quote> 
 because it is used to spawn sub-daemons. <command>inetd</command> itself will
 generally be started via init scripts, and will <quote>listen</quote> on the
 various ports as determined by which services are enable in its configuration
 file, <filename>/etc/inetd.conf</filename>. Any service listed here will be 
 under the control of <command>inetd</command>. Likewise, any of the listening 
 servers in <command>netstat</command> output that list <quote>inetd</quote> 
 in the last column under <quote>Program Name</quote>, will have been started
 by <command>inetd</command>.  You will have to adjust the
 <command>inetd</command> configuration to stop these services.
 <command>xinetd</command> is an enhanced <command>inetd</command> replacement,
 and is configured differently (see next section below). 
-->
  <application>inetd</application> はサブデーモンを生むために使われるので、
<quote>スーパーデーモン</quote> と呼ばれます。
<command>inetd</command> 自身は一般に init スクリプト経由で開始され、
設定ファイル <filename>/etc/inetd.conf</filename> で
可能になっているサーヴィスによって決まる様々なポートに
<quote>耳をすませる</quote>ことになります。 
ここで挙げられているどのサーヴィスも <command>inetd</command> に
制御されます。
同様に、<quote>プログラム名</quote>の後の最後のコラムに
<quote>inetd</quote> と書かれている <command>netstat</command> 出力
の中の listen している（つまり、耳をすませている）サーバは皆、
<command>inetd</command> によって開始されることになります。
これらのサーヴィスを停止するためには、
<command>inetd</command> の設定を調整する必要があるでしょう。
<command>xinetd</command> は <command>inetd</command> の
の拡張された代替物ですが、設定方法は異なります
（以下の次の章を見てください）。
</para>

<para>
<!--
 Below is a partial snippet from a typical <filename>inetd.conf</filename>. Any 
 service with a <quote>#</quote> at the beginning of the line is
 <quote>commented out</quote>, and thus ignored by <command>inetd</command>,
 and consequently disabled.
-->
  以下は典型的な <filename>inetd.conf</filename> からの抜粋です。
行の最初に <quote>#</quote> がついているサーヴィスは
<quote>コメントアウト</quote>されていて、
<command>inetd</command> には無視されるので、
結果として無効にされます。
</para>

<para>
 <screen>

#
# inetd.conf  This file describes the services that will be available
#    through the INETD TCP/IP super server.  To re-configure
#    the running INETD process, edit this file, then send the
#    INETD process a SIGHUP signal.
#
# Version:  @(#)/etc/inetd.conf  3.10  05/27/93
#
# Authors:  Original taken from BSD UNIX 4.3/TAHOE.
#    Fred N. van Kempen, &lt;waltje@uwalt.nl.mugnet.org&gt;
#
# Modified for Debian Linux by Ian A. Murdock &lt;imurdock@shell.portal.com&gt;
#
# Echo, discard, daytime, and chargen are used primarily for testing.
#
# To re-read this file after changes, just do a 'killall -HUP inetd'
#
#echo  stream  tcp  nowait  root  internal
#echo  dgram  udp   wait    root  internal
#discard  stream  tcp  nowait  root  internal
#discard  dgram  udp   wait    root  internal
#daytime  stream tcp   nowait  root  internal
#daytime  dgram  udp   wait    root  internal
#chargen  stream tcp   nowait  root  internal
#chargen  dgram  udp   wait    root  internal
time  stream    tcp   nowait  root  internal
#
# These are standard services.
#
#ftp     stream  tcp   nowait  root  /usr/sbin/tcpd  in.ftpd -l -a
#telnet  stream  tcp   nowait  root  /usr/sbin/tcpd  in.telnetd
#
# Shell, login, exec, comsat and talk are BSD protocols.
#
#shell  stream  tcp  nowait  root  /usr/sbin/tcpd  in.rshd
#login  stream  tcp  nowait  root  /usr/sbin/tcpd  in.rlogind
#exec   stream  tcp  nowait  root  /usr/sbin/tcpd  in.rexecd
#comsat dgram   udp  wait    root  /usr/sbin/tcpd  in.comsat
#talk   dgram   udp  wait    root  /usr/sbin/tcpd  in.talkd
#ntalk  dgram   udp  wait    root  /usr/sbin/tcpd  in.ntalkd
#dtalk  stream  tcp  wait    nobody /usr/sbin/tcpd in.dtalkd
#
# Pop and imap mail services et al
#
#pop-2   stream  tcp     nowait  root    /usr/sbin/tcpd  ipop2d
pop-3    stream  tcp     nowait  root    /usr/sbin/tcpd  ipop3d
#imap    stream  tcp     nowait  root    /usr/sbin/tcpd  imapd
#
# The Internet UUCP service.
#
#uucp  stream tcp nowait uucp /usr/sbin/tcpd  /usr/lib/uucp/uucico -l
#

&lt;snip&gt;

 </screen>
</para>

<para>
<!--
 The above example has two services enabled: <command>time</command> and 
 <command>pop3</command>. To disable these, all we need is to open the 
 file with a text editor, comment out the two services with a
 <quote>#</quote>, save the file, and then restart <command>inetd</command>
 (as root): 
-->
  上の例では二つのサーヴィス、
<command>time</command> と <command>pop3</command> が可能になっています。
これらを無効にするには、
テキストエディタでこのファイルを開いて、
この二つのサーヴィスを <quote>#</quote> でコメントアウトし、
ファイルを保存して、（ルートとして）<command>inetd</command> を
再スタートするだけです：
</para>

<para>
 <screen>

 <![%linuxall;[ # /etc/init.d/inetd restart  ]]>
 <![%redhat;[ # /etc/rc.d/init.d/inetd restart  ]]>

 </screen>
</para>

<para>
<!--
 Check your logs for errors, and run <command>netstat</command> again to 
 verify all went well.
-->
  エラーがないかログを調べて、
<command>netstat</command> を再び走らせ、
全てがうまく行っているか確かめてください。
</para>

<para>
<!--
 A quicker way of getting the same information, using <command>grep</command>:
-->
  同じ情報を手っ取り早く得るには、
以下のように <command>grep</command> を使います。
</para>

<para>
 <screen>

 $ grep  -v '^#' /etc/inetd.conf
 time     stream  tcp     nowait  root  internal
 pop-3    stream  tcp     nowait  root  /usr/sbin/tcpd  ipop3d

 </screen>
</para>

<para>
<!--
 Again, do you see anything there that you don't know what it is? Then in
 all likelihood you are not using it, and it should be disabled.
-->
  またしても、それが何だか知らないものが出てきましたか？
でしたら、十中八九あなたはそれを使っていないので、
無効化すべきです。
</para>

<para>
<!--
 Unlike the init services configuration, this is a lasting change so only 
 the one step is required.
-->
  init サーヴィスの設定とは違って、
これは後まで続く変更なので、必要なのはこのステップ一回だけです。
</para>

<para>
<!--
 Let's expose one myth that gets tossed around: you shouldn't disable a 
 service by commenting out, or removing, entries from 
 <filename>/etc/services</filename>. This may have the desired effect 
 in some cases, but is not the right way to do it, and may interfere 
 with the normal operation of other system utilities. 
-->
  あちこちに広がっている一つの神話を暴露しましょう：
<filename>/etc/services</filename> ファイルから
項目をコメントアウトしたり削除したりすることで、
サーヴィスを無効化すべきではありません。
これはある場合には、望んだ効果が得られるかもしれませんが、
正しい方法ではなく、他のシステムユーティリティの通常の操作を
邪魔することになるかもしれません。
</para>

</sect3>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->
<sect3 id="xinetd">
<title><!--Xinetd-->xinetd</title>

<para>
<!--
<application>xinetd</application> is an <application>inetd</application> replacement with 
enhancements. <![%redhat;[ Red Hat includes <application>xinetd</application> with 
7.0 and later releases. ]]> It essentially serves the same purpose as 
<application>inetd</application>, but the 
configuration is different. The configuration can be in the file 
<filename>/etc/xinetd.conf</filename>, or individual files in the directory 
<filename>/etc/xinetd.d/</filename>. 
<![%redhat;[ Configuration of individual services will be in the individual
files under <filename>/etc/xinetd.d/*</filename>.]]> Turning off
<application>xinetd</application> services is done by either deleting the
corresponding configuration section, or file. Or by using your text editor and
simply setting <literal>disable = yes </literal> for the appropriate service.
<![%redhat;[ Or by using <command>chkconfig</command>. ]]> Then, 
<application>xinetd</application> will need to be restarted. See <literal>man
xinetd</literal> and <literal>man xinetd.conf</literal> for syntax and
configuration options. A sample <command>xinetd</command> configuration:
-->
  <application>xinetd</application> は
拡張された機能を持つ <application>inetd</application> の代替物です。
<![%redhat;[ Red Hat は 7.0 以降のリリースから
 <application>xinetd</application> を含んでいます。]]>
これは本質的に <application>inetd</application> と同じ目的を果たしますが、
設定が異なります。
設定は <filename>/etc/xinetd.conf</filename> ファイルか、
 <filename>/etc/xinetd.d/</filename> ディレクトリの個別のファイルで
行うことができます。
<![%redhat;[個別のサーヴィスの設定は  <filename>/etc/xinetd.d/*</filename> 
以下の個別のファイルで行います。]]>
<application>xinetd</application> サーヴィスの停止は、
対応する設定箇所かファイルを削除することで可能です。
または、テキストエディタを用いて、単に適当なサーヴィスについて
 <literal>disable = yes </literal> と設定することでも可能です。
<![%redhat;[または、<command>chkconfig</command> でもできます。]]>
このとき、<application>xinetd</application> は再スタートする必要があります。
構文と設定オプションについては
<literal>man xinetd</literal> と <literal>man xinetd.conf</literal> 
を見てください。以下は<command>xinetd</command> の設定例です：
</para>

<para>
 <screen>

 # default: on
 # description: The wu-ftpd FTP server serves FTP connections. It uses \
 #       normal, unencrypted usernames and passwords for authentication.
 service ftp
 {
        disable                 = no
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/in.ftpd
        server_args             = -l -a
        log_on_success          += DURATION USERID
        log_on_failure          += USERID
        nice                    = 10
 }

 </screen>
</para>

<para>
<!--
You can get a quick list of enabled services:
-->
  以下のように、動作しているサーヴィスのリストを簡単に得ることができます。
</para>

<para>
 <screen>

 $ grep disable /etc/xinetd.d/* |grep no
 /etc/xinetd.d/finger:   disable = no
 /etc/xinetd.d/rexec:    disable = no
 /etc/xinetd.d/rlogin:   disable = no
 /etc/xinetd.d/rsh:      disable = no
 /etc/xinetd.d/telnet:   disable = no
 /etc/xinetd.d/wu-ftpd:  disable = no

 </screen>
</para>

<para>
<!--
 At this point, the above output should raise some red flags. In the 
 overwhelming majority of systems, all the above can be disabled without any
 adverse impact. Not sure? Try it without that service. After disabling
 unnecessary services, then restart <command>xinetd</command>:
-->
  ここで、上の出力にはいくつか赤信号が点いています。
圧倒的多数のシステムでは、上のどれも悪影響なしに停止できます。
確かかって？そのサーヴィスを停止して試してみてください。
不必要なサーヴィスを無効化して、<command>xinetd</command> を
再スタートさせてください。
</para>

<para>
 <screen>

 <![%linuxall;[ # /etc/init.d/xinetd restart  ]]>
 <![%redhat;[ # /etc/rc.d/init.d/xinetd restart  ]]>

 </screen>
</para>

</sect3>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect3>
<title><!--When All Else Fails-->全部失敗したときには</title>

<para>
<!--
 OK, if you can't find the <quote>right</quote> way to stop a service, 
 or maybe a service is being started and you can't find how or where, 
 you can <quote>kill</quote> the process. To do this, you will need to know
 the PID (Process I.D.). This can be found with <command>ps</command>, 
 <command>top</command>, <command>fuser</command> or other system utilities.
 For <command>top</command> and <command>ps</command>, this will be the number
 in the first column. See the <link linkend="pid">Port and Process Owner</link> 
 section in the Appendix for examples.
 -->
  もしあなたがサーヴィスを停止する<quote>正しい</quote>
方法を見つけられないとしても、または、
開始されているあるサーヴィスが
どうやってどこで開始されたのかわからないとしても、大丈夫。
そのプロセスを<quote>殺す</quote>ことができます。
これを行うには、PID（プロセスI.D.）を知る必要があります。
これは <command>ps</command>, <command>top</command>, 
<command>fuser</command> といったコマンド、
または他のシステムユーティリティを使って見つけることができます。
<command>top</command> と <command>ps</command> については、
最初のコラムに出ている数字がこれです。
例については、
補遺の<link linkend="pid">ポートとプロセスオーナー</link>を見てください。 
</para>

<para>
<!--
 Example (as root):
-->
  例（ルート権限で）：
</para>

<para>
 <screen>

 # kill 1163

 </screen>
</para>

<para>
<!--
 Then run <command>top</command> or <command>ps</command> again to verify 
 that the process is gone. If not, then:
-->
  そして、そのプロセスが消えていることを確認するために、
もう一度 <command>top</command> か <command>ps</command> を走らせてください。
</para>

<para>
 <screen>

 # kill -KILL 1163

 </screen>
</para>

<para>
<!--
 Note the second <quote>KILL</quote> in there. This must be done either 
 by the user who owns the process, or root. Now go find where and how this 
 process got started ;-)
-->
  この二番目に出ている <quote>KILL</quote> に注意してください。
この命令は、
そのプロセスを所有しているユーザか、またはルートのどちらかによって、
実行されなければなりません。さて、このプロセスがどこからどうやって
開始されたか調べにいきましょう ;-)
</para>

<para>
<!--
 The <filename>/proc</filename> filesystem can also be used to find out 
 more information about each process. Armed with the PID, we can find 
 the path to a mysterious process:
-->
  <filename>/proc</filename> ファイルシステムは各プロセスについての
さらなる情報を見つけ出すために用いることもできます。
PID を使って、謎のプロセスへのパスを見つけることができます。
</para>

<para>
 <screen>

 $ /bin/ps ax|grep tcpgate
  921 ?   S    0:00        tcpgate

 </screen>
</para>


<para>
 <screen>

 # ls -l /proc/921/exe
 lrwxrwxrwx 1 root  root  0 July 21 12:11 /proc/921/exe -> /usr/local/bin/tcpgate

 </screen>
</para>



</sect3>

</sect2>

<!--  ~  End section  ~  -->



<!--    ~~~~~       New section      ~~~~~     -->

<sect2 id="exceptions">
<title><!--Exceptions-->例外事項</title>

<para>
<!--
 Above we used the criteria of turning off <emphasis>all</emphasis> unnecessary
 services. Sometimes that is not so obvious. And sometimes what may be 
 required for one person's configuration is not the same for another's. 
 Let's look at a few common services that fall in this category.
 -->
  上では、<emphasis>全ての</emphasis>不必要なサーヴィスを
停止する基準を用いましたが、
時にそれはそんなに明白なことではありません。
そして、時折、ある人の設定で要求されていることは、
他の人にとってのものと異なるかも知れません。
このようなカテゴリーに入る二、三の一般的なサーヴィスを見てみましょう。 
</para>

<para>
<!--
 Again, our rule of thumb is if we don't need it, we won't run it. It's that
 simple. If we do need any of these, they are prime candidates for some 
 kind of restrictive policies via firewall rules or other mechanisms (see 
 below).
-->
  再び、我々の目安となるのは、
必要としていないものはそもそも走らせない、という単純なルールです。
もしそれらのどれも必要としていないなら、
ファイヤーウォールのルールや他の仕組み（以下を見てください）
によるこの種の制限ポリシーを運営するにあたって、
一番に停止するべき候補です。
</para>

<para>
 <itemizedlist>

  <listitem>
   <para>
<!--
    <application>identd</application> - This is a protocol that has been
    around for ages, and is often installed and running by default. It is used
    to provide a minimal amount of information about who is connecting to a
    server. But, it is not necessary in many cases. Where might you need it?
    Most IRC servers require it. Many mail servers use it, but don't really
    require it. Try your mail setup without it. If
    <application>identd</application> is going to be a problem, it will
    be because there is a time out before before the server starts sending or
    receiving mail. So mail should work fine without it, but may be slower. A
    few <application>ftp</application> servers may require it. Most don't
    though.
    <![%redhat;[ Older versions of Red Hat started
    <application>identd</application> via <application>inetd</application>.
    Recent versions start this via init scripts.]]> 
    -->
  <application>identd</application> - 
これはかなり年季の入ったプロトコルで、
しばしばデフォルトでインストールされ走っています。
これはサーバにつながっている者についての最小限の情報を得るためのものです。
しかし、これは多くの場合、必要ではありません。
では、どこで必要になるでしょうか？
ほとんどの IRC サーバはこれを必要とします。
多くのメイルサーバもこれを使っていますが、実際は必要ありません。
それ抜きでのメイル設定を試してみてください。
もし、<application>identd</application> が問題になるなら、
その理由はサーバがメイルを送ったり受け取ったりする前に
タイムアウトすることでしょう。
ですから、
メイルはそれ抜きでもちゃんと動くはずですが、
動作は遅くなるかもしれません。
二、三の <application>ftp</application> サーバはそれを必要とします。
しかし、ほとんどのものでは要りません。
<![%redhat;[Red Hat の古いバージョンでは
<application>identd</application> を <application>inetd</application>
経由で開始していました。
最近のバージョンでは init スクリプトで開始します。]]> 
   </para>

   <para>
<!--
    If <application>identd</application> is required, there are some 
    configuration options that can greatly reduce the information that is 
    revealed:
-->
  もし、<application>identd</application> が必要ならば、
以下のように、
報せる情報を大いに減らしてくれる設定オプションがあります：
   </para>

   <para>
    <screen>
   
    /usr/sbin/in.identd in.identd -l -e -o -n -N
    
    </screen>
   </para>

   <para>
<!--
    The <literal>-o</literal> flag tells <application>identd</application> to
    not reveal the operating system type it is run on and to instead always
    return <quote>OTHER</quote>. The  <literal>-e</literal> flag tells identd
    to always return <quote>UNKNOWN-ERROR</quote> instead of the
    <quote>NO-USER</quote> or <quote>INVALID-PORT</quote> errors. The
    <literal>-n</literal> flag tells identd to  always  return  user numbers
    instead of user names, if you wish to keep the user names a secret. The
    <literal>-N</literal> flag makes identd check for the file
    <filename>.noident</filename> in the user's home directory for which the
    daemon is about to return a user name. It that  file  exists then the
    daemon will give the error <quote>HIDDEN-USER</quote> instead of the
    normal <quote>USERID</quote> response.
-->
  <literal>-o</literal> フラッグは <application>identd</application> 
に、その上で走っているOS のタイプを示さず、
そのかわりに常に <quote>OTHER</quote> を返すよう伝えます。
<literal>-e</literal> フラッグは identd に、
<quote>NO-USER</quote> や <quote>INVALID-PORT</quote> エラーの代わりに
常に  <quote>UNKNOWN-ERROR</quote> を返すよう伝えます。
もしあなたがユーザ名を秘密にしておきたいなら、
<literal>-n</literal> フラッグは identd に、
ユーザ名の代わりに常にユーザ番号を返すように伝えます。
<literal>-N</literal> フラッグは identd に、
デーモンがユーザ名を返そうとしているそのユーザのホームディレクトリにある
 <filename>.noident</filename> をチェックさせます。
そのファイルが存在すれば、
デーモンは普通に <quote>USERID</quote> の代わりに
 <quote>HIDDEN-USER</quote> エラーを返します。
   </para>
   
  </listitem> 

  <listitem>
   <para>
<!--
     Mail server (MTA's like <application>sendmail</application>,
     <application>qmail</application>, etc) - Often a fully functional mail
     server like <application>sendmail</application> is installed by default.
     The only time that this is actually required is if you are hosting a
     domain, and receiving incoming mail directly. Or possibly, for exchanging
     mail on a LAN, in which case it does not need Internet exposure and can
     be safely firewalled. For your ISP's POP mail access, you don't need it
     even though this is a common configuration. One alternative here is to
     use <application>fetchmail</application> for POP mail retrieval with the
     <literal>-m</literal> option to specify a local delivery agent:
     <literal>fetchmail -m procmail</literal> for instance works with no
     sendmail daemon running at all. Sendmail, can be handy to have running,
     but the point is, it is not required in many situations, and can be
     disabled, or firewalled safely.
-->
  メイルサーバ（<application>sendmail</application>,
 <application>qmail</application> などのようなMTA）−
しばしば <application>sendmail</application> のような
完全な機能を持つメイルサーバがデフォルトでインストールされています。
これが実際に必要になるのは、ドメインのホストをしていて、
直接に入ってくるメイルを受け取るときだけです。
あるいは、LAN 上でメイルを交換するときですが、
この場合にはインターネットにさらす必要はありませんし、
安全にファイアーウォールで守ることができます。
プロバイダへの POP メイルアクセスのためには、
よく行われている設定ではありますが、
メイルサーバを必要としません。この代わりの手段の一つは、
ローカルな配送エージェントを <literal>-m</literal> オプションで
指定して <application>fetchmail</application> に POP メイルを
取りに行かせることです：
例えば、<literal>fetchmail -m procmail</literal> は
sendmail デーモンが全く走っていなくてもちゃんと働きます。
sendmail は走らせておくと便利なものではありますが、
ここでのポイントは、それは多くの場合は必要ではなく、
停止させるか、またはファイアーウォールで安全に守ることが出来る、
ということなのです。
   </para>
  </listitem> 

  <listitem>
   <para>
<!--
    <application>BIND</application> (named) - This often is installed by
    default, but is only really needed if you are an authoritative name server
    for a domain. If you are not sure what this means, then you definitely
    don't need it. BIND is probably the number one crack target on the
    Internet. <application>BIND</application> is often used though in a
    <quote>caching</quote> only mode. This can be quite useful, but does not
    require full exposure to the Internet. In other words, it should be
    restricted or firewalled. See special handling of <link linkend="indapps">individual applications</link> below.
    -->
      <application>BIND</application> (named) −
これはしばしばデフォルトでインストールされていますが、
実際に必要になるのは、あるドメインの、
オーソライズされたネームサーバを運用するときだけです。
もしあなたがこれが何を意味しているのかよくわからないなら、
これは絶対に不要です。おそらく、BIND はインターネット上で
一番狙われているターゲットでしょう。
<application>BIND</application> は、
<quote>キャッシング</quote> オンリーモードでしばしば用いられていて、
これは大変便利ですが、
インターネットに完全にさらす必要はありません。
つまり、それは適用を制限するか、
ファイアーウォールで守るべきです。
以下の <link linkend="indapps">個別のアプリケーション</link> の
特別な運用法の箇所を参照してください。
   </para>
  </listitem> 

 </itemizedlist>
</para>


</sect2>

<!--  ~  End section  ~  -->




<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="conclusions">
<title><!--Summary and Conclusions for Step 1-->ステップ１のまとめと結論</title>

<para>
<!--
 In this section we learned how to identify which services are running 
 on our system, and were given some tips on how to determine which 
 services may be necessary. Then we learned how to find where the services
 were being started, and how to stop them. If this has not made sense, 
 now is a good time to re-read the above.
-->
  この章では、
システム上でどんなサーヴィスが走っているかを同定する方法を学び、
どれが必要なサーヴィスかを決めるためのポイントをいくつか紹介しました。
さらに、そのサーヴィスがどこで開始されたのかを見つけ、
それらを停止する方法を学びました。
もしこれがよく分っていないようなら、今が上を読み返す良いチャンスです。
</para>

<para>
<!--
 Hopefully you've already taken the above steps. Be sure to test your results 
 with <command>netstat</command> again, just to verify the desired end has 
 been achieved, and only the services that are really required are running.
-->
  望むらくは、
あなたは上で示したステップを既にとってくれていることでしょう。
その結果を <command>netstat</command> で再度テストして、
望みの結果が達成されていること、そして、
本当に必要なサーヴィスだけが走っていることを確認してください。
</para>

<para>
<!--
 It would also be wise to do this after the next reboot, anytime you upgrade 
 a package (to make sure a new configuration does not sneak in), and after 
 every system upgrade or new install. 
-->
  次回のリブート時、パッケージを更新した時
（新しい設定がそっと忍び込んでいないことを確認するためです）、
そしてシステムがアップグレードされた時や新たにインストールされた時は常に、
このようなチェックをすることをお勧めします。
</para>

</sect2>

</sect1>

<!--  ~  End section  ~  -->





<!--   ~~~~~~~~       New section Header    ~~~~~~~~~     -->

<sect1 id="updates">
<title><!--Step 2: Updating-->ステップ２：アップデート作業</title>

<para>
<!--
 OK, this section should be comparatively short, simple and straightforward
 compared to the above, but no less important.
-->
  確かに、この章は上の章に比べて、短く、
単純で、直接的なものではありますすが、
上の章と同じくらい重要です。
</para>

<para>
<!--
 The very first thing after a new install you should check <![%linuxall;[ your
 distribution's updates and security notices and apply all patches]]>
 <![%redhat;[ the errata notices at <ulink
 url="http://redhat.com/errata/">http://redhat.com/apps/errata/</ulink>,
 and apply all relevant updates]]>. Only a year old you say? That's a long
 time actually, and not current enough to be safe. Only a few months or few
 weeks? Check anyway. A day or two? Better safe than sorry. It is quite
 possible that security updates have been released during the pre-release
 phase of the development and release cycle. If you can't take this step,
 disable any publicly accessible services until you can.
-->
  新たなインストールの後にまず最初にすべきことは、
<![%linuxall;[ ディストリビューションのアップデート情報とセキュリティの注意を
チェックして、すべてのパッチをあてることです。]]>
<![%redhat;[ <ulink url="http://redhat.com/errata/">http://redhat.com/apps/errata/</ulink> にある訂正情報をチェックして、
適切なアップデートを全て行うことです。]]>
たった一年古いだけじゃないか、ですって？
それは実際長い期間だし、安全のためには充分新しいとは言えません。
たった数ヶ月、またはたった数週間ですって？とにかくチェックしてください。
一日か二日？それでも後悔するよりはいいでしょう。
セキュリティ関係のアップデートが、
開発のプレリリースフェイズとリリースサイクルの間にリリースされていることは、
非常にありうることです。
もしこの作業ができないというなら、
できるまで公けにアクセス可能な公開サーヴィスは全て停止してください。
</para>

<para>
<!--
 Linux distributions are not static entities. They are updated with new, 
 patched packages as the need arises. The updates are just as important 
 as the original installation. Even more so, since they are fixes. Sometimes
 these updates are bug fixes, but quite often they are security fixes because
 some hole has been discovered. Such <quote>holes</quote> are
 <emphasis>immediately</emphasis> known to the cracker community, and they are
 quick to exploit them on a large scale. Once the hole is known, it is quite
 simple to get in through it, and there will be many out there looking for it.
 And Linux developers are also equally quick to provide fixes. Sometimes the
 same day as the hole has become known!
-->
  Linux のディストリビューションは静的なものではありません。
必要に応じて、新しい、パッチをあてられたパッケージに
アップデートされています。
アップデート作業はオリジナルのインストールと全く同じ程度に重要です。
いいえ、それらはフィックス（修復）である分、より重要でさえあります。
時に、これらのアップデートはバグ・フィックスですが、
もっとしばしば起こるのは、
新たにセキュリティホールが見つかったための、
セキュリティ・フィックスである場合です。
このような<quote>穴（セキュリティホール）</quote>
はクラッカーのコミュニティに<emphasis>ただちに</emphasis>知られます。
そして彼らはすばやくそれらを大きく広げ利用してしまうはずです。
一旦、セキュリティホールが知られたら、
それを通して侵入することは極めて簡単なことで、
それを探す者が沢山現れるでしょう。
そして Linux 開発者たちは同じくらい素早くフィックスします。
時には、セキュリティホールが知られたまさにその日に！
</para>

<para>
<!--
 Keeping <emphasis>all</emphasis> installed packages current with your release 
 is one of the most important steps you can take in maintaining a secure
 system. It can not be emphasized enough that all installed packages should be
 kept updated &#045;&#045; not just the ones you use. If this is burdensome, consider
 uninstalling any unused packages. Actually this is a good idea anyway. 
-->
  インストールされた<emphasis>全ての</emphasis>パッケージを
最新のものに保つことは、
安全なシステムを維持する上で最も重要なステップの一つです。
使用しているものだけではなく、
インストールされた全てのパッケージを最新に保つべきであることは、
いくら強調しても十分ではありません。
もしこれが面倒ならば、使わないパッケージを全てアンインストール
することを考えてください。実際、どうあれ、これは良い考えです。
</para>

<para>
<!--
 But where to get this information in a timely fashion? There are a number of
 web sites that offer the latest security news. There are also a number of
 mailing lists dedicated to this topic. <![%linuxall;[ In fact, your vendor
 most likely has such a list where vulnerabilities and the corresponding fix
 is announced. ]]> <![%redhat;[ In fact, Red Hat has the <quote>watch</quote>
 list, just for this purpose at <ulink
 url="https://listman.redhat.com/mailman/listinfo/redhat-watch-list">https://listman.redhat.com/mailman/listinfo/redhat-watch-list</ulink>. This is a very low 
 volume list by the way. ]]> This is an excellent way to stay abreast of
 issues effecting your release, and is <emphasis>highly
 recommended</emphasis>. <ulink
 url="http://linuxsecurity.com">http://linuxsecurity.com</ulink> is a good
 site for Linux only issues. They also have weekly newsletters available:
 <ulink
 url="http://www.linuxsecurity.com/general/newsletter.html">http://www.linuxsecurity.com/general/newsletter.html</ulink>.
 -->
  しかし、この最新情報をどこで手に入れられるのでしょう。
最新のセキュリティニュースを掲示しているウェブサイトはたくさんあります。
また、このトピックを扱っているメイリングリストもたくさんあります。
<![%linuxall;[ 実際、たいていの場合、システムの各ベンダ自身が、
弱点とそのフィックス法を発表するためのリストを公開しているでしょう。]]>
<![%redhat;[ 実際、Red Hat はまさにこの目的のために、
 <ulink
 url="https://listman.redhat.com/mailman/listinfo/redhat-watch-list">https://listman.redhat.com/mailman/listinfo/redhat-watch-list</ulink>
に<quote>監視</quote>リストを持っています。
ところで、これはとても簡潔なリストですが。]]>
これはリリースを最新のものに保ち続ける素晴らしい方法で、
<emphasis>強くお勧めします。</emphasis>
<ulink
 url="http://linuxsecurity.com">http://linuxsecurity.com</ulink>
 は Linux 限定の情報についての良いサイトです。
また週間のニュースレターも以下で手に入ります：
 <ulink
 url="http://www.linuxsecurity.com/general/newsletter.html">http://www.linuxsecurity.com/general/newsletter.html</ulink>.
</para>

<para>
<!--
 <![%linuxall;[ Also, many distributions have utilities that will automatically update your 
 installed packages via ftp. This can be run as a
 <application>cron</application> job on a regular basis and is a painless 
 way to go if you have ready Internet access.  ]]>
 <![%redhat;[ Red Hat also has the <application>up2date</application> utility 
 for automatically keeping your system(s) up to date ;-). See the man page 
 for details.]]>
-->
  <![%linuxall;[また、多くのディストリビューションでは、
ftp 経由で自動的にインストールしたパッケージを
更新してくれるユーティリティを用意しています。
これは通常業務として <application>cron</application> 
ジョブで走らせることも可能で、
もしインターネットアクセスが可能なら最も楽なやり方でしょう。]]>
<![%redhat;[Red Hat にはシステムを自動的に最新に保つための
 <application>up2date</application> ユーティリティもあります ;-)
詳しくは man ページを見てください。]]>
</para>

<!--
<para>
 If you are running public services over the Internet, you can further stay
 ahead of the curve, by running the latest version of these packages, whether
 they are an official update to your distribution or not. 

</para>
-->

<para>
<!--
 This is not a one time process &#045;&#045; it is ongoing. It is important to stay 
 current. So watch those security notices. And subscribe to 
 <![%linuxall;[  your vendor's ]]> <![%redhat;[ that ]]>
 security mailing list today! If you have cable modem, DSL, or other 
 full time connection, there is no excuse not to do this religiously. 
 All distributions make this easy enough!
 -->
  これは一度きりで終わるプロセスではありません -- 
ずっと続けていくものです。 最新に保つことが大事なのです。
ですからセキュリティ報告に常に注目していてください。
そして<![%linuxall;[各ベンダの]]><![%redhat;[上記の]]>
セキュリティメイリングリストを今日から購読してください！
もしあなたがモデム、DSL や、その他の常時接続の手段を持っているなら、
これを熱心に行わないことに弁解はありえません。
どのディストリビューションでもこれは充分に簡単なんですから！
</para>

<para>
<!--
 One last note: any time a new package is installed, there is also a 
 chance that a new or revised configuration has been installed as well. 
 Which means that if this package is a server of some kind, it may be 
 enabled as a result of the update. This is bad manners, but it can 
 happen, so be sure to run <application>netstat</application> or 
 comparable to verify your system is where you want it after any 
 updates or system changes. In fact, do it periodically even if there are no
 such changes.
-->
  最後の注意：新しいパッケージをインストールした時には常に、
新しい設定、
または改定された設定も同時にインストールされた可能性があります。
つまり、このパッケージがある種のサーバであれば、
アップデートの結果として動き出してしまっているかもしれないということです。
これは酷い作法ですが、実際ありえます。ですから、
アップデートかシステム変更の後にはいつでも、
確実に<application>netstat</application> か同等のものを走らせて、
システムが望むようになっていることを確認しましょう。
実際、このような変更がなくても、定期的に確認してください。
</para>


<!--   ~~~~~       New section      ~~~~~     -->

<sect2>
<title><!--Summary and Conclusions for Step 2-->ステップ２のまとめと結論</title>

<para>
<!--
 It is very simple: make sure your Linux installation is current. Check 
 <![%linuxall;[ with your vendor  ]]> <![%redhat;[ the Red Hat errata ]]> 
 for what updated packages may be available. There is nothing 
 wrong with running an older release, just so the packages in it are 
 updated according to what <![%linuxall;[ your vendor ]]> <![%redhat;[ Red Hat ]]>
 has made available since the initial release. At least as long as 
 <![%linuxall;[ your vendor  ]]> <![%redhat;[ Red Hat ]]> is still supporting
 the release and updates are still being provided. <![%redhat;[ For instance,
 Red Hat has stopped providing updates for 5.0 and 5.1, but still does for
 5.2.]]>
 -->
  これは単純なことです：あなたの Linux システムが
最新のものであることを確認してください。
アップデートされたパッケージが入手可能か、
<![%linuxall;[各ベンダ]]> <![%redhat;[Red Hat 訂正表]]> 
のページをチェックしましょう。
古いリリース版を走らせておくこと自体には何の不都合もありませんが、
そのパッケージは初期リリース以降に
<![%linuxall;[各ベンダ]]> <![%redhat;[ Red Hat ]]>
が提供したものに従ってアップデートされていなければなりません。
少なくとも <![%linuxall;[各ベンダ]]> <![%redhat;[ Red Hat ]]> が
サポートを続けている限り、
そのリリースとアップデートは提供され続けています。
<![%redhat;[例えば、
Red Hat はバージョン5.0 と 5.1 のためのアップデートを提供するのを
止めてしまいましたが、5.2 についてはまだ続けています。]]>
</para>

</sect2>

</sect1>

<!--  ~  End section  ~  -->



<!--   ~~~~~~~~       New section Header    ~~~~~~~~~     -->

<sect1 id="firewalls">
<title><!--Step 3: Firewalls and Setting Access Policies-->ステップ３：ファイアーウォールとアクセスポリシーの設定</title>

<para>
<!--
 So what is a <quote>firewall</quote>? It's a vague term that can mean
 anything that acts as a protective barrier between us and the outside world.
 This can be a dedicated system, or a specific application that provides this
 functionality. Or it can be a combination of components, including various
 combinations of hardware and software. Firewalls are built from 
 <quote>rules</quote> that are used to define what is allowed to enter and
 exit a given system or network. Let's look at some of the possible components
 that are readily available for Linux, and how we might implement a reasonably
 safe firewalling strategy.
-->
  さて、<quote>ファイアーウォール</quote>とは何でしょう？
これは漠然とした用語で、
我々と外の世界との間の保護バリアーとして働くものなら何でも意味しています。
これは専用のシステムを指す時もあるでしょうし、
これを機能として果たす特定のアプリケーションのことかもしれません。
または、様々なハードウェアとソフトウェアを含む要素の組み合わせ
ということもあるでしょう。
ファイアーウォールは与えられたシステムへの情報の出入りについて、
何を許可するかを定義する<quote>ルール</quote>から成っています。
では、Linux で簡単に使えるその構成要素をいくつかを見てみましょう。
そして、どのようにして適正に安全なファイアーウォール戦略を
実現するかを見てみましょう。
</para>

<para>
<!--
 In Step 1 above, we have turned off all services we don't need. In our 
 example, there were a few we still needed to have running. In this 
 section, we will take the next step here and decide which we need to leave
 open to the world. And which we might be able to restrict in some way. If we can
 block them all, so much the better, but this is not always practical.
-->
  上のステップ１では、必要でないサーヴィスを全て停止しました。
上の例では、走らせておく必要があるものはわずかでした。
この章では、次のステップに進み、どれを表の世界に開いておくか、
何らかの方法で制限することができるのはどれかを決定します。
もし全てをブロックできれば大変結構なことですが、
これは多くの場合、現実的ではありません。
</para>


<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="strategy">
<title><!--Strategy-->戦略</title>

<para>
<!--
 What we want to do now is restrict connections and traffic so that we only 
 allow the minimum necessary for whatever our particular situation is. In
 some cases we may want to block all incoming <quote>new</quote> connection
 attempts. Example: we want to run <application>X</application>, but don't
 want anyone from outside to access it, so we'll block it completely from 
 outside connections.  In other situations, we may want to limit, or restrict,
 incoming connections to trusted sources only. The more restrictive, the
 better. Example: we want to <command>ssh</command> into our system from
 outside, but we only ever do this from our workplace. So we'll limit
 <command>sshd</command> connections to our workplace address range. There are
 various ways to do this, and we'll look at the most common ones. 
 -->
  ここでの目的は、固有の状況が何であれ、
そのために必要最小限だけを許可するように、接続と通信を制限することです。
ある場合には、外から入ってくる全ての<quote>新たな</quote>接続試行を
ブロックしたいということもありえます。
例えば、<application>X</application> を走らせたいが、
誰も外からはそれにアクセスしようとは思っていないならば、
外部からの接続を完全にブロックすることになるでしょう。
他の状況では、外から入ってくる接続を信用できる出所のものだけに
制限したいかもしれません。制限が強いほど、より良いと言えます。
例えば、外から我々のシステムに <command>ssh</command> で入りたいのですが、
実際のところ我々は自分たちの仕事場からしかこの接続をしないとします。
それなら、<command>sshd</command> 接続を仕事場の
アドレスの範囲からのものに制限しておくことになるでしょう。
このための方法は色々ありますが、一番普通のやり方を見てみましょう。
</para>

<para>
<!--
 We also will not want to limit our firewall to any one application. There is 
 nothing wrong with a <quote>layered</quote> defense-in-depth approach. Our
 front line protection will be a packet filter &#045;&#045; either
 <application>ipchains</application> or <application>iptables</application>
 (see below). Then we can use additional tools and mechanisms to reinforce 
 our firewall.
 -->
  また、我々は、ファイアーウォールを一つのアプリケーションに限定
しようとは思っていません。 <quote>層になった</quote>、つまり、
深さに応じた多重の防御のアプローチをとるのに悪いことは何もありません。
前線の防御はパケットフィルタリング、
 <application>ipchains</application> か <application>iptables</application>
（以下を参照してください）のどちらかになるでしょう。
さらに、ファイアーウォールを補強するための、
追加的なツールやメカニズムを利用することができます。
</para>

<para>
<!--
 We will include some brief examples. Our rule of thumb will be to deny
 everything as the default policy, then open up just what we need. We'll try
 to keep this as simple as possible since it can be an involved and complex
 topic, and just stick to some of the most basic concepts. See the 
 <link linkend="links">Links section</link> for further reading on this
 topic.
-->
  いくつか簡単な例を紹介しましょう。
単純な方針として、デフォルトのポリシーは全てを拒否し、
必要なものだけを開くことにします。
この問題は込み入った複雑なものになりえますから、
可能な限り単純に保ち、
最も基本的なコンセプトのいくつかに集中することを心がけましょう。
このトピックについてのより進んだ内容については、
<link linkend="links">リンクの章</link>を参照してください。
</para>

</sect2>


<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="filters">
<title><!--Packet Filters &#045;&#045; Ipchains and Iptables-->パケットフィルター ― ipchains と iptables</title>

<para>
<!--
 <quote>Packet filters</quote> (like <application>ipchains</application>) 
 have the ability to look at individual packets, and make decisions based 
 on what they find. These can be used for many purposes. One common purpose
 is to implement a firewall.
-->
  （<application>ipchains</application> のような）
<quote>パケットフィルタ</quote>は個々のパケットを見て、
その内容に基づいて判断をすることができ、
様々な目的に使うことができます。
一つのよくある目的はファイアーウォールの設置です。
</para>

<para>
<!--
 Common packet filters on Linux are <application>ipchains</application> which
 is standard with 2.2 kernels, and <application>iptables</application> which
 is available with the more recent 2.4 kernels.
 <application>iptables</application> has more advanced packet filtering
 capabilities and is recommended for anyone running a 2.4 kernel. But either
 can be effective for our purposes. <application>ipfwadm</application> is 
 a similar utility for 2.0 kernels (not discussed here).
 -->
  Linux で普通のパケットフィルタは <application>ipchains</application> で、
これは 2.2 カーネルで標準になっています。
<application>iptables</application> もそうですが、
これはより最近の 2.4 カーネルで使えるようになっています。
<application>iptables</application> はさらに進んだ
パケットフィルタの能力を持ち、
2.4 カーネルを走らせているなら誰にでもお勧めです。
しかし、どちらも今の目的には充分に効果的です。
<application>ipfwadm</application> は 2.0 カーネルのための
同様のユーティリティですが、ここでは議論しません。
</para>

<para>
<!--
 If constructing your own <application>ipchains</application> or
 <application>iptables</application> firewall rules seems a bit daunting,
 there are various sites that can automate the process. See the 
 <link linkend="links">Links section</link>. Also the included examples may be
 used as a starting point. 
 <![%linuxall;[ And your distribution may be including a 
 utility of some kind for generating a firewall script.  ]]> 
 <![%redhat;[ As of Red Hat 7.1, Red Hat is providing init scripts 
 for <application>ipchains</application> and <application>iptables</application>, 
 and <application>gnome-lokkit</application> for generating a very basic
 set of firewall rules (<link linkend="lokkit">see below</link>). ]]> This may be
 adequate, but it is still recommended to know the proper syntax and 
 how the various mechanisms work as such tools rarely do more than a 
 few very simple rules.
-->
  もし自分の <application>ipchains</application> または
<application>iptables</application> ファイアーウォールの規則の
設定が少し厄介に思えるようでしたら、
この過程を自動化できるさまざまなサイトがあります。
<link linkend="links">リンクの章</link> を参照してください。
また、そこで挙げられている例を出発点として
用いることができるかもしれません。
<![%linuxall;[また、ディストリビューションによっては、
ファイアーウォールのスクリプトを生成してくれるような
ユーティリティが含まれているかもしれません。]]>
<![%redhat;[ Red Hat 7.1 以降では、
Red Hat はファイアーウォールの規則のごく基本的なセットを
生成してくれる、
<application>ipchains</application> と <application>iptables</application>, 
 と <application>gnome-lokkit</application> のための init スクリプト
を用意しています。
（<link linkend="lokkit">以下を</link>参照してください。）]]>
これはまずまずの働きをしてくれますが、
このようなツールは非常に単純な二、三の規則を設定する以上
のことは滅多にしてくれませんので、
適切な文法と様々なメカニズムがどのように働くか
を知ることをお勧めします。
</para>

<note>
 <para>
<!--
  Various examples are given below. These are presented for illustrative 
  purposes to demonstrate some of the concepts being discussed here. 
  While they might also be useful as a starting point for your own 
  script, please note that they are not meant to be all encompassing.
  You are strongly encouraged to understand how the scripts work, so 
  you can create something even more tailored for your own situation.
-->
  以下に様々な例が挙げられています。これらはここで議論した
いくつかの概念を示すための実例として挙げたものです。
これはあなた自身のスクリプトを書くための出発点としても
役立つことと思いますが、
全ての場合を含んでいるわけではないことに注意してください。
そのスクリプトがどのように働くかを
自分自身で理解するように強く勧めたいと思います。
これによって、自分自身の状況にぴったりとあう
スクリプトを作れるようになるでしょう。
 </para>
 <para>
<!--
  The example scripts are just protecting inbound connections to one interface 
  (the one connected to the Internet). This may be adequate for many simple
  home type situations, but, conversely, this approach is not adequate for 
  <emphasis>all</emphasis> situations! 
-->
  例に挙げたスクリプトは単に一つのインターフェース
（インターネットに接続されたもの）
への内側への接続を防御するだけのものです。
これは多くの自宅ユーザの状況には充分なものかも知れませんが、
逆に言えば、これは<emphasis>全ての</emphasis>
状況に妥当なわけではありません。
 </para>
</note>

<!--   ~~~~~       New section      ~~~~~     -->

<sect3 id="ipchains">
<title>ipchains</title>
<para>
<!--
 <application>ipchains</application> can be used with either 2.2 or 2.4
 kernels. When <application>ipchains</application> is in place, it checks
 every packet that moves through the system. The packets move across different
 <quote>chains</quote>, depending where they originate and where they are
 going. Think of <quote>chains</quote> as rule sets. In advanced
 configurations, we could define our own custom chains. The three default
 built-in chains are <literal>input</literal>, which is incoming traffic,
 <literal>output</literal>, which is outgoing traffic, and
 <literal>forward</literal>, which is traffic being forwarded from one
 interface to another (typically used for <quote>masquerading</quote>).
 Chains can be manipulated in various ways to control the flow of traffic in
 and out of our system. Rules can be added at our discretion to achieve 
 the desired result.
-->
  <application>ipchains</application> は 2.2 または 2.4 カーネルで
用いることができます。<application>ipchains</application> が働いている時は、
このシステムを通って行く全てのパケットがチェックされます。
パケットはそれらがどこを出発して、どこに行くかによって、
異なる<quote>チェイン（鎖）</quote>を通って移動します。
<quote>チェイン</quote>を規則の集まりと考えてください。
より進んだ設定においては、
我々は自分自身用にあつらえたチェインを定義することになるでしょう。
デフォルトで組み込み済みの三つのチェインは、
入ってくるトラフィック <literal>input</literal>,
出て行くトラフィック <literal>output</literal>,
そしてあるインターフェースから別のどこかへフォワードされる
（典型的には<quote>マスカレーディング</quote>に用いられます）
トラフィック <literal>forward</literal> です。
チェインはシステムに出入りする通信の流れの制御をするために、
様々な方法で操作することができます。
規則は望みの結果を達成するために自分の判断で付け加えることもできます。
</para>

<para>
<!--
 At the end of every <quote>chain</quote> is a <quote>target</quote>. The 
 target is specified with the <literal>-j</literal> option to the command. The
 target is what decides the fate of the packet and essentially terminates that
 particular chain. The most common targets are mostly self-explanatory:
 <literal>ACCEPT</literal>, <literal>DENY</literal>,
 <literal>REJECT</literal>, and <literal>MASQ</literal>.
 <literal>MASQ</literal> is for <quote>ipmasquerading</quote>.
 <literal>DENY</literal> and <literal>REJECT</literal> essentially do the
 same thing, though in different ways. Is one better than the other? That is
 the subject of much debate, and depends on other factors that are beyond the
 scope of this document. For our purposes, either should suffice.
 -->
  全ての<quote>チェイン</quote>の終端は<quote>ターゲット</quote>です。
ターゲットはコマンドに <literal>-j</literal> オプションをつけて特定します。
ターゲットはパケットの運命を決めるもので、
その特定のチェインを本質的に終わらせるものです。
最も普通に見られるターゲットは、
以下のようにほとんどその名前から意味がわかります：
 <literal>ACCEPT</literal>, <literal>DENY</literal>,
 <literal>REJECT</literal>, そして <literal>MASQ</literal> です。
<literal>MASQ</literal> は<quote>IPマスカレーディング</quote>のため
のものです。
<literal>DENY</literal> と <literal>REJECT</literal> は
そのやり方は違いますが、本質的には同じことをします。
では、このどちらがいいでしょうか？
これには山ほど議論があるところなのですが、
この文書の範囲を超える他のファクターに依存します。
我々の目的にはどちらでも充分でしょう。
</para>

<para>
<!--
 <application>ipchains</application> has a very flexible configuration. Port 
 (or port ranges), interfaces, destination address, source address can be
 specified, as well as various other options. The man page explains these 
 details well enough that we won't get into specifics here.
-->
  <application>ipchains</application> は非常に柔軟な設定ができます。
ポート（またはポートレンジ）、インターフェース、行き先のアドレス、
出発アドレスを他の様々なオプション同様に特定することができます。
これらは man ページで充分詳しく説明されていますので、
ここでは詳細に立ち入らないことにしましょう。
</para>

<para>
<!--
 Traffic entering our system from the Internet, enters via the
 <literal>input</literal> chain. This is the one that we need as tight as we
 can make it.
-->
  インターネットから我々のシステムに入ってくる通信は、
<literal>input</literal> のチェインを通して入ってきます。
これこそ我々が出来る限り制限する必要があるものです。
</para>

<para>
<!--
 Below is a brief example script for a hypothetical system. We'll let the
 comments explain what this script does. Anything starting with a 
 <quote>#</quote> is a comment. <application>ipchains</application> rules 
 are generally incorporated into shell scripts, using shell variables to 
 help implement the firewalling logic.
-->
  以下は仮想的なシステムのための短いスクリプトの例です。
このスクリプトが何をするかはコメント文で説明されています。
<quote>#</quote> で始まっている行は全てコメント文です。
<application>ipchains</application> の規則は一般に
シェルスクリプトに取り込まれ、
ファイアーウォールのロジックの設定を助けるために
シェル変数を用います。
</para>

<para>
 <programlisting>

#!/bin/sh
#
# ipchains.sh
#
# An example of a simple ipchains configuration. 
# 単純な ipchains 設定例
#
# This script allows ALL outbound traffic, and denies 
# ALL inbound connection attempts from the outside.
# このスクリプトは全ての外へのトラフィックを許可し、
# 全ての中への接続試行を拒否します。
#
###################################################################
# Begin variable declarations and user configuration options ######
# 変数の宣言とユーザ設定オプションの始まり
#
IPCHAINS=/sbin/ipchains
# This is the WAN interface, that is our link to the outside world.
# これは WAN インターフェース、つまり外部につながっている我々のリンク。
# For pppd and pppoe users.
# pppd と pppoe ユーザのために。
# WAN_IFACE="ppp0"
WAN_IFACE="eth0"

## end user configuration options #################################
### エンドユーザ設定オプション    #################################
###################################################################
# The high ports used mostly for connections we initiate and return
# traffic.
# 高い番号のポートはトラフィックの初期化と応答の設定のために
# 主に用いられる。
LOCAL_PORTS=`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f1`:\
`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f2`

# Any and all addresses from anywhere.
# 任意の場所からの任意の全てのアドレス
ANYWHERE="0/0"

# Let's start clean and flush all chains to an empty state.
# 全てのチェインをすっかり空の状態に。
$IPCHAINS -F  

# Set the default policies of the built-in chains. If no match for any 
# of the rules below, these will be the defaults that ipchains uses.
# 組み込みのチェインをデフォルトのポリシーにセット。以下のルールのどれにも
# マッチしないなら、これらは ipchains が用いるデフォルトになる。
$IPCHAINS -P forward DENY
$IPCHAINS -P output ACCEPT
$IPCHAINS -P input DENY 

# Accept localhost/loopback traffic.
# localhost/loopback トラフィックは受け入れる。
$IPCHAINS -A input -i lo -j ACCEPT

# Get our dynamic IP now from the Inet interface. WAN_IP will be our
# IP address we are protecting from the outside world. Put this
# here, so default policy gets set, even if interface is not up
# yet.
# ここでInet インターフェースから我々の動的な IP を得る。
# WAN_IP は我々が外の世界から守っている IP アドレスになる。
# ここでこれをおいておくと、もしインターフェースがまだ用意されてなくても、
# デフォルトのポリシーがセットされる。
WAN_IP=`ifconfig $WAN_IFACE |grep inet |cut -d : -f 2 |cut -d \  -f 1`

# Bail out with error message if no IP available! Default policy is 
# already set, so all is not lost here.
# もしどのIP も使えないなら、エラーメッセージを出して抜け出す。
# デフォルトのポリシーが既に設定されているので、全てがここで失われる
# わけではない。
[ -z "$WAN_IP" ] && echo "$WAN_IFACE not configured, aborting." && exit 1

# Accept non-SYN TCP, and UDP connections to LOCAL_PORTS. These are
# the high, unprivileged ports (1024 to 4999 by default). This will
# allow return connection traffic for connections that we initiate
# to outside sources. TCP connections are opened with 'SYN' packets.
# 非-SYN TCP を受け入れ、LOCAL_PORTS への UDP 接続を受け入れる。
# これらは高い番号で、割り当てのないポート（デフォルトでは1024から4999)。
# これは我々が外部のソースへ通信を始める時の接続の、
# 返答の接続通信を許可する。
# TCP 接続は 'SYN' パケットとともに開かれている。
$IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS ! -y -j ACCEPT 

# We can't be so selective with UDP since that protocol does not
# know about SYNs.
# UDP はSYNについて知らないので、これと選択しては使えない。
$IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS -j ACCEPT 

## ICMP (ping)
#
# ICMP rules, allow the bare essential types of ICMP only. Ping
# request is blocked, ie we won't respond to someone else's pings,
# but can still ping out. 
# ICMP の規則、ICMP の最低限の本質的な型だけを許す。
# Ping 要求はブロックされる。つまり、我々は誰かのping には応答せず、
# ping を出すことはできる。
$IPCHAINS -A input  -p icmp  --icmp-type echo-reply \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPCHAINS -A input  -p icmp  --icmp-type destination-unreachable \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPCHAINS -A input  -p icmp  --icmp-type time-exceeded \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT

###################################################################
# Set the catchall, default rule to DENY, and log it all. All other
# traffic not allowed by the rules above, winds up here, where it is
# blocked and logged. This is the default policy for this chain
# anyway, so we are just adding the logging ability here with '-l'.
# Outgoing traffic is allowed as the default policy for the 'output'
# chain. There are no restrictions on that.
# なんでも箱をおき（デフォルトルールは DENY）、全てのログをとる。
# 上のルールで許可されない他の全ての通信は、ここで引き上げ、
# ブロックされてログが取られる。とにかく、これはこのチェインの
# デフォルトのポリシーなので、ここで'-l' オプションでログ能力を付け加えるだけ。
# 外へ出て行く通信は 'output' チェインのデフォルトポリシーとして許可する。
# これについては何の制限もおかない。
$IPCHAINS -A input -l -j DENY

echo "Ipchains firewall is up `date`."

##-- eof ipchains.sh

 </programlisting>
</para>

<para>
<!--
 To use the above script would require that it is executable (i.e. 
 <literal>chmod +x ipchains.sh</literal>), and run by root to build the
 chains, and hence the firewall. 
-->
  上のスクリプトを使うには、実行可能ファイルになっていなければなりません
（つまり、<literal>chmod +x ipchains.sh</literal> で、実行可能にします）。
そして、root 権限で走らせてチェインをつくり、
ファイアーウォールをつくるわけです。
</para>

<para>
<!--
 To summarize what this example did was to start by setting some shell 
 variables in the top section, to be used later in the script. Then we set
 the default rules (ipchains calls these <quote>policies</quote>) of denying
 all inbound and forwarded traffic, and of allowing all our own outbound
 traffic. We had to open some holes in the high, unprivileged ports so
 that we could have return traffic from connections that bigcat initiates to
 outside addresses. If we connect to someone's web server, we want that HTML
 data to be able to get back to us, for instance. The same applies to other
 network traffic. We then allowed a few specific types of the ICMP protocol
 (most are still blocked). We are also logging any inbound traffic that
 violates any of our rules so we know who is doing what. Notice that we are
 only using IP address here, not hostnames of any kind. This is so that 
 our firewall works, even in situation where there may be DNS failures. 
 Also, to prevent any kind of DNS spoofing.
-->
  この例で行ったことをまとめると、
まず始めに頭の部分でいくつかのシェル変数を設定します。
これはこのスクリプトの後の部分で用いられます。
そして、全ての内向きの通信とフォワードの通信を拒否し、
外向きの通信は全て許可するというデフォルトのルール
（ipchain はこれらを <quote>policies（ポリシー）</quote> と呼びます）
を設定します。
bigcat が外部のアドレスへの通信の初期化を行う接続の返答を受け取るために、
高い番号を持つ、
割り当てされていないポートにいくつか穴を開けなければなりません。
例えば、もし誰かのウェブサーバに接続するならば、
HTML データにはこちらに戻って来てもらいたいわけです。
同じことが他のネットワーク通信にもあてはまります。
さらに ICMP プロトコルの二、三の特定のタイプを許可します
（ほとんどは依然ブロックされていますが）。
また設定したルールを破るような、
つまり何をしているのか分らないような内向きの通信は、
すべてログを取ります。
ここでは IP アドレスを用いているだけであって、
どんな種類のホスト名も使っていないことに注意してください。
これは、このファイアーウォールが、
DNS の失敗があるような場合でさえ、
DNS スプーフィングの類のごまかしを避けて、正しく動作するようにです。
</para>

<para>
<!--
 See the <application>ipchains</application> man page for a full explanation 
 of syntax. The important ones we used here are:
-->
  文法の完全な説明については <application>ipchains</application> の
 man ページを参照してください。ここで用いた重要なものは以下のものです：
</para>

<blockquote>

 <simplelist>
  <member>
   &nbsp;<literal>-A input</literal>: <!--Adds a rule to the
   <quote>input</quote> chain. The default chains are input, output, and forward.--><quote>input</quote> チェインに規則を追加する。
デフォルトのチェインは input, output, forward.
  </member>
 </simplelist>

 <simplelist>
  <member>
   &nbsp;<literal>-p udp</literal>: <!--This rule only applies to the
   <quote>UDP</quote> <quote>protocol</quote>. The <literal>-p</literal> 
   option can be used with tcp, udp or icmp protocols.-->
このルールは <quote>UDP</quote> <quote>プロトコル</quote> だけに適用。
<literal>-p</literal> オプションは tcp, udp または icmp プロトコルに
用いることが出来る。
  </member>
 </simplelist>

 <simplelist>
  <member>
   &nbsp;<literal>-i $WAN_IFACE</literal>: <!--This rule applies to the specified
   interface only, and applies to whatever chain is referenced (input, output,
   or forward).-->
このルールは特定のインターフェースのみに適用され、
参照された（input, output または output）チェイン全てに適用される。
  </member>
 </simplelist>

 <simplelist>
  <member>
   &nbsp;<literal>-s &lt;IP address&gt;</literal> [port]: <!--This rule only
   applies to the source address as specified. It can optionally have a port
   (e.g. 22) immediately afterward, or port range, e.g. 1023:4999.-->
このルールは出発点のアドレスが指定されているときにのみ適用される。
オプションとしてすぐ後にポート番号（例えば22番）、またはポート番号の範囲、
例えば 1023:4999 を持つことが出来る。
  </member>
 </simplelist>

 <simplelist>
  <member>
   &nbsp;<literal>-d &lt;IP address&gt;</literal> [port]: <!--This rule only
   applies to the destination address as specified. Also, it may include port or
   port range.-->
このルールは到着点のアドレスが指定されているときにのみ適用される。
また、ポート番号またはポート番号の範囲を含めることが可能。
  </member>
 </simplelist>

 <simplelist>
  <member>
   &nbsp;<literal>-l</literal> : <!--Any packet that hits a rule with this option
   is logged (lower case <quote>L</quote>).-->
このオプションのルールにヒットする任意のパケットのログを取る
（小文字の<quote>L</quote>）。 
  </member>
 </simplelist>

 <simplelist>
  <member>
   &nbsp;<literal>-j ACCEPT</literal>: <!--Jumps to the <quote>ACCEPT</quote> 
   <quote>target</quote>. This effectively terminates this chain 
   and decides the ultimate fate for this particular packet, which in this 
   example is to <quote>ACCEPT</quote> it. The same is 
   true for other <literal>-j</literal> targets like <literal>DENY</literal>.-->
<quote>ACCEPT</quote> <quote>ターゲット</quote> にジャンプする。
これは効果的にこのチェインを終了させ、この特定のパケットの最終的な運命、
この例では <quote>ACCEPT</quote> すること、を決定する。
同じことが <literal>DENY</literal> のような他の <literal>-j</literal> 
ターゲットについても言える。
  </member>
 </simplelist>

</blockquote>

<para>
<!--
 By and large, the order in which command line options are specified is not
 significant. The chain name (e.g. <literal>input</literal>) must come first
 though.
-->
  概して、コマンドラインオプションが置かれる順序は重要ではありませんが、
チェインの名前（例えば、 <literal>input</literal>）
は一番最初にこなくてはなりません。
</para>

<para>
<!--
 Remember in Step 1 when we ran <command>netstat</command>, we had
 both X and print servers running among other things. We don't want these
 exposed to the Internet, even in a limited way. These are still happily
 running on bigcat, but are now safe and sound behind our
 <application>ipchains</application> based firewall. You probably have other
 services that fall in this category as well.
-->
  ステップ１で我々が <command>netstat</command> を走らせた時に、
他のものの中に X とプリントサーバがあったことを思い出してください。
我々は、制限された方法を用いてでさえ、
これらをインターネットにさらしたくありません。
これらは未だ何の問題もなく bigcat 上で走っていますが、いまや
<application>ipchains</application> 
に基づいたファイアーウォールの背後に守られて、
安全かつ正常に働いているのです。
あなたのシステムには、
同じくこのカテゴリーに入る他のサーヴィスもあるかもしれませんね。
</para>

<para>
<!--
 The above example is a simplistic all or none approach. We allow all our own
 outbound traffic (not necessarily a good idea), and block all inbound
 connection attempts from outside. It is only protecting one interface, and 
 really just the inbound side of that interface. It would more than likely
 require a bit of fine tuning to make it work for you. For a more advanced set
 of rules, see the <link linkend="pfilters">Appendix</link>. And you might
 want to read <ulink
 url="http://tldp.org/HOWTO/IPCHAINS-HOWTO.html">http://tldp.org/HOWTO/IPCHAINS-HOWTO.html</ulink>.
-->
  上の例は極度に単純化されたオール・オア・ナッシングの方針でした。
つまり、自分自身の外向きの通信は全て許可し
（これは必ずしも良いアイデアではありませんが）、
外側から入ってくる全ての接続試行をブロックしました。
これは一つのインターフェースを守っているだけで、
実際にはさらにそのインターフェースの内側を守っているだけです。
しかし、あなたが自分のシステム用にうまく働かせるには、
もう少し詳細なチューニングが必要となることもあるでしょう。
さらに進んだ規則を知るには、<link linkend="pfilters">補遺</link>
を参照してください。
さらに
<ulink
 url="http://tldp.org/HOWTO/IPCHAINS-HOWTO.html">http://tldp.org/HOWTO/IPCHAINS-HOWTO.html</ulink>
（JF日本語版：<ulink
 url="http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO.html">http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO.html</ulink>）
を読むと良いでしょう。
</para>

<para>
<!--
 Whenever you have made changes to your firewall, you should verify its
 integrity. One step to make sure your rules seem to be doing what you 
 intended, is to see how <application>ipchains</application> has interpreted 
 your script. You can do this by opening your <application>xterm</application> 
 very wide, and issuing the following command:
-->
  ファイアーウォールに変更を加えた時はいつでも、
その整合性を確認するべきです。
設定したルールが意図したように動いていることを
確認するための一つの方法は、
<application>ipchains</application> がどのようにスクリプトを
解釈しているかを見ることです。
これには <application>xterm</application> を
ぐんと大きく開いて、以下のコマンドをたたいてください：
</para>

<para>
 <screen>

 # ipchains -L -n -v | less

 </screen>
</para>

<para>
<!--
 The output is grouped according to chain. You should also find a way to scan
 yourself (see the <link linkend="verify">Verifying section</link> below). And
 then keep an eye on your logs to make sure you are blocking what is
 intended.
-->
 この 出力はチェインによってグループ分けされています。
さらに、あなたは自分自身をスキャンする方法も知らねばなりません。
（以下の <link linkend="verify">検証の章</link>を参照してください ）。
そして自分のログから目を離さず、
目指しているものがブロックされていることを確認してください。
</para>

</sect3>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect3 id="iptables">
<title>iptables</title>

<para>
<!--
 <application>iptables</application> is the next generation packet filter for
 Linux, and requires a 2.4 kernel. It can do everything
 <application>ipchains</application> can, but has a number of noteworthy
 enhancements. The syntax is similar to <application>ipchains</application> in
 many respects. See the man page for details.
-->
  <application>iptables</application> は Linux 用の次世代型の
パケットフィルターで、2.4 カーネルを必要とします。
これは <application>ipchains</application> にできることなら何でもできますが、
注意する価値のある拡張機能をたくさん持っています。
文法は多くの面で <application>ipchains</application> に似ています。
詳しくは man ページを参照してください。
</para>

<para>
<!--
 The most noteworthy enhancement is <quote>connection tracking</quote>, also
 known as <quote>stateful inspection</quote>. This gives
 <application>iptables</application> more knowledge of the state of each
 packet. Not only does it know if the packet is a TCP or UDP packet, or
 whether it has the SYN or ACK flags set, but also if it is part of an existing
 connection, or related somehow to an existing connection. The implications 
 for firewalling should be obvious.
-->
  最も記す価値がある拡張機能は<quote>コネクション・トラッキング</quote>
（接続追跡）でしょう。
これは<quote>ステイトフル・インスペクション</quote>
（ステイトフルな検査）という名前でも知られています。
これは <application>iptables</application> に各パケットの状態の
さらに豊富な知識を与えるものです。
そのパケットが TCP パケットと UDP パケットのどちらであるかや、
SYN か ACK フラッグのどちらがセットされているかだけではなく、
それが存在している接続の一部であるかどうかや、
存在している接続と何か関係しているかどうかまで知ることができます。
ファイアーウォールの設定との関係は明白でしょう。
</para>

<para>
<!--
 The bottom line is that it is easier to get a tight firewall with
 <application>iptables</application>, than with
 <application>ipchains</application>. So this is the recommended way to go.
 -->
  結論として、
厳しいファイアーウォールを設定するには、
 <application>ipchains</application> を用いるより、
<application>iptables</application> の方が簡単です。
ですから、これがお勧めの方法です。
</para>

<para>
<!--
 Here is the same script as above, revised for
 <application>iptables</application>:
-->
  以下は上に挙げたものと同じスクリプトを
 <application>iptables</application> 用に書き換えたものです：
</para>

<para>
 <programlisting>

#!/bin/sh
#
# iptables.sh
#
# An example of a simple iptables configuration. 
# iptables 設定のシンプルな例
#
# This script allows ALL outbound traffic, and denies 
# ALL inbound connection attempts from the Internet interface only.
# このスクリプトは全ての外向きの通信を許可し、
# 全ての内側への接続試行を拒否します。
###################################################################
# Begin variable declarations and user configuration options ######
# 変数宣言とユーザ設定オプションの開始。
#
IPTABLES=/sbin/iptables
# Local Interfaces
# ローカルインターフェース
# This is the WAN interface that is our link to the outside world.
# これは外の世界へ我々をつなげている WAN インターフェース。
# For pppd and pppoe users.
# ppd と pppoe ユーザのため。
# WAN_IFACE="ppp0"
WAN_IFACE="eth0"
#

## end user configuration options #################################
## エンドユーザ設定オプション
###################################################################

# Any and all addresses from anywhere.
# 任意の場所からの任意の全てのアドレス
ANYWHERE="0/0"

# This module may need to be loaded:
# このモジュールはロードする必要があるかも知れない
modprobe ip_conntrack_ftp

# Start building chains and rules #################################
# チェインと規則の作成の開始
# Let's start clean and flush all chains to an empty state.
# 全てのチェインを空の状態に初期化
$IPTABLES -F  

# Set the default policies of the built-in chains. If no match for any 
# of the rules below, these will be the defaults that IPTABLES uses.
# 組み込みのチェインのデフォルトのポリシーを設定する。
# もし以下のルールのどれにもマッチしないなら、これらが IPTABLES ユーザの
# デフォルトとなる。
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P INPUT DROP

# Accept localhost/loopback traffic.
# localhost/loopback 通信を許可
$IPTABLES -A INPUT -i lo -j ACCEPT

## ICMP (ping)
#
# ICMP rules, allow the bare essential types of ICMP only. Ping
# request is blocked, ie we won't respond to someone else's pings,
# but can still ping out.
# ICMP ルール。ICMP の最低限の本質的タイプのみを許可。
# ping の要求はブロックされる、つまり、我々は誰か他の ping には
# 応答しないが、ping を出すことは可能。
$IPTABLES -A INPUT  -p icmp  --icmp-type echo-reply \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT  -p icmp  --icmp-type destination-unreachable \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT  -p icmp  --icmp-type time-exceeded \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT

###################################################################
# Set the catchall, default rule to DENY, and log it all. All other
# traffic not allowed by the rules above, winds up here, where it is
# blocked and logged. This is the default policy for this chain
# anyway, so we are just adding the logging ability here with '-j
# LOG'. Outgoing traffic is allowed as the default policy for the
# 'output' chain. There are no restrictions on that.
# なんでも箱をおき（デフォルトルールは DENY）、全てのログをとる。
# 上のルールで許可されない他の全ての通信は、ここで引き上げ、
# ブロックされてログが取られる。とにかく、これはこのチェインの
# デフォルトのポリシーなので、ここで'-l' オプションでログ能力を付け加えるだけ。
# 外へ出て行く通信は 'output' チェインのデフォルトポリシーとして許可する。
# これについては何の制限もおかない。
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -i ! $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT -j LOG -m limit --limit 30/minute --log-prefix "Dropping: "

echo "Iptables firewall is up `date`."

##-- eof iptables.sh

 </programlisting>
</para>

<para>
<!--
 The same script logic is used here, and thus this does pretty much the same
 exact thing as the <application>ipchains</application> script in the
 previous section. There are some subtle differences as to syntax. Note the
 case difference in the chain names for one (e.g. INPUT vs input). Logging is
 handled differently too. It has its own <quote>target</quote> now
 (<literal>-j LOG</literal>), and is much more flexible.
-->
  同じスクリプトのロジックをここで用いているので、これは、
前の <application>ipchains</application> スクリプトとほぼ
同じことを行います。文法的にはわずかに差がありますが。
チェインの名前の変化がある場合に気をつけてください
（例えば、INPUT と input など）。
ログを取ることについても扱いが異なります。
今度は自分自身の<quote>ターゲット</quote>を持ち
(<literal>-j LOG</literal>)、さらに柔軟になっています。
</para>

<para>
<!--
 There are some very fundamental differences as well, that might not be so
 obvious. Remember this section from the <application>ipchains</application> 
 script:
-->
  同様にきわめて根本的な違いもいくつかありますが、
それはそんなに明らかなものではないかもしれません。
この章での<application>ipchains</application> スクリプトの
以下の部分を思い出してください：
</para>

<para>
 <programlisting>

# Accept non-SYN TCP, and UDP connections to LOCAL_PORTS. These are the high,
# unprivileged ports (1024 to 4999 by default). This will allow return
# connection traffic for connections that we initiate to outside sources.
# TCP connections are opened with 'SYN' packets. We have already opened 
# those services that need to accept SYNs for, so other SYNs are excluded here
# for everything else.
# LOCAL_PORTS への非-SYN TCP と UDP 接続を受け入れる。
# これらは高い番号で、割り当てのないポート（デフォルトでは1024から4999)。
# これは我々が外部のソースへ通信を始める時の接続の、返答の接続通信を許可する。
# TCP 接続は 'SYN' パケットとともに開かれている。
# 我々は既に SYN を受け入れる必要のあるサーヴィスを開いていたので、
# 他のSYN については、それら以外の全てをここで除く。
$IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS ! -y -j ACCEPT 

# We can't be so selective with UDP since that protocol does not know 
# about SYNs.
# UDP は SYN について知らないので、
# このプロトコルとそれほど選択的にはなれない。
$IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS -j ACCEPT 

 </programlisting>
</para>

<para>
<!--
 We jumped through hoops here with <application>ipchains</application> so 
 that we could restrict unwanted, incoming connections as much as possible. A
 bit of a kludge, actually.
-->
  我々は内側に入ってくる望まぬ接続を出来る限り制限するために、
 <application>ipchains</application> によって、
ここで輪くぐりの曲芸をしました。実際、少々不調和です。
</para>

<para>
<!--
 That section is missing from the <application>iptables</application> version. 
 It is not needed as connection tracking handles this quite nicely, and then
 some. This is due to the <quote>statefulness</quote> of
 <application>iptables</application>. It knows more about each packet than 
 <application>ipchains</application>. For instance, it knows whether the 
 packet is part of a <quote>new</quote> connection, or an
 <quote>established</quote> connection, or a <quote>related</quote>
 connection. This is the so-called <quote>stateful inspection</quote> of 
 connection tracking.
-->
  以上の部分は<application>iptables</application> 
版のスクリプトからは抜けています。
この場合はコネクション・トラッキング（接続追跡）
がこれをうまく扱ってくれるため不要で、結局なくても同じなのです。
これは <application>iptables</application> の<quote>ステイトフルネス</quote>
のおかげです。 
それは各パケットについて、
<application>ipchains</application> よりも多くのことを知っているのです。
例えば、これはパケットが<quote>新しい</quote>接続の
一部なのか、既に<quote>確立した</quote>接続か、
また<quote>関連した</quote>接続の一部なのかを知っているのです。
これがいわゆる、コネクション・トラッキングにおける
<quote>ステイトフル・インスペクション</quote> です。
</para>

<!--

<para>
 To show another brief example and just how much work connection tracking can
 do for us, here is an short and sweet example from the Netfilter
 Packet-Filtering HOWTO:

</para>


<para>
 This very succinct example shows the use of a user defined chain -
 <quote>block</quote> here, which is jumped to from the only
 <literal>INPUT</literal> and <literal>FORWARD</literal> rules there at the
 end. This essentially allows all outbound traffic (since
 <literal>OUTPUT</literal> is not defined here and that is the default
 behavior). And then any connections that are <literal>ESTABLISHED</literal>
 or <literal>RELATED</literal> to those <literal>OUTPUT</literal> connections
 that we generate. So <quote>connection tracking</quote> is doing the lion's
 share of the work here.

</para>
-->

<para>
<!--
 There are many, many features of <application>iptables</application> that 
 are not touched on here. For more reading on the Netfilter project and
 <application>iptables</application>, see <ulink
 url="http://netfilter.samba.org">http://netfilter.samba.org</ulink>. 
 And for a more advanced set of rules, see the <link
 linkend="pfilters">Appendix</link>. 
-->
   <application>iptables</application> には、
ここでは触れなかった機能がまだまだたくさんあります。
ネットフィルタープロジェクトと <application>iptables</application>
についてのさらなる読み物としては、<ulink
 url="http://netfilter.samba.org">http://netfilter.samba.org</ulink>
を参照してください。また、より進んだルールの設定については、
<link linkend="pfilters">補遺</link>を参照してください。
</para>

</sect3>

<!--  ~  End section  ~  -->


<!--   ~~~~~       New section      ~~~~~     -->

<![%redhat;[ 
<sect3 id="lokkit">
<title><!--Red Hat Firewall Configuration Tools-->Red Hat ファイアーウォール設定ツール</title>
<para>
<!--
 Red Hat has not included firewall configuration tools until 7.1, when 
 the GUI utility <command>gnome-lokkit</command> started being bundled. 
 <command>gnome-lokkit</command> does a minimalist set of rules for 
 <application>ipchains</application> only. Explicit support for 
 <application>iptables</application> configuration is not an option, despite 
 the fact that the default kernel is 2.4.
-->
  Red Hat は、GUI ユーティリティ <command>gnome-lokkit</command> の
バンドルが開始されたバージョン 7.1 までは、
ファイアーウォール設定ツールを含んでいませんでした。
<command>gnome-lokkit</command> は <application>ipchains</application> のみ
の最小限の規則のセットです。
そのデフォルトのカーネルが 2.4 であるにも関わらず、
<application>iptables</application> 設定の正式なサポートは
オプションにありません。
</para>

<para>
<!--
 <command>gnome-lokkit</command> is an option on non-upgrade installs, and
 can also be run as a stand-alone app any time after installation. It will ask
 a few simple questions, and dump the resulting rule-set into
 <filename>/etc/sysconfig/ipchains</filename>.
-->
  <command>gnome-lokkit</command> は非アップグレードインストールで
オプションになっていて、インストール後のいつでもスタンドアローンの
アプリケーションとして走らせることもできます。
これはいくつかの簡単な質問をして、その結果を
<filename>/etc/sysconfig/ipchains</filename> に規則セットとして
吐き出してくれます。
</para>

<para>
<!--
 As mentioned, this is a fairly minimalist set of rules, and possibly a 
 sufficient starting point. An example
 <filename>/etc/sysconfig/ipchains</filename> created by
 <command>gnome-lokkit</command>:
-->
  既に述べたように、これは全く最小の規則セットですが、
出発点としては充分なものになりえます。以下は、
<command>gnome-lokkit</command> によって生成された
<filename>/etc/sysconfig/ipchains</filename> の例です：
</para>

<para>
 <programlisting>

 # Firewall configuration written by lokkit
 # Manual customization of this file is not recommended.
 # Note: ifup-post will punch the current nameservers through the
 #       firewall; such entries will *not* be listed here.
 :input ACCEPT
 :forward ACCEPT
 :output ACCEPT
 -A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT
 -A input -s 0/0 -d 0/0 25 -p tcp -y -j ACCEPT
 -A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT
 -A input -s 0/0 -d 0/0 23 -p tcp -y -j ACCEPT
 -A input -s 0/0 -d 0/0 -i lo -j ACCEPT
 -A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT
 -A input -s 127.0.0.1 53 -d 0/0 -p udp -j ACCEPT
 -A input -s 0/0 -d 0/0 -p tcp -y -j REJECT
 -A input -s 0/0 -d 0/0 -p udp -j REJECT

 </programlisting>
</para>

<para>
<!--
 This is in a format that can be read by the
 <application>ipchains</application> command
 <command>ipchains-restore</command>. Consequently, a new or modified set or
 rules can be generated with the <command>ipchains-save</command>, and
 redirecting the output to this file. <command>ipchains-restore</command> is
 indeed how the <application>ipchains</application> init script processes
 this file. So for this to work, the <application>ipchains</application>
 service must be activated: 
-->
  これは <application>ipchains</application> コマンドの
 <command>ipchains-restore</command> が読むことのできる
フォーマットになっています。
結果として、新しい、または変更した規則セットは
 <command>ipchains-save</command> でアウトプットを
このファイルにリダイレクトすることで生成することができます。
実際、<command>ipchains-restore</command> によって、
 <application>ipchains</application> init スクリプトが
このファイルを処理します。
ですから、これを働かせるには、
<application>ipchains</application> を
以下のように起動しなければなりません：
</para>

<para>
 <screen>

 # chkconfig ipchains on

 </screen>
</para>

<para>
<!--
 Conversely, if you want to roll your own <application>iptables</application>
 rules instead, you should make sure the <application>ipchains</application>
 init service is disabled. There is also an
 <application>iptables</application> init script, that works much the same as
 the <application>ipchains</application> version. There is just no support
 from <command>gnome-lokkit</command> at this time.
-->
  逆に、もし代わりに自分自身の <application>iptables</application>
の規則を走らせたいなら、
<application>ipchains</application> init サーヴィスが
停止されていることを確認すべきです。
<application>iptables</application> init スクリプトもあり、
これは <application>ipchains</application> 版とほとんど同じことをします。
ただ、今のところ、
<command>gnome-lokkit</command> からのサポートはありません。
</para>

</sect3>
]]>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="tcpwrappers">
<title>Tcpwrappers (libwrap)</title>

<para>
<!--
 <application>Tcpwrappers</application> provides much the same desired results
 as <application>ipchains</application> and
 <application>iptables</application> above, though works quite differently.
 <application>Tcpwrappers</application> actually intercepts the connection
 attempt, then examines its configurations files, and decides whether to
 accept or reject the request. <application>Tcpwrappers</application> 
 controls access at the application level, rather than the socket level 
 like <application>iptables</application> and <application>ipchains</application>.
 This can be quite effective, and is a standard component on most Linux
 systems.
-->
  <application>tcpwrappers</application> は上の
<application>ipchains</application> や <application>iptables</application> 
とほぼ同じ望みの結果をもたらしてくれますが、その働く仕組みは全く違います。
実際、<application>tcpwrappers</application> は接続試行に割り込んで、
その設定ファイルを調べ、要求を受け入れるか拒否するかを決定するのです。
<application>tcpwrappers</application> は、
<application>iptables</application> と <application>ipchains</application>
のようにソケットのレベルで制御するのではなく、
アプリケーションのレベルでアクセスを制御します。
これは非常に効果的ですので、
多くの Linux システムで標準のコンポーネントになっています。
</para>

<para>
<!--
 <application>Tcpwrappers</application> consists of the configuration 
 files <filename>/etc/hosts.allow</filename> and
 <filename>/etc/hosts.deny</filename>. The functionality is provided by the 
 <application>libwrap</application> library. 
-->
  <application>tcpwrappers</application> は設定ファイルの
 <filename>/etc/hosts.allow</filename> と
 <filename>/etc/hosts.deny</filename> からなり、
その機能自体は
<application>libwrap</application> ライブラリで提供されます。
</para>

<para>
<!--
 <application>Tcpwrappers</application> first looks to see if access is
 permitted in <filename>/etc/hosts.allow</filename>, and if so, access is
 granted. If not in <filename>/etc/hosts.allow</filename>, the file
 <filename>/etc/hosts.deny</filename> is then checked to see if access is
 <emphasis>not</emphasis> allowed. If so, access is denied. Else,
 <emphasis>access is granted</emphasis>.  For this reason,
 <filename>/etc/hosts.deny</filename> should contain only one uncommented
 line, and that is: <literal>ALL: ALL</literal>. Access should then be
 permitted through entries in <filename>/etc/hosts.allow</filename>, where
 specific services are listed, along with the specific host addresses allowed
 to access these services. While hostnames can be used here, use of hostnames
 opens the limited possibility for name spoofing.
-->
  <application>tcpwrappers</application> はまず、
<filename>/etc/hosts.allow</filename> ファイルで
アクセスが許可されているかどうかを調べて、
許可されていればそのアクセスを認めます。
もし <filename>/etc/hosts.allow</filename> ファイルになければ、
<filename>/etc/hosts.deny</filename> ファイルでアクセスが許可されて
<emphasis>いない</emphasis>かどうかを調べて、
もし許可されていないなら、そのアクセスを拒否します。
それ以外の場合は、<emphasis>アクセスを許可します</emphasis>。
この仕組みからして、<filename>/etc/hosts.deny</filename> ファイルには
<literal>ALL: ALL</literal> という一行のみを書くべきです。
これによって、アクセスは <filename>/etc/hosts.allow</filename> ファイルに
エントリーされているものだけが許可されるはずで、
ここには特定のサーヴィスを、
これにアクセスすることが許される特定のホストのアドレスとともに書きます。
ここでホスト名を用いることもできますが、
ホスト名を使用すると、
名前のなりすましというわずかな危険性が残ります。
</para>

<para>
<!--
 <application>Tcpwrappers</application> is commonly used to protect services
 that are started via <application>inetd</application> (or 
 <application>xinetd</application>). But also any program 
 that has been compiled with <application>libwrap</application> support, can 
 take advantage of it. Just don't assume that all programs have built in 
 <application>libwrap</application> support &#045;&#045; they do not. In fact, most 
 probably don't. So we will only use it in our examples here to protect
 services start via <application>inetd</application>. And then rely on our
 packet filtering firewall, or other mechanism, to protect non-(x)inetd
 services.
-->
  <application>tcpwrappers</application> は普通、
<application>inetd</application>
 (または <application>xinetd</application>) を経由して開始される
サーヴィスを守るために使われます。
しかし、 <application>libwrap</application> をサポートするように
コンパイルされたプログラムも、
同じく tcpwrappers に守ってもらうことができます。
ただ 全てのプログラムが<application>libwrap</application> サポート
のもとビルドされていると仮定してはいけません。
実際、そうでないからです。事実、ほとんどのものはそうではないでしょう。
ですから、我々はここでは、
 <application>inetd</application> 経由で開始されたサーヴィスを守る
という例にだけ用いることにしましょう。
そして、非(x)inetd サーヴィスを守ることについては、
我々のパケットフィルタリングのファイアーウォールか、
または他の仕組みに頼ることにしましょう。
</para>

<para>
<!--
 Below is a small snippet from a typical <filename>inetd.conf</filename> file:
-->
  以下は典型的な <filename>inetd.conf</filename> ファイルから
一部抜き出したものです：
</para>

<para>
 <screen>

 # Pop and imap mail services et al
 #
 #pop-2   stream  tcp     nowait  root    /usr/sbin/tcpd ipop2d
 #pop-3   stream  tcp     nowait  root    /usr/sbin/tcpd ipop3d
 #imap    stream  tcp     nowait  root    /usr/sbin/tcpd imapd
 #

 </screen>
</para>

<para>
<!--
 The second to last column is the <application>tcpwrappers</application>
 daemon &#045;&#045; <command>/usr/sbin/tcpd</command>. Immediately after is the daemon
 it is protecting. In this case, <application>POP</application> and
 <application>IMAP</application> mail servers. Your distro probably has 
 already done this part for you. For the few applications that have built-in
 support for <application>tcpwrappers</application> via the
 <application>libwrap</application> library, specifying the daemon as above 
 is not necessary.
-->
  最後から二番目のコラムが <application>tcpwrappers</application> デーモン、
つまり<command>/usr/sbin/tcpd</command> です。
デーモンのすぐ後ろにあるのが、防御されているもので、
この場合には、<application>POP</application> と
 <application>IMAP</application> メイルサーバです。
ディストリビューションによっては、
既にこの部分が最初から用意されているかもしれません。
<application>libwrap</application> ライブラリによって、
<application>tcpwrapper</application> で組み込みサポートされている
二、三のアプリケーションについては、
上のようにデーモンを指定する必要はありません。
</para>

<para>
<!--
 We will use the same principles here: default policy is to deny everything,
 then open holes to allow the minimal amount of traffic necessary.
-->
  ここでもまた同じ原則を使います：
つまり、デフォルトのポリシーとして、全てを拒否し、
必要最小限の通信だけを許可するために穴を開けます。
</para>

<para>
<!--
 So now with your text editor, <command>su</command> to root and open
 <filename>/etc/hosts.deny</filename>. If it does not exist, then create 
 it. It is just a plain text file. We want the following line:
 -->
  さて、ここでテキストエディタの出番です。
<command>su</command> で root になり、
<filename>/etc/hosts.deny</filename> ファイルを開きましょう。
もしそのファイルが存在しないようなら、作ってください。
これはただのプレーンなテキストファイルです。
そこに以下のように書きます：
</para>

<para>
 <screen>

 ALL: ALL

 </screen>
</para>

<para>
<!--
 If it is there already, fine. If not, add it in and then save and close file.
 Easy enough. <quote>ALL</quote> is one of the keywords that
 <application>tcpwrappers</application> understands. The format is
 <literal>$SERVICE_NAME : $WHO</literal>, so we are denying all connections to
 all services here. At least all services that are using
 <application>tcpwrappers</application>. Remember, this will primarily be
 <application>inetd</application> services. See <literal>man 5
 hosts_access</literal> for details on the syntax of these files. Note the
 <quote>5</quote> there!
-->
  もしそれが既にあれば、結構。もしなければ、これを書き込んで、
保存し、ファイルを閉じてください。簡単ですね。
<quote>ALL</quote> は <application>tcpwrapper</application> が
理解してくれるキーワードの一つです。
そのフォーマットは <literal>$SERVICE_NAME : $WHO</literal> の
形ですので、
ここで全てのサーヴィスへの全ての接続を拒否していることになります。
少なくとも、 <application>tcpwrappers</application> を使っている
全てのサーヴィスについてはそうです。
これが主に <application>inetd</application> サーヴィスであることを
思い出してください。
これらのファイルの文法についての詳細は
<literal>man 5 hosts_access</literal> を参照してください。
ここの <quote>5</quote> に注意してください！
</para>

<para>
<!--
 Now let's open up just the services we need, as restrictively as we can, 
 with a brief example:
-->
  さて今度は、出来る限り制限した、
必要なサーヴィスだけを開きましょう。
以下は簡単な一つの例です：
</para>

<para>
 <screen>

 ALL: 127.0.0.1
 sshd,ipop3d: 192.168.1.
 sshd: .myworkplace.com, hostess.mymomshouse.com 

 </screen>
</para>

<para>
<!--
 The first line allows all <quote>localhost</quote> connections. 
 You will need this. The second
 allows connections to the <application>sshd</application> and 
 <application>ipop3d</application> services from IP addresses that start with
 <literal>192.168.1.</literal>, in this case the private address range for
 our hypothetical home LAN. Note the trailing <quote>.</quote>. It's
 important. The third line allows connections to only our
 <application>sshd</application> daemon from any host associated with
 <literal>.myworkplace.com</literal>. Note the leading <quote>.</quote> in
 this example. And then also, the single host
 <literal>hostess.mymomshouse.com</literal>. In summary, localhost and all
 our LAN connections have access to any and all tcpwrappered services on
 bigcat. But only our workplace addresses, and our mother can use
 <application>sshd</application> on bigcat from outside connections. Everybody
 else is denied by the default policy in <filename>/etc/hosts.deny</filename>.
 -->
  最初の行は全ての <quote>localhost</quote> 接続を許可しています。
これは必要でしょう。次の行は、
我々の仮想的な自宅内 LANのプライベートアドレスの範囲である
 <literal>192.168.1.</literal> から始まるIP アドレスからの
 <application>sshd</application> と <application>ipop3d</application>
 サーヴィスへの接続を許可します。
後に <quote>.</quote> が続いていることに注意してください。
これは重要です。
三行目は <literal>.myworkplace.com</literal> と続く任意のホストから、
我々の <application>sshd</application> デーモンへの接続だけを許可します。
今度は、前に <quote>.</quote> が来ていることに注意してください。
それから、一つのホストである <literal>hostess.mymomshouse.com</literal>
も許可しています。
結果、localhost と我々の全ての LAN 接続は、
bigcat 上の全ての tcpwrapper で守られたサーヴィスへの接続が
許可されています。しかし、
外部から bigcat 上の <application>sshd</application> を使うことができるのは、
我々の仕事場のアドレスからとお母さんの家からだけです。
他の全ては <filename>/etc/hosts.deny</filename> 
ファイルのデフォルトポリシーによって拒否されます。
</para>

<para>
<!--
 The types of wild cards above (<literal>.myworkplace.com</literal> and 
 <literal>192.168.1.</literal>) are not supported by
 <application>ipchains</application> and <application>iptables</application>,
 or most other Linux applications for that matter. Also, 
 <application>tcpwrappers</application> can use hostnames in place of 
 IP addresses which is quite handy in some situations. This does 
 not work with <application>ipchains</application> and 
 <application>iptables</application>. 
-->
  上の <literal>.myworkplace.com</literal> や
 <literal>192.168.1.</literal> のようなワイルドカードのタイプは
 <application>ipchains</application> や <application>iptables</application> や、
この問題についての他の Linux アプリケーションではサポートされていません。
また、 <application>tcpwrappers</application> は
IP アドレスのかわりにホスト名を使うことができ、
これはある場合にはとても便利です。
これは<application>ipchains</application> と
 <application>iptables</application> では使えません。
</para>

<para>
<!--
 You can test your <application>tcpwrappers</application> configuration 
 with the included <command>tcpdchk</command> utility (see the man page). Note
 that at this time this does not work with <application>xinetd</application>,
 and may not even be included in this case.
-->
  自分で作った <application>tcpwrappers</application> 設定は、
同梱の <command>tcpdchk</command> ユーティリティでチェックすることができます
（man ページを見てください）。今度は、
これは <application>xinetd</application> と一緒には働かないこと、
この場合には含まれもしないかもしれないことに注意してください。
</para>

<para>
<!--
 There is nothing wrong with using both <application>tcpwrappers</application>
 and a packet filtering firewall like <application>ipchains</application>. In
 fact, it is recommended to use a <quote>layered</quote> approach. This 
 helps guard against accidental misconfigurations. In this case, each 
 connection will be tested by the packet filter rules first, then 
 <application>tcpwrappers</application>. 
-->
  <application>tcpwrappers</application> と
 <application>ipchains</application> のようなパケットフィルタリングの
ファイアーウォールの両方を使うことには何も問題はありません。
実際、このような
<quote>多層化された</quote>アプローチを用いることをお勧めします。
これはうっかり設定ミスをしたときの防御にもなります。
この場合、それぞれの接続が、まずパケットフィルタによってチェックされ、
次に <application>tcpwrapper</application> でチェックされます。
</para>

<para>
<!--
 Remember to make backup copies before editing system configuration files, 
 restart the daemon afterward, and then check the logs for error messages.
-->
  忘れずにシステム設定ファイルを編集する前にそのコピーをバックアップし、
デーモンを再スタートさせて、エラーメッセージのログをチェックしてください。
</para>


<!--   ~~~~~       New section      ~~~~~     -->

<sect3 id="xinetd2">
<title>xinetd</title>

<para>
<!--
 As mentioned, <ulink url="http://www.xinetd.org">xinetd</ulink> is an
 enhanced <application>inetd</application> <![%redhat;[, and replaces
 <application>inetd</application> as of Red Hat 7.0]]>. It has much of the
 same functionality, with some notable enhancements. One is that
 <application>tcpwrappers</application> support <![%linuxall;[ can ]]> be
 <![%redhat;[ is ]]> compiled in, eliminating the need for explicit references to
 <command>tcpd</command>. Which means <filename>/etc/hosts.allow</filename>
 and <filename>/etc/hosts.deny</filename> are automatically in effect. 
 <![%linuxall;[ Don't
 assume this is the case though. A little testing, then viewing the logs
 should be able to tell you whether <application>tcpwrappers</application>
 support is automatic or not.  ]]>
 -->
  既に述べたように、
<ulink url="http://www.xinetd.org">xinetd</ulink> は
拡張された <application>inetd</application> です。
<![%redhat;[Red Hat 7.0 では <application>inetd</application> から
置き換わっています。]]>
これはほぼ同じ機能を果たしますが、いくつかの注目すべき
拡張を持っています。
一つは <application>tcpwrappers</application> のサポートが
<![%linuxall;[可能になり、]]><![%redhat;[されていて、]]>
 <command>tcpd</command> へのあらわな参照が不要であることです。
これは <filename>/etc/hosts.allow</filename>
 と <filename>/etc/hosts.deny</filename> が自動的に有効になる
ことを意味します。
 <![%linuxall;[でも、必ずしもそうとは限りませんので、
少しテストをして、ログを眺めてみて、
 <application>tcpwrappers</application> サポートが
自動的かどうかチェックしてください。]]>
</para>

<para>
<!--
 Some of <application>xinetd's</application> other enhancements: specify 
 IP address to listen on, which is a very effective method of access control;
 limit the rate of incoming connections and the total number of simultaneous
 connections; limit services to specific times of day. See the 
 <application>xinetd</application> and <application>xinetd.conf</application>
 man pages for more details.
-->
  <application>xinetd</application> の他の拡張機能には、
耳をすませる IP アドレスを指定すること
（これはアクセス制御の非常に有効な方法です）、
内側への接続の割合と同時接続の総数を制限すること、
一日の特定の時間にサーヴィスを制限することなどがあります。
<application>xinetd</application> と
 <application>xinetd.conf</application> についての、
より詳しい情報については man ページを参照してください。
</para>

<para>
<!--
 The syntax is quite different though. An example from 
 <filename>/etc/xinetd.d/tftp</filename>:
-->
  しかし文法はまったく異なります。以下は
 <filename>/etc/xinetd.d/tftp</filename> からの一例です：
</para>

<para>
 <screen>

 service tftp
 {
        socket_type     = dgram
        bind            = 192.168.1.1
        instances       = 2
        protocol        = udp
        wait            = yes
        user            = nobody
        only_from       = 192.168.1.0
        server          = /usr/sbin/in.tftpd
        server_args     = /tftpboot
        disable         = no
 }

 </screen>
</para>

<para>
<!--
 Notice the <literal>bind</literal> statement. We are only listening on, 
 or <quote>binding</quote> to, the private, LAN interface here. No outside
 connections can be made since the outside port is not even opened. We are
 also only accepting connections from <literal>192.168.1.0</literal>, our LAN.
 For <application>xinetd's</application> purposes, this denotes any IP
 address beginning with <quote>192.168.1</quote>. Note that the syntax is different
 from <application>inetd</application>. The <literal>server</literal>
 statement in this case is the <command>tftp</command> daemon,
 <command>in.tftpd</command>. Again, this assumes that
 <application>libwrap/tcpwrappers</application> support is compiled into
 <application>xinetd</application>. The <literal>user</literal> running the
 daemon will be <quote>nobody</quote>. Yes, there is a user account called
 <quote>nobody</quote>, and it is wise to run such daemons as non-root users
 whenever possible. Lastly, the <literal>disable</literal> statement is
 <application>xinetd's</application> way of turning services on or off. In
 this case, it is <quote>on</quote>. This is on here only as an example. Do
 NOT run <application>tftp</application> as a public service as it is unsafe.
-->
  <literal>bind</literal> の記述に注意してください。
ここではプライベートの LAN インターフェースに耳をすませているだけ、
または、
<quote>binding</quote> している（結び付けられている）だけです。
外側のポートは開いてさえいないので、外側への接続は全くなされません。
そして <literal>192.168.1.0</literal> と LAN からの接続だけを
許可します。
<application>xinetd</application> の目的のためには、
これは <quote>192.168.1</quote> から始まる全ての IP アドレスを
示しています。文法が <application>inetd</application> と
異なることに注意してください。この場合の
<literal>server</literal> 項目の記述は
 <command>tftp</command> デーモン、<command>in.tftpd</command> です。
またここでも、<application>libwrap/tcpwrappers</application> 
サポートが <application>xinetd</application> に組み込み
コンパイルされていることを仮定しています。
デーモンを走らせている <literal>user</literal> 項目は
 <quote>nobody</quote> になります。
そうです、 <quote>nobody</quote> と呼ばれるユーザアカウントが
あるのです。。これは可能ならば、
この種のデーモンを非ルートユーザとして走らせる賢い方法です。
最後に、 <literal>disable</literal> の項目は
サーヴィスをオン、またはオフにする <application>xinetd</application> 
の方法で、この場合には <quote>on</quote> になっています。
これはここでの一例としてオンになっているだけです。
安全でないなら、 <application>tftp</application> を
公けのサーバとして走らせては「いけません」。
</para>

</sect3>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="portsentry">
<title>PortSentry</title>

<para>
<!--
 <ulink url="http://www.psionic.org/products/portsentry.html">Portsentry</ulink> 
 works quite differently than the other tools discussed so far. 
 <application>Portsentry</application> does what its name implies &#045;&#045; 
 it guards ports. <application>Portsentry</application> is configured with the
 <filename>/etc/portsentry/portsentry.conf</filename> file.
 -->
  <ulink url="http://www.psionic.org/products/portsentry.html">portsentry</ulink> はこれまで議論した他のツールとはまったく異なる働きをします。
<application>portsentry</application> はその名の通りのことをします、
つまり、ポートを守ってくれるのです。
<application>portsentry</application> は
 <filename>/etc/portsentry/portsentry.conf</filename> ファイルで設定します。
</para>

<para>
<!--
 Unlike the other applications discussed above, it does this by actually
 becoming the listening server on those ports. Kind of like baiting a trap.
 Running <literal>netstat -taup</literal> as root while
 <application>portsentry</application> is running, will show
 <application>portsentry</application> as the <literal>LISTENER</literal> on
 whatever ports <application>portsentry</application> is configured for. If
 <application>portsentry</application> senses a connection attempt, it blocks
 it completely. And then goes a step further and blocks the route to that host
 to stop all further traffic. Alternately, <application>ipchains</application>
 or <application>iptables</application> can be used to block the host
 completely. So it makes an excellent tool to stop port scanning of a range of
 ports.
 -->
  上で議論した他のアプリケーションとは違って、
これは実際に自分自身がポートで耳をすませるサーバになることによって、
この仕事をします。これは罠をしかけるのに似ています。
<application>portsentry</application> が走っている間、
root として <literal>netstat -taup</literal> を走らせると、
<application>portsentry</application> が設定されているポートが何であれ、
その <literal>LISTENER</literal> として <application>portsentry</application> が示されます。
もし、<application>portsentry</application> が接続試行を感知すると、
それを完全にブロックします。
そして次の段階に進んで、それ以上の通信を全て停止するために、
そのホストへの経路をブロックします。
代わりに、<application>ipchains</application>
 や <application>iptables</application> を完全にそのホストを
ブロックするために用いることができます。
そういうわけでこれは、ある範囲にわたるポートスキャンを
やめさせる素晴らしいツールになるのです。
</para>

<para>
<!--
 But <application>portsentry</application> has limited flexibility as to 
 whether it allows a given connection. It is pretty much all or nothing. You
 can define specific IP addresses that it will ignore in 
 <filename>/etc/portsentry/portsentry.ignore</filename>. But you cannot allow
 selective access to individual ports. This is because only one server can 
 bind to a particular port at the same time, and in this case that is 
 <application>portsentry</application> itself. So it has limited usefulness as a
 stand-alone firewall. As part of an overall firewall strategy, yes, it can
 be quite useful. For most of us, it should not be our first line of defense,
 and we should only use it in conjunction with other tools.
 -->
  しかし <application>portsentry</application> は
接続を許可するかどうかについては自由が限られていて、
オールオアナッシングで全部許すか全部拒否するかです。
無視したい特定のIPアドレスを
 <filename>/etc/portsentry/portsentry.ignore</filename> ファイルで
定義できますが、個々のポートに対して
選択的なアクセスを許可することは出来ません。
その理由は、
同時に特定の一つのポートに結び付けられるのは唯一つのサーバだけだからで、
この場合には <application>portsentry</application>
 自身ということになります。
ですから、スタンドアローンのファイアーウォールとしては
有用性が限られます。しかし、
ファイアーウォール全体の戦略の一部としては、そう、
とても有用なのです。ほとんどの場合、
これは防御の最前線に使うべきではなく、
他のツールと結びつけて使うべきでしょう。
</para>

<para>
<!--
 Suggestion on when <application>portsentry</application> might be useful:
-->
  どんな時に
 <application>portsentry</application> が便利に使えるかのアドバイス：
</para>

<ItemizedList>

<listitem>
 <para>  
<!--
  As a second layer of defense, behind either
  <application>ipchains</application> or <application>iptables</application>. 
  Packet filtering will catch the packets first, so that anything that gets 
  to <application>portsentry</application> would indicate a misconfiguration.
  Do not use in conjunction with <application>inetd</application> services &#045;&#045;
  it won't work. They will butt heads.
-->
  防御の二番目の層として、
<application>ipchains</application> や <application>iptables</application>
 の背後で使う。
パケットフィルタリングがまずパケットを捕まえることになるので、
次に <application>portsentry</application> に入ってきたものは、
それが何であろうが設定ミスであることになります。
<application>inetd</application> サーヴィスと一緒に使わないように。
これは働きません。この二つはぶつかりあってしまいますから。
 </para>
</listitem>

<listitem>
 <para>  
<!--
  As a way to catch full range ports scans. Open a pinhole or two in the 
  packet filter, and let <application>portsentry</application> catch these 
  and re-act accordingly. 
-->
  全範囲のポートスキャンをキャッチする方法として。
パケットフィルターに一つか二つの小さな穴を開けて、
<application>portsentry</application>
 にこれらを捕まえ、随時対応させます。
 </para>
</listitem>

<listitem>
 <para>  
<!--
  If you are <emphasis>very sure</emphasis> you have no exposed public servers
  at all, and you just want to know who is up to what. But do not assume 
  anything about what <application>portsentry</application> is protecting. 
  By default it does not watch all ports, and may even leave some very 
  commonly probed ports open. So make sure you configure it accordingly.
  And make sure you have tested and verified your set up first, and that
  nothing is exposed. 
 -->
  外にさらされた公開サーバは全くないという
<emphasis>絶対の確信があり</emphasis>、
誰が何に繋ごうとしているのか知りたいだけのとき。
しかし、
<application>portsentry</application> が守っているものについて、
こうだろう、とは何も勝手に仮定しないでください。
デフォルトでは、それは全てのポートを見ているわけではなく、
非常によく外から探られることがあるいくつかのポートを
開いたままにしていることさえありえます。
ですから、状況に応じて正しく設定されていることを確認してください。
そして、まず、あなたの設定がテストされ証明されていること、
何も外部にさらされていないことを確認してください。
 </para>
</listitem>

</ItemizedList>

<para>
<!--
 All in all, the packet filters make for a better firewall.
-->
  結局、結論としては、
パケットフィルターの方が良いファイアーウォール
を作るために役立つということです。
</para>

</sect2>

<!--  ~  End section  ~  -->


<!--   ~~~~~       New section      ~~~~~     -->
<sect2 id="proxies">
<title><!--Proxies-->プロキシ</title>

<para>
<!--
 The dictionary defines <quote>proxy</quote> as <quote>the authority or power
 to act on behalf of another</quote>. This pretty well describes software proxies as
 well. It is an intermediary in the connection path. As an example, if we
 were using a web proxy like <quote>squid</quote> (<ulink
 url="http://www.squid-cache.org/">http://www.squid-cache.org/</ulink>), 
 every time we browse to a web site, we
 would actually be connecting to our locally running <application>squid</application> server.
 Squid in turn, would relay our request to the ultimate, real destination. And
 then <application>squid</application> would relay the web pages back to us. It is
 a go-between. Like <quote>firewalls</quote>, a <quote>proxy</quote> can refer
 to either a specific application, or a dedicated server which runs a proxy
 application. 
-->
  辞書によれば、<quote>proxy（プロキシ）</quote> という言葉は、
他の人の代わりに行動する権限または力と定義されています。
これはソフトウェアのプロキシについてもなかなか良い説明になっています。
プロキシは通信経路の中間物です。例えば、
我々が <quote>squid</quote> (<ulink
 url="http://www.squid-cache.org/">http://www.squid-cache.org/</ulink>)
 のような Web プロキシを用いていたとすれば、
Web サイトを閲覧する度に、
実際のところは、我々がローカルに走らせている
 <application>squid</application> サーバに接続しているのです。
そして、squid はこの要求を最終点の、本当の目的場所にリレーします。
そして次に <application>squid</application> は Web ページを
リレーしてこちらに返してくれるのです。つまりプロキシは仲立ちです。
<quote>ファイアーウォール</quote> のように、
<quote>プロキシ</quote> は他の特定のアプリケーションや、
プロキシ・アプリケーションを走らせている専用サーバも参照できます。
</para>

<para>
<!--
 Proxies can perform various duties, not all of which have much to do with
 security. But the fact that they are an intermediary, makes them a good place
 to enforce access control policies, limit direct connections through a
 firewall, and control how the network behind the proxy looks to the Internet.
 So this makes them strong candidates to be part of an overall firewall
 strategy. And, in fact, are sometimes used instead of packet filtering
 firewalls. Proxy based firewalls probably make more sense where many users
 are behind the same firewall. And it probably is not high on the list of
 components necessary for home based systems. 
-->
  プロキシは様々な仕事を果たしてくれますが、
その全てがセキュリティに深く関係しているわけではありません。
しかし、プロキシは通信の仲介であるために、
アクセス制御のポリシーを実施して
ファイアーウォールを通る直接の接続を制限し、
プロキシの背後にあるネットワークが
外部のインターネットからどのように見えるかを
制御する格好の場所になるのです。
これによって、プロキシはファイアーウォール全体戦略の一部として、
強力な候補になります。
そして、事実、時にパケットフィルタリングのファイアーウォール
の代わりに用いられることもあります。
多くのユーザが同じファイアーウォールに背後にいるような場合には、
おそらくプロキシに基づいたファイアーウォールの方がより合理的でしょう。
しかし、一般の自宅でのシステムにおいては、
あまり優先順位は高くないかもしれません。
</para>

<para>
<!--
 Configuring and administering proxies can be complex, and is beyond the scope of
 this document. The Firewall and Proxy Server HOWTO, <ulink url="http://tldp.org/HOWTO/Firewall-HOWTO.html
 ">http://tldp.org/HOWTO/Firewall-HOWTO.html</ulink>, has examples 
 of setting up proxy firewalls. Squid usage is discussed at 
<ulink url="http://squid-docs.sourceforge.net/latest/html/book1.htm">http://squid-docs.sourceforge.net/latest/html/book1.htm</ulink>
 -->
  プロキシを設定し管理することは時に複雑で、
この文書の範囲を超えています。
ファイアーウォールとプロキシサーバの HOWTO 
  <ulink url="http://tldp.org/HOWTO/Firewall-HOWTO.html
 ">http://tldp.org/HOWTO/Firewall-HOWTO.html</ulink>
（<ulink url="http://www.linux.or.jp/JF/JFdocs/Firewall-HOWTO.html">JF 日本語訳</ulink>）
 にプロキシファイアーウォールを設定する例が載っています。
squid の使い方は
<ulink url="http://squid-docs.sourceforge.net/latest/html/book1.htm">http://squid-docs.sourceforge.net/latest/html/book1.htm</ulink>
 で議論されています。
</para>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="indapps">
<title><!--Individual Applications-->個別のアプリケーション</title>

<para>
<!--
 Some servers may have their own access control features. You should check 
 this for each server application you run. We'll only look at a few of the
 common ones in this section. Man pages, and other application specific
 documentation, is your friend here. This should be done whether you have
 confidence in your firewall or not. Again, <application>layers</application>
 of protection is always best. 
-->
  サーバの中にはそれ自身のアクセス制御機能を持っているものもあります。
自分が走らせているサーバアプリケーションのそれぞれについて、
これをチェックすべきでしょう。この章では、二、三のよくあるものについて
だけ見ることにします。
man ページやアプリケーション個別の文書などが役立ちます。
これは自分のファイアーウォールに自信を持っていてもいなくても、
行うべきことです。再びここでも、
防御の<application>多層化</application>が常にベストなのです。
</para>

<para>
 <itemizedlist>

 <listitem>
  <para>
<!--
    <application>BIND</application> - a very common package that provides name
    server functionality. The daemon itself is <quote>named</quote>. This only 
    requires full exposure to the Internet if you are providing DNS look ups 
    for one or more domains to the rest of the world. If you are not sure what
    this means, <emphasis>you do not need, or want</emphasis>, it exposed. For
    the overwhelming majority of us this is the case. It is a very common
    crack target. 
-->
  <application>BIND</application> : ネームサーバの機能を果たす
非常にありふれたパッケージです。
そのデーモン自体は <quote>named</quote> です。
これは、外部の世界に対して、
一つ以上のドメインについてのDNS 参照を提供しているなら、
インターネットに完全にさらす必要があります。
もしこれが何を意味するのかあなたによくわからないなら、
それを表にさらす
<emphasis>必要がないか、そうすべきでないか</emphasis>
のどちらかです。
ほとんどの人はこの場合にあたるでしょう。
実際、これは非常にありふれたクラックのターゲットです。
   </para>

   <para>
<!--
    But it may be installed, and can be useful in a caching only mode. This 
    does not require full exposure to the Internet. Limit the interfaces 
    on which it <quote>listens</quote> by editing
    <filename>/etc/named.conf</filename> (random example shown):
-->
  しかし、これはキャッシングオンリーモードでインストールされている
かもしれませんし、この場合は便利に使うことができます。
このときはインターネットに対して完全にさらす必要がありません。
<filename>/etc/named.conf</filename> ファイルを編集して、
それが<quote>聞いている</quote>インターフェースを制限してください
（以下は例の一つです）：
   </para>
   
   <para>
    <screen>
 
 options {
   directory "/var/named";
   listen-on { 127.0.0.1; 192.168.1.1; };
   version "N/A";
 };
   
    </screen>
   </para>
   
   <para>
<!--
     The <quote>listen-on</quote> statement is what limits where named 
     listens for DNS queries. In this example, only on localhost and bigcat's
     LAN interface. There is no port open for the rest of the world. It just
     is not there. Restart <command>named</command> after making changes.
-->
  <quote>listen-on</quote> の記述は、
DNS 要求に対して named が耳を開く場所を制限しています。
この例では、localhost と bigcat の LAN インターフェースのみを聞きます。
残りの世界については全くポートを開きません。
それは単にそこにないのです。変更してから、
<command>named</command> を再スタートさせてください。
   </para>
   
 </listitem> 

 <listitem>
  <para>
<!--
   X11 can be told not to allow TCP connections by using the
   <literal>-nolisten tcp</literal> command line option. If using 
   <command>startx</command>, you can make this automatic by placing 
   <literal>alias startx="startx &#045;&#045; -nolisten tcp"</literal> in your
   <filename>~/.bashrc</filename>, or the system-wide file, 
   <filename>/etc/bashrc</filename>, with your text editor. If using 
   <application>xdm</application> (or variants such as
   <application>gdm</application>, <application>kdm</application>, etc), 
   this option would be specified in
   <application>/etc/X11/xdm/Xservers</application> (or comparable) as 
   <literal>:0 local /usr/bin/X11/X -nolisten tcp</literal>. 
   <application>gdm</application> actually uses 
   <filename>/etc/X11/gdm/gdm.conf</filename>.
   -->
  X11 は <literal>-nolisten tcp</literal> コマンドラインオプションを
用いることで、TCP 接続を許可しないようにさせることができます。
<command>startx</command> を使っているなら、
<filename>~/.bashrc</filename> ファイル、または
システム全体のファイル <filename>/etc/bashrc</filename> に、
テキストエディタを使って
 <literal>alias startx="startx -- -nolisten tcp"</literal> と書くことで、
これを自動的に行うことが出来ます。
<application>xdm</application> (または
 <application>gdm</application>, <application>kdm</application> 
などのようなそのバリエーション)を使っているなら、
このオプションは
<application>/etc/X11/xdm/Xservers</application> （またはそのコンパチ）
によって<literal>:0 local /usr/bin/X11/X -nolisten tcp</literal>
と指定されることになります。
実際、<application>gdm</application> は
 <filename>/etc/X11/gdm/gdm.conf</filename> ファイルを使います。
  </para>
  <para>
<!--
   If using <application>xdm</application> (or comparable) to start X 
   automatically at boot, <filename>/etc/inittab</filename> can 
   be modified as: <literal>xdm -udpPort 0</literal>, to further 
   restrict connections. This is typically near the bottom of 
   <filename>/etc/inittab</filename>.
-->
  ブート時に自動的に X をスタートさせるために
 <application>xdm</application> （またはそのコンパチブル）を使っているなら、
<filename>/etc/inittab</filename> ファイルを
 <literal>xdm -udpPort 0</literal> のように変更して、
さらなる接続制限をすることができます。
これは典型的には <filename>/etc/inittab</filename> ファイルの
一番下のあたりにあります。
  </para>
  
 </listitem> 

 <listitem>
  <para>
<!--
   Recent versions of <application>sendmail</application> can be told to 
   listen only on specified addresses:
-->
  <application>sendmail</application> の最近のバージョンは、
特定のアドレスのみを聞くように設定できます。
  </para>

  <para>
   <screen>

 # SMTP daemon options
 O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA

   </screen>
  </para>

  <para>
<!--
   The above excerpt is from <filename>/etc/sendmail.cf</filename> which can
   be carefully added with your text editor. The
   <filename>sendmail.mc</filename> directive is:
-->
  上の抜粋は<filename>/etc/sendmail.cf</filename> ファイルからです。
変更はテキストエディタで注意深く行わねばなりません。
<filename>sendmail.mc</filename> ディレクティヴは以下のようになります：
  </para>

  <para>
   <screen>
 
 dnl This changes sendmail to only listen on the loopback device 127.0.0.1
 dnl and not on any other network devices.
 DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

   </screen>
  </para>
 
 <para>
<!--
  In case you would prefer to build a new <filename>sendmail.cf</filename>,
  rather than edit the existing one. Other mail server daemons likely have
  similar configuration options. Check your local documentation.
  <![%redhat;[ As of Red Hat 7.1, <application>sendmail</application> has 
  compiled in support for <application>tcpwrappers</application> as well.]]>
 -->
  場合によっては、
既にあるものを編集するよりも、
新しい <filename>sendmail.cf</filename> を作りたいこともあるでしょう。
他のメイルサーバデーモンも大抵、同様の設定オプションを持っています。
関連の文書をチェックしてみてください。
<![%redhat;[Red Hat 7.1 では、
<application>sendmail</application> は
 <application>tcpwrapper</application> 
をサポートするようコンパイルされています。]]>
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   <application>SAMBA</application> connections can be restricted in 
   <filename>smb.conf</filename>:
-->
  <application>SAMBA</application> の接続は以下のように
 <filename>smb.conf</filename> で制限することができます：
  </para>

  <para>
   <screen>

 bind interfaces = true
 interfaces = 192.168.1. 127.
 hosts allow = 192.168.1. 127.

   </screen>
  </para>

  <para>
<!--
   This will only open, and allow, connections from localhost (127.0.0.1), 
   and the local LAN address range. Adjust the LAN address as needed.
-->
  これで localhost (127.0.0.1) とローカルな LAN のアドレスの範囲のみ、
接続を開き、許可することになります。
必要に応じて LAN アドレスを調整してください。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   The <application>CUPS</application> print daemon can be told where 
   to listen for connections. Add to <filename>/etc/cups/cupsd.conf</filename>:
-->
  <application>CUPS</application> プリントデーモンは、
接続のために「聞く」場所を教えてやることができます。
<filename>/etc/cups/cupsd.conf</filename> に以下のように追加してください：
  </para>

  <para>
   <screen>

 Listen 192.168.1.1:631

   </screen>
  </para>

  <para>
<!--
   This will only open a port at the specified address and port number.
-->
  これで特定のアドレスとポート番号のポートだけを開くようになります。
  </para>

 </listitem> 

 <listitem>
  <para>
<!--
   <application>xinetd</application> can force daemons to listen only 
   on a specified address with its <quote>bind</quote> configuration
   directive. For instance, an internal LAN interface address. 
   See <literal>man xinetd.conf</literal> for this and other syntax. 
   There are various other control mechanisms as well.
-->
  <application>xinetd</application> はデーモンに対して、
その <quote>bind</quote> 設定の方向にあわせて、
特定のアドレスだけを聞くようにさせることができます。
例えば、内部 LAN インターフェースアドレスなどです。
このことや他の文法については <literal>man xinetd.conf</literal> 
で man ページを参照してください。
他にも色々の制御の仕組みがあります。
  </para>
 </listitem> 
 
 </itemizedlist>
</para>


<para>
<!--
 As always, anytime you make system changes, backup the configuration file
 first, restart the appropriate daemon afterward, and then check the
 appropriate logs for error messages.
-->
  これまでと同様に、システムに変更を加えたら常に、
まず設定ファイルをバックアップした後で、そのデーモンを再スタートさせ、
当該のログを見てエラーメッセージをチェックしてください。
</para>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="verify">
<title><!--Verifying-->検証</title>

<para>
<!--
 The final step after getting your firewall in place, is to verify that it 
 is doing what you intended. You would be wise to do this anytime you make 
 even minor changes to your system configuration. 
-->
  ファイアーウォール設定の最後のステップは、
あなたの目指した通りのことが行われているか検証することです。
あなたのシステム設定に些細な変更を加えたときでさえ、
常にこの検証をすることが賢明でしょう。
</para>

<para>
<!--
 So how to do this? There are several things you can do.
-->
  さて、どうやってこれをしましょう。
あなたにできることは色々あります。
</para>

<para>
<!--
 For our packet filters like <application>ipchains</application> and 
 <application>iptables</application>, we can list all our rules, chains, 
 and associated activity with <literal>iptables -nvL | less</literal>
 (substitute <command>ipchains</command> if appropriate). Open 
 your xterm as wide as possible to avoid wrapping long lines. 
-->
  <application>ipchains</application> と
 <application>iptables</application> のようなパケットフィルターについては、
我々の規則、チェイン、そして関連した動作の全てを
 <literal>iptables -nvL | less</literal>
 によってリストアップすることができます
（必要に応じて <command>ipchains</command> におきかえてください）。
xterm を出来る限り広く開いて、
長い行が折り曲げられないようにしましょう。
</para>

<para>
<!--
 This should give you an idea if your chains are doing what you think they 
 should. You may want to perform some of the on-line tasks you normally do 
 first: open a few web pages, send and retrieve mail, etc. This will, of 
 course, not give you any information on <application>tcpwrappers</application> or 
 <application>portsentry</application>. <command>tcpdchk</command> can 
 be used to verify <application>tcpwrappers</application> configuration 
 (except with <application>xinetd</application>).
-->
  これで設定したチェインが、望んだ通りのことをしているかどうか、
ある程度分るはずです。普段行いそうなオンラインの作業、
例えば、Web ページを開くとか、メイルを送受信することなどを、
試してみるべきです。これは、もちろんのことですが、
<application>tcpwrapper</application> や
 <application>portsentry</application> については何の情報も与えてくれません。
<application>tcpwrapper</application> の設定を検証するには
（<application>xinetd</application> を除いて）、
<command>tcpdchk</command> を用いることができます。
</para>

<para>
<!--
 And then, scan yourself. <application>nmap</application> is the scanning 
 tool of choice and <![%linuxall;[  may be available via your distribution]]> 
 <![%redhat;[ is included with recent Red Hat releases]]>, or from 
 <ulink url="http://www.insecure.org/nmap/nmap_download.html">http://www.insecure.org/nmap/nmap_download.html</ulink>. <application>nmap</application> is very 
 flexible, and essentially is a <quote>port prober</quote>. In other words, 
 it looks for open ports, among other things. See the
 <application>nmap</application> man page for details.
 -->
  そして次は、自分自身をスキャンしましょう。
<application>nmap</application> がそのスキャンのためのツールで、
<![%linuxall;[各ディストリビューションを通して手に入るでしょうし、]]>
<![%redhat;[最新の Red Hat リリースに含まれていますし、]]>
<ulink url="http://www.insecure.org/nmap/nmap_download.html">http://www.insecure.org/nmap/nmap_download.html</ulink> からも手に入ります。
<application>nmap</application> は非常に自由度が高く、
本質的には<quote>ポート調査ツール</quote>です。
言い換えれば、これは他のものの中から開いているポートを探します。
詳しくは <application>nmap</application> の man ページを参照してください。
</para>

<para>
<!--
 If you do run <application>nmap</application> against yourself (e.g. 
 <literal>nmap localhost</literal>), this should tell you what ports are 
 open &#045;&#045; and <emphasis>visible locally</emphasis> only! Which hopefully by now, is
 quite different from what can be seen from the outside. So, scan yourself,
 and then find a trusted friend, or site (see the <link linkend="links">Links
 section</link>), to scan you from the outside. Make sure you are not
 violating your ISPs Terms of Service by port scanning. It may not be allowed,
 even if the intentions are honorable. Scanning from outside is the best way
 to know how the rest of the world sees you. This should tell you how well
 that firewall is working. See the <link linkend="nmap">nmap</link> section in
 the Appendix for some examples on <application>nmap</application> usage.
 -->
   自分自身に対して <application>nmap</application> を
走らせると（例えば、<literal>nmap localhost</literal> など）、
開いているポートで、ただし、
<emphasis>ローカルに可視的</emphasis>であるもの、を教えてくれるはずです。
いまファイアーウォールがうまくいっていれば、
これは外部から見えているものとは全く違います。
ですから、自分自身をスキャンしたら、次に信用できる友達か、
サイト（<link linkend="links">リンク</link>を見てください）
を見つけ、外部からスキャンしてもらってください。
ただしポートスキャンがプロバイダのサービス規約に
違反していないか確認してください。
趣旨は立派であっても、それは許可されていないことかも知れません。
外部からのスキャンは外の世界から自分のシステムがどのように
見えているかを知る最良の方法です。
これはファイアーウォールがどのように働いているかを教えてくれます。
<application>nmap</application> の使い方の例については
補遺の <link linkend="nmap">nmap</link> の章を参照してください。
</para>

<para>
<!--
 One caveat on this: some ISPs may filter some ports, and you will not know
 for sure how well your firewall is working. Conversely, they make it look 
 like certain ports are open by using web, or other, proxies. The scanner 
 may see the web proxy at port 80 and mis-report it as an open port on your 
 system.  
-->
  警告を一つ：
プロバイダの中にはいくつかのポートをフィルターしているものがあり、
その場合には、
どのように自分のファイアーウォールが働いているか、
確実には知ることができないでしょう。
逆に言えば、その場合は web やプロキシによって、
あるポートが開いているように見せかけているのです。
スキャンするものは 80 番ポートの web プロキシを見て、
あなたのシステム上の開いたポートとして
誤って報告してしまうかも知れません。
</para>

<para>
<!--
 Another option is to find a website that offers <emphasis>full
 range</emphasis> testing. <ulink
 url="http://www.hackerwhacker.com">http://www.hackerwhacker.com</ulink> is
 one such site. Make sure that any such site is not just scanning a relatively
 few well known ports.
-->
  また一つの選択は<emphasis>ポートの全範囲の</emphasis>
テストを提供している web サイトを見つけることです。
<ulink
 url="http://www.hackerwhacker.com">http://www.hackerwhacker.com</ulink> 
がそのようなサイトの一つです。
このようなサイトのどれでも、
単に比較的少数のよく知られたポートをスキャンするだけではないことを
確認して、使用してください。
</para>

<para>
<!--
 Repeat this procedure with every firewall change, every system upgrade or new
 install, and when any key components of your system changes.
-->
  ファイアーウォールの変更やシステムのアップグレード、
また新たなインストールをするたびに、
そしてシステムのどんな重要コンポーネントが変更された時にも、
この手続きを繰り返してください。
</para>

<para>
<!--
 You may also want to enable logging all the denied traffic. At least 
 temporarily. Once the firewall is verified to be doing what you think it 
 should, and if the logs are hopelessly overwhelming, you may want to disable
 logging. 
-->
  また、拒否された全ての通信のログを取れるようにするべきでしょう。
少なくとも、一時的には。と言うのも、一旦、ファイアーウォールが
目指したとおりに動いていることを確認したら、
そして、もしログがとても手に負えないほど圧倒的な量なら、
ログを取るのを停止したくなるかもしれませんから。
</para>

<para>
<!--
 If relying on <application>portsentry</application> at all, please read the 
 documentation. Depending on your configuration it will either drop the 
 route to the scanner, or implement a 
 <application>ipchains</application>/<application>iptables</application> rule
 doing the same thing. Also, since it <quote>listens</quote> on the 
 specified ports, all those ports will show as <quote>open</quote>. A false
 alarm in this case.
 -->
   全く <application>portsentry</application> に頼っているなら、
その文書を読んでください。設定によっては、
それはスキャナーへの経路を落としてしまうか、
または同じことをする
 <application>ipchains</application>/<application>iptables</application> 
のルールを適用するかのどちらかでしょう。
また、それは特定のポートに<quote>耳をすませて</quote>いますから、
これら全てのポートは<quote>開いている</quote>と示されます。
この場合は偽の警報です。
</para>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="logging">
<title><!--Logging-->ログ</title>

<para>
<!--
 Linux does a lot of logging. Usually to more than one file. It is not always
 obvious what to make of all these entries &#045;&#045; good, bad or indifferent? Firewall 
 logs tend to generate a fair amount of each. Of course, you are wanting to 
 stop only the <quote>bad</quote>, but you will undoubtedly catch some
 harmless traffic as well. The 'net has a lot of background noise. 
-->
  Linux はたくさんのログをとります。
普通は複数のファイルにとります。
これらログに記録されているもの全てについて、
良いものなのか悪いものなのか、
またはどうでもよいものなのかは、常に明白なわけではありません。
ファイアーウォールはそれぞれかなりの量のログを作成しがちです。
もちろん、<quote>悪いもの</quote>だけを止めたいのですが、
他の無害な通信も当然ながら同様に捕まえてしまいます。
インターネットはたくさんの背景ノイズにあふれているのです。
</para>

<para>
<!--
 In many cases, knowing the intentions of an incoming packet are almost
 impossible. Attempted intrusion? Misbehaved protocol? Mis-typed IP address?
 Conclusions can be drawn based on factors such as destination port, source
 port, protocol, and many other variables. But there is no substitute for
 experience in interpreting firewall logs. It is a black art in many cases.
-->
  多くの場合、入ってくるパケットの目的を知ることはほとんど不可能です。
侵入の試みなのか、間違ったプロトコルなのか、
それとも IP アドレスのミスタイプかも知れません。
結論は行き先ポート、出発したポート、プロトコル、
そのほかの変数などの因子に基づいて導かれます。
しかし、ファイアーウォールのログの解釈については、
経験が何よりです。それは多くの場合、
経験に基づいた「アート」の領域なのです。
</para>

<para>
<!--
 So do we really need to log? And how much should we be trying to log? Logging
 is good in that it tells us that the firewall is functional. Even if we
 don't understand much of it, we know it is doing <quote>something</quote>.
 And if we have to, we can dig into those logs and find whatever data might be
 called for.
 -->
  それでは、我々は本当にログをとる必要があるのでしょうか？
そしてどれくらいたくさんログをとるべきなのでしょうか？
ログをとることの利点は、
ファイアーウォールが実際に機能を果たしていることがわかることです。
我々がログの内容のほとんどを理解できないとしても、
それが<quote>何事かを</quote>しているのだ、
ということは知ることができます。
そして、もし必要が生じれば、そのログを掘り起こして、
問題になっているデータを見つけることができるでしょう。
</para>

<para>
<!--
 On the other hand, logging can be bad if it is so excessive, it is difficult
 to find pertinent data, or worse, fills up a partition. Or if we over re-act
 and take every last entry as an all out assault. Some perspective is a great
 benefit, but something that new users lack almost by definition. Again, once
 your firewall is verified, and you are perplexed or overwhelmed, home
 desktop users may want to disable as much logging as possible. Anyone with
 greater responsibilities should log, and then find ways to extract the
 pertinent data from the logs by filtering out extraneous information.
-->
  一方では、ログをとることは、もしそれがあまりに過剰で、
適切なデータを見つけることができないほどなら悪ですし、
ハードディスクを一杯にしてしまうようなら、なおさらです。
または、過剰反応のあまり、
全ての最新エントリーが全て襲撃の証拠ととってしまうことも良くありません。
正しいバランス感覚でログを見ることは素晴らしい利益になりますが、
それはその定義からしてほとんどの場合、
新米ユーザに欠けている能力でもあります。
また、ひとたびファイアーウォールが検証されたなら、
しかも莫大なログに混乱して見当を失っているならば、
自宅のデスクトップユーザはログをとることを可能な限り
少なくとどめたいと思うことでしょう。
より大きな責任のある人はログをとるべきで、
異質な情報をフィルターにかけて、
ログから適切なデータを見つけ出すための方法を探さねばなりません。
</para>

<para>
<!--
 Not sure where to look for log data? <![%linuxall;[ This could conceivably be
 many places depending on how your distribution configured the various daemons
 and <command>syslogd</command>. Most logging is done in
 <filename>/var/log/*</filename>. Check that directory with <literal>ls -l
 /var/log/</literal> and see if you can tell the most active logs by size and
 timestamp. Also, look at <filename>/etc/syslog.conf</filename> to see where
 the default logs are. <filename>/var/log/messages</filename> is a good place
 to look for starters.]]> <![%redhat;[ The two logs to keep an eye on are
 <filename>/var/log/messages</filename> and <filename>/var/log/secure</filename>.
 There may be other application specific logs, depending on what you have 
 installed, or using. <application>FTP</application>, for instance, logs 
 to <filename>/var/log/xfer</filename> on Red Hat.]]>
-->
  ログのデータをどこで探せばよいのか、確かでないですか？
<![%linuxall;[これはあなたのディストリビューションが
様々なデーモンと<command>syslogd</command> をどう設定したかに
依存して多くの場所がありえます。
ほとんどのログは <filename>/var/log/*</filename> に取られています。
<literal>ls -l /var/log/</literal> として、
このディレクトリを調べてみてください。
そして、そのサイズとタイムスタンプから判断して、
もっとも頻繁に変化しているログはどれか見てみましょう。
また、デフォルトのログを置く場所はどこか知るために、
<filename>/etc/syslog.conf</filename> を見てください。
<filename>/var/log/messages</filename> ファイルを
最初に探すのがよいでしょう。]]>
<![%redhat;[目を注ぐべき二つのログファイルは、
<filename>/var/log/messages</filename> と
 <filename>/var/log/secure</filename> です。
インストールしたものや使っているものによって、
そのアプリケーション特定のログがあるかもしれません。
例えば、<application>FTP</application> は Red Hat では、
 <filename>/var/log/xfer</filename> ファイルにログをとります。]]>
</para>

<para>
<!--
 <application>Portsentry</application> and <application>tcpwrappers</application> 
 do a certain amount of logging that is not adjustable.
 <application>xinetd</application> has logging enhancements that can be turned
 on. Both <application>ipchains</application> and
 <application>iptables</application>, on the other hand, are very flexible as
 to what is logged. 
-->
  <application>portsentry</application> と
 <application>tcpwrapper</application> では
一定量のログをとり、それは調整できません。
<application>xinetd</application> では、
ログの拡張機能をオンにすることができます。
一方、<application>ipchains</application> と
 <application>iptables</application> では、
何のログを取るかについて、非常に柔軟性があります。
</para>

<para>
<!--
 For <application>ipchains</application> the <literal>-l</literal> option can
 be added to any rule. <application>iptables</application> uses the
 <literal>-j LOG</literal> target, and requires its own, separate rule instead.
 <application>iptables</application> goes a few steps further and allows
 customized log entries, and rate limiting. See the man page. Presumably, we 
 are more interested in logging blocked traffic, so we'd confine logging to 
 only our <literal>DENY</literal> and <literal>REJECT</literal> rules.
-->
  <application>ipchains</application> では
 <literal>-l</literal> オプションを任意のルールに追加できます。
<application>iptables</application> では
<literal>-j LOG</literal> ターゲットを用います。
これには、それ自身の別の代用のルールが必要です。
<application>iptables</application> はもう少し進んでいて、
ログを取るエントリーをカスタマイズしたり、
制限を見積もることもできます。man ページを参照してください。
おそらく、ブロックされた通信により興味を持っているでしょうから、
<literal>DENY</literal> と <literal>REJECT</literal> 
のルールに限ってログを取ることになるでしょう。
</para>

<para>
<!--
 So whether you log, and how much you log, and what you do with the logs, is
 an individual decision, and probably will require some trial and error so
 that it is manageable. A few auditing and analytical tools can be quite 
 helpful:
-->
  あなたが何のログを、どれくらい取るか、
そしてそのログをどうするか、は個々の判断になります。
そしておそらく、ログをうまく扱えるようになるには、
いくらかの試行錯誤が必要になるでしょう。
以下のような、
検査ツールと解析ツールは非常に助けになります：
</para>

<para>
<!--
 Some tools that will monitor your logs for you and notify you when necessary. 
 These likely will require some configuration, and trial and error, to make
 the most out of them: 
-->
  ログをモニターしてくれ、必要な時に教えてくれるツール。
これらをうまく使うには、いくらか設定の試行錯誤が必要になるでしょう：
</para>

<para>
 <itemizedlist>

 <listitem>
  <para>
<!--
   A nice log entry analyzer for <application>ipchains</application> and
   <application>iptables</application> from Manfred Bartz: <ulink
   url="http://www.logi.cc/linux/NetfilterLogAnalyzer.php3">http://www.logi.cc/linux/NetfilterLogAnalyzer.php3</ulink>.
   What does all that stuff mean anyway?
  -->
    <application>ipchains</application> と
 <application>iptables</application> のための
素晴らしいログエントリー解析ツールとして、
次の Manfred Bartz のものがあります：
<ulink   url="http://www.logi.cc/linux/NetfilterLogAnalyzer.php3">http://www.logi.cc/linux/NetfilterLogAnalyzer.php3</ulink>.
ログの内容が結局のところ、何を意味しているのか分かります。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--  
   <application>LogSentry</application> (formerly <application>logcheck</application>) is available from 
   <ulink url="http://www.psionic.org/products/logsentry.html">http://www.psionic.org/products/logsentry.html</ulink>,
   the same group that is responsible for
   <application>portsentry</application>. <application>LogSentry</application>
   is an all purpose log monitoring tool with a flexible configuration, that
   handles multiple logs. 
-->
  <application>LogSentry</application> 
(前の <application>logcheck</application>) は、
<ulink url="http://www.psionic.org/products/logsentry.html">http://www.psionic.org/products/logsentry.html</ulink> から手に入ります。
これは <application>portsentry</application> と同じグループによるものです。
<application>LogSentry</application> は柔軟な設定のできる、
万能のログモニタリングツールで、複数のログを扱えます。
  </para>
 </listitem>

 <listitem>
  <para>
<!--
   <ulink 
   url="http://freshmeat.net/projects/firelogd/">http://freshmeat.net/projects/firelogd/</ulink>, the Firewall Log Daemon from Ian Jones, is designed to 
   watch, and send alerts on <application>iptables</application> or 
   <application>ipchains</application> logs data.
   -->
  <ulink    url="http://freshmeat.net/projects/firelogd/">http://freshmeat.net/projects/firelogd/</ulink>　は、Ian Jones によるファイアーウォールの
ログデーモンで、
<application>iptables</application> か<application>ipchains</application>
のログデータを監視して、警報を送るように設計されています。 
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   <ulink
   url="http://freshmeat.net/projects/fwlogwatch/">http://freshmeat.net/projects/fwlogwatch/</ulink> by  Boris Wesslowski, is a similar idea, but supports 
   more log formats.
   -->
  <ulink
   url="http://freshmeat.net/projects/fwlogwatch/">http://freshmeat.net/projects/fwlogwatch/</ulink> は Boris Wesslowski によるもので、
同様のアイデアですが、より多くのログ形式をサポートしています。
   </para>
 </listitem> 
 
 </itemizedlist>
</para>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="wheretostart">
<title><!--Where to Start-->始まりの場所</title>

<para>
<!--
 Let's take a quick look at where to run our firewall scripts from.
-->
  ファイアーウォールのスクリプトがどこから開始されるのか、
間単に見てみましょう。
</para>

<para>
<!--
 <application>Portsentry</application> can be run as an init process, like
 other system services. It is not so important when this is done.
 <application>Tcpwrappers</application> will be automatically be invoked by
 <application>inetd</application> or <application>xinetd</application>, so not
 to worry there either.
 -->
   <application>portsentry</application> は他のシステムサーヴィスと同様に、
init プロセスとして走らせることができます。
これがいつ行われるかはそれほど重要ではありません。
<application>tcpwrapper</application> は
 <application>inetd</application> か <application>xinetd</application>
 によって自動的に呼び出されるので、これも心配はありません。
</para>

<para>
<!--
 But the packet filtering scripts will have to be started somewhere. And many 
 scripts will have logic that uses the local IP address. This will mean that 
 the script must be started after the interface has come up and been assigned
 an IP address. Ideally, this should be immediately after the interface is up.
 So this depends on how you connect to the Internet. Also, for protocols like 
 <application>PPP</application> or <application>DHCP</application> that may 
 be dynamic, and get different IP's on each re-connect, it is best to have 
 the scripts run by the appropriate daemon.
 -->
  しかし、パケットフィルタリングのスクリプトは、
どこかで開始させる必要があります。
そして、多くのスクリプトは、
そのローカルな IP アドレスを用いる仕組みを持っています。
これはそのスクリプトを、
そのインターフェースが立ち上がって IP アドレスが割り当てられた後で、
スタートしなければならないことを意味しています。
理想的には、これはインターフェースが立ち上がった直後であるべきです。
ですから、これはインターネットに接続している方法に依存します。
また、<application>PPP</application> や
 <application>DHCP</application> のように、割り当てが動的だったり、
再接続の毎に異なる IP になるかもしれないプロトコルについては、
適切なデーモンによってそのスクリプトを走らせるのが最善です。
</para>

<para>
<!--
 <![%linuxall;[ 
 For <application>PPP</application>, you probably have an 
 <filename>/etc/ppp/ip-up</filename> file. This will be executed every 
 time there is a connect or re-connect. You should put the full path to your 
 firewall script here. Check the local documentation for the correct 
 location. Debian use files in <filename>/etc/ppp/ip-up.d/</filename>, so 
 either put the script itself there, or a symlink to it.]]> Red Hat uses 
  <filename>/etc/ppp/ip-up.local</filename> for any user defined, local
 PPP configuration. <![%redhat;[ If this file does not exist, create it, and 
 make it executable (<literal>chmod +x</literal>). Then with your text editor, 
 add a reference to your firewall script.]]>
-->
   <![%linuxall;[<application>PPP</application> については、
多分 <filename>/etc/ppp/ip-up</filename> ファイルがあることでしょう。
これは接続、再接続の度に実行されます。
ファイアーウォールスクリプトへのフルパス名をここに書いてください。
正しい場所については個別のドキュメントもチェックしてください。
Debian は <filename>/etc/ppp/ip-up.d/</filename> にあるファイル群を
使っていますので、そこにスクリプト自身を置くか、
またはシムリンクしてください。]]>
Red Hat はユーザが定義したローカルな PPP 設定については
 <filename>/etc/ppp/ip-up.local</filename> を用います。
<![%redhat;[もしこのファイルがないようでしたら、
作成して、実行可能にし(<literal>chmod +x</literal>)、
テキストエディタでファイアーウォールスクリプトへの
参照を加えてください。]]>
</para>

<para>
<!--
 For <application>DHCP</application>, it depends on which client. 
 <command>dhcpcd</command> will execute 
 <command>/etc/dhcpcd/dhcpcd-&lt;interface&gt;.exe</command> (e.g.
 dhcpcd-eth0.exe) whenever a lease is obtained or renewed. So this is where to
 put a reference to your firewall script. For
 <command>pump</command><![%redhat;[ (the default on Red Hat)]]>, the main
 configuration file is <filename>/etc/pump.conf</filename>.
 <command>Pump</command> will run whatever script is defined by the
 <quote>script</quote> statement any time there is a new or renewed lease:
-->
  <application>DHCP</application> は、そのクライアントに依存します。
<command>dhcpcd</command> は、
IP の割り当てが得られたり更新される時はいつでも、
 <command>/etc/dhcpcd/dhcpcd-&lt;interface&gt;.exe</command> 
(例えば dhcpcd-eth0.exe)を実行します。
ですから、ここがファイアーウォールスクリプトへの
参照を置く場所になります。
<command>pump</command><![%redhat;[(Red Hat でのデフォルト)]]>については、
そのメインの設定ファイルは <filename>/etc/pump.conf</filename> です。
<command>Pump</command> は、
新たな IP の割り当てが得られるか更新されるといつでも、
以下のように、その<quote>スクリプト</quote>ステートメントで
定義された全てのスクリプトを走らせます：
</para>

<para>
 <programlisting>

 script /usr/local/bin/ipchains.sh

 </programlisting>
</para>

<para>
<!--
 If you have a static IP address (i.e. it never changes), the placement is not
 so important and should be <emphasis>before</emphasis> the interface comes
 up!
-->
  もしあなたが固定のIP アドレスを持っている場合
（つまり、IP アドレスが決して変更されない場合）には、
その場所はそれほど重要でありませんが、
そのインターフェースが立ち上がる<emphasis>前に</emphasis>すべきです。
</para>

</sect2>

<!--  ~  End section  ~  -->




<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="summary3">
<title><!--Summary and Conclusions for Step 3-->ステップ３のまとめと結論</title>

<para>
<!--
 In this section we looked at various components that might be used to
 construct a <quote>firewall</quote>. And learned that a firewall is as  
 much a strategy and combination of components, as it is any one particular 
 application or component. We looked at a few of the most commonly available 
 applications that can be found on most, if not all, Linux systems. This is 
 not a definitive list.
-->
  この章では、<quote>ファイアーウォール</quote>を構成するのに
用いられる様々なコンポーネント（構成要素）について見ました。
そしてファイアーウォールは、何かの特定のアプリケーションや
コンポーネントであると同時に、一つの戦略であり、
コンポーネントの組み合わせであるということを学びました。
全てではありませんがほとんどの Linux システムで、
最も普通に用いられるアプリケーションについて見ましたが、
これらに限るものではありません。
</para>

<para>
<!--
 This is a lot of information to digest at all at one time and expect anyone 
 to understand it all. Hopefully this can used as a starting point, and 
 used for future reference as well. The packet filter firewall examples can be
 used as starting points as well. Just use your text editor, cut and paste
 into a file with an appropriate name, and then run <literal>chmod
 +x</literal> against it to make it executable. Some minor editing of the
 variables may be necessary. Also look at the <link
 linkend="links">Links</link> section for sites and utilities that can be
 used to generate a custom script. This may be a little less daunting.
-->
  結局、この章は多くの情報を一度に要約したものであって、
読者の全員にその全てを理解してもらいたいものです。
また出発点として用いることが出来れば、とも思っており、
同様に、より進んだ内容へのリファレンスになることも期待しています。
パケットフィルターによるファイアーウォールの例も、
出発点として用いることができます。
単に、テキストエディタでカットアンドペーストして、
ファイルに適切な名前を書き入れ、
<literal>chmod +x</literal> として実行可能ファイルにして使えます。
変数をいくつか、少し編集する必要があるかもしれません。
また自分用のスクリプトを作るために用いることのできる
サイトやユーティリティについては
 <link linkend="links">リンク</link>の章を参照してください。
これで面倒な仕事を省けるかもしれません。 
</para>

<para>
<!--
 Now we are done with Steps 1, 2 and 3. Hopefully by now you have already
 instituted some basic measures to protect your system(s) from the various and
 sundry threats that lurk on networks. If you haven't implemented any of the
 above steps yet, now is a good time to take a break, go back to the top, and
 have at it. The most important steps are the ones above.
 -->
  ここまでで我々はステップ１，２，３を果たしました。
ここまでのところで、あなたは既に基本的な手段を設定し、
ネットワークに潜む雑多かつ様々な脅威から
システムを守っていることと思います。
まだ上に挙げたどのステップも遂げていないなら、
ここが中断するのによい場所ですから、上に戻ってそうしてください。
一番重要なステップは既に上で挙げた部分なのです。
</para>

<para>
<!--
 A few quick conclusions...
-->
  二、三の短い結論…
</para>

<para>
<!--
 <quote>What is best <application>iptables</application>, 
 <application>ipchains</application>, <application>tcpwrappers</application>, 
 or <application>portsentry</application>?</quote> The quick answer is that 
 <application>iptables</application> can do more than any of the others. So 
 if you are using a 2.4 kernel, use 
 <application>iptables</application>. Then,
 <application>ipchains</application> if using a 2.2 kernel. The long answer is
 <quote>it just depends on what you are doing and what the objective
 is</quote>. Sorry. The other tools all have some merit in any given
 situation, and all can be effective in the right situation. 
-->
  <quote><application>iptables</application>, 
 <application>ipchains</application>, <application>tcpwrapper</application>, 
 また <application>portsentry</application>
 の中で、どれがベストでしょうか？</quote>
手短かに答えれば、
<application>iptables</application> が
他のものよりも多くのことができます。
ですから、2.4 カーネルを用いているなら、
 <application>iptables</application> を使ってください。
そして、2.2 カーネルならば <application>ipchains</application> です。
でも、本当の詳しい答は、
<quote>それは単に、あなたが何をしているか、対象は何かによる</quote>
ということになります。すみません。
他のツールはそれぞれに与えられた情況によって利点があり、
また、どれも正しい状況で使えば効果的になりえます。
</para>

<para>
<!--
 <quote>Do I really need all these packages?</quote> No, but please combine
 more than one approach, and please follow all the above recommendations.
 <application>iptables</application> by itself is good, but in conjunction
 with some of the other approaches, we are even stronger. Do not rely on any
 single mechanism to provide a security blanket. <quote>Layers</quote> of
 protection is always best. As is sound administrative practices. The best
 <application>iptables</application> script in the world is but one piece of
 the puzzle, and should not be used to hide other system weaknesses.
-->
  <quote>これら全てのパッケージが必要でしょうか？</quote>
いいえ。しかし、一つのアプローチよりも、
多くを組み合わせて下さい。そして、上の全ての勧めにしたがってください。
<application>iptables</application> 自体良いものですが、
その他の手段をいくつか組み合わせると、もっと強くなります。
安全を確保するのに、一つだけの方法に頼らないでください。
<quote>何層にもなった</quote>防御が常にベストです。
安全な管理の実際がそうであるように。
世界で最高の <application>iptables</application> スクリプトも
パズルの単なる一つのピースに過ぎず、
システムの他の弱点を隠すために用いるべきではありません。
</para>

<para>
<!--
 <quote>If I have a small home LAN, do I need to have a firewall on each
 computer?</quote> No, not necessary as long as the LAN gateway has a properly
 configured firewall. Unwanted traffic should be stopped at that point. And as
 long as this is working as intended, there should be no unwanted traffic on
 the LAN. But, by the same token, doing this certainly does no harm. And on
 larger LANs that might be mixed platform, or with untrusted users, it would
 be advisable.
-->
  <quote>私は小さな家庭内 LAN を持っていますが、各コンピュータ上に
ファイアーウォールをおく必要がありますか？</quote>
いいえ。LAN ゲートウェイに適切に設定されたファイアーウォールが
ありさえすれば、必要ありません。
望まない通信はそこで食い止められるはずです。
そしてこれが望んだ通りに働いている限り、
LAN 内には望まぬ通信は存在しないはずです。
しかし、同じ理由で、
各コンピュータ上にファイアーウォールをおいても、
何も悪くはないことも確かです。
より大きな LAN で、色々なプラットフォームが混じっていたり、
信用できないユーザがいたりする場合には、
そうした方が良いと言えるでしょう。
</para>
 
</sect2>

</sect1>

<!--  ~  End section  ~  -->




<!--   ~~~~~~~~       New section Header    ~~~~~~~~~     -->

<sect1 id="intrusion">
<title><!--Intrusion Detection-->不正侵入の発見</title>

<para>
<!--
 This section will deal with how to get early warning, how to be alerted 
 after the fact, and how to clean up from intrusion attempts.
 -->
  この章は、いかにして早期に前兆に気づくか、
いかにして事実の後に警戒態勢をとるか、
そしていかにして侵入の企てからシステムをクリーンな状態に復旧するか、
を扱います。
</para>


<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="ids">
<title><!--Intrusion Detection Systems (IDS)-->侵入発見システム(Intrusion Detection System, IDS)</title>

<para>
<!--
 Intrusion Detection Systems (IDS for short) are designed to catch what might
 have gotten past the firewall. They can either be designed to catch an 
 active break-in attempt in progress, or to detect a successful break-in 
 after the fact. In the latter case, it is too late to prevent any damage, but
 at least we have early awareness of a problem. There are two basic types of
 IDS: those protecting networks, and those protecting individual hosts.
-->
  侵入発見システム(Intrusion Detection Systems, IDS)
はファイアーウォールを通り過ぎて何かが起こったかもしれないとき、
それを捕まえるよう設計されています。
また、進行中の能動的な侵入の企てを捕まえるようにも、
または事件の後に成功した侵入を発見するようにも設計されています。
後の場合には、いかなる被害を避けるにも遅過ぎますが、
少なくとも早期に問題に気づくことが出来ます。
IDS には二つの基本的なタイプがあります。
それは、ネットワークを保護するものと、個別のホストを保護するものです。
</para>

<para>
<!--
 For host based IDS, this is done with utilities that monitor the filesystem
 for changes. System files that have changed in some way, but should not
 change &#045;&#045; unless we did it &#045;&#045; are a dead give away that something is amiss.
 Anyone who gets in, and gets root, will presumably make changes to the system
 somewhere. This is usually the very first thing done. Either so he can get
 back in through a backdoor, or to launch an attack against someone else. In
 which case, he has to change or add files to the system. 
-->
  ホストに基づく IDS は、ファイルシステムの変更をモニタする
ユーティリティによってなされます。
変更されるべきでないシステムファイルが、
自分が変更したのではないのに、何らかの方法で変更されていたとすると、
それは何かまずいことが起こった証拠と言えます。
誰かが中に入り、root 権限を得て、
おそらくシステムのどこかに変更を加えているのでしょう。
これは通常、侵入後の一番最初になされることです。
これで、侵入者はバックドアを通って帰ってこられるし、
さらに他の誰かへの攻撃を始めることができます。
どの場合も、侵入者はシステムに対しファイルを変更するか、
付け加える必要があります。
</para>

<para>
<!--
 This is where tools like tripwire (<ulink
 url="http://www.tripwire.org">http://www.tripwire.org</ulink>) play a role.
 <![%redhat;[ Tripwire is included beginning with Red Hat 7.0. ]]>
 Such tools monitor various aspects of the filesystem, and compare them against a
 stored database. And can be configured to send an alert if
 <emphasis>any</emphasis> changes are detected. Such tools should only be 
 installed on a known <quote>clean</quote> system. 
-->
  ここでは tripwire (<ulink
 url="http://www.tripwire.org">http://www.tripwire.org</ulink>) のような
ツールが役割を果たします。
<![%redhat;[Red Hat 7.0 以降は tripwire を含んでいます。]]>
このようなツールはファイルシステムの様々な側面をモニタし、
それらを蓄積しておいたデータベースと比較します。
そして<emphasis>いかなる</emphasis>変更が発見されても、
警告を報せるように設定できます。
このようなツールは<quote>クリーンである</quote>（侵入されていない）
ことが分かっているシステムにだけインストールすべきです。
</para>

<para>
<!--
 For home desktops and home LANs, this is probably not an absolutely necessary
 component of an overall security strategy. But it does give peace of mind, and
 certainly does have its place. So as to priorities, make sure the Steps 1, 2
 and 3 above are implemented and verified to be sound, before delving into
 this.
-->
  自宅のデスクトップマシンと家庭内 LAN においては、
これはおそらくセキュリティの全体戦略において
絶対不可欠な部分というわけではないでしょう。
しかし、心の平安を与えてくれますし、存在意義があることは確かです。
ですから優先順位としては、これにとりかかる前に、
まず上のステップ１，２，３を果たしたことを確認して、
うまくいってることを確かめてください。
</para>

<para>
<!--
 <![%linuxall;[<application>RPM</application> users]]><![%redhat;[We]]> can
 get somewhat the same results with <literal>rpm -Va</literal>, which will
 verify all packages, but without all the same functionality. For instance, it
 will not notice new files added to most directories. Nor will it detect 
 files that have had the extended attributes changed (e.g. <literal>chattr +i</literal>, 
 man <command>chattr</command> and man <command>lsattr</command>). For this to
 be helpful, it needs to be done after a clean install, and then each time any
 packages are upgraded or added. Example:
-->
  <![%linuxall;[<application>RPM</application> ユーザ]]>
<![%redhat;[RedHat ユーザ]]>は、
<literal>rpm -Va</literal> で大体同じ結果が得られます。
これは全てのパッケージを調べてくれますが、
全く同じ機能を持っているわけではありません。
例えば、それはほとんどのディレクトリでは、
新しいファイルが追加されても気づきません。
また、拡張属性が変更されたファイルも検出しません
（例えば、<literal>chattr +i</literal>, 
 man <command>chattr</command> と man <command>lsattr</command>
で参照のこと）。これをうまく使うには、
クリーンインストールの後で行わねばなりませんし、
どんなパッケージがアップグレード、または追加されても、
その度に行う必要があります：
</para>

<para>
 <screen>
 
 # rpm -Va > /root/system.checked

 </screen>
</para>

<para>
<!--
 Then we have a stored system snapshot that we can refer back to. 
-->
  このようにして、後で比較できるように、
システムのスナップショットを保管しておくのです。
</para>

<![%linuxall;[
<para>
<!--
 Debian users have a similar tool with <command>debsums</command>.
-->
  Debian ユーザには類似したツール <command>debsums</command> があります。
</para>

<para>
 <screen>
 
 # debsums -s > /root/system.checked

 </screen>
</para>
]]>

<para>
<!--
 Another idea is to run <command>chkrootkit</command>
 (<ulink url="http://www.chkrootkit.org/">http://www.chkrootkit.org/</ulink>)
 as a weekly cron job. This will detect common <quote>rootkits</quote>. 
-->
  また別のアイデアには、
 <command>chkrootkit</command>
 (<ulink url="http://www.chkrootkit.org/">http://www.chkrootkit.org/</ulink>)
を毎週の cron ジョブとして走らせるという方法があります。
これは通常の <quote>rootkit</quote> 
（侵入した偽ルートがインストールするツール群）を検出します。
</para>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="hacked">
<title><!--Have I Been Hacked?-->もうハックされてる？</title>

<para>
<!--
 Maybe you are reading this because you've noticed something <quote>odd</quote> 
 about your system, and are suspicious that someone was gotten in? This can be
 a clue. 
-->
  あなたがここを読んでいるのは、
システムに何か<quote>おかしな</quote>ところがあるのに気づいて、
誰かに侵入されたのではないかと疑っているからかも知れませんね。
以下が手がかりになるはずです。
</para>

<para>
<!--
 The first thing an intruder typically does is install a <quote>rootkit</quote>. 
 There are many prepackaged rootkits available on the Internet. 
 The rootkit is essentially a script, or set of scripts, that makes quick work
 of modifying the system so the intruder is in control, and he is well hidden.
 He does this by installing modified binaries of common system utilities and
 tampering with log files. Or by using special kernel modules that achieve
 similar results. So common commands like <command>ls</command> may be
 modified so as to not show where he has his files stored. Clever! 
-->
  典型的な侵入者が最初に行うことは、
<quote>rootkit</quote> のインストールです。
インターネット上ではたくさんの rootkit のパッケージが手に入ります。
rootkit は本質的にはスクリプト、またはスクリプトの組み合わせで、
侵入者がシステムをコントロール下におき、うまく身を隠すために、
手早くシステムを変更するのに使うためのものです。
侵入者は、
通常のシステムユーティリティの改竄バイナリをインストールすることと、
ログファイルを書き変えることで、これを行います。
または、同様の結果が得られる特別なカーネルモジュールを使います。
ですから、<command>ls</command> のような普通のコマンドが、
侵入者がファイルを保存している場所を表示しないように、
変更されているかも知れないのです。なんて賢いのでしょう！
</para>

<para>
<!--
 A well designed rootkit can be quite effective. Nothing on the system can
 really be trusted to provide accurate feedback. Nothing! But sometimes the
 modifications are not as smooth as intended and give hints that something is
 not right. Some things that <emphasis>might</emphasis> be warning signs:
-->
  うまく設計された rootkit は極めて効果的です。
そのシステムの上の何一つ、
正しい答えを返してくれるか本当には信用できなくなります。
何もかもです！しかし時に、その変化が狙い通りほども滑らかではなく、
何事かが正しくないというヒントを与えてくれます。
以下は危険信号<emphasis>かも知れない</emphasis>兆候のいくつかです：
</para>

<para>
 <itemizedlist>

 <listitem>
  <para>  
<!--
   <command>Login</command> acts weird. Maybe no one can login. Or only 
   root can login. Any <command>login</command> weirdness at all should be
   suspicious. Similarly, any weirdness with adding or changing passwords.
-->
  <command>login</command> コマンドのふるまいがおかしい。
または誰も login できない。または root だけが login できる。
ふるまいのおかしな <command>login</command> コマンドは
全て疑うべきです。 
パスワード追加、変更についておかしな所があるのも同様です。
  </para>
  <para>
<!--
   Wierdness with other system commands (e.g. <command>top</command> or
   <command>ps</command>) should be cause for concern as well. 
-->
  他のシステムコマンド（例えば、 <command>top</command> や
 <command>ps</command>）がおかしいのも同様に疑うべき要因です。
  </para>
 </listitem>

 <listitem>
  <para>
<!--
   System utilities are slower, or awkward, or show strange and unexpected 
   results. Common utilities that might be modified are: <command>ls</command>, 
   <command>find</command>, <command>who</command>, <command>w</command>, 
   <command>last</command>, <command>netstat</command>,
   <command>login</command>, <command>ps</command>, <command>top</command>.
   This is not a definitive list!
-->
  システムユーティリティの動作が通常より遅くなっている、
使い難い、または、おかしな、予期せぬ結果を示す。
変更を加えられるかもしれない普通のユーティリティは、
<command>ls</command>, 
   <command>find</command>, <command>who</command>, <command>w</command>, 
   <command>last</command>, <command>netstat</command>,
   <command>login</command>, <command>ps</command>, <command>top</command>
 などです。もちろんこれらに限りません！
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Files or directories named <quote>...</quote> or <quote>.. </quote> 
   (dot dot space). A sure bet in this case. Files with haxor looking 
   names like <quote>r00t-something</quote>.
-->
  <quote>...</quote> や <quote>.. </quote>（ドット、ドット、空白）
と名づけられたファイルやディレクトリ。
この場合はかなり怪しいです。
<quote>r00t-なになに</quote> のようなハッカーぽい名前のファイル。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Unexplained bandwidth usage, or connections. Script kiddies have a fondness 
   for IRC, so such connections should raise a red flag.
-->
  説明できない帯域の使用や接続。スクリプトキディたちは
IRC が大好きですから、このような接続は赤信号とすべきです。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Logs that are missing completely, or missing large sections. Or a sudden 
   change in <command>syslog</command> behavior.  
-->
  ログが完全に失われている、または大きな部分が欠損している。
または <command>syslog</command> のふるまいに突然の変化がある。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
    Mysterious open ports, or processes. 
-->
  謎の開いたポート、またはプロセス。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
    Files that cannot be deleted or moved. Some rootkits use 
    <command>chattr</command> to make files <quote>immutable</quote>, 
    or not changable. This kind of change will not show up with
    <command>ls</command>, or <command>rpm -V</command>, so the files look
    normal at first glance. See the man pages for <command>chattr</command>
    and <command>lsattr</command> on how to reverse this. Then see the next
    section below on restoring your system as the jig is up at this point.
-->
  削除することも move することもできないファイル。
rootkit の中にはファイルを<quote>不変</quote>にする、
または変更不可能にするために <command>chattr</command> コマンド
を使うものがあります。この種の変更は、
 <command>ls</command> や <command>rpm -V</command> では示されないので、
そのファイルは一見は正常に見えます。
これをくつがえすにはどうすればよいか、
 <command>chattr</command> と <command>lsattr</command> 
のman ページを参照してください。
そして、ここでお手上げになったシステムを復旧するための
次の章を見てください。
  </para>
  <para>
<!--
    This is becoming a more and more common script kiddie trick. In fact, one 
    quick test to run on a suspected system (as root):
-->
  これはますますありふれたのスクリプトキディのトリックになってきています。
実際、疑わしいシステム上で走らせる手っ取り早い手は（root になって）
次のようにします；
  </para>
  <screen>
  /usr/bin/lsattr `echo $PATH | tr ':' ' '` | grep i--
  </screen>
  <para>
<!--
   This will look for any <quote>immutable</quote> files in root's
   <literal>PATH</literal>, which is almost surely a sign of trouble since 
   no standard distributions ship files in this state. If the above command 
   turns up <emphasis>anything at all</emphasis>, then plan on completely
   restoring the system (see below). A quick sanity check:
-->
  これで root の <literal>PATH</literal> にある
全ての<quote>不変な</quote>ファイルを見つけてくれます。
標準的なディストリビューションでファイルをこの状態で
出荷しているものはありませんので、
これはほぼ確実にトラブルの徴候です。
もし、上のコマンドが<emphasis>どんなものであっても</emphasis>
何かのファイルを表示したら、（以下を参照して）
システムを完全に復帰させる計画をたててください。
手っ取り早く健全性をチェックするには次のようにします：
  </para>
  <screen>
  # chattr +i /bin/ps
  # /usr/bin/lsattr `echo $PATH | tr ':' ' '` | grep "i--"
    ---i---------- /bin/ps
  # chattr -i /bin/ps
  </screen>
  <para>
<!--
   This is just to verify the system is not tampered with to the point that
   <command>lsattr</command> is completely unreliable. The third line is 
   <emphasis>exactly</emphasis> what you should see. 
-->
  これは単に、<command>lsattr</command> が
完全にあてにならないと言うところまでは、
システムが変更を加えられてはいないということを確認しているだけです。
三行目が<emphasis>まさにその</emphasis>注目すべき箇所です。
  </para>

 </listitem> 

 <listitem>
  <para>
<!--
   Indications of a <quote>sniffer</quote>, such as log messages of an 
   interface entering <quote>promiscuous</quote> mode.
-->
  <quote>sniffer</quote>（トラフィック聴取、解析ツールの類）の兆候。
例えば、<quote>無差別</quote>モードになったインターフェースの
ログメッセージ。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Modifications to <filename>/etc/inetd.conf</filename>, 
   <filename>rc.local</filename>, <filename>rc.sysint</filename> or
   <filename>/etc/passwd</filename>. Especially, any additions. Try 
   using <command>cat</command> or <command>tail</command> to view these 
   files. Additions will most likely be appended to the end. Remember though
   such changes may not be <quote>visible</quote> to any system tools. 
-->
  <filename>/etc/inetd.conf</filename>, 
 <filename>rc.local</filename>, <filename>rc.sysint</filename>,
 <filename>/etc/passwd</filename> への変更。特に、追加。
<command>cat</command> か
 <command>tail</command> を使って、これらのファイルを見てみましょう。
追加は最後の行に付け加えられていることが多いでしょう。しかし、
このような変化はどのシステムツールからも<quote>見えない</quote>
かもしれないことを忘れないで下さい。
  </para>
 </listitem> 

 </itemizedlist>
</para>

<para>
<!--
 Sometimes the intruder is not so smart and forgets about root's 
 <filename>.bash_history</filename>, or cleaning up log entries, or even
 leaves strange, leftover files in <filename>/tmp</filename>. So these should
 always be checked too. Just don't necessarily expect them to be accurate. 
 Often such left behind files, or log entries, will have obvious 
 script kiddie sounding names, e.g. <quote>r00t.sh</quote>.
-->
  時に、侵入者はそれほど賢くなく、
root の <filename>.bash_history</filename>
 のことを忘れたり、ログの内容を消去するのを忘れたり、
または奇妙な、使い残しのファイルを <filename>/tmp</filename> に
残していたりすることさえあります。
ですから、これらを常にチェックしましょう。
それらが正しいと必ずしも期待しないように。
しばしば、これらの使い残しのファイルやログエントリーは、
明白にスクリプトキディぽい名前になっているでしょう。
例えば、<quote>r00t.sh</quote> など。
</para>

<para>
<!--
 Packet sniffers, like <application>tcpdump</application>
 (<ulink url="http://www.tcpdump.org">http://www.tcpdump.org</ulink>), might
 be useful in finding any uninvited traffic. Interpreting sniffer output is
 probably beyond the grasp of the average new user. <application>snort</application>  
 (<ulink url="http://www.snort.org">http://www.snort.org</ulink>), and 
 <application>ethereal</application>  
 (<ulink url="http://www.ethereal.com">http://www.ethereal.com</ulink>), are 
 also good. <application>Ethereal</application> has a GUI.
-->
  <application>tcpdump</application>
 (<ulink url="http://www.tcpdump.org">http://www.tcpdump.org</ulink>)
のようなパケットスニファ(sniffer)は招かれざる通信を見つけ出すのに
有用かもしれません。しかし、
スニファの出力を解釈することは、
おそらく平均的な新人ユーザのレベルを超えているでしょう。
<application>snort</application>  
 (<ulink url="http://www.snort.org">http://www.snort.org</ulink>) と
 <application>ethereal</application>  
 (<ulink url="http://www.ethereal.com">http://www.ethereal.com</ulink>)
も有用です。
<application>Ethereal</application> は GUI を備えています。
</para>

<para>
<!--
 As mentioned, a compromised system will undoubtedly have altered system
 binaries, and the output of system utilities is not to be trusted. Nothing on
 the system can be relied upon to be telling you the whole truth. Re-installing
 individual packages may or may not help since it could be system libraries
 or kernel modules that are doing the dirty work. The point here is that there
 is no way to know with absolute certainty exactly what components have been
 altered. 
-->
  既に述べたように、信頼できないシステムは疑いもなく、
システムバイナリを変更されてしまっているでしょうし、
そのシステムのユーティリティの出力を信頼すべきでないでしょう。
そのシステムの何も、
あなたに真実を全て伝えてくれると信用することはできません。
個別のパッケージを再インストールすることは、
助けになるかも知れないし、ならないかも知れません。
と言うのも、悪さをしているのは、
システムライブラリやカーネルモジュールかも知れないからです。
ここでのポイントは、どのコンポーネントに変更が加えられたか、
絶対的に確実に知る方法は存在しないということです。
</para>

<para>
<!--
 <![%linuxall;[<application>RPM</application> users]]> <![%redhat;[We]]> can
 use <literal>rpm -Va |less</literal> to attempt to verify the integrity all
 packages. But again there is no assurance that <application>rpm</application>
 itself has not been tampered with, or the system components that
 <application>RPM</application> relies on. 
-->
  <![%linuxall;[<application>RPM</application> ユーザ]]>
 <![%redhat;[RedHat ユーザ]]>
は全てのパッケージの整合性を確認するために、
 <literal>rpm -Va |less</literal> を使うことができます。
しかし、ここでも再び、<application>rpm</application>
自身が変更を加えられていないという保証はないし、
<application>RPM</application> が依存しているシステムコンポーネントが
いじられてしまっているかも知れないのです。
</para>

<para>
<!--
 If you have <command>pstree</command> on your system, try this instead 
 of the standard <command>ps</command>. Sometimes the script kiddies forget
 about this one. No guarantees though that this is accurate either.
-->
  もしシステムに <command>pstree</command> コマンドがあるなら、
これを標準的な <command>ps</command> コマンドの代わりに使ってみてください。
時々、スクリプトキディ（スクリプト使いの悪餓鬼、新米クラッカーたち）
はこのことを忘れているので。
しかし、これも正しいという保証はありません。
</para>

<para>
<!--
 You can also try querying the <filename>/proc</filename> filesystem, 
 which contains everything the kernel knows about processes that are 
 running:
-->
  また、<filename>/proc</filename> ファイルシステムを使って、
以下のように調べてみることもできます。
これには、現在走っているプロセスについて
カーネルが知っていることの全てが含まれています：
</para>

<para>
 <screen>
 
 # cat /proc/*/stat | awk '{print $1,$2}'
 
 </screen>
</para>

<para>
<!--
 This will provide a list of all processes and PID numbers (assuming 
 a malicious kernel module is not hiding this).
-->
  これは全てのプロセスと PID 番号
（邪悪なカーネルモジュールがこれを隠していないと仮定しての話ですが）
のリストを作ってくれます。
</para>

<para> 
<!--
 Another approach is to visit <ulink
 url="http://www.chkrootkit.org">http://www.chkrootkit.org</ulink>, download
 their rootkit checker, and see what it says.
-->
  また別の方法は
 <ulink
 url="http://www.chkrootkit.org">http://www.chkrootkit.org</ulink>
サイトを訪ねて、rootkit キャッチャーをダウンロードして、
それに調べさせてみることでしょう。
</para>

<para>
<!--
 Some interesting discussions on issues surrounding forensics can be found at <ulink
 url="http://www.fish.com/security/">http://www.fish.com/security/</ulink>. 
 There is also a collection of tools available, aptly called  
 <quote>The Coroner's Toolkit</quote> (TCT). 
-->
  この問題にまつわる興味深い議論の場が、
<ulink
 url="http://www.fish.com/security/">http://www.fish.com/security/</ulink>
で見つかると思います。そこには、
適切にも<quote>検視官の道具箱</quote> (The Coroner's Toolkit, TCT)
と呼ばれているツールもあります。
 </para>

<para>
<!--
 Read below for steps on recovering from an intrusion. 
-->
  侵入から復旧するためのステップについては以下を読んでください。
</para>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="reclaim">
<title><!--Reclaiming a Compromised System-->信頼を失ったシステムの復旧</title>

<para>
<!--
 So now you've confirmed a break-in, and know that someone else has root 
 access, and quite likely one or more hidden backdoors to your system. You've 
 lost control. How to clean up and regain control? 
-->
  さて、あなたは侵入を確認し、
誰か他の人が root アクセスを持っていることがわかりました。
しかも、システムに一つ以上の隠されたバックドア（裏口）
が作られている可能性も極めて高い。
あなたはコントロールを失ってしまいました。
どうやってこれを掃除し、コントロールを取り戻せばよいでしょう。
</para>

<para>
<!--
 There is no sure fire way of doing this short of a complete re-install. There
 is no way to find with assurance all the modified files and backdoors that
 may have been left. Trying to patch up a compromised system risks a false 
 sense of security and may actually aggravate an already bad situation.
 -->
  これを手っ取り早く行うには、
完全な再インストールしか確かな方法はありません。
全ての変更されたファイルと残されているかもしれないバックドアを
確実に見つけ出す方法はありません。
信頼を失ったシステムを取り繕おうとすることは、
間違ったセキュリティ意識であって、
しかも実際、既に悪い状況にあるシステムを
さらに悪化させる可能性があります。
</para>

<para>
<!--
 The steps to take, in this order:
-->
  以下の順番に従って、段階を踏んでいきましょう：
</para>

<para>
 <itemizedlist>

 <listitem>
  <para>
<!--
   Pull the plug and disconnect the machine. You may be unwittingly
   participating in criminal activity, and doing to others what has been done
   to you. 
-->
  プラグを抜いて、マシンをネットワークから切断しましょう。
あなたは望まぬ犯罪の片棒を担がされているかもしれず、
既に自分がされてしまったことを今、
他人に対して行っている最中かもしれないのです。
  </para>
 </listitem>

 <listitem>
  <para>
<!--
   Depending on the needs of the situation and time available to restore the
   system, it is advantageous to learn as much as you can about how the 
   attacker got in, and what was done in order to plug the hole and avoid a
   recurrence. This could conceivably be time consuming, and is not always
   feasible. And it may require more expertise than the typical user
   possesses.
-->
  システムを回復させるために使える時間と必要性に依存しますが、
穴を再び繋ぎ、また侵入者が帰ってくるのを避けるために、
出来る限りの時間をかけて、
攻撃者がどのようにして侵入し何がされたのかを
調査することは利益になります。
想像されるように、これは時間のかかる作業になりえますし、
常に実行できるわけではありません。
しかも、この作業には典型的なユーザが持っているよりも、
高度な熟練が必要となるかもしれません。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Backup important data. Do <emphasis>not</emphasis> include any system files
   in the backup, and system configuration files like
   <filename>inetd.conf</filename>. Limit the backup to personal data files 
   only! You don't want to backup, then restore something that might open 
   a backdoor or other hole.
-->
  大事なデータのバックアップをとりましょう。
システムファイルをバックアップに含め<emphasis>ない</emphasis>こと。
<filename>inetd.conf</filename> のようなシステム設定ファイルもです。
バックアップするのは、個人的なデータファイルのみに限ってください。
バックドアやその他の穴を開けられるかも知れないものまでバックアップして、
復活させたくはないでしょう。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Re-install from scratch, and reformat the drive during the installation
   (<command>mke2fs</command>) to make sure no remnants are hiding. Actually, 
   replacing the drive is not a bad idea. Especially, if you want to keep 
   the compromised data available for further analysis.
  -->
  最初から再インストールし、残り物が隠れていないことを
確実にするためにもインストールの際には、
ドライブを再フォーマットしましょう(<command>mke2fs</command>)。
実際のところ、特に、
これから解析を行うために信頼を失ったデータを保存しておきたい場合には、
ドライブごと入れ替えるのは悪くないアイデアです。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Restore from backups. After a clean install is the best time to install 
   an IDS (Intrusion Detection System) such as <application>tripwire</application>
   (<ulink url="http://www.tripwire.org">http://www.tripewire.org</ulink>). 
-->
  バックアップしたデータを戻します。
クリーンなインストールの後が、
 <application>tripwire</application>
   (<ulink url="http://www.tripwire.org">http://www.tripewire.org</ulink>)
などの IDS (侵入発見システム Intrusion Detection System)
をインストールする一番良いタイミングです。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Apply all updates<![%linuxall;[ or patches for your distribution. Check
   your vendor's web site for security related notices.]]> <![%redhat;[ from 
   <ulink url="ftp://updates.redhat.com">ftp://updates.redhat.com</ulink>.]]>
-->
  <![%linuxall;[そのディストリビューションの
全ての最新のアップデートファイルを適用し、パッチをあてます。
セキュリティ関係の情報を集めるためにベンダの web サイトを
チェックしてください。]]>
<![%redhat;[<ulink url="ftp://updates.redhat.com">ftp://updates.redhat.com</ulink> にある全ての最新アップデートファイルを適用してください。]]>
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
    Re-examine your system for unnecessary services. Re-examine your firewall and 
    access policies, and tighten all holes. <emphasis>Use new
    passwords</emphasis>, as these were stolen in all likelihood.
-->
  システムが不必要なサーヴィスを走らせていないか再チェックしましょう。
ファイアーウォールとアクセスポリシーを再検査し、
全ての穴を厳しく締めつけてください。
<emphasis>新しいパスワードを使ってください。</emphasis>
盗まれていることは非常にありそうなことですから。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
    Re-connect system ;-) 
-->
  システムを再接続します ;-)
  </para>
 </listitem> 

 </itemizedlist>
</para>

<para>
<!--
 At this time, any rootkit cleanup tools that may be available on-line are not 
 recommended. They probably do work just fine most of the time. But again, 
 how to be absolutely sure that all is well and all vestiges of the intrusion
 are gone?
-->
  この時点では、
オンラインで手に入る rootkit 駆除ツールを使うことはお勧めできません。
それらはほとんどの場合にはうまく働いてくれるでしょうが、
繰り返しますが、万事オーケーで、侵入の全ての形跡が去ったと、
どうやって絶対の確信が持てるというのでしょう。
</para>

</sect2>

</sect1>

<!--  ~  End section  ~  -->




<!--   ~~~~~~~~       New section Header    ~~~~~~~~~     -->

<sect1 id="general">
<title><!--General Tips-->一般的な Tips</title>

<para>
<!--
 This section will quickly address some general concepts for maintaining a
 more secure and reliable system or network. Let's emphasize
 <quote>maintaining</quote> here since computer systems change daily, as does
 the environment around them. As mentioned before, there isn't any one thing
 that makes a system secure. There are too many variables. Security is an
 approach and an attitude more than it is a reliance on any particular
 product, application or specific policy.
 -->
  この章は、より安全で信頼できるシステムやネットワークを
維持するための一般的なコンセプトを手短に紹介します。
コンピュータシステムはその周りの環境の変化に連れて、
日々変わって行くものですから、
ここでは、<quote>維持する</quote>ということを強調したいと思います。
既に述べたように、あるシステムを安全にするような、
一つの方法といったものは存在しません。
それにはあまりに多くの変数があるのです。
セキュリティとは特定の製品やアプリケーションやポリシーに
頼ることではなく、問題へのアプローチ、
またはその態度のことなのです。
</para>

<para>
 <itemizedlist>
 
 <listitem>
  <para>  
<!--
   Do not allow remote root logins. This may be controlled by a configuration 
   file such as <filename>/etc/securetty</filename>. Remove any lines 
   that begin <quote>pts</quote>. This is one big security hole.
-->
  遠隔からの root ログインを許可しないこと。
これは <filename>/etc/securetty</filename> のような設定ファイルで
制御できるでしょう。
<quote>pts</quote> から始まっている全ての行を削除してください。
これは大きなセキュリティホールです。
  </para>
 </listitem>

 <listitem>
  <para>
<!--
   In fact, don't log in as root at all. Period. Log in on your user account
   and <command>su</command> to root when needed. Whether the login is remote
   or local. Or use <command>sudo</command>, which can run individual commands
   with root privileges. 
   <![%linuxall;[(There should be a <command>sudo</command> package
   available from your vendor.) ]]> 
   <![%redhat;[(Red hat includes a <command>sudo</command> package. )]]>
    This takes some getting used to, but it is
   the <quote>right</quote> way to do things. And the safest. And will become 
   more a more natural way of doing this as time goes on.
-->
  そもそも、root としてログインしないで下さい。以上。
必要があればユーザアカウントでログインして、
<command>su</command> で root になってください。
ログインが遠隔からであっても、ローカルであってもです。
または <command>sudo</command> を用いてください。
これはルート特権で個別のコマンドを走らせることができます。
<![%linuxall;[（各ベンダから <command>sudo</command> 
パッケージを手に入れられるはずです）]]> 
<![%redhat;[（Red hat は <command>sudo</command> パッケージを含んでいます）]]>
これは慣れるのに少々かかりますが、
ことを行う上での正しい方法です。また、最も安全な方法でもあります。
そして、時がたつにつれ、ますます、
より自然な方法に思えてくることでしょう。
  </para>
  
  <para>
<!--
   I know someone is saying right now <quote>but that is so much trouble, I am
   root, and it is my system</quote>. True, but root is a specialized account that
   was not ever meant to be used as a regular user account. Root has access to
   everything, even hardware devices. The system <quote>trusts</quote> root.
   It believes that you know what you are doing. If you make a mistook, it
   assumes that you meant that, and will do it's best to do what you told it
   to do...even if that destroys the system!
-->
  誰かがまさに今、こう言っているのが聞こえますよ。
<quote>でも本当に面倒くさいじゃないか、
僕は root なんだし、それにこれは僕のシステムなんだから</quote>、と。
よろしい、しかし root は特別なアカウントであり、
通常のユーザアカウントとして使われるように意図されていないものです。
root は全てのものへの、ハードウェアデバイスにさえ、
アクセス権を持っています。
システムは root を<quote>信用している</quote>のです。
システムは root が何をしているのかを知っているのだ、と信じます。
もしあなたが間違いをしたら、システムはそう意図したのだと仮定し、
命令の通りにするよう全力を尽くすでしょう…
例え、そのシステムを破壊せよ、という命令だったとしても。
  </para>
   
  <para>
<!--
   As an example, let's say you start X as root, open
   <application>Netscape</application>, and visit a web site. The web page has
   badly behaved java script. And conceivably now that badly written java
   script might have access to much more of your system than if you had done
   it the <quote>right</quote> way.
   -->
  例えば、root として X をスタートさせ、
<application>Netscape</application> を開き、
web サイトを訪れたとしましょう。
その web ページは酷い振る舞いをする java スクリプトを含んでいたとすれば、
その酷い java スクリプトが、
あなたが<quote>正しい</quote>方法でおこなった時よりも、
あなたのシステムに対して、もっと深いアクセス権を持つ、
ということが充分考えられます。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Take passwords seriously. Don't give them out to anyone. Don't use the same
   one for everything. Don't use root's password for anything else &#045;&#045; except
   root's password! Never sign up or register on line, using any of your
   system passwords. Passwords should be a combination of mixed case letters,
   numbers and/or punctuation and a reasonable length (eight characters or
   longer). Don't use so-called <quote>dictionary</quote> words that are easy
   to guess like <quote>cat</quote> or <quote>dog</quote>. Don't incorporate 
   personal information like names or dates or hostnames. Don't write down
   system passwords &#045;&#045; memorize them.
-->
  パスワードのことを真剣に考えてください。
それらを誰にも渡してはいけません。
全てのものに同じパスワードを使わないこと。
root パスワードを他のものに使わないこと
（もちろん root のパスワードを除いて！）。
あなたのシステムのパスワードを使って、
絶対にオンラインでサインアップや登録をしないこと。
パスワードは大文字と小文字を混ぜたアルファベット、
数字、かつ（または）記号の組み合わせにし、
充分な長さ（8文字以上）を持つものにすべきです。
<quote>cat</quote> や <quote>dog</quote> のように簡単に推測される、
いわゆる<quote>辞書</quote>単語を用いないこと。
名前や日付やホスト名のような個人的な情報を使わないこと。
パスワードをどこにも書かず、頭に記憶すること。
   
<!--   

From FBI-NIPC (excerpt)

Password Protection 101

Remembering long passwords can be difficult, but there are some basic
techniques users can employ to lessen the pain. First, choose a phrase that
you will remember. As an example, we will use the phrase "The pearl in the
river." You can then take a number that you are familiar with, such as a
birthday. For this example we will use 7/4/01. Next, you can take the first
letter of your phrase and interlace it with the chosen date to make
something similar to t7p4i0t1r. This method creates a password that won't be
found in any dictionary and is unique to the person who created it.


      t p i t r =t7p4i0t1r

      7 4 0 1

-->
   
  </para>

  <para>
<!--
   Use the more secure <quote>shadow</quote> passwords. <![%linuxall;[This
   should be the default for any recent Linux distribution now.]]> 
   <![%redhat;[This has been the default on Red Hat for some time now.]]> If
   the file <filename>/etc/shadow</filename> exists, then it is enabled
   already. The commands <command>pwconv</command> and
   <command>grpconv</command>, can be used to convert password and group files
   to shadow format if available. 
-->
  より安全な<quote>シャドウ</quote>パスワードを使いましょう。
<![%linuxall;[これは今や、
全ての最近の Linux ディストリビューションでデフォルトになっているはずです。]]>
<![%redhat;[これはある時点から Red Hat でデフォルトになっています。]]>
もし <filename>/etc/shadow</filename> ファイルがあるなら、
既に使えるようになっています。
<command>pwconv</command> と <command>grpconv</command> コマンドがあるなら、
パスワードファイルとグループファイルをシャドウフォーマットに変換できます。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Avoid using programs that require clear text logins over untrusted networks 
   like the Internet. <command>Telnet</command> is a prime example. 
   <command>ssh</command> is much better. If there is any support for 
   SSL (Secure Socket Layers), use it. For instance, does your ISP offer POP
   or IMAP mail via SSL? Recent <![%linuxall;[ distributions should include ]]> 
   <![%redhat;[ Red Hat releases do include ]]> <application><ulink
   url="http://www.openssl.org/">openssl</ulink></application>, and many
   Linux applications can use SSL where support is available.
-->
  インターネットのような信頼できないネットワークを通じて、
テキストそのままのログインを要求するようなプログラムを使うのは避けましょう。
<command>telnet</command> が一番の例です。
<command>ssh</command> がずっと良い方法です。
もし SSL (Secure Socket Layer) のサポートがあれば、それを使いましょう。
例えば、あなたのプロバイダは SSL 経由の POP や IMAP メイルを提供していますか？
最近の<![%linuxall;[ディストリビューションでは]]>
<![%redhat;[Red Hat リリースでは]]>
<application><ulink
   url="http://www.openssl.org/">openssl</ulink></application>
を含んでいますし、多くの Linux アプリケーションは、
SSL がサポートされている所ではそれを使うことができます。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Set resource limits. There are various ways to do this. The need for 
   this probably increases with the number of users accessing a given system.
   Not only does setting limits on such things as disk space prevent
   intentional mischief, it can also help with unintentionally misbehaved
   applications or processes. <command>quota</command> (<literal>man
   quota</literal>) can be used to set disk space limits.
   <application>Bash</application> includes the <command>ulimit</command>
   command (<literal>man ulimit</literal> or <literal>man bash</literal>),
   that can limit various functions on a per user basis. 
   -->
  リソースに制限をおきましょう。
このためには色々な方法があります。
おそらく、この必要性は与えられたシステムにアクセスしている
ユーザ数に応じて増加するでしょう。
このような制限をおいておけば、
ディスク容量オーバーのような予期された災害を防げるだけでなく、
アプリケーションやプロセスの予期せぬ誤動作に対する防御にもなります。
<command>quota</command> コマンド(<literal>man quota</literal>)
はディスクスペースに制限を置くのに使えます。
<application>bash</application> は <command>ulimit</command>
コマンド(<literal>man ulimit</literal> または <literal>man bash</literal>)
を含んでいて、ユーザ毎に応じて様々な機能を制限できます。
  </para>

  <para>
<!--
   Also, not discussed here at any length, but <application>PAM</application> 
   (Pluggable Authentication Modules) has a very sophisticated approach to 
   controlling various system functions and resources. See <literal>man
   pam</literal> to get started. <application>PAM</application> is configured
   via either <filename>/etc/pam.conf</filename> or
   <filename>/etc/pam.d/*</filename>. Also files in
   <filename>/etc/security/*</filename>, including
   <filename>/etc/security/limits.conf</filename>, where again various sane
   limits can be imposed. An in depth look at <application>PAM</application>
   is beyond the scope of this document. The 
   User-Authentication HOWTO (<ulink url="http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html">http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html</ulink>) has more on this.
   -->
  また、ここでは長くは議論しませんが、
<application>PAM</application> (Pluggable Authentication Modules)
は様々なシステムの機能やリソースを制御するための
非常に洗練されたアプローチを提供しています。
手始めに <literal>man pam</literal> を参照してください。
<application>PAM</application> は
 <filename>/etc/pam.conf</filename> か <filename>/etc/pam.d/*</filename>
ファイルによって設定されます。
また、 <filename>/etc/security/*</filename> の中のファイル、
<filename>/etc/security/limits.conf</filename> などで、
様々な適当な制限をおくことができます。
<application>PAM</application> について詳しく見ることは
この文書の範囲を超えますので、
詳しくは
User-Authentication HOWTO
 (<ulink url="http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html">http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html</ulink>)を参照してください。
（JF版<ulink url="http://www.linux.or.jp/JF/JFdocs/User-Authentication-HOWTO.txt">http://www.linux.or.jp/JF/JFdocs/User-Authentication-HOWTO.txt</ulink>）
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
    Make sure someone with a clue is getting root's mail. This can be done with an 
    <quote>alias</quote>. Typically, the mail server will have a file such 
    as <filename>/etc/aliases</filename> where this can defined. This can 
    conceivably be an account on another machine if need be:
-->
  誰かきちんとした知識のある人が root へのメイルを
受け取っていることを確認しましょう。
これは <quote>alias</quote> を使ってできます。
典型的なメイルサーバでは、これが定義される場所は
 <filename>/etc/aliases</filename> ファイルです。
もし必要ならば、他のマシンのアカウントにしても構いません：
  </para>
  
  <para>
   <screen>
  
 # Person who should get root's mail.  This alias
 # must exist.
 # CHANGE THIS LINE to an account of a HUMAN
 # root メイルを受け取るべきひと。
 # このエイリアスは必要です。
 # この行を人間のアカウントへ変更してください。
 root:           hal@bigcat

   </screen>
  </para>

  <para>
<!--
   Remember to run <command>newaliases</command> (or equivalent) afterward.
-->
  その後で、 <command>newaliases</command> （か、同じ働きをするもの）
を走らせるのを忘れないように。
  </para>
  
 </listitem> 

 <listitem>
  <para>
<!--
   Be careful where you get software. Use trusted sources. How well do you
   trust complete strangers? Check <![%linuxall;[your vendor]]> 
   <![%redhat;[ Red Hat's ftp site (or mirrors)]]> first if looking for a
   specific package. It will probably be best suited for your system any way.
   Or, the original package's project site is good as well. Installing from raw
   source (either tarball or src.rpm) at least gives you the ability to
   examine the code. Even if you don't understand it ;-) While this does not
   seem to be a wide spread problem with Linux software sites, it is very
   trivial for someone to add a very few lines of code, turning that harmless
   looking binary into a <quote>Trojan horse</quote> that opens a backdoor to
   your system. Then the jig is up.
  -->
  ソフトウェアを手に入れる場所に注意してください。
信用できる情報源を用いましょう。
あなたはまったくの他人をどれくらい信用しますか？
特定のパッケージを探しているなら、まず
<![%linuxall;[各ベンダ]]>
<![%redhat;[Red Hat のftp サイト（か、そのミラーサイト）]]>
をチェックしてください。
おそらく、とにかくここがそのシステムにとって最良でしょう。
または、そのパッケージのプロジェクトのオリジナルサイトも
同様に良いでしょう。生のソースコードから
（または tarball か src.rpm から）インストールすることで、
少なくとも自分自身でそのコードをチェックすることができます。
実際はそれが理解できないとしても ;-)
これは Linux ソフトウェアサイトで広く拡がっている問題に
見えないかもしれませんが、
ある人にとってはコードにほんの数行を付け加えて、
無害に見えるバイナリを、
システムに裏ドアを開ける
<quote>トロイの木馬</quote>に変えてしまうことは、
極めて簡単なことなのです。
そうなったら、大変なことです。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
    So someone has scanned you, probed you, or otherwise seems to want into
    your system? Don't retaliate. There is a good chance that the source IP 
    address is a compromised system, and the owner is a victim already. Also, 
    you may be violating someone's Terms of Service, and have trouble with 
    your own ISP. The best you can do is to send your logs to the abuse
    department of the source IP's ISP, or owner. This is often
    something like <quote>abuse@someisp.com</quote>. Just don't expect to 
    hear much back. Generally speaking, such activity is not legally 
    criminal, unless an actual break-in has taken place. Furthermore, 
    even if criminal, it will never be prosecuted unless significant 
    damage (read: big dollars) can be shown.
    -->
  誰かがシステムをスキャンして調べている、
または誰かがシステムに侵入しようとしているようだ、としましょう。
報復しないでください。
源のIPアドレスは信頼できないシステムかも知れないし、
その持ち主が既に犠牲者なのかもしれません。
または自分が何かのサービス規約を破っていて、
自身のプロバイダとトラブルを起こしているのかもしれません。
この場合、最も良い対処法は、
ログを源の IP のプロバイダか、所有者の苦情係に送ることです。
これはしばしば <quote>abuse@someisp.com</quote> のようなアドレスです。
ただし、まともに相手をしてもらえると期待しないように。
一般的に言えば、実際の侵入が実行されない限り、
このような行動は法律的には犯罪ではありません。
さらに言えば、犯罪であったとしても、重大な損害が
（大金とか）示されない限り、法的に訴えることは無理でしょう。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   Red Hat<![%linuxall;[,Mandrake and Debian]]> users can install the <quote>Bastille
   Hardening System</quote>, <ulink
   url="http://www.bastille-linux.org/">http://www.bastille-linux.org/</ulink>.
   This is a multi-purpose system for <quote>hardening</quote> Red Hat and
   Mandrake system security. It has a GUI interface which can be used to
   construct firewall scripts from scratch and configure
   <application>PAM</application> among many other things. Debian support 
   is new.
-->
  Red Hat <![%linuxall;[と Mandrake と Debian]]> のユーザは
<quote>Bastille Hardening System</quote>
(<ulink url="http://www.bastille-linux.org/">http://www.bastille-linux.org/</ulink>) を使うことができます。
これは Red Hat と Mandrake のシステムセキュリティを
<quote>強化</quote>する多目的システムで、
一からファイアーウォールのスクリプトを構成し、
<application>PAM</application> やその他の色々のものを
設定するためのGUI インターフェースを持っています。
Debian のサポートは新しいものです。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   So you have a full-time Internet connection via cable-modem or DSL. But 
   do you always use it, or always need it? There's an old saying that
   <quote>the only truly secure system, is a disconnected system</quote>.
   Well, that's certainly one option. So take that interface down, or stop the
   controlling daemon (<command>dhcpcd</command>, <command>pppoed</command>,
   etc).  Or possibly even set up <application>cron</application> jobs to bring your
   connection up and down according to your normal schedule and usage. 
  -->
  ケーブルモデムか DSL を通じて、
インターネットへ常時接続しているとしましょう。
しかし、それを常に使っているでしょうか？
または常にそれが必要ですか？  
<quote>唯一の真にセキュアなシステムは、
ネットワークから切断されたシステムだ</quote>、
と昔から言われています。
これは確かに一つの選択でしょう。
ですから、インターフェースを落とすか停止する制御デーモン
(<command>dhcpcd</command>, <command>pppoed</command> など)
を使ってください。または、普段のスケジュールや
使用法にしたがって接続を切ったり繋いだりする
 <application>cron</application> ジョブを設定することも考えられます。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   What about cable and DSL routers that are often promoted as
   <quote>firewalls</quote>? The lower priced units are mostly equating 
   NAT (Network Address Translation), together with the ability to open holes 
   for ports through it, as a firewall. While NAT itself does provide a fair
   degree of security for the systems behind the NAT gateway, this does not
   constitute anything but a very rudimentary firewall. And if holes are
   opened, there is still exposure. Also, you are relying on the router's
   firmware and implementation not to be flawed. It is wise to have some kind
   of additional protection behind such routers. 
-->
  しばしば<quote>ファイアーウォール</quote>として宣伝されている
ケーブルルータまたは DSL ルータはどうでしょう？
安い値段のユニットはほとんど NAT (Network Address Translation)
に等しいもので、ファイアーウォールとして、
それを通じてポートのための穴を開ける能力を持っています。
NAT 自体は NAT ゲイトウェイの背後のシステムをかなりの程度には
安全に保ってくれますが、
これは非常に初歩的なファイアーウォール以外のなにものも与えてくれません。
そして、穴が開いているならば、それはまだ脅威にさらされているのです。
また、傷を作らないためには、
ルータのファームウェアや実装に依存することになります。
このようなルータの背後でいくつか追加的な防御をするのが、
賢い方法でしょう。
  </para>
 </listitem> 
 
 <listitem>
  <para>
<!--
   What about wireless network cards and hubs? Insecure, despite what 
   the manufacturers may claim. Treat these connections just as you would an
   Internet connection. Use secure protocols like <application>ssh</application> 
   only! Even if it is just one LAN box to another.
-->
  ワイアレスのネットワークカードやハブはどうでしょう？
製造元がなんと言おうが、安全ではありません。
これらの接続はインターネット接続と全く同じものと扱ってください。
<application>ssh</application> のような安全なプロトコルだけを用いましょう。
たとえそれが単に、ある LAN ボックスからもう一つのものへの接続でも。
  </para>
 </listitem> 
  
 <listitem>
  <para>
<!--
   If you find you need to run a particular service, and it is for just you,
   or maybe a relatively small number of people, use a non-standard port. Most 
   server daemons support this. For instance, <command>sshd</command> runs on 
   port 22 by default. All worms and script kiddies will expect it there, and 
   look for it there. So, run it on another port! See the <command>sshd</command>
   man page.
   -->
  もしある特定のサーヴィスを走らせる必要があると分かったら、
そしてそれを使うのは自分だけであるか、
比較的少数の人数のためのものなら、
標準的でないポート番号を使いましょう。
ほとんどのサーバデーモンはこれをサポートしています。
例えば、<command>sshd</command> はデフォルトでは 22 番ポートを使います。
ワームやスクリプトキディはみなこれを期待して、その番号を探します。
ですから、別のポート番号で走らせましょう！
<command>sshd</command> の man ページを参照してください。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   What about firewalls that block Internet connections according to the
   application (like <application>ZoneAlarm</application> from Windowsdom)?
   These were designed with this feature primarily because of the plethora 
   of virii and trojans  that are so common with MS operating systems. This 
   is really not a problem on Linux. So, really no such application exists 
   on Linux at this time. And there does not seem to be enough demand for it 
   that someone has taken the time to implement it. A better firewall can be 
   had on Linux, by following the other suggestions in this document.
-->
アプリケーションによってインターネット接続をブロックする
ファイアーウォール（例えば、ウィンドウズ王国から来た <application>ZoneAlarm</application> など）はどうでしょう？
これらは主に、
MS OS にあまりにありふれたものとなった
ヴィリー、つまりコンピュータウィルスと
トロイの木馬の過剰症に対応するように設計されているものです。
これは Linux にとっては実際、問題ではありません。
ですから、Linux 上では、
今のところこのようなアプリケーションは存在しないのです。
そして、誰かがそれを実装する手間をかける充分な需要もあるようには
思えません。Linux 上にはより良いファイアーウォールがあります。
この文書の他の提案にしたがって行けばよいのです。
  </para>
 </listitem> 

  
 <listitem>
  <para>
<!--
   Lastly, know your system! Let's face it, if you are new to Linux, you can't
   already know something you have never used. Understood. But in the process
   of learning, learn how to do things the right way, not the easiest way.
   There is several decades of history behind <quote>the right way</quote> of
   doing things. This has stood the test of time. What may seem unnecessary or
   burdensome now, will make sense in due time.
-->
  最後に、自分自身のシステムを知りましょう。
もしあなたが Linux の新米ユーザだというなら、
使ったことのないものを既に良く知っているはずがないのだ、
という事実に向かい合いましょう。理解しましょう。
そして、学習のプロセスの中で、
ものごとを、最も易しいやり方ではなくて、
正しいやり方で行う方法を学びましょう。
ものごとを<quote>正しい方法で</quote>行うことの背後には、
何十年もの歴史があるのです。
これは時間という試験をくぐり抜けてきています。
今これが不必要で面倒なことのように見えるとしても、
やがてはこれに意味があることがわかるでしょう。
  </para>

  <para>
<!--
   Be familiar with whatever services you are running, and the implications
   these services might have to the overall health of your system if
   something does go wrong. Read what you can, and ask questions. Don't run
   something as a service <quote>just because I can</quote>, or because the
   installer put it there. You can't start out being an experienced System
   Administrator clearly. But you can work to learn enough about your own
   system, that you are in control. This is one thing that separates *nix from
   MS systems: we can never be in complete control with MS, but we can with
   *nix. Conversely, if something bad happens, we often have no one else to
   blame. 
-->
  走らせているサーヴィスが何であろうと、それに親しみましょう。
そして、もし何かがおかしくなるときには、
これらのサーヴィスがシステム全体の健康に対して
持つかもしれない関連性に親しみましょう。
できる限りのものを読み、質問しましょう。
<quote>単にそれができるから</quote>、という理由や、
インストーラがそうしたから、という理由で、
何かをサーヴィスとして走らせてはいけません。
明らかに、誰も始めから経験を積んだシステム管理者であることはできません。
しかし、自分のシステムについて充分に学ぶために努力し、
システムをコントロール下におくことができます。
これは *nix を MS システムから区別する特徴の一つです。
つまり、MS システムでは決して完全なコントロールをすることはできませんが、
*nix では可能です。逆に言えば、何か悪いことが起こった時、
しばしば自分以外の誰も責めることができないのです。
  </para>
 </listitem> 
<!--
And neither a borrower nor lender be...in a pear tree :/
-->
 </itemizedlist>
</para>

</sect1>

<!--  ~  End section  ~  -->


<!--   ~~~~~~~~       New section Header    ~~~~~~~~~     -->

<sect1 id="appendix">
<title><!--Appendix-->補遺</title>

<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="serversetc">
<title><!--Servers, Ports, and Packets-->サーバ、ポート、パケット</title>
<para>
<!--
 Let's take a quick, non-technical look at some networking concepts, and how
 they can potentially impact our own security. We don't need to know much
 about networking, but a general idea of how things work is certainly going to
 help us with firewalls and other related issues.
-->
  ネットワークのいくつかの概念を、
特にそれらがどのようにセキュリティに潜在的な影響を与えるのかを、
技術的にならないように手短かに見てみましょう。
ネットワークについてそんなに多くを知る必要はなくても、
どのようにものごとが働いているかの一般的なアイデアを知ることは、
ファイアーウォールやその他の問題を理解する助けになるでしょう。
</para>

<para>
<!--
 As you may have noticed Linux is a very network oriented Operating System. 
 Much is done by connecting to <quote>servers</quote> of one type or another
 &#045;&#045; X servers, font servers, print servers, etc. 
-->
  もうお気づきになっているかもしれませんが、
Linux は非常にネットワーク指向なオペレーティングシステムです。
多くのことが一つのタイプの、またはそのほかの<quote>サーバ</quote>、
例えば、X サーバ、フォントサーバ、プリントサーバ、
等に接続することによって行われます。
</para>

<para>
<!--
 Servers provide <quote>services</quote>, which provide various capabilities,
 both to the local system and potentially other remote systems. The same
 server generally provides both functionalities. Some servers
 work quietly behind the scenes, and others are more interactive by nature. We
 may only be aware of a print server when we need to print something, but it
 is there running, listening, and waiting for connection requests whether we
 ever use it or not (assuming of course we have it enabled). A typical Linux
 installation will have many, many types of servers available to it. Default 
 installations often will turn some of these <quote>on</quote>.
-->
  サーバは<quote>サーヴィス</quote>を提供し、
そのサーヴィスは様々な能力を、
ローカルシステムと、潜在的には他のリモートシステムの両面に提供します。
一般的には、同じサーバが両方の機能を提供しています。
それぞれの場面の背後で静かに働いているサーバもありますし、
また他のサーバはその性質として、もっとインタラクティブに働いています。
我々は何かを印刷する必要があるときに、
プリントサーバの存在に気づくだけかも知れませんが、
それを実際に使おうが使うまいが
（もちろん使うことが可能であると仮定してですが）、
それはそこで動いていて、耳をすませていて、接続要求を待っているのです。
典型的な Linux インストールでは本当に沢山のタイプのサーバが
使えるようになっているでしょう。
デフォルトのインストールはしばしば、
これらのいくつかを<quote>オン</quote>にしてしまう、
つまり走らせてしまいます。
</para>

<para>
<!--
 And even if we are not connected to a real network all the time, we are still
 <quote>networked</quote> so to speak. Take our friendly local X server for
 instance. We may tend to think of this as just providing a GUI interface,
 which is only true to a point. It does this by <quote>serving</quote> to
 client applications, and thus is truly a server. But X Windows is also
 capable of serving remote clients over a network &#045;&#045; even large networks like
 the Internet. Though we probably don't really want to be doing this ;-)
-->
  ですから、常時、本当のネットワークに接続していないとしても、
やはり、言わば<quote>ネットワーク環境にある</quote>のです。
例えば、馴染み深いローカルな X サーバをとりましょう。
これは単に GUI インターフェースを提供するだけのものと考えられがち
かもしれませんが、これはある点においてのみ正しいだけです。
それはクライアントのアプリケーションに<quote>サーヴィスを提供する</quote>
ことでこれを行っていて、つまり実際にサーバなのです。
X Window はネットワーク越しにリモートクライアントに
サーヴィスを提供することもできます。
インターネットのような大きなネットワーク越しでさえ。
おそらく実際にはそんなことを望んでいないとしても ;-)
</para>

<para>
<!--
 And yes, if you are not running a firewall or have not taken other
 precautions, and are connected to the Internet, it is quite possible that
 someone &#045;&#045; anyone &#045;&#045; could connect to your X server. X11
 <quote>listens</quote> on TCP <quote>port</quote> 6000 by default. This 
 principle applies to most other servers as well &#045;&#045; they can be easily 
 connected to, unless something is done to restrict or prevent connections.
-->
  そして、そうです、あなたがファイアーウォールを走らせておらず、
または、代わりの手段もとっておらず、インターネットに接続しているとしたら、
それは誰かが、いえ、誰でも、あなたの X サーバに接続してくる
可能性が高いということなのです。
X11 はデフォルトでは 6000 番のTCP <quote>ポート</quote>で
耳をすませています。
この原則は他のほとんどのサーバにも同様に適用できます。
つまり、接続を制限するか避けるために何か手が打たれていない限り、
誰もが簡単に接続できるのです。
</para>

<para>
<!--
 In TCP/IP (Transmission Control Protocol/Internet Protocol) networks like we
 are talking about with Linux and the Internet, every connected computer 
 has a unique <quote>IP Address</quote>. Think of this like a phone number. 
 You have a phone number, and in order to call someone else, you have to know
 that phone number, and then dial it. The phone numbers have to be unique for
 the system to work. IP address are generally expressed as <quote>dotted
 quad</quote> notation, e.g. 152.19.254.81.
-->
  ここで議論している Linux やインターネットでの
TCP/IP (Transmission Control Protocol/Internet Protocol) ネットワークでは、
全ての接続されたコンピュータが一意な <quote>IP アドレス</quote>
を持っています。電話番号のように考えればいいでしょう。
各人が一つの電話番号を持っていて、
そして、他の誰かに電話をかけるためにはその人の電話番号を知る必要があり、
その電話番号をダイアルするわけです。
電話番号が機能するには、番号はそのシステムで一意でなければなりません。
IP アドレスは一般的にドットで分けられた四つの数字で、
例えば 152.19.254.81 のように記述されています。
</para>

<para>
<!--
 On this type of network, servers are said to <quote>listen</quote>. This
 means that they have a <quote>port</quote> opened, and are awaiting incoming
 connections to that port. Connections may be local, as is typically the case
 with our X server, or remote &#045;&#045; meaning from another computer
 <quote>somewhere</quote>. So servers <quote>listen</quote> on a specific
 <quote>port</quote> for incoming connections. Most servers have a default
 port, such as port 80 for web servers. Or 6000 for X11. See 
 <filename>/etc/services</filename> for a list of common ports and their 
 associated service.
-->
  この種のネットワーク上で、サーバは
<quote>listen している（聞いている、耳をすませている）</quote>
などと言われます。
この意味するところは、それらが<quote>ポート</quote>を開いていて、
そのポートに入ってくる接続を待っているということです。
接続は、X サーバが典型的な場合であるように、
ローカルなものかもしれませんし、
リモート、つまり<quote>どこかにある</quote>
他のコンピュータからのものかもしれません。
ですから、サーバは入ってくる接続に対して、
特定のポートで<quote>耳をすませている</quote>のです。
ほとんどのサーバはデフォルトのポートをもっています。
例えば、web サーバは 80 番のポートで、X11 は 6000 番です。
一般的なポートとそれらが提供するサーヴィスのリストについては、
<filename>/etc/services</filename> ファイルを見てください。
</para>

<para>
<!--
 The <quote>port</quote> is actually just an address in the kernel's 
 networking stack, and is a method that TCP, and other protocols, use to
 organize connections and the exchange of data between computers. There are
 total of 65,536 TCP and UDP ports available, though usually only a relatively
 few of these are used at any one time. These are classified as
 <quote>privileged</quote>, those ports below 1024, and
 <quote>unprivileged</quote>, 1024 and above. Most servers use the privileged
 ports. 
-->
  <quote>ポート</quote>
は実際にはカーネルのネットワーキングスタックの中の一つのアドレスであり、
TCP と他のプロトコルが接続を制御し、
コンピュータ間のデータ交換をするために用いられる方法の一つなのです。
全体では 65,536 の TCP と UDP ポートが使えますが、
普通は常時これらの中の比較的少数のものが使われています。
これらは 1024 未満の<quote>特権のある</quote>ポートと、
1024 以上の<quote>特権のない</quote>ポートの二つに分けられています。
ほとんどのサーバは特権のあるポートを使います。
</para>

<para>
<!--
 Only one server may listen on, or <quote>bind</quote> to, a port at a time.
 Though that server may well be able to open multiple connections via that one
 port. Computers talk to each other via these <quote>port</quote> connections.
 One computer will open a connection to a <quote>port</quote> on another
 computer, and thus be able to exchange data via the connection that has been
 established between their respective ports. 
-->
  唯一つのサーバだけが一度に一つのポートに耳をすませているか、
または<quote>結びつけ</quote>られています。
サーバはその一つのポートを通じて複数の接続を開くことができますが。
コンピュータは他のコンピュータにこれらの<quote>ポート</quote>
の接続を通して話しかけるのです。
一つのコンピュータは他のコンピュータの一つの<quote>ポート</quote>
に接続を開き、そしてそれら各自のポートの間に確立された接続を通じて
データを交換することができるのです。
</para>

<para>
<!--
 Getting back to the phone analogy, and stretching it a bit, think of calling 
 a large organization with a complex phone system. The organization has many 
 <quote>departments</quote>: sales, shipping, billing, receiving, customer
 service, R&amp;D, etc. Each department has it's own <quote>extension</quote>
 number. So the shipping department might be extension 21, the sales might be
 department 80 and so on. The main phone number is the IP Address, and the
 department's extension is the port in this analogy. The
 <quote>department's</quote> number is always the same when we call. And
 generally they can handle many simultaneous incoming calls.
 -->
  電話の喩えに戻りましょう。話を少し拡げて、
複雑な電話システムを持つ大きな組織を呼び出すことを考えましょう。
その組織はたくさんの<quote>部署</quote>を持っています。
セールス課、出荷課、請求課、入荷課、
カスタマーサービス課、研究開発課、などなど。
各課はそれぞれの<quote>内線</quote>番号を持っています。
つまり、出荷課は内線 21 番、セールス課は内線 80 番、などです。
この喩えでは、その代表番号が IP アドレスで、
各部署の内線番号がポート番号ということになります。
呼び出す時には、その<quote>部署</quote>の番号は常に同じです。
そして一般的には、同時にかかってくる多くの電話を扱うことが可能です。
</para>

<para>
<!--
 The data itself is contained in <quote>packets</quote>, which are small
 chunks of data, generally 1500 bytes or less each. Packets are used to
 control and organize the connection, as well as carry data. There are
 different types of packets. Some are specifically used for controlling the
 connection, and then some packets carry our data as their payload. If
 there is a lot of data, it will be broken up into multiple packets which is
 almost always how it works. The packets will be transmitted one at a time,
 and then <quote>re-assembled</quote> at the other end. One web page for
 instance, will take many packets to transmit &#045;&#045; maybe hundreds or even
 thousands. This all happens very quickly and transparently.
-->
  データ自身は<quote>パケット</quote>の中に含まれています。
パケットとはデータの小さなかたまりで、
一般的には 1500 バイト以下です。
パケットはデータを運ぶだけではなく、
接続を制御し組織化するために用いられます。
パケットには異なるタイプがあります。
あるものは接続を制御するために特別に用いられ、
またあるパケットはその積荷としてデータを運びます。
もしたくさんのデータがあれば、それは複数のパケットに分割されます。
実際ほとんどがこの場合です。そしてこれらのパケットは一時に一つずつが送られ、
到着したところで<quote>組み立て直し</quote>されるのです。
例えば、一つの web ページが送信されるときは
たくさんの、おそらく数百か数千ものパケットに分けられます。
これらの全てがあっという間に、見えないところで起こっているのです。
</para>

<para>
<!--
 We can see a typical connection between two computers in this one line
 excerpt from <command>netstat</command> output:
-->
  以下の <command>netstat</command> の出力からの一行の引用で、
二つのコンピュータの間の典型的な接続を見ることができます：
</para>

<para>
 <screen>

 tcp    30    0 169.254.179.139:1359    18.29.1.67:21      CLOSE_WAIT

 </screen>
</para>

<para>
<!--
 The interesting part is the IP addresses and ports in the fourth and fifth 
 columns. The port is the number just to the right of the colon. The left side
 of the colon is the IP address of each computer. The fourth column is the
 local address, or our end of the connection. In the example, 169.254.179.139
 is the IP address assigned by my ISP. It is connected to port 21
 (FTP) on 18.29.1.67, which is rpmfind.net. This is just after an FTP download
 from rpmfind.net. Note that while I am connected to their FTP server on their
 port 21, the port on my end that is used by my FTP client is 1359. This is a
 randomly assigned <quote>unprivileged</quote> port, used for my end of the
 two-way <quote>conversation</quote>. The data moves in both directions:
 me:port#1359 &lt;-&gt; them:port#21. The FTP protocol is actually a little
 more complicated than this, but we won't delve into the finer points here.
 The <literal>CLOSE_WAIT</literal> is the TCP state of the connection at this 
 particular point in time. Eventually the connection will close completely on
 both ends, and <application>netstat</application> will not show anything for
 this. 
 -->
  興味深い部分は四番目と五番目のコラムの IP アドレスとポート番号です。
ポート番号はコロンの右にある数字です。
コロンの左側が各コンピュータの IP アドレスになります。
四番目のコラムはローカルアドレス、つまり接続のこちら側の端です。
この場合、169.254.179.139 が、
プロバイダによって割り当てられた私の IP アドレスです。
それが 18.29.1.67 （これは rpmfind.net のアドレスです）上の
21 番ポート(FTP)に接続されています。
これは rpmfind.net からの FTP ダウンロードの直後のものです。
私が 21 番ポート上の FTP サーバと接続している間に、
私の FTP クライアントによって用いられている私側のポート番号は 1359 です。
この番号はランダムに<quote>特権のない</quote>ポートから割り当てられ、
双方向(2-way)<quote>対話</quote>のこちら側の端点として使われます。
データは両方向に移動します：
こちら側:1359 番ポート &lt;-&gt;あちら側:21番ポート、というように。
FTP プロトコルは実際はこれよりも少しばかり複雑ですが、
ここではより細かい説明に入るのはやめておきましょう。
<literal>CLOSE_WAIT</literal> はこの時点での接続の TCP 状態です。
これで結局、接続は両方の端で完全に閉じられ、
<application>netstat</application> は何も示さなくなります。
</para>

<para>
<!--
 The <quote>unprivileged</quote> port that is used for my end of the
 connection, is temporary and is not associated with a locally running server.
 It will be closed by the kernel when the connection is terminated. This is
 quite different than the ports that are kept open by <quote>listening</quote>
 servers, which are permanent and remain <quote>open</quote> even after a
 remote connection is terminated.
-->
  接続のこちら側で用いている<quote>非特権</quote>ポートは
一時的なもので、ローカルに走っているサーバには関係しません。
それは接続が終了したときに、カーネルによって閉じられます。
これは<quote>耳をすませている</quote>サーバによって
開き続けられているポートとは全く違うものです。
これらのポートは永続的なもので、
リモート接続が終了した後もずっと<quote>開いて</quote>います。
</para>

<para>
<!--
 So to summarize using the above example, we have client (me) connecting 
 to a server (rpmfind.net), and the connection is defined and controlled by
 the respective ports on either end. The data is transmitted and controlled by
 packets. The server is using a <quote>privileged</quote> port (i.e. a port
 below number 1024) which stays open listening for connections. The
 <quote>unprivileged</quote> port used on my end by my client application is
 temporary, is only opened for the duration of the connection, and only
 responds to the server's port at the other end of the connection. This type
 of port is not vulnerable to attacks or break-ins generally speaking. The
 server's port is vulnerable since it remains open. The administrator of the
 FTP server will need to take appropriate precautions that his server is
 secure. Other Internet connections, such as to web servers or mail servers,
 work similar to the above example, though the server ports are different. 
 SMTP mail servers use port 25, and web servers typically use port 80. 
 See the <link linkend="ports">Ports section</link> for other commonly used 
 ports and services.
-->
  さて、上の例を用いてまとめてみましょう。
我々はサーバ(rpmfind.net)にクライアント（私）を接続し、
その接続は両端のそれぞれのポートによって定義され制御されます。
データはパケットによって送られ制御されます。
サーバは<quote>特権</quote>ポート（つまり、1024 未満の番号のポート）
を用いて、ポートを開き接続のために耳をすませています。
私のクライアントによって用いられている私の側の端の
<quote>非特権</quote>ポートは一時的なもので、
接続が持続している間だけ開いていて、
接続の他端のサーバのポートへの応答だけを行います。
一般的に言って、このタイプのポートは攻撃や侵入の弱点にはなりません。
サーバのポートはそれが開き続けているがゆえに危険なのです。
FTP サーバの管理者はサーバが安全であるように、
適切な警戒をしている必要があります。
他のインターネット接続、例えば web サーバやメイルサーバのような接続は、
サーバのポート番号は違いますが、上の例と同じ様に働いています。
SMTP メイルサーバは 25 番ポートを用いますし、
web サーバは典型的には 80 番を使います。
他のよく用いられているポート番号やそのサーヴィスについては、
<link linkend="ports">ポート</link>の章を参照してください。
</para>

<para>
<!--
 One more point on ports: ports are only accessible if there is something 
 listening on that port. No one can force a port open if there is no service
 or daemon listening there, ready to handle incoming connection requests. 
 A closed port is a totally safe port. 
 -->
  ポートについてのポイントをもう一つ：
ポートはそこに耳をすませている何かがあるときに、
アクセス可能であるだけです。
もしそこで耳をすませているサーヴィスやデーモンがいて、
入ってくる接続要求に応えるよう待ち受けていないならば、
誰もポートを開くように強制することはできません。
閉じているポートはまったく安全なのです。
</para>

<para>
<!--
 And a final point on the distinction between clients and servers. The example
 above did not have a <command>telnet</command> or <command>ftp</command> 
 server in the <literal>LISTENER</literal> section in the
 <command>netstat</command> example above. In other words, no such servers 
 were running locally. You do not need to run a <command>telnet</command> or
 <command>ftp</command> server daemon in order to connect to
 <emphasis>somebody else's</emphasis> <command>telnet</command> or
 <command>ftp</command> server. These are only for providing these services
 to others that would be making connections to you. Which you don't really
 want to be doing in most cases. This in no way effects the ability to use 
 <command>telnet</command> and <command>ftp</command> client software.
-->
  クライアントとサーバの間の違いについての最後のポイント。
上の例では <command>netstat</command> の<literal>LISTENER</literal> 
の箇所に <command>telnet</command> や <command>ftp</command>
などの項目がありませんでした。
言い換えれば、このようなサーバはローカルに走っていないのです。
<emphasis>誰か他の</emphasis> <command>telnet</command> または
 <command>ftp</command> サーバに接続するために、
<command>telnet</command> や <command>ftp</command>
のサーバデーモンを走らせる必要はありません。
これらは接続しようとする他の人たちに対して、
サーヴィスを提供するためにあるのです。
ほとんどの場合、本当にそうしたい人は少ないでしょう。
サーバを走らせていなくても、
<command>telnet</command> と <command>ftp</command> 
のクライアントソフトウェアを使用するのに、
何の問題もないのです。
</para>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="ports">
<title><!--Common Ports-->ポート</title>

<para>
<!--
 A quick run down of some commonly seen and used ports, with the commonly 
 associated service name, and risk factor. All have <emphasis>some</emphasis>
 risk. It is just that some have historically had more exploits than others.
 That is how they are evaluated below, and not necessarily to be interpreted
 as whether any given service is safe or not. 
-->
  通常良く見られ、用いられているポート、
通常それに付随しているサーヴィス名とその危険について、
簡単に見てみましょう。
全てのポートは<emphasis>なんらかの</emphasis>危険をともなっています。
単に、その内のいくつかは、歴史的に他のものより
多くの攻撃を受けてきたというだけのことです。
以下でそれらがどのように評価されるかを見ますが、
必ずしもそれぞれのサーヴィスが安全かそうでないか
で解釈するとは限りません。
</para>

<para>
 <simplelist>
  <member>
<!--
   1-19, assorted protocols, many of which are antiquated, and probably 
   none of which are needed on a modern system. If you don't know what 
   any of these are, then you definitely don't need them.
   The <application>echo</application> service (port 7) should not be 
   confused with the common <command>ping</command> program. Leave all these
   off. 
-->
  1番から19番と、それらに結びついたプロトコルの多くは古臭くて、
おそらくそのどれも現代のシステムでは必要ないでしょう。
もしあなたがそれらが何なのかどれも知らないなら、確実に必要ありません。
7番ポートの <application>echo</application> サーヴィスを
通常の <command>ping</command> プログラムと混同してはいけません。
これら全てをオフのままにしておいてください。
  </member>
 </simplelist>
</para>


<para>
 <simplelist>
  <member>
<!--
    20 - FTP-DATA. <quote>Active</quote> FTP connections use two
    ports: 21 is the control port, and 20 is where the data comes through.
    Passive FTP does not use port 20 at all. Low risk, but see below.
-->
  20番ポート（FTP-DATA）。<quote>アクティブな</quote> FTP 接続は
二つのポートを使います：21 番ポートは制御用ポートで、
20 番ポートはデータが通るために用いられます。
受動的な FTP は全く 20 番ポートを用いません。
リスクは小さいですが、以下を見てください。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   21 - FTP server port, aka File Transfer Protocol. A well entrenched protocol
   for transferring files between systems. Very high risk, and maybe the number 
   one crack target.
-->
  21 番ポート（FTP サーバポート、すなわちファイル転送プロトコル）。
システム間でファイルを転送するための、非常に確立されたプロトコルです。
大変危険が大きく、ナンバーワンの攻撃ターゲットかもしれません。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   22 - SSH (Secure Shell), or sometimes PCAnywhere. Low to moderate 
   risk (yes there are exploits even against so called <quote>secure</quote>
   services).
-->
  22 番ポート（SSH, Secure Shell, または時に PCAnywhere プロトコル）。
危険は低いか中程度。（もちろん、いわゆる<quote>安全な</quote>
サーヴィスに対してさえ攻撃はあります）
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   23 - Telnet server. For LAN use only. Use <application>ssh</application>
   instead in non-secure environments. Moderate risk.
-->
  23 番ポート（Telnet サーバ）。LAN での使用のみに。
安全でない環境においては、
代わりに <application>ssh</application> を用いてください。危険は中程度。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   25 - SMTP, Simple Mail Transfer Protocol, or mail server port, used for 
   sending outgoing mail, and transferring mail from one place to another. 
   Moderate risk. This has had a bad history of exploits, but has improved 
   lately.
-->
  25 番（SMTP, Simple Mail Transfer Protocol, またはメイルサーバポート）
はメイルを外に送るためと、メイルをある場所から他のところへ
転送するために用いられます。危険は中程度。
これは長い間、酷い攻撃にさらされてきましたが、
最近改善されてきています。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    37 - Time service. This is the built-in
    <application>inetd</application> time service. Low risk. For LAN use 
    only.
-->
  37 番ポート（time サーヴィス）。これは組み込みの
<application>inetd</application> time サーヴィスです。
危険度は低。LAN での使用のみに。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    53 - DNS, or Domain Name Server port. Name servers listen on this port,
    and answer queries for resolving host names to IP addresses. High Risk.
-->
  53 番ポート（DNS, Domain Name Server ポート）。
ネームサーバはこのポートで耳をすませ、ホスト名を IP アドレスに
解決するための問い合わせに応えます。危険度は高。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    67 (UDP) - BOOTP, or DHCP, server port. Low risk. If using DHCP on your 
    LAN, this does not need to be exposed to the Internet.
-->
  67 番(UDP)ポート（BOOTP, DHCP のサーバポート）。危険度は低。
もし LAN で DHCP を用いるなら、
これをインターネットにさらす必要はありません。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    68 (UDP) - BOOTP, or DHCP, client port. Low risk.   
-->
  68 番(UDP)ポート（BOOTP または DHCP のクライアントポート）。危険度は低。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    69 - tftp, or Trivial File Transfer Protocol. Extremely insecure. LAN
    only, if really, really needed.   
-->
  69 番ポート（tfpt, Trivial File Transfer Protcol)。
極めて危険。本当に、本当に必要なら、LAN のみで使ってください。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    79 - Finger, used to provide information about the system, and logged 
    in users. Low risk as a crack target, but gives out way too much 
    information and should not be run.
-->
  79 番ポート（finger,
システムとログインしているユーザの情報を提供するために用いられる）。
クラックの標的としては危険度は低いが、あまりに多くの情報を流すため、
走らせるべきではない。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   80 - WWW or HTTP standard web server port. The most commonly used service 
   on the Internet. Low risk.
-->
  80 番ポート（WWW または HTTP 標準 web サーバポート）。
インターネットでもっとも通常に用いられるサーヴィス。危険度は低い。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    98 - Linuxconf web access administrative port. LAN only, if really needed
    at all.   
-->
  98 番ポート（Linuxconf web アクセス管理ポート）。
もし、本当に必要ならば、LAN のみで。
   </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   110 - POP3, aka Post Office Protocol, mail server port. POP mail is mail 
   that the user retrieves from a remote system. Low risk.
-->
  110 番ポート
（POP3 つまり Post Office Protocol, メイルサーバポート）。
POP メイルでは、ユーザがリモートシステムからメイルを取り出します。
危険度は低。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   111 - sunrpc (Sun Remote Procedure Call), or portmapper port. Used by NFS
   (Network File System), NIS (Network Information Service), and various related
   services. Sounds dangerous and is high risk. LAN use only. A favorite crack
   target. 
-->
  111 番ポート（sunrpc, Sun Remote Procudure Call, または portmapper ポート）。
NFS (Network File System), NIS (Network Information Service),
そして様々の関係サーヴィスに用いられます。
危険そうに聞こえますし、実際危険度は高です。
LAN の使用のみで。クラッカーたちのお気に入りの標的です。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   113 - identd, or auth, server port. Used, and sometimes required, by some
   older style services (like SMTP and IRC) to validate the connection.
   Probably not needed in most cases. Low risk, but could give an attacker
   too much information about your system.
-->
  113 番ポート（identd または auth サーバポート）。
古いスタイルのサーヴィス（SMTP や IRC のような）で、
接続を許可するために用いられることがあり、時に必要です。
おそらくほとんどの場合では必要ではなく、
危険度は低いですが、攻撃者にあまりに多くのシステム情報を
与えてしまう可能性があります。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
  119 &#045;&#045; nntp or news server port. Low risk.   
-->
  119 番ポート（nntp またはニュースサーバポート）。危険度は低。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   123 - Network Time Protocol for synchronizing with time servers where a 
   high degree of accuracy is required. Low risk, but probably not required 
   for most users. <application>rdate</application> makes an easier and more  
   secure way of updating the system clock. And then
   <application>inetd's</application> built in time service for synchronizing 
   LAN systems is another option.
-->
  123 番ポート（高い精度が必要な time サーバで同期をするための
Network Time プロトコル）。
危険度は低いですが、おそらくほとんどのユーザには必要でないでしょう。
システムクロックを更新するには、
<application>rdate</application> を用いるのがより簡単で安全です。
そして、LAN システムを同期するためには time サーヴィス
にビルドされた <application>inetd</application> を使うという
選択もあるでしょう。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   137-139 - NetBios (SMB) services. Mostly a Windows thing. Low risk on
   Linux, but LAN use only.  137 is a very commonly seen port attempt. A 
   rather obnoxious protocol from Redmond that generates a lot of 
   <quote>noise</quote>, much of which is harmless.
-->
  137 から139 番ポート（NetBios (SMB) サーヴィス）。
ほとんどの場合、Windows 関係です。
Linux では危険度は低いですが、LAN での使用のみにしてください。
137 番への攻撃は非常に良く見られます。
多くは無害ではありますがたくさんのノイズを生成することで、
非難されがちな Redmond 産プロトコルです。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    143 - IMAP, Interim Mail Access Protocol. Another mail retrieval protocol. 
    Low to moderate risk.
-->
  143 番ポート（IMAP, Interim Mail Access Protocol）。
これもまた、メイル受信プロトコル。危険度は低から中。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   161 - SNMP, Simple Network Management Protocol. More commonly used in
   routers and switches to monitor statistics and vital signs. Not needed 
   for most of us, and low risk.
-->
  161 番ポート（SNMP, Simple Network Management Protocol）。
ルータやスイッチが統計や重大なサインをモニタするために
もっとも普通に用いられます。ほとんどの場合には必要でなく、
危険度も低いです。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    177 - XDMCP, the X Display Management Control Protocol for remote connections 
    to X servers. Low risk, but LAN only is recommended.
-->
  177 番ポート（XDMCP, X サーバにリモート接続するための
X Display Management Control Protocol）。
危険度は低いですが、LAN での使用のみにすることをお勧めします。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   443 - HTTPS, a secure HTTP (WWW) protocol in fairly wide use. Low risk.   
-->
  443 番ポート（HTTPS, 広く用いられている安全な HTTP (WWW) プロトコル）。
危険度は低。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    465 - SMTP over SSL, secure mail server protocol. Low risk.   
-->
  465 番ポート（SSL 経由のSMTP (secure mail server protocol) ）。
危険度は低。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   512 (TCP) - exec is how it shows in <application>netstat</application>. 
   Actually the proper name is <command>rexec,</command> for Remote 
   Execution. Sounds dangerous, and is. High risk, LAN only if at all.
-->
  512 番(TCP)ポート（<application>netstat</application>では
 exec と表示されますが、実際、
その適切な呼び方はリモートでの実行のための
 <command>rexec</command> です。）
危険そうに聞こえるでしょうし、実際危険です。
危険度は高く、どんな場合でも LAN での使用のみにしてください。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   512 (UDP) - biff, a mail notification protocol. Low risk, LAN only.   
-->
  512 番(UDP)ポート（biff, メイル通知プロトコル）。
危険度は低。LAN のみで。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   513 - login, actually <command>rlogin</command>, aka Remote Login. No 
   relation to the standard <command>/bin/login</command> that we use 
   every time we log in. Sounds dangerous, and is. High risk, and LAN only if
   really needed.
-->
  513 番ポート（login, 実際 <command>rlogin</command> つまり
リモートログイン）。
いつもログインする時に用いている標準の <command>/bin/login</command> 
とは何の関係もありません。
これは危険そうに聞こえるでしょうし、実際危険です。
危険度は高、本当に必要なときにだけ LAN のみで用いてください。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   514 (TCP) - shell is the nickname, and how <application>netstat</application>
   shows it. Actually, <command>rsh</command> is the application for 
   <quote>Remote Shell</quote>. Like all the <quote>r</quote> commands, this
   is a throw back to kindler, gentler times. Very insecure, so high risk, and
   LAN only usage, if at all.
-->
  514 番(TCP)ポート（shell がその別名で、
<application>netstat</application> ではそう示されます。
実際、<command>rsh</command> が <quote>Remote Shell</quote> のための
アプリケーションです。）
すべての <quote>r</quote> コマンドたちと同様に、
古き良き、紳士的だった時代への先祖返りです。
まったく安全でなく、危険度は高。
どんな場合にも LAN での使用のみにしてください。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   514 (UDP) - syslog daemon port, only used for remote logging purposes. The 
   average user does not need this. Probably low risk, but definitely LAN 
   only if really required.
-->
  514 番(UDP)ポート（syslog デーモンのポートで、
リモートログイン目的のためにのみ用いられる）。
平均的なユーザには必要ありません。おそらく危険度は低いでしょうが、
本当に必要な時にでも絶対に LAN 使用で。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    515 - lp or print server port. High risk, and LAN only of course. Someone 
    on the other side of the world does not want to use your printer for it's
    intended purpose! 
-->
  515 番ポート（lp つまりプリントサーバポート）。
高リスク。もちろん LAN のみで。
世界の反対側にいる誰かはあなたのプリンタを本来の目的で使いはしません！
   </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   587 - MSA, or <quote>submission</quote>, the Mail Submission Agent 
   protocol. A new mail handling protocol supported by most MTA's (mail
   servers). Low risk.
-->
  587 番ポート（MSA, つまり<quote>投函</quote>、メイル投函エージェント
(Mail Submission Agent)プロトコル）。
ほとんどの MTA （メイルサーバ）
によってサポートされている新しいメイル運用プロトコル。
危険度は低。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   631 - the CUPS (print daemon) web management port. LAN only, low risk.   
-->
  631 番ポート（CUPS （プリントデーモン） web マネージメントポート）。
LAN のみの使用で。危険度は低。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   635 - mountd, part of NFS. LAN use only.
-->
  635 番ポート（mountd, NFS の一部）。LAN のみの使用で。
  </member>
 </simplelist>
</para>


<para>
 <simplelist>
  <member>
<!--
   901 - SWAT, Samba Web Administration Tool port. LAN only.
-->
  901 番ポート（SWAT, Samba Web 管理ツールポート）。
LAN のみの使用で。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   993 - IMAP over SSL, secure IMAP mail service. Very low risk.   
-->
  993 番ポート（SSL 経由のIMAP, 安全な IMAP メイルサーヴィス）。
危険度は非常に低い。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   995 - POP over SSL, secure POP mail service. Very low risk.   
-->
  995 番ポート（SSL 経由の POP, 安全な POP メイルサーヴィス）。
危険度は非常に低い。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   1024 - This is the first <quote>unprivileged</quote> port, which is 
   dynamically assigned by the kernel to whatever application requests 
   it. This can be almost anything. Ditto for ports just above this.
-->
  1024 番ポート（これは最初の<quote>非特権</quote>ポートで、
要求があったアプリケーションに対しカーネルによって動的に割り当てられる）。
これはほとんど何にでもなれます。上のポートらの記述に同じ。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   1080 - Socks Proxy server. A favorite crack target. 
-->
  1080 番ポート（Socks Proxy サーバ）。クラッカーのお気に入りの標的です。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   1243 - SubSeven Trojan. Windows only problem.
-->
  1243 番ポート（SubSeven Trojan）。Windows のみの問題です。
  </member>
 </simplelist>
</para>


<para>
 <simplelist>
  <member>
<!--
   1433 - MS SQL server port. A sometimes target. N/A on Linux.   
-->
  1433 番ポート（MS SQL サーバポート）。
時に標的になります。Linux には適用されません. 
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    2049 - nfsd, Network File Service Daemon port. High risk, and LAN 
    usage only is recommended.
-->
  2049 番ポート（nfsd, つまり Network File Service Daemon ポート）。
危険度は高。LAN だけで使用することを勧めます。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   3128 - Squid proxy server port. Low risk, but for most should be
   LAN only.   
-->
  3128 番ポート（squid proxy サーバポート）。
危険度は低いですが、ほとんどの場合は LAN での使用のみにすべきです。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   3306 - MySQL server port. Low risk, but for most should be
   LAN only.   
-->
  3306 番ポート（MySQL サーバポート）危険度は低いですが、
ほとんどの場合 LAN での使用のみにすべきです。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   5432 - PostgreSQL server port. LAN only, relatively low risk.   
-->
  5432 番ポート（PostgreSQL サーバポート）LAN のみで。比較的低リスク。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   5631 (TCP), 5632 (UDP) - PCAnywhere ports. Windows only. PCAnywhere 
   can be quite <quote>noisy</quote>, and broadcast wide address ranges.
-->
  5631 番(TCP), 5632 番(UDP)ポート（PCAnywhere ポート）。
Windows のみ。PCAnywhere は大変<quote>ノイズの多い</quote>
ものになりえますし、広い範囲のアドレスにブロードキャストします。
  </member>
 </simplelist>
</para>


<para>
 <simplelist>
  <member>
<!--
   6000 - X11 TCP port for remote connections. Low to moderate risk, but 
   again, this should be LAN only. Actually, this can include ports 
   6000-6009 since X can support multiple displays and each display would 
   have its own port. <application>ssh's</application> X11Forwarding will 
   start using ports at 6010.
-->
  6000 番ポート（リモート接続のための X11 TCP ポート）。
危険度は低から中程度ですが、やはり、LAN での使用のみにすべきです。
実際、X は複数のディスプレイと各ディスプレイ毎に自身のポートを
持つことをサポートしているので、
これは 6000 番から 6009 番のポートも含む可能性があります。
<application>ssh</application> の X11 フォワーディングは
6010 番からポートを使い始めます。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   6346 - gnutella.    
-->
  6346 番ポート（gnutella）。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   6667 - ircd, Internet Relay Chat Daemon.
-->
  6667 番ポート（ircd, つまり Internet Relay Chat Daemon）。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   6699 - napster.    
-->
  6699 番ポート（napster）。
  </member>
 </simplelist>
</para>


<para>
 <simplelist>
  <member>
<!--
   7100-7101 - Some font servers use these ports. Low risk, but LAN only.   
-->
  7100-7101 番ポート（フォントサーバにこれらのポートを使うものがあります）。
危険度は低いですが、LAN での使用のみで。
  </member>
 </simplelist>
</para>
<!--
<para>
 <simplelist>
  <member>
   7070 (UDP) - Realplayer.   
  </member>
 </simplelist>
</para>
-->
<para>
 <simplelist>
  <member>
<!--
    8000 and 8080 - common web cache and proxy server ports. LAN only.
-->
  8000 番と 8080 番ポート（通常 web キャッシュとプロキシのサーバポート）。
LAN のみ。 
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
   10000 - webmin, a web based system administration utility. Low risk at this
   point.   
-->
  10000 番ポート（webmin, つまり web ベースのシステム管理ユーティリティ）。
この点では危険度は低。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    27374 - SubSeven, a commonly probed for Windows only Trojan. Also, 1243.
-->
  27374 番ポート（SubSeven, つまり Windows のみの Trojan で
使用されます）。1243 番ポートもそうです。
  </member>
 </simplelist>
</para>

<para>
 <simplelist>
  <member>
<!--
    31337 - Back Orifice, another commonly probed for Windows only Trojan.
-->
  31337 番ポート（Back Orifice, つまり、また別の良く見られる
Windows のみの Trojan で使われます）。
  </member>
 </simplelist>
</para>

<para>
<!--
 More services and corresponding port numbers can be found in 
 <filename>/etc/services</filename>. Also, the <quote>official</quote> 
 list is <ulink url="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</ulink>.
-->
  さらに多くのサーヴィスと対応するポート番号は
 <filename>/etc/services</filename> で見ることができます。
また、<quote>公式の</quote>リストは
 <ulink url="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</ulink> にあります。
</para>

<para>
<!--
 A great analysis of what probes to these and other ports might mean 
 from Robert Graham: <ulink url="http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html">http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html</ulink>. A very good reference.
-->
  これらと他のポートへのプローブが何を意味しているかについては、
 Robert Graham による素晴らしい解析が以下にあります：
<ulink url="http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html">http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html</ulink>
これは非常に良い文献です。
</para>

<para>
<!--
 Another point here, these are the <emphasis>standard</emphasis> port
 designations. There is no law that says any service has to run on a 
 specific port. Usually they do, but certainly they don't always have to.
-->
  ここでのもう一つのポイントは、
これらが<emphasis>標準の</emphasis>ポート指定だということです。
どのサーヴィスも特定のポートで走っていると言える法則はありません。
通常は標準ポートを使っていますが、常にそうであるとは限りません。
</para>

<para>
<!--
 Just a reminder that when you see these types of ports in your firewall logs,
 it is not anything to go off the deep end about. Not if you have followed
 Steps 1-3 above, and verified your firewall works. You are fairly safe. Much
 of this traffic may be <quote>stray bullets</quote> too &#045;&#045; Internet
 background noise, misconfigured clients or routers, noisy Windows stuff, etc.
-->
   自分のファイアーウォールのログに
これらのタイプのポートが見つかったからと言って、
突然大慌てする必要はないということを覚えておいてください。
前述のステップ１から３に従って、
ファイアーウォールが正しく働いていることを確認していれば、
まずは安全です。
この通信の多くは<quote>流れ弾</quote>かも知れません、
つまりインターネットの背景ノイズか、どこかのクライアントかルータの設定ミス、
ノイズの多い Windows 関連ソフトから来たものかも知れないのです。

</para>

</sect2>

<!--  ~  End section  ~  -->


<!--  ~~~~~       New section      ~~~~~     -->

<sect2 id="netstat">
<title><!--Netstat Tutorial-->Netstat チュートリアル</title>


<!--   ~~~~~       New section      ~~~~~     -->
<sect3>
<title><!--Overview-->概観</title>

<para>
<!--
 <command>netstat</command> is a very useful utility for viewing 
 the current state of your network status &#045;&#045; what servers are listening for
 incoming connections, what interfaces they listen on, who is connected to us,
 who we are connect to, and so on. Take a look at the man page for some of the
 many command line options. We'll just use a relative few options here.
-->
  <command>netstat</command> はネットワークの現在の状態を
見るのに非常に便利なユーティリティです。
つまり、どんなサーバが入ってくる接続に耳をすませているか、
どのインターフェースに耳をすませているか、
こちらに接続しているのは誰か、こちらから接続しているのは誰か、などです。
たくさんあるコマンドラインオプションのいくつかについては
man ページに目を通してください。
ここでは、比較的少数のオプションだけを説明します。
</para>

<para>
<!--
 As an example, let's check all currently listening servers and active
 connections for both TCP and UDP on our hypothetical host,
 bigcat. bigcat is a home desktop installation, with a DSL
 Internet connection in this example. bigcat has two ethernet cards: one for
 the external connection to the ISP, and one for a small LAN with an address
 of 192.168.1.1. 
-->
  一例として、仮想的ホスト big cat 上の TCP と UDP 両方について、
耳をすませているサーバとアクティブな接続の全てをチェックしてみましょう。
big cat は自宅のデスクトップマシンで、
この例では DSL インターネット接続しています。
bigcat は二枚のイーサネットカードを挿していて、
一つはプロバイダへの外部接続に、
一つはアドレス 192.168.1.1 の小さな LAN に用いられています。
</para>

<para>
 <screen>
   
$ netstat -tua
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:printer               *:*                     LISTEN     
tcp        0      0 bigcat:8000             *:*                     LISTEN     
tcp        0      0 *:time                  *:*                     LISTEN     
tcp        0      0 *:x11                   *:*                     LISTEN
tcp        0      0 *:http                  *:*                     LISTEN     
tcp        0      0 bigcat:domain           *:*                     LISTEN     
tcp        0      0 bigcat:domain           *:*                     LISTEN     
tcp        0      0 *:ssh                   *:*                     LISTEN     
tcp        0      0 *:631                   *:*                     LISTEN     
tcp        0      0 *:smtp                  *:*                     LISTEN     
tcp        0      1 dsl-78-199-139.s:1174   64.152.100.93:nntp      SYN_SENT   
tcp        0      1 dsl-78-199-139.s:1175   64.152.100.93:nntp      SYN_SENT   
tcp        0      1 dsl-78-199-139.s:1173   64.152.100.93:nntp      SYN_SENT   
tcp        0      0 dsl-78-199-139.s:1172   207.153.203.114:http    ESTABLISHED
tcp        1      0 dsl-78-199-139.s:1199   www.xodiax.com:http     CLOSE_WAIT 
tcp        0      0 dsl-78-199-139.sd:http  63.236.92.144:34197     TIME_WAIT
tcp      400      0 bigcat:1152             bigcat:8000             CLOSE_WAIT 
tcp     6648      0 bigcat:1162             bigcat:8000             CLOSE_WAIT 
tcp      553      0 bigcat:1164             bigcat:8000             CLOSE_WAIT 
udp        0      0 *:32768                 *:*                                
udp        0      0 bigcat:domain           *:*                                
udp        0      0 bigcat:domain           *:*                                
udp        0      0 *:631                   *:*                               

 </screen>
</para>

<para>
<!--
 This output probably looks very different from what you get on your own 
 system. Notice the distinction between <quote>Local Address</quote> and
 <quote>Foreign Address</quote>, and how each includes a corresponding port
 number (or service name if available) after the colon. <quote>Local
 Address</quote> is our end of the connection. The first group with
 <literal>LISTEN</literal> in the far right hand column are services that are
 running on this system. These are servers that are running in the background 
 on bigcat, and <quote>listen</quote> for incoming connections. So they 
 have a port opened, and this is where they <quote>listen</quote>. These
 connections might come from the local system (i.e. bigcat itself), or remote
 systems. This is very important information to have! The others just below
 this are connections that have been established from this system to other
 systems. The respective connections are in varying states as indicated by the
 key words in the last column. Those with no key word in the last column at
 the end are servers responding to UDP connections. UDP is a different
 protocol from TCP altogether, but is used for some types of low priority
 network traffic.
-->
  おそらくこの出力はあなた自身のシステムについてのものと
ずいぶんと違った見かけをしているかもしれません。
<quote>Local Address</quote> と <quote>Foreign Address</quote>
の欄の間の記述の違いと、
それぞれが対応するポート番号（可能な時はそのサーヴィス名）
がコロンの後にどのように書かれているかに注意してください。
<quote>Local Address</quote> は接続の我々の側の端点です。
一番右の欄に <literal>LISTEN</literal> と書かれている最初のグループは
このシステムでいま走っているサーヴィスです。
これらは bigcat の背後で走っていて、入ってくる接続に
<quote>耳をすませている</quote>サーバです。
ですから、それらは開いたポートを持ち、
そこで<quote>耳をすませて</quote>います。
これらの接続はローカルシステムから（つまり bigcat 自身から）
入ってきたのかも知れませんし、
またはリモートシステムからのものかもしれません。
これは非常に重要な情報です！
この下の他のものはこのシステムから他のシステムへ確立されている接続です。
それぞれの接続は最後の欄にキーワードで示されているように、
様々な状態にあります。最後にある最後の欄にキーワードが示されていない
ものは UDP 接続に対応するサーバたちです。
UDP は TCP とは全く異なるプロトコルですが、
ある種のプライオリティの低いネットワーク通信で用いられています。
</para>

<para>
<!--
 Now, the same thing with the <quote>-n</quote> flag to suppress converting to
 <quote>names</quote> so we can actually see the port numbers:
-->
  ここで、<quote>サーヴィス名</quote>への変換をさせないために、
<quote>-n</quote> フラッグをつけて同じことをしてみると、
実際に以下のようにポート番号を見ることができます：
</para>

<para>
 <screen>

$ netstat -taun
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address      State
tcp        0      0 0.0.0.0:515             0.0.0.0:*            LISTEN     
tcp        0      0 127.0.0.1:8000          0.0.0.0:*            LISTEN     
tcp        0      0 0.0.0.0:37              0.0.0.0:*            LISTEN     
tcp        0      0 0.0.0.0:6000            0.0.0.0:*            LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*            LISTEN     
tcp        0      0 192.168.1.1:53          0.0.0.0:*            LISTEN     
tcp        0      0 127.0.0.1:53            0.0.0.0:*            LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*            LISTEN     
tcp        0      0 0.0.0.0:631             0.0.0.0:*            LISTEN     
tcp        0      0 0.0.0.0:25              0.0.0.0:*            LISTEN     
tcp        0      1 169.254.179.139:1174    64.152.100.93:119    SYN_SENT   
tcp        0      1 169.254.179.139:1175    64.152.100.93:119    SYN_SENT   
tcp        0      1 169.254.179.139:1173    64.152.100.93:119    SYN_SENT   
tcp        0      0 169.254.179.139:1172    207.153.203.114:80   ESTABLISHED
tcp        1      0 169.254.179.139:1199    216.26.129.136:80    CLOSE_WAIT 
tcp        0      0 169.254.179.139:80      63.236.92.144:34197  TIME_WAIT 
tcp      400      0 127.0.0.1:1152          127.0.0.1:8000       CLOSE_WAIT 
tcp     6648      0 127.0.0.1:1162          127.0.0.1:8000       CLOSE_WAIT 
tcp      553      0 127.0.0.1:1164          127.0.0.1:8000       CLOSE_WAIT 
udp        0      0 0.0.0.0:32768           0.0.0.0:*                    
udp        0      0 192.168.1.1:53          0.0.0.0:*                      
udp        0      0 127.0.0.1:53            0.0.0.0:*                     
udp        0      0 0.0.0.0:631             0.0.0.0:*          
   
 </screen>
</para>

<para>
<!--
 Let's look at the first few lines of this in detail. On line one, 
-->
  この最初の数行を詳しく見て見ましょう。一行目は、
</para>

<para>
 <screen>

 tcp        0      0 0.0.0.0:515            0.0.0.0:*          LISTEN     

 </screen>
</para>

<para>
<!--
 <quote>Local Address</quote> is <literal>0.0.0.0</literal>, meaning
 <quote>all</quote> interfaces that are available. The local port is 515, or the
 standard print server port, usually owned by the lpd daemon. You can find a
 listing of common service names and corresponding ports in the file 
 <filename>/etc/services</filename>. 
-->
  <quote>Local Address</quote> は <literal>0.0.0.0</literal> で、
使用可能な全てのインターフェースを意味しています。
ローカルポート番号は 515 番、つまり標準のプリントサーバポートで、
通常は lpd デーモンによって使われています。
通常のサーヴィス名と対応するポートは <filename>/etc/services</filename>
 ファイルで見ることができます。
</para>

<para>
<!--
 The fact that it is listening on all interfaces is significant. In this case,
 that would be lo (localhost), eth0, and eth1. Printer connections could
 conceivably be made over any of these interfaces. Should a user on this system
 bring up a PPP connection, then the print daemon would be listening on that
 interface (ppp0) as well. The <quote>Foreign Address</quote> is also
 <literal>0.0.0.0</literal>, meaning from <quote>anywhere</quote>.
-->
  これが全てのインターフェースの上で耳をすませているという事実は重大です。
この場合では、それは lo (localhost ローカルホスト）、
eth0 と eth1 です。プリンタ接続はこれらのインターフェースの
どれを通して使用することもできます。
このシステムのユーザが PPP で接続するのなら、
プリントデーモンはそのインターフェース (ppp0) で耳をすませる
ことになるでしょう。
<quote>Foreign Address</quote> もまた <literal>0.0.0.0</literal>
で、<quote>どこからでも</quote>を意味します。
</para>

<para>
<!--
 It is also worth noting here, that even though this server is telling the
 kernel to listen on all interfaces, the <command>netstat</command> output
 does not reflect whether there may be a firewall in place that may be
 filtering incoming connections. We just can't tell that at this point.
 Obviously, for certain servers, this is very desirable. Nobody outside your
 own LAN has any reason whatsoever to connect to your print server port for
 instance.
-->
  また、
このサーバは全てのインターフェース上で耳をすませるように、
カーネルに依頼してはいますが、
入ってくる接続をフィルタリングするファイアーウォールが
働いているかどうかについては、
<command>netstat</command> 出力には何も表示されていないという事実は、
ここで注意しておく価値があるでしょう。
この点においては、
それについて単に何も言うことができないということです。
明らかに、ある種のサーバにとっては、
接続をフィルタリングすることは非常に望ましいことです。
例えば、LAN の外にいる誰も、
あなたのプリントサーバポートに接続しようとする
理由は全くないでしょう。
</para>

<para>
<!--
 Line two is a little different:
-->
  二行目は少し違います：
</para>

<para>
 <screen>

 tcp        0      0 127.0.0.1:8000         0.0.0.0:*          LISTEN     

 </screen>
</para>

<para>
<!--
 Notice the <quote>Local Address</quote> this time is localhost's address 
 of <literal>127.0.0.1</literal>. This is very significant as only connections 
 local to this machine will be accepted. So only bigcat can connect to
 bigcat's TCP port 8000. The security implications should be obvious. Not all 
 servers have configuration options that allow this kind of restriction, but 
 it is a very useful feature for those that do. Port 8000 in this example, 
 is owned by the web proxy <application>Junkbuster</application>.
-->
  今度は <quote>Local Address</quote> はローカルホストのアドレス
 <literal>127.0.0.1</literal> になっています。
これはこのマシンへのローカル接続だけが許可されているということで、
大変重要な事実です。
つまり、bigcat だけが bigcat の 8000 番（TCP) ポートに
接続することができます。
セキュリティ上の意味は明白でしょう。
全てのサーバがこの種の制限を可能にする設定オプションを持っている
わけではありません。しかし、
それを持つものについては非常に有効な機能です。
この例での 8000 番ポートは web プロキシ
 <application>Junkbuster</application> が使っています。
</para>

<para>
<!--
 With the next three entries, we are back to listening on all available 
 interfaces:
-->
  次の三つのエントリでは、また全ての可能なインターフェースの上で
耳をすませるように戻っています：
</para>

<para>
 <screen>

 tcp        0      0 0.0.0.0:37             0.0.0.0:*           LISTEN     
 tcp        0      0 0.0.0.0:6000           0.0.0.0:*           LISTEN
 tcp        0      0 0.0.0.0:80             0.0.0.0:*           LISTEN     

 </screen>
</para>

<para>
<!--
 Looking at <filename>/etc/services</fileName>, we can tell that port 37 
 is a <quote>time</quote> service, which is a time server. 
 6000 is <application>X11</application>, and 80 is the standard port for HTTP
 servers like <application>Apache</application>. There is nothing really
 unusual here as these are all readily available services on Linux.
-->
  <filename>/etc/services</filename> を見ると、
37 番ポートは <quote>time</quote> サーヴィスで、
つまりこのサーバは time サーバであることがわかります。
6000 番ポートは <application>X11</application> で、
80 番ポートは <application>Apache</application> のような
HTTP サーバの標準ポートです。
ここでは実際普通でないことは何もなく、
これらは全て Linux ですぐに使用可能になっているサーヴィスです。
</para>

<para>
<!--
 The first two above are definitely not the kind of services you'd want just
 anyone to connect to. These should be firewalled so that all outside
 connections are refused. Again, we can't tell from this output whether any
 firewall is in place, much less how effectively implemented it may be.
-->
  上の最初の二つは絶対に、
他の誰かに接続してもらいたい種類のサーヴィスではありません。
これらは外部からの接続を全て拒否するように
ファイアーウォールで保護されるべきです。
上と同様に、この出力からは、
何かのファイアーウォールが働いているかどうか、
ましてやそれがいかに効果的に設定されているかどうかについては、
何も言えません。
</para>

<para>
<!--
 The web server on port 80 is not a huge security risk by itself. HTTP is a
 protocol that is often open to all comers. For instance, if we wanted to host
 our own home page, <application>Apache</application> can certainly do this
 for us. It is also possible to firewall this off, so that it is for use only
 to our LAN clients as part of an Intranet. Obviously too, if you do not have
 a good justification for running a web server, then it should be disabled 
 completely.
 -->
  80 番ポートの web サーバ自身は
大きなセキュリティ上のリスクではありません。 
HTTP はしばしば全ての訪問者に開かれているプロトコルです。
例えば、自分自身のホームページのホストになりたいならば、
<application>Apache</application> などを使うことになるでしょう。
これをファイアーウォールでオフにして、
イントラネットの一部として我々の LAN クライアントだけが
使えるように設定することも可能です。
また、
web サーバを走らせることを正当化する理由が何もないなら、
もちろん完全に使用不可能にしておくべきでしょう。
</para>

<para>
<!--
 The next two lines are interesting:
-->
  次の二つの行は興味深いものです：
</para>

<para>
 <screen>

 tcp        0      0 192.168.1.1:53         0.0.0.0:*           LISTEN     
 tcp        0      0 127.0.0.1:53           0.0.0.0:*           LISTEN     

 </screen>
</para>

<para>
<!--
 Again notice the <quote>Local Address</quote> is not <literal>0.0.0.0</literal>. 
 This is good! The port this time is 53, or the DNS port used by nameserver
 daemons like <command>named.</command> But we see the nameserver
 daemon is only listening on the lo interface (localhost), and the interface
 that connects bigcat to the LAN. So the kernel only allows connections from
 localhost, and the LAN. There will be no port 53 available to outside
 connections at all. This is a good example of how individual applications 
 can sometimes be securely configured. In this case, we are probably looking 
 at a caching DNS server since a real nameserver that is responsible for 
 handling DNS queries would have to have port 53 open to the world. This 
 is a security risk and requires special handling.
 -->
  再び、<quote>Local Address</quote> が <literal>0.0.0.0</literal>
ではないことに注意しましょう。これは結構なことです！
今度のポート番号は 53 番、つまり <command>named</command> のような
ネイムサーバによって用いられる DNS ポートです。
しかし、このネイムサーバデーモンは lo インターフェース（localhost)、
bigcat を LAN に接続しているインターフェースで
耳をすませているだけだということがわかります。
ですから、カーネルは localhost から、つまり LAN からの接続のみを
許可しています。外部から可能な接続は 53 番ポートには全くありません。
これはいかに個別のアプリケーションを安全に設定できるかを示す
良い例です。この場合では、DNS 要求を扱うための対応をする本当の
ネイムサーバなら世界に向けて 53 番ポートを開く必要があるでしょうから、
ここで見ているものはおそらくキャッシング DNS サーバなのです。
外部にまで開くなら、
これは一つのセキュリティ上のリスクで、特別な対応が必要です。
</para>

<para>
<!--
 The last three <literal>LISTENER</literal> entries:
-->
  最後の三つは <literal>LISTENER</literal>、
つまりポートで耳をすませているエントリです：
</para>

<para>
 <screen>

 tcp        0      0 0.0.0.0:22             0.0.0.0:*           LISTEN     
 tcp        0      0 0.0.0.0:631            0.0.0.0:*           LISTEN     
 tcp        0      0 0.0.0.0:25             0.0.0.0:*           LISTEN     

 </screen>
</para>

<para>
<!--
 These are back to listening on all available interfaces. Port 22 is
 <application>sshd</application>, the Secure Shell server daemon. This is a good
 sign! Notice that the service for port 631 does not have a service name if we
 look at the output in the first example. This might be a clue that something
 unusual is going on here. (See the next section for the answer to this
 riddle.) And lastly, port 25, the standard port for the SMTP mail daemon.
 Most Linux installations probably will have an SMTP daemon running, so this
 is not necessarily unusual. But is it necessary?
-->
  これらはまた全ての可能なインターフェース上で耳をすませています。
22 番ポートは <application>sshd</application> つまり、
Secure Shell サーバデーモンです。これは良い兆候です！
最初の例の出力を見るに、631 番ポートのサーヴィスは名前を持っていません。
これはここで何か普通でないことが起きている証拠かもしれません。
（この謎についての答えは次の章を見てください。）
そして最後に、25 番ポート、つまり SMTP メイルデーモンの標準ポートです。
ほとんどの Linux インストールではおそらく
 SMTP デーモンが走っているでしょうから、
これは必ずしも異常なことではありません。
でも、本当に SMTP デーモンが必要でしょうか？
</para>

<para>
<!--
 The next grouping is established connections. For our purposes the state of 
 the connection as indicated by the last column is not so important. This is 
 well explained in the man page.
-->
  次のグループは確立された接続です。我々の目的には、
最後のコラムで示されている接続の状態はそれほど重要ではありません。
これは man ページで詳しく説明されています。
</para>

<para>
 <screen>

 tcp        0      1 169.254.179.139:1174    64.152.100.93:119    SYN_SENT   
 tcp        0      1 169.254.179.139:1175    64.152.100.93:119    SYN_SENT    
 tcp        0      1 169.254.179.139:1173    64.152.100.93:119    SYN_SENT   
 tcp        0      0 169.254.179.139:1172    207.153.203.114:80   ESTABLISHED
 tcp        1      0 169.254.179.139:1199    216.26.129.136:80    CLOSE_WAIT 
 tcp        0      0 169.254.179.139:80      63.236.92.144:34197  TIME_WAIT 
 tcp      400      0 127.0.0.1:1152          127.0.0.1:8000       CLOSE_WAIT 
 tcp     6648      0 127.0.0.1:1162          127.0.0.1:8000       CLOSE_WAIT 
 tcp      553      0 127.0.0.1:1164          127.0.0.1:8000       CLOSE_WAIT 

 </screen>
</para>

<para>
<!--
 There are nine total connections here. The first three is our external
 interface connecting to a remote host on their port 119, the standard NNTP (News) 
 port. There are three connections here to the same news server. Apparently 
 the application is multi-threaded, as it is trying to open multiple
 connections to the news server. The next two entries are connections to a
 remote web server as indicated by the port 80 after the colon in the fifth
 column. Probably a pretty common looking entry for most of us. But the one
 just after is reversed and has the port 80 in the fourth column, so this is
 someone that has connected to bigcat's web server via its external,
 Internet-side interface. The last three entries are all connections from
 localhost to localhost. So we are connecting to ourselves here. Remembering
 from above that port 8000 is bigcat's web proxy, this is a web browser that
 is connected to the locally running proxy. The proxy then will open an
 external connection of its own, which probably is what is going on with lines
 four and five.
-->
  ここには全部で 9 つの接続があります。
最初の三つは 119 番ポート（標準の NNTP ニュースポート）
でリモートのホストへ接続している外部インターフェースです。
ここでは同じニュースサーバへの三つの接続があります。
これは同じ一つのニュースサーバに多重の接続を開こうとしていますから、
明らかに、このアプリケーションはマルチスレッド化されています。
次の二つのエントリは 5 番目のコラムにコロンの後に 80 番ポートと
示されているように、リモートの web サーバに接続しています。
おそらくほとんどの場合には非常に良く見られるものでしょう。
しかし、そのすぐ一つ後の行ではこの逆に、
4 番目のコラムに 80 番ポートがあります。
つまりこれは誰かが、その外部、インターネット側のインターフェースを
通して bigcat の web サーバに接続しているのです。
最後の三つのエントリはすべてローカルホストからローカルホストへの接続です。
つまり、自分自身に接続しているのです。
8000 番ポートが bigcat の web プロキシであったことを思い返せば分るように、
これはローカルに走っているプロキシに接続している web ブラウザです。
プロキシはそれ自身の外部接続を開きますが、
その接続がおそらく 4 行目と 5 行目で起こっていることでしょう。
</para>

<para>
<!--
 Since we gave <command>netstat</command> both the <literal>-t</literal> and 
 <literal>-u</literal> options, we are getting both the TCP and UDP listening 
 servers. The last few lines are the UDP ones:
-->
  <command>netstat</command> に <literal>-t</literal> と
 <literal>-u</literal> オプションの両方をつけたので、
TCP と UDP の両方の耳をすませているサーバが表示されています。
最後の数行は UDP のものです：
</para>

<para>
 <screen>

 udp        0      0 0.0.0.0:32768          0.0.0.0:*                    
 udp        0      0 192.168.1.1:53         0.0.0.0:*                      
 udp        0      0 127.0.0.1:53           0.0.0.0:*                     
 udp        0      0 0.0.0.0:631            0.0.0.0:*          

 </screen>
</para>

<para>
<!--
 The last three entries have ports that are familiar from the above
 discussion. These are servers that are listening for both TCP and UDP 
 connections. Same servers in this case, just using two different protocols.
 The first one on local port 32768 is new, and does not have a service name
 available to it in <filename>/etc/services</filename>. So at first glance
 this should be suspicious and pique our curiosity. See the next section for
 the explanation.
-->
  最後の三つのエントリは上の議論で見慣れたポートを持っています。
これらのサーバは TCP と UDP の両方の接続に耳をすませているのでした。
この場合は同じサーバが、異なる二つのプロトコルを使っているのです。
ローカルポート 32768 番を使っている最初の一つは初顔ですが、
<filename>/etc/services</filename> の中にはサーヴィス名はありません。
ですから、一見は、これは疑うべきもので、我々の好奇心を刺激します。
この説明については次の章を見てください。
</para>

<para>
<!--
 Can we draw any conclusions from this hypothetical situation? For 
 the most part, these look to be pretty normal looking network services and 
 connections for Linux. There does not seem to be an unduly high number of
 servers running here, but that by itself does not mean much since we don't
 know if all these servers are really required or not. We know that
 <command>netstat</command> can not tell us if any of these are effectively
 firewalled, so there is no way to say how secure all this might be. We also
 don't really know if all the listening services are really required by the
 owner here. That is something that varies widely from installation to
 installation. Does bigcat even have a printer attached for instance?
 Presumably it does, or this is a completely unnecessary risk.
-->
  この仮想的な状況からどんな結論が得られるでしょうか？
ほとんどの場合について、
これらは Linux において非常にノーマルに見えるネットワークサーヴィス
と接続です。
ここでは過度に多くのサーバが走っているようには見えませんが、
これら全てのサーバが本当に必要なのかそうでないか知らなければ、
それには大した意味はありません。
これらのどれも効果的にファイアーウォールで守られているかどうか、
<command>netstat</command> は何も教えてくれないのでした。
ですから、これら全部がどれくらい安全なのか、
何も言うことはできません。またここでは、
すべての耳をすませているサーバたちが
その持ち主によって本当に必要とされているのかどうか、
まったくわかりません。
それはインストールの状況によって幅広く変わってしまうことだからです。
例えば、bigcat にはプリンタを接続してあるのでしょうか？
おそらくそうでしょう、でなければ、これは全く必要のないリスクです。
</para>

</sect3>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect3 id="pid">
<title><!--Port and Process Owners-->ポートとプロセス所有者</title>

<para>
<!--
 We've learned a lot about what is going on with bigcat's networking from 
 the above section. But suppose we see something we don't recognize and 
 want to know what started that particular service? Or we want to stop a
 particular server and it is not obvious from the above output?
-->
  上の章では bigcat のネットワークで何が起こっているかについて
たくさんのことを学びました。しかし、そこでは学んだことでは、
何がその特定のサーヴィスをスタートさせたのか分りません。
今度はそれを調べましょう。
つまり、我々は特定のサーヴィスを停止したいと思っているのですが、
それは上の出力からは明らかなことではないのです。
</para>

<para>
<!--
 The <literal>-p</literal> option should give us the process's PID and the 
 program name that started the process in the last column. Let's look at the
 TCP servers again (with first three columns cropped for spacing). We'll have
 to run this as root to get all the available information:
-->
  <literal>-p</literal> オプションを使うと、最後のコラムに、
そのプロセスの PID とそのプロセスを開始したプログラム名が
表示されます。再び TCP サーヴィスのリストを見てみましょう
（今度はスペースの関係上、最初の三つのコラムは省略してあります）。
利用できる情報を全て得るために、
root としてこれを実行する必要があります。
</para>

<para>
 <screen>

# netstat -tap
Active Internet connections (servers and established)
  Local Address           Foreign Address      State       PID/Program name
  *:printer               *:*                  LISTEN       988/inetd
  bigcat:8000             *:*                  LISTEN       1064/junkbuster
  *:time                  *:*                  LISTEN       988/inetd
  *:x11                   *:*                  LISTEN       1462/X
  *:http                  *:*                  LISTEN       1078/httpd
  bigcat:domain           *:*                  LISTEN       956/named
  bigcat:domain           *:*                  LISTEN       956/named
  *:ssh                   *:*                  LISTEN       972/sshd
  *:631                   *:*                  LISTEN       1315/cupsd
  *:smtp                  *:*                  LISTEN       1051/master

 </screen>
</para>

<para>
<!--
 Some of these we already know about. But we see now that the printer daemon
 on port 515 is being started via <command>inetd</command> with a 
 PID of <quote>988</quote>. <command>inetd</command> is a special situation.
 <command>inetd</command> is often called the <quote>super server</quote>,
 since it's main role is to spawn sub-services. <![%redhat;[
 <application>xinetd</application> replaces <application>inetd</application>
 as of Red Hat 7.0. ]]> If we look at the first line, <command>inetd</command>
 is listening on port 515 for printer services. If a connection comes for this
 port, <command>inetd</command> intercepts it, and then will spawn the
 appropriate daemon, i.e. the print daemon in this case. The configuration of
 how <command>inetd</command> handles this is typically done in
 <filename>/etc/inetd.conf</filename>. This should tell us that if we want to
 stop an <command>inetd</command> controlled server on a permanent basis, then
 we will have to dig into the <command>inetd</command> (or perhaps
 <command>xinetd</command>) configuration. Also the time service above is
 started via <command>inetd</command> as well. This should also tell us that
 these two services can be further protected by
 <application>tcpwrappers</application> (discussed in Step 3 above). This is
 one benefit of using <command>inetd</command> to control certain system
 services.
-->
  これらの中には既に顔なじみのものもあります。
しかし今回は、515 番ポートのプリンタデーモンが <quote>988</quote> 番の
PID で <command>inetd</command> を通して開始されたこともわかります。
<command>inetd</command> は特別な状況です。
<command>inetd</command> はしばしば <quote>スーパーサーバ</quote>
 と呼ばれますが、それはその主な役割がサブデーモンを
産み出すことだからです。<![%redhat;[Red Hat 7.0. 以降では、
<application>inetd</application> の代わりに 
<application>xinetd</application> が使われています。]]>
最初の行を見ると、<application>inetd</application> は
プリンタサーヴィスのために 515 番ポートで耳をすませています。
このポートに接続がやってくると、<application>inetd</application> が
これを途中で捕まえて、適切なデーモン、
つまりこの場合にはプリントデーモンを生成するのです。
<command>inetd</command> がこれをどう扱うかの設定は、
典型的な場合では <filename>/etc/inetd.conf</filename> でなされます。
ですから、もし恒常的に <command>inetd</command> に制御されている
サーバを停止したいならば、<command>inetd</command>
（または <command>xinetd</command>）の設定を詳しく調べなければなりません。
また上の time サーバも同様に <command>inetd</command>
経由で開始されています。この事実は、これら二つのサーヴィスをさらに
 <application>tcpwrapper</application> （上のステップ３で説明しました）
で守ることができることも意味しています。
これはシステムサーヴィスを制御するのに <command>inetd</command>
 を用いる利点の一つです。
</para>

<para>
<!--
 We weren't sure about the service on port 631 above since it did not have 
 a standard service name, which means it is something maybe unusual or off 
 the beaten path. Now we see it is owned by <command>cupsd</command> 
 <![%redhat;[ (not included with Red Hat by the way)]]>, which is one of
 several print daemons available under Linux. This happens to be the web
 interface for controlling the printer service. Something
 <command>cupsd</command> does that is indeed a little different than other
 print servers. 
-->
  上の章では 631 番ポートのサーヴィスについては確信がもてませんでしたね。
と言うのも、それが標準的なサーヴィス名を持っていなかったからで、
それはおそらく、何かしら普通でないか、
常道に外れていることを意味しているからです。
しかし、今やそれが <command>cupsd</command> によって
所有されていることを知ることができました。
これは<![%redhat;[ （Red Hat には含まれていませんが、）]]>
Linux で使用可能なプリントサーバの一つです。
これがたまたまプリンタサーヴィスを制御するための
 web インターフェースになっているのです。
<command>cupsd</command> がすることは実際、
他のプリントサーバとほとんど変わりません。
</para>

<para>
<!--
 The last entry above is the SMTP mail server on bigcat. Often, this is 
 <command>sendmail</command><![%linuxall;[ with many distributions]]>. But
 not in this case. The command is <quote>master</quote>, which may not ring
 any bells. Armed with the program name we could go searching the filesystem
 with tools like the <command>locate</command> or <command>find</command>
 commands. After we found it, we could then probably discern what package it
 belonged to. But with the PID available now, we can look at
 <command>ps</command> output, and see if that helps us any:
-->
  上の最後のエントリは bigcat の SMTP メイルサーバです。
しばしば、これは<![%linuxall;[多くのディストリビューションで]]>
 <command>sendmail</command> になっています。
しかし、この場合はそうではありません。
このコマンドは <quote>master</quote> で、
危険ではないものと思われます。
プログラム名がわかれば、<command>locate</command> や
 <command>find</command> といったツールでファイルシステムを
探しに行くことができるでしょうし、
それが見つかれば、どのパッケージに属しているかも
見分けることができます。
しかし、今や PID を知っているのですから、
以下のように <command>ps</command> コマンドで、
何か助けが得られるかどうか試すことができます：
</para>

<para>
 <screen>

 $ /bin/ps ax |grep 1051 |grep -v grep
  1051 ?        S        0:24 /usr/libexec/postfix/master

 </screen>
</para>

<para>
<!--
 We took a shortcut here by combining <command>ps</command> with
 <command>grep</command>. It looks like that this file belongs to  
 <command>postfix</command>, which is indeed a mail server package 
 comparable to <command>sendmail</command><![%redhat;[ ( and is  
 included with Powertools, not the base distribution)]]>. 
-->
  ここでは近道をするために <command>ps</command> コマンドを
 <command>grep</command> と合わせて使っています。
このファイルは <command>postfix</command> に属しているようです。
これは実際 <command>sendmail</command>
と同等のメイルサーバのパッケージです
<![%redhat;[（これは基本のディストリビューションではなく、
Powertools に含まれるものです。）]]>。
</para>

<para>
<!--
 Running <command>ps</command> with the <literal>&#045;&#045;forest</literal> flag 
 (<literal>-f</literal> for short) can be helpful in determining what
 processes are parent or child process or another process. An edited example:
 -->
   <command>ps</command> を<literal>--forest</literal> フラッグ
（省略形は <literal>-f</literal> ）とともに使うと、
どのプロセスが親プロセスか子プロセスかまた別のものなのか
決定するのに便利です。以下はその一例です（編集してあります）：
</para>

<para>
 <screen>

 $ /bin/ps -axf
  956 ?        S      0:00 named -u named
  957 ?        S      0:00  \_ named -u named
  958 ?        S      0:46      \_ named -u named
  959 ?        S      0:47      \_ named -u named
  960 ?        S      0:00      \_ named -u named
  961 ?        S      0:11      \_ named -u named
 1051 ?        S      0:30 /usr/libexec/postfix/master
 1703 ?        S      0:00  \_ tlsmgr -l -t fifo -u -c
 1704 ?        S      0:00  \_ qmgr -l -t fifo -u -c
 1955 ?        S      0:00  \_ pickup -l -t fifo -c
 1863 ?        S      0:00  \_ trivial-rewrite -n rewrite -t unix -u -c
 2043 ?        S      0:00  \_ cleanup -t unix -u -c
 2049 ?        S      0:00  \_ local -t unix
 2062 ?        S      0:00  \_ smtpd -n smtp -t inet -u -c

 </screen>
</para>

<para>
<!--
 A couple of things to note here. We have two by now familiar daemons here: 
 <command>named</command> and <command>postfix (smtpd)</command>. Both 
 are spawning sub-processes. In the case of <command>named</command>, what we are
 seeing is threads, various sub-processes that it always spawns. 
 <command>Postfix</command> is also spawning sub-processes, but not as 
 <quote>threads</quote>. Each sub-process has its own specific task. It is 
 worth noting that child processes are dependent on the parent process. 
 So killing the parent PID, will in turn kill all child processes. 
 -->
  ここで二、三注意があります。
今までに馴染みになったデーモンが二つあります：
 <command>named</command> と <command>postfix (smtpd)</command> です。
両方ともサブプロセスとして生成されたものです。
<command>named</command> の場合には、見えているものはスレッドで、
常に生成されている様々なサブプロセスです。
<command>Postfix</command> も生成されたサブプロセスですが、
<quote>スレッド</quote>としてではありません。
各サブプロセスはそれ自身の特定の仕事を持っています。
子プロセスは親プロセスに依存しているということは
注意しておく価値があるでしょう。
ですから、親 PID を殺すと、その結果、全ての子プロセスが殺されます。
</para>

<para>
<!--
 If all this has not shed any light, we might also try <command>locate</command>:
-->
  もしこのどれも何の光も投げかけてくれないなら、
さらに <command>locate</command> を使ってみる手もあるでしょう：
</para>

<para>
 <screen>

 $ locate /master
 /etc/postfix/master.cf
 /var/spool/postfix/pid/master.pid
 /usr/libexec/postfix/master
 /usr/share/vim/syntax/master.vim
 /usr/share/vim/vim60z/syntax/master.vim
 /usr/share/doc/postfix-20010202/html/master.8.html
 /usr/share/doc/postfix-20010202/master.cf
 /usr/share/man/man8/master.8.gz

 </screen>
</para>

<para>
<!--
 <command>find</command> is perhaps the most flexible file finding utility, 
 but doesn't use a database the way <command>locate</command> does, so is 
 much slower:
-->
  <command>find</command> コマンドはおそらくもっとも自由度の高い
ファイルを探すユーティリティですが、
<command>locate</command> がするようにデータベースを使わないので、
ずっと遅いです：
</para>

<para>
 <screen>

 $ find / -name master         
 /usr/libexec/postfix/master

 </screen>
</para>

<para>
<!--
 If <command>lsof</command> is installed, it is another command that is useful
 for finding who owns processes or ports:
-->
  もし <command>lsof</command> がインストールされていれば、
誰がプロセスやポートを所有しているか見つけるのに便利な
また一つのコマンドです：
</para>

<para>
 <screen>

 # lsof -i :631       
 COMMAND  PID  USER    FD   TYPE DEVICE SIZE NODE NAME
 cupsd   1315  root    0u   IPv4   3734       TCP *:631 (LISTEN)

 </screen>
</para>

<para>
<!--
 This is again telling us that the <command>cupsd</command> print daemon is
 the owner of port 631. Just a different way of getting at it. Yet one more
 way to get at this is with <command>fuser</command>, which should be
 installed:
-->
  これは再び、<command>cupsd</command> プリントデーモンが
631 番ポートの所有者であることを教えてくれています。
同じことを、違った方法で得たわけです。
これを得るまたもう一つの方法は <command>fuser</command> で、
これもインストールされているはずです：
</para>

<para>
 <screen>

 # fuser -v -n tcp 631

                      USER        PID  ACCESS  COMMAND
 631/tcp              root       1315  f....   cupsd

 </screen>
</para>

<para>
<!--
 See the man pages for <command>fuser</command> and <command>lsof</command> 
 command syntax.
-->
  <command>fuser</command> と <command>lsof</command> 
コマンドの文法については man ページを参照してください。
</para>

<para>
<!--
 Another place to look for where a service is started, is in the
 <filename>init.d</filename> directory, where the actual init scripts
 live<![%linuxall;[ (for SysVinit systems)]]>. Something like <literal>ls -l
 /etc/<![%redhat;[rc.d/]]>init.d/</literal>, should give us a list of these.
 Often the script name itself gives a hint as to which service(s) it starts,
 though it may not necessarily exactly match the <quote>Program Name</quote>
 as provided by <command>netstat</command>. Or we can use
 <command>grep</command> to search inside files and match a search pattern.
 Need to find where <command>rpc.statd</command> is being started, and we
 don't see a script by this name?
-->
  サーヴィスが開始される場所を探すまた別の場所は、
<filename>init.d</filename> ディレクトリで、
これは<![%linuxall;[（SysVinit システムについては）]]>
実際 init スクリプトが住んでいる場所です。
<literal>ls -l /etc/<![%redhat;[rc.d/]]>init.d/</literal>
 のようなことをすれば、このリストが得られるはずです。
<command>netstat</command> が用意してくれるように、
必ずしも正確に<quote>プログラム名</quote>と一致しないかも知れないのですが、
しばしば、
スクリプトの名前自身がどのサーヴィスを開始させるのかのヒントになります。
または、<command>grep</command> コマンドを用いて、
ファイルの中身を探してパターンマッチさせることもできます。
<command>rpc.statd</command> が開始された場所を探す必要があって、
この名前ではどのスクリプトかわからない？では…
</para>

<para>
 <screen>

 # grep rpc.statd /etc/init.d/*
 /etc/init.d/nfslock: [ -x /sbin/rpc.statd ] || exit 0
 /etc/init.d/nfslock:    daemon rpc.statd
 /etc/init.d/nfslock:    killproc rpc.statd
 /etc/init.d/nfslock:    status rpc.statd
 /etc/init.d/nfslock:    /sbin/pidof rpc.statd &gt;/dev/null 2>&amp;1; STATD="$?"

 </screen>
</para>

<para>
<!--
 We didn't really need all that information, but at least we see now 
 exactly which script is starting it. Remember too that not all services 
 are started this way. Some may be started via <application>inetd</application>, 
 or <application>xinetd</application>.
-->
  この全部の情報が実際必要なわけではありませんが、
少なくとも今や正確にどのスクリプトがこれを開始させているのかわかりました。
全てのサーヴィスがこのように開始されるのではないということも
覚えておいてください。
<application>inetd</application> や <application>xinetd</application>
 経由で開始されることもあります。
</para>

<para>
<!--
 The <filename>/proc</filename> filesystem also keeps everything we want 
 to know about processes that are running. We can query this to find out 
 more information about each process. Do you need to know the full path of the
 command that started a process?
-->
  <filename>/proc</filename> ファイルシステムも今走っているプロセスに
ついて知りたいことの全てを持っています。
各プロセスについてさらなる情報を見つけるために、
これに問い合わせることもできます。
あるプロセスを開始したコマンドへのフルパスを知りたい？
それならこうです。
</para>

<para>
 <screen>

 # ls -l /proc/1315/exe
 lrwxrwxrwx  1 root  root   0 July 4 19:41 /proc/1315/exe -> /usr/sbin/cupsd

 </screen>
</para>

<para>
<!--
 Finally, we had a loose end or two in the UDP listening services. Remember we
 had a strange looking port number 32768, that also had no service name 
 associated with it:
-->
  最後に、UDP に耳をすませているサーヴィスについて
一つ二つ述べて終わることにしましょう。
32768 番ポートで変なことがあったことを思い出してください。
それはサーヴィス名を持っていないのでした。
</para>

<para>
 <screen>

 # netstat -aup
 Active Internet connections (servers and established)
  Local Address           Foreign Address         State       PID/Program name   
   *:32768                 *:*                                 956/named           
   bigcat:domain           *:*                                 956/named           
   bigcat:domain           *:*                                 956/named           
   *:631                   *:*                                 1315/cupsd          

 </screen>
</para>

<para>
<!--
  Now by including the <quote>PID/Program name</quote>
 option with the <literal>-p</literal> flag, we see this also belongs to
 <command>named</command>, the nameserver daemon. Recent versions of
 <application>BIND</application> use an unprivileged port for some types 
 of traffic. In this case, this is <application>BIND 9.x</application>. 
 So no real alarms here either. The unprivileged port here is the one 
 <command>named</command> uses to to talk to other nameservers for name 
 and address lookups, and should not be firewalled. 
-->
  今や <literal>-p</literal> フラッグで
 <quote>PID/ プログラム名</quote>オプションを含めることによって、
これも <command>named</command> つまりネイムサーバデーモンに
属していることがわかります。
<application>BIND</application> の最新のバージョンは
あるタイプの通信については非特権ポートを使います。
この場合には、これは <application>BIND 9.x</application> です。
ですから、ここでは本当の危険はないのです。
ここではこの非特権ポートは<command>named</command> が名前とアドレス
を参照するために他のネイムサーバに話しかけるのに使われていて、
ファイアーウォールでこれを防ぐべきではないのです。
</para>

<para>
<!--
 So we found no big surprises in this hypothetical situation.
-->
  つまり我々のこの仮想的な状況においては、
大きな驚きは何もなかったということです。
</para>

<para>
<!--
 If all else fails, and you can't find a process owner for an open port,
 suspect that it may be an RPC (Remote Procedure Call) service of some kind.
 These use randomly assigned ports without any seeming logic or consistency,
 and are typically controlled by the <command>portmap</command> daemon. 
 In some cases, these may not reveal the process owner to
 <command>netstat</command> or <command>lsof</command>. Try stopping
 <command>portmap</command>, and then see if the mystery service goes away. Or
 you can use <command>rpcinfo -p localhost</command> to see what RPC services
 may be running (<command>portmap</command> must be running for this to
 work).
-->
  もし全ての試みが失敗して、ある開いたポートについて
プロセスの所有者が見つけられなかった場合には、
それがある種の RPC (Remote Procedure Call) サーヴィスかも知れない
と疑ってください。
これらは何のロジックも一貫性もなくランダムに
割り当てられたポートを使っており、
典型的には <command>portmap</command> デーモンによって制御されています。
ある場合には、これらは <command>netstat</command> や
 <command>lsof</command> コマンドでプロセス所有者を知ることができます。
<command>portmap</command> を止めてみて、
その不思議なサーヴィスがいなくなるかどうか見てみましょう。
またあなたは RPC サーヴィスが走っているかもしれないこと
（このために <command>portmap</command> が走っているはずです）
を見るために、 <command>rpcinfo -p localhost</command> 
コマンドを使うこともできます。
</para>

 <warning>
  <para>
<!--
   If you suspect you have been broken into, <emphasis>do not trust</emphasis> 
   <command>netstat</command> or <command>ps</command> output. There is a good
   chance that they, and other system components, has been tampered with in
   such a way that the output is not reliable.
-->
  もしあなたが既に侵入されているかもしれないと疑っているのでしたら、
<command>netstat</command> や <command>ps</command> の出力を
<emphasis>信じないでください</emphasis>。
他のシステム要素もそうですが、
既にこれらも改竄されてしまっていて、
その出力が信用できなくなっている可能性が充分にあります。
  </para>
 </warning>

</sect3>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="threats">
<title><!--Attacks and Threats-->攻撃と脅威</title>

<para>
<!--
 In this section, we will take a quick look at some of the common threats 
 and techniques that are out there, and attempt to put them into some 
 perspective.
-->
  この章では、
あちこちでよく見かけられる脅威とテクニックについて簡単に紹介して、
いくらかの見通しを与えましょう。
</para>

<para>
<!--
 The corporate world, government agencies and high profile Internet sites have
 to be concerned with a much more diverse and challenging set of threats than
 the typical home desktop user. There are many reasons someone may want to
 break in to someone else's computer. It may be just for kicks, or any number
 of malicious reasons. They may just want a base from which to attack 
 someone else. This is a very common motivation.
 -->
  法人の世界や、政府機関や、
広く注目されているインターネットサイトでは、
典型的な自宅でのデスクトップユーザよりも、
はるかに広く難しい脅威に注意せねばなりません。
誰かが他の誰かのコンピュータに侵入しようとする理由はたくさんあります。
それは単にスリルが目的かもしれませんが、
悪意のある理由は他にいくらでもありえるでしょう。
彼らは単に他の誰かを攻撃するための足がかりを得たいだけかもしれません。
これは非常によくある動機の一つです。
</para>

<para>
<!--
 The most common <quote>attack</quote> for most of us is from already
 compromised systems. The Internet is littered with computers that have been
 broken into, and are now doing their master's bidding blindly, in zombie-like
 fashion. They are programmed to scan massively large address ranges, probing
 each individual IP address as they go. Looking for one or more open ports,
 and then probing for known weaknesses if they get the chance. Very
 impersonal. Very methodical. And very effective. We are all in the path of
 such robotic scans. All because those responsible for these systems fail to
 do what you are doing now - taking steps to protect their system(s), and
 avoid being r00ted.
-->
  我々のほとんどにとって、もっともよくある<quote>攻撃</quote>は
既に乗っ取られているシステムからのものです。
インターネットは既に侵入されてしまったコンピュータにあふれていて、
主人の命令をまるでゾンビのように盲目的に実行中です。
それらは巨大なアドレス範囲に渡ってスキャンし、
そこで各個別の IP アドレスを検査するようにプログラミングされています。
一つ以上の開いたポートを探しあて、
チャンスがあれば既知の弱点を検査します。これは、
非常に非人格的で、非常に方法論的で、しかも非常に効果的です。
我々は皆このような自動化されたスキャンロボットの通り道にいるのです。
我々が今行っているのは、
システムを守り r00t されることを避けるためのステップを取り、
システムに対する彼らの対応を失敗させるためなのです。
</para>

<para>
<!--
 These scans do not look at login banners that may be presented on connection.
 It will do little good to change your <filename>/etc/issue.net</filename> to
 pretend that you are running some obscure operating system. If they find
 something listening, they will try all of the exploits appropriate to that
 port, without regard to any indications your system may give. If it works,
 they are in &#045;&#045; if not, they will move on.
-->
  これらのスキャンは接続したときに示される
ログインバナーを見るためにしているのではありません。
それはあなたがいくらか不明瞭なオペレーティングシステムを
走らせているかのように偽るように、
あなたの <filename>/etc/issue.net</filename> を変更するといった
ちょっとしたことをするのです。
彼らは耳をすませているポートを見つけると、
そのシステムがどんな指示を与えようがかまわずに、
そのポートに対してあてはまる全ての攻撃を試してみるでしょう。
もしそれがうまくいけば、彼らは入ってきますし、
もし駄目なら、別の標的に移動するわけです。
</para>



<!--   ~~~~~       New section      ~~~~~     -->

<sect3 id="scans">
<title><!--Port Scans and Probes-->ポートスキャンとプローブ</title>

<para>
<!--
 First, let's define <quote>scan</quote> and <quote>probe</quote> since these 
 terms come up quite a bit. A <quote>probe</quote> implies testing if a given
 port is open or closed, and possibly what might be listening on that port. A
 <quote>scan</quote> implies either <quote>probing</quote> multiple ports on
 one or more systems. Or individual ports on multiple systems. So you might 
 <quote>scan</quote> all ports on your own system for instance. Or a 
 cracker might <quote>scan</quote> the 216.78.*.* address range to see who
 has port 111 open. 
 -->
  <quote>スキャン</quote>と<quote>プローブ（調査）</quote>
という言葉は何度も問題になってきますから、 
まずこれらの言葉の定義から始めましょう。
<quote>プローブ</quote>とは、
ある与えられたポートが開いているか閉じているか、
そしてそのポートで何が耳をすませているかを、
テストすることを意味します。
<quote>スキャン</quote>とは、
一つまたはそれ以上のシステム上で複数のポートを
<quote>プローブする</quote>ことです。
または複数のシステム上の特定のポートかもしれません。
ですから、例えば、自分のシステム上の全てのポートを
<quote>スキャンする</quote>とか、
またはクラッカーが 111 番ポートを開いているのは誰かを知るために
 216.78.*.* アドレスを<quote>スキャンしている</quote>、
などと言うのです。
</para>

<para>
<!--
 Black hats can use scan and probe information to know what services are
 running on a given system, and then they might know what exploits to try.
 They may even be able to tell what Operating System is running, and even
 kernel version, and thus get even more information. <quote>Worms</quote>, on
 the other hand, are automated and scan blindly, generally just looking for
 open ports, and then a susceptible victim. They are not trying to
 <quote>learn</quote> anything, the way a cracker might.
-->
  black hat （黒帽子、悪者ハッカー）たち
は与えられたシステム上でどんなサーヴィスが
走っているかについての情報をスキャンしプローブすることができ、
これによってどんな攻撃を試してみるべきかを知ります。
彼らはどんなオペレーティングシステムが走っているか、
そのカーネルのバージョンは何か、について答えることさえ、
さらには、もっと多くの情報を得ることも可能かも知れません。
一方では、<quote>ワーム(worm)</quote>は自動化されていて、
盲目的にスキャンし、一般的には開いているポート、
つまり弱い犠牲者を探しているだけです。
それらはクラッカーがするかも知れないような
<quote>学習</quote>は全くしようとしません。
</para>

<para>
<!--
 The distinction between <quote>scan</quote> and <quote>probe</quote>is often
 blurred.  Both can used in good ways, or in bad ways, depending on who is
 doing it, and why.  You might ask a friend to scan you, for instance, to see
 how well your firewall is working. This is a legitimate use of scanning tools
 such as <application>nmap</application>. But what if someone you don't know
 does this? What is their intent? If it's your ISP, they may be trying to
 enforce their Terms of Service Agreement. Or maybe, it is someone just
 playing, and seeing who is <quote>out there</quote>. But more than likely it
 is someone or something with not such good intentions.
-->
  <quote>スキャン</quote>と<quote>プローブ</quote>の間の区別は
しばしば曖昧です。
両方とも誰が、何のために、行うのかに依存して、
良い意味にも悪い意味にも使われます。
例えば、ファイアーウォールの設定がうまく行っているか知るために、
あなたが友達にあなた自身をスキャンしてもらうよう頼むかも知れません。
これは <application>nmap</application> のようなスキャン用ツールの
合法的な使用ということになります。
しかし、あなたの知らない誰かが同じことをしたらどうでしょう？
彼らの目的は何でしょう？もしそれがあなたのプロバイダならば、
サーヴィス契約書の条項を守らせようとしているのかも知れません。
または、誰かが遊んでいるだけで、
そこに誰が<quote>出てくるか</quote>見ているだけかもしれません。
しかし、もっとありそうなのは、
それがこのような善意の意図を持っていない誰かか何かであることです。
</para>

<para>
<!--
 Full range port scans (meaning probing of many ports on the same machine)
 seem to be a not so common threat for home based networks. But certainly, 
 scanning individual ports across numerous systems is a very, very common 
 occurrence.
 -->
  全範囲のポートのスキャン
（同じ一台のマシン上の多くのポートをプローブすること）
は自宅でのネットワークについてはそれほどよくある脅威では
ないようです。
しかし確かに、多くのシステムに対して特定のポートをスキャンすることは、
非常に、非常に、よく起こっていることです。
</para>

</sect3>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect3>
<title><!--Rootkits-->ルートキット (rootkit)</title>


<para>
<!--
 A <quote>rootkit</quote> is the script kiddie's stock in trade. When a
 successful intrusion takes place, the first thing that is often done, is to
 download and install such <quote>rootkits</quote>. The rootkit is a set of
 scripts designed to take control of the system, and then hide the intrusion.
 Rootkits are readily available on the web for various Operating Systems. 
-->
  <quote>ルートキット(rootkit)</quote> とはスクリプトキディ
（既成のスクリプト使いの悪がきども、新米クラッカー）
の道具箱として提供されているものです。
侵入がうまく成功したとき、しばしば最初になされることは、
このような<quote>ルートキット</quote>をダウンロードし、
インストールすることなのです。
</para>

<para>
<!--
 A rootkit will typically replace critical system files such as 
 <command>ls</command>, <command>ps</command>, <command>netstat</command>, 
 <command>login</command> and others. Passwords may be added, hidden 
 daemons started, logs tampered with, and surely one of more backdoors are
 opened. The hidden backdoors allow easy access any time the attacker wants
 back in. And often the vulnerability itself may even be fixed so that the new
 <quote>owner</quote> has the system all to himself. The entire process is
 scripted so it happens very quickly. The rightful owners of these compromised
 systems generally have no idea what is going on, and are victims themselves.
 A well designed rootkit can be very difficult to detect.
-->
  ルートキットは典型的には
<command>ls</command>, <command>ps</command>, <command>netstat</command>, 
 <command>login</command> などの基本的なシステムコマンドを置き換えます。
パスワードを加えたり、密かにデーモンをスタートしたり、
ログを変更したりするかもしれませんし、
確実に一つ以上のバックドア（裏口）を開くでしょう。
隠されたバックドアによって、攻撃者は入りたいときにいつでも
簡単に入ってこれるようになります。
そしてしばしばそのシステムの弱点自身が直されることさえあります。
というのも、新たな<quote>所有者</quote>がそのシステムの全てを
自分のものにするためです。
全体のプロセスはスクリプト化されていますので、
この乗っ取りは非常に素早くなされます。
これらの信頼を失ったシステムの正規の所有者は
一般的には何が起こっているかわからないでしょうが、
餌食になっているのは彼らなのです。
うまく設計されたルートキットは発見するのが非常に難しいものです。
</para>

</sect3>

<!--  ~  End section  ~  -->


<!--   ~~~~~       New section      ~~~~~     -->
<sect3>
<title><!--Worms and Zombies-->ワームとゾンビ</title>

<para>
<!--
 A <quote>worm</quote> is a self replicating exploit. It infects a system, 
 then attempts to spread itself typically via the same vulnerability. Various
 <quote>worms</quote> are weaving their way through the entire Internet
 address space constantly, spreading themselves as they go.
-->
  <quote>ワーム</quote>とは自己複製する攻撃プログラムです。
ワームはシステムに感染すると、典型的な活動としては、
同じシステムの弱点を通して自分自身をばらまこうとします。
さまざまな<quote>ワーム</quote>が常に、
インターネットのアドレス空間全体にのたくっていて、
その行くところに自分自身をばらまいていきます。
</para>

<para>
<!--
 But somewhere behind the zombie, there is a controller. Someone launched 
 the worm, and they will be informed after a successful intrusion. It is 
 then up to them how the system will be used.
 -->
  しかし、ゾンビの背後のどこかには、それをあやつっているものがいます。
誰かがワームを立ち上げ、侵入がうまくいった後でワームがそれを報せるのです。
そして、システムがどのように使われているかを知るわけです。
</para>

<para>
<!--
 Many of these are Linux systems, looking for other Linux systems to
 <quote>infect</quote> via a number of exploits. But most Operating Systems
 share in this threat. Once a vulnerable system is found, the actual entry
 and take over is quick, and may be difficult to detect after the fact. The
 first thing an intruder (whether human or <quote>worm</quote>) will do is
 attempt to cover their tracks. A <quote>rootkit</quote> is downloaded and
 installed. This trend has been exacerbated by the growing popularity of cable
 modems and DSL. The number of full time Internet connections is growing
 rapidly, and this makes fertile ground for such exploits since often 
 these aren't as well secured as larger sites. 
-->
  これらの多くは Linux システムで、
数ある弱点を通して感染しようと他の Linux システムを探しています。
しかしほとんどのオペレーティングシステムはこの脅威をわけあっています。
ひとたび脆弱なシステムが発見されると、
その実際の侵入と乗っ取りは非常に素早いので、
その事実の後でそれと知ることは困難かもしれません。
侵入者が最初にすることは（それが人間であれ<quote>ワーム</quote>であれ）、
その侵入の形跡を隠そうとすることです。
<quote>ルートキット</quote>がダウンロードされてインストールされます。
この流行はケーブルモデムや DSL が広まったことで悪化しています。
インターネットへの常時接続は急速に広がっており、
しばしばこれらがより大きなサイトと同じようには充分安全ではないため、
このような脅威に対して豊かな土壌を提供してしまっているのです。
</para>

<para>
<!--
 While this may sound ominous, a few simple precautions can effectively
 deter this type of attack. With so many easy victims out there, why waste much
 effort breaking into <Emphasis>your</Emphasis> system? There is no incentive
 to really try very hard. Just scan, look, try, move on if unsuccessful. There
 is always more IPs to be scanned. If your firewall is effectively bouncing
 this kind of thing, it is no threat to you at all. Take comfort in that, 
 and don't over re-act.
-->
  これは不吉な話に聞こえますが、
二、三の簡単な注意で効果的に防ぐことができます。
たくさんの易しい餌食があちこちにいるのに、
わざわざ<Emphasis>あなたの</Emphasis>システムに侵入するために
多大な努力を費やすでしょうか？
本気で非常に難しいことに挑戦するインセンティブはありません。
単にスキャンして、見て、試して、駄目なら次へ行く。
世の中にはスキャンする IP が常にまだいくらでもあるのです。
もしあなたのファイアーウォールが効果的にこの種のことを防いでいれば、
あなたにはまったく脅威にはなりません。
気楽に構えて、過剰反応しないようにしましょう。
</para>

<para>
<!--
 It is worth noting, that these worms cannot <quote>force</quote> their way
 in. They need an open and accessible port, <emphasis>and</emphasis> a known
 vulnerability. If you remember the <quote>Iptables Weekly Log Summary</quote>
 in the opening section above, many of those may have all been the result of
 this type of scan. If you've followed the steps in this HOWTO, you should be
 reasonably safe here. This one is easy enough to deflect.
-->
  これらのワームは<quote>無理やりに</quote>入ってくることはできない、
ということは注意しておく価値があるでしょう。
ワームには開いていてアクセス可能なポートが必要で、
<emphasis>かつ</emphasis>、既に知られている弱点が必要です。
上の始めの章での<quote>Iptables の今週のログ要約</quote>
を思い出してもらえれば、
その多くはこのタイプのスキャンの結果だったかもしれません。
あなたがこの HOWTO で示したステップに従っていれば、
あなたは充分に安全です。これは充分簡単に逸らせることができます。
</para>

</sect3>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect3>
<title><!--Script Kiddies-->スクリプトキディたち</title>

<para>
<!--
 A <quote>script kiddie</quote> is a <quote>cracker</quote> wanna be who 
 doesn't know enough to come up with his/her own exploits, but instead 
 relies on <quote>scripts</quote> and exploits that have been developed by
 others. Like <quote>worms</quote>, they are looking for easy victims, 
 and may similarly scan large address ranges looking for specific ports 
 with known vulnerabilities. Often, the actual scanning is done from  
 already comprised systems so that it is difficult to trace it back to them.
-->
  <quote>スクリプトキディ</quote>とは<quote>クラッカー</quote>
ワナビー（なりたがり屋）で、
彼または彼女自身の攻撃をするのに充分な知識はないけれども、
その代わりに他の誰かが開発した<quote>スクリプト</quote>や攻撃
を使う連中のことです。
<quote>ワーム</quote>のように、彼らは易しい餌食を探していて、
ワームと同様に、知られている弱点を持った特定のポートを探すために、
広い範囲に渡ってアドレスをスキャンするかもしれません。
しばしば、実際のスキャンは既に乗っ取ったシステムから行われます。
というのも、そうすれば彼ら自身にまで跡を辿るのが難しくなるからです。
</para>

<para>
<!--
 The script kiddie has a bag of ready made tricks at his disposal, including 
 an arsenal of <quote>rootkits</quote> for various Operating Systems. Finding 
 susceptible victims is not so hard, given enough time and address space to
 probe. The motives are a mixed bag as well. Simple mischief, defacement 
 of web sites, stolen credit card numbers, and the latest craze, 
 <quote>Denial of Service</quote> attacks (see below). They collect 
 zombies like trophies and use them to carry out whatever their objective is.
-->
  スクリプトキディは自分が使う既製品のトリックを入れた鞄を持っていて、
そこには様々なオペレーティングシステムの<quote>ルートキット</quote>
の兵器庫が含まれています。
攻撃しやすい犠牲者を見つけることは、
充分な時間とプローブするための充分に広いアドレス空間が与えられれば、
それほど難しいことではありません。
その動機はごちゃまぜの鞄と同様です。単なるいたずら、
web サイトの攻撃、クレジットカード番号を盗む、
最近流行の<quote>Denial of Service（サーヴィス拒否）</quote>攻撃
（以下を参照のこと）など。
彼らはトロフィーのようにゾンビを集め、
目的が何であれそれを達成するために用いるのです。
</para>

<para>
<!--
 Again, the key here is that they are following a <quote>script</quote>, and 
 looking for easy prey. Like the worm threat above, a functional firewall 
 and a few very basic precautions, should be sufficient to deflect any 
 threat here. By now, you should be relatively safe from this nuisance.
-->
  再び、ここでのキーポイントは彼らが<quote>スクリプト</quote>を使い、
易しい餌食を探しているということです。
ワームの脅威と同様に、機能を果たしているファイアーウォールと、
二、三の基本的な用心があれば、ここでのどんな脅威も充分に逸らすことが
できるはずです。今や、あなたはこの厄介から比較的安全であるはずです。
</para>

</sect3>


<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect3>
<title><!--Spoofed IPs-->IP のなりすまし</title>

<para>
<!--
 How easy is it to spoof an IP address? With the right tools, very easy. How
 much of a threat is this? Not much, for most of us, and is over-hyped as a 
 threat.
-->
  IP アドレスをごまかすことはどれくらい易しいことでしょうか？
適切なツールがあれば、非常に簡単なことなのです。
これはどれくらいの脅威になるでしょう？
実際は、ほとんどに場合にはそれほど大きな脅威ではなく、
脅威として過大に宣伝されています。
</para>

<para>
<!--
 Because of the way TCP/IP works, each packet must carry both the source and
 destination IP addresses. Any return traffic is based on this information. So
 a spoofed IP can never return any useful information to an attacker who is
 sending out spoofed packets. The traffic would go back to wherever that
 spoofed IP address was pointed. The attacker gets nothing back at all.
-->
  TCP/IP が働く方法として、
各パケットはその出発点とあて先の IP アドレスの両方を運んでいます。
それに対する返答の通信は全て、この情報に基づいています。
ですから、IP のなりすましによって、
だましたパケットを送り出した攻撃者に対しては、
何の有用な情報も決して帰ってこないことになります。
その通信はなりすましている IP アドレスが指し示す場所がどこであろうと、
そこに向かって帰っていきます。
攻撃者のところには結局何も戻ってきません。
</para>

<para>
<!--
 This does have potential for <quote>DoS</quote> attacks (see below) where 
 learning something about the targeted system is not important. And may be 
 used for some general mischief making as well.
-->
  しかし、
これは標的にするシステムについて何かを知ることが重要でない場合、
<quote>DoS</quote> 攻撃（以下を参照）の可能性を確かに持っています。
そして同様に、ある種のいたずらにも使われるかもしれません。
</para>

</sect3>

<!--  ~  End section  ~  -->




<!--   ~~~~~       New section      ~~~~~     -->

<sect3>
<title><!--Targeted Attacks-->標的を定めた攻撃</title>

<para>
<!--
 The worm and wide ranging address type scans, are impersonal. They are just
 looking for any vulnerable system. It makes no difference whether it is a top
 secret government facility, or your mother's Window's box. But there are 
 <quote>black hats</quote> that will spend a great deal of effort to get into 
 a system or network.  We'll call these <quote>targeted</quote> attacks since 
 there has been a deliberate decision made to break in to a specific system 
 or network.
 -->
  ワームと広い範囲に渡るアドレスのスキャンは、非個人的なものです。
それらは単に脆弱なシステムを探しているだけだからです。
 それがトップシークレットの政府機関であろうが、
あなたのお母さんのウィンドウズマシンであろうと、何の違いもありません。
しかし、ある特定のシステムやネットワークに侵入することに
多大な努力を費やす<quote>黒帽子たち</quote>（悪者たち）もいるのです。
特定のシステムやネットワークに侵入するための熟考された決断があるところから、
我々はそれを<quote>標的を定めた</quote>攻撃と呼ぶことにしましょう。
</para>

<para>
<!--
 In this case, the attacker will look the system over for weaknesses. And
 possibly make many different kinds of attempts, until he finds a crack to
 wiggle through. Or gives up. This is more difficult to defend against. The
 attacker is armed and dangerous, so to speak, and is stalking his prey. 
-->
  この場合には、攻撃者は中にもぐりこむための裂け目を見つけるまで、
または諦めるまで、そのシステムの弱点を探し、
おそらく多くの異なる種類の手を試してみるでしょう。
これは防衛するのがより難しい相手です。
攻撃者は武装しており、危険で、いわば犠牲者をつけ狙っているのです。
</para>

<para>
<!--
 Again, this scenario is very unlikely for a typical home system. There just
 generally isn't any incentive to take the time and effort when there are
 bigger fish to fry. For those who may be targets, the best defense here
 includes many of things we've discussed. Vigilance is probably more important
 than ever. Good logging practices and an IDS (Intrusion Detection System)
 should be in place. And subscribing to one or more security related mailing
 lists like BUGTRAQ. And of course, reading those alerts daily, and taking
 the appropriate actions, etc. 
 -->
  繰り返しますが、このシナリオは典型的な自宅のシステムについては、
めったにありそうにないことです。
一般的には、もっと大きな獲物がある時に、
小さな魚に時間と努力を使うインセンティブが単にないからです。
標的になるかもしれない人々についての、
最善の防御は我々が既に議論してきた方法の多くを含んでいます。
注意深くあることが何よりも重要なことです。
良いログの取り方を学び、
IDS （Intrusion Detection System, 侵入検知システム）を使うべきでしょう。
さらに、BUGTRAQ のようなセキュリティ関係のメイリングリストの
一つ以上を購読し、そして、もちろん、これらの警告を毎日読んで、
適切な対応をとるべきです。
</para>

</sect3>


<!--  ~  End section  ~  -->


<!--   ~~~~~       New section      ~~~~~     -->


<sect3 id="dos">
<title><!--Denial of Service (DoS)-->サーヴィス拒否攻撃(Denial fo Service DoS)</title>

<para>
<!--
 <quote>DoS</quote> is another type of <quote>attack</quote> in which the
 intention is to disrupt or overwhelm the targeted system or network in such a
 way that it cannot function normally. DoS can take many forms. On the
 Internet, this often means overwhelming the victim's bandwidth or TCP/IP
 stack, by sending floods of packets and thus effectively disabling the
 connection. We are talking about many, many packets per second. Thousands in
 some cases. Or perhaps, the objective is to crash a server.
-->
  <quote>DoS</quote> とはまた別のタイプの攻撃で、
その目的は、
目標のシステムやネットワークがその機能を正常に果たせなくなるように、
混乱させ、トラフィック量で圧倒することです。
DoS には様々な形がありえますが、
インターネット上ではこれはしばしば、
大量のパケットを送りつけ、効果的に接続を不可能にすることで、
犠牲者の帯域、または TCP/IP スタックを圧倒してしまうことを意味します。
ここで言っているのは、一秒間に膨大の数のパケットということで、
ある場合には数千ということもありえるでしょう。
さらに、ひょっとしたら、
目標はサーバをクラッシュさせることかもしれません。
</para>

<para>
<!--
 This is much more likely to be targeted at organizations or high profile
 sites, than home users. And can be quite challenging to stop depending 
 on the technique. And it generally requires the co-operation of 
 networks between the source(s) and the target, so that the floods are
 stopped, or minimized, before they reach the targeted destination. Once they
 hit the destination, there is no good way to completely ignore them. 
-->
  この攻撃は自宅ユーザよりも、企業や、
広く注目されているサイトをターゲットにすることの方が、
よりありそうなことです。
そしてこのテクニックに屈服するのを食い止めることは
極めて難しいことになりえます。
そしてそのためには、一般的には、
その標的に到達する前にその流れを止めるか、または最小化するために、
その源と標的の間のネットワークの協力が必要になります。
ひとたび、それらが目標に届いてしまえば、
完全にそれらを無視する良い方法はありません。
</para>

<para>
<!--
 <quote>DDoS</quote>, Distributed Denial of Service, is where multiple sources
 are used to maximize the impact. Again, not likely to be directly targeted at
 home users. These are <quote>slaves</quote> that are <quote>owned</quote> 
 by a cracker, or script kiddie, that are woken up and are targeted at the 
 victim. There may be many computers involved in the attack.
 -->
   <quote>DDoS</quote> (Distributed Denial of Service),
つまり分散されたサーヴィス拒否攻撃は、
その効果を最大化するために複数の源を使うものです。
これもまた、直接ホームユーザを標的にすることはありそうにないでしょう。
これらは<quote>クラッカー</quote>またはスクリプトキディによって
<quote>所有されている</quote><quote>奴隷たち(slaves)</quote>で、
目を覚まされると犠牲者に襲いかかるのです。
この攻撃にはたくさんのコンピュータがまきこまれるかもしれません。
</para>

<para>
<!--
 If you are home user, and with a dynamic IP address, you might find
 disconnecting, then re-connecting to get a new IP, an effective way out 
 if you are the target. Maybe.
 -->
  もしあなたがホームユーザで、動的な IP アドレスを使っていれば、
あなたがその標的になったときには、
新しい IP を得るために接続を切って再接続することが、
効果的な対処法かもしれません。おそらく。 
</para>


</sect3>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect3>
<title><!--Brute Force-->Brute Force （力まかせ、虱つぶし攻撃）</title>

<para>
<!--
 <quote>Brute force</quote> attacks are where the attacker makes repetitive
 attempts at the same perceived weakness(es). Like a battering ram. A classic
 example would be where someone tries to access a
 <application>telnet</application> server simply by continually throwing
 passwords at it, hoping that one will eventually work. Or maybe crash the
 server. This doesn't require much imagination, and is not a commonly used
 tactic against home systems.
 -->
  <quote>Brute force（力まかせ、しらみつぶし）</quote>攻撃は
攻撃者が知られている同じ弱点に対し繰り返し試行をおこないます。
破壊槌のように。古典的な例は、
何者かが <application>telnet</application> サーバ
にアクセスするために、単にパスワードを次々に投げつけることで、
いつかはその一つがうまく行くだろうと期待するものでしょう。
またはサーバがクラッシュすることを期待するのかもしれません。
これはそれほど想像力を必要としませんし、
自宅のシステムに対して通常用いられる作戦ではありません。
</para>

<para>
<!--
 By the way, this is one good argument against allowing remote root logins. 
 The root account exists on all systems. It is probably the only one that this
 is true of. You'd like to make a potential attacker guess both the login 
 name <emphasis>and</emphasis> password. But if root is allowed remote logins, 
 then the attacker only needs to guess the password!
 -->
  ところで、
これは遠隔からの root ログインを許可することに反対する、
一つの良い論点を与えてもいます。
root アカウントは全てのシステムで存在します。
おそらくこのような性質を持つアカウントはこれだけでしょう。
あなたは潜在的な攻撃者に、
ログイン名とパスワードの<emphasis>両方</emphasis>を
推測させたいでしょうが、
もし root にリモートログインが許されていれば、
攻撃者はパスワードだけを推測すればよいことになってしまいます！
</para>

</sect3>

<!--  ~  End section  ~  -->


<!--   ~~~~~       New section      ~~~~~     -->

<sect3 id="viruses">
<title><!--Viruses-->ウィルス</title>

<para>
<!--
 And now something <emphasis>not</emphasis> to worry about. Viruses seem to be
 primarily a Microsoft problem. For various reasons, viruses
 are not a significant threat to Linux users. This is not to say that it will
 always be this way, but the current virus explosion that plagues Microsoft
 systems, can not spread to Linux (or Unix) based systems. In fact, the
 various methods and practices that enable this phenomena, are not exploitable
 on Linux. So Anti-Virus software is not recommended as part of our arsenal.
 At least for the time being with Linux only networks.
 -->
  これは心配することの<emphasis>ない</emphasis>ものです。
ウィルスは主に Microsoft ユーザの問題に思えます。
多くの理由によって、ウィルスは Linux ユーザにとって大きな脅威には
なりません。これからも常にそうだとは言えませんが、
現在 Microsoft システムを悩ませているウィルス被害の爆発的な拡大は
Linux （または Unix）ベースのシステムには拡がらないはずです。
実際、この現象を可能にしている様々な方法は、
Linux 上では有効ではありません。ですからウィルス防御ソフトウェアを
我々の武器庫に入れることはお勧めしません。
少なくとも Linux のみのネットワークである間は。
</para>

</sect3>

</sect2>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="links">
<title><!--Links-->リンク集</title>

<para>
<!--
 Some references for further reading are listed below. Not listed is your 
 distribution's site, security page or ftp download site. You will 
 have to find these on your own. Then you should bookmark them!
-->
  さらなる読み物へのリファレンスを以下に挙げます。
あなたが使っているディストリビューションのサイト、
セキュリティページ、ftp ダウンロードサイトは挙げられていませんので、
自分で見つける必要があります。
そしてそれらを必ずブックマークしてください！
</para>

<para>
 <itemizedlist>

  <![%redhat;[ 
  <listitem>
   <para>
<!--
     Redhat sites of interest:
-->
  興味深い RedHat サイト：
   </para>
   
   <simplelist>
    <member>
<!--
     The Redhat watch/security mailing list:
-->
  Redhat ウォッチ/セキュリティメイリングリスト：
 <ulink
     url="https://listman.redhat.com/mailman/listinfo/redhat-watch-list">https://listman.redhat.com/mailman/listinfo/redhat-watch-list</ulink>
    </member>
   </simplelist>

   <simplelist>
    <member>
<!--
     Red Hat errata and security notices:
-->
 Red Hat 訂正、セキュリティ報告：
     <ulink url="http://redhat.com/errata/">http://redhat.com/errata/</ulink>
    </member>
   </simplelist>

   <simplelist>
    <member>
<!--
     The Red Hat update FTP site:
-->
  Red Hat アップデート FTP サイト：
     <ulink url="ftp://updates.redhat.com/">ftp://updates.redhat.com/</ulink>
    </member>
   </simplelist>
  </listitem> ]]>

  <listitem>
   <para>
<!--
     Other relevant documents available from the Linux Documentation Project:
-->
  他の関連文書は Linux ドキュメントプロジェクトで見つけられます：
   </para>

   <simplelist>
    <member>
     Security HOWTO: <ulink url="http://tldp.org/HOWTO/Security-HOWTO.html
">http://tldp.org/HOWTO/Security-HOWTO.html
</ulink>
     （JF日本語版<ulink url="http://www.linux.or.jp/JF/JFdocs/Security-HOWTO.html">http://www.linux.or.jp/JF/JFdocs/Security-HOWTO.html</ulink>）
    </member>
   </simplelist>

   <simplelist>
    <member>
      Firewall HOWTO: <ulink url="http://tldp.org/HOWTO/Firewall-HOWTO.html">http://tldp.org/HOWTO/Firewall-HOWTO.html</ulink>  
     （JF日本語版<ulink url="http://www.linux.or.jp/JF/JFdocs/Firewall-HOWTO.html">http://www.linux.or.jp/JF/JFdocs/Firewall-HOWTO.html</ulink>）
    </member>
   </simplelist>

   <simplelist>
    <member>
     Ipchains HOWTO: <ulink url="http://tldp.org/HOWTO/IPCHAINS-HOWTO.html
">http://tldp.org/HOWTO/IPCHAINS-HOWTO.html
</ulink>  
     （JF日本語版<ulink url="http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO.html">http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO.html</ulink>）
    </member>
   </simplelist>

   <simplelist>
    <member>
      User Authentication: <ulink
      url="http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html">http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html</ulink>, 
<!--includes a 
      nice discussion on PAM.-->
これは PAM についての素晴らしい議論を含んでいます。
     （JF日本語版<ulink url="http://www.linux.or.jp/JF/JFdocs/User-Authentication-HOWTO.txt">http://www.linux.or.jp/JF/JFdocs/User-Authentication-HOWTO.txt</ulink>）
      </member>
   </simplelist>

   <simplelist>
    <member>
     VPN (Virtual Private Network): <ulink
     url="http://tldp.org/HOWTO/VPN-HOWTO.html">http://tldp.org/HOWTO/VPN-HOWTO.html</ulink>
     と <ulink
     url="http://tldp.org/HOWTO/VPN-Masquerade-HOWTO.html">http://tldp.org/HOWTO/VPN-Masquerade-HOWTO.html</ulink>
     （JF日本語版<ulink url="http://www.linux.or.jp/JF/JFdocs/VPN-HOWTO.html/">http://www.linux.or.jp/JF/JFdocs/VPN-HOWTO.txt</ulink>）
     </member>
   </simplelist>

   <simplelist>
    <member>
      The Remote X Apps Mini HOWTO, 
      <ulink url="http://www.tldp.org/HOWTO/mini/Remote-X-Apps.html">http://www.tldp.org/HOWTO/mini/Remote-X-Apps.html</ulink>, 
<!--
      includes excellent discussions on the security implications of running 
      X Windows.
-->
には X Window をセキュアに実装するための素晴らしい議論が含まれています。
     </member>
   </simplelist>

   <simplelist>
    <member>
      The Linux Network Administrators Guide: 
      <ulink
      url="http://tldp.org/LDP/nag2/index.html">http://tldp.org/LDP/nag2/index.html</ulink>, 
<!--
includes a good overview of networking and TCP/IP, and 
      firewalling.
-->
はネットワークと TCP/IP とファイアーウォールについての良い
概観説明を含んでいます。
      </member>
   </simplelist>

   <simplelist>
    <member>
      The Linux Administrator's Security Guide: 
      <ulink
      url="http://www.seifried.org/lasg/"> http://www.seifried.org/lasg/</ulink>,
<!-- 
      includes many obvious topics of interest, including firewalling, 
      passwords and authentication, PAM, and more.
-->
は、ファイアーウォール、パスワード、認証、PAM などなどについての、
興味深い多くのトピックを含んでいます。
      </member>
   </simplelist>

   <simplelist>
    <member>
     Securing Red Hat: 
     <ulink
     url="http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/index.html">http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/index.html</ulink>
     </member>
   </simplelist>

  </listitem> 

  <listitem>
   <para>
<!--
     Tools for creating custom <application>ipchains</application> and 
     <application>iptables</application> firewall scripts:
-->
  <application>ipchains</application> と <application>iptables</application>
ファイアーウォールスクリプトのカスタム設定を作るためのツール： 
   </para>
<!--   
   <simplelist>
    <member>
      PMFirewall: <ulink
      url="http://www.pmfirewall.com/PMFirewall/">http://www.pmfirewall.com/PMFirewall/</ulink>
      </member>
   </simplelist>
-->   
   <simplelist>
    <member>
      Firestarter: <ulink
      url="http://firestarter.sourceforge.net">http://firestarter.sourceforge.net</ulink>
      </member>
   </simplelist>

   <simplelist>
    <member>
<!--
     Two related projects:
-->
  二つの関連プロジェクト：
 <ulink url="http://seawall.sourceforge.net/">http://seawall.sourceforge.net/</ulink> (ipchains), 
      <ulink url="http://shorewall.sourceforge.net/"></ulink> (iptables).
    </member>
   </simplelist>
   
  </listitem> 

  <listitem>
   <para>
<!--
     Netfilter and iptables documentation from the netfilter developers 
     (available in many other languages as well):
-->
  netfilter ディベロッパーからの netfilter と iptables の文書
（多くの他の言語でも入手可能）：
   </para>

   <simplelist>
    <member>
      FAQ: <ulink
      url="http://netfilter.samba.org/documentation/FAQ/netfilter-faq.html">http://netfilter.samba.org/documentation/FAQ/netfilter-faq.html</ulink>
      </member>
    <member>
      <!--Packet filtering:-->パケットフィルタリング： <ulink
      url="http://netfilter.samba.org/documentation/HOWTO/packet-filtering-HOWTO.html">http://netfilter.samba.org/documentation/HOWTO/packet-filtering-HOWTO.html</ulink>
      </member>
    <member>
      <!--Networking:-->ネットワーキング： <ulink
      url="http://netfilter.samba.org/documentation/HOWTO/networking-concepts-HOWTO.html">http://netfilter.samba.org/documentation/HOWTO/networking-concepts-HOWTO.html</ulink>
      </member>
    <member>
      <!--NAT/masquerading:-->NAT/マスカレーディング： <ulink
      url="http://netfilter.samba.org/documentation/HOWTO/NAT-HOWTO.html">http://netfilter.samba.org/documentation/HOWTO/NAT-HOWTO.html</ulink>
      </member>
   </simplelist>
   
  </listitem> 

  <listitem>
   <para>
<!--
     Port number assignments, and what that scanner may be scanning for:
-->
  ポート番号割り当て、スキャナーがスキャンするかもしれないものについて：
   </para>

   <simplelist>
    <member>
      <ulink
      url="http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html">http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html</ulink>
      </member>
   </simplelist>
   <simplelist>
    <member>
      <ulink
      url="http://www.sans.org/newlook/resources/IDFAQ/oddports.htm">http://www.sans.org/newlook/resources/IDFAQ/oddports.htm</ulink>
      </member>
   </simplelist>
   <simplelist>
    <member>
      <ulink url="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</ulink>, <!--the official assignments.-->
公式のポート番号割り当て。
    </member>
   </simplelist>
   
  </listitem> 

  <listitem>
   <para>
<!--
    General security sites. These all have areas on documentation, alerts, 
    newsletters, mailing lists, and other resources.
-->
  一般的なセキュリティサイト。
これらには全て、文書、警告、ニュースレター、メイリングリスト、
そのほかの情報源についてのコーナーがあります。
   </para>
   
   <simplelist>
    <member>
      Linux Security.com: <ulink url="http://www.linuxsecurity.com">http://www.linuxsecurity.com</ulink>, <!--loaded with good info, and Linux specific. -->
良い情報が集められている。Linux 固有の情報。 
      <!--Lots of good docs:-->良い文書が沢山： <ulink url="http://www.linuxsecurity.com/docs/">http://www.linuxsecurity.com/docs/</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
      CERT, <ulink url="http://www.cert.org">http://www.cert.org</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
      The SANS Institute: <ulink
      url="http://www.sans.org/">http://www.sans.org/</ulink> 
    </member>
   </simplelist>
   
   <simplelist>
    <member>
      The Coroner's Toolkit (TCT)（検視官の道具箱）: <ulink
      url="http://www.fish.com/security/">http://www.fish.com/security/</ulink>, 
<!--
      discussions and tools for dealing with post break-in issues (and
      preventing them in the first place).
-->
  侵入のその後の問題（侵入者が侵入して最初にすること）についての
議論とツール群。
    </member>
   </simplelist>

 </listitem> 

  <listitem>
   <para>
<!--
    Privacy:
-->
  プライバシー：
   </para>

   <simplelist>
    <member>
      Junkbuster: <ulink
      url="http://www.junkbuster.com">http://www.junkbuster.com</ulink>,
<!-- a web proxy and cookie manager.-->
web プロキシ、クッキーマネージャ。
     </member>
   </simplelist>
   <simplelist>
    <member>
      PGP: <ulink url="http://www.gnupg.org/">http://www.gnupg.org/</ulink>
    </member>
   </simplelist>
   
 </listitem> 
 
 <listitem>
  <para>
<!--
   Other documentation and reference sites:
-->
  他の文書と参考サイト：
  </para>

   <simplelist>
    <member>
      Linux Security.com: <ulink
      url="http://www.linuxsecurity.com/docs/">http://www.linuxsecurity.com/docs/</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
      Linux Newbie: <ulink
      url="http://www.linuxnewbie.org/nhf/intel/security/index.html">http://www.linuxnewbie.org/nhf/intel/security/index.html</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
      The comp.os.linux.security FAQ: <ulink
      url="http://www.linuxsecurity.com/docs/colsfaq.html">http://www.linuxsecurity.com/docs/colsfaq.html</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
      The Internet Firewall FAQ: <ulink
      url="http://www.interhack.net/pubs/fwfaq/">http://www.interhack.net/pubs/fwfaq/</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
     The Site Security Handbook RFC: <ulink
      url="http://www.ietf.org/rfc/rfc2196.txt">http://www.ietf.org/rfc/rfc2196.txt</ulink>
    </member>
   </simplelist>

  </listitem> 
 
  <listitem>
   <para>
<!--
     Miscellaneous sites of interest:
-->
  興味深いサイトいろいろ：
   </para>
   
   <simplelist>
    <member>
      <ulink url="http://www.bastille-linux.org">http://www.bastille-linux.org</ulink>, <!--for Mandrake and Red Hat only.-->
  Mandrake と Redhat のみ。
    </member>
   </simplelist>
   <simplelist>
    <member>
      SAINT: <ulink
      url="http://www.wwdsi.com/saint/">http://www.wwdsi.com/saint/</ulink>,
<!--
       system security analysis.
-->
  システムセキュリティ解析。
    </member>
   </simplelist>
   <simplelist>
    <member>
      SSL: <ulink url="http://www.openssl.org/">http://www.openssl.org/</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
      SSH: <ulink url="http://www.openssh.org/">http://www.openssh.org/</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
<!--
      Scan yourself: -->自分自身をスキャン：<ulink
      url="http://www.hackerwhacker.com">http://www.hackerwhacker.com</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
     PAM: <ulink
      url="http://www.kernel.org/pub/linux/libs/pam/index.html">http://www.kernel.org/pub/linux/libs/pam/index.html</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
<!--
     Detecting Trojaned Linux Kernel Modules: 
-->
トロイの木馬をしかけられた Linux カーネルモジュールを検出：
<ulink
      url="http://members.prestige.net/tmiller12/papers/lkm.htm">http://members.prestige.net/tmiller12/papers/lkm.htm</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
<!--
      Rootkit checker: -->ルートキット・チェッカー<ulink
      url="http://www.chkrootkit.org">http://www.chkrootkit.org</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
<!--
     Port scanning tool <application>nmap's</application> home page:-->
ポートスキャン・ツール <application>nmap</application> のホームページ：
 <ulink
      url="http://www.insecure.org">http://www.insecure.org</ulink> 
    </member>
   </simplelist>
   <simplelist>
    <member>
<!--
      Nessus, more than just a port scanner: 
-->
  Nessus（単なるポートスキャナー以上のもの）：
<ulink
      url="http://www.nessus.org">http://www.nessus.org</ulink> 
    </member>
   </simplelist>
   <simplelist>
    <member>
<!--
      Tripwire, intrusion detection: 
-->
  tripwire, 侵入検出ツール：
      <ulink url="http://www.tripwire.org">http://www.tripwire.org</ulink>
    </member>
   </simplelist>
   <simplelist>
    <member>
<!--
      Snort, sniffer and more: -->
  snort, スニッファー、その他：
<ulink
      url="http://www.snort.org">http://www.snort.org</ulink> 
    </member>
   </simplelist>
   <simplelist>
    <member>
<!--
      <ulink url="http://www.mynetwatchman.com">http://www.mynetwatchman.com</ulink>
      and <ulink url="http://dshield.org">http://dshield.org</ulink> are 
      <quote>Distributed Intrusion Detection Systems</quote>. They collect 
      log data from subscribing <quote>agents</quote>, and collate the 
      data to find and report malicious activity. If you want to fight back, 
      check these out.
-->
  <ulink url="http://www.mynetwatchman.com">http://www.mynetwatchman.com</ulink>
      と <ulink url="http://dshield.org">http://dshield.org</ulink> 
は<quote>分散侵入検出システム</quote>です。
これは前もって用意した<quote>エージェントたち</quote>
によってログを集め、
データを解析することで邪悪な活動を見つけて報告してくれます。
反撃したいなら、これをチェックしましょう。
    </member>
   </simplelist>

  </listitem> 
 
 </itemizedlist>
</para>



</sect2>

<!--  ~  End section  ~  -->




<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="text">
<title><!--Editing Text Files-->テキストファイルの編集</title>

<para>
By Bill Staehle
</para>

<para>
<!--
All the world is a file.
-->
  全ての世界は一つのファイルです。
</para>

<para>
<!--
There are a great many types of files, but I'm going to stretch it here,
and class them into two really broad families:
-->
  ファイルには非常に様々なタイプがありますが、
ここでは無理に二つのかなり広い族に分けてみます：
</para>

<Para>
 <Literal>
  <MSGText> 
   <LiteralLayout>

<!--
 Text files are just that.
 Binary files are not.
-->
  ここでまさにあなたが読んでいるテキストファイルと、
　それとは異なるものであるバイナリファイル。
    </LiteralLayout>
  </MSGText>
 </Literal>
</Para>

<para>
<!--
Binary files are meant to be read by machines, text files can be easily
edited, and are generally read by people. But text files can be (and
frequently are) read by machines. Examples of this would be configuration
files, and scripts.
-->
  バイナリファイルはマシンが読むもので、
テキストファイルは人間によって容易に編集でき、
一般的には人間が読むものです。
しかし、テキストファイルはマシンにも読むことが可能で、
実際しばしばそうしています。
その例は設定ファイルやスクリプト群ということになるでしょう。
</para>

<para>
<!--
There are a number of different text editors available in *nix.  A few
are found on every system. That would be '/bin/ed' and '/bin/vi'. 'vi' is
almost always a clone such as 'vim' due to license problems. The problem with
'vi' and 'ed' is that they are terribly user unfriendly. Another common editor
that is not always installed by default is 'emacs'. It has a lot more features
and capability, and is not easy to learn either.
-->
  *nix では様々に異なったテキストエディタが使用可能です。
二、三のものは全てのシステムにあります。
'/bin/ed' と '/bin/vi' はそうでしょう。
'vi' はたいていの場合、ライセンスの問題によって 'vim'
のようなクローンになっています。
'vi' と 'ed' の問題点は、それらは恐ろしくユーザーに優しくない、
ということです。
また一つのよくみられるエディタは 'emacs' ですが、
常にデフォルトでインストールされているとは限りません。
これはより多くの機能と能力を持っていますが、
これも同様に学ぶのが易しくありません。
</para>

<para>
<!--
 As to 'user friendly' editors, 'mcedit' and 'pico' are good choices to start
 with. These are often much easier for those new to *nix. 
-->
  「ユーザに優しい」エディタとしては、
'mcedit' と 'pico' は始めるのに良い選択です。
これらはしばしば *nix に慣れていない人たちにとっては、
他のものよりずっと易しいものです。
</para>

<para>
<!--
 The first things to learn are how to exit an editing session, how to save
 changes to the file, and then how to avoid breaking long lines that should
 not be broken (wrapped). 
-->
  最初に学ぶべきことは、いかに編集のセッションを終了するか、
いかにファイルの変更を保存するか、
そして折り返すべきでない長い一行の折り返しを避けるにはどうするか
（ラップ、つまり行の折り返しの問題）でしょう。
</para>

<para>
<!--
The 'vi' editor
-->
'vi' エディタ
</para>

<para>
<!--
'vi' is one of the most common text editors in the Unix world, and it's
nearly always found on any *nix system. Actually, due to license problems,
the '/bin/vi' on a Linux system is always a 'clone', such as 'elvis',
'nvi', or 'vim' (there are others). These clones can act exactly like
the original 'vi', but usually have additional features that make it
slightly less impossible to use.
-->
  'vi' は Unix の世界では最も普通のテキストエディタの一つで、
ほとんど全ての *nix システム上に見られます。
実際は、ライセンスの問題によって、Linux システム上の'/bin/vi'
 は常に 'elvis' や  'nvi', 'vim' といった「クローン」です
（他にもあります）。これらのクローンはオリジナルの
'vi' とまったく同様にふるまいますが、
たいていの場合は追加機能があり、
使えなくもないようになっています。
</para>

<para>
<!--
So, if it's so terrible, why learn about it?  Two reasons. First, as
noted, it's almost guaranteed to be installed, and other (more user
friendly) editors may not be installed by default.  Second, many of the
'commands' work in other applications (such as the pager 'less' which is
also used to view man pages). In 'less', accidentally pressing the 'v' key
starts 'vi' in most installations.
-->
  'vi' がそんなに恐ろしい代物なら、
どうしてそれを学ぶ必要があるのでしょうか？
二つの理由があります。
まず第一に、前述のように、
それはほとんど確実にインストールされていることが保証されていて、
他の（もっとユーザに優しい）エディタはデフォルトでインストールされて
いるとは限らないからです。
第二の理由は、
その「コマンド」の多くが他のアプリケーションでも働くことです
（例えば man ページを見るためにも用いられている 'less' のような）。
'less' を使っているときに、うっかり 'v' のキーを押してしまうと、
ほとんどの実装では 'vi' がスタートしてしまいます。
</para>

<para>
<!--
'vi' has two modes.  The first is 'command mode', and keystrokes are
interpreted as commands. The other mode is 'insert' mode, where nearly all
keystrokes are interpreted as text to be inserted.
-->
  'vi' には二つのモードがあります。
一つは「コマンドモード」で、
キーボード入力はコマンドとして解釈されます。
もう一つのモードは「挿入モード」で、
ほとんど全てのキーボード入力は挿入するテキストとして解釈されます。
</para>

<para>
<!--
==> Emergency exit from 'vi'
1. press the &lt;esc&gt; key up to three times, until the computer beeps, or the
screen flashes.
2. press the keys :q! &lt;Enter&gt;
-->
  ==> 'vi' を強制終了する方法
1. コンピュータがビープ音を鳴らすか、
スクリーンがフラッシュするまで、
&lt;esc&gt; キーを三回押します。
2. :q! &lt;Enter&gt; とキー入力する。
</para>

<para>
<!--
 That is: colon, the letter Q, and then the exclamation point, followed by
 the Enter key.
-->
  つまり、コロン、文字の Q, そしてエクスクラメーションマーク、
最後にエンター（改行）キーです。
</para>

<para>
<!--
'vi' commands  are as follows. All of these are in 'command' mode:
-->
  'vi' コマンドは以下のようになっています。
これらは全て「コマンドモード」内で使います。
</para>

<Para>
 <Literal>
  <MSGText> 
   <LiteralLayout>
<!--
a    Enter insertion mode after the cursor.
A    Enter insertion mode at the end of the current line.
i    Enter insertion mode before the cursor.
o    Enter insertion mode opening a new line BELOW current line.
O    Enter insertion mode opening a new line ABOVE current line.
h    move cursor left one character.
l    move cursor right one character.
j    move cursor down one line.
k    move cursor up one line.
-->
a    カーソルの後から挿入モードに入る。
A    現在いる行の終わりで挿入モードに入る。
i    カーソルの前で挿入モードに入る。
o    現在いる行の「下に」新しい行を開き挿入モードに入る。
O    現在いる行の「上に」新しい行を開き挿入モードに入る。
h    カーソルを一文字分、左に移動する。
l    カーソルを一文字分、右に移動する。
j    カーソルを一行分、下に移動する。
k    カーソルを一行分、上に移動する。
<!--
/mumble  move cursor forward to next occurrence of 'mumble' in 
         the text
?mumble  move cursor backward to next occurrence of 'mumble' 
         in the text
n    repeat last search (? or / without 'mumble' to search for 
     will do the same thing)
u    undo last change made
-->
/ほにゃらら    そのテキストの前方で、次に文字列「ほにゃらら」が現れた箇所
               にカーソルを移動する。
?ほにゃらら    そのテキストをさかのぼって、次に文字列「ほにゃらら」が現れた箇所
               にカーソルを移動する。
n    前回のサーチを繰り返す（同じことをするのに「ほにゃらら」抜きで、
     ? または / ）。
u    最後に行った変更を取り消す。
<!--
^B   Scroll back one window.
^F   Scroll forward one window.
^U   Scroll up one half window.
^D   Scroll down one half window.
-->
^B    ウィンドウ一つ後ろにスクロール。
^F    ウィンドウ一つ前にスクロール。
^U    ウィンドウ半分スクロールアップ。
^D    ウィンドウ半分スクロールダウン。

<!--
:w   Write to file.
:wq  Write to file, and quit.
:q   quit.
:q!  Quit without saving.

&lt;esc&gt;   Leave insertion mode.
-->
:w    ファイルに保存。
:wq   ファイルに保存して、終了。
:q    終了。
:q!   保存せずに終了。

&lt;esc&gt;   挿入モードを終えてコマンドモードに。

    </LiteralLayout>
  </MSGText>
 </Literal>
</Para>

<para>
<!--
NOTE: The four 'arrow' keys almost always work in 'command' or 'insert'
mode.
-->
注意：四つの「矢印」キーは「コマンドモード」でも「挿入モード」
でもほとんど常に使えます。
</para>

<para>
<!--
The 'ed' editor.
-->
  'ed' エディタ
</para>

<para>
<!--
The 'ed' editor is a line editor. Other than the fact that it is virtually
guaranteed to be on any *nix computer, it has no socially redeeming
features, although some applications may need it. A _lot_ of things have
been offered to replace this 'thing' from 1975.
-->
  'ed' エディタはラインエディタです。
アプリケーションにはこれを必要とするものがあるとは言え、
全ての *nix コンピュータ上で使えることが仮想的に
保証されているという事実以上には、
これには社会的にはまったく値打ちのある機能がありません。
1975 年以来こいつを置き換えようとたくさん、
たくさんのものが提供されています。
</para>

<para>
<!--
==> Emergency exit from 'ed'
-->
    'ed' の強制終了
</para>

<para>
<!--
1. type a period on a line by itself, and press &lt;Enter&gt;   This gets you to
the command mode or prints a line of text if you were in command mode.
2.  type  q  and press &lt;Enter&gt;.  If there were no changes to the file,
this action quits ed. If you then see a '?' this means that the file had
changed, and 'ed' is asking if you want to save the changes. Press q and
&lt;Enter&gt; a second time to confirm that you want out.
-->
  1. それ自身で一行のピリオドをタイプし、
&lt;Enter&gt; を押す。
これでコマンドモードに入るか、
もしあなたが既にコマンドモードにいたとすれば一行のテキストを印字します。
2. q をタイプし、&lt;Enter&gt; を押す。
ファイルに何の変更もなかったなら、この動作で 'ed' を抜け出ます。
もし '?' と表示されたなら、これはファイルに変更があったことを意味し、
'ed' が変更を保存するかどうかあなたに尋ねているのです。
q を押して&lt;Enter&gt; として、
この二回目であなたが本当に終了したいということが確認されます。
</para>

<para>
<!--
The 'pico' editor.
-->
'pico' エディタ
</para>

<para>
<!--
'pico' is a part of the Pine mail/news package from the University of
Washington (state, USA). It is a very friendly editor, with one minor
failing. It silently inserts a line feed character and wraps the line when
it exceeds (generally) 74 characters.  While this is fine while creating
mail, news articles, and text notes, it is often fatal when editing system
files. The solution to this problem is simple. Call the program with the
-w  option, like this:
-->
  'pico' はワシントン大学（アメリカ合衆国）
で開発された Pine メイル/ニュース
パッケージに含まれています。
これは非常にユーザに優しいエディタですが、
一つ小さな短所があります。
'pico' は一行が（普通）74 文字を超えた時に、
黙って改行文字を挿入して行を折り返してしまいます。
これはメイルやニュース記事やメモをとる分には結構なことですが、
システムファイルを作る時にはしばしば致命的な問題になります。
この問題の解決策は簡単です。プログラムを呼び出すときに、
以下のように -w オプションをつけましょう：
</para>

<para>
pico -w file_2_edit
</para>

<para>
<!--
Pico is so user friendly, no further instructions are needed. It _should_
be obvious (look at the bottom of the screen for commands). There is an
extensive help function.  Pico is available with nearly all distributions,
although it _may_ not be installed by default.
-->
  'pico' はとてもユーザに優しいので、これ以上の説明は必要ありません。
それは実際、とても、簡単です（必要なコマンドはスクリーンの下にあります）。
さらなるヘルプ機能もあります。
'pico' はほとんど全てのディストリビューションで使用可能ですが、
デフォルトでインストールされていないかもしれません。
</para>

<para>
<!--
==> Emergency exit from 'pico'
-->
  ==> 'pico' の強制終了
</para>

<para>
<!--
Press and hold the &lt;Ctrl&gt; key, and press the letter x. If no changes
had been made to the file, this will quit pico. If changes had been made,
it will ask if you want to save the changes. Pressing n will then exit.
-->
  &lt;Ctrl&gt; キーを押しながら文字 x を押してください。
もしファイルに変更がされていないなら、これで 'pico' を終了します。
もし変更がされていれば、それを保存するかどうか訊ねられます。
n を押して終了してください。
</para>

<para>
<!--
The 'mcedit' editor.
-->
  'mcedit' エディタ
</para>

<para>
<!--
'mcedit' is part of the Midnight Commander shell program, a full featured
visual shell for Unix-like systems. It can be accessed directly from the
command line ( mcedit file_2_edit ) or as part of 'mc' (use the arrow keys
to highlight the file to be edited, then press the F4 key).
-->
  'mcedit' は Unix ライクなシステムのための完全な機能を持つ
ビジュアルシェルプログラム、Midnight Comander shell program
 に含まれています。
これはコマンドラインから直接アクセスできますし (mcedit file_2_edit),
また 'mc' の一部としても使えます
（矢印キーを使って編集するファイルを選択し、
F4 キーを押します）。
</para>

<para>
<!--
mcedit is probably the most intuitive editor available, and comes with
extensive help. "commands" are accessed through the F* keys. Midnight
Commander is available with nearly all distributions, although it _may_ not
be installed by default.
-->
  'mcedit' はおそらく最も直感的に使えるエディタで、
拡張ヘルプもついています。「コマンド」は F* キーで操作します。
Midnight Commander はほとんど全てのディストリビューションで使用可能ですが、
デフォルトでインストールされていないかもしれません。
</para>

<para>
<!--
==> Emergency exit from 'mcedit'
-->
  ==> 'mcedit' の強制終了
</para>

<para>
<!--
Press the F10 key. If no changes have been made to the file, this will
quit mcedit. If changes had been made, it will ask if you want to Cancel
this action. Pressing n   will then exit.
-->
  F10 キーを押します。ファイルに変更がなされていなければ、
これで 'mcedit' を終了します。もし変更がなされていれば、
この動作をキャンセルするかどうか訊ねてきます。
n を押して終了します。
</para>

</sect2>


<!--  ~  End section  ~  -->






<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="nmap">
<title>nmap</title>

<para>
<!--
 Let's look at a few quick examples of what <command>nmap</command> scans 
 look like. The intent here is to show how to use <command>nmap</command>
 to verify our firewalling, and system integrity. <command>nmap</command> 
 has other uses that we don't need to get into. Do NOT use 
 <command>nmap</command> on systems other than your own, unless you have 
 permission from the owner, and you know it is not a violation of anyone's
 Terms of Service. This kind of thing <emphasis>will</emphasis> be taken as
 hostile by most people.
-->
  <command>nmap</command> のスキャンがどのようなものか
二、三の簡単な例をみてみましょう。
ここでの目的は我々のファイアーウォールとシステムの完全さを
検証するためにどのように <command>nmap</command> を
使うかを紹介することです。
<command>nmap</command> には
我々に必要のないその他の使い方もあります。
あなたがその所有者から許可を得ていない限り、
あなた自身のものではないシステム上で <command>nmap</command> 
を絶対に使わないで下さい。
これは誰のサーヴィス契約の違反でもありませんが、
この種のことは、
ほとんどの人々には敵意があると取られるでしょう。
</para>

<para>
<!--
 As mentioned previously, <command>nmap</command> is a sophisticated 
 port scanning tool. It tries to see if a host is <quote>there</quote>, 
 and what ports might be open. Barring that, what states those ports 
 might be in. <command>nmap</command> has a complex command line and 
 can do many types of <quote>scans</quote>. See the man page for all 
 the nitty gritty.
-->
  既に見たように、<command>nmap</command> は洗練された
ポートスキャン用ツールです。それは、
ホストが<quote>そこに</quote>あるかどうか、
どのポートが開いてる可能性があるのかを調べようとします。
他には、それらのポートがどんな状態にあるのかも。
<command>nmap</command> は複雑なコマンドラインを持ち、
色々なタイプの<quote>スキャン</quote>が可能です。
詳細については man ページをみてください。
</para>

<para>
<!--
 A couple of words of warning first. If using
 <application>portsentry</application>, turn it off. It will drop the route
 to wherever the scan is coming from. You might want to turn off any logging
 also, or at least be aware that you might get copious logs if doing multiple
 scans.
-->
  まず二、三注意をしておきましょう。
もし <application>portsentry</application> を使っているなら、
それを停止してください。
これはスキャンがどこから来ようが、その向かう経路を落としてしまいます。
すべてのログ取得も停止しておいた方がよいかもしれません。
そうでなければ、少なくとも、多くのスキャンをするときには、
おびただしいログを受け取ることになることに気をつけてください。
</para>

<para>
<!--
 A simple, default scan of <quote>localhost</quote>:
-->
  単純な、<quote>ローカルホスト</quote>のデフォルトスキャン：
</para>

<para>
 <screen>

 # nmap localhost

 Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
 Interesting ports on bigcat (127.0.0.1):
 (The 1507 ports scanned but not shown below are in state: closed)

 Port       State       Service
 22/tcp     open        ssh                     
 25/tcp     open        smtp                    
 37/tcp     open        time                    
 53/tcp     open        domain                  
 80/tcp     open        http                    
 3000/tcp   open        ppp                     

 Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds

 </screen>
</para>

<para>
<!--
 If you've read most of this document, you should be familiar with 
 these services by now. These are some of the same ports we've seen in other
 examples. Some things to note on this scan: it only did 1500+
 <quote>interesting</quote>  ports &#045;&#045; not all ports. This can be configured
 differently if more is desirable (see man page). It only did TCP ports too.
 Again, configurable. It only picks up <quote>listening</quote> services,
 unlike <command>netstat</command> that shows all open ports &#045;&#045; listening or
 otherwise. Note the last <quote>open</quote> port here is 3000 is identified
 as <quote>PPP</quote>. Wrong! That is just an educated guess by nmap based on
 what is contained in <filename>/etc/services</filename> for this port number.
 Actually in this case it is <application>ntop</application> (a network
 traffic monitor). Take the service names with a grain of salt. There is no
 way for <command>nmap</command> to really know what is on that port. Matching
 port numbers with service names can at times be risky. Many do have standard
 ports, but there is nothing to say they have to use the commonly associated
 port numbers.  
-->
  この文書のほとんどに既に目を通している方には、
今やこれらのサーヴィスが見慣れたものになっていることでしょう。
これらの中には今までの他の例で見てきたものと同じポートがあります。
このスキャンで注意すべきことは、
スキャンは 1500 個強の<quote>興味ある</quote>ポート
に対し行われただけである（全てのポートに対してではない）ということです。
これ以上のスキャンがしたければ、そうした設定も可能です
（man ページを参照してください）。
それに、TCP ポートのみしかスキャンされていません。
これも望めば、それ以外のスキャンも設定可能です。
これは <command>netstat</command> が全ての開いたポートを、
耳をすませていようがいまいが表示するのとは異なって、
<quote>耳をすませている</quote>サーヴィスだけをピックアップします。
ここでの最後の 3000 番となっている<quote>開いた</quote>ポートは、
<quote>PPP</quote> であると認識されています。
間違いです！これはこのポート番号について <filename>/etc/services</filename> 
ファイルに含まれている情報に基づいて nmap が学習した結果の推測に
過ぎないからです。
実際、この場合それは
 <application>ntop</application> (network traffic monitor)です。
このようにサーヴィス名は多少割り引いて解釈してください。
<command>nmap</command> が本当にそのポートが何なのかを知る方法は
存在しないのです。
サーヴィス名にポート番号をマッチさせることは時に危険です。
多くは標準のポート番号を持っていますが、
同じポート番号を使うべきだということではありません。
</para>

<para>
<!--
 Notice that in all our <command>netstat</command> examples, we had two classes
 of open ports: listening servers, and then established connections that we
 initiated to other remote hosts (e.g. a web server somewhere).
 <command>nmap</command> only sees the first group &#045;&#045; the listening servers! 
 The other ports connecting us to remote servers are not visible, and thus 
 not vulnerable. These ports are <quote>private</quote> to that single 
 connection, and will be closed when the connection is terminated.
-->
  この文書の全ての <command>netstat</command> の例においては、
我々は開いたポートを二つのクラスに分けていました：
耳をすませているサーバと、我々が接続を希望した他のリモートホスト
（例えば、どこかにある web サーバ）と接続が確立しているものです。
<command>nmap</command> は最初のグループしか見ません、
つまり耳をすませているサーバだけです！
我々をリモートサーバに繋げているポートは不可視で、
ゆえに、危険ではないのです。
これらのポートはその接続一つについて<quote>プライベート</quote>
なものなので、接続が終了した時に閉じられます。
</para>

<para>
<!--
 So we have open and closed ports here. Simple enough, and gives a pretty good
 idea what is running on bigcat &#045;&#045; but not necessarily what we look like to
 the outside world since this was done from localhost, and wouldn't reflect 
 any firewalling or other access control mechanisms.
-->
  ですから、ここで開いたポートと閉じたポートを持っているわけです。
充分に単純で、何がこの bigcat 上で走っているかについて、
なかなか良い情報を与えてくれています。
しかし、それは必ずしもこのシステムが外部の世界からどう見えているかを
示しているわけではありません。と言うのも、
これはローカルホストからスキャンされていることであって、
何のファイアーウォールもまた他のアクセス制御の仕組みの影響も
受けていないからです。
</para>

<para>
<!--
 Let's do a little more intensive scan. Let's check all ports &#045;&#045; TCP and UDP.
-->
  もう少し強力なスキャンをしてみましょう。
今度は、全てのポート、TCP も UDP も、をチェックします。
</para>

<para>
 <screen>

 # nmap -sT -sU -p 1-65535 localhost

 Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
 Interesting ports on bigcat (127.0.0.1):
 (The 131050 ports scanned but not shown below are in state: closed)

 Port       State       Service
 22/tcp     open        ssh                     
 25/tcp     open        smtp                    
 37/tcp     open        time                    
 53/tcp     open        domain                  
 53/udp     open        domain                  
 80/tcp     open        http                    
 3000/tcp   open        ppp                     
 8000/tcp   open        unknown                 
 32768/udp  open        unknown                 

 Nmap run completed -- 1 IP address (1 host up) scanned in 385 seconds

 </screen>
</para>

<para>
<!--
 This is more than just <quote>interesting</quote> ports &#045;&#045; it is everything. 
 We picked up a couple of new ones in the process too. We've seen these before 
 with <command>netstat</command>, so we know what they are. That is the 
 <command>Junkbuster</command> web proxy on port 8000/tcp and
 <command>named</command> on 32768/udp. This scan takes much, much longer, but it 
 is the only way to see all ports.
-->
  今度はただ<quote>興味ある</quote>ポートだけではなく、
全てのポートを調べています。
このプロセスで新たに二つのものがピックアップされました。
我々は以前に既にこれらを <command>netstat</command> を用いて
見たので、我々はこれらが何であるかを知っています。
それは 8000/tcp ポート上の <command>Junkbuster</command>
 ウェブプロキシと、32768/udp ポート上の  <command>named</command> です。
これには前の場合よりもっと、もっと長い時間がかかりますが、
全てのポートを調べるための唯一の方法です。
</para>

<para>
<!--
 So now we have a pretty good idea of what is open on bigcat. Since 
 we are scanning localhost from localhost, everything should be visible. 
 We still don't know how the outside world sees us though. Now I'll
 <command>ssh</command> to another host on the same LAN, and try again.
-->
  これで bigcat の上でどのポートが開いているかについて
なかなか良い情報を得られました。
ここではローカルホストからローカルホストをスキャンしていますから、
全てのポートが可視です。
我々は依然として外の世界から我々がどう見えているのかはわかりません。
ここで、同じ LAN 内の他のホストに <command>ssh</command> 
接続してみて、またスキャンしてみます。
</para>

<para>
 <screen>

 # nmap bigcat

 Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
 Interesting ports on bigcat (192.168.1.1):
 (The 1520 ports scanned but not shown below are in state: closed)

 Port       State       Service
 22/tcp     open        ssh
 3000/tcp   open        ppp

 Nmap run completed -- 1 IP address (1 host up) scanned in 1 second

 </screen>
</para>

<para>
<!--
 I confess to tampering with the <application>iptables</application> rules 
 here to make a point. Only two visible ports on this scan. Everything 
 else is <quote>closed</quote>. So says <application>nmap</application>. 
 Once again:
-->
  ここでは強調のために <application>iptables</application> 
のルールに手を加えていることを白状します。
このスキャンではただ二つのポートが見えています。
他の全ては<quote>閉じて(closed)</quote>います。
これが <application>nmap</application> の報告でした。
もう一度やってみましょう：
</para>

<para>
 <screen>

 # nmap bigcat

 Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
 Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
 
 Nmap run completed -- 1 IP address (0 hosts up) scanned in 30 seconds

 </screen>
</para>

<para>
<!--
Oops, I blocked ICMP (ping) while I was at it this time. One more time: 
-->
  おっと、今度は私が仕事をしている間に、
ICMP (ping) をブロックしてしまったようです。
もう一回：
</para>

<para>
 <screen>

 # nmap -P0 bigcat

 Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
 All 1523 scanned ports on bigcat (192.168.1.1) are: filtered
 
 Nmap run completed -- 1 IP address (1 host up) scanned in 1643 seconds

 </screen>
</para>

<para>
<!--
 That's it. Notice how long that took. Notice ports are now
 <quote>filtered</quote> instead of <quote>closed</quote>. How does
 <command>nmap</command> know that? Well for one, <quote>closed</quote> means
 bigcat sent a packet back saying <quote>nothing running here</quote>, i.e.
 port is closed. In this last example, the <application>iptables</application>
 rules were changed to not allow ICMP (ping), and to <quote>DROP</quote> all
 incoming packets. In other words, no response at all. A subtle difference
 since <command>nmap</command> seems to still know there was a host there,
 even though no response was given. One lesson here, is if you want to slow a
 scanner down, <quote>DROP</quote> (or <quote>DENY</quote>) the packets. This
 forces a TCP time out for the remote end on each port probe. Anyway, if your
 scans look like this, that is probably as well as can be expected, and your 
 firewall is doing its job.
-->
  これです。いかに長い時間がかかっているかに注意してください。
ポートは今、<quote>閉じて</quote>いる代わりに、
<quote>フィルター</quote>をかけられていることに注意してください。
<quote>nmap</quote> はどうやってこれを知るのでしょう？
<quote>閉じている(closed)</quote>という言葉が意味するのは
bigcat が<quote>ここには何も走っていませんよ</quote>、
とパケットを送り返してきた、ということで、
つまり、ポートが閉ざされている、ということになります。
この最後の例では、<application>iptables</application> の規則は
ICMP (ping) を許可せず、全ての入ってくるパケットを
<quote>落とす(DROP)</quote>ように変更されていました。
言い換えれば、まったく何の返事もありません。
たとえ何の返事もないとしても、
<command>nmap</command> は依然としてホストがそこにあることは知っている
のですから、ここには微妙な差があります。
ここでの一つの教訓は、もしあなたがスキャンを遅くさせたいなら、
パケットを<quote>DROP</quote> (または <quote>DENY</quote>)
すればよいと言うことです。 
これによって、各ポートの検証において、
リモート接続が TCP タイムアウトすることになります。
結局、スキャンがこのような結果を示しているなら、
うまく期待通りの動作をしている、つまり、
あなたのファイアーウォールが自分の仕事を果たしているのです。
</para>

<para>
<!--
 A brief note on UDP: <command>nmap</command> can not accurately determine 
 the status of these ports if they are <quote>filtered</quote>. You probably
 will get a false-positive <quote>open</quote> condition. This has to do with
 UDP being a connectionless protocol. If <command>nmap</command> gets no 
 answer (e.g. due to a <quote>DROP</quote>), it assumes the packets reached
 the target, and thus the port will be reported as <quote>open</quote>. 
 This is <quote>normal</quote> for <command>nmap</command>.
-->
  UDP についての短い注意：
<command>nmap</command> は実際には、
もしフィルターされていれば、
これらのポートの状態を判定することはできません。
この場合おそらく、<quote>開いた</quote>状態であるという
間違った情報を受け取るでしょう。
これは UDP が接続のないプロトコルであることに関係しています。
もし <command>nmap</command> が何の返答も得なければ
（例えば、 <quote>DROP</quote> のために）、
パケットが目標に届いたのだと仮定して、
その結果そのポートは<quote>開いている</quote>と報告するでしょう。
これは <command>nmap</command> としては<quote>正常な</quote>動きです。
</para>

<para>
<!--
 We can play with firewall rules in a LAN set up to try to simulate how the 
 outside world sees us, and if we are smart, and know what we are doing, 
 and don't have a brain fart, we probably will have a pretty good picture. But
 it is still best to try to find a way to do it from outside if possible.
 Again, make sure you are not violating any ISP rules of conduct. Do you have
 a friend on the same ISP? 
-->
  外部の世界からシステムがどう見えているかをシミュレートするために、
LAN の設定でファイアーウォールをいじってみることができます。
もしあなたが充分賢くて、自分が何をしているかをちゃんとわかっていて、
とんだへまをしでかさなければ、
おそらくシステムの状態をかなり想像できるでしょう。
しかしやはり、もし可能なら実際に外部からチェックをしてもらう方法を
探すのがベストの方法ではあります。
この場合もプロバイダの運用ルールを破っていないことを確認してください。
同じプロバイダを使っている友達がいますか？
</para>

</sect2>

<!--  ~  End section  ~  -->




<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="sysctl">
<title><!--Sysctl Options-->Sysctl のオプション</title>

<para>
<!--
 The <quote>sysctl</quote> options are kernel parameters that can be
 configured via the <filename>/proc</filename> filesystem. These can 
 be dynamically adjusted at run-time. Typically these options are off 
 if set to <quote>0</quote>, and on if set to <quote>1</quote>.
-->
  <quote>sysctl</quote> のオプションは <filename>/proc</filename> 
 ファイルシステムを通して設定できるカーネルパラメータです。
これらはランタイム時に動的に調整することができます。
典型的にはこれらのオプションは
<quote>0</quote> にセットされていればオフで、
<quote>1</quote> のときはオンです。
</para>

<para>
<!--
 Some of these have security implications, and thus is why we are here ;-) 
 We'll just list the ones we think are relevant. Feel free to cut and 
 paste these into a firewall script, or other file that is run during boot
 (like <filename>/etc/rc.local</filename>). <![%linuxall;[ Or your
 distribution may have their own way of tuning this. ]]> 
 <![%redhat;[ Red Hat provides the <command>sysctl</command> command for
 dynamically adjusting these values (see man page). Or they can permanently be
 set in <filename>/etc/sysctl.conf</filename> with your text editor of choice.
 <command>sysctl</command> is executed during init, and uses these values.]]>
 You can read up on what these mean in
 <filename>/usr/src/linux/Documentation/sysctl/README</filename> and other
 files in the kernel Documentation directories.
-->
  これらのいくつかはセキュリティ実装を持ってます
（だからこのテーマを今あつかっているわけですが ;-)）。
ここでは関連性があると思われるものをリストアップするだけにします。
自由にカットアンドペーストして、
ファイアーウォールのスクリプトや、
ブート時に起動される他のファイル（<filename>/etc/rc.local</filename>
 のような）に使ってください。
<![%linuxall;[または、各ディストリビューションが
これを設定する独自の方法を用意しているかもしれません。]]>
<![%redhat;[Red Hat では動的にこれらの値を調整するための
 <command>sysctl</command> コマンドが用意されています
（man ページを参照してください）。
また、自分の好きなテキストエディタを使って、
<filename>/etc/sysctl.conf</filename> で永続的に
設定することもできます。
<command>sysctl</command> コマンドは init 時に実行され、
これらの値を使用します。]]>
これらの意味については
 <filename>/usr/src/linux/Documentation/sysctl/README</filename> 
ファイルとカーネル文書ディレクトリのその他のファイルを
読めば知ることができます。

<!--
# ???????
net.ipv4.tcp_rfc1337 = 1
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
-->

</para>

<![%redhat;[ 
<para>
<!--
 The traditional method:
-->
  伝統的な方法：
</para>
]]>

<para>
 <programlisting>

#!/bin/sh
# 
# Configure kernel sysctl run-time options. 
# kernel sysctl ランタイムオプション設定
###################################################################

# Anti-spoofing blocks
# アンチ・スプーフィングがブロック
for i in /proc/sys/net/ipv4/conf/*/rp_filter; 
do
 echo 1 > $i
done

# Ensure source routing is OFF
# ソースルーティングをオフに
for i in /proc/sys/net/ipv4/conf/*/accept_source_route;
 do
  echo 0 > $i
 done

# Ensure TCP SYN cookies protection is enabled
# TCP SYN クッキープロテクションを可能に
[ -e /proc/sys/net/ipv4/tcp_syncookies ] &&\
 echo 1 > /proc/sys/net/ipv4/tcp_syncookies 

# Ensure ICMP redirects are disabled
# ICMP リダイレクトを不可能に
for i in /proc/sys/net/ipv4/conf/*/accept_redirects; 
 do
  echo 0 > $i
 done

# Ensure oddball addresses are logged
# おかしなアドレスはログを取る
[ -e /proc/sys/net/ipv4/conf/all/log_martians ] &&\
 echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

[ -e /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts ] &&\
 echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

[ -e /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ] &&\
 echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

## Optional from here on down, depending on your situation. ############
# ここから下はシステムに応じたオプション。
#
# Ensure ip-forwarding is enabled if
# we want to do forwarding or masquerading.
# フォワーディングかマスカレーディングをするなら ip-forwarding を可能に。
[ -e /proc/sys/net/ipv4/ip_forward ] &&\
 echo 1 > /proc/sys/net/ipv4/ip_forward

# On if your IP is dynamic (or you don't know).
# IP が動的である（またはどうか知らない）時はオン。
[ -e /proc/sys/net/ipv4/ip_dynaddr ] &&\
 echo 1 > /proc/sys/net/ipv4/ip_dynaddr        

# eof

 </programlisting>
</para>

<![%redhat;[ 
<para>
<!--
 The same effect by using <filename>/etc/sysctl.conf</filename> instead:
-->
  代わりに <filename>/etc/sysctl.conf</filename> を用いても
同じ効果が得られます：
</para>

<para>
 <programlisting>

# 
# Add to existing sysctl.conf
# 既にある sysctl.conf に追加

# Anti-spoofing blocks
# アンチ・スプーフィングがブロック
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

# Ensure source routing is OFF
# ソースルーティングをオフに
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_source_route = 0

# Ensure TCP SYN cookies protection is enabled
# TCP SYN クッキープロテクションを可能に
net.ipv4.tcp_syncookies = 1

# Ensure ICMP redirects are disabled
# ICMP リダイレクトを不可能に
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.accept_redirects = 0

# Ensure oddball addresses are logged
# おかしなアドレスはログをとる
net.ipv4.conf.default.log_martians = 1
net.ipv4.conf.all.log_martians = 1


net.ipv4.icmp_echo_ignore_broadcasts = 1

net.ipv4.icmp_ignore_bogus_error_responses = 1

## Optional from here on down, depending on your situation. ############
## ここから下はシステムに応じたオプション
#
# Ensure ip-forwarding is enabled if
# we want to do forwarding or masquerading.
# フォワーディングかマスカレーディングをするなら ip-forwarding を可能に。
net.ipv4.ip_forward = 1

# On if your IP is dynamic (or you don't know).
# IP が動的なら（またはどうか知らないなら）オンに。
net.ipv4.ip_dynaddr = 1

# end of example

 </programlisting>
</para>
]]>

</sect2>

<!--  ~  End section  ~  -->




<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="securealt">
<title><!--Secure Alternatives-->セキュアな代替物</title>

<para>
<!--
 This section will give a brief run down on secure alternatives to 
 potentially insecure methods. This will be a hodge podge of clients 
 and servers. 
-->
  この章では潜在的にセキュアでない方法に対して、
安全な代替物を手短に紹介します。
クライアントとサーバ両方のごたまぜになっています。
</para>

<para>
 <itemizedlist>

 <listitem>
  <para>  
<!--
   telnet, rsh - ssh
-->
  telnet, rsh は ssh に。
  </para>
 </listitem>

 <listitem>
  <para>
<!--
   ftp, rcp - scp or sftp. Both are part of ssh packages. Also, files 
   can easily be transfered via HTTP if Apache is already running 
   anyway. Apache can be buttoned down even more by using SSL (HTTPS). 
-->
  ftp, rcp は scp または sftp に。
両方とも ssh パッケージに含まれています。
また、もし Apache が既に走っていれば、
HTTP 経由でファイルは簡単に転送できます。
Apache は SSL (HTTPS) を用いることでさらにしっかりと鍵をかけられます。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
   sendmail - postfix, qmail. Not to imply that current versions of 
   <application>sendmail</application> are insecure. Just that there 
   is some bad history there, and just because it is so widely used 
   that it makes an inviting crack target.
-->
  sendmail は postfix, qmail に。
<application>sendmail</application> の新しいバージョンらが
安全でないと言っているわけではありません。
ただ単に、これには今までの酷い歴史があり、
あまりに広く用いられているので、
クラッカーを呼び寄せがちだということです。
  </para>

  <para>
<!--
   As noted above, Linux installations often include a fully functional 
   mail server. While this may have some advantages, it is not necessary 
   in many cases for simply sending mail, or retrieving mail. This can all 
   be done without a <quote>mail server daemon</quote> running locally.
-->
  上で述べたように、Linux インストールはしばしば
完全な機能のメイルサーバを含んでいます。
これには有利な点がいくつかありますが、
単純にメイルを送ったり取って来るだけの多くの場合には不必要です。
これは全て<quote>メイルサーバデーモン</quote>が
ローカルで走っていなくても可能なことです。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
    POP3 - SPOP3, POP3 over SSL. If you really need to run your own 
    POP server, this is the way to do it. If retrieving your mail from 
    your ISP's server, then you are at their mercy as to what they provide.
-->
  POP3 は SPOP3, SSL 経由の POP3 に。
もし本当にあなた自身の POP サーバを運用する必要があるのならば、
これがその正しい方法です。
プロバイダのサーバからあなたのメイルを取ってくる場合は、
プロバイダが提供するものに従わざるを得ません。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
    IMAP - IMAPS, same as above. 
-->
  IMAP を IMAPS に。上に同じ。
  </para>
 </listitem> 

 <listitem>
  <para>
<!--
    If you find you need a particular service, and it is for just you or a few
    friends, consider running it on a non-standard port. Most server daemons 
    support this, and is not a problem as long as those who will be
    connecting, know about it. For instance, the standard port for
    <command>sshd</command> is 22. Any worm or scan will probe for this port
    number. So run it on a randomly chosen port. See the <command>sshd</command>
    man page.
-->
  特定のサーヴィスが必要で、それが自分自身だけ、
または少数の友人だけの場合には、
それをその標準でないポートで走らせることを考えましょう。
ほとんどのサーバデーモンでこれが可能ですし、
接続する人たちがそれを知っている限り問題はありません。
例えば、<command>sshd</command> の標準ポート番号は 22 番です。
どのワームやスキャンもこのポート番号をプローブするでしょう。
ですから、これをランダムに選んだポート番号で走らせるのです。
詳しくは <command>sshd</command> の man ページを参照してください。
  </para>
 </listitem> 


 </itemizedlist>
</para>



<!--

<simplelist>
 <member>
  
 </member>
</simplelist>

-->
</sect2>


<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect2 id="pfilters">
<title><!--Ipchains and Iptables Redux-->ipchains と iptables 再び</title>

<para>
<!--
 This section offers a little more advanced look at some of things that 
 <application>ipchains</application> and <application>iptables</application>
 can do. These are basically the same scripts as in Step 3 above, just 
 with some more advanced configuration options added. These will provide
 <quote>masquerading</quote>, <quote>port forwarding</quote>, allow access to
 some user definable services, and a few other things. Read the comments for
 explanations.
-->
  この章では <application>ipchains</application> と
 <application>iptables</application> にできることの
いくつかをもう少し詳しく見てみます。
これらは基本的には上のステップ３で見たものと同じスクリプトですが、
いくらかさらに進んだ設定オプションが追加されています。
<quote>マスカレーディング</quote>、
<quote>ポートフォワーディング</quote>、
あるユーザに限定したサーヴィスへのアクセス許可、
そのほか二、三の機能が提供されています。
それらの説明についてはコメント文を読んでください。
</para>


<!--   ~~~~~       New section      ~~~~~     -->

<sect3>
<title>ipchains II</title>

<para>
 <programlisting>

#!/bin/sh
#
# ipchains.sh
#
# An example of a simple ipchains configuration. This script 
# can enable 'masquerading' and will open user definable ports.
# 単純な ipchains 設定の例。このスクリプトは「マスカレーディング」
# が可能で、ユーザ定義ポートを開く。
###################################################################
# Begin variable declarations and user configuration options ######
# 変数宣言とユーザ設定オプション
# Set the location of ipchains (default).
# ipchains （デフォルト）の場所を設定。
IPCHAINS=/sbin/ipchains

# Local Interfaces
# ローカルインターフェース
# This is the WAN interface, that is our link to the outside world.
# これは WAN インターフェース、外の世界に我々をつなげる。
# For pppd and pppoe users.
# pppd と pppoe ユーザのため。
# WAN_IFACE="ppp0"
WAN_IFACE="eth0"
#
# Local Area Network (LAN) interface.
# ローカルエリアネットワーク(LAN)インターフェース
#LAN_IFACE="eth0"
LAN_IFACE="eth1"

# Our private LAN address(es), for masquerading.
# 我々のプライベート LAN アドレス（たち）、マスカレーディングのための。
LAN_NET="192.168.1.0/24"

# For static IP, set it here! 
# スタティック IP のため。ここで設定せよ！
#WAN_IP="1.2.3.4"

# Set a list of public server port numbers here...not too many!
# These will be open to the world, so use caution. The example is
# sshd, and HTTP (www). Any services included here should be the
# latest version available from your vendor. Comment out to disable
# all PUBLIC services.
# ここでパブリックサーバのポート番号のリストを設定。多すぎないように！
# これらは世界に向けて開かれるので、要注意。この例は sshd, HTTP(www).
# ここのどのサーヴィスもヴェンダの最新バージョンにすべき。
# 全てのパブリックサーヴィスを不可能にするためにはコメントアウトせよ。
#PUBLIC_PORTS="22 80 443"
PUBLIC_PORTS="22"

# If we want to do port forwarding, this is the host 
# that will be forwarded to.
# もしポートフォワーディングしたいなら、これがフォワードされる先のホスト
#FORWARD_HOST="192.168.1.3"

# A list of ports that are to be forwarded. 
# フォワードされるべきポートのリスト
#FORWARD_PORTS="25  80"

# If you get your public IP address via DHCP, set this.
# もし DHCP を通じてパブリックな IP アドレスを設定するなら、ここで。
DHCP_SERVER=66.21.184.66

# If you need identd for a mail server, set this.
# メイルサーバのために identd が必要ならここで。
MAIL_SERVER=

# A list of unwelcome hosts or nets. These will be denied access 
# to everything, even our 'PUBLIC' services. Provide your own list.
# 望まぬ客のホストとネットのリスト。これらは全てへのアクセス、
# 我々のパブリックサーヴィスさえも、拒否される
# 自分自身のリストを用意せよ。
#BLACKLIST="11.22.33.44 55.66.77.88"

# A list of "trusted" hosts and/or nets. These will have access to 
# ALL protocols, and ALL open ports. Be selective here.
# 「信用できる」ホストと/またはネットのリスト。これらは全ての
# プロトコルと全ての開いたポートにアクセスできる。
# これは精選して。
#TRUSTED="1.2.3.4/8  5.6.7.8"

## end user configuration options #################################
## エンドユーザ設定オプション
###################################################################

# The high ports used mostly for connections we initiate and return
# traffic.
# トラフィックを初期化、返信のための接続に主に用いられる
# 高番号ポート。
LOCAL_PORTS=`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f1`:\
`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f2`

# Any and all addresses from anywhere.
# 任意の場所からの全てのアドレス
ANYWHERE="0/0"

# Start building chains and rules #################################
# チェインと規則の設定の始まり
# Let's start clean and flush all chains to an empty state.
# まず全てのチェインを空の状態に。
$IPCHAINS -F  

# Set the default policies of the built-in chains. If no match for any 
# of the rules below, these will be the defaults that ipchains uses.
# 組み込みのチェインのデフォルトポリシーを設定。以下のルールのどれにも
# 一致しなければ、これらが ipchains の使うデフォルトになる。
$IPCHAINS -P forward DENY
$IPCHAINS -P output ACCEPT
$IPCHAINS -P input DENY 

# Accept localhost/loopback traffic.
# localhost/loopback トラフィックを受け入れる。
$IPCHAINS -A input -i lo -j ACCEPT

# Get our dynamic IP now from the Inet interface. WAN_IP will be our
# IP address we are protecting from the outside world. Put this
# here, so default policy gets set, even if interface is not up
# yet.
# ここで Inet インターフェースから我々のダイナミック IP を取得。
# WAN_IP は外の世界から我々が守る IP アドレスになる。
# インターフェースがまだ立ち上がっていなくても、ここにおいているので、
# デフォルトのポリシーが準備される。
[ -z "$WAN_IP" ] &&\
  WAN_IP=`ifconfig $WAN_IFACE |grep inet |cut -d : -f 2 |cut -d \  -f 1`

# Bail out with error message if no IP available! Default policy is 
# already set, so all is not lost here.
# どの IP も可能でないならエラーメッセージとともに抜け出る。
# デフォルトポリシーは既に設定されているので、すべてがここで
# 失われるわけではない。
[ -z "$WAN_IP" ] && echo "$WAN_IFACE not configured, aborting." && exit 1

WAN_MASK=`ifconfig $WAN_IFACE | grep Mask | cut -d : -f 4`
WAN_NET="$WAN_IP/$WAN_MASK"

## Reserved IPs:
#　予約 IP:
# We should never see these private addresses coming in from outside 
# to our external interface.
# 外部から我々の外部インターフェースへ、これらのプライベートアドレスが
# 入ってくることは決してあるべきではない。
$IPCHAINS -A input -l -i $WAN_IFACE -s 10.0.0.0/8     -j DENY
$IPCHAINS -A input -l -i $WAN_IFACE -s 172.16.0.0/12  -j DENY
$IPCHAINS -A input -l -i $WAN_IFACE -s 192.168.0.0/16 -j DENY
$IPCHAINS -A input -l -i $WAN_IFACE -s 127.0.0.0/8    -j DENY
$IPCHAINS -A input -l -i $WAN_IFACE -s 169.254.0.0/16 -j DENY
$IPCHAINS -A input -l -i $WAN_IFACE -s 224.0.0.0/4    -j DENY
$IPCHAINS -A input -l -i $WAN_IFACE -s 240.0.0.0/5    -j DENY
# Bogus routing
# 偽もののルーティング
$IPCHAINS -A input -l -s 255.255.255.255 -d $ANYWHERE -j DENY

## LAN access and masquerading
# LAN アクセスとマスカレーディング
#
# Allow connections from our own LAN's private IP addresses via the LAN
# interface and set up forwarding for masqueraders if we have a LAN_NET
# defined above. 
# LAN インターフェスを通じての、我々自身の LAN のプライベート IP アドレス
# からの接続を許可し、上で LAN_NET が定義されていればマスカレーダーの
# フォワーディングを設定する。
if [ -n "$LAN_NET" ]; then 
 echo 1 > /proc/sys/net/ipv4/ip_forward
 $IPCHAINS -A input  -i $LAN_IFACE  -j ACCEPT
 $IPCHAINS -A forward -s $LAN_NET -d $LAN_NET -j ACCEPT
 $IPCHAINS -A forward  -s $LAN_NET -d ! $LAN_NET -j MASQ
fi

## Blacklist hosts/nets
# ブラックリスト hosts/nets
#
# Get the blacklisted hosts/nets out of the way, before we start opening 
# up any services. These will have no access to us at all, and will be
# logged.
# ブラックリストにのったホスト/ネットを、どのサーヴィスも開かれ
# る前に閉め出す。これらはまったく我々にアクセスを持たず、
# ログをとられる。
for i in $BLACKLIST; do
 $IPCHAINS -A input -l -s $i -j DENY
done

## Trusted hosts/nets
# 信用できるホスト/ネット
#
# This is our trusted host list. These have access to everything.
# 信用するホストのリスト。これらは全てへのアクセス権を持つ。
for i in $TRUSTED; do
 $IPCHAINS -A input -s $i -j ACCEPT
done

# Port Forwarding
# ポートフォワーディング
#
# Which ports get forwarded to which host. This is one to one 
# port mapping (ie 80 -> 80) in this case.
# NOTE: ipmasqadm is a separate package from ipchains and needs 
# to be installed also. Check first!
# どのポートがどのホストへフォワードされるか。これはこの場合
# 一対一のマッピング（つまり、80 から 80 へ）。
# 注意： ipmasqadm は ipchains とは別のパッケージで、これも
# インストールする必要がある。まずチェックすること。
[ -n "$FORWARD_HOST" ] && ipmasqadm portfw -f &&\
 for i in $FORWARD_PORTS; do
   ipmasqadm portfw -a -P tcp -L $WAN_IP $i -R $FORWARD_HOST $i
 done

## Open, but Restricted Access ports/services
# 開いた、しかし制限されたアクセスのポート/サーヴィス
#
# Allow DHCP server (their port 67) to client (to our port 68) UDP traffic
# from outside source.
# 外部ソースからクライアントの（我々の68番ポートへの）UDP トラフィック
# へ　DHCP サーバ（67番ポート）を許可する。
[ -n "$DHCP_SERVER" ] &&\
 $IPCHAINS -A input -p udp -s $DHCP_SERVER 67 -d $ANYWHERE 68 -j ACCEPT 

# Allow 'identd' (to our TCP port 113) from mail server only.
# メイルサーバのみから（我々の TCP 113 番ポートへの）'identd' を許可
[ -n "$MAIL_SERVER" ] &&\
 $IPCHAINS -A input -p tcp -s $MAIL_SERVER  -d $WAN_IP 113 -j ACCEPT 

# Open up PUBLIC server ports here (available to the world):
# ここで PUBLIC サーバポートを開く（世界へ繋げるため）：
for i in $PUBLIC_PORTS; do
 $IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $i -j ACCEPT 
done

# So I can check my home POP3 mailbox from work. Also, so I can ssh 
# in to home system. Only allow connections from my workplace's
# various IPs. Everything else is blocked.
# こうしておけば仕事場から自宅の POP3 メイルボックスをチェックできる。
# また、自宅システムへ ssh で入ることもできる。仕事場のさまざまな
# IP アドレスからの接続を許可するだけ。他は全てブロックされる。
$IPCHAINS -A input -p tcp -s 255.10.9.8/29 -d $WAN_IP 110 -j ACCEPT 

# Uncomment to allow ftp data back (active ftp). Not required for 'passive'
# ftp connections.
# ftp データバック（アクティブ ftp）を許可するときはコメントアウトを外す。
# パッシブ ftp 接続については必要ない。
#$IPCHAINS -A input -p tcp -s $ANYWHERE 20 -d $WAN_IP $LOCAL_PORTS -y -j ACCEPT

# Accept non-SYN TCP, and UDP connections to LOCAL_PORTS. These are
# the high, unprivileged ports (1024 to 4999 by default). This will
# allow return connection traffic for connections that we initiate
# to outside sources. TCP connections are opened with 'SYN' packets.
# We have already opened those services that need to accept SYNs
# for, so other SYNs are excluded here for everything else.
# LOCAL_PORTS への非 SYN TCP と UDP 接続を受け入れる。これらは
# 番号の高い非特権ポート（デフォルトでは 1024 から 4999番）。
# これは外部のソースへ初期化する接続のための返信接続トラフィックを
# 許可する。TCP 接続は 'SYN' パケットとともに開かれている。
# SYN を受け入れる必要のあるそれらのサーヴィスは既に開いているので、
# 他の SYN はそれ以外の全てについてここで拒絶する。
$IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS ! -y -j ACCEPT 

# We can't be so selective with UDP since that protocol does not know 
# about SYNs.
# UDP は SYN について知らないので、それほど選択的にできない。
$IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS -j ACCEPT 

# Allow access to the masquerading ports conditionally. Masquerading
# uses it's own port range -- on 2.2 kernels ONLY! 2.4 kernels, do not 
# use these ports, so comment out!
# 場合によってはマスカレードしているポートへの接続を許可する。
# マスカレーディングは自身のポート範囲を用いる（2.2 カーネルのみで！）。
# 2.4 カーネルはこれらのポートを使わないので、コメントアウトするように！
[ -n "$LAN_NET" ] &&\
 $IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP 61000: ! -y -j ACCEPT &&\
 $IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP 61000: -j ACCEPT

## ICMP (ping)
#
# ICMP rules, allow the bare essential types of ICMP only. Ping
# request is blocked, ie we won't respond to someone else's pings,
# but can still ping out. 
# ICMP の規則、ICMP のむき出しの本質的なタイプだけを許可。
# Ping 要求はブロックされる。つまり、他の誰かの ping には答えないが、
# 自分は ping out することができる。
$IPCHAINS -A input  -p icmp  --icmp-type echo-reply \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPCHAINS -A input  -p icmp  --icmp-type destination-unreachable \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPCHAINS -A input  -p icmp  --icmp-type time-exceeded \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT

#######################################################################
# Set the catchall, default rule to DENY, and log it all. All other
# traffic not allowed by the rules above, winds up here, where it is
# blocked and logged. This is the default policy for this chain
# anyway, so we are just adding the logging ability here with '-l'.
# Outgoing traffic is allowed as the default policy for the 'output'
# chain. There are no restrictions on that.
# なんでも箱をおき（デフォルトルールは DENY）、その全てのログをとる。
# 上のルールで許可されていない他の全てのトラフィックを、ここで
# 始末をつけ、ブロックしログをとる。これはこのチェインについての
# デフォルトのポリシーだから、ここでは '-l' でログ能力を追加するのみ。
# 外に向かうトラフィックは 'output' チェインについてのデフォルト
# ポリシーとして許可されている。これについては何の制限もおかない。
$IPCHAINS -A input -l -j DENY

echo "Ipchains firewall is up `date`."

##-- eof ipchains.sh

 </programlisting>
</para>

</sect3>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect3>
<title>iptables II</title>

<para>
 <programlisting>

#!/bin/sh
#
# iptables.sh
#
# An example of a simple iptables configuration. This script 
# can enable 'masquerading' and will open user definable ports.
# 単純な ipchains 設定の例。このスクリプトは「マスカレーディング」
# が可能で、ユーザ定義ポートを開く。
###################################################################
# Begin variable declarations and user configuration options ######
#  変数宣言とユーザ設定オプション
# Set the location of iptables (default).
# ipchains （デフォルト）の場所を設定。
IPTABLES=/sbin/iptables

# Local Interfaces
# ローカルインターフェース
# This is the WAN interface that is our link to the outside world.
# これは WAN インターフェース、外の世界に我々をつなげる。
# For pppd and pppoe users.
# pppd と pppoe ユーザのため。

# WAN_IFACE="ppp0"
WAN_IFACE="eth0"
#
# Local Area Network (LAN) interface.
# ローカルエリアネットワーク(LAN)インターフェース
#LAN_IFACE="eth0"
LAN_IFACE="eth1"

# Our private LAN address(es), for masquerading.
# 我々のプライベート LAN アドレス（たち）、マスカレーディングのための。
LAN_NET="192.168.1.0/24"

# For static IP, set it here! 
# スタティック IP のため。ここで設定せよ！
#WAN_IP="1.2.3.4"

# Set a list of public server port numbers here...not too many!
# These will be open to the world, so use caution. The example is
# sshd, and HTTP (www). Any services included here should be the
# latest version available from your vendor. Comment out to disable
# all Public services. Do not put any ports to be forwarded here,
# this only direct access.
# ここでパブリックサーバのポート番号のリストを設定。多すぎないように！
# これらは世界に向けて開かれるので、要注意。この例は sshd, HTTP(www).
# ここのどのサーヴィスもヴェンダの最新バージョンにすべき。
# 全てのパブリックサーヴィスを不可能にするためにはコメントアウトせよ。
# フォワードされるポートはどれもここにおかないこと、これは直接の
# アクセスのみ。
#PUBLIC_PORTS="22 80 443"
PUBLIC_PORTS="22"

# If we want to do port forwarding, this is the host 
# that will be forwarded to.
# もしポートフォワーディングしたいなら、これがフォワードされる先のホスト。
#FORWARD_HOST="192.168.1.3"

# A list of ports that are to be forwarded. 
# フォワードされるべきポートのリスト
#FORWARD_PORTS="25  80"

# If you get your public IP address via DHCP, set this.
# もし DHCP を通じてパブリックな IP アドレスを設定するなら、ここで。
DHCP_SERVER=66.21.184.66

# If you need identd for a mail server, set this.
# メイルサーバのために identd が必要ならここで。
MAIL_SERVER=

# A list of unwelcome hosts or nets. These will be denied access 
# to everything, even our 'Public' services. Provide your own list.
# 望まぬ客のホストとネットのリスト。これらは全てへのアクセス、
# 我々のパブリックサーヴィスさえも、拒否される
# 自分自身のリストを用意せよ。
#BLACKLIST="11.22.33.44 55.66.77.88"

# A list of "trusted" hosts and/or nets. These will have access to 
# ALL protocols, and ALL open ports. Be selective here.
# 「信用できる」ホストと/またはネットのリスト。これらは全ての
# プロトコルと全ての開いたポートにアクセスできる。
# これは精選して。
#TRUSTED="1.2.3.4/8  5.6.7.8"

## end user configuration options #################################
## エンドユーザ設定オプション
###################################################################

# Any and all addresses from anywhere.
# 任意の場所からの全てのアドレス
ANYWHERE="0/0"

# These modules may need to be loaded:
# これらのモジュールを読み込む必要があるかも。
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

# Start building chains and rules #################################
## チェインと規則の設定の始まり
# Let's start clean and flush all chains to an empty state.
# まず全てのチェインを空の状態に。
$IPTABLES -F
$IPTABLES -X


# Set the default policies of the built-in chains. If no match for any 
# of the rules below, these will be the defaults that IPTABLES uses.
# 組み込みのチェインのデフォルトポリシーを設定。以下のルールのどれにも
# 一致しなければ、これらが IPTABLES の使うデフォルトになる。
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P INPUT DROP 

# Accept localhost/loopback traffic.
# localhost/loopback トラフィックを受け入れる。
$IPTABLES -A INPUT -i lo -j ACCEPT

# Get our dynamic IP now from the Inet interface. WAN_IP will be the
# address we are protecting from outside addresses.
# ここで Inet インターフェースから我々のダイナミック IP を取得。
# WAN_IP は外の世界から我々が守る IP アドレスになる。
[ -z "$WAN_IP" ] &&\
  WAN_IP=`ifconfig $WAN_IFACE |grep inet |cut -d : -f 2 |cut -d \  -f 1`

# Bail out with error message if no IP available! Default policy is 
# already set, so all is not lost here.
# どの IP も可能でないならエラーメッセージとともに抜け出る。
# デフォルトポリシーは既に設定されているので、すべてがここで
# 失われるわけではない。
[ -z "$WAN_IP" ] && echo "$WAN_IFACE not configured, aborting." && exit 1

WAN_MASK=`ifconfig $WAN_IFACE |grep Mask |cut -d : -f 4`
WAN_NET="$WAN_IP/$WAN_MASK"

## Reserved IPs:
#　予約 IP:
# We should never see these private addresses coming in from outside 
# to our external interface.
# 外部から我々の外部インターフェースへ、これらのプライベートアドレスが
# 入ってくることは決してあるべきではない。
$IPTABLES -A INPUT -i $WAN_IFACE -s 10.0.0.0/8      -j DROP
$IPTABLES -A INPUT -i $WAN_IFACE -s 172.16.0.0/12   -j DROP
$IPTABLES -A INPUT -i $WAN_IFACE -s 192.168.0.0/16  -j DROP
$IPTABLES -A INPUT -i $WAN_IFACE -s 127.0.0.0/8     -j DROP
$IPTABLES -A INPUT -i $WAN_IFACE -s 169.254.0.0/16  -j DROP
$IPTABLES -A INPUT -i $WAN_IFACE -s 224.0.0.0/4     -j DROP
$IPTABLES -A INPUT -i $WAN_IFACE -s 240.0.0.0/5     -j DROP
# Bogus routing
# 偽もののルーティング
$IPTABLES -A INPUT -s 255.255.255.255 -d $ANYWHERE -j DROP

# Unclean
$IPTABLES -A INPUT -i $WAN_IFACE -m unclean -m limit \
  	--limit 15/minute -j LOG --log-prefix "Unclean: "
$IPTABLES -A INPUT -i $WAN_IFACE -m unclean -j DROP

## LAN access and masquerading
#LAN アクセスとマスカレーディング
# Allow connections from our own LAN's private IP addresses via the LAN
# interface and set up forwarding for masqueraders if we have a LAN_NET
# defined above.
# LAN インターフェスを通じての、我々自身の LAN のプライベート IP アドレス
# からの接続を許可し、上で LAN_NET が定義されていればマスカレーダーの
# フォワーディングを設定する。
if [ -n "$LAN_NET" ]; then 
 echo 1 > /proc/sys/net/ipv4/ip_forward
 $IPTABLES -A INPUT -i $LAN_IFACE  -j ACCEPT
# $IPTABLES -A INPUT -i $LAN_IFACE -s $LAN_NET -d $LAN_NET  -j ACCEPT  
 $IPTABLES -t nat -A POSTROUTING -s $LAN_NET -o $WAN_IFACE -j MASQUERADE
fi

## Blacklist
#　ブラックリスト
# Get the blacklisted hosts/nets out of the way, before we start opening 
# up any services. These will have no access to us at all, and will 
# be logged.
# ブラックリストにのったホスト/ネットを、どのサーヴィスも開かれ
# る前に閉め出す。これらはまったく我々にアクセスを持たず、
# ログをとられる。
for i in $BLACKLIST; do
 $IPTABLES -A INPUT -s $i -m limit --limit 5/minute \
   -j LOG --log-prefix "Blacklisted: "
 $IPTABLES -A INPUT -s $i -j DROP
done

## Trusted hosts/nets
#信用できるホスト/ネット
# This is our trusted host list. These have access to everything.
# 信用するホストのリスト。これらは全てへのアクセス権を持つ。
for i in $TRUSTED; do
 $IPTABLES -A INPUT -s $i -j ACCEPT
done

# Port Forwarding
#ポートフォワーディング
# Which ports get forwarded to which host. This is one to one 
# port mapping (ie 80 -> 80) in this case.
# どのポートがどのホストへフォワードされるか。これはこの場合
# 一対一のマッピング（つまり、80 から 80 へ）。
[ -n "$FORWARD_HOST" ] &&\
 for i in $FORWARD_PORTS; do
   $IPTABLES -A FORWARD -p tcp -s $ANYWHERE -d $FORWARD_HOST \
     --dport $i -j ACCEPT
   $IPTABLES -t nat -A PREROUTING -p tcp -d $WAN_IP --dport $i \
     -j DNAT --to $FORWARD_HOST:$i
 done

## Open, but Restricted Access ports
#開いた、しかし制限されたアクセスのポート/サーヴィス
# Allow DHCP server (their port 67) to client (to our port 68) UDP
# traffic from outside source.
# 外部ソースからクライアントの（我々の68番ポートへの）UDP トラフィック
# へ　DHCP サーバ（67番ポート）を許可する。
[ -n "$DHCP_SERVER" ] &&\
 $IPTABLES -A INPUT -p udp -s $DHCP_SERVER --sport 67 \
   -d $ANYWHERE --dport 68 -j ACCEPT 

# Allow 'identd' (to our TCP port 113) from mail server only.
# メイルサーバのみから（我々の TCP 113 番ポートへの）'identd' を許可
[ -n "$MAIL_SERVER" ] &&\
 $IPTABLES -A INPUT -p tcp -s $MAIL_SERVER  -d $WAN_IP --dport 113 -j ACCEPT 

# Open up Public server ports here (available to the world):
# ここで PUBLIC サーバポートを開く（世界へ繋げるため）：
for i in $PUBLIC_PORTS; do
 $IPTABLES -A INPUT -p tcp -s $ANYWHERE -d $WAN_IP --dport $i -j ACCEPT 
done

# So I can check my home POP3 mailbox from work. Also, so I can ssh 
# in to home system. Only allow connections from my workplace's
# various IPs. Everything else is blocked.
# これによって仕事場から自宅の POP3 メイルボックスをチェックできる。
# また、自宅システムへ ssh で入ることもできる。仕事場のさまざまな
# IP アドレスからの接続を許可するだけ。他は全てブロックされる。
$IPTABLES -A INPUT -p tcp -s 255.10.9.8/29 -d $WAN_IP --dport 110 -j ACCEPT 

## ICMP (ping)
#
# ICMP rules, allow the bare essential types of ICMP only. Ping
# request is blocked, ie we won't respond to someone else's pings,
# but can still ping out.
# ICMP の規則、ICMP のむき出しの本質的なタイプだけを許可。
# Ping 要求はブロックされる。つまり、他の誰かの ping には答えないが、
# 自分は ping out することができる。
$IPTABLES -A INPUT  -p icmp  --icmp-type echo-reply \
   -s $ANYWHERE -d $WAN_IP -j ACCEPT
$IPTABLES -A INPUT  -p icmp  --icmp-type destination-unreachable \
   -s $ANYWHERE -d $WAN_IP -j ACCEPT
$IPTABLES -A INPUT  -p icmp  --icmp-type time-exceeded \
   -s $ANYWHERE -d $WAN_IP -j ACCEPT

# Identd Reject
# Identd 拒否
#
# Special rule to reject (with rst) any identd/auth/port 113
# connections. This will speed up some services that ask for this,
# but don't require it. Be careful, some servers may require this
# one (IRC for instance).
# 全ての identd/auth/port 113 接続を (rst と）拒否する特別規則。
# これを要求するが必要とはしないサーヴィスをスピードアップする。
# 要注意、これを必要とするサーヴィス（IRC など）もある。
#$IPTABLES -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

###################################################################
# Build a custom chain here, and set the default to DROP. All
# other traffic not allowed by the rules above, ultimately will
# wind up here, where it is blocked and logged, unless it passes
# our stateful rules for ESTABLISHED and RELATED connections. Let
# connection tracking do most of the worrying! We add the logging
# ability here with the '-j LOG' target. Outgoing traffic is
# allowed as that is the default policy for the 'output' chain.
# There are no restrictions placed on that in this script.
# ここであつらえのチェインを構築し、DROP へのデフォルトを設定。
# 上の規則で許可されない他のトラフィックは全て、最終的にここで
# 始末をつけ、ESTABLISHED と RELATED 接続についてのステイトフル規則
# をパスしていない限り、ブロックしログをとる。接続追跡機能に心配事の
# ほとんどをやらせましょう！ここでは '-j LOG' ターゲットでログ機能を
# 追加する。外に向かうトラフィックは 'output' チェインについての
# デフォルトポリシーなので許可されている。このスクリプトでは
# 何の制限もおかない。

# New chain...
# 新しいチェイン
$IPTABLES -N DEFAULT
# Use the 'state' module to allow only certain connections based 
# on their 'state'.
# その 'state' に基づいてある種の接続を許可するために
# 'state' モジュールを使う。
$IPTABLES -A DEFAULT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A DEFAULT -m state --state NEW -i ! $WAN_IFACE -j ACCEPT
# Enable logging for anything that gets this far.
# これが成功したものは全てログをとる。
$IPTABLES -A DEFAULT -j LOG -m limit --limit 30/minute --log-prefix "Dropping: "
# Now drop it, if it has gotten here.
# ここでつかまれば、今ドロップ。
$IPTABLES -A DEFAULT -j DROP

# This is the 'bottom line' so to speak. Everything winds up
# here, where we bounce it to our custom built 'DEFAULT' chain
# that we defined just above. This is for both the FORWARD and 
# INPUT chains. 
# これがいわば、「結論」。全てをここで始末をつけ、まさに上で
# 定義したあつらえで作った 'DEFAULT' チェインに押し込める。
# これは FORWARD と INPUT チェインの両方のため。
$IPTABLES -A FORWARD -j DEFAULT
$IPTABLES -A INPUT   -j DEFAULT

echo "Iptables firewall is up `date`."

##-- eof iptables.sh
 
 </programlisting>
</para>

</sect3>

<!--  ~  End section  ~  -->



<!--   ~~~~~       New section      ~~~~~     -->

<sect3>
<title><!--Summary-->まとめ</title>

<para>
<!--
 A quick run down of the some highlights...
-->
  最重要ポイントを簡単におさらいしてみましょう…
</para>

<!--
<para>
 Again we started by setting some shell variables in the top section, but a
 few more this time. Then we set the default rules (ipchains calls these
 <quote>policies</quote>) of denying all inbound and forwarded traffic, and of
 allowing all our own outbound traffic. Same as the former example. 

</para>

<para>
 But then we added some specific rules to block any <quote>private</quote> 
 IP addresses that from our external interface. We shouldn't see these on the
 Internet. These are used for LANs, and private networks. We then enabled
 <quote>masquerading</quote>. Then added a <quote>blacklist</quote> concept.
 These would addresses that we want banned totally, no matter what. We also
 added a <quote>trusted</quote> hosts rule, for our good friends who we are
 allowing access to all services. Then made possible <quote>port
 forwarding</quote>, if we wanted some services forwarded to an internal host,
 rather than be running on our firewall itself. This is considered a safer way
 in most cases. Note that <application>iptables</application> handles this
 itself, but <application>ipchains</application> requires a separate helper
 package, <application>ipmasqadm</application>.

</para>

<para>
 We then opened a few exceptions to the inbound default policy. First by
 allowing public access to our ssh server. This could have been a list of
 ports, but we just used one in this example. Anybody on the Internet could
 be able to access these - except the <quote>blacklisted</quote> hosts that
 we have a special rule for.

</para>
-->

<para>
<!--
 We added some host based access control rules: <quote>blacklisted</quote>, 
 and <quote>trusted</quote>. We then showed several types of service 
 and port based access rules. For instance, we allowed some very restrictive
 access to bigcat's <application>POP3</application> server so we could connect
 only from our workplace. We allowed a very narrow rule for the ISP's DHCP
 server. This rule only allows one port on one outside IP address to connect
 to only one of our ports and only via the UDP protocol. This is a very
 specific rule! We are being specific since there is no reason to allow any
 other traffic to these ports or from these addresses. Remember our goal is
 the minimum amount of traffic necessary for our particular situation. 
-->
  我々はホストに基づいたアクセス制御の規則：
<quote>ブラックリストにあがるもの</quote>と<quote>信用できるもの</quote> 
の二つについての規則を加えました。
そして様々な種類のサーヴィスとポートに基づいたアクセス規則を
示しました。
たとえば、bigcat の <application>POP3</application> 
サーバへのアクセス許可に非常に強い制限をおき、
仕事場からだけ接続できるようにしました。
また、プロバイダの DHCP サーバについても非常に狭い規則だけを許しました。
この規則は、外部の一つの IP アドレスの一つのポートに
我々のポートの一つだけに、UDP プロトコルを通してのみ、
接続を許可するものでした。
これは非常に限定されたルールです！
これらのポートやアドレスに対して他のどんな通信も許可する
理由はないのですから、限定されてあるべきなのです。
我々の目標は、
自分たちの特定の状況での必要最小限の通信だけに制限すること
であったことを思い出してください。
</para>

<para>
<!--
 So we made those few exceptions mentioned above, and all other services
 running on bigcat should be effectively blocked completely from outside
 connections. These are still happily running on bigcat, but are now safe and
 sound behind our packet filtering firewall. You probably have other services
 that fall in this category as well.
-->
  ですから、上で述べた少数の例外だけをおいて、
それ以外の bigcat 上の全てのサーヴィスについては、
外部からの接続を、実際上、完全にブロックするべきです。
これでも bigcat 上で何の問題もなく動作していますが、
今や、パケットフィルタリングのファイアーウォールの
背後に守られて安全かつ堅牢に動いているのです。
あなた自身の場合も同様に、
このカテゴリーに入るその他のサーヴィスを動かしているかもしれません。
</para>

<para>
<!--
 We also have a small, home network in the above example. We did not take any
 steps to block that traffic. So the LAN has access to all services running on
 bigcat. And it is further <quote>masqueraded</quote>, so that it has Internet 
 access (different HOWTO), by manipulating the <quote>forward</quote> chain. 
 And the LAN is still protected by our firewall since it sits behind the
 firewall. We also didn't impose any restrictive rules on the traffic leaving
 bigcat. In some situations, this might be a good idea. 
-->
  上の例では、小さな自宅内のネットワークも持っていましたが、
これらの通信をブロックするための対策は取りませんでした。
ですから、この LAN 内では bigcat 上で走っている全てのサーヴィスに
アクセスできます。
そしてそれはさらに<quote>マスカレード</quote>されていて、
<quote>フォワード</quote>されたチェインを使うことで、
インターネットへのアクセスを持っています（別の HOWTO 参照）。
そして LAN はファイアーウォールの背後にあるのですから、
やはりファイアーウォールによって守られています。
我々は bigcat から出ていく通信については、
なんら制限の規則をおきませんでした。
状況によっては、これはよい考えでしょう。
</para>

<para>
<!--
 Of course, this is just a hypothetical example. Your individual situation is
 surely different, and would require some changes and likely some additions to
 the rules above. For instance, if your ISP does not use DHCP (most do not),
 then that rule would make no sense. <application>PPP</application> works
 differently and such rules are not needed. 
 -->
  もちろん、これは単なる仮想的な一例でした。
あなた個人の状況は確実に異なるものでしょうし、
いくらかの変更や、上の規則にいくつか追加することも必要となるでしょう。
たとえば、あなたのプロバイダが DHCP を使っていないならば
（多くは使っていません）、上の規則は意味をなしません。
<application>PPP</application> は異なった働きをしますから、
そのような規則は必要ありません。
</para>

<para>
<!--
 Please don't interpret that running any server as we did in this example is
 necessarily a <quote>safe</quote> thing to do. We shouldn't do it this way
 unless a) we really need to and b) we are running the current, safe version,
 and c) we are able to keep abreast of security related issues that might
 effect these services. Vigilance and caution are part of our responsibilities
 here too. 
 -->
  この例でのようにサーバを走らせることが、
必ず<quote>安全</quote>な方法であるとは思わないで下さい。
(a) 本当に必要でない限り、
(b) 最新の安全なバージョンを走らせていない限り、
そして、
(c) これらのサーヴィスに影響を与えるだろう
セキュリティ関連の情報に常に遅れないようにし続けていない限り、
この方法を行うべきではありません。
ここでも警戒と注意が我々の責任に含まれるのです。
</para>

</sect3>

<!--  ~  End section  ~  -->


<!--   ~~~~~       New section      ~~~~~     -->
<sect3>
<title>iptables mini-me</title>
<para>
<!--
 Just to demonstrate how succinctly <application>iptables</application> can be
 configured in a minimalist situation, the below is from the Netfilter team's
 <citetitle>Rusty's Really Quick Guide To Packet Filtering</citetitle>:
-->
  最小限の状況でいかに簡潔に <application>iptables</application> を
設定するか示すために、以下をあげましょう。
これは Netfilter team の
 <citetitle>Rusty's Really Quick Guide To Packet Filtering</citetitle>
 からの引用です。
</para>

<blockquote>
 <para>
<!--
 <quote>Most people just have a single PPP connection to the Internet, and
 don't want anyone coming back into their network, or the firewall:</quote>
-->
  <quote>ほとんどの人は単にインターネットへの PPP 接続一つを
持っているだけで、誰にも自分のネットワークやファイアーウォールに
入ってきてもらいたくない：</quote>
 </para>
</blockquote>

<para>
 <programlisting>

 ## Insert connection-tracking modules (not needed if built into kernel).
 ## 接続追跡モジュールを挿入（カーネル組み込みなら不要）。 
 insmod ip_conntrack
 insmod ip_conntrack_ftp

 ## Create chain which blocks new connections, except if coming from inside.
 ## 内側から来るもの以外、新しい接続をブロックするチェインを作成。
 iptables -N block
 iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
 iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
 iptables -A block -j DROP

 ## Jump to that chain from INPUT and FORWARD chains.
 ## INPUT と FORWARD チェインからそのチェインへジャンプ。
 iptables -A INPUT -j block
 iptables -A FORWARD -j block

 </programlisting>
</para>

<para>
<!--
 This simple script will allow all outbound connections that we initiate, i.e. 
 any <application>NEW</application> connections (since the default policy of
 ACCEPT is not changed). Then any connections that are
 <quote>ESTABLISHED</quote> and <quote>RELATED</quote> to these are also
 allowed. And, any connections that are not incoming from our WAN side
 interface, <literal>ppp0</literal>, are also allowed. This would be lo or
 possibly a LAN interface like eth1. So we can do whatever we want, but no
 unwanted, incoming connection attempts are allowed from the Internet. None.
-->
  この単純なスクリプトは我々が初期化した全ての外向きの接続
つまり、すべての <application>NEW</application> 接続を許可します
（ACCEPT のデフォルトのポリシーは変更されていないので）。
そして、これらについて<quote>ESTABLISHED</quote> と
 <quote>RELATED</quote> された全ての通信も許可します。
さらに、WAN 側のインターフェース、<literal>ppp0</literal>,
 から入ってきたのではない全ての接続も許可されます。
これは lo か、または eth1 のような LAN インターフェースでしょう。
ですから我々がしたいことは何であれ全て可能ですが、
インターネットからの、望まぬ、中に入ってくる接続試行は全て許可しません。
何一つ。
</para>

<para>
<!--
 This script also demonstrates the creation of a custom chain, defined here
 as <quote>block</quote>, which is used both for the INPUT and FORWARD 
 chains.
 -->
  また、このスクリプトはあつらえのチェインの作成例を示してもいます。
ここでは <quote>block</quote> と定義されていて、
INPUT と FORWARD チェインの両方に用いられています。
</para>

</sect3>

</sect2>

</sect1>


<!-- thanks (japanese version) -->
<sect1>
<title>日本語版謝辞</title>
<para>
校正を担当してくださった渡辺崇史さんと山下義之さん、
貴重なご意見をいただいた JF メンバに御礼申し上げます。
誤字・脱字・誤訳等なにかありましたら &lt;JF@linux.or.jp&gt; 
までお知らせください。
</para>
</sect1>

</article>
