自己搭过邮件服务器的人都清楚，Mail-in-a-Box 这套东西最省心的地方在于它把 Postfix、Dovecot、Roundcube、Nginx 全串好了，一条命令跑完就能收发信。但它默认交付的状态是“能跑”，不是“扛打”。我这两年帮几个小团队维护过自建邮件系统，出问题最多的不是 SMTP 投递链路，而是 Webmail 这一层——Roundcube 直接挂在公网 443 上，登录页、邮件列表、正文渲染，每一个环节都是 XSS 与 CSRF 的潜在入口。这篇 Mail-in-a-Box Webmail 安全加固实战，讲的就是在不改动上游代码的前提下，怎么用反向代理、会话策略和应用配置三层把攻击面压下去。适合已经跑起来一套自建邮箱、打算对外长期开放 Web 入口的朋友，也适合刚开始接触邮件系统安全、想搞清楚“为什么这么配”的同学。文中所有配置都以可复现为目标，参数选择会给出推导过程，踩过的坑也会一并写出来。

1. 先想清楚：Webmail 到底在防什么

1.1 邮件正文是天然的不可信输入源

做 Web 应用安全的人都有一个共识：任何用户可控的输入都必须当作恶意内容处理。邮件系统把这个共识放大了一百倍——因为给你发信的人，你根本不认识，也不需要经过任何认证。一封邮件从外部 SMTP 进来，经过 Postfix 收下、Dovecot 存进 Maildir、Roundcube 从 IMAP 拉出来渲染，这条链路上没有任何一环能保证正文是干净的。

更麻烦的是，邮件正文天生就是 HTML。营销邮件、通知邮件、报表邮件，绝大多数都是富文本格式，里面带内联样式、带图片、带表格、带链接。Webmail 为了不让用户看到一堆源码，必须把这段 HTML 渲染出来。渲染就意味着解析，解析就意味着可能被执行。历史上 Webmail 类产品的 XSS 漏洞，绝大部分都出在 HTML 清洗器上——过滤规则写漏了一个属性、一个协议前缀、一个 SVG 命名空间，攻击面就打开了。

所以加固的第一个认知转变是：不要把 Webmail 当成一个普通 Web 应用，要把它当成一个“每天都在主动加载陌生人提供的 HTML”的容器。这个定位决定了后面所有的配置取向。

1.2 XSS 和 CSRF 在邮箱场景下的破坏力差异

很多人把这两个漏洞混在一起讲，实际上在邮箱场景里它们的攻击路径和后果完全不同，防御手段也不能互相替代。

XSS 的核心是“在受害者浏览器里执行攻击者的脚本”。一旦成功，脚本拥有和当前页面同源的权限，可以读取 DOM 里已经渲染的邮件内容、可以发起任意同源请求、可以把邮件列表里的信息打包外发。对于企业邮箱来说，一封精心构造的邮件如果能稳定触发存储型 XSS，等于攻击者拿到了一个可以持续窃取信件的后门，而且受害者完全无感。

CSRF 的核心是“借用受害者的已登录状态发起操作”。它不需要执行脚本，只需要诱导你点开一个页面，页面上一个自动提交的表单或者一个图片标签，就能让你的浏览器带着 Cookie 去请求 Webmail 的某个接口。在邮箱场景里，最有价值的 CSRF 目标不是“发一封垃圾邮件”，而是自动转发规则和密码修改。前者一旦被写入，攻击者从此能静默抄送你所有来信；后者直接导致账号易主。这两个操作一旦被 CSRF 打通，损失是不可逆的。

理解了这层差异，加固方案的设计就有了主线：XSS 靠“输出侧净化 + 执行侧限制”双管齐下，CSRF 靠“令牌 + 会话属性 + 来源校验”三层拦截。

2. 加固方案的整体设计与选型考量

2.1 为什么不直接改 Roundcube 源码

我见过一些团队的做法是直接 fork 一份 Roundcube，在模板里手动加转义、在控制器里加校验。这个思路我不推荐，原因有三个。

