Product SiteDocumentation Site

第 5 章 增强系统上运行服务的安全性

5.1. ssh 安全化
5.1.1. Chrooting ssh
5.1.2. ssh 客户端
5.1.3. 禁止文件传送
5.1.4. Restricing access to file transfer only
5.2. Squid 安全化
5.3. FTP 安全化
5.4. 对 X 窗口系统的安全访问
5.4.1. 检查您的显示管理器
5.5. Securing printing access (the lpd and lprng issue)
5.6. 邮件服务的安全化
5.6.1. 配置 Nullmailer
5.6.2. 提供对邮箱的安全访问
5.6.3. 安全的接收邮件
5.7. 增强 BIND 的安全性
5.7.1. 配置Bind以防误用
5.7.2. 管理 BIND 用户
5.7.3. 使名称服务器运行于 chroot 环境
5.8. 增加 Apache 的安全性
5.8.1. 禁止用户发布 web 内容
5.8.2. 日志文件权限
5.8.3. 发布 web 文件
5.9. 增强 finger 的安全性
5.10. 常用 chroot 和 suid
5.10.1. 自动配置 chroot 环境
5.11. 明文密码
5.12. 禁用 NIS
5.13. 增强 RPC 服务的安全性
5.13.1. Disabling RPC services completely
5.13.2. Limiting access to RPC services
5.14. 增加防火墙
5.14.1. 为本地系统构建放火墙
5.14.2. 使用防火墙保护其它系统
5.14.3. Setting up a firewall
  • 使其只能通过它们应当所在的访问点(接口)访问.
  • 正确配置, 使其只能由合法的用户使用授权方式访问.
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.
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
        bind            =

5.1. ssh 安全化

如果您仍然使用 telnet, 而不是 ssh, 则需要改变对本手册的阅读方式. 应当用 ssh 来取代所有的 telnet 远程登录. 任何时候通过嗅探互联网通讯来获取明文密码都是相当简单的, 您应该采用使用加密算法的协议. 那么, 现在在你的系统上执行 apt-get install ssh .
鼓励您系统上的所有用户使用 ssh 取代 telnet, 或者更进一步, 卸载 telnet/telnetd. 另外您应该避免使用 ssh 以 root 身份登录, 其替代的方法是使用 susudo 转换成 root 用户. 最后, /etc/ssh 目录下的 sshd_config 文件, 应当作如下修改, 以增强安全性:
  • ListenAddress 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).
  • PermitRootLogin no 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.
  • Port 666 or ListenAddress 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.
  • AllowGroups wheel admin 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".
  • PasswordAuthentication yes 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 ~/.ssh/authorized_keys file. If you want so, set this one to "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 or the
  • 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 sense=allow onerr=fail item=user file=/etc/loginusers
最后, 应当注意那些存放 OpenSSH 配置文件的目录. 现在, 有三种常用的 SSH 守护进程, ssh1, ssh2, 和 OpenBSD 用户使用的 OpenSSH. ssh1 是第一个可以使用的 ssh 守护进程, 并且仍然有很大的用户群(甚至谣传有windows版本). ssh2 和 ssh1 相比有更多高级特性, 但是它是基于保留源代码协议的. OpenSSH 是完全自由的 ssh 守护进程, 它支持 ssh1, 和 ssh2. OpenSSH 是在 Debian 系统中选择安装的 ssh 软件包.
You can read more information on how to set up SSH with PAM support in the

5.1.1. Chrooting ssh

当前的 OpenSSH 没有提供用户连接后自动完成 chroot 的方法(商业版本提供这种功能). 但是有个项目为 OpenSSH 提供这种功能,参见, 尽管它不在当前 Debian 的软件包中. 然而, 您可以使用 pam_chroot 模块,如 第 4.11.15 节 “限制用户访问” 所述.
In 第 B.7 节 “Chroot environment for SSH you can find several options to make a chroot environment for SSH.

5.1.2. ssh 客户端

如果您使用的 SSH 客户端不能访问 SSH 服务器, 则需要确认是否支持在服务器端被强制执行的协议. 例如, 如果您使用了只支持 version 1 协议的 mindterm 软件包. 但是 sshd 服务器默认配置为只接受 version 2 协议(基于安全的原因).

5.1.3. 禁止文件传送

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:
  • 禁止用户通过 login 登录 ssh 服务器(如上所述或通过配置文件或PAM 配置).
  • 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.