Question

客户端的数据经过网络层的过滤后到达了应用程序，应用程序对客户端的数据进行解析和处理。应用层的安全措施，主要包括对账号密码的保护、SSHD 的安全配置、Web 服务器安全、数据库安全、BIND 的安全配置等。通过这些措施，可以防止非授权的访问、避免数据被非法泄露以及提高系统安全性和可用性。以下的各个小节会对应用层安全措施进行详细讲解。

密码安全策略

在需要认证客户端的应用程序中，目前使用比较多的仍然是通过用户输入账号和密码来进行确认，例如登录 SMTP 邮箱、登录微博和购物网站结算等。制定一个科学有效的密码策略可以从以下方面进行。

- 立即修改系统默认密码。有部分的开源软件或者商业硬件，在初始交付的时候，会内置默认密码，以方便管理员进行配置。运维工程师们，在接触此类软件或者硬件时，初始化的第一步一定是修改默认密码。

- 对测试账号严格要求。很多开发人员或者测试人员，为了简便性考虑，喜欢用非常简单的账号和密码来测试系统，使用 12345678 类似账号的情况屡见不鲜。殊不知，这样就给系统留下了一个“定时炸弹”。在系统上线后可能因为某些测试账号被黑客所入侵。因此倡议，即使是创建测试账号，也一定要符合密码安全策略。

- 密码符合一定的复杂度。如果系统被外部用户所使用，那需要教育和提醒用户不要使用包含有生日或者身份证号码的密码，更不要和用户名相同。推荐使用密码生成器作为服务器系统的密码，例如 Keepass（官网：keepass.info）等。如图 11-3 所示，生成 8 位包含了数字、大小写和下划线的随机密码。

- 密码加密存储。在 Keepass 中，所有密码以加密方式存储。这样就可以防止电脑丢失时或者被恶意软件入侵后明文密码被泄露的情况。

- 定期更换密码。

- 使用验证码防止黑客使用密码工具进行保留破解。一个在线提供验证码服务的是 reCAPTCHA 项目。

- 使用密码检查工具，对服务器系统等密码进行定期检查，防止弱密码的使用。例如使用 John the Ripper 等工具，可以对系统密码强度进行检查。

- 在发布共享文档时，把涉及密码的敏感信息加以处理。在使用搜索引擎的时候，很多文档里面会泄露这样那样的账号信息，这个需要引起运维人员的注意。

图 11-3　使用 Keepass 生成强密码

SSHD 安全配置

SSHD，对于 Linux、UNIX 运维工程师来说是最为熟悉的服务之一。运维工程师们通过 SSHD 去使用命令行管理和配置服务器。作为最重要的管理通道，保障 SSHD 的安全，成为 Linux 安全的重要部分。本节将通过以下几个方面介绍 SSHD 的安全配置。

- 使用 TCP Wrappers 增加安全性。

- SSHD 的安全配置项。

- PAM 增加系统安全性。

1.使用 TCP Wrappers 增加安全性

TCP Wrappers 是一个基于主机的 ACL 系统，它被用来过滤对 Linux、UNIX 系统提供的网络服务的访问。它通过 libwrap 向 daemon 进程提供过滤功能。

对于一个应用程序是否使用了 libwrap 的功能，可以使用如下方法来确认。

以 SSHD 为例：

[root@ossec-server ~]# ldd /usr/sbin/sshd 
     linux-vdso.so.1 =>  (0x00007fffbdca8000)
     libwrap.so.0 => /lib64/libwrap.so.0 (0x00002ac7a9ed9000) #连接到了 libwrap，可以使用 TCP Wrappers 进行防护
     libpam.so.0 => /lib64/libpam.so.0 (0x00002ac7aa0e2000)
     libdl.so.2 => /lib64/libdl.so.2 (0x00002ac7aa2ee000)
     libselinux.so.1 => /lib64/libselinux.so.1 (0x00002ac7aa4f2000)
     libaudit.so.0 => /lib64/libaudit.so.0 (0x00002ac7aa70a000)
     libfipscheck.so.1 => /usr/lib64/libfipscheck.so.1 (0x00002ac7aa923000)
     libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002ac7aab25000)
     libutil.so.1 => /lib64/libutil.so.1 (0x00002ac7aae77000)
     libz.so.1 => /lib64/libz.so.1 (0x00002ac7ab07b000)
     libnsl.so.1 => /lib64/libnsl.so.1 (0x00002ac7ab28f000)
     libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002ac7ab4a7000)
     libresolv.so.2 => /lib64/libresolv.so.2 (0x00002ac7ab6e0000)
     libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002ac7ab8f5000)
     libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002ac7abb23000)
     libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002ac7abdb9000)
     libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002ac7abfde000)
     libnss3.so => /usr/lib64/libnss3.so (0x00002ac7ac1e0000)
     libc.so.6 => /lib64/libc.so.6 (0x00002ac7ac514000)
     /lib64/ld-linux-x86-64.so.2 (0x000000325b200000)
     libsepol.so.1 => /lib64/libsepol.so.1 (0x00002ac7ac86d000)
     libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002ac7acab4000)
     libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002ac7accbc000)
     libnssutil3.so => /usr/lib64/libnssutil3.so (0x00002ac7acebe000)
     libplc4.so => /usr/lib64/libplc4.so (0x00002ac7ad0e9000)
     libplds4.so => /usr/lib64/libplds4.so (0x00002ac7ad2ed000)
     libnspr4.so => /usr/lib64/libnspr4.so (0x00002ac7ad4f0000)
     libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ac7ad72c000)
     librt.so.1 => /lib64/librt.so.1 (0x00002ac7ad948000)

