ある場所からのみアクセスできるようにサービスを制限するのはカーネルレベルで (すなわち、ファイアウォールで) アクセスを制限すること、あるインターフェイスに だけ応答するように設定すること (この機能を提供しないサービスもあります) またはその他の方法を使うことによって可能です。たとえば 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
}
もし ssh のかわりにまだ telnet を動かしているなら、このマニュアルを読むのを やめてそれを変更するべきです。リモートログインにはすべて telnet のかわりに Ssh を用いるべきです。インターネットのトラフィックを盗聴して平文の パスワードを得ることが簡単にできる時代には、暗号を使うプロトコルだけを 使うべきです。よって、あなたのシステムでただちに apt-get install ssh を実行しましょう。
あなたのシステムのすべてのユーザに telnet のかわりに ssh を使うことを すすめましょう。よりよいのは telnet や telnetd をアンインスールすることです。 さらに ssh を使って root としてシステムにログインすることを避け、
su や
sudo のような、root になるためのかわりの手段を使いましょう。 最後に、セキュリティを向上させるために /etc/ssh 中のファイル sshd_config を 変更するべきです:
ふたつ以上のインターフェイスがあるかもしれないので (そこで ssh を利用 可能にはしたくないなら)、または将来新しいネットワークカードを追加するのに そなえて (そしてそこからの ssh 接続を望まないなら)、ssh をある インターフェイスにだけ応答するようにしましょう。
可能なら Root のログインをいつでも禁止するべきです。ssh 経由で root に なりたいなら、こうすると 2 回のログインが必要になり、root のパスワードを SSH 経由で力まかせに推測することができなくなります。
Port 666 or ListenAddress 192.168.0.1:666 Change the listen port, so the intruder cannot be completely sure whether a sshd daemon runs (be forewarned, this is security by obscurity).
PermitEmptyPasswords no Empty passwords make a mockery of system security.
AllowUsers alex ref me@somewhere Allow only certain users to have access via ssh to this machine. user@host can also be used to restrict a given user from accessing only at a given host.
特定のグループのメンバーだけが ssh 経由でこのマシンにアクセスできるように しましょう。AllowGroups と AllowUsers にはアクセスを拒否するための同様の ディレクティブがあります。驚くべきことでもなく、それは「DenyUsers」や 「DenyGroups」と呼ばれています。
何をしたいかは完全にあなたが選べます。ssh の鍵をファイル ~/.ssh/authorized_keys に置いているユーザからのマシンへのアクセスだけを 許可するほうがより安全です。もしそうしたいなら、これを「no」に設定して ください。
Disable any form of authentication you do not really need, if you do not use, for example RhostsRSAAuthentication, HostbasedAuthentication, KerberosAuthentication or RhostsAuthentication you should disable them, even if they are already by default (see the manpage sshd_config(5) manual page).
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 にインストールされるバージョンです。
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
第 4.11.15 節「ユーザを制限する」.
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.
