Nginx安全防护与HTTPS部署实战

目录

一：核心安全配置

1.隐藏版本号

2.限制危险请求方法

4.请求限制（CC攻击防御）

5.防盗链

二：高级防护

1.动态黑名单

2.nginx https 配置

3.nginx配置https证书

---

在当今互联网技术高速发展的背景下，web 服务的安全性与可靠性已成为企业及开发者不可忽视的核心课题。作为全球最受欢迎的高性能 Web 服务器和反向代理工具，Nginx凭借其轻量级、高并发处理能力和灵活的模块化设计，占据了全球近三分之一的 Web 服务器市场份额。然而，随着网络攻击手段的不断升级(如DDoS、SQL 注入、恶意爬虫等),以及全球范围内对数据隐私保护的法规要求(如GDPR、等保 2.0)，掌握 Nginx 的安全防护策略与 HTTPS 部署能力，已成为运维工程师和开发者的必备技能

一：核心安全配置

1.隐藏版本号

在生产环境中，需要隐藏 Nginx 的版本号，以避免泄漏 Nginx 的版本，使攻击者不能针对特定版本进行攻击。在隐藏版本号之前，可以使用 Fiddler 工具抓取数据包，查看 Nginx版本，也可以在 0penEuler 中使用命令 curl -Ihttp://192.168.10.101/查看

修改配置文件

再次查看文件

2.限制危险请求方法

不安全的请求方式,是潜在的安全风险,TRACE(易引发XST攻击)、PUT/DELETE(文件修改风险)、CONNECT(代理滥用)，通过正则表达式匹配请求方法，非白名单方法返回 444(无响应关闭连接)

修改配置文件

验证测试请求：使用其他请求服务器会拒绝

使用指定方式请求，服务器会允许

4.请求限制（CC攻击防御）

CC 攻击(Challenge Collapsar 攻击)是一种常见的网络攻击方式，通过大量合法或伪造的小流量请求来耗尽服务器资源，导致正常用户无法访问网站。要在 Nginx 中有效防止 CC 攻击，可以采用多种策略和方法。

CC攻击，也称为连接数攻击或请求速率限制攻击，通过模拟大量用户访问来消耗服务器资源，从而使得正常用户无法正常访问网站。为了防止此类攻击，可以使用 Nginx 提供的模块来限制请求速率和并发连接数

编辑配置文件

关键参数说明：

• 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个

300个请求，其中278个未成功

查看access.log 发现大量请求日志状态码503

5.防盗链

防盗链是一种重要的安全设置，旨在防止未经授权的用户盗用网站(静态)资源。盗链行为不仅侵犯了内容创作者的版权，还可能导致原网站带宽和资源的过度消耗，影响正常用户的访问速度和体验。

一般来说，用户浏览一个完整的页面并不是一次性全部传送到客户端的。如果所请求的页面带有图片或其他信息,那么第一个 HTTP 请求传送的是这个页面的文本，然后通过客户端的浏览器对这段文本进行解释执行。如果发现其中还有图片，那么客户端的浏览器会再次发送一条 HTTP 请求，当这个请求被处理后这个图片文件才会被传送到客户端,最后浏览器会将图片安放到页面的正确位置,就这样一个完整的页面要经过多次发送 HTTP 请求才能够被完整的显示

基于这样的机制，就会产生盗链问题:如果一个网站中没有其页面中所说图片信息，那么它完全可以链接到其他网站的图片信息上。这样，没有任何资源的网站利用了其他网站的资源来展示给浏览者，提高了自己的访问量，而大部分浏览者又不会很容易地发现。一些不良网站为了不增加成本而扩充自己站点内容，经常盗用其他网站的链接。一方面损害了原网站的合法利益，另一方面又加重了服务器的负担

本实验需要两台主机

操作系统	域名	IP	服务
Open Euler	www.aaa.com	192.168.10.101	源主机
Open Euler	www.bbb.com	192.168.10.102	盗链主机

（1）修改Windows的C:\Windows\System32\drivers\etc\hosts文件，设置域名和IP映射关系

（2）修改两台Open Euler的hosts文件，设置域名和IP对应关系

（3）把图片放到源主机上的工作目录下

（4）编辑原网站首页

（5）在Windows主机上访问网站