第一是维护成本。Mail-in-a-Box 本身有升级脚本，Roundcube 也在持续发版修安全问题。你 fork 之后，每次上游更新都要手工合并，合并冲突处理不好就会漏掉安全补丁，反而比不打补丁更危险。

第二是改错的风险高。XSS 防护最怕“以为改了其实没改”，模板里加一个htmlspecialchars看起来解决了问题，但如果上下文是 JavaScript 字符串或者 URL 属性，转义方式完全不同，加错了等于没加，还会给人虚假的安全感。

第三是职责边界。Roundcube 自己有一套相对成熟的输出编码和 HTML 清洗机制（rcube_washtml那一套），这套东西的正确性依赖于它自己的上下文判断。你在外面再包一层，很容易和它打架，比如双重转义导致显示乱码。

所以我的方案是：应用层配置只做“收紧开关”，真正的拦截放在反向代理和会话层。代理层能做的事其实很多——安全响应头、CSP、请求方法限制、来源校验，这些都不需要动一行 PHP 代码，升级时也不受影响。

2.2 分层防御的骨架怎么搭

整套加固我分成四层，从外到内依次是：

这个分层的好处是每层都能独立生效，也能独立回滚。CSP 配错了顶多页面样式崩，不会导致整个 Webmail 打不开；会话策略配错了用户会频繁掉线，但至少不会泄露数据。逐层上线、逐层验证，比一次性全量改要稳得多。

2.3 兼容性与可用性的取舍原则

安全加固最容易翻车的地方是“配得太狠，用户没法用”。CSP 直接上default-src 'none'，页面必然白屏；SameSite 直接上Strict，用户从邮件里的链接点回来会丢会话；把unsafe-inline全禁了，很多皮肤的内联样式会失效。

我的取舍原则是：先观察，再拦截。CSP 先以Content-Security-Policy-Report-Only模式跑一周，收集违规报告，看清楚哪些资源是真的需要放行，再切成强制模式。SameSite 从Lax起步，观察登录跳转和外部链接回流的体验，稳定之后再评估要不要收紧到Strict。这个节奏看起来慢，但避免了“上线当天全员无法登录”的灾难。

提醒：任何安全响应头的调整都建议在维护窗口做，并且提前准备好回滚命令。Nginx 改完先nginx -t校验语法，再systemctl reload nginx平滑重载，不要直接 restart。

3. XSS 防御的核心细节拆解

3.1 邮件正文渲染的三个风险点

邮件正文在 Webmail 里的渲染路径，风险主要集中在三处。

第一处是HTML 邮件的清洗边界。Roundcube 默认会把 HTML 正文塞进一个 iframe（sandbox 属性可配），或者经过rcube_washtml清洗后内联输出。清洗器要处理的边界情况非常多：<svg>里嵌<script>、<math>里的表达式、data:协议的 URI、javascript:前缀被编码绕过、CSS 的expression()、<iframe srcdoc>等等。这些不是靠一两条正则能覆盖的，所以我的建议是不要尝试自己写清洗规则，把这件事交给上游，然后通过 CSP 做第二道兜底。哪怕清洗器漏了一个，CSP 也能拦住脚本执行。

第二处是邮件头的输出上下文。发件人显示名、主题、附件文件名，这些字段会出现在列表页、详情页、下拉菜单、提示框里。不同位置的输出上下文不一样——列表页是 HTML 文本节点，标题栏可能是title属性，附件名可能进 URL 参数。同一个恶意字符串在不同上下文里的转义方式完全不同，这是经典的“同一条数据多处输出”陷阱。

第三处是URL 参数反射。搜索框、分页参数、_task/_action这类路由参数，如果被直接回显到页面上就会形成反射型 XSS。这类漏洞的特点是攻击者需要构造一条链接诱导点击，虽然利用门槛比存储型高，但在钓鱼场景里依然有效。

3.2 CSP 与输出编码是互补关系不是替代关系

