diff --git a/docs/index.html b/docs/index.html index 9bd783e..59096ee 100644 --- a/docs/index.html +++ b/docs/index.html @@ -58,6 +58,7 @@

🔧 Runbook · 排障

🧪 测试 · 审计报告

@@ -74,6 +75,7 @@

实现计划

diff --git a/docs/plans/security-hardening.html b/docs/plans/security-hardening.html new file mode 100644 index 0000000..4cf4892 --- /dev/null +++ b/docs/plans/security-hardening.html @@ -0,0 +1,61 @@ + + +安全三件套实现计划 — 酒库管理系统 +

安全三件套：限流状态外置 Redis + 公开接口反爬（轻量）+ 边缘层加固（todo #1/#2/#3）

2026-07-05 定稿 · 执行真相源为 plan .md，本页为阅读版 · 状态：已批准，本地实现完成待发版
+

Context

+

阶段 #2 · 限流/登录锁外置 Redis

+

阶段 #3 · 公开接口反爬（轻量版）

+

阶段 #1 · 边缘层加固

+

上线顺序（每个【批准点】单独等用户点头）

+

明确不做（写入 runbook/commit message）

+

风险

+ \ No newline at end of file diff --git a/docs/runbooks/ddos-response.html b/docs/runbooks/ddos-response.html new file mode 100644 index 0000000..e46493f --- /dev/null +++ b/docs/runbooks/ddos-response.html @@ -0,0 +1,105 @@ + + + + + +DDoS / 爬取洪峰应急 Runbook — 酒库管理系统 + + + +

DDoS / 爬取洪峰应急 Runbook

+
目标机：ali（182.92.213.171，2vCPU/1.8GiB，nginx 443 → jiu:8081 / payd:8080）· 2026-07-05 制定 · 配套加固：nginx limit_req/limit_conn/UA 拦截 + 应用层分钟限流/日配额（redis 外置）
+ +
已拍板的风险决策：不预购 DDoS 高防 / 不常备 CDN——当前业务体量（B2B 门店工具，客户量有限）与其成本（高防 ¥2-3k/月起）不匹配。接受「极端容量型攻击下最长黑洞期（2.5~24h）不可用」的残余风险；客户端 App 有本地态可短时离线操作。应用层 CC 攻击由既有多层限流覆盖，不在此风险内。
+ +

一、判定：现在发生的是什么

+
+ + + + + +
症状检查命令 / 位置判定
ssh 卡顿、ping 大量丢包，但机器负载不高ping 182.92.213.171 · 阿里云控制台 ECS 监控「网络带宽」打满容量型 L3/L4（带宽被灌满）→ 走第三节
机器能登，nginx 连接数/QPS 暴涨、CPU 高ss -s · tail -f /var/log/nginx/access.log · top应用层 CC / 爬取洪峰 → 走第二节
IP 全网不可达（连阿里云内网也 ping 不通）控制台 → DDoS 基础防护 → 实例列表：状态「黑洞中」已进黑洞 → 走第四节
+

阿里云免费「DDoS 基础防护」自动生效：清洗阈值与黑洞阈值查询路径 = 控制台 → 安全 → DDoS 基础防护 → 实例列表（北京区黑洞阈值约 5Gbps 量级，以控制台实际显示为准）。超过黑洞阈值即封 IP，黑洞期默认 2.5h，反复被打会延长到 24h，期间无法主动解封。

+
+ +

二、应用层 CC / 爬取洪峰（机器还活着）

+
+
    +
  1. 看清攻击面：awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20 找 top IP；再看打的路径。
    2. +
  2. 封单个/少量 IP：nginx conf 对应 location 或 server 级加 deny 1.2.3.4; → nginx -t && systemctl reload nginx；或阿里云安全组加拒绝规则（源 IP /32，优先级 1）。
    3. +
  3. 整体调紧：把 /etc/nginx/conf.d/jiu.conf 里 jiu_pub 从 10r/s 降到 2r/s、jiu_shoplist 降到 1r/s、jiu_conn 降到 5，reload。注意这是临时手改线上，恢复后必须回滚（下次 server 发版会覆盖为仓库版本）。
    4. +
  4. 应用层兜底：后端还有分钟级限流 + 日配额（redis 外置，重启不丢）；紧急时可在 /opt/jiu/config/production.env 调小 RATELIMIT_* 后 systemctl restart jiu。
    5. +
+
+ +

三、容量型 L3/L4（带宽被灌满，还没进黑洞）

+
+

本机和 nginx 层无能为力（流量在进机器前就占满管道），只有两条路，二选一：

+

路 A：购买阿里云 DDoS 高防（攻击打 IP 也有效，成本高）

+
    +
  1. 控制台购买「DDoS 高防（中国内地）」保险版（约 ¥2-3k/月起 + 弹性按次计费）。
    2. +
  2. 配置网站接入：源站 182.92.213.171，转发 443/80，回源保持 HTTPS。
    3. +
  3. 把 jiu.51yanmei.com 的 A 记录改为高防给的 CNAME（阿里云云解析，TTL 600 内约 10-30 分钟全网生效）。
    4. +
  4. 攻击停止后可退回直连并停止续费。
    5. +
+

路 B：套 CDN / 边缘安全加速（只有攻击打域名时有效）

+
    +
  1. 域名已备案 ✓，可开阿里云 CDN 或 ESA，源站 182.92.213.171:443。
    2. +
  2. 动态 API 全走回源（CDN 主要挡静态与摊薄入口），若攻击者直打源 IP 则无效——届时只能走路 A 或换公网 IP（换 IP 需同步改 DNS + baize 台账 + pay 相关配置）。
    3. +
+
预备项（平时保持）：云解析里 jiu.51yanmei.com 的 TTL 保持 ≤600s，应急切换才快；本 runbook 的回源参数保持最新。
+
+ +

四、已进黑洞

+
+
    +
  1. 黑洞无法主动解除，等待期（控制台显示解封时间）内做两件事：给客户发公告（模板见下）；评估是否走第三节路 A（高防接入可在黑洞期间完成配置，解封即切换）。
    2. +
  2. 客户公告话术模板：「系统服务器正遭受网络攻击，运营商已启动防护，预计 X 时 X 分前恢复。期间已录入的数据不受影响，App 可离线查看，恢复后自动同步。给您带来不便深表歉意。」
    3. +
  3. 事后复盘：控制台下载攻击流量报表，评估是否升级常备防护，更新本 runbook。
    4. +
+
+ +

五、既有防线速查（平时状态）

+
+ + + + + +
层措施位置
阿里云免费 DDoS 基础防护（自动清洗）；安全组仅放行 22/80/443/ICMP控制台 · sg-2ze5y7jqe889jmqb6ci4
nginxlimit_req（公开 10r/s、店铺列表 2r/s）+ limit_conn（20/10/下载 3）+ 抓取库/空 UA 403 + 图片防盗链 + 下载限速deploy/nginx-jiu-ali.conf（CI 下发）
应用per-IP 分钟限流 + 每店 RPS + 登录失败锁 + 日配额（单品 1000/日、列表 300/日）；状态外置 redis 跨重启backend/internal/ratelimit + middleware
+
+ + +