Xiuno 安全加固实战：WAF接入全攻略

52JinY 助手

很多朋友把 Xiuno 搭起来后，就放着跑，直到被扫库、挂暗链才开始补课。说实话，Xiuno 轻量是优点，也是风险：默认配置偏“开发友好”，对攻击面的收口不够。下面把我给几个站做安全加固与接入 WAF 的要点梳理一下，尽量说人话，能落地。

先从最低成本的“房门上锁”做起。后台路径别用默认的 admin，而是改成随机长路径，并在服务器侧对后台再加一层 HTTP 基本认证或基于 IP 白名单的限制。管理员账号禁用弱口令，开启两步验证（没有内置就用反向代理层做 OTP 校验或用独立的登录保护插件）。定期清理不必要的管理员与版主权限，很多事故来自“临时开了就忘”的账号。

文件与目录权限是第二道坎。Xiuno 的 writable 目录要最小化授写范围，典型是 upload、cache 这类，chmod 控制在 0755/0644，拒绝 0777。给可写目录加上服务器级的执行阻断：Nginx 用 location 限制 php 执行只允许在指定目录，禁掉 upload 下的 php、phar、phtml 扩展。顺手在这些目录丢一份空的 index.html，降低目录遍历泄露几率。

SQL 与配置安全同样重要。数据库账号只给最小权限，别用 root；库、表前缀不要默认；把 config 里的密钥换成高熵随机值。能上 MySQL 的 socket 连接就别暴露 3306 给公网。再者，关闭 PHP 的危险函数（exec、shell_exec、proc_open 等），打开 open_basedir 限制，禁用 phar 的反序列化入口，很多“传马”都走这一套。

HTTPS 是基础设施。全站强制 HTTPS，HSTS 开启，TLS 版本不低于 1.2。证书用自动续期（acme），避免“证书过期一夜之间全站掉光流量”。同理，站点的 Cookie 设置 secure + httponly，管理端再加 samesite=strict。

再说 WAF 接入与策略落地。对于中小站点，选云厂商自带的 CDN+WAF 是性价比最高的方案：把 A 记录切到 CDN，回源走内网或指定端口，源站只对 CDN IP 开放。WAF 规则别一上来全开最严，容易误伤发帖与附件上传。我的做法是：
- 先开托管规则的低敏级别，只拦已知恶意 IP、僵尸 UA、明显的 SQLi/XSS 特征；
- 打开敏感接口限速：登录、注册、找回密码、发帖接口按 IP/账号做速率限制，比如 60s 内 5 次；
- 针对上传接口单独放行 multipart 表单，但白名单扩展，开启内容型检测（阻断包含 PHP 代码片段的伪装图片）；
- 开启 5 秒挑战或 JavaScript 挑战，仅对高风险路径与异常流量国家/地区生效，避免影响正常用户；
- 开启自定义规则记录模式跑一周，观察误报，再切换成阻断。日志里重点看 URI、参数长度、Referer 异常。

别忽视应用层的小护栏。表单统一加 CSRF Token，登录失败做指数级退避，验证码在异常频率时触发而不是全局常开。对用户生成内容做最小可信渲染，严控 BBCode/HTML 白名单；预览与保存两边都做服务端校验，前端校验只能当体验优化。

监控与应急是“出事不慌”的底气。打开 WAF 日志推送，源站也要有 Nginx 访问/错误日志留存，配合 fail2ban 对暴力 IP 立即拉黑。做全量与增量备份：数据库每天，附件每周，异地存一份；演练一次“还原到昨天”的流程，很多人以为能恢复，真到时候才发现没脚本、没带宽、没窗口。

最后提醒两点现实主义：一是插件来自何处要心里有数，别为了一个小功能引入全站钩子、外链脚本；二是别迷信“装上 WAF 就安全”。安全是组合拳：最小权限、面向失败的设计、可观测与可恢复。把这些基本盘打稳，Xiuno 跑得久、跑得稳，比啥都更省心。