（6）编辑盗链网站首页文件

（7）测试访问盗链网站（成功）

（8）配置nginx防盗链

测试访问盗链网站

二：高级防护

1.动态黑名单

动态黑名单是 Nginx中一种实时拦截恶意请求的安全机制，它允许在不重启服务的情况下,动态更新需要封禁的 IP地址或网段。相比静态配置的 allow/deny指令，动态黑名单更灵活高效，适用于高并发、多变的攻击防护场景。

（1）编辑黑名单配置文件

（2）编辑配置文件

• geo:Nginx 内置模块指令，专门用于处理 IP 地址相关的逻辑。基于客户端IP 地址生成一个变量值，用于后续的访问控制判断
• $block ip:自定义的变量名，存储计算结果(通常为0或1)。
• default 0:默认值，表示不在黑名单中的 IP 允许访问
• if($block ip):当变量值为1时触发封禁逻辑

（3）使用封禁ip测试访问：使用102测试

2.nginx https 配置

（1）https 概念

HTTPS,全称HyperText Transfer Protocol over Secure Socket Layer,设计初衷是为了保证数据传输安全。国内大型互联网巨头在 2016 开始大力推行https，期间关于 https 的重大事件有:

Google 搜索引擎让 https的网站在搜索排名中更靠前。

从2017年开始，chrome浏览器把只采用http的网站标记为不安全网站。
苹果要求 App Store 中的所有应用都必须使用 https 加密链接。
微信小程序也要求必须使用 https。
新一代的 http/2协议的支持需要以 https 为基础。

3.HTTP为什么不安全

HTTP 由于是明文传输，主要存在三大风险:窃听风险、篡改风险、冒充风险。

窃听风险

中间人可以获取到通信内容，由于内容是明文，所以获取明文后有安全风险

篡改风险

中间人可以篡改报文内容在发送给对方

冒充风险

比如你以为是在和某宝通信，实际是一个钓鱼网站

4.安全通信的四大原则

不难猜到 HTTPS 就是为了解决上述三个风险而生的，一般我们认为安全的通信需要包括以下四个原则: 机密性、完整性，身份认证和不可否认。

机密性:即对数据加密，解决了窃听风险，因为即使被中间人窃听，由于数据是加密的，他也拿不到明文;

完整性:指数据在传输过程中没有被篡改，不多不少，保持原样，中途如果哪怕改了一个标点符号，接收方也能识别出来，从来判定接收报文不合法;

身份认证:确认对方的真实身份，即证明“你妈是你妈”的问题，这样就解决了冒充风险，用户不用担心访问的是某宝结果却在和钓鱼网站通信的问题;

不可否认:即不可否认已发生的行为，比如小明向小红借了1000元，但没打借条，或者打了借条但没有签名，就会造成小红的资金损失。

HTTPS 通信原理简述

既然 HTTP 是明文传输的，那我们给报文加密不就行了，既然要加密，我们肯定需要通信双方协商好密钥吧。一种是通信双方使用同一把密钥，即对称加密的方式来给报文进行加解密。

但是这里有一个关键问题:对称加密的通信双方要使用同一把密钥，这个密钥是如何协商出来的?如果通过报文的方式直接传输密钥,之后的通信其实还是在裸奔，因为这个密钥会被中间人截获甚至替换掉，这样中间人就可以用截获的密钥解密报文，甚至替换掉密钥以达到篡改报文的目的。

有人说对这个密钥再次加密不就完了，但对方如果要解密这个密钥，那还是要传加密密钥给对方，依然还是会被中间人截获的，这么看来直接传输密钥无论
怎样都无法摆脱俄罗斯套娃的难题，是不可行的。

直接传输密钥无论从哪一端传从上节分析来看是不行了，这里我们再看另一种加密方式:非对称加密。

非对称加密即加解密双方使用不同的密钥，一把作为公钥，可以公开的，把作为私钥，不能公开，公钥加密的密文只有私钥可以解密，私钥签名的内容，也只有公钥可以验签。

样的话对 serve 来说,保管好私钥,发布公钥给其他 client，其他 client只要把对称加密的密钥(或用于生成对称加密密钥的信息)使用公钥加密后传给server 即可。如此一来由于公钥加密只有私钥能解密，而私钥只有 server 有，所以能保证 client 向 server 传输是安全的，server 解密后即可拿到对称加密密钥，这样交换了密钥之后就可以用对称加密密钥通信了。