TCP Wrappers 的工作流程如下。

1）它读取/etc/hosts.allow，如果能匹配到策略，则允许；否则进行下一步。

2）它读取/etc/hosts.deny，如果能匹配到策略，则拒绝；否则允许。

以只允许 10.0.0.0/8 访问 SSHD 为例，以上 2 个文件的内容分别是：

# cat /etc/hosts.allow
sshd:10.0.0.0/255.0.0.0
# cat /etc/hosts.deny
sshd:ALL

2.SSHD 的安全配置项

在实践中，以下 SSHD 配置项是关系到安全的重要配置。

- PermitRootLogin：是否允许 root 用户登录。建议设置为 no。同时新增一个用于登录的账号如 myadmin，赋予 sudo 权限。禁用 root 登录，能直接减少黑客暴力破解的威胁。

- RSA Authentication、Pubkey Authentication：公钥私钥认证。建议设置为 no。统一强制用户使用密码登录。公钥私钥认证带来便利性的同时，也会因为密钥泄露或者密钥没有密码保护而出现安全问题。

3.使用 PAM 增加系统安全性

PAM（Pluggable Authentication Modules for Linux，Linux 可插拔的认证模块）是一组共享库来支持系统对管理员的认证。通过 SSHD 结合 PAM，可以实现以下功能。

- 结合 LDAP 进行统一认证。

- 使用动态口令卡，防止静态密码泄露的问题。

在 sshd_config 中，使用如下指令启用 PAM：

UsePAM yes

PAM 配置文件的格式如下：

# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth requisite pam_unix.so nullok try_first_pass #首先必须通过系统的账号密码认证
auth sufficient /lib64/security/pam_ekey.so #在此处，我们可以定义自己的 PAM 处理逻辑，如动态口令、管理员额外信息认证等
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so

Web 服务器安全

Web 服务器对外部提供网络访问服务，只要拥有一台可以联网的计算机，黑客就可以对 Web 服务器进行不断的入侵尝试。

1.常见的攻击方法

首先来了解下目前常见的针对 Web 服务器的攻击方法。

（1）URL 解析错误

在 2010 年曾经发生过一个 Nginx 解析的问题，导致大量基于 Nginx+PHP 的网站被入侵。

漏洞介绍：Nginx 是一款高性能的 Web 服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好地支持 PHP 的运行。默认情况下可能导致服务器错误地将任何类型的文件以 PHP 的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持 PHP 的 Nginx 服务器。

漏洞分析：Nginx 默认以 cgi 的方式支持 PHP 的运行，譬如在配置文件当中可以以如下的方式支持对 PHP 的解析，location 对请求进行选择的时候会使用 URI 环境变量进行选择，其中传递到后端 Fastcgi 的关键变量 SCRIPT_FILENAME 由 nginx 生成的$fastcgi_script_name 决定，而通过分析可以看到$fastcgi_script_name 是直接由 URI 环境变量控制的，这里就是产生问题的点。而为了较好地支持 PATH_INFO 的提取，在 PHP 的配置选项里存在 cgi.fix_pathinfo 选项，其目的是为了从 SCRIPT_FILENAME 里取出真正的脚本名。

location ~ \.php$ {
    root html;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    include fastcgi_params;
}

那么假设存在一个 http://www.xxx.com/xxx.jpg ，以如下的方式去访问将会得到一个 URI/xxx.jpg/xxx.php。

http://www.xxx.com/xxx.jpg/xxx.php

经过 location 指令，该请求将会交给后端的 fastcgi 处理，Nginx 为其设置环境变量 SCRIPT_FILENAME，内容为/scripts/xxx.jpg/xxx.php。而在其他的 WebServer 如 Lighttpd 当中，发现其中的 SCRIPT_FILENAME 被正确的设置为/scripts/xxx.jpg，所以不存在此问题。

后端的 fastcgi 在接到该选项时，会根据 fix_pathinfo 配置决定是否对 SCRIPT_FILENAME 进行额外的处理，一般情况下如果不对 fix_pathinfo 进行设置将影响使用 PATH_INFO 进行路由选择的应用，所以该选项一般配置开启。PHP 通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出 SCRIPT_FILENAME 和 PATH_INFO，分别为/scripts/xxx.jpg 和 xxx.php。最后，以/scripts/xxx.jpg 作为此次请求需要执行的脚本，攻击者就可以实现让 Nginx 以 PHP 来解析任何类型的文件了。

访问一个 Nginx 来支持 PHP 的站点，在一个任何资源的文件如 robots.txt 后面加上/xxx.php，这个时候可以看到如下区别。

访问 http://www.xxx.com/robots.txt ：

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:05:30 GMT
Content-Type: text/plain
Content-Length: 18
Last-Modified: Thu, 20 May 2010 06:26:34 GMT
Connection: keep-alive
Keep-Alive: timeout=20
Accept-Ranges: bytes

访问 http://www.xxx.com/robots.txt/xxx.php ：

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:06:49 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.6

其中的 Content-Type 的变化说明了后端负责解析的变化，该站点就可能存在漏洞。

（2）目录遍历

往往是因为服务器设置不够严格导致黑客可以直接看到所有网站的目录结构。

（3）获取非 Web 文件

非 Web 文件包括以下几种。

- 打包文件（.zip，.tar.gz 等）。

- 备份文件（.bak 等）。

- header 文件（.inc 等）。

这些文件可能包含有关键信息，例如数据库连接字符串设置、接口 IP 地址和账号等，被非法获取后将直接导致信息泄露。

（4）源代码泄露

在服务器配置错误或者发生解析异常时，黑客可以直接获得源代码。

（5）SQL 注入

黑客通过对 URL 或者输入表单的字段进行恶意构造，使得应用程序把参数直接构造成 SQL 语句传入数据库服务器，导致被“脱库”。

2.使用 ModSecurity 加固 Web 服务器

在介绍了 5 种常见的针对 Web 应用程序的攻击类型后，现在使用 ModSecurity 来进行针对性的加固。

部署 ModSecurity 后的逻辑架构图如图 11-4 所示。

图 11-4　部署 ModSecurity 逻辑架构图

ModSecurity 是 Web 应用层防火墙（Web Application Firewall，WAF）。为了增加 Web 应用程序的安全性，需要使用 WAF 来检测和阻止恶意请求到达 Web 应用程序。ModSecurity 对 HTTP 流量进行实时分析，通过其内置的一系列规则来抵抗攻击。ModSecurity 最早是基于 Apache 进行开发，作为 Apache 的模块发布。后期增加了对 Nginx 和 IIS 等 Web 服务器的支持。

ModSecurity 的强大之处在于，它内置了 HTTP 层的攻击请求判断规则，例如 HTTP 协议遵从性的判断规则、SQL 注入的判断规则等。ModSecurity 的规则下载地址是 https://github.com/SpiderLabs/owasp-modsecurity-crs 。

数据库安全策略

数据库服务器上存储了应用程序记录的核心数据，保障数据库安全，一般可以从以下方面进行。

- 删除安装后的测试数据库。在 MySQL 中，数据库初始安装完成后，会生成一个 test 库，直接删除即可。

- 检查数据库的密码。通过如下语句，可以检查出没有配置密码的账号。

select User,Host,Pasword from mysql.user where Password='';

- 数据库授权。采用权限最小化原则，对应用程序使用分级授权。对于只需要读的账号，仅仅授予 SELECT 权限。

BIND 安全配置

BIND 是 Linux 系统中最重要的域名解析服务软件，也是全球使用量最大的。BIND 的安全配置主要集中在以下两个方面。

- 对于权威服务器，设置 recursion no。

- BIND 服务器 Crash 的问题。

在 2015 年 8 月，曾经发生过一起针对 BIND 的攻击，攻击者通过构造恶意 DNS 请求，导致权威服务器 BIND 进程挂掉，无法对外提供解析服务。

BIND 服务器的所有漏洞信息可以关注：

BIND 9 Security Vulnerability Matrix，URL https://kb.isc.org/article/AA-00913/74/BIND-9-Security-Vulnerability-Matrix.html 。

通过关注该发布，应及时分析和判断自己使用的 BIND 版本是否需要升级。