harden-doc 3.19 - en to ja translation catalogue (101 entries)

en: Securing services running on your system
ja: システム上で動いているサービスを安全にする

en: Services can be secured in a running system in two ways:
ja: すでに動いているシステム上でサービスを安全にする方法は 2 通りあります:

en: Making them only accessible at the access points (interfaces) they need to be in.
ja: 必要とされるアクセスポイント (インターフェイス) でのみアクセス できるようにする。

en: Configuring them properly so that they can only be used by legitimate users in an authorized manner.
ja: 適切に設定して正当なユーザだけが認められているやり方でのみ 使えるようにする。

en: Restricting services so that they can only be accessed from a given place can be done by restricting access to them at the kernel (i.e. firewall) level, configure them to listen only on a given interface (some services might not provide this feature) or using some other methods, for example the Linux vserver patch (for 2.4.16) can be used to force processes to use only one interface.
ja: ある場所からのみアクセスできるようにサービスを制限するのはカーネルレベルで (すなわち、ファイアウォールで) アクセスを制限すること、あるインターフェイスに だけ応答するように設定すること (この機能を提供しないサービスもあります) またはその他の方法を使うことによって可能です。たとえば linux vserver パッチは プロセスがインターフェイスをひとつしか使わないように強制するのに使えます。

en: The following sections detail how specific individual services can be configured properly depending on their intended use.
ja: 以下の章は特定のサービスを意図されている用途にしたがってどのように適切に 設定できるかの詳細を論じます。

en: Securing ssh
ja: ssh を使う

en: If you are still running telnet instead of ssh, you should take a break from this manual and change this. Ssh should be used for all remote logins instead of telnet. In an age where it is easy to sniff Internet traffic and get clear-text passwords, you should use only protocols which use cryptography. So, perform an <literal>apt-get install ssh</literal> on your system now.
ja: もし ssh のかわりにまだ telnet を動かしているなら、このマニュアルを読むのを やめてそれを変更するべきです。リモートログインにはすべて telnet のかわりに Ssh を用いるべきです。インターネットのトラフィックを盗聴して平文の パスワードを得ることが簡単にできる時代には、暗号を使うプロトコルだけを 使うべきです。よって、あなたのシステムでただちに <literal>apt-get install ssh</literal> を実行しましょう。

en: Encourage all the users on your system to use ssh instead of telnet, or even better, uninstall telnet/telnetd. In addition you should avoid logging into the system using ssh as root and use alternative methods to become root instead, like <command>su</command> or <command>sudo</command>. Finally, the <filename>sshd_config</filename> file, in <filename>/etc/ssh</filename>, should be modified to increase security as well:
ja: あなたのシステムのすべてのユーザに telnet のかわりに ssh を使うことを すすめましょう。よりよいのは telnet や telnetd をアンインスールすることです。 さらに ssh を使って root としてシステムにログインすることを避け、<literal>su</literal> や <literal>sudo</literal> のような、root になるためのかわりの手段を使いましょう。 最後に、セキュリティを向上させるために /etc/ssh 中のファイル sshd_config を 変更するべきです:

en: <literal>ListenAddress 192.168.0.1</literal> Have ssh listen only on a given interface, just in case you have more than one (and do not want ssh available on it) or in the future add a new network card (and don't want ssh connections from it).
ja: ふたつ以上のインターフェイスがあるかもしれないので (そこで ssh を利用 可能にはしたくないなら)、または将来新しいネットワークカードを追加するのに そなえて (そしてそこからの ssh 接続を望まないなら)、ssh をある インターフェイスにだけ応答するようにしましょう。

en: <literal>PermitRootLogin no</literal> Try not to permit Root Login wherever possible. If anyone wants to become root via ssh, now two logins are needed and the root password cannot be brute forced via SSH.
ja: 可能なら Root のログインをいつでも禁止するべきです。ssh 経由で root に なりたいなら、こうすると 2 回のログインが必要になり、root のパスワードを SSH 経由で力まかせに推測することができなくなります。

en: <literal>AllowGroups wheel admin</literal> Allow only certain group members to have access via ssh to this machine. AllowGroups and AllowUsers have equivalent directives for denying access to a machine. Not surprisingly they are called "DenyUsers" and "DenyGroups".
ja: 特定のグループのメンバーだけが ssh 経由でこのマシンにアクセスできるように しましょう。AllowGroups と AllowUsers にはアクセスを拒否するための同様の ディレクティブがあります。驚くべきことでもなく、それは「DenyUsers」や 「DenyGroups」と呼ばれています。

en: <literal>PasswordAuthentication yes</literal> It is completely your choice what you want to do. It is more secure to only allow access to the machine from users with ssh-keys placed in the <filename>~/.ssh/authorized_keys</filename> file. If you want so, set this one to "no".
ja: 何をしたいかは完全にあなたが選べます。ssh の鍵をファイル ~/.ssh/authorized_keys に置いているユーザからのマシンへのアクセスだけを 許可するほうがより安全です。もしそうしたいなら、これを「no」に設定して ください。

en: As a final note, be aware that these directives are from a OpenSSH configuration file. Right now, there are three commonly used SSH daemons, ssh1, ssh2, and OpenSSH by the OpenBSD people. Ssh1 was the first ssh daemon available and it is still the most commonly used (there are rumors that there is even a Windows port). Ssh2 has many advantages over ssh1 except it is released under a closed-source license. OpenSSH is completely free ssh daemon, which supports both ssh1 and ssh2. OpenSSH is the version installed on Debian when the package <application>ssh</application> is chosen.
ja: 最後に、これらのディレクティブは OpenSSH のものであることに注意してください。 現時点では、広く使われている SSH デーモンは 3 種類あります。ssh1、ssh2 そして OpenBSD の人たちによる OpenSSH です。Ssh1 は利用できる最初の ssh デーモンでした。そして依然として最も広く使われています (windows への 移植版さえあるといううわさです)。Ssh2 はソース非公開のライセンスで リリースされていることを除けば ssh1 より多くの長所があります。OpenSSH は 「ssh」が選択されたとき Debian にインストールされるバージョンです。

en: Securing Squid
ja: Squid を安全にする

en: Notice that, if not properly configured, someone may relay a mail message through Squid, since the HTTP and SMTP protocols are designed similarly. Squid's default configuration file denies access to port 25. If you wish to allow connections to port 25 just add it to Safe_ports lists. However, this is <emphasis>NOT</emphasis> recommended.
ja: さらに、適切に設定されていなければ、だれもがメールを Squid を通じてリレーする ことができます。なぜなら、HTTP プロトコルと SMTP プロトコルは同じように 設計されているからです。Squid のデフォルトの設定ファイルでは 25 番ポートへの アクセスは禁止されています。もし 25 番ポートへの接続を許可したいなら それを Safe_ports リストに追加するだけです。しかし、これは推奨されて <emphasis>「いません」</emphasis>。

en: Setting and configuring the proxy/cache server properly is only part of keeping your site secure. Another necessary task is to analyze Squid's logs to assure that all things are working as they should be working. There are some packages in Debian GNU/Linux that can help an administrator to do this. The following packages are available in Debian 3.0 and Debian 3.1 (sarge):
ja: プロキシおよびキャッシュサーバを適切に設置して設定することはあなたのサイトを 安全に保つことの一部にすぎません。他に必要な仕事には何事もそうあるべきように 動いていることを確実にするため Squid のログを解析することがあります。 Debian GNU/Linux には管理者がこれを行うのを助けるパッケージがいくつかあります。 以下のパッケージが woody (Debian 3.0) で利用可能です:

en: Securing FTP
ja: FTP を安全にする

en: If you really have to use FTP (without wrapping it with sslwrap or inside a SSL or SSH tunnel), you should chroot ftp into the ftp users' home directory, so that the user is unable to see anything else than their own directory. Otherwise they could traverse your root file system just like if they had a shell in it. You can add the following line in your <filename>proftpd.conf</filename> in your global section to enable this chroot feature:
ja: 本当に FTP を (sslwrap でラップしたり、SSL や SSH のトンネルを通さずに) 使わなければいけないならば、 ユーザが自分のディレクトリ以外のどんなものも見ることができないように ftp を ftp ユーザのホームディレクトリの内部へ chroot するべきです。そうしないと ユーザはシェルを持っているかのようにあなたのルートファイルシステムをうろつく ことができます。この chroot 機能を有効にするには <filename>proftpd.conf</filename> のグローバル セクションに以下の行を追加することができます:

en: Restart ProFTPd by <literal>/etc/init.d/proftpd restart</literal> and check whether you can escape from your homedir now.
ja: <literal>/etc/init.d/proftpd restart</literal> で proftpd を再起動して ホームディレクトリから逃げだせるか確かめてください。

en: To prevent ProFTPd DoS attacks using ../../.., add the following line in <filename>/etc/proftpd.conf</filename>: <literal>DenyFilter \*.*/</literal>
ja: ../../.. を使った Proftp DoS 攻撃を防ぐには、以下の行を <filename>/etc/proftpd.conf</filename> に追加してください。

en: Always remember that FTP sends login and authentication passwords in clear text (this is not an issue if you are providing an anonymous public service) and there are better alternatives in Debian for this. For example, <command>sftp</command> (provided by <application>ssh</application>). There are also free implementations of SSH for other operating systems: <ulink name="putty" url="http://www.chiark.greenend.org.uk/~sgtatham/putty/" /> and <ulink name="cygwin" url="http://www.cygwin.com" /> for example.
ja: FTP はログインや認証のパスワードを平文で送っていること (これは匿名の公共 サービスを提供しているのなら問題ではありません) および Debian にはよりよい 代用品があることをいつもおぼえておいてください。たとえば、<command>sftp</command> (<application>ssh</application> パッケージによって提供されます)。他の オペレーティングシステムのためのフリーな SSH 実装もあります: たとえば <ulink name="putty" url="http://www.chiark.greenend.org.uk/~sgtatham/putty/" /> や <ulink url="http://www.cygwin.com" name="cygwin" /> です。

en: Securing access to the X Window System
ja: X Window System へのアクセスを安全にする

en: Today, X terminals are used by more and more companies where one server is needed for a lot of workstations. This can be dangerous, because you need to allow the file server to connect to the clients (X server from the X point of view. X switches the definition of client and server). If you follow the (very bad) suggestion of many docs, you type <literal>xhost +</literal> on your machine. This allows any X client to connect to your system. For slightly better security, you can use the command <literal>xhost +hostname</literal> instead to only allow access from specific hosts.
ja: 今日では、X 端末はひとつのサーバが多くのワークステーションで必要とされる 多くの企業で使われています。これは危険かもしれません。なぜならファイルサーバに クライアント (X の観点からは X サーバです。X はクライアントとサーバの定義を 入れかえています) への接続を許可する必要があるからです。もし多くの文書に ある (非常に悪い) 提案にしたがうなら、あなたのマシンで <literal>xhost +</literal> と 入力することになります。これはすべての X クライアントにあなたのシステムへの 接続を許可します。すこしだけセキュリティをよくするには、特定のホストからの アクセスだけを許可するためにかわりに <literal>xhost +hostname</literal> コマンドを 使うことができます。

en: For best security, if you do not need X access from other machines, switch off the binding on TCP port 6000 simply by typing:
ja: 最高のセキュリティのためには、他のマシンからの X アクセスが必要ないなら、 こう入力して tcp の 6000 番ポートをバインドすることを停止することです: <literal>startx -- -nolisten tcp</literal>

en: This is the default behavior in Xfree 4.1.0 (the Xserver provided in Debian 3.0 and 3.1). If you are running Xfree 3.3.6 (i.e. you have Debian 2.2 installed) you can edit <filename>/etc/X11/xinit/xserverrc</filename> to have it something along the lines of:
ja: 注意: これは Xfree 4.0 (Debian 3.0 で提供される X サーバです) の デフォルトのふるまいです。もし Xfree 3.3.6 を動かしているなら (すなわち、 Debian 2.2 をインストールしているなら)、<filename>/etc/X11/xinit/xserverrcc</filename> を編集してこのような行を追加できます:

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

en: FIXME: Add info on thread of debian-security on how to change config files of XFree 3.3.6 to do this.
ja: FIXME: これを行うために XFree 3.3.6 の設定ファイルをどう変更するべきかに ついての debian-security スレッドの情報を追加する。

en: Check your display manager
ja: ディスプレイマネージャを調べる

en: If you only want to have a display manager installed for local usage (having a nice graphical login, that is), make sure the XDMCP (X Display Manager Control Protocol) stuff is disabled. In XDM you can do this with this line in <literal>/etc/X11/xdm/xdm-config</literal>:
ja: もしローカルで使うためだけに (つまり、きれいなグラフィカルログインのために) ディスプレイマネージャをインストールしたいなら、XDMCP (X Display Manager Control Protocol) 関連を停止しましょう。XDM ではこれは <literal>/etc/X11/xdm/xdm-config</literal> のこういう行で行うことができます。

en: Normally, all display managers are configured not to start XDMCP services per default in Debian.
ja: ふつう、Debian ではすべてのディスプレイマネージャはデフォルトでは XDMCP サービスを開始しないよう設定されています。

en: Securing printing access (the lpd and lprng issue)
ja: プリントサービスを安全にする (lpd と lprng の問題)

en: In order to avoid any issues you should keep your printer servers especially secure. This means you need to configure your printer service so it will only allow connections from a set of trusted servers. In order to do this, add the servers you want to allow printing to your <filename>/etc/hosts.lpd</filename>.
ja: 職場に着いたとき、だれかがあなたのラインプリンタデーモンに DoS しているせいで プリンタが紙を際限なくはきだしているとしましょう。いやでしょう? だから プリンタサーバを特に安全にしましょう。これは信用されているサーバからの 接続のみを許可するようプリンタサービスを設定する必要があるということです。 これを行うには、印刷を許可したいサーバを <filename>/etc/hosts.lpd</filename> に 追加してください。

en: However, even if you do this, the <command>lpr</command> daemon accepts incoming connections on port 515 of any interface. You should consider firewalling connections from networks/hosts which are not allowed printing (the <command>lpr</command> daemon cannot be limited to listen only on a given IP address).
ja: しかし、これを行っても、lpr デーモンは 515 番ポートへの外部からの接続をどの インターフェイスからでも受けつけます。印刷を許可されていないネットワーク (またはホスト) からの接続をファイアウォールで防ぐことを検討するべきです (lpr デーモンは特定の IP アドレスにのみ応答するようには制限できません)。

en: <command>Lprng</command> should be preferred over <command>lpr</command> since it can be configured to do IP access control. And you can specify which interface to bind to (although somewhat weirdly).
ja: lpr より Lprng を優先するべきです。なぜなら IP アクセス制御を行うように 設定できるからです。そしてどのインターフェイスをバインドするか (やや奇妙な やり方ですが) 指定できます。

en: If you are using a printer in your system, but only locally, you will not want to share this service over a network. You can consider using other printing systems, like the one provided by <application>cups</application> or <ulink name="PDQ" url="http://pdq.sourceforge.net/" /> which is based on user permissions of the <filename>/dev/lp0</filename> device.
ja: もしあなたのシステムでプリンタを使っているが、ローカルでのみ使っているなら、 そのサービスをネットワークで共有したくはないでしょう。<filename>/dev/lp0</filename> デバイスのユーザパーミッションにもとづく <application>cups</application> とか <ulink url="http://pdq.sourceforge.net/" name="PDQ" /> によって提供されるような他の印刷 システムを使うことを検討することができます。

en: However, if you want to use <command>cups</command>, but only locally, you can configure it to bind to the loopback interface by changing <filename>/etc/cups/cupsd.conf</filename>:
ja: また、<command>cups</command> は <filename>/etc/cups/cupsd.conf</filename> をこのように 変更することによってループバックインターフェイスをバインドするように 設定できます:

en: FIXME: Check if PDG is available in Debian, and if so, suggest this as the preferred printing system.
ja: FIXME: PDG が Debian で利用可能か調べて、もしそうなら、これをよりよい 印刷システムとして提案する。

en: FIXME: Check if Farmer/Wietse has a replacement for printer daemon and if it's available in Debian.
ja: FIXME: Farmer/Wietse がプリンタデーモンのかわりになるものを持っているか、 それが Debian で利用可能か調べる。

en: If your server is not a mailing system, you do not really need to have a mail daemon listening for incoming connections, but you might want local mail delivered in order, for example, to receive mail for the root user from any alert systems you have in place.
ja: あなたのサーバがメールシステムでなければ、メールデーモンが外部からの接続に 応答する必要は本当はありませんが、たとえば設置している警告システムからの root ユーザへのメールを受けとるなどのために、ローカルのメールが配達される ようにしたいかもしれません。

en: and configure the mailer daemon to only listen on the loopback interface. In <command>exim</command> (the default MTA) you can do this by editing the file <filename>/etc/exim.conf</filename> and adding the following line:
ja: そして loopback インターフェイスにのみ応答するようにメーラデーモンを 設定します。exim (デフォルトの MTA) ではこれは <filename>/etc/exim.conf</filename> ファイルを編集して以下の行を追加することによって行えます:

en: Restart both daemons (inetd and exim) and you will have exim listening on the 127.0.0.1:25 socket only. Be careful, and first disable inetd, otherwise, exim will not start since the inetd daemon is already handling incoming connections.
ja: 両方のデーモン (inetd と exim) を再起動すると exim は 127.0.0.1:25 ソケットに のみ応答するようになります。注意してください、最初に inetd を停止しましょう。 そうしないと exim は起動しません。なぜなら inetd デーモンがすでに外部からの 接続を扱っているからです。

en: For <command>postfix</command> edit <filename>/etc/postfix/main.conf</filename>:
ja: postfix については <filename>/etc/postfix/main.conf</filename> をこう編集しましょう:

en: If you only want local mail, this approach is better than tcp-wrapping the mailer daemon or adding firewalling rules to limit anybody accessing it. However, if you do need it to listen on other interfaces, you might consider launching it from inetd and adding a tcp wrapper so incoming connections are checked against <filename>/etc/hosts.allow</filename> and <filename>/etc/hosts.deny</filename>. Also, you will be aware of when an unauthorized access is attempted against your mailer daemon, if you set up proper logging for any of the methods above.
ja: もしローカルのメールだけが望みなら、この方法はメーラデーモンに tcp wrapper を 使ったりファイアウォールの規則を追加してアクセスを制限したりするのより よいです。しかし、他のインターフェイスにも応答させる必要があるなら、inetd から 起動して、外部からの接続を <filename>/etc/hosts.allow</filename> と <filename>/etc/hosts.deny</filename> でチェックできるよう tcp wrapper を追加することを 検討してもいいです。そして、上で述べたような方法のどれかで記録するように 正しく設定していれば、許可されていないアクセスがメーラデーモンに対して いつ行われようとしたかわかるでしょう。

en: Receiving mail securely
ja: メールを安全に受けとる

en: Reading/receiving mail is the most common clear-text protocol. If you use either POP3 or IMAP to get your mail, you send your clear-text password across the net, so almost anyone can read your mail from now on. Instead, use SSL (Secure Sockets Layer) to receive your mail. The other alternative is SSH, if you have a shell account on the box which acts as your POP or IMAP server. Here is a basic <filename>fetchmailrc</filename> to demonstrate this:
ja: メールを読んだり受けとったりするのは最も一般的な平文のプロトコルです。 メールを受けとるのに POP3 か IMAP を使っていれば、平文のパスワードを ネット経由で送っているので、今後ほとんどだれでもあなたのメールを読むことが できることになります。かわりに、メールを受けとるのに SSL (Secure Sockets Layer) を使いましょう。POP または IMAP サーバとして働いているマシンに シェルアカウントを持っていれば、ほかの選択肢は ssh です。これををやって みせる基本的な fetchmailrc がこれです:

en: The preconnect is the important line. It fires up an ssh session and creates the necessary tunnel, which automatically forwards connections to localhost port 1236 to the IMAP mail server, but encrypted. Another possibility would be to use <command>fetchmail</command> with the SSL feature.
ja: preconnect が重要な行です。これは ssh セッションを開始して必要なトンネルを 作ります。それが自動的に localhost の 1236 番ポートから IMAP メールサーバへの 接続を暗号化して転送します。ほかの可能性は ssl 機能つきの fetchmail を 使うことです。

en: If you want to provide encrypted mail services like POP and IMAP, <literal>apt-get install stunnel</literal> and start your daemons this way:
ja: POP や IMAP のような暗号化されたメールサービスを提供したいなら、 <literal>apt-get install stunnel</literal> してデーモンをこのように起動してください:

en: This command wraps the provided daemon (-l) to the port (-d) and uses the specified SSL certificate (-p).
ja: これは与えられたデーモン (-l) を指定されたポート (-d) へラップして、指定された ssl cert (-p) を使います。

en: Securing BIND
ja: BIND を安全にする

en: There are different issues that can be tackled in order to secure the Domain server daemon, which are similar to the ones considered when securing any given service:
ja: Domain サーバデーモンを安全にするために取り組まなければならない問題がいくつか あります。これは他のどのサービスを安全にするときも検討されることです:

en: configuring the daemon itself properly so it cannot be misused from the outside (see <xref linkend="configure-bind" />). This includes limiting possible queries from clients: zone transfers and recursive queries.
ja: 外部から乱用されないようにデーモン自体を適切に設定しましょう。 これにはクライアントから可能な問いあわせの個数を制限すること (zone transfers や逆引きの問いあわせ) が含まれます。

en: limit the access of the daemon to the server itself so if it is used to break in, the damage to the system is limited. This includes running the daemon as a non-privileged user (see <xref linkend="user-bind" />) and chrooting it (see <xref linkend="chroot-bind" />).
ja: サーバへ侵入するのに使われたときシステムへの損害が限られるように デーモンからサーバそのものへのアクセスを制限しましょう。これにはデーモンを 非特権ユーザで動かすことや chroot することが含まれます。

en: You should restrict some of the information that is served from the DNS server to outside clients so that it cannot be used to retrieve valuable information from your organization that you do not want to give away. This includes adding the following options: <emphasis>allow-transfer</emphasis>, <emphasis>allow-query</emphasis>, <emphasis>allow-recursion</emphasis> and <emphasis>version</emphasis>. You can either limit this on the global section (so it applies to all the zones served) or on a per-zone basis. This information is documented in the <application>bind-doc</application> package, read more on this on <filename>/usr/share/doc/bind/html/index.html</filename> once the package is installed.
ja: あなたの組織のもらしたくない貴重な情報を引きだすのに使えないように DNS サーバから外部のクライアントへ提供される情報を制限するべきです。これには 以下のオプションを追加することが含まれます: <emphasis>allow-transfer</emphasis>、<emphasis>allow-query</emphasis>、 <emphasis>allow-recursive</emphasis>、そして <emphasis>version</emphasis> です。これを (提供される すべてのゾーンに適用されるように) グローバルセクションで制限することも できますし、ゾーンごとに制限することもできます。この情報は <application>bind-doc</application> で文書化されています。このことについて くわしくはそのパッケージをインストールしたあと <filename>/usr/share/doc/bind/html/index.html</filename> をごらんください。

en: Imagine that your server is connected to the Internet and to your internal (your internal IP is 192.168.1.2) network (a basic multi-homed server), you do not want to give any service to the Internet and you just want to enable DNS lookups from your internal hosts. You could restrict it by including in <filename>/etc/bind/named.conf</filename>:
ja: あなたのサーバがインターネットと内部の (あなたの内部 IP は 192.168.1.2 だと します) ネットワークに接続されていて (基本的なマルチホームのサーバです)、 インターネットにはサービスを何も提供したくはなく、内部のホストからだけ DNS 参照ができるようにしたいとしましょう。 <filename>/etc/bind/named.conf</filename> にこれを追加することによって DNS 参照を 制限できます:

en: The <emphasis>listen-on</emphasis> option makes the DNS bind to only the interface that has the internal address, but, even if this interface is the same as the interface that connects to the Internet (if you are using NAT, for example), queries will only be accepted if coming from your internal hosts. If the system has multiple interfaces and the <emphasis>listen-on</emphasis> is not present, only internal users could query, but, since the port would be accessible to outside attackers, they could try to crash (or exploit buffer overflow attacks) on the DNS server. You could even make it listen only on 127.0.0.1 if you are not giving DNS service for any other systems than yourself.
ja: <emphasis>listen-on</emphasis> オプションは DNS が内部アドレスを持つインターフェイスだけを バインドするようにしますが、このインターフェイスがインターネットに接続されて いるインターフェイスと同じでも (たとえば NAT を使っているときなど)、 問いあわせは内部のホストから来たときのみ受けいれられます。システムに インターフェイスが複数あって、<emphasis>listen-on</emphasis> がないときは、内部ユーザ だけが問いあわせることができますが、このポートは外部の攻撃者からもアクセス できるので、攻撃者は DNS サーバをクラッシュさせようと (またはバッファ オーバーフロー攻撃を行おうと) するかもしれません。自分自身以外のどの システムにも DNS サービスを提供しないなら 127.0.0.1 にだけ応答するように することさえできます。

en: The version.bind record in the chaos class contains the version of the currently running bind process. This information is often used by automated scanners and malicious individuals who wish to determine if one's <command>bind</command> is vulnerable to a specific attack. By providing false or no information in the version.bind record, one limits the probability that one's server will be attacked based on its published version. To provide your own version, use the <emphasis>version</emphasis> directive in the following manner:
ja: chaos クラスの version.bind レコードは現在動いている bind プロセスの バージョンを含みます。この情報はしばしば自動スキャナや、bind が特定の攻撃に 対して脆弱であるか調べたい、悪意ある人に利用されます。version.bind レコードでうその情報を提供したり、情報を何も提供しないことによって、 公開されているバージョンにもとづいてサーバが攻撃される確率を制限することが できます。独自のバージョンを提供するには、<emphasis>version</emphasis> ディレクティブを 次のように使ってください:

en:  options { ... various options here ...
    version "Not available."; };
ja: options {
            ... various options here ...
            version "Not available.";
    };

en: Changing the version.bind record does not provide actual protection against attacks, but it might be considered a useful safeguard.
ja: version.bind レコードを変更することは攻撃に対する実際の保護にはなりませんが、 役に立つ防御策と考えられるべきです。

en: Regarding limiting BIND's privileges you must be aware that if a non-root user runs BIND, then BIND cannot detect new interfaces automatically, for example when you put a PCMCIA card into your laptop. Check the <filename>README.Debian</filename> file in your named documentation (<filename>/usr/share/doc/bind/README.Debian</filename>) directory for more information about this issue. There have been many recent security problems concerning BIND, so switching the user is useful when possible. We will detail here the steps needed in order to do this, however, if you want to do this in an automatic way you might try the script provided in <xref linkend="bind-chuser" />.
ja: BIND の権限を制限することについては、もし root でないユーザが BIND を 動かしたら、BIND は新しいインターフェイスを自動的に検知できなくなるという ことを知っておかなければなりません。たとえば、PCMCIA カードをラップトップに さしこんだときです。このことについてくわしくは named 文書ディレクトリの README.Debian (<filename>/usr/share/doc/bind/README.Debian</filename>) を ごらんください。BIND に関するセキュリティ問題が最近多くあります。よって ユーザを切りかえることは可能ならば役に立ちます。

en: To run BIND under a different user, first create a separate user and group for it (it is <emphasis>not</emphasis> a good idea to use nobody or nogroup for every service not running as root). In this example, the user and group <literal>named</literal> will be used. You can do this by entering:
ja: BIND を異なるユーザで動かすには、まずそのために別個のユーザおよびグループを 作ってください (root として動いていないサービスすべてに nobody または nogroup を使うのはよい考えでは<emphasis>ありません</emphasis>)。この例では、 <literal>named</literal> というユーザおよびグループが使われます。これはこう入力する ことによって可能です:

en: Now you can either edit <filename>/etc/init.d/bind</filename> with your favorite editor and change the line beginning with
ja: そこであなたのすきなエディタで <literal>/etc/init.d/bind</literal> を編集し、

en: to:
ja: こう変更します:

en: All you need to do now is to restart bind via <literal>/etc/init.d/bind restart</literal>, and then check your syslog for two entries like this:
ja: あと必要なのは「/etc/init.d/bind restart」で bind を再起動し、こういう 2 行が syslog にないかさがすだけです。

en: In order for your Bind daemon to work properly it needs permission in the named files. This is an easy task since the configuration files are always at <literal>/etc/named/</literal>. Take into account that it only needs read-only access to the zone files, unless it is a secondary or cache name server. If this is your case you will have to give read-write permissions to the necessary zones (so that zone transfers from the primary server work).
ja: Bind デーモンが適切に動くためには named ファイルのパーミッションが必要です。 設定ファイルがいつも <literal>/etc/named/</literal> にあるのでこれは容易な作業です。 セカンダリまたはキャッシュネームサーバでなければ、zone ファイルへは 読みとり専用のアクセスだけでいいことを考慮してください、セカンダリまたは キャッシュネームサーバの場合は、(プライマリサーバからの zone transfer が うまくいくように) 必要な zone への読み書き許可を与える必要があります。

en: Also, you can find more information regarding Bind chrooting in the <ulink name="Chroot-BIND-HOWTO" url="http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html" /> (regarding Bind 9) and <ulink name="Chroot-BIND8-HOWTO" url="http://www.tldp.org/HOWTO/Chroot-BIND8-HOWTO.html" /> (regarding Bind 8). This same documents should be available through the installation of the <application>doc-linux-text</application> (text version) or <application>doc-linux-html</application> (HTML version). Another useful document is <ulink url="http://web.archive.org/web/20011024064030/http://www.psionic.com/papers/dns/dns-linux" />.
ja: さらに、Bind を chroot することについては <ulink name="Chroot-Bind-HOWTO" url="http://www.linuxdoc.org/HOWTO/Chroot-Bind-HOWTO.html" /> (Bind 9 について) と <ulink url="http://www.linuxdoc.org/HOWTO/Chroot-Bind8-HOWTO.html" name="Chroot-Bind8-HOWTO" /> (Bind 8 について) にくわしい情報があります。この文書は <application>doc-linux-text</application> (テキスト版) または <application>doc-linux-html</application> (html 版) をインストールすることに よっても利用できます。

en: Securing Apache
ja: Apache を安全にする

en: You can limit access to the Apache server if you only want to use it internally (for testing purposes, to access the <application>doc-central</application> archive, etc.) and do not want outsiders to access it. To do this use the <literal>Listen</literal> or <literal>BindAddress</literal> directives in <filename>/etc/apache/http.conf</filename>.
ja: 内部でのみ使用したいのであって、外部の人にアクセスしてもらいたくないならば (試験用であるとか、<application>doc-central</application> アーカイブにアクセス したいためであるとか...)、 Apache サーバへのアクセスを制限できます。これを行うには <filename>/etc/apache/http.conf</filename> で <literal>Listen</literal> または <literal>BindAddress</literal> ディレクティブを使います。

en: Using Listen:
ja: Listen を使うなら:

en: Using BindAddress:
ja: BindAddress を使うなら:

en: Then restart apache with <literal>/etc/init.d/apache restart</literal> and you will see that it is only listening on the loopback interface.
ja: そして <literal>/etc/init.d/apache restart</literal> で apache を再起動してください。 すると apache が loopback インターフェイスにしか応答しないことが わかるでしょう。

en: In any case, if you are not using all the functionality provided by Apache, you might want to take a look at other web servers provided in Debian like <application>dhttpd</application>.
ja: いずれの場合も、Apache によって提供される機能をすべて使っているのでなければ、 <application>dhttpd</application> のような Debian で提供されている他のウェブサーバを 見てみたくなるかもしれません。

en: The <ulink name="Apache Documentation" url="http://httpd.apache.org/docs/misc/security_tips.html" /> provides information regarding security measures to be taken on Apache web server (this same information is provided in Debian by the <application>apache-doc</application> package).
ja: <ulink url="http://httpd.apache.org/docs/misc/security_tips.html" name="Apache Documentation" /> は Apache ウェブサーバについて行われるべきセキュリティ対策に関する情報を提供しています (Debian では同じ情報が <application>apache-doc</application> パッケージで提供されて います)。

en: Logfiles permissions
ja: ログファイルのパーミッション

en: Securing finger
ja: finger を安全にする

en: If you want to run the finger service first ask yourself if you need to do so. If you do, you will find out that Debian provides many finger daemons (output from <command>apt-cache search fingerd</command>):
ja: もし finger サービスを動かしたいならまずそうするのが必要かどうか考えて ください。もし必要なら、 Debian は多くの finger デーモンを提供しているのが わかるでしょう (<command>apt-cache search fingerd</command> の出力です):

en: efingerd - Another finger daemon for unix, capable of fine-tuning your output.
ja: efingerd - Another finger daemon for unix capable of fine-tuning your out put.

en: xfingerd - BSD-like finger daemon with qmail support.
ja: BSD-like finger daemon with qmail support.

en: <application>ffingerd</application> is the recommended finger daemon if you are going to use it for a public service. In any case, you are encouraged to, when setting it up through inetd, xinetd or tcpserver to: limit the number of processes that will be running at the same time, limit access to the finger daemon from a given number of hosts (using tcp wrappers) and having it only listening to the interface you need it to be in.
ja: 公開のサービスに finger デーモンを使うなら <application>ffingerd</application> が 推奨されています。いずれにせよ、inetd、xinetd または tcpserver を通じて finger デーモンを設置するときにはこうすることをおすすめします: 同時に動くことができるプロセスの個数を制限し、(tcp wrapper を使って) あるホストからの finger デーモンへのアクセスを制限し、必要なインターフェイス だけに応答するようにしましょう。

en: General chroot and suid paranoia
ja: 一般的な chroot および suid のパラノイア

en: <command>chroot</command> is one of the most powerful possibilities to restrict a daemon or a user or another service. Just imagine a jail around your target, which the target cannot escape from (normally, but there are still a lot of conditions that allow one to escape out of such a jail). You can eventually create a modified root environment for the user or service you do not trust. This can use quite a bit of disk space as you need to copy all needed executables, as well as libraries, into the jail. But then, even if the user does something malicious, the scope of the damage is limited to the jail.
ja: <command>chroot</command> はデーモンやユーザやその他のサービスを制限するための 最も強力な可能性のひとつです。対象のまわりに檻があると考えてください。 対象はここから逃げることができません (ふつうはできませんが、このような 檻がら逃げだすことを可能にする条件はいくつもあります)。もしユーザを信用 しないのであれば、そのユーザのために chroot された環境を作ることができます。 檻の中にライブラリとともに必要な実行ファイルをすべてコピーしなければ ならないので、これはディスクスペースを大量に消費するかもしれません。 たとえそのユーザが何か悪事をはたらいても、被害の範囲はその檻に限定されます。

en: However, be forewarned that a <command>chroot</command> jail can be broken if the user running in it is the superuser. So, you need to make the service run as a non-privileged user. By limiting its environment you are limiting the world readable/executable files the service can access, thus, you limit the possibilities of a privilege escalation by use of local system security vulnerabilities. Even in this situation you cannot be completely sure that there is no way for a clever attacker to somehow break out of the jail. Using only server programs which have a reputation for being secure is a good additional safety measure. Even minuscule holes like open file handles can be used by a skilled attacker for breaking into the system. After all, <command>chroot</command> was not designed as a security tool but as a testing tool.
ja: しかし、<command>chroot</command> はそこで動いているユーザがスーパーユーザなら 破られる可能性があることに注意してください。だから、サービスは非特権ユーザと して動かす必要があります。環境を制限することによってそのサービスが アクセスできる、世界中から読める (または実行できる) ファイルを制限して いることになります。こうしてあなたのシステムにあるローカルのセキュリティ上の 脆弱性を使った、権限の昇進の可能性を制限するわけです。この場合でも、 かしこい攻撃者がこの檻を破る方法が全くないとは言えません。安全だという 評判があるサーバプログラムだけを使うのは安全のための追加の手段としてよいです。 オープンファイルハンドルのような非常に小さなセキュリティホールでも 熟練した攻撃者によってシステムを破るのに使われる可能性があります。 結局、<command>chroot</command> はセキュリティ関連の道具としてではなく試験用の 道具として設計されたのです。

en: General cleartext password paranoia
ja: 一般的な平文パスワードのパラノイア

en: You should try to avoid any network service which sends and receives passwords in cleartext over a net like FTP/Telnet/NIS/RPC. The author recommends the use of ssh instead of telnet and ftp to everybody.
ja: FTP、Telnet、NIS、RPC のような、ネット上でパスワードを平文で送ったり 受けとったりするネットワークサービスをすべて避けるべきです。この HOWTO の 著者は telnet や ftp のかわりに ssh を使うことを全員にすすめます。

en: Keep in mind that migrating from telnet to ssh, but using other cleartext protocols does not increase your security in ANY way! Best would be to remove ftp, telnet, pop, imap, http and to supersede them with their respective encrypted services. You should consider moving from these services to their SSL versions, ftp-ssl, telnet-ssl, pop-ssl, https ...
ja: telnet から ssh に移行しても、他の平文プロトコルを使うのではセキュリティは 「すこしも」向上しないことに気をつけてください。最善なのは ftp、telnet、 pop、imap、http を取りのぞいて対応する暗号化サービスで置きかえることでしょう。 これらのサービスから ftp-ssl、telnet-ssl、pop-ssl、https などのような SSL バージョンに移行することを検討するべきです。

en: Most of these above listed hints apply to every Unix system (you will find them if reading any other hardening-related document related to Linux and other Unices).
ja: 上にあげたヒントの多くはすべての Unix システムにあてはまります (Linux や その他の Unixes についての強化関連の文書をほかに読んでいればそれに気が つくでしょう)。

en: Disabling NIS
ja: NIS を無効にする

en: You should not use NIS, the Network Information Service, if possible, because it allows password sharing. This can be highly insecure if your setup is broken.
ja: もし可能なら、NIS、すなわち Network Information Service を使うべきでは ありません。なぜならそれはパスワードの共有を可能にするからです。設定が まちがっていたらこれはきわめて危険になります。

en: If you need password sharing between machines, you might want to consider using other alternatives. For example, you can setup an LDAP server and configure PAM on your system in order to contact the LDAP server for user authentication. You can find a detailed setup in the <ulink name="LDAP-HOWTO" url="http://www.tldp.org/HOWTO/LDAP-HOWTO.html" /> (<filename>/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz</filename>).
ja: 複数のマシン間でパスワードの共有が必要なら、他の選択肢を使うことを考えたく なるかもしれません。たとえば、LDAP サーバを設置してユーザ認証用にその LDAP サーバに接触するためにあなたのシステムの PAM を設定することができます。 設定の詳細は <ulink url="http://www.linuxdoc.org/HOWTO/LDAP-HOWTO.html" name="LDAP-HOWTO" /> (<filename>/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz</filename>) をごらんください。

en: You can read more about NIS security in the <ulink name="NIS-HOWTO" url="http://www.tldp.org/HOWTO/NIS-HOWTO.html" /> (<filename>/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz</filename>).
ja: NIS のセキュリティについてくわしくは <ulink url="http://www.linuxdoc.org/HOWTO/NIS-HOWTO.html" name="NIS-HOWTO" /> (<filename>/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz</filename>) を ごらんください。

en: FIXME (jfs): Add info on how to set this up in Debian.
ja: FIXME (jfs): これを Debian で設定する方法についての情報を加える

en: Disabling RPC services completely
ja: RPC サービスを無効にする

en: Disabling portmap is quite simple. There are several different methods. The simplest one in a Debian 3.0 system and later releases is to uninstall the <application>portmap</application> package. If you are running an older Debian version you will have to disable the service as seen in <xref linkend="disableserv" />, because the program is part of the <application>netbase</application> package (which cannot be de-installed without breaking the system).
ja: portmap を停止することは非常に簡単です。いくつかの方法があります。Debian 3.0 システムで最も簡単なのは <application>portmap</application> パッケージを アンイントールすることです。他のバージョンを使っているなら <xref linkend="disableserv" /> にあるようにしてサービスを無効にする必要があるでしょう。 これは portmap が <application>net-base</application> パッケージ (システムを壊すこと なくこれをアンインストールすることはできません) の一部であるためです。

en: Adding firewall capabilities
ja: ファイアウォール機能を追加する

en: Firewalling the local system
ja: ローカルシステムをファイアウォールで守る

en: You can use firewall rules as a way to secure the access to your local system and, even, to limit the outbound communications made by it. Firewall rules can also be used to protect processes that cannot be properly configured <emphasis>not</emphasis> to provide services to some networks, IP addresses, etc.
ja: ファイアウォール規則をローカルシステムへのアクセスを安全にし、さらにそこで 行われる外向きのやりとりを制限する方法として使うことができます。 ファイアウォール規則はサービスをあるネットワーク、IP アドレスなどにだけ 提供するように適切に設定<emphasis>できない</emphasis>プロセスを守るのにも使えます。

en: However, this step is presented last in this manual basically because it is <emphasis>much</emphasis> better not to depend solely on firewalling capabilities in order to protect a given system. Security in a system is made up of layers, firewalling should be the last to include, once all services have been hardened. You can easily imagine a setup in which the system is solely protected by a built-in firewall and an administrator blissfully removes the firewall rules for whatever reason (problems with the setup, annoyance, human error...), this system would be wide open to an attack if there were no other hardening in the system to protect from it.
ja: しかし、主にシステムを守るためにファイアウォール機能だけに頼らないほうが <emphasis>ずっと</emphasis>よいという理由により、この段階はこのマニュアルの最後に 書かれています。システムのセキュリティは層によって構成されています。 ファイアウォールは最後に、すべてのサービスが強化されたあとで取りいれる べきです。システムが組みこみのファイアウォールでしか守られていない設定なのに 管理者が喜んでファイアウォール規則を何らかの理由で (設定に問題があるとか、 気にくわないとか、まちがえてとか...) 削除してしまうことが容易に想像できます。 このようなシステムは攻撃にさらされることになるでしょう。

en: Using a firewall to protect other systems
ja: 他のシステムを守るのにファイアウォールを使う

en: If you do not have a clue on how to set up your firewall rules manually consult the <emphasis>Packet Filtering HOWTO</emphasis> and <emphasis>NAT HOWTO</emphasis> provided by <application>iptables</application> for offline reading at <filename>/usr/share/doc/iptables/html/</filename>.
ja: ファイアウォール規則をどうやって設定するべきかわからないなら <emphasis>Packet Filtering HOWTO</emphasis> を読んでください。これは <application>iptables</application> をインストールすると <filename>/usr/share/doc/iptables/html/</filename> でオフラインで読めます。

en: Using firewall packages
ja: ファイアウォールパッケージ

en: Some software that can be used to set up firewall rules in a Debian system is:
ja: Debian システムでファイアウォール規則を設定するのに使える ソフトウェアはいろいろあります:
