先把结论放前面
2023 年我们一个做跨境电商 SaaS 的团队要把主站搬到新加坡，老板顺手给我加了活：把 IPS 也一起搞了。我当时的理解是买台盒子挂链路上就完事，结果这活从 3 月干到 6 月，中间因为一条 GeoIP 规则把雅加达的客服团队全员拦在后台外面，被人在群里 @ 了一上午。所以这不是什么标准答案，就是我翻过的坑，加了点事后复盘觉得顺序该换的地方。
如果你现在正在搜这个东西，大概率你手上也有个出海项目，可能还没想清楚一个问题：你的明文字节到底在哪个国家落地。 这个问题比「选 Fortinet 还是 Palo Alto」重要得多，后面会展开。
一、我一开始看错了指标
大部分人挑 IPS 的第一反应是翻 datasheet 里 IPS Throughput 那一栏，我也不例外。FortiGate 600F 标 7 Gbps，Palo Alto PA-3410 那一栏大概 8.6 Gbps，看着都挺香。但你真把它串到业务链路上、真的开了 TLS 解密，Threat Protection 那一行的数字会直接掉到三分之一——600F 的 Threat Protection 我记得标 3 Gbps 上下，而且那还是理想包长下测出来的。真实业务流量里小包占比能到六七成，最后能扛多少，自己心里得有数。
后来我觉得，出海 IPS 的第一性问题压根不是「检测率多高」，而是探针放在哪条数据主权边界之内。你比如在新加坡本地做 TLS 解密，明文落在新加坡，这条链路不涉及跨境传输；但你要是图省事，把新加坡节点的流量通过专线拉回香港的解密集群统一检测，那新加坡到香港这一跳就是一次跨境数据流动，你要准备的东西立刻从「买设备」升级成「做数据映射 + 签 SCC + 改隐私政策 + 和法务对一遍」。同样的检测动作，位置不同，合规成本差好几倍。
我们最后选的是前者：每个区域一套轻量探针，明文不出本区域。代价是规则要维护三份、告警要汇总、运维复杂度直接翻倍。但省下来的合规解释成本，我到现在都觉得值。
二、三条路，我把当时的账摊开算
市面上能走的路其实就三条，我按当时调研的口径列一下，数字都是 2023 年下半年的，现在可能有变，你们自己去核实一遍：
| 方案 | 典型配置 | 吞吐参考 | 落地周期 | 适合谁 |
|---|---|---|---|---|
| 硬件盒子 | FortiGate 600F / PA-3410 | 标称 IPS 7~8.6 Gbps，开了 TLS 解密按 1.5~2 Gbps 实打实估 | 采购加东南亚备件调拨，4~8 周 | 流量集中、有自建机房、采购流程要求硬件凭证 |
| 云厂商托管 | AWS Network Firewall / 云防火墙 | 按流量计费，规则条数有上限，TLS 走旁路解密 | 当天能开 | 纯云上、人手少、不想碰底层 |
| 自建 Suricata | c6i.4xlarge（16 vCPU / 32 GiB） | AF_PACKET 模式我跑到 6.8 Gbps 左右开始丢包，DPDK 能翻倍但调起来要命 | 从零搭一周起 | 有 SRE、要深度定制规则 |
中间那条我多说一句。AWS Network Firewall 当时是 $0.395 每个 endpoint-hour 再加流量处理费，一个 AZ 一个 endpoint，你要是三个 AZ 就是三份钱。这个数字我印象很深是因为算完我直接把方案毙了，但可能已经涨价了，别拿我这段当报价单用。
自建那条我们真跑过一阵。Suricata 7 的配置大概是这个形状：
sudo suricata -c /etc/suricata/suricata.yaml -i eth1 --af-packet
跑起来容易，难的是后面调优。ET Open 规则集拉下来四万多条，第一次开 IDS 模式（不开拦截）跑了两周，每天的告警量从 3800 条慢慢降到 400 条左右，靠的全是 suppress 和 threshold。我记得当时 ET SCAN Potential SSH Scan 这条一天能刷两千多次，源头全是我们自己内网的 Jenkins 在扫机器。后来我直接整条 suppress 掉了，sid 我记不清是 2001219 还是 2001972，你们自己在 fast.log 里按名字搜，反正是那一条。
三、真正吃掉时间的三件事
第一件是 TLS 解密。 这块的性能损耗不是线性的，你开解密之后 CPU 会涨 3~4 倍，而且 TLS 1.3 的 session ticket 复用一上来，设备内存也会跟着涨。我们当时在新加坡用的 c6i.4xlarge，解密一开，同一个实例的吞吐从 6.8 Gbps 掉到 2 Gbps 出头。后来是拆成两个实例，一个专门做解密回源，一个做检测。
第二件是 GeoIP 误封，这个是真出过事故。 当时为了挡东南亚某地的撞库流量，我在规则里把整个 ID 段 drop 了。第二天雅加达客服组长在群里 @ 我，说团队十几个人全登不上后台。GeoIP 库用的是 MaxMind GeoLite2，那个库对印尼这种岛屿国家的精度本来就一般，加上客服团队走的是本地 ISP 的动态 IP，很容易被划到奇怪的段里。教训是：GeoIP 只能用来做限速或者加验证，绝对不能用来做全量拦截，除非你能接受误杀。 后来改成挑战模式，问题才算解决。
第三件是告警疲劳。 我见过太多团队把 IPS 挂上去，前两周看告警，第三周开始没人看了。我们后来定了个死规矩：任何一条规则如果一周内告警超过 50 次且确认为误报，要么加阈值要么直接关，不养着。听着粗暴，但比起大家都在刷手机不看告警，我宁可规则少一点。
四、绕不开的合规：日志要留多久、存在哪
出海做安全设备，绕不开的就是日志留存和跨境传输这两件事。我踩过或者被法务问过的几个点：
- 印度 CERT-In：2022 年 4 月 28 日那版指令要求日志留存 180 天，安全事件 6 小时内上报。我们印度节点是单独一套存储，没和新加坡混。
- GDPR：第 44 条往后都是跨境传输的条款，你要把欧盟用户流量传出欧盟做检测（哪怕只是解密看一眼），就得有法律依据。所以法兰克福节点的探针我们是坚决本地化的。
- 沙特 NCA ECC、印尼 BSSN：这两个我当时是让本地合作方帮忙对的，自己看原文太吃力，条款更新也快。
还有个很现实的问题：RMA。 Fortinet 在新加坡有备件库，但你要是在印尼、越南的机房里挂了台盒子，走一趟 RMA 两到四周是常态。所以我们后来在所有关键节点都备了一台冷备机，配置用 Ansible 统一推，坏了一台半小时切过去。这个成本很多人做预算的时候会漏掉。
五、如果重来一次，我会按这个顺序做
- 先画数据流图，标清楚每一段流量在哪个法域落地，明确哪些数据绝对不能出境。这一步做完，探针位置基本就定了。
- 再定部署形态：旁路 TAP（只告警不拦截）还是串联 inline。第一次上，我强烈建议先跑两周纯 IDS，把误报摸清楚再说。
- 规则集从最小可用开始，别一上来就全量 ET Open 四万条。先上 20 条针对性规则，比如针对你们业务实际被打过的那些类型。
- GeoIP 只用做限速和验证，不做全量拦截。这条是我用一次线上事故换来的。
- 日志存储单独规划，按法域分开，留存期按各地最严的那个来。
- 备件方案写进预算，别等坏了才想起来。
最后说句实话：IPS 这东西，部署只占两成精力，剩下八成全是调优和运维。我见过太多人买完盒子往链路上一挂，截图发个朋友圈就完事，三个月后那台设备的规则库还是出厂版本。真要用起来，你得有人天天看告警、每周调规则，不然它就是个挺贵的装饰品。