SamWaf v1.3.21 从多个 beta 版本进入正式版，这次升级的关键词很明确：更安全、更省心。对运维来说，最需要提前看清的是登录密码加密方式从 MD5 切换到 bcrypt。向上升级正常情况下无感，但一旦升级后再回滚到 v1.3.21-beta.8 之前的版本，旧版本可能无法识别新密码格式。
这次最该关注的不是功能，而是升级路径
WAF 属于边界组件，升级失败的代价通常比普通后台服务更高：管理后台进不去、规则无法调整、流量代理异常，都会直接影响站点暴露面。
v1.3.21 的一个关键变化是密码哈希算法升级：
- 旧方式：MD5，速度快，但抗暴力破解能力弱。
- 新方式：bcrypt，带成本因子，计算更慢，更适合存储登录密码。
- 向上升级：正常升级无需额外操作。
- 回滚风险：如果从 v1.3.21 回滚到 v1.3.21-beta.8 之前版本，旧版本可能无法处理 bcrypt 后的密码。
这类变更不是简单的二进制替换问题，而是数据格式迁移问题。升级前要把“能不能启动”之外的检查补齐：能否登录、能否加载站点配置、能否应用防护规则、能否查看日志。
bcrypt 的价值：让密码库泄露后的攻击成本变高
MD5 的问题不只是“老”，而是它太快。攻击者拿到哈希后，可以用 GPU 或彩虹表快速试探大量候选密码。bcrypt 的设计目标正好相反：让每次校验都需要可控成本，从而提高离线破解门槛。
对 SamWaf 这类私有化部署的网站防火墙来说，管理后台密码尤其敏感。WAF 规则、放行策略、黑白名单、站点代理配置都集中在后台，一旦后台账号被撞开，攻击面会从“绕过防护”变成“直接修改防护”。
不过 bcrypt 也不是银弹：
- 弱密码仍然危险，bcrypt 只是拖慢破解速度。
- 需要保管好备份，备份库里同样包含敏感配置。
- 回滚前要确认密码字段兼容性，不能只看程序版本。
可以这样实践：升级前做一次可回退快照
下面示例不假设你的 SamWaf 具体安装方式，只给出一个通用升级前备份脚本。运行前把 SAMWAF_HOME 改成你的实际安装目录，例如 /opt/samwaf。如果你的数据目录、配置目录名称不同，也要同步调整。
#!/usr/bin/env bash
set -euo pipefail
SAMWAF_HOME="/opt/samwaf"
BACKUP_ROOT="/opt/backups/samwaf"
TS="$(date +%Y%m%d-%H%M%S)"
BACKUP_DIR="${BACKUP_ROOT}/${TS}"
mkdir -p "${BACKUP_DIR}"
# 按你的实际目录调整：常见需要备份配置、数据、证书、规则文件。
tar -C "${SAMWAF_HOME}" -czf "${BACKUP_DIR}/samwaf-files.tgz" \
conf data certs rules 2>/tmp/samwaf-backup-warn.log || true
# 记录当前版本和文件校验，方便回滚时核对。
if [ -x "${SAMWAF_HOME}/samwaf" ]; then
"${SAMWAF_HOME}/samwaf" --version > "${BACKUP_DIR}/version.txt" 2>&1 || true
fi
find "${SAMWAF_HOME}" -maxdepth 2 -type f -print0 \
| sort -z \
| xargs -0 sha256sum > "${BACKUP_DIR}/sha256sum.txt"
cat > "${BACKUP_DIR}/README.txt" <<EOF
SamWaf pre-upgrade backup
Time: ${TS}
Source: ${SAMWAF_HOME}
Before rollback, verify whether the target version supports bcrypt password hashes.
Rolling back to versions earlier than v1.3.21-beta.8 may break admin login.
EOF
echo "Backup written to: ${BACKUP_DIR}"
if [ -s /tmp/samwaf-backup-warn.log ]; then
echo "Warnings:"
cat /tmp/samwaf-backup-warn.log
fi
执行方式：
chmod +x backup-samwaf-before-upgrade.sh
sudo ./backup-samwaf-before-upgrade.sh
如果你用 systemd 管理 SamWaf，可以在升级前后记录服务状态：
sudo systemctl status samwaf --no-pager
sudo journalctl -u samwaf -n 100 --no-pager
如果你用容器部署，可以采用类似的思路备份挂载卷。以下是一个可改造的 docker compose 示例，目录名仅作假设，请按你的实际镜像名和挂载路径调整：
services:
samwaf:
image: your-registry/samwaf:v1.3.21
container_name: samwaf
restart: unless-stopped
ports:
- "80:80"
- "443:443"
- "26666:26666"
volumes:
- ./samwaf-data:/app/data
- ./samwaf-conf:/app/conf
- ./samwaf-certs:/app/certs
升级前可以先打包这些挂载目录：
mkdir -p backups
tar -czf "backups/samwaf-compose-$(date +%Y%m%d-%H%M%S).tgz" \
docker-compose.yml samwaf-data samwaf-conf samwaf-certs
升级后别急着关窗口：做四类验证
WAF 升级后的验证应该贴近真实流量，而不是只看进程是否存活。
建议检查：
- 管理后台：管理员账号能否正常登录，密码变更是否可用。
- 站点代理：被保护网站的首页、登录页、静态资源是否正常。
- 防护规则：已有规则是否仍然生效，误拦截是否增加。
- 日志审计：访问日志、拦截日志、错误日志是否持续写入。
可以准备一个最小化验证脚本，把域名换成你的测试站点：
#!/usr/bin/env bash
set -euo pipefail
BASE_URL="https://example.com"
curl -k -fsS "${BASE_URL}/" -o /tmp/samwaf-home.html
curl -k -fsS "${BASE_URL}/favicon.ico" -o /tmp/samwaf-favicon.ico || true
# 一个常见的探测型 payload，用于确认 WAF 日志/规则是否有记录。
# 不建议直接打生产核心接口；优先使用测试域名或低风险路径。
curl -k -sS "${BASE_URL}/?q=%3Cscript%3Ealert(1)%3C/script%3E" -o /tmp/samwaf-xss-test.html || true
echo "Basic traffic checks completed. Now inspect SamWaf access/block logs."
这段脚本不等于安全测试，只是升级后冒烟检查。真正上线前，还应结合你的业务路径、规则集和白名单策略做更完整的回归。
采用建议：把 v1.3.21 当成一次安全迁移
SamWaf v1.3.21 值得升级的核心理由，是它把后台密码存储从 MD5 推向 bcrypt，这符合现代密码存储的基本要求。但这也意味着你要把它当成一次带数据格式变化的安全迁移来处理。
上线前保留三件东西：升级前备份、当前版本记录、回滚版本包。上线后盯住三类信号：登录是否正常、业务流量是否正常、拦截日志是否正常。若确实需要回滚，优先回滚到理解 bcrypt 密码格式的版本；如果必须回到更早版本，要提前准备后台账号恢复方案，避免在故障窗口里才发现无法登录。
对轻量级、私有化部署的 WAF 来说，“省心”不是少做检查，而是把检查脚本化、流程化。v1.3.21 的升级点正适合顺手把这套流程补起来。