随着互联网的不断发展，Web应用的规模和复杂性也在不断增加。Nginx作为一款高性能开源Web服务器软件，经过多年发展，已成为全球最流行的Web服务器之一，其自身的安全性尤为重要。
Nginx是由伊戈尔·赛索耶夫（Igor Sysoev）2002年开发的一款开源高性能Web服务器软件，他在俄罗斯第二大型门户网站和搜索引擎Rambler.ru工作时，为了解决C10K问题（即同时支持上万并发连接），使用C语言开发了Nginx，使她天生具有轻量级和高并发等特点，第一个开源版本0.1.0发布于2004年10月，其将源代码以类BSD许可证的形式发布，因她的稳定性、丰富的功能集、简单的配置文件和低系统资源消耗而闻名于世。
Nginx可以提供HTTP服务，包括处理静态文件，支持SSL(提供HTTPS访问)、GZIP(网页压缩)、虚拟主机、URL重写等功能，可搭配FastCGI程序(如PHP)处理动态请求。除此之外，Nginx还可以用于基本的代理、反向代理、负载均衡、缓存等服务器功能，在集群环境中解决网络负载、提高可用性等。其在BSD-like 协议下发行，可以在UNIX、Linux、macOS、Solaris以及Windows等多种操作系统下运行。其特点是占有内存少，并发能力强。
根据2023年11月份W3Techs公司统计的数据显示，在全球约11.3亿网站中，市场占有率排名前三的Web服务器分别是Nginx（34.2%）、Apache(30.8%)和Cloudflare Server(21.2%)，可以看到作为后起之秀的Nginx已超越了Apache。Nginx之所以能够脱颖而出，是因为它具有性能高、稳定性好、结构模块化、配置简单以及资源消耗低等优点。
通过本地文件系统提供服务
缓存加速、负载均衡
OpenRestry（又称：ngx_openresty）是一个基于 Nginx 的可伸缩的 Web 平台，支持 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块,可以快速构造出足以胜任 C10K 以上并发连接响应的超高性能 Web 应用系统。
首先要明确一个概念，所谓代理（Proxy）就是一个代表、一个渠道；此时就涉及到两个角色，一个是被代理角色，一个是目标角色。被代理角色通过这个代理访问目标角色完成一些任务的过程称为代理操作过程，代理（Proxy）分为正向代理和反向代理。
正向代理，是最常接触到的代理模式， “它代理的是客户端（Client）”，正向代理是一个位于客户端和原始服务器（Origin Server）之间的服务器，客户端向代理发送一个请求并指定目标（原始服务器），由代理服务器将此请求转发至目标（原始服务器），并将从原始服务器取得内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理，例如必须设置正向代理服务器的 IP 地址或域名，以及代理的服务端口。
-
对客户端访问授权，上网进行认证；
-
记录用户上网行为管理；
-
对外隐藏实际用户信息。
反向代理，“它代理的是服务端（Server）”，主要用于服务器集群分布式部署的情况下，即通过部署多台服务器来解决单台服务器访问人数限制的问题，从而提高服务的整体吞吐量，并且反向代理服务器可根据不同请求的特征，决定将某个请求转发至某台后端服务器，从而实现负载均衡。反向代理隐藏了服务器的信息，对外都是透明的，访问者并不知道自己访问的是一个代理服务器。常见场景如下图所示：
-
保护内网的安全，通常将公网地址配置于反向代理服务器，将 Web 服务器配置于内网，从而对外避免暴露Web服务的内网地址，提高安全性；
-
缓存加速；
-
负载均衡，通过反向代理服务器来优化网站的负载。
Nginx反向代理服务器接收到客户端发送的请求，并按照一定的分配规则，分发到不同的后台服务，尽可能做到各个后台服务器的负载大致相同，这种分发的过程称为负载均衡。
Nginx支持多种协议的反向代理，如HTTP、TCP和UDP等。
Nginx支持的负载均衡调度算法如下：
-
轮询策略：轮询是默认的负载均衡方法，按照上游池中服务器列表的顺序分发请求。当上游服务器的容量变化时，还可以考虑使用加权轮询。其指令名称是weight。
-
最小连接：通过将当前请求代理到打开连接数最少的上游服务器实现负载均衡。与轮询一样，在决定将连接发送到哪台服务器时，最少连接也会考虑权重。其指令名称是least_conn。
-
随机：该方法用于指示 NGINX 从组中随机选择一台服务器，同时考虑服务器的权重。随机负载均衡的指令名称是random。
-
通用哈希：管理员使用请求或运行时给定的文本、变量或两者的组合定义哈希值，NGINX 能够为当前请求生成哈希值并将其放在上游服务器上，从而在这些服务器之间分发负载。其指令名称是 hash。
-
IP 哈希：此方法仅适用于 HTTP。IP 哈希算法使用客户端 IP 地址作为哈希。IP 哈希与通用哈希存在细微的不同，前者使用 IPv4 地址的前三个八进制位或整个 IPv6 地址，而后者使用的是远程变量。其指令名称是 ip_hash。
-
最短时间：该算法仅在 NGINX Plus 中提供，与最小连接算法类似，它将请求代理到当前连接数最少的上游服务器，但首选平均响应时间最短的服务器。此方法是最复杂的负载均衡算法之一，能够满足高性能 Web 应用的需求。其指令名称是least_time。
Nginx的安全加固主要从以下两点考虑：一是Nginx服务器自身是否安全，比如是否存在安全漏洞；二是Nginx是否提供了可使用的安全功能，这部分主要是检查Nginx的配置是否得当，在安全性、可用性、稳定性之间取得平衡。
Nginx加固首先建议选择最新的稳定版本，且符合安全基线要求，在升级版本时，建议优先在测试环境测试通过后再进行升级，避免由于兼容性带来的问题。另外在安装时使用自定义的安装路径，并配置使用自定义的Web目录。此外，针对Nginx的安全特性，有如下加固建议：
为保持最大的安全性，应该按照最小授权原则分配访问权限。最小授权原则规定，在安全环境中，应该授予用户完成工作任务或工作职责所必需的最小访问权限。该原则实际应用要求对所有资源和功能进行低级别的粒度访问控制，建议使用指定的普通用户和组来运行Nginx（注意：切勿使用特权用户运行nginx，如root或Administrator用户）。
（1）以root用户创建安装Nginx所需的文件系统。
为Nginx创建独立的逻辑卷：
lvcreate -L 10G -n lv_nginx system
创建文件系统：
mkfs -t ext3 /dev/mapper/system-lv_nginx
创建安装目录，并mount文件系统
mkdir -p /nginx
mount /dev/mapper/system-lv_nginx /nginx
修改fstab，添加挂载点
echo "/dev/system/lv_nginx /nginx ext3 acl,user_xattr 1 2">>/etc/fstab
（2）以root用户创建Nginx所需用户、组
创建 nginx 组：
groupadd nginx
创建 nginx 用户并加入 nginx 组：
useradd nginx –g nginx
（3）以root用户安装Nginx
解压并安装：
cd /nginx //切换目录
tar -xzf nginx-1.24.0.tar.gz //解压
cd nginx-1.24.0 // 切换目录
./configure --prefix=/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_stub_status_module --with-pcre --with-zlib
//--prefix=/nginx 是安装目录 --with后跟的是模块名，按照需要进行安装
make // 编译
make install // 安装
（4）修改Nginx安装目录属组
chown -R nginx:nginx /nginx
（5）以nginx用户修改监听端口
Linux/Unix限制非特权用户不能监听1024以下的端口，而且对于一些服务，赋予过高的权限，会带来一定的风险，所以需要将默认监听端口80和443修改为大于1024的可用端口。
vi /nginx/conf/nginx.conf
server {
# regular server listening for HTTP traffic
# listen 80;
listen 8080;
}
server {
# server listening for SSL traffic on port 443;
# listen 443 ssl;
listen 8443 ssl;
}
如果使用默认端口，虽然操作系统可以使用setuid（如chmod u+s /nginx/sbin/nginx）、或使用iptables端口转发等来实现，但这些方式都会给系统带来一些
风险。当操作系统内核超过2.1版本后出现了基于能力（capability）的授权，可以给/nginx/sbin/nginx赋予监听80端口的能力
（setcap cap_net_bind_service =+eip /nginx/sbin/nginx），我们建议使用此方法。
（6）使用nginx用户启动服务
/nginx/sbin/nginx
可将Web资源部署到独立的文件系统上，并确保该文件系统挂载时使用noexec,、nodev和nosetuid选项，具体如下所示：
LABEL=/www /www ext3 defaults,nosuid,noexec,nodev 1 2
nodev 不解析文件系统中的字符设备或块设备。
noexec不允许执行被加载的文件系统中的任何二进制文件。
nosuid 不允许 set-user-identifier 或 set-group-identifier 位起作用
OverlayFS伪文件系统最初包含在Linux 内核3.18版本中：允许以一种对用户完全透明的方式组合两个目录树或文件系统(“上层”和“下层”)，能够访问“合并”层上的文件和目录。
Linux内核在挂载文件系统时采用的标准行为：作为挂载点目录中存在的文件和目录被屏蔽，并且对用户不可用，而挂载文件系统上存在的文件和目录被显示。只有在卸载文件系统后，才能再次访问原始文件。当我们在同一目录上挂载多个文件系统时，也会发生这种情况。相反，当使用OverlayFS伪文件系统时，不同层上存在的文件被“组合”在一起，生成的文件系统可自行挂载。
OverlayFS工作涉及两层：lower和upper。lower通常以readonly模式mount。由于不能对其上托管的文件和目录直接进行更改，因此可将其用作安全备用设置。相反，upper可以以read/write模式进行安装。存在于这两层上的文件被combine在一起，并可在merged层中进行访问，该层本身可作为标准文件系统来进行挂载。
假设网站根目录/www/html有一个目录upload是要求可读写的，其他只读即可。可通过以下操作实现：
mkdir -p /data/lower
mkdir -p /data/upper
mkdir -p /data/worker
mv /www/html/upload /data/upper/
mv /www/html/* /data/lower/
mount -t overlayfs overlay -o lower=/data/lower,upper=/data/upper,workdir=/data/worker, rw overlay /www1/html
各组成部分的详细解释如下：
mount ：Linux系统的命令，用于挂载文件系统。
-t overlay ：指定挂载的文件系统类型是overlay。
-o ：指定挂载选项，后面跟的是各种选项，用逗号分隔。
• lowerdir=${lower_dir} ：指定lower directory，也就是底层目录，这个目录的内容是只读的。
• upperdir=${upper_dir} ：指定upper directory，也就是上层目录，这个目录的内容是可读写的，所有的修改都会在这个目录中进行。
• workdir=${work_dir} ：指定工作目录，这个目录用于存储一些必要的元数据，以支持overlay文件系统的操作。这个目录必须要和upper directory在同一个文件系统下。
rw ：指定文件系统是可读写的。
overlay ：这是挂载的文件系统类型。
${merged_dir} ：这是挂载点，overlay文件系统会在这个位置被挂载，你可以在这个位置看到整个overlay文件系统的内容，也就是lower directory和upper directory合并之后的结果。
这样就完美实现了读写分离，底层目录只读，上层目录可写。
overlayfs因为特殊的机制，建议使用Linux内核4.0以上版本，否则对硬盘的inode消耗较大。
从源代码安装Nginx的过程中，可使用--whithout标志禁用不必要的模块：
./configure --without-mail --without-http_fastcgi_module
make
make install
也可通过修改Nginx配置文件，通过load_module对不需要的模块进行注释，如：
# load_module modules/ngx_http_geoip_module.so;
nginx -s reload
因为SSL 3、TLS 1.0 和 TLS 1.1 很容易受到BEAST攻击，建议使用更安全的 TLS 1.2/1.3 协议。可在Nginx配置文件的server部分添加以下指令实现：
ssl_protocols TLSv1.2 TLSv1.3;
弱加密套件可能导致logjam等相关漏洞，建议使用强加密套件。
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
Niginx默认会在HTTP头和错误页面发送其版本信息，攻击者可使用此信息来识别潜在的漏洞。建议通过删除Nginx配置文件中server_tonkens的注释（#），来隐藏Nginx版本信息：
server_tokens off
根据需要可使用limit_except指令禁用Nginx中任何不需要的HTTP方法，如限制除GET和POST之外的HTTP访问方法：
location /path {
limit_except GET POST {
deny all;
}
...
}
当 Nginx 用于代理来自上游服务器（例如 PHP-FPM）的请求时，可通过隐藏上游响应中发送的某些标头（例如运行的 PHP 版本）防止不必要的信息泄露。具体如下：
curl -I https://example.com
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/8.2
nginx 可使用 proxy_hide_header 指令隐藏：
proxy_hide_header X-Powered-By;
修改后，重新发送请求，将得到如下响应：
curl -I https://example.com
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
在Nginx中可通过“allow”和“deny”指令限制某些IP地址对具体资源的访问，具体如下：
location /restricted {
deny 1.1.1.1;
allow 1.1.1.0/24;
allow 1.0.0.0/8;
deny all;
...
}
Nginx可通过配置安全相关的header，以提高Web应用安全性。以下是常见的安全header配置：
X-Content-Type-Options：此标头告诉浏览器不要覆盖HTTP响应标头中指定的内容类型，可防止如内容嗅探、扫描等攻击类型。
add_header X-Content-Type-Options "nosniff";
X-XSS-Protection：此标头启用大多数浏览器中的内置跨站点脚本 (XSS) 过滤器。该过滤器可防止跨站点脚本攻击 (XSS)。
add_header X-XSS-Protection "1; mode=block";
X-Frame-Options：此标头告诉浏览器是否允许Web应用程序嵌入到另一个站点的框架或iframe中。该功能可防止点击劫持攻击(Clickjacking)。
add_header X-Frame-Options "SAMEORIGIN";
Content-Security-Policy：此标头定义各种类型资源的可信源白名单，包括脚本、样式表、图像和字体，可防止如跨站点脚本攻击 (XSS)、数据注入等攻击。
add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;
X-Robots-Tag：Spider Robots 爬取策略限制
add_header X-Robots-Tag none;
Strict-Transport-Security：此标头告诉浏览器仅在指定时间段内使用HTTPS访问 Web应用程序。可防止中间人(MitM)攻击及cookie劫持类攻击。
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
速率限制可用于保护服务器免受暴力攻击和拒绝服务 (DoS) 攻击，可通过如下配置以限制每个客户端IP地址的请求数量：
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
limit_req zone=one burst=5;
为防止某些未备案的域名或者恶意镜像站域名绑定到Nginx服务器, 导致服务器被警告关停，可通过如下方式进行防范：
if ($host !~ ^(example.com|www. example.com|images.example.com)$ ) {
return 444;
}
仅允许example.com、www.example.com、images.example.com向Nginx服务器发送请求。
恶意攻击者采用扫描器进行扫描或信息采集时，可利用http-use-agent字段判断客户端是否为常用扫描工具或使用特定版本,如果是则返回错误或者重定向报文，具体配置如下：
## Block download agents ##
if ($http_user_agent ~* LWP::Simple|BBBike|wget) {
return 403;
}
##
## Block some robots ##
if ($http_user_agent ~* msnbot|scrapbot) {
return 403;
}
为防止外部站点恶意引用Nginx上的静态资源，可通过如下配置限制仅允许某些源站域名可访问Nginx上的静态资源：
# Stop deep linking or hot linking
location /images/ {
valid_referers none blocked www.example.com example.com;
if ($invalid_referer) {
return 403;
}
}
禁止带有图像链接的实例：
valid_referers blocked www.example.com example.com;
if ($invalid_referer) {
rewrite ^/images/uploads.*.(gif|jpg|jpeg|png)$ http://www.examples.com/banned.jpg last
}
HTTP Referrer Spam是垃圾信息发送者用来提高正在推广网站的互联网搜索引擎排名一种技术，如果他们的垃圾信息链接显示在Nginx访问日志中，且这些日志被搜索引擎扫描，则会对网站排名产生不利影响。建议可通过如下方法进行加固：
if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen) ){
return 403;
}
建议设置所有客户端的缓冲区大小限制，防止缓冲区溢出类攻击事件，具体配置如下：
## Start: Size Limits & Buffer Overflows ##
client_body_buffer_size 1K;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;
## END: Size Limits & Buffer Overflows ##
1. client_body_buffer_size 1k –（默认为8k 或16k）该指令可设置客户端请求正文缓冲区大小。
2. client_header_buffer_size 1k – 该指令可设置来自客户端请求标头的缓冲区大小。对绝大多数请求而言，1K的缓冲区大小已能够满足日常需求。
3. client_max_body_size 1k – 该指令设置客户端请求可接受的主体大小，由请求标头中的Content-Length行指示。如果大于给定的主体大小设置，则客户端将收到错误“请求实体太大”(413)。
4. large_client_header_buffers 2 1k – 该指令为从客户端请求读取的大标头分配缓冲区的最大数量和大小，有助于对抗不良机器人和 DDoS攻击。
同时建议控制超时时长，以提高Nginx服务器性能，减少客户端连接数。具体如下所示：
## Start: Timeouts ##
client_body_timeout 10;
client_header_timeout 10;
keepalive_timeout 5 5;
send_timeout 10;
## End: Timeouts ##
1. client_body_timeout 10；–可根据实际业务需求配置请求体（request body）读超时时间。
2. client_header_timeout 10；–可根据实际业务需求配置等待client发送一个请求头的超时时间（例如：GET / HTTP/1.1）。
3. keepalive_timeout 5 5; – 可根据实际业务需求配 置与client的keep-alive连接超时时间
4. send_timeout 10；可根据实际业务需求配置客户端响应超时时间。
当前银行互联网业务越来越多，攻击暴露面也随之变大，如何加强Web服务器的安全防护成为一项迫切需要解决的问题。本文简要介绍Nginx基本概念、功能及安全加固建议等内容，后续我们将结合科技运营维护工作实际，持续优化和创新，持续完善互联网系统安全防护能力，护航业务系统高质量发展。
↑↑↑长按图片识别二维码关註↑↑↑
原文始发于微信公众号（全栈网络空间安全）：网络原来如此之浅谈Nginx服务器安全加固
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论