但是问题又来了，server 怎么把公钥安全地传输给 client 呢???????
如果直接传公钥，也会存在被中间人调包的风险，好像没完没了了一样......

数字证书，解决公钥传输信任问题

如何解决公钥传输问题呢?从现实生活中的场景找答案。员工入职时，企业一般会要求提供学历证明，这个学历必须由第三方权威机构(CertificateAuthority 证书颁发机构，简称 CA)即教育部颁发。同理，server 也可以向 CA申请证书，在证书中附上公钥，然后将证书传给 client。

证书是由站点管理者向CA 申请，申请的时候会提交域名、组织单位信息和公钥等数据(这些数据组成了 Certificate Signing Request 证书签名请求,简称 CSR),CA 会根据这些信息生成证书

这样当 client 拿到证书后，就可以获得证书上的公钥，再用此公钥加密对称加密密钥传给 server 即可。看起来确实很完美，不过在这里大家要考虑一个问题

想象一下上文中我们提到的学历，企业如何认定你提供的学历证书是真是假呢?答案是用学历编号,企业拿到证书后用学历编号在学信网上一查就知道证书真伪了，学历编号其实就是我们常说的证书的数字签名，可以防止证书造假。

证书的数字签名怎么来的?是使用的 CA机构的私钥给 CSR(确切来说是 CSR生成的摘要信息)进行的签名，这样的话 client 得用 CA 的公钥来给签名解密才行，拿到的才是未经篡改合法的证书(私钥签名，公钥验签)

细心的你一定发现了问题，那 CA 公钥又是如何安全地传输到 client 的?如果还是从 server 传输到 client，依然无法解决公钥被调包的风险。实际上CA 公钥是存在于 CA 证书上，而此证书(也称 Root CA 证书)被操作系统信任内置在操作系统上的，无需传输，如果用的是windows 的同学，可以通过:控制面板->网络和 Internet->Internet 选项->内容一>证书->受信任的根证书颁发机构，可以看到很多内置的被信任的证书

3.nginx配置https证书

由于 ss1 证书需要向 CA 组织申购，实验采用自签名证书(也就是自己给自己签名并颁发证书，当然这种证书是不被信任的)

（1）使用openssl 生成证书和私钥生成证书和私钥

创建证书存储目录

参数解释：

• -x509:生成自签名证书(而非 CSR)
• -nodes:不加密私钥(无密码保护)。
• -days 365:证书有效期1年。
• -keyout:私钥文件。
•  -out:自签名文件。
• -newkey rsa:2048:生成 2048 位的 RSA 私钥。
• -subj:证书主题信息(按需修改字段)

Ps:

CA 签名证书:

需要由受信任的第三方证书颁发机构(CA)签发。流程如下:

用户生成私钥和 CSR(证书签名请求)

将 CSR 提交给 CA(如Let's Encrypt、DigiCert等)。

.CA 机构验证身份后，用 CA 的私钥对证书签名，生成最终证书。

自签名证书:

证书的颁发者(Issuer)和主体(Subject)是同一个实体(即自己)无需第三方 CA 参与，直接用工具(如 0penSsL)生成私钥和证书。签名时使用自己的私钥，而不是 CA 的私钥。适用于测试、内部环境或无需公开信任的场景。

（2）nginx启用https

编辑nginx配置文件

（3）通过浏览器验证

访问 https://你的服务器 ip

浏览器会提示证书不安全(因自签名)，选择“高级”--继续前往或信任此证书(测试环境可忽略警告)。

总结：本章节深入介绍了 Nginx 安全防护与 HTTPS 部署的实战知识。首先，详细阐述了Nginx 在 Web 应用安全防护方面的重要作用，包括其提供的访问控制、错误页面定制、日志记录等安全配置选项，这些配置能够有效增强 Web 应用的安全性。接着，课件重点讲解了 HTTPS 的部署方法和意义，强调了 SSL/TLS 加密通信在保障数据传输安全性方面的重要性。通过具体的实战案例，展示了如何在 Nginx 上配置 HTTPS，实现加密通信，并提升用户对网站的信任度和搜索引警排名