Product SiteDocumentation Site

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

5.1. ssh を使う
5.1.1. Chrooting ssh
5.1.2. Ssh clients
5.1.3. Disallowing file transfers
5.1.4. Restricing access to file transfer only
5.2. Squid を安全にする
5.3. FTP を安全にする
5.4. X Window System へのアクセスを安全にする
5.4.1. ディスプレイマネージャを調べる
5.5. プリントサービスを安全にする (lpd と lprng の問題)
5.6. Securing the mail service
5.6.1. Configuring a Nullmailer
5.6.2. Providing secure access to mailboxes
5.6.3. メールを安全に受けとる
5.7. BIND を安全にする
5.7.1. Bind configuration to avoid misuse
5.7.2. Changing BIND's user
5.7.3. Chrooting the name server
5.8. Apache を安全にする
5.8.1. Disabling users from publishing web contents
5.8.2. ログファイルのパーミッション
5.8.3. Published web files
5.9. finger を安全にする
5.10. 一般的な chroot および suid のパラノイア
5.10.1. Making chrooted environments automatically
5.11. 一般的な平文パスワードのパラノイア
5.12. NIS を無効にする
5.13. Securing RPC services
5.13.1. RPC サービスを無効にする
5.13.2. Limiting access to RPC services
5.14. ファイアウォール機能を追加する
5.14.1. ローカルシステムをファイアウォールで守る
5.14.2. 他のシステムを守るのにファイアウォールを使う
5.14.3. Setting up a firewall
すでに動いているシステム上でサービスを安全にする方法は 2 通りあります:
  • 必要とされるアクセスポイント (インターフェイス) でのみアクセス できるようにする。
  • 適切に設定して正当なユーザだけが認められているやり方でのみ 使えるようにする。
ある場所からのみアクセスできるようにサービスを制限するのはカーネルレベルで (すなわち、ファイアウォールで) アクセスを制限すること、あるインターフェイスに だけ応答するように設定すること (この機能を提供しないサービスもあります) またはその他の方法を使うことによって可能です。たとえば linux vserver パッチは プロセスがインターフェイスをひとつしか使わないように強制するのに使えます。
Regarding the services running from inetd (telnet, ftp, finger, pop3...) it is worth noting that inetd can be configured so that services only listen on a given interface (using service@ip syntax) but that's an undocumented feature. One of its substitutes, the xinetd meta-daemon includes a bind option just for this matter. See ixnetd.conf(5) manual page.
service nntp
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = news
        group           = news
        server          = /usr/bin/env
        server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
+/usr/sbin/snntpd logger -p news.info
        bind            = 127.0.0.1
}
以下の章は特定のサービスを意図されている用途にしたがってどのように適切に 設定できるかの詳細を論じます。

5.1. ssh を使う

もし ssh のかわりにまだ telnet を動かしているなら、このマニュアルを読むのを やめてそれを変更するべきです。リモートログインにはすべて telnet のかわりに Ssh を用いるべきです。インターネットのトラフィックを盗聴して平文の パスワードを得ることが簡単にできる時代には、暗号を使うプロトコルだけを 使うべきです。よって、あなたのシステムでただちに apt-get install ssh を実行しましょう。
あなたのシステムのすべてのユーザに telnet のかわりに ssh を使うことを すすめましょう。よりよいのは telnet や telnetd をアンインスールすることです。 さらに ssh を使って root としてシステムにログインすることを避け、susudo のような、root になるためのかわりの手段を使いましょう。 最後に、セキュリティを向上させるために /etc/ssh 中のファイル sshd_config を 変更するべきです:
  • ふたつ以上のインターフェイスがあるかもしれないので (そこで ssh を利用 可能にはしたくないなら)、または将来新しいネットワークカードを追加するのに そなえて (そしてそこからの ssh 接続を望まないなら)、ssh をある インターフェイスにだけ応答するようにしましょう。
  • 可能なら Root のログインをいつでも禁止するべきです。ssh 経由で root に なりたいなら、こうすると 2 回のログインが必要になり、root のパスワードを SSH 経由で力まかせに推測することができなくなります。
  • Port 666 or ListenAddress 192.168.0.1:666 Change the listen port, so the intruder cannot be completely sure whether a sshd daemon runs (be forewarned, this is security by obscurity).
  • PermitEmptyPasswords no Empty passwords make a mockery of system security.
  • AllowUsers alex ref me@somewhere Allow only certain users to have access via ssh to this machine. user@host can also be used to restrict a given user from accessing only at a given host.
  • 特定のグループのメンバーだけが ssh 経由でこのマシンにアクセスできるように しましょう。AllowGroups と AllowUsers にはアクセスを拒否するための同様の ディレクティブがあります。驚くべきことでもなく、それは「DenyUsers」や 「DenyGroups」と呼ばれています。
  • 何をしたいかは完全にあなたが選べます。ssh の鍵をファイル ~/.ssh/authorized_keys に置いているユーザからのマシンへのアクセスだけを 許可するほうがより安全です。もしそうしたいなら、これを「no」に設定して ください。
  • Disable any form of authentication you do not really need, if you do not use, for example RhostsRSAAuthentication, HostbasedAuthentication, KerberosAuthentication or RhostsAuthentication you should disable them, even if they are already by default (see the manpage sshd_config(5) manual page).
  • Protocol 2 Disable the protocol version 1, since it has some design flaws that make it easier to crack passwords. For more information read http://earthops.net/ssh-timing.pdf or the http://xforce.iss.net/static/6449.php.
  • Banner /etc/some_file Add a banner (it will be retrieved from the file) to users connecting to the ssh server. In some countries sending a warning before access to a given system about unauthorized access or user monitoring should be added to have legal protection.
You can also restrict access to the ssh server using pam_listfile or pam_wheel in the PAM control file. For example, you could keep anyone not listed in /etc/loginusers away by adding this line to /etc/pam.d/ssh:
auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers
最後に、これらのディレクティブは OpenSSH のものであることに注意してください。 現時点では、広く使われている SSH デーモンは 3 種類あります。ssh1、ssh2 そして OpenBSD の人たちによる OpenSSH です。Ssh1 は利用できる最初の ssh デーモンでした。そして依然として最も広く使われています (windows への 移植版さえあるといううわさです)。Ssh2 はソース非公開のライセンスで リリースされていることを除けば ssh1 より多くの長所があります。OpenSSH は 「ssh」が選択されたとき Debian にインストールされるバージョンです。
You can read more information on how to set up SSH with PAM support in the http://lists.debian.org/debian-security/2001/11/msg00395.html.

5.1.1. Chrooting ssh

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

5.1.2. Ssh clients

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

5.1.3. Disallowing file transfers

If you do not want users to transfer files to and from the ssh server you need to restrict access to the sftp-serverand the scp access. You can restrict sftp-server by configuring the proper Subsystem in the /etc/ssh/sshd_config.
You can also chroot users (using libpam-chroot so that, even if file transfer is allowed, they are limited to an environment which does not include any system files.

5.1.4. Restricing access to file transfer only

You might want to restrict access to users so that they can only do file transfers and cannot have interactive shells. In order to do this you can either:
  • disallow users from login to the ssh server (as described above either through the configuration file or PAM configuration).
  • give users a restricted shell such as scponly or rssh. These shells restrict the commands available to the users so that they are not provided any remote execution priviledges.