有个常见误区是“上了 CSP 就不用管转义了”。这个想法很危险。

CSP 的作用是限制“什么样的脚本可以执行”，它拦不住“数据被错误地渲染成结构”。举个具体例子：如果邮件主题里的双引号没有被转义，直接拼进了title="..."属性，攻击者可以闭合属性再注入一个新属性。这种情况下没有脚本执行，CSP 完全不会报警，但页面结构已经被破坏了，可能被用来做点击劫持或者伪造界面。

反过来，输出编码也替代不了 CSP。编码只能保证“数据不出界”，但只要页面里存在任何一个合法的脚本注入点（比如某个第三方库的动态执行、某个eval调用），编码就无能为力了。CSP 是在这个层面做最后一道闸。

所以正确的姿势是：默认相信 Roundcube 的输出编码，用 CSP 兜住“万一编码漏了”的情况。两者叠加，才是纵深防御。

3.3 Cookie 属性与 DOM 侧的最后兜底

除了 CSP，还有两个成本极低但效果明显的配置。

一是HttpOnly。会话 Cookie 加上HttpOnly后，JavaScript 读不到document.cookie，即使 XSS 成功执行，也没法直接把会话 ID 偷走。这不能阻止攻击者在页面内为所欲为，但能显著降低“会话被完整接管”的风险，把一次 XSS 从“永久后门”降级成“单次页面内操作”。

二是Secure。强制 Cookie 只在 HTTPS 下传输，避免明文链路上被嗅探。自建邮箱如果做了强制 HTTPS 跳转，这一条基本是顺带的，但配置里必须显式写上，不能靠默认值。

再往下是iframe sandbox。Roundcube 渲染 HTML 正文时可以走 iframe 模式，给 iframe 加sandbox="allow-same-origin"之类的属性，把脚本执行能力直接掐掉。这个方案对正文里的交互式内容（比如某些邮件里的表单）有影响，但对普通阅读场景完全够用。我的建议是默认开启，让用户明确知道“这封邮件里有需要交互的内容”时再手动放行。

4. CSRF 防御的完整链条

4.1 令牌机制为什么必须配合会话属性

Roundcube 内置了请求令牌机制，表单提交时会带上一个_token字段，服务端校验不通过就拒绝。这个机制的原理是：攻击者的页面无法读取受害者浏览器里的令牌值（受同源策略保护），所以伪造不出合法请求。

但令牌机制有个前提——攻击者不能读取页面内容。如果存在 XSS，令牌就能被读出来，CSRF 防护直接失效。这就是为什么 XSS 和 CSRF 必须一起治，只治一个等于没治。

另一个容易被忽略的点是令牌的绑定范围。如果令牌是全局固定的，一旦泄露就是永久有效；理想的做法是与会话绑定，会话销毁令牌失效。Roundcube 的默认实现是会话级的，这一点不需要额外改，但要确保会话本身是安全的（见下一节）。

4.2 SameSite 策略在邮箱场景下的实际影响

SameSite是浏览器层面的 CSRF 缓解手段，它控制 Cookie 在跨站请求中是否被发送。

• Strict：任何跨站请求都不带 Cookie。安全性最高，但用户体验有损——从外部链接（比如邮件里的链接、聊天软件里的链接）点回 Webmail，浏览器不会带会话 Cookie，用户会看到登录页。
• Lax：顶层导航的 GET 请求带 Cookie，POST 和 iframe 等子请求不带。这是目前的主流选择，防住了绝大部分 CSRF，同时保留了从外部点链接的正常体验。
• None：必须配合Secure，等于放弃了 SameSite 防护，除非有明确的跨站嵌入需求，否则不要用。

对自建 Webmail 来说，我推荐Lax。理由是邮箱的使用场景里，“从外部点链接进来”是高频行为，Strict带来的重登录体验损失不值得。而Lax已经拦住了 POST 型 CSRF，剩下的风险靠令牌机制覆盖。

需要额外注意的是，如果 Webmail 和主站不同域（比如mail.example.com和www.example.com），SameSite判断的是“站点”而不是“域”，同站点下的子域互访不受影响。这一点在规划域名时要提前想清楚。

4.3 敏感操作的二次确认与来源校验

令牌和 SameSite 都是技术手段，还有一层是产品层面的设计：对不可逆的敏感操作做二次确认。

邮箱里最值得做二次确认的操作有这么几个：修改密码（要求输入当前密码）、设置自动转发（要求输入当前密码或者邮件验证）、删除账号、修改恢复邮箱。这几个操作的共同点是“一旦被攻击者得手，损失不可逆”。

代理层也能加一道来源校验。具体做法是在 Nginx 里对 POST 请求检查Origin或Referer头，如果来源不是本站域名就直接拒绝。这个检查对正常用户完全透明，但对跨站伪造请求是致命的——因为浏览器在跨站发起的请求里，Origin头会如实标注来源，攻击者没法伪造（这是浏览器强制的，不是 JS 能改的）。

# 示意：对 POST 请求做 Origin 校验 if ($request_method = POST) { set $origin_ok 0; if ($http_origin ~* "^https://mail\.example\.com$") { set $origin_ok 1; } if ($http_origin = "") { set $origin_ok 1; } # 同源表单可能不带 Origin if ($origin_ok = 0) { return 403; } }

上面这段只是示意逻辑，实际部署时要把域名换成自己的，并且注意if在 Nginx 里的已知限制——if块内不能随意嵌套，复杂逻辑建议用map指令改写。这个校验作为令牌机制之外的补充，不要当成唯一防线。

5. 实操落地：从配置文件到验证测试

5.1 Nginx 反向代理层的安全响应头配置

Mail-in-a-Box 的 Nginx 站点配置由管理脚本生成，直接改生成出来的文件，下次跑升级脚本会被覆盖。我的做法是在站点配置里include一个自己维护的片段文件，比如/etc/nginx/conf.d/webmail-hardening.conf，这样升级后即使主配置被重写，只要 include 语句还在（或者升级后重新加一次），加固内容就能保留。

下面是我实际用的响应头组合，逐条说明用途：

# /etc/nginx/conf.d/webmail-hardening.conf add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always; add_header Cross-Origin-Opener-Policy "same-origin" always; add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; font-src 'self' data:; connect-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; object-src 'none'; report-uri /csp-report" always;

逐条解释一下为什么这么选：

X-Content-Type-Options: nosniff禁止浏览器做 MIME 类型嗅探。有些老攻击手法是把恶意内容伪装成图片上传，靠浏览器嗅探成 HTML 来执行，这个头直接堵死。

X-Frame-Options: SAMEORIGIN防点击劫持。虽然 CSP 的frame-ancestors已经覆盖了这个功能，但老浏览器可能不认 CSP，两个都写属于兼容性保险。

Referrer-Policy控制跨域请求携带多少来源信息。strict-origin-when-cross-origin的意思是同源请求带完整路径，跨域只带域名，HTTPS 降级到 HTTP 时不带。这样既保留了站内统计能力，又不会把邮件 ID 之类的敏感路径泄露给外部站点。

Permissions-Policy关掉地理定位、麦克风、摄像头。Webmail 用不到这些，关掉可以减少被恶意 iframe 借用的风险。

CSP 那一行先用Report-Only模式。script-src 'self'表示只允许加载本站脚本，禁掉一切内联onclick和<script>块。style-src保留了'unsafe-inline'，因为 Roundcube 的皮肤里有大量内联样式，禁了会直接崩样式。img-src允许data:和blob:，因为邮件里的内联图片和附件预览需要。form-action 'self'限制表单只能提交到本站，这对 CSRF 是个额外约束。object-src 'none'禁掉 Flash 之类的插件对象。

注意：add_header有个坑——如果location块里也写了add_header，父级的add_header全部不继承（不是合并，是覆盖）。所以要么把加固头写在最外层 server 块，要么在每个需要的 location 里重复写一遍。我踩过这个坑，排查了半天才发现某个 location 的安全头全丢了。

