目录
- 前言
- 一. 核心安全配置
- 1. 隐藏版本号
- 2. 限制危险请求方法
- 3. 请求限制(CC攻击防御)
- (1)使用nginx的limit_req模块限制请求速率
- (2)压力测试验证
- 4. 防盗链
- 二. 高级防护
- 1. 动态黑名单
- (1)编辑黑名单配置文件
- (2)编辑主配置文件
- (3)使用封禁ip测试访问
- 2. nginx https配置
- (1)https概念
- (2)HTTP为什么不安全
- (3)安全通信的四大原则
- (4)HTTPS通信原理简述
- 3. nginx配置https证书
- (1)使用openssl生成证书和私钥生成证书和私钥
- (2)nginx启用https
- (3)通过浏览器验证
前言
在当今互联网技术高速发展的背景下,Web服务的安全性与可靠性已成为企业及开发者不可忽视的核心课题。作为全球最受欢迎的高性能Web服务器和反向代理工具,Nginx凭借其轻量级、高并发处理能力和灵活的模块化设计,占据了全球近三分之一的Web服务器市场份额。然而,随着网络攻击手段的不断升级(如DDoS、SQL注入、恶意爬虫等),以及全球范围内对数据隐私保护的法规要求(如GDPR、等保2.0),掌握Nginx的安全防护策略与HTTPS部署能力,已成为运维工程师和开发者的必备技能
一. 核心安全配置
1. 隐藏版本号
在生产环境中,需要隐藏 Nginx 的版本号,以避免泄漏 Nginx 的版本,使攻击者不能针对特定版本进行攻击。在隐藏版本号之前,可以使用 Fiddler 工具抓取数据包,查看Nginx 版本,也可以在 OpenEuler 中使用命令 curl -I http://192.168.10.101/查看
[root@localhost ~]# curl -I 192.168.10.101
HTTP/1.1 200 OK
Server: nginx/1.26.3 //版本号
Date: Mon, 07 Apr 2025 08:32:36 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Mon, 07 Apr 2025 08:17:10 GMT
Connection: keep-alive
ETag: "67f38a06-267"
Accept-Ranges: bytes
修改配置文件
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf
[root@localhost ~]# nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
[root@localhost ~]# systemctl restart nginx
[root@localhost ~]# curl -I 192.168.10.101
HTTP/1.1 200 OK
Server: nginx #版本号被隐藏
Date: Mon, 07 Apr 2025 08:39:31 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Mon, 07 Apr 2025 08:17:10 GMT
Connection: keep-alive
ETag: "67f38a06-267"
Accept-Ranges: bytes
2. 限制危险请求方法
不安全的请求方式,是潜在的安全风险,TRACE(易引发XST攻击)、PUT/DELETE(文件修改风险)、CONNECT(代理滥用),通过正则表达式匹配请求方法,非白名单方法返回444(无响应关闭连接)
修改配置文件
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf
server {
listen 80;
server_name localhost;
if ($request_method !~ ^(GET|HEAD|POST)$) {
return 444;
}
[root@localhost ~]# nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
[root@localhost ~]# systemctl restart nginx
验证测试请求;测试PUT/DELETE请求
[root@localhost ~]# curl -XPUT -I 192.168.10.101
curl: (52) Empty reply from server
[root@localhost ~]# curl -XDELETE -I 192.168.10.101
curl: (52) Empty reply from server
查看access.log日志
[root@localhost ~]# cat /usr/local/nginx/logs/access.log
127.0.0.1 - - [07/Apr/2025:16:32:24 +0800] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.4.0"
192.168.10.101 - - [07/Apr/2025:16:32:36 +0800] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.4.0"
192.168.10.101 - - [07/Apr/2025:16:37:43 +0800] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.4.0"
192.168.10.101 - - [07/Apr/2025:16:38:46 +0800] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.4.0"
192.168.10.101 - - [07/Apr/2025:16:39:31 +0800] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.4.0"
192.168.10.101 - - [07/Apr/2025:19:04:44 +0800] "PUT / HTTP/1.1" 444 0 "-" "curl/8.4.0"
192.168.10.101 - - [07/Apr/2025:19:12:30 +0800] "DELETE / HTTP/1.1" 444 0 "-" "curl/8.4.0"
注意测试TRACE和CONNECT方法时,状态码不是444(原因:1.CONNECT请求的目标不是代理服务器时,服务器必须返回400 Bad Request,Nginx核心层在请求解析阶段直接拦截,根本不进入后续的location处理流程 2.现代Nginx默认禁用TRACE方法,在ngx_http_core_module阶段直接返回405 Not Allowed)
3. 请求限制(CC攻击防御)
CC攻击(Challenge Collapsar攻击)是一种常见的网络攻击方式,通过大量合法或伪造的小流量请求来耗尽服务器资源,导致正常用户无法访问网站。要在Nginx中有效防止CC攻击,可以采用多种策略和方法。
CC攻击,也称为连接数攻击或请求速率限制攻击,通过模拟大量用户访问来消耗服务器资源,从而使得正常用户无法正常访问网站。为了防止此类攻击,可以使用Nginx提供的模块来限制请求速率和并发连接数
(1)使用nginx的limit_req模块限制请求速率
编辑配置文件
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf
关键参数说明:
参数 | 含义 |
---|---|
limit_req_zone | 定义共享内存区 |
$binary_remote_addr | 是一个内置变量,用于表示客户端 IP 地址的二进制格式 |
zone=req_limit:10m | 创建名为req_limit的共享内存区,大小10M,用来存储客户端 IP |
rate=10r/s | 限制并发数,每个IP每秒可以发起的请求次数 |
limit_req | 实施速率限制 |
zone=req_limit | 绑定到预定义的共享内存区 |
burst=20 | 类似与等候区,超出并发数的请求会到等候区,等候区占满后,多余的请求会立刻返回503 |
nodelay | 立即处理突发请求而不延迟,相当于立即处理等候区的请求,多余的请求会立刻返回503 |
(2)压力测试验证
安装ab测试工具:
ApacheBench(简称ab)是Apache HTTP服务器自带的一个轻量级、易用的HTTP服务器性能测试工具。它主要用于评估服务器在并发访问下的性能表现,包括响应时间、吞吐量等关键指标。
发起测试请求:
共发起300个请求,每次发起30个请求
查看access.log发现大量请求日志状态码503
[root@localhost ~]# tail -300 /usr/local/nginx/logs/access.log
关键选项说明:
选项 | 含义 |
---|---|
-n 300 | 表示总请求数为 300 次,即模拟客户端向服务器发送 300 次 HTTP 请求 |
-c 30 | 表示并发用户数为 30,即同时有 30 个请求并行发送到服务器 |
4. 防盗链
防盗链是一种重要的安全设置,旨在防止未经授权的用户盗用网站(静态)资源。盗链行为不仅侵犯了内容创作者的版权,还可能导致原网站带宽和资源的过度消耗,影响正常用户的访问速度和体验。
一般来说,用户浏览一个完整的页面并不是一次性全部传送到客户端的。如果所请求的页面带有图片或其他信息,那么第一个 HTTP 请求传送的是这个页面的文本,然后通过客户端的浏览器对这段文本进行解释执行。如果发现其中还有图片,那么客户端的浏览器会再次发送一条 HTTP 请求,当这个请求被处理后这个图片文件才会被传送到客户端,最后浏览器会将图片安放到页面的正确位置,就这样一个完整的页面要经过多次发送 HTTP 请求才能够被完整的显示。基于这样的机制,就会产生盗链问题:如果一个网站中没有其页面中所说图片信息,那么它完全可以链接到其他网站的图片信息上。这样,没有任何资源的网站利用了其他网站的资源来展示给浏览者,提高了自己的访问量,而大部分浏览者又不会很容易地发现。一些不良网站为了不增加成本而扩充自己站点内容,经常盗用其他网站的链接。一方面损害了原网站的合法利益,另一方面又加重了服务器的负担
资源清单
本实验需要两台主机;一台客户机测试
(1)修改 Windows10 的 C:\Windows\System32\drivers\etc\hosts 文件,设置域名和 IP 映射关系
(2)修改两台 OpenEuler 的 hosts 文件,设置域名和 IP 映射关系
(3)把图片 kgc.png 放到源主机(www.aaa.com)的工作目录下
(4)编辑原网站首页文件
(5)测试访问网站
(6)编辑盗链网站首页文件(102主机)
(7)测试访问盗链网站(盗链成功)
(8)配置Nginx防盗链
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf
- ~* .(jpg|gif|swf)$:这段正则表达式表示匹配不区分大小写,以.jpg 或.gif 或.swf 结尾的文件
- Valid_referers:设置信任的网站,可以正常使用图片
- 后面的网址或者域名:referer 中包含相关字符串的网址
- If 语句:如果链接的来源域名不在 valid_referers 所列出的列表中,$invalid_referer 为 1,则执行后面的操作,即进行重写或返回 403 页面
(8)测试访问盗链网站(盗链失败403)
二. 高级防护
1. 动态黑名单
动态黑名单是Nginx中一种实时拦截恶意请求的安全机制,它允许在不重启服务的情况下,动态更新需要封禁的IP地址或网段。相比静态配置的allow/deny指令,动态黑名单更灵活高效,适用于高并发、多变的攻击防护场景
(1)编辑黑名单配置文件
[root@localhost ~]# vim /usr/local/nginx/conf/blockips.conf
(2)编辑主配置文件
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf
参数 | 含义 |
---|---|
geo | Nginx 内置模块指令,专门用于处理 IP 地址相关的逻辑。基于客户端 IP 地址生成一个变量值,用于后续的访问控制判断 |
$block_ip | 自定义的变量名,存储计算结果(通常为 0 或 1) |
default 0 | 默认值,表示不在黑名单中的IP允许访问 |
(3)使用封禁ip测试访问
禁止102主机访问
2. nginx https配置
(1)https概念
TTPS,全称HyperText Transfer Protocol over Secure Socket Layer,设计初衷是为了保证数据传输安全。国内大型互联网巨头在2016开始大力推行https,期间关于https的重大事件有:
-
Google搜索引擎让https的网站在搜索排名中更靠前
-
从2017年开始,chrome浏览器把只采用http的网站标记为不安全网站
-
苹果要求App Store中的所有应用都必须使用https加密链接
-
微信小程序也要求必须使用https
-
新一代的http/2协议的支持需要以https为基础
众所周知,http(超文本传输协议)是客户端浏览器与web服务器之间的通信协议,而https协议可以认为是HTTP + SSL/TLS,在http之下tcp之上加了ssl一层,用于对应用层数据的加解密。如下图所示
SSL:由Netscape公司开发,专门用于保护Web通讯。SSL协议位于TCP/IP协议与各种应用层协议之间,为数据通讯提供安全支持。SSL协议可分为SSL记录协议(SSL Record Protocol)和SSL握手协议(SSL Handshake Protocol)两层。SSL经历了多个版本的迭代,包括从未公开发布的SSL 1.0、存在严重安全漏洞且现已废弃的SSL 2.0、在2014年因POODLE攻击漏洞而被逐步淘汰的SSL 3.0
TLS:是IETF(Internet Engineering Task Force,互联网工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。从历史上看,TLS对SSL首先是继承关系,后来逐步发展并取代了SSL,成为当前主流的网络安全协议。TLS经历了多个版本的演进,包括TLS 1.0(1999年发布,基于SSL 3.0但进行了改进)、TLS 1.1(2006年发布,增加了对CBC攻击的保护)、TLS 1.2(2008年发布,引入了更强大的加密算法,如AES)和TLS 1.3(2018年发布,进一步简化了握手过程,提高了性能和安全性)。值得注意的是,TLS 1.0和TLS 1.1也在2021年被正式弃用
(2)HTTP为什么不安全
HTTP 由于是明文传输,主要存在三大风险:窃听风险、篡改风险、冒充风险。
- 窃听风险
中间人可以获取到通信内容,由于内容是明文,所以获取明文后有安全风险
- 篡改风险
比如你以为是在和某宝通信,但实际上是在和一个钓鱼网站通信
- 冒充风险
比如你以为是在和某宝通信,但实际上是在和一个钓鱼网站通信
HTTPS 显然是为了解决这三大风险而存在的
(3)安全通信的四大原则
不难猜到 HTTPS 就是为了解决上述三个风险而生的,一般我们认为安全的通信需要包括以下四个原则: 机密性、完整性,身份认证和不可否认
-
机密性:即对数据加密,解决了窃听风险,因为即使被中间人窃听,由于数据是加密的,他也拿不到明文
-
完整性:指数据在传输过程中没有被篡改,不多不少,保持原样,中途如果哪怕改了一个标点符号,接收方也能识别出来,从来判定接收报文不合法
-
身份认证:确认对方的真实身份,即证明“你妈是你妈”的问题,这样就解决了冒充风险,用户不用担心访问的是某宝结果却在和钓鱼网站通信的问题
-
不可否认: 即不可否认已发生的行为,比如小明向小红借了 1000 元,但没打借条,或者打了借条但没有签名,就会造成小红的资金损失
(4)HTTPS通信原理简述
HTTPS(超文本传输协议安全)是HTTP的安全版本,它通过在传输层实现安全套接字层(SSL)或传输层安全性(TLS)来加密通信协议确保网络上的数据传输安全。HTTPS不仅保护数据免受窃听,还确保数据在传输过程中未被篡改,保持了完整性。
HTTPS的安全性基于三种主要的加密技术:证书、对称加密和非对称加密
-
证书:服务器在使用HTTPS之前需要向证书颁发机构(CA)申请证书。这个证书包含了服务器的公钥和其他身份信息。当服务器向客户端发送证书时,客户端会验证证书的有效性,以确保正在通信的服务器是合法的
-
对称加密:在客户端和服务器之间建立安全通信后,双方会使用对称加密算法来加密传输的数据。对称加密使用相同的密钥进行加密和解密,因此密钥的安全传输至关重要
-
非对称加密:在初始的握手阶段,非对称加密扮演着关键角色。客户端和服务器使用两个不同的密铜–一个公钥和一个私钥。公钥可以公开,而私钥必须保密。非对称加密用于安全地交换对称加密的密钥
3. nginx配置https证书
由于ssl证书需要向CA组织申购,实验采用自签名证书(也就是自己给自己签名并颁发证书,当然这种证书是不被信任的)
(1)使用openssl生成证书和私钥生成证书和私钥
创建证书存储目录
生成自签名证书
参数解释:
参数 | 含义 |
---|---|
-x509 | 生成自签名证书(而非CSR) |
-nodes | 不加密私钥(无密码保护) |
-days 365 | 证书有效期1年 |
-keyout | 私钥文件 |
-out | 自签名文件 |
-newkey rsa:2048 | 生成2048位的RSA私钥 |
-subj | 证书主题信息(按需修改字段) |
CA签名证书:
需要由受信任的第三方证书颁发机构(CA)签发。流程如下:
- 用户生成私钥和CSR(证书签名请求)
- 将CSR提交给CA(如Let’s Encrypt、DigiCert等)
- CA机构验证身份后,用CA的私钥对证书签名,生成最终证书
自签名证书:
- 证书的颁发者(Issuer)和主体(Subject)是同一个实体(即自己)
- 无需第三方CA参与,直接用工具(如OpenSSL)生成私钥和证书
- 签名时使用自己的私钥,而不是CA的私钥
- 适用于测试、内部环境或无需公开信任的场景
(2)nginx启用https
编辑nginx配置文件
[root@localhost ~]#vim /usr/local/nginx/conf/nginx.conf
(3)通过浏览器验证
访问https://你的服务器ip
浏览器会提示证书不安全(因自签名),选择“高级”–继续前往或信任此证书(测试环境可忽略警告)