目录
(1)修改 Windows 的C:\Windows\System32\drivers\etc\hosts 文件，设置域名和 IP 映射关系
(2)修改两台0penEuler 的 hosts 文件，设置域名和 IP 映射关系
(3)把图片 kgc.png 放到源主机(www.aaa.com)的工作目录下
一.核心安全配置
1.编译安装Nginx
（1）编译安装软件
Nginx 的配置及运行需要 pcre、zlib 等软件包的支持，因此应预先安装这些软件的开发包(devel)，以便提供相应的库和头文件，确保 Nginx 的安装顺利完成。
（2）创建运行用户、组和日志目录
（3）编译安装Nginx
（4）添加Nginx系统服务
2.隐藏版本号
在生产环境中，需要隐藏 Nginx 的版本号，以避免泄漏 Nginx 的版本，使攻击者不能针对特定版本进行攻击。在隐藏版本号之前，可以使用 Fiddler 工具抓取数据包，查看Nginx版本，也可以在 0penEuler 中使用命令 curl -Ihttp://192.168.10.101/查看。
修改配置文件：
3.限制危险请求方法
| 配置项 | 说明 | 测试方法 | 预期结果 | 注意事项 | ||
|---|---|---|---|---|---|---|
| 限制危险请求方法 | 通过正则表达式匹配请求方法，只允许 GET, HEAD, POST 方法，其他方法返回444 | curl -XPUT -I 192.168.10.101 |
返回444 (无响应关闭连接) | 语法应为 `if ($request_method !~ ^(GET | HEAD | POST)$)` |
| TRACE方法 | 默认被Nginx核心模块禁用 | curl -XTRACE -I 192.168.10.101 |
返回405 (Not Allowed) | Nginx在ngx_http_core_module阶段直接拦截 |
||
| CONNECT方法 | 当目标不是代理服务器时被拦截 | curl -XCONNECT -I 192.168.10.101 |
返回400 (Bad Request) | Nginx在请求解析阶段直接拦截，不进入location处理 | ||
| PUT/DELETE方法 | 被配置规则拦截 | curl -XPUT -I 192.168.10.101 或 curl -XDELETE -I 192.168.10.101 |
返回444 | 日志中会记录444状态码 |
PS:注意测试 TRACE 和 CONNECT 方法时，状态码不是 444(原因:1.CONNECT 请求的目标不是代理服务器时，服务器必须返回400Bad Request，Nginx 核心层在请求解析阶段直接拦截,根本不进入后续的 location 处理流程 2.现代 Nginx默认禁用 TRACE 方法,在 ngx http core module 阶段直接返回 405 Not Allowed)
4.请求限制（CC攻击防御）
CC 攻击(Challenge Collapsar 攻击)是一种常见的网络攻击方式，通过大量合法或伪造的小流量请求来耗尽服务器资源，导致正常用户无法访问网站。要在 Nginx中有效防止CC攻击，可以采用多种策略和方法。
CC攻击，也称为连接数攻击或请求速率限制攻击，通过模拟大量用户访问来消耗服务器资源，从而使得正常用户无法正常访问网站。为了防止此类攻击，可以使用 Nginx 提供的模块来限制请求速率和并发连接数
（1）使用Nginx的limit_req 模块限制请求速率
| 参数 | 说明 | 示例值 | 作用 |
|---|---|---|---|
| limit_req_zone | 定义共享内存区 | limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s |
创建用于存储客户端请求状态的共享内存区 |
| $binary_remote_addr | 客户端IP地址的二进制格式 | - | 作为限流的key，比字符串IP更节省空间 |
| zone=name:size | 定义共享内存区名称和大小 | zone=req_limit:10m |
创建10MB大小的名为req_limit的共享内存区 |
| rate=rate | 请求速率限制 | rate=10r/s |
每个IP每秒允许10个请求 |
| limit_req | 实施速率限制的指令 | limit_req zone=req_limit burst=20 nodelay |
在server/location中应用限流规则 |
| burst=number | 突发请求缓冲区大小 | burst=20 |
允许超过rate的20个请求进入排队 |
| nodelay | 立即处理突发请求 | nodelay |
不延迟处理突发请求，超过(burst+rate)的请求直接返回503 |
（2）压力测试验证
安装 ab 测试工具
ApacheBench(简称ab)是 Apache HTTP 服务器自带的一个轻量级、易用的HTTP 服务器性能测试工具。它主要用于评估服务器在并发访问下的性能表现,包括响应时间、吞吐量等关键指标。
发起测试请求
共发起 300 个请求，每次发起 30个请求
查看 access.log 发现大量请求日志状态码 503
-n 300
表示总请求数为 300次，即模拟客户端向服务器发送300次HTTP 请求。
-c 30
表示并发用户数为30，即同时有30个请求并行发送到服务器。
4.防盗链
| 防盗链概念 | 说明 | 技术原理 | 影响 | 防御手段 |
|---|---|---|---|---|
| 定义 | 防止外部网站未经授权直接链接使用本站资源（图片/文件等） | HTTP请求头中的Referer字段标识来源页面 |
盗链者直接使用资源链接，消耗原站带宽 | 通过Nginx/Apache配置校验Referer |
| 盗链原理 | 利用浏览器自动请求资源的特性 | 浏览器解析HTML时自动发送子资源（图片/JS/CSS）请求 | 原站承担流量成本，盗链站零成本获益 | 限制非本站域名的资源请求 |
| 危害 | 1. 版权侵犯 2. 原站带宽消耗 3. 服务器资源浪费 4. 正常用户访问变慢 |
一个页面可能触发数十次资源请求 | 盗链站流量可能远高于原站访问量 | 返回403或替换为警告图片 |
| 防御实现 | 校验HTTP请求头中的来源信息 | 主要依赖Referer头，但可伪造（需配合其他手段） |
- | 典型Nginx配置：valid_referers none blocked *.example.com;if ($invalid_referer) { return 403; } |
| 进阶防护 | 1. 签名URL 2. 动态Token 3. 时间戳验证 |
生成临时访问令牌或加密链接 | 增加盗链者获取资源的难度 | 需要程序配合生成临时资源链接 |
| 注意事项 | 1. 需允许空Referer（直接访问） 2. 考虑CDN兼容性 3. 避免影响SEO |
部分合法爬虫可能无Referer | 过度限制可能影响用户体验 | 可设置白名单或例外规则 |
(1)修改 Windows 的C:\Windows\System32\drivers\etc\hosts 文件，设置域名和 IP 映射关系
(2)修改两台0penEuler 的 hosts 文件，设置域名和 IP 映射关系
(3)把图片 kgc.png 放到源主机(www.aaa.com)的工作目录下
(4)编辑原网站首页文件
(5)测试访问源网站
(6)编辑盗链网站首页文件
(7)测试访问盗链网站(盗链成功)
二.高级防护
1.动态黑名单
| 配置步骤 | 操作指令/内容 | 说明 |
|---|---|---|
| 1. 编辑黑名单配置文件 | vim /usr/local/nginx/conf/blockips.conf |
添加需要封禁的IP或网段，格式为：IP地址/网段 数字。数字含义：0-允许；1-403封禁；2-444断开；3-503不可用。 |
| 示例封禁条目 | 192.168.1.0/24 1:192.168.10.201 1: |
封禁整个192.168.1.0/24网段和单个IP 192.168.10.201。 |
| 2. 编辑主配置文件 | vim /usr/local/nginx/conf/nginx.conf |
在http块中添加geo指令定义动态黑名单逻辑。 |
| geo模块配置 | geo $block_ip {<br> default 0;<br> include /usr/local/nginx/conf/blockips.conf;<br>} |
default 0表示默认允许访问；include加载黑名单文件。 |
| 封禁逻辑 | if ($block_ip) {<br> return 403;<br>} |
当$block_ip值为1时，返回403禁止访问。 |
| 3. 重载配置 | nginx -tnginx -s reload |
测试配置语法并重载Nginx服务使配置生效。 |
| 测试封禁效果 | curl 192.168.10.202 |
被封禁的IP访问时会返回403 Forbidden页面。 |
| 关键指令说明 | geo：基于IP生成变量值；$block_ip：自定义变量；default 0：默认允许访问。 | 动态黑名单通过变量和条件判断实现灵活拦截，无需重启服务。 |
2.nginx https配置
（1）https概念
| 分类 | 关键内容 | 说明 |
|---|---|---|
| HTTPS 定义 | HyperText Transfer Protocol over Secure Socket Layer | 在HTTP基础上加入SSL/TLS加密层，确保数据传输安全。 |
| 推行背景 | - 2016年起国内互联网巨头推广 - Google提升HTTPS网站搜索排名 - Chrome标记HTTP为“不安全” - 苹果App Store、微信小程序强制要求HTTPS |
HTTPS成为行业安全标准，主流平台强制支持。 |
| HTTP vs HTTPS | HTTP：明文传输 HTTPS：HTTP + SSL/TLS（加密传输） |
HTTPS在TCP与应用层之间加入SSL/TLS协议，实现数据加密。 |
| SSL/TLS 协议栈 | 应用层（HTTP） ↓ SSL/TLS（加密层） ↓ 传输层（TCP） |
SSL/TLS位于传输层之上，对应用层数据加密。 |
| SSL 发展 | - SSL 1.0（未发布） - SSL 2.0（废弃） - SSL 3.0（2014年因POODLE漏洞淘汰） |
由Netscape开发，后因安全漏洞逐步被TLS取代。 |
| TLS 发展 | - TLS 1.0（1999年，基于SSL 3.0） - TLS 1.1（2006年，防CBC攻击） - TLS 1.2（2008年，支持AES） - TLS 1.3（2018年，简化握手） |
TLS是SSL的继承者，1.0/1.1于2021年弃用，1.3为当前主流版本。 |
| TLS 核心改进 | - 更安全的加密算法（如AES） - 简化握手流程（TLS 1.3） - 禁用不安全的协议版本 |
性能与安全性逐步提升，淘汰旧版本以应对新型攻击。 |
（2）HTTP为什么不安全
HTP 由于是明文传输，主要存在三大风险:窃听风险、篡改风险、冒充风险!
窃听风险
中间人可以获取到通信内容，由于内容是明文，所以获取明文后有安全风险
篡改风险
中间人可以篡改报文内容后再发送给对方，风险极大。
冒充风险
比如你以为是在和某宝通信，但实际上是在和一个钓鱼网站通信。
HTTPS 显然是为了解决这三大风险而存在的
（3）安全通信的四大原则
| 原则 | 定义 | 作用 | 实际应用示例 |
|---|---|---|---|
| 机密性 | 对数据进行加密，确保只有授权方可以读取明文内容。 | 防止窃听风险，即使数据被截获也无法解密。 | HTTPS使用SSL/TLS加密传输数据，如银行交易信息。 |
| 完整性 | 确保数据在传输过程中未被篡改或损坏。 | 防止数据被中间人篡改，保证接收到的数据与发送的一致。 | 数字签名或哈希校验（如SHA-256）验证文件完整性。 |
| 身份认证 | 验证通信双方的真实身份，确保对方是合法的实体。 | 防止冒充风险，避免与伪造的服务器或客户端通信。 | SSL证书验证网站身份（如浏览器显示绿色锁标志），防止钓鱼网站。 |
| 不可否认性 | 确保行为或交易发生后，参与者无法否认其参与或执行的操作。 | 提供法律或审计依据，防止抵赖行为。 | 数字签名合同（如电子签章）、区块链交易记录。 |
（4）HTTPS通信原理简述
| 加密方式 | 核心机制 | 优点 | 缺点 | 在HTTPS中的应用 |
|---|---|---|---|---|
| 对称加密 | 通信双方使用同一把密钥加密/解密数据。 | 加密速度快，适合大数据量传输。 | 密钥传输不安全，易被中间人截获。 | 不直接用于密钥交换，仅用于后续通信加密（如AES）。 |
| 非对称加密 | 使用公钥（公开）和私钥（私有）： - 公钥加密 → 私钥解密 - 私钥签名 → 公钥验签。 |
解决密钥传输安全问题。 | 计算复杂，速度慢，不适合大数据量。 | 用于密钥交换阶段（如RSA）：客户端用服务器公钥加密对称密钥，确保密钥安全传输。 |
| 混合加密 | 结合两者： 1. 非对称加密协商对称密钥； 2. 对称加密加密实际通信数据。 |
兼顾安全性与性能。 | 需依赖证书体系（CA）验证公钥合法性。 | HTTPS实际采用的方式：TLS握手阶段用非对称加密交换密钥，后续通信用对称加密。 |
服务器：生成公私钥对，公钥通过证书（CA签发）公开，私钥保密。
客户端：获取服务器公钥（证书验证合法性），生成对称密钥，用公钥加密后发送给服务器。
服务器：用私钥解密获取对称密钥，双方开始用对称密钥加密通信。
关键问题解决
密钥传输安全：非对称加密保护对称密钥的传输（避免“俄罗斯套娃”问题）。
性能优化：对称加密处理实际数据（非对称加密仅用于初始握手）。
身份认证：通过CA证书验证服务器公钥真实性，防止中间人攻击。
但是问题又来了，server 怎么把公钥安全地传 client 呢???????
如果直接传公钥，也会存在被中间人调包的风险，好没完没了了一样......
| 项目 | 说明 | 作用 | 关键流程 |
|---|---|---|---|
| 数字证书定义 | 由CA（证书颁发机构）签发的电子文件，包含服务器公钥及身份信息。 | 解决公钥传输的信任问题，防止中间人伪造公钥。 | - |
| 证书申请流程（CSR） | 服务器提交CSR（证书签名请求），包含组织信息、公钥等，CA审核后签发证书。 | 确保证书中的公钥与服务器身份绑定，由权威机构验证。 | 1. 服务器生成CSR → 2. CA验证身份 → 3. CA签发证书。 |
| 证书内容 | 包含： - 公钥 - 持有者信息 - CA签名 - 有效期等。 |
提供公钥合法性证明，支持客户端验证服务器身份。 | - |
| 客户端验证流程 | 1. 客户端获取证书； 2. 用CA公钥验证签名； 3. 确认证书有效后信任公钥。 |
防止伪造证书，确保公钥来自合法服务器。 | 依赖系统预置的CA根证书（信任链）。 |
| CA的角色 | 作为可信第三方，对服务器身份审核并签发证书。 | 建立公钥信任体系，避免公钥被篡改或冒用。 | - |
| 信任链机制 | 客户端通过预置的根证书验证中间CA和服务器证书的签名链。 | 确保即使证书由中间CA签发，仍可追溯至可信根CA。 | 根证书 → 中间CA证书 → 服务器证书。 |
| HTTPS中的实际应用 | 服务器将CA签发的证书发送给客户端，客户端验证后使用证书中的公钥加密通信。 | 实现安全密钥交换（如TLS握手），后续通信用对称加密。 | 1. 证书验证 → 2. 非对称加密协商密钥 → 3. 对称加密传输数据。 |
关键问题与解决
公钥信任问题：通过CA签名的证书绑定公钥与身份，防止中间人攻击。
证书伪造风险：客户端用CA公钥验证证书签名，确保未被篡改。
性能优化：非对称加密仅用于验证和密钥交换，实际数据用对称加密传输。
3.nginx配置https证书
| 分类 | 操作/配置 | 说明 | 注意事项 |
|---|---|---|---|
| 证书类型 | 自签名证书 vs CA签名证书 | - 自签名：自己签发，不受浏览器信任，适合测试。 - CA签名：由可信CA（如Let's Encrypt）签发，用于生产环境。 |
生产环境必须使用CA签名证书，否则浏览器会提示不安全。 |
| 生成自签名证书 | openssl req -x509 -nodes -days 365 -newkey rsa:2048 \<br>-keyout nginx-selfsigned.key \<br>-out nginx-selfsigned.crt \<br>-subj "/CN=localhost" |
- -x509：生成自签名证书。- -nodes：私钥不加密。- -subj：设置证书信息（如域名）。 |
自签名证书仅限内部测试使用，需手动信任。 |
| CA签名证书流程 | 1. 生成私钥和CSR。 2. 提交CSR给CA（如Let's Encrypt）。 3. CA验证后签发证书。 |
确保公钥受信任，需域名所有权验证（如DNS解析或文件验证）。 | 免费CA（如Let's Encrypt）有效期90天，需定期续签。 |
| Nginx配置HTTPS | nginx<br>server {<br> listen 443 ssl;<br> server_name localhost;<br> ssl_certificate /path/to/cert.crt;<br> ssl_certificate_key /path/to/key.key;<br> ssl_protocols TLSv1.2 TLSv1.3;<br> ssl_ciphers HIGH:!aNULL:!MD5;<br>}<br> |
- ssl_certificate：证书路径。- ssl_certificate_key：私钥路径。- ssl_protocols：禁用旧协议（如TLSv1.0）。 |
配置后需执行 nginx -t 测试语法，再 nginx -s reload 重载配置。 |
| 安全性增强配置 | nginx<br>ssl_prefer_server_ciphers on;<br>ssl_session_cache shared:SSL:10m;<br>ssl_session_timeout 10m;<br> |
- 优先使用服务端加密套件。 - 启用会话缓存以提升性能。 |
使用现代加密算法（如AES-GCM），禁用弱算法（如RC4、SHA1）。 |
| HTTP重定向到HTTPS | nginx<br>server {<br> listen 80;<br> server_name localhost;<br> return 301 https://$host$request_uri;<br>}<br> |
强制所有HTTP请求跳转到HTTPS，提升安全性。 | 确保用户始终通过加密连接访问。 |
（1）关键区别：自签名 vs CA签名证书
| 对比项 | 自签名证书 | CA签名证书 |
|---|---|---|
| 信任度 | 不被浏览器/系统默认信任 | 由可信CA签发，自动信任 |
| 适用场景 | 测试、内部环境 | 生产环境、公开服务 |
| 成本 | 免费 | 免费（Let's Encrypt）或付费（DigiCert） |
| 有效期 | 自定义（如-days 365） |
通常90天（免费CA）或1-2年（付费CA） |