5.2 PHP 与 Roundcube 侧的会话安全参数

代理层管住了响应头，会话本身的安全要落到 PHP 和 Roundcube 配置上。

先看 PHP-FPM 的池配置（一般在/etc/php/*/fpm/pool.d/下），重点是这几项：

php_admin_value[session.cookie_httponly] = 1 php_admin_value[session.cookie_secure] = 1 php_admin_value[session.use_strict_mode] = 1 php_admin_value[session.use_only_cookies] = 1 php_admin_value[session.sid_length] = 48 php_admin_value[session.sid_bits_per_character] = 6

session.use_strict_mode这一项值得单独说。它要求 PHP 只接受自己生成过的会话 ID，客户端随便传一个不存在的 ID 过来，PHP 会拒绝并重新生成。这防的是会话固定攻击——攻击者先拿到一个自己知道的会话 ID，诱导受害者用这个 ID 登录，之后攻击者就能用同一个 ID 访问受害者会话。开启严格模式后，这个套路直接失效。

sid_length和sid_bits_per_character是加大会话 ID 的熵。默认值在一些老版本上偏短，调到 48 位长度、每字符 6 bit，暴力猜解的成本高到可以忽略。

再看 Roundcube 的配置文件（一般在安装目录的config/config.inc.php）。下面这几项是我认为必改的：

// 关闭安装器，装完就关，这个是硬要求 $config['enable_installer'] = false; // 强制 HTTPS $config['use_https'] = true; $config['force_https'] = true; // 会话策略 $config['session_lifetime'] = 30; // 分钟，按团队习惯调 $config['session_samesite'] = 'Lax'; $config['session_domain'] = ''; // 登录限速，防暴力破解 $config['login_rate_limit'] = 3; $config['login_rate_limit_window'] = 300; // 邮件图片加载策略：0=不加载 1=总是加载 2=同域加载 $config['show_images'] = 2; // 禁用远程资源预取，减少信息泄露 $config['preview_pane'] = true;

enable_installer这一项特别要强调。Roundcube 的安装器是个独立的入口，能检测环境、写配置，如果忘了关，等于把配置修改权限挂在公网上。装完第一件事就是把installer目录删掉或者改权限，配置里再关一次，双保险。

show_images = 2是一个偏保守的选择。邮件里的远程图片是经典的追踪像素——发信方在图片 URL 里带上唯一标识，你只要加载了图片，对方就知道你什么时候看了这封信、用的什么客户端。设成 2 表示只加载同域图片（比如邮件里嵌入的附件图片），外部图片默认不加载，用户如果确实要看，会有个确认提示。这个设置对体验有一点影响，但对隐私的保护是实打实的。

5.3 验证：手工 PoC 与自动化检查

配置改完不代表生效，必须验证。我一般分两步走。

第一步是响应头核对，用 curl 直接看：

curl -sI https://mail.example.com/ | grep -iE "content-security|x-frame|x-content|referrer|set-cookie"

重点看三件事：CSP 头有没有出现、Set-Cookie里有没有HttpOnly和Secure标记、SameSite是不是预期的值。如果 Cookie 是 PHP 自动生成的会话 Cookie，它的属性来自 php.ini 配置，改完要重载 PHP-FPM 才生效，重启 Nginx 是没用的——这个顺序问题我见过太多次了。

第二步是 CSRF 的手工验证。在自己的测试环境里，本地写一个 HTML 文件，模拟跨站表单提交到 Webmail 的某个写操作接口：

<!-- 仅用于自有环境的安全测试 --> <form id="f" action="https://mail.example.com/?_task=settings&_action=save-identity" method="POST"> <input name="name" value="test"> <input name="email" value="attacker@example.net"> </form> <script>document.getElementById('f').submit();</script>

保存成.html从本地文件打开（这样来源就是null或者file://，算跨站），看提交后返回什么。预期结果是 403 或者被重定向回列表页，而不是提示“保存成功”。如果居然成功了，说明令牌校验没生效，要回去检查是不是某些接口走了例外路径。

第三步是 CSP 报告的收集。Report-Only模式跑一周，把/csp-report这个端点收到的 JSON 收集起来，看看被拦的都是些什么资源。常见的误报是某些皮肤的动态样式、某些插件的脚本加载。根据报告内容逐条调整script-src和style-src的白名单，调整到“正常功能零违规”之后再切成强制模式。

提示：切强制模式前，建议先在一个小范围（比如只对自己的账号或者测试账号）验证一遍完整流程：登录、收信、看 HTML 邮件、带附件转发、修改密码。这几个流程覆盖了大部分脚本和样式的加载路径，全部走通再放开。

6. 常见问题与排查技巧实录

6.1 上了 CSP 之后页面样式错乱或白屏

这是最常见的反馈。原因基本集中在两类：一类是style-src没给'unsafe-inline'，皮肤里所有内联style="..."全部失效，界面直接变形；另一类是img-src漏了data:，图标字体、内联小图片全部加载失败，看起来像“白屏”。

排查方法是打开浏览器开发者工具的控制台，CSP 违规会打印明确的错误信息，包含被拦的资源 URL 和违反的指令名。照着报错逐条补白名单，别凭感觉猜。我一般的顺序是先补style-src和img-src（这两个最影响观感），再处理script-src（这个最影响功能），最后处理connect-src（影响 AJAX 请求，报错会在网络面板里表现为请求被 block）。

还有一种隐蔽情况：某些资源是通过blob:URL 加载的，比如附件预览、前端生成的下载链接。这种要在img-src或者default-src里显式允许blob:，否则功能看着正常，一点预览就失败。

6.2 登录后频繁掉会话，几分钟就要重登

会话丢失的排查要按“从外到内”的顺序来。

先看 Cookie 的Secure标记和实际访问协议是否匹配。如果前面有一层负载均衡或者 CDN 做 TLS 终止，后端 Nginx 看到的是 HTTP，如果此时又在后端强制Secure，浏览器那边是 HTTPS 但后端认为不安全，可能出现各种诡异行为。这种情况下要在代理层把X-Forwarded-Proto头正确透传，应用侧据此判断真实协议。

再看session_lifetime和 PHP 的session.gc_maxlifetime是否一致。两个值不一致时，PHP 的垃圾回收可能在你还没到 Roundcube 配置的过期时间就把会话文件删了，表现就是“明明设了 30 分钟，5 分钟就掉线”。这两个值要设成一样，或者让 PHP 的略大一点。

最后看session_domain有没有设错。如果设成了mail.example.com，但从example.com的某个路径访问 Webmail，Cookie 就不会被带上，表现是“登录成功了但下一页又是登录页”。

6.3 表单提交返回 403 或者提示 token 失效

令牌校验失败通常有三个来源。

一是会话过期但页面还开着。用户在登录页停留太久，会话已经失效，这时候提交表单，令牌自然对不上。这种情况的正确处理是重定向到登录页并给出友好提示，而不是抛一个 403 让用户一头雾水。

二是多标签页或者多设备登录。如果令牌和会话强绑定，而用户开了多个标签页，某些操作可能会刷新令牌导致其他标签页的旧表单失效。这是设计上的取舍，一般不影响主流程，但如果团队里有人习惯开一堆标签页，可能会抱怨。可以考虑把令牌的校验放宽到“会话内有效”，而不是“一次性有效”。

三是反向代理改写了请求体。这种情况比较少见，但如果代理层做了请求体大小限制或者内容重写，可能会导致表单字段丢失，令牌字段被截断。排查方法是看 Nginx 的 error log 里有没有client intended to send too large body之类的记录，有的话调client_max_body_size。

6.4 邮件里的外链图片和跟踪像素怎么处理

这个话题在隐私加固里份量不小。邮件里的远程图片是发信方追踪阅读行为的标准手段，图片 URL 里带唯一 ID，你一加载，对方服务器就记一笔。

从防御角度有三层可以做：

第一层是应用配置，把show_images设成不自动加载外部图片，用户要看就点确认。这个最简单，但依赖用户的行为习惯。

第二层是图片代理。让 Webmail 通过自己的服务器去拉取图片，再把图片转给浏览器。这样发信方看到的是你的服务器 IP，不是用户的真实 IP，追踪链就断了。Roundcube 有一些插件能做这件事，配置成本中等，但对隐私保护效果明显。

第三层是响应头层面的限制，用 CSP 的img-src只允许本站和data:，把外部图片域名全部拦掉。这个做法最彻底，但会影响正常邮件的观感——很多营销邮件没有图片就是一片空白。

我的实际做法是第二层加第一层：默认不自动加载，用户点击后通过代理加载。既保住了阅读体验，又切断了追踪链路。

6.5 常见问题速查表

7. 上线节奏与长期维护的几个建议

7.1 分阶段上线的具体排期

我不建议一次性把所有配置推上去。实际执行的节奏是这样的：

第一天，只上响应头里的X-Content-Type-Options、X-Frame-Options、Referrer-Policy这三项。这三项对功能零影响，属于纯收益，出问题的概率极低。

第二天到第三天，上SameSite=Lax和 Cookie 的HttpOnly/Secure。这一步会影响会话行为，需要重点观察登录、外部链接回流、多标签页这几个场景。

第四天到第十天，CSP 走 Report-Only 模式，收集一周的违规数据。这期间只观察不拦截，每天早上花十分钟看看报告里有没有异常。

第十一天，根据报告调整完白名单后切强制模式。切换当天保持监控，准备好回滚命令。

第十二天起，做 Roundcube 配置的收紧——关安装器、调show_images、加登录限速。这些属于应用层，影响面可控。

这个排期看起来拖，但每一步都有明确的验证点和回滚点，出了问题能快速定位到是哪一层的改动导致的。

7.2 升级之后怎么保住加固配置

Mail-in-a-Box 的升级脚本会重新生成 Nginx 配置和部分应用配置，这是自建邮箱维护里最容易翻车的地方。我的做法是维护一个独立的加固脚本，放在/root/下，升级之后手动跑一次。

脚本内容大概就是：把加固片段文件复制到/etc/nginx/conf.d/、检查主配置里有没有 include 语句（没有就追加）、校验 Roundcube 配置里的关键项（有则改之）、最后nginx -t加systemctl reload。

这个脚本不需要写得很复杂，几十行 bash 就够，核心是幂等——跑一次和跑十次结果一样。每次升级后跑一遍，配置就回来了。我还会在日历上设个提醒，每月检查一次关键配置项是否还在，因为有些升级路径可能连 include 语句都清掉了。

7.3 日志里值得盯的几个信号

加固做得再好，也得靠日志发现问题。我一般关注这么几类记录：

Nginx 的 access log 里，如果某个 IP 在短时间内大量请求带_task=login的路径，基本就是撞库。配合 fail2ban 自动封禁，能挡掉大部分自动化攻击。Roundcube 自己的 log 目录下会记录登录失败、会话异常、插件报错，这些是应用层的信号。还有 CSP 报告的端点，如果某天突然出现大量来自同一个来源的违规记录，可能意味着有人在尝试探测注入点。

另外建议把 Webmail 的访问日志和邮件投递日志分开存储，前者保留时间长一点（比如 90 天），方便事后追溯。邮箱系统一旦出问题，追溯窗口往往比想象的长。

我在实际维护里最大的体会是：加固不是一次性的配置动作，是一个持续的观察和调整过程。头一年我几乎每两周就要看一次 CSP 报告和登录失败日志，慢慢把规则调到一个既安全又不影响使用的平衡点。后面就轻松了，配置稳定下来，每月例行检查一次就够。真正需要警惕的是升级——每次版本变动都可能引入新的资源加载方式，CSP 白名单要跟着调整，这个环节千万别图省事跳过。