①，首先安装Nginx（nginx-.26.3版）略
目录
一
1，隐藏版本号
在生产环境中，需要隐藏Nginx的版本号，以避免泄漏Nginx的版本，使攻击者不能针对特定版本进行攻击。在隐藏版本号之前，可以使用Fiddler工
具抓取数据包，查看Nginx版本，也可以在penEuler中使用命令curhttp://192.168.10.101/查看
修改配置文件
2，限制危险请求方法
不安全的请求方式,是潜在的安全风险,TRACE(易引发XST攻击)、PUT/DELETE(文件修改风险)、CONNECT(代理滥用)，通过正则表达式匹配请求方法，非白名单方法返回444(无响应关闭连接)
修改配置文件
测试
查看日志
PS:注意测试TRACE和CONNECT方法时，状态码不是444(原因:1.CONNECT请求的目标不是代理服务器时，服务器必须返回400BadRequest，Nginx核心层在请求解析阶段直接拦截,根本不进入后续的1ocation处理流程2.现代Nginx默认禁用 TRACE方法,在ngx http core_module阶段直接返回 405 Not Allowed)
3，请求限制（CC攻击防御）
CC攻击(ChallengeCollagar攻击)是一种常见的网络攻击方式，通过大量合法或伪造的小流量请求来耗尽服务器资源，导致正常用户无法访问网站。要在Nginx中有效防止CC攻击，可以采用多种策略和方法。
CC攻击，也称为连接数攻击或请求速率限制攻击，通过模拟大量用户访间来消耗服务器资源，从而使得正常用户无法正常访问网站。为了防止此类攻击，可以使用Nginx提供的模块来限制请求速率和并发连接数
（1）使用Nginx的limit_req模块限制请求速率
修改配置文件
参数说明
| limit_req_zone | 定义共享内存区 |
| $binary_remote_addr | 是一个内置变量，用于表示客户端IP地址的二进制格式 |
| zone=req_limit | 10m创建名为req_limit的共享内存区，大小10M,用来存储客户端IP |
| rate=10r/s | 限制并发数，每个IP每秒可以发起的请求次数 |
| limit_req | 实施速率限制 |
| zone=reg limit | 绑定到预定义的共享内存区 |
| burst=20 | 类似与等候区，超出并发数的请求会到等候区，等候区占满后，多余的请求会立刻返回503 |
| nodelay | 立即处理突发请求而不延迟，相当于立即处理等候区的请求，多余的请求会立刻返回503 |
（2）压力测试验证
4，防盗链
防盗链是一种重要的安全设置，旨在防止未经授权的用户盗用网站(静态)资源。盗链行为不仅侵犯了内容创作者的版权，还可能导致原网站带宽和资源的过度消耗，影响正常用户的访问速度和体验。
一般来说，用户浏览一个完整的页面并不是一次性全部传送到客户端的。如果所请求的页面带有图片或其他信息,那么第一个HTTP请求传送的是这个页面的文本，然后通过客户端的浏览器对这段文本进行解释执行。如果发现其中还有图片，那么客户端的浏览器会再次发送一条HTTP请求，当这个请求被处理后这个图片文件才会被传送到客户端,最后浏览器会将图片安放到页面的正确位置，就这样一个完整的页面要经过多次发送HTTP请求才能够被完整的显示。基于这样的机制，就会产生盗链问题:如果一个网站中没有其页面中所说图片信息，那么它完全可以链接到其他网站的图片信息上。这样，没有任何资源的网站利用了其他网站的资源来展示给浏览者，提高了自己的访问量，而大部分浏览者又不会很容易地发现。一些不良网站为了不增加成本而扩充自己站点内容，经常盗用其他网站的链接。一方面损害了原网站的合法利益，另一方面又加重了服务器的负担
（1）修改hosts文件
（2）编辑网站首页
第二台安装
第一台网页
第二台网页
（3）测试网页
（4）测试（防盗链失败）
二，高级防护
1，动态黑名单
动态黑名单是Nginx中一种实时拦截恶意请求的安全机制，它允许在不重启服务的情况下,动态更新需要封禁的IP地址或网段。相比静态配置的allow/deny指令，动态黑名单更灵活高效，适用于高并发、多变的击防护场景
（1）编辑黑名单配置文件
（2）编辑主配置文件
| geo: | Nginx内置模块指令，专门用于处理IP地址相关的逻辑。基于客户端IP地址生成一个变量值，用于后续的访问控制判断 |
| $block_ip: | 自定义的变量名，存储计算结果(通常为0或1) |
| defau1t0: | 默认值，表示不在黑名单中的IP允许访问 |
| if($block ip): | 当变量值为1时触发封禁逻辑 |
（3）使用封禁IP测试访问
curl 192.168.10.101
（4）自动添加黑名单
uniq-c:统计连续出现的次数，并在行首显示次数
sort-nr:按数值排序
2，nginx https配置
（1）https概念
HTTPS,全称HyperText Transfer Protocol over Secure Socket Layer,设计初衷是为了保证数据传输安全。国内大型互联网巨头在2016开始大力推行https，期间关于https的重大事件有:
Google搜索引擎让https的网站在搜索排名中更靠前。从2017年开始，chrome浏览器把只采用http的网站标记为不安全网站苹果要求 AppStore 中的所有应用都必须使用https 加密链接。微信小程序也要求必须使用https。新一代的 http/2 协议的支持需要以 https 为基础
众所周知，http(超文本传输协议)是客户端浏览器与web服务器之间的通信协议，而https协议可以认为是HTTP+SSL/TLS，在http之下tcp之上加了ss1一层，用于对应用层数据的加解密。
SSL:由Netscape公司开发，专门用于保护Web通讯。SSL协议位于ICP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为SSL记录协议(SSL Record Protocol)和SSL据手协议(SSl Handshake Protocol)两层。SSL经历了多个版本的选代，包括从未公开发布的SSL1.0、存在严重安全漏洞且现已废弃的SSL2.0、在2014年因POODLE攻击洞而被逐步淘汰的SSL3.0.
TLS:是ET(nternetEngineeringTaskForce，互联网工程任务组)制定的一种新的协议，它建立在SSL3.0协议规范之上，是SSL3.0的后续版本从历史上看，TLS对SSL首先是继承关系，后来逐步发展并取代了SSL，成为当前主流的网络安全协议。IS经历了多个版本的演进，包括TLS1.0(1999年发布，基于SSL3.0但进行了改进)、TLS1.1(2006年发布，增加了对CBC攻击的保护)、TLS1.2(2008年发布，引入了更强大的加密算法，如AES)和TLS1.3(2018年发布，进一步简化了提手过程，提高了性能和安全性)。值得注意的是，TLS1.0和TLS1.1也在2021年被正式弃用
（2）HTTP为什么不安全
HTTP由于是明文传输，主要存在三大风险:窃听风险、篡改风险、冒充风险
窃听风险
中间人可以获取到通信内容，由于内容是明文，所以获取明文后有安全风险
篡改风险
中间人可以篡改报文内容后再发送给对方，风险极大。
冒充风险
比如你以为是在和某宝通信，但实际上是在和一个钓鱼网站通信
HTTPS显然是为了解决这三大风险而存在的
（3）安全通信的四大原则
不难猜到 HTTPS 就是为了解决上述三个风险而生的，一般我们认为安全的通信需要包括以下四个原则: 机密性、完整性，身份认证和不可否认。
| 机密性: |
即对数据加密，解决了窃听风险，因为即使被中间人窃听，由于数据是加密的，他也拿不到明文; |
| 完整性: | 指数据在传输过程中没有被篡改，不多不少，保持原样，中途如果哪怕改了一个标点符号，接收方也能识别出来，从来判定接收报文不合法: |
| 身份认证: | 确认对方的真实身份，即证明“你妈是你妈”的问题，这样就解决了冒充风险，用户不用担心访问的是某宝结果却在和钓鱼网站通信的问题: |
| 不可否认: | 即不可否认已发生的行为，比如小明向小红借了1000元，但没打借条，或者打了借条但没有签名，就会造成小红的资金损失。 |
（4）HTTPS通信原理简述
既然HTTP是明文传输的，那我们给报文加密不就行了，既然要加密，我们肯定需要通信双方协商好密钥吧。一种是通信双方使用同一把密钥，即对称加密的方式来给报文进行加解密。
但是这里有一个关键问题:对称加密的通信双方要使用同一把密钥，这个密钥是如何协商出来的?如果通过报文的方式直接传输密钥，之后的通信其实还是在裸奔，因为这个密钥会被中间人截获甚至替换掉，这样中间人就可以用截获的密钥解密报文，甚至替换掉密钥以达到篡改报文的目的。
3，nginx配置https证书
由于ssl证书需要向CA组织申购，实验采用自签名证书(也就是自己给自己签名并颁发证书，当然这种证书是不被信任的)
（1）使用openssl生成证书和私钥生成证书和密钥
mkdir -p /etc/nginx/ssl
openssl req -x509 -nodes -days 365 -newkey rsa:2048
- keyout /etc/nginx/ssl/nginx-selfsigned, key
-out /ete/nginx/ss1/nginx-selfsigned.crt
-subj "/C=CN/ST=Beijing/L=Beijing/0=MyOrg/CN=localhost
| -x509: | 生成自签名证书(而非 CSR)。 |
| -nodes: | 不加密私钥(无密码保护) |
| -days 365: | 证书有效期1年。 |
| -keyout: | 私钥文件。 |
| -out: | 自签名文件 |
| -newkey rsa:2048: | 生成2048 位的 RSA 私钥。 |
| -subj: | 证书主题信息(按需修改字段)。 |
CA签名证书:
需要由受信任的第三方证书颁发机构(CA)签发。流程如下:1.用户生成私钥和CSR(证书签名请求)。
2.将 CSR 提交给 CA(如Let's Encrypt、Digicert 等)。
3.CA机构验证身份后，用CA的私钥对证书签名，生成最终证书。
自签名证书:
证书的颁发者(Issuer)和主体(Subject)是同一个实体(即自己)无需第三方CA参与，直接用工具(如OpensSL)生成私钥和证书。签名时使用自己的私钥，而不是CA的私钥。适用于测试、内部环境或无需公开信任的场景。