把 Snort 装到一台租来的服务器上，第一个小时通常很顺利：装依赖、拉规则、跑起来、屏幕上开始刷告警。真正的麻烦出现在第二天——告警多到没人看，或者流量一大就开始丢包，或者更糟，某天下午业务反馈"网络有点卡"，你才意识到这台机器已经串在业务链路上了。
我这些年给客户做安全监测，踩的坑几乎都集中在同一件事上：性能瓶颈不在你以为的地方。多数人的直觉是"CPU 不够就加核"，但 Snort 在一台千兆、万兆服务器上跑不动，八成问题出在网卡队列、中断分布和抓包路径上，跟 CPU 核数关系不大。而规则集的选择又决定了另一半——你到底是在做合规留痕，还是真的想拦住东西。这两件事的配置方式差别非常大。
这篇文章按"瓶颈在哪"这条线写：先讲部署形态（这是最大的不可逆决策），再讲抓包路径和网卡队列（这是最常见的性能黑盒），接着是规则集取舍、告警收敛、日志留存，最后给一张对比表和上机前的检查清单。写给需要过等保、或者想自建一套网络侧安全监测的中小团队。
这是所有决策里最不可逆的一个，也是我最常跟客户争的一个。旁路（IDS）拿的是流量的副本，来自交换机镜像口或者分光器；内联（IPS）是流量真的从这台机器穿过去，Snort 判定通过后包才继续走。
两者的失败后果完全不同。旁路模式下，Snort 进程挂了、规则炸了、处理不过来了，最坏的结果是漏检——你少看到一些东西，业务零感知。内联模式下，同样的故障意味着丢业务包。你不是少看到东西，你是把客户的请求扔了。这个差别决定了你需要什么样的运维投入：旁路可以随便重启、随便改配置、随便试新规则；内联的每一次改动都得排变更窗口、准备回滚、确认控制台可达。
我的判断一直很明确：如果你的目标是等保合规、或者"要有检测、要有记录、要有告警能查"，上旁路就够了，别上内联。合规测评看的是你有没有检测措施、日志留没留、能不能查，不看你拦没拦住。真正需要内联的场景是：你已经清楚地知道要拦哪几类流量、能接受误拦的代价、并且有物理或逻辑 bypass 手段。除此之外都是自找麻烦。
旁路也有自己的坑，别以为它就一定安全。交换机镜像口（SPAN）在端口拥塞时是会丢包的，而且优先丢镜像流量；如果你拿一个 1G 的镜像口去收 4G 上行的流量，那不是"可能会丢"，是必然丢。分光器（TAP）是物理分光，不丢包也不影响原链路，但要多花一份钱和一个口子。云主机上更麻烦——很多云平台根本不给你镜像能力，这时候 Snort 只能装在业务机本身上做主机侧检测，抓的是本机流量，价值打了折扣。
DAQ（Data Acquisition）是 Snort 和网卡之间那层数据面抽象库，很多人装完就直接跑，从没看过自己用的是哪个模块。这一步偷懒，后面所有性能调优都是盲调。
pcap 是最通用的，走 libpcap，兼容性最好，代价是每抓一个包都要经过一次系统调用和一次内存拷贝，小包高并发场景下开销明显。afpacket 是 Linux 上的 mmap 环形缓冲方案，绕掉了那层拷贝，而且它是目前 Snort 做内联桥接的主力模块——用成对接口 eth1:eth2 的方式把两个口桥起来，Snort 自己充当桥，不需要你预先配 bridge，也不需要动 iptables。netmap 是零拷贝路径，理论上最快，但它依赖网卡驱动支持，而且是编译期可选的模块，不是每个发行版的包都带。
这里有个必须养成的习惯：装完之后先跑一次 snort --daq-list，看清楚你手上到底有哪些模块。输出长这样——afpacket(v5): live inline multi unpriv。v5 是模块版本，live 表示能抓实时流量，inline 表示支持内联，multi 表示支持多实例，unpriv 表示不需要特权。如果你要上内联而列表里没有 inline 字样，那这个模块就干不了这活儿，别硬试。
afpacket 有个关键变量叫 buffer_size_mb，官方文档明确说它取决于硬件、被检测流量大小和启用的规则数，常见配置从 1024 起步。这里是个典型的取舍：缓冲区给大了，抗突发能力强，但内存占用上去了，而且包在缓冲里排队会抬高处理延迟——内联模式下这个延迟是直接叠加到业务往返上的；给小了，一个流量突发就把缓冲打满，直接丢包。我的做法是先在旁路模式下用真实流量的 pcap 回读压一遍，找到丢包的临界点，再往上留 30% 到 50% 的余量。
先算一笔容易被忽略的账：千兆链路打满小包大约是 1.48 Mpps，万兆是 14.8 Mpps。IDS 的瓶颈单位是 PPS（每秒包数），不是带宽。你可能会说"我们带宽才用了 300M"，但如果这 300M 全是 64 字节的小包，PPS 已经非常高了。
现代网卡靠多队列 + RSS（Receive Side Scaling）把不同流按哈希分到不同队列，每个队列对应一个中断，再由不同 CPU 核处理。这套机制正常工作的前提是：队列数足够、中断真的散开了、散到的核在同一个 NUMA 节点上。这三个前提里坏任何一个，你都会看到一种非常典型的现象——整机 CPU 空闲，但某一颗核的 si（软中断）长期 100%，同时接口统计里 dropped 一直在涨。
irqbalance 这个服务本意是自动均衡中断，但在 IDS 这种持续高收包的场景下，我不太信任它：它按负载动态调整中断亲和，迁移过程中可能把队列堆到同一个 NUMA 节点的少数核上，跨节点访问内存的代价会吃掉你以为省下来的性能。我一般的做法是要么关掉 irqbalance 手动把队列中断绑到网卡所在 NUMA 节点的核上，要么至少用 cat /proc/interrupts 确认它没搞出奇怪的分布。判断手段很朴素：cat /proc/interrupts 看队列中断落在哪些核，top 按 1 展开看各核 si 列，mpstat -P ALL 1 看软中断分布。
还有一个在租用环境里特别容易踩的坑：虚拟网卡的队列数受实例规格限制。你在云主机上跑 ethtool -l 想调 combined 队列数，很可能直接报错或者调不动，因为 virtio-net、ENA 这类虚拟驱动的队列数是平台给的。这时候唯一能做的是开 RPS，把软中断在软件层面再散一次——效果不如硬件多队列，但有总比没有强。所以选机器的时候，网卡类型和队列能力要提前问清楚，别等上架了才发现。
把"丢包"当成一个词是没法排查的，它至少发生在三个不同的位置，处置方式完全不同。我一般按从下往上的顺序查。
第一层是网卡 ring buffer。用 ethtool -g 看当前大小，ethtool -G 调。环满了新帧没地方放，直接硬件层丢弃，体现在 ethtool -S 的 rx_fifo、rx_missed、rx_over 这类计数上。把环从常见的 256 调到 4096 是常规操作，但这里有个必须知道的代价：环越大缓冲越深，抗突发变强的同时尾延迟会上升，公开实测样例里就出现过环调大后延迟明显翻倍的情况。旁路模式无所谓，内联模式就得掂量。
第二层是内核的每 CPU 收包队列。netdev_max_backlog 默认 1000，收包速率超过内核消费速率时队列涨到这个上限就开始丢。判断依据藏在 /proc/net/softnet_stat 里——每一行是一个 CPU 核，第二列就是因为 backlog 溢出丢掉的包数。这个文件值得背下来，它是区分"内核软件丢"和"硬件丢"的分水岭。高速链路上把这个值调到几千是常规操作。
第三层是软中断预算。netdev_budget（默认 300）限制一次软中断周期最多轮询多少个包，netdev_budget_usecs 限制时间。超了就发生 time_squeeze，softnet_stat 的第三列会涨。这种情况通常伴随单核软中断打满，回到上一节的队列问题。
最后一层才是 Snort 自己处理不过来——DAQ 的丢包计数和 Snort 自带的性能监控会告诉你。只有把前三层都排干净了，你才有资格说"这台机器 CPU 不够"。我见过太多人一上来就加 CPU，加完照样丢，因为包根本没到 Snort 手里就已经没了。
顺带说一个跟丢包无关但同样致命的坑：网卡 offload。TSO、GRO、LRO 这些卸载功能会让 Snort 看到远超 MTU 的"巨型包"或者校验和错误的包，导致检测逻辑完全跑偏。旁路抓包前老老实实 ethtool -K 关掉 gro、lro、tso、gso。这个坑我见过太多次了——现象是"Snort 跑得好好的但什么都没检测到"，查三天查不出来。
把前面分散讲的东西收成一张表，选形态的时候对着看：
| 部署形态 | 抓包与 DAQ 方式 | 处置能力 | 对业务的故障面 | 什么业务适合 |
|---|---|---|---|---|
| 旁路镜像（交换机 SPAN 口） | pcap 或 afpacket 单口只读，收副本 | 只告警，drop 动作不会被真正执行 | 零故障面；但镜像口拥塞时会丢，超配必丢 | 等保合规监测、需要留痕与事后审计的业务 |
| 旁路分光（TAP 串在链路外） | afpacket 单口只读，物理分光不占用上行 | 只告警 | 对原链路几乎无影响，丢包只发生在传感器侧 | 流量大、不能接受镜像口争抢带宽的核心链路 |
| 内联桥接（afpacket 成对接口） | afpacket inline，-Q 模式，成对接口 eth1:eth2 | 能拦，drop 规则真正生效 | 故障面最大：处理不过来就是丢业务包，进程挂了可能断链 | 有明确拦截目标、且有 bypass 与回滚手段的边界段 |
| 内联队列（NFQUEUE / nfq） | nfq 模块，靠 iptables 规则把选中的流送进队列等判定 | 能拦，且粒度可以按防火墙规则收窄 | 队列存在而进程不在时默认 fail-closed；加 queue-bypass 则变 fail-open | 主机侧、只需保护少数端口与协议的场景 |
| 离线回读（pcap 文件） | pcap readback，读抓好的包文件重放 | 只产出告警，用于验证与调优 | 完全不影响生产 | 规则上线前验证、性能压测、误报复现 |
判读方法说清楚一点，不然这张表容易被看歪。先看第三列"处置能力"——如果你们的诉求只是"检测到并留记录"，那第三列是"只告警"的前两行就够了，没必要为了"能拦"这两个字去承担第四列的故障面。反过来说，如果第三列必须选"能拦"，那你接下来所有的工作重点就不是规则调优，而是可用性和回滚：bypass 怎么走、进程挂了链路上是什么行为、控制台通道是不是独立于被检测的流量。一个没有独立管理口、没有旁路手段的内联部署，本质上是在业务链路上放了一个单点故障。
再看第二列和第四列的对应关系：抓包方式越接近零拷贝（afpacket 优于 pcap），抗 PPS 能力越强，第四列的故障面才越可控。也就是说，哪怕是旁路部署，抓包路径选错了也会导致"传感器自己丢包"，区别只是丢的是检测不是业务。最后看第五列做交叉验证——如果你的场景同时符合"合规留痕"和"不能断网"，那答案只能是前两行里的一个，别犹豫。
还在用 2.9 的团队不少，尤其是那些规则和配置已经沉淀了好几年的。升级与否要看你卡在哪，我把官方给的几条核心差异和它们的实际含义列一下。
配置模型是最大的变化。2.9 用 snort.conf，是 Snort 自定义的语法；Snort 3 用 Lua（LuaJIT），语法统一、可编程、变量随意。官方提供了 snort2lua 转换工具，跑完生成 snort.lua，转不动的选项会进 snort.rej 文件。这里必须提醒一句：转换成功只代表语法被接受了，不代表语义等价，更不代表检测还有效。我给客户做迁移的时候，转换完一定还要拿真实 pcap 回读比对一遍告警，否则你根本不知道少了什么。
命令行层面，2.9 里命令行参数和配置文件内容是部分重叠的，经常搞不清谁覆盖谁；Snort 3 明确成"命令行可以覆盖任何配置项"，而且自带完整的命令行帮助。对自动化运维来说这条很实用——同一份基础配置，靠命令行参数就能拉起不同策略的实例。
多线程是最实在的性能差异。2.9 每个进程只有一个包处理线程，要扩展就得多开进程，配置内存是"N 个进程 × M"；Snort 3 支持任意多个包处理线程，所有线程共享一份配置和属性表，省下来的内存全部留给包处理。规则集越大，这个差距越明显。官方还给了个参考口径：pcap 回读速度在 Max-Detect 策略下，用 AC 加速约 2 倍、用 Hyperscan 约 4 倍。
插件化是另一个分水岭。2.9 的扩展点只有 preprocessor 和 output 两类；Snort 3 是完整插件体系，官方口径 200 多个（升级手册里写 220 到 230 个），SO 规则本身也是插件，加 0day 规则比 2.9 时代基于 C 结构体的方式容易得多。检测能力上，Snort 3 原生支持 Hyperscan（正则快速模式）、HTTP 检查器全状态化（官方口径 HTTP Evader 测试用例从 65 处漏检降到 10 处）、服务自动识别让多数端口配置变成可选。数据面从 DAQ 2.X 的 run-to-completion 变成 3.X 的向量输入、允许多个未决包。代码规模也从约 47 万行 C 变成约 38.9 万行 C++。事件日志方面，2.9 推荐 unified2，3 推荐 JSON，直接对接 ELK 这类栈。
规则来源的选择，本质是在为"新鲜度"和"覆盖深度"付钱。先把官方口径摆清楚。
Cisco Talos 的规则分三档。社区规则集（Community）由社区开发、Talos 做质量检查，公开免注册。注册规则集（Registered）注册拿 oinkcode 后有，免费，但官方 FAQ 明确说明它比订阅档晚 30 天——这个延迟的实际影响比字面严重：这 30 天窗口内新产出的内容注册用户拿不到，而且面向 0day 的限量规则集一般不向注册用户分发。订阅规则集（Subscriber）是 Talos 开发测试并批准的那套，与 Cisco 客户同步实时发布，还能直接向 Talos 提交误报与漏报。价格方面，公开渠道常见口径是分个人档和商业档、商业档为每传感器每年数百美元级，具体数字各渠道口径不一，以 snort.org 官方报价为准。
Emerging Threats 是另一条线。Proofpoint 的官方对比材料给出的数字是：ETPro 规则数 71,500+，日均新增 30 到 50 条，背后有每天百万级样本引爆、全球传感器网络、MAPP 覆盖和完整 QA，带 SLA 支持；ETOpen 规则数 28,500+，日均新增 5 条，来源是社区贡献以及基于社区研究编写的规则，同样做完整 QA，但支持是 best effort。哪个新规则进哪个集，材料里说得很明确：Proofpoint 自有研究产出的进 ETPro、不自动迁移到 ETOpen；社区贡献的进 ETOpen。
关于"ET Open 是不是延迟 30 天"，这里要诚实说一句：公开资料口径不一。一些第三方材料宣称 ETOpen 有 30 天延迟，但 Emerging Threats 团队在公开论坛上回应过其 Open 规则集每日更新、不存在所谓 30 天延迟。真实的差别是产量和来源——日均 5 条和日均 30 到 50 条，这不是延迟问题，是产能问题。我建议不要在任何正式文档里引用"ET Open 延迟 30 天"这个说法。
我的实际取舍是这样：目标明确是合规监测、要留痕要覆盖常见攻击的，用 Talos 的 Balanced 策略打底，再叠加 ETOpen 里几个能在本地验证的类目就够了。Talos 官方对 Balanced 的定义是包含当年及前两年 CVSS 9 及以上的 CVE 规则，外加 MALWARE-CNC、BLACKLIST、SQL-INJECTION、EXPLOIT-KIT 四个类目全开——这几类最直接对应"已经被打进来了"。而 Maximum Detection 是安全优先策略，官方明说它预期会有误报和性能影响，那是测试环境用的，别往生产放。真要拦新东西，那就老实买订阅，社区规则集本来就设计得比任何单一部署该跑的都大。
网上流传的"多少条规则占多少内存"我一律不信，因为变量太多：规则内容、包长分布、流数、检测引擎版本全都影响结果。正确做法是量自己的曲线，方法也不复杂。
内存这边，Snort 2 的配置内存是"进程数 × 单份"，Snort 3 是共享一份、把省下的给包处理——这是官方给的架构性差异，可以直接用来判断为什么 Snort 3 在大规则集下更扛得住。具体量法：加载规则前记一次进程 RSS，加载后再记一次，差值就是这套规则集的配置内存；再逐步加减规则类目，你就能画出自己环境下的那条曲线。DAQ 的 buffer_size_mb 是另一块大内存，它乘以实例数直接算。
延时这边要区分部署形态。旁路模式下，处理慢一点最多是丢包和漏检，对业务没有任何影响；内联模式下，每多一条参与评估的规则，都在抬升每个包的判定耗时，最终体现为 P99 延迟和吞吐上限。所以内联部署对规则数的敏感度远高于旁路，这也是我反对"内联 + 全量规则"这种组合的原因。
找慢规则要用官方的性能剖析能力：Snort 3 有 perf monitor、时间和空间剖析、以及按规则统计匹配耗时的选项（具体选项名以你安装版本的命令行帮助为准，不同小版本有差异）。跑一轮真实流量，把耗时排名前二十的规则挑出来，逐条决定去留。这一步做完，通常能在规则数只减几个百分点的情况下把吞吐抬上去一截——因为耗时往往集中在极少数写得很重的规则上。
自写规则是刚需，因为通用规则集不知道你的业务长什么样。但自写规则也是最容易把性能拖垮的地方，几条写得烂的 PCRE 能吃掉整台机器。
第一条原则：content 打头，PCRE 收尾。content 是字面匹配，走多模式匹配引擎（AC 或 Hyperscan），一次扫描同时匹配成千上万条模式；PCRE 是正则，代价高一个数量级。正确写法是先用一个便宜的 content 做预筛，只有命中了才去执行后面的 PCRE。直接用裸 PCRE 扫全流量，是最常见的性能自杀方式。
第二条：用 sticky buffer 限定检测范围。Snort 3 里所有 buffer 都是 sticky 的，http_uri、http_header、file_data 这类写法会把检测限定在特定缓冲区内，比在裸 payload 上全扫便宜得多，顺带还能减少误报。官方说 Snort 3 的快速模式缓冲区从 2.9 时代的 6 个增加到 14 个，这个扩展带来的可优化空间要利用起来。
第三条：加前置条件。flow:to_server,established 这种限定能让规则只在会话已建立且方向正确时才参与评估；urilen 之类的长度门槛可以先滤掉一大批明显不匹配的包。这类条件的评估成本极低，收益却很大。
第四条是管理要求，跟性能无关但更容易出事：本地 sid 用自留段（一般从 1000000 起），msg 里带上业务标识方便检索，写 rev 便于迭代，全部纳入版本控制，并给每条规则写退役日期。最关键的一条——每条本地规则必须有对应的测试流量。snort -T 只检查语法，规则能加载不等于能命中，我见过大量"转换通过、加载正常、但从来没响过"的规则静静躺在配置里占着检测预算。
新装好的 Snort 跑一天出几千条告警是常态，不是异常。噪声主要来自几个固定的地方：policy 类规则（P2P、代理、下载行为）、扫描探测、内网健康检查和监控探针、NTP 与 DNS 的常规查询。这些都不是攻击，但在通用规则的视角里都"像"攻击。
收敛之前先做一件事：按业务分桶。把告警分成"确认良性""未知""可处置"三桶。最容易犯的错是把"未知"直接倒进"良性"——理由通常是"看不懂而且好像很规律"。看不懂不等于良性，规律的扫描器很可能是没人认领的主机在按计划扫你的内网段，那恰恰是你最该知道的事。判断时要问的是"这个源是谁负责的"，而不只是"这个模式规不规律"。
工具选择上顺序很重要。threshold 和 event_filter 是限流：规则仍然在评估，只是少告诉你几次，可用 limit（周期内最多记 N 次）、threshold（每 N 次记一次）、both 三种类型，还能用 track by_src / by_dst 按源或目的收窄。suppress 是停止评估：匹配的源或目的根本不再走这条规则，这是一个"有形状的盲区"，比限流危险得多。优先用前者，能按 CIDR 收窄就别全局关。
每条 suppress 都必须有主人和过期日期，这不是形式主义。理由很具体：抑制条件会活得比它成立的前提更久——扫描器下线了、应用重写了、网段改用途了，但那条为旧世界写的 suppress 还在配置里，覆盖着已经两年没人看过的流量。没有日期的 suppress 默认就是永久的。另外部署前必须问一句：如果这个攻击从被抑制的网段里来，还有别的规则会响吗？答案是"没有"的话，先补一个补偿检测再上线，别事后补。
发布方式上，别一次全量推。在 staging 传感器上用回放流量验证，或者先上一个生产网段观察几天。还有一个监控信号值得留意：某个原来每天响的 SID 突然完全不响了，这可能是调好了，也可能是调坏了，不亲自看一眼分不清。
误报不是一次性的活儿，是个闭环。我给团队定的流程是四步，缺一步这个闭环就会漏。
第一步是复现：把告警对应的原始流量抓下来看，确认它到底长什么样。没有包只有一条文本告警，后面所有的判断都是猜。第二步是关联：拿这条流量去对防火墙日志、代理日志、服务器访问日志，确认它的真实身份——这是唯一能抓住"看起来像良性其实是没人管的主机"这个坏结果的环节。第三步是定级：确认良性、未知、真实命中，三选一，不许模糊。第四步才是处置：限流、抑制、改规则内容、或者禁用，并留下处置记录。
处置方式也有优先级：优先调 threshold 和 suppress 的收窄范围，其次改规则内容，最后才是整条禁用。禁用是最粗暴的，它把这条检测能力彻底丢掉，通常意味着你没搞懂这条规则而不是这条规则错了。
记录这件事要花点心思。每条处置记下：SID、触发源、判断依据、处置方式、处置人、生效日期、复审日期。这些字段看着繁琐，但价值在于让队列变得可检索——否则一个月后有人问"这个 SID 以前从外部源触发过吗，当时怎么定的"，答案永远是"不知道，从头查吧"。结构化字段能把几百条已关闭的记录变成证据，自由文本笔记做不到。
还有个组织层面的细节比技术更关键：写抑制的人不能是唯一批准它的人。自我批准的 suppress 是检测覆盖悄悄消失的主要途径。哪怕团队只有五个人，也得保证写和批是两个人——其余的流程都可以合并，这一条不能省。
输出格式的选择直接决定后面日志侧的工作量，而且这个决定改起来很烦，一开始要想清楚。
alert_fast 是每行一条告警的精简格式，体积小、人读还行、机器解析略麻烦但可接受。alert_full 会带上包头信息和 payload，排查时很方便，但体积是 fast 的数量级倍数。unified2 是 Snort 2.9 时代推荐的二进制格式，配套用 Barnyard2 这类工具解析后写入数据库，这套组合在老部署里很常见。Snort 3 的官方口径变了——事件日志推荐 JSON，理由是能直接对接 Elastic Stack 一类的日志平台。
我的部署习惯是：传感器本地只做轻量的事。写 fast 或 JSON 到本地盘，配好按天轮转，入库和检索交给日志侧（Filebeat、rsyslog 之类）去做。绝对不要在传感器上跑重型数据库——那台机器的 CPU 和磁盘 IO 应该全部留给抓包和检测，数据库在上面跑就是跟检测抢资源，而且数据库一抖动还可能反噬检测进程。
日志量这笔账要提前算，公式很简单：日均告警条数 × 单条平均字节 × 留存天数 × 副本数。fast 一行大致几百字节，full 带 payload 可能到 KB 级，两者差一个数量级，选错了磁盘压力差十倍。另外两个硬要求：日志盘不要和业务盘抢 IO，最好独立；以及别让它写满——写满之后 Snort 的行为取决于版本和配置，不要赌，配好告警和自动清理。
合规场景一定会问留存期。常见口径是半年起，但具体以你所在地区的测评要求和备案等级为准，别照抄别人的数字——这一项各地执行尺度确实不一样，正式方案里写"按测评要求确认"比写死一个数字稳妥。
磁盘账顺着上一节的公式往下算就行，但真正的痛点不是总量，是检索效率。合规检查的场景通常是"某时间段的某类事件能不能查出来"，这就要求入库时字段是齐的：时间戳、源目的 IP、端口、SID、分类、优先级、协议。如果只往库里塞一行原始文本，等到要按 SID 统计或者按目的 IP 回溯的时候，就只能全表扫，几百 GB 的文本扫一次你就知道错了。
折中方案我一般是这么给的：热数据（近 30 天）进可检索的库，保证秒级查询；冷数据压缩归档到廉价存储，需要时再恢复检索。payload 全量留存成本太高，通常只留包头元数据和告警上下文，真要取证时靠会话日志或者临时抓包补。这个取舍要在方案里写明并让合规方认可，不然测评的时候容易被挑。
还有一点容易被忽略：时间同步。传感器、日志服务器、业务主机必须统一时钟源，否则跨设备关联事件时对不上时间戳，合规性材料里的因果链就断了。这条技术上不复杂，但漏了会很尴尬。
落到租机器这一层，我把各项的判断依据写清楚，你可以直接照着填配置。
CPU：核数比主频重要。Snort 3 的多包线程需要核，网卡队列绑核也需要核，两者叠加意味着核数最好不少于网卡队列数。主频影响单包处理速度，但在队列没散开的前提下，再高的主频也只能让那颗打满的核快一点点。实际选型上，中等主频的更多核，优于高主频的少核。
内存：三块加起来——规则集配置内存（按上一节的量法测）、流表（并发会话数决定，流量越大越吃）、DAQ 缓冲（buffer_size_mb × 实例数）。其中流表和 DAQ 缓冲在流量上来之后往往比规则集本身更占内存，别只按规则数估。
磁盘：告警日志是顺序写，吞吐量要求不高，但要的是稳定 IO 和足够容量。别用单块盘硬撑留存期，也别和业务数据共用一块盘抢 IO。
网卡：这一项最容易被省掉，也最不该省。我的要求是独立管理口 + 独立镜像口。镜像口专门收包，不配 IP、不跑业务、不参与转发；管理口单独走 SSH 和告警上报。这么做的意义在出故障的时候才体现得出来——当传感器被打满的时候，你还能登上去看，还能把告警发出去。把管理通道和被检测流量放在同一个口上，等于把唯一的救援通道也堵死。
地区选择上有一点合规边界要提前想清楚：监测境内业务的传感器放境内机房最省心；如果监测对象涉及境外节点，链路镜像流量的跨境传输、以及中国香港、中国澳门、中国台湾等地名的规范表述，都属于需要单独确认的合规事项，不要想当然。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。用于流量监测的机型在官网并未单列专门配置，通常按通用服务器租用选型叠加网卡与内存要求，具体配置与报价需询价、以官方实时报价为准。
劝退比推荐更值钱，我把明确不建议的场景列出来，省得花了钱又没效果。
第一类是加密流量占比高又不做解密的链路。现在大部分业务的 HTTPS 占比都在九成以上，Snort 在没有解密能力的情况下只能看到握手阶段的元数据——SNI、证书信息、JA3 之类的指纹特征，payload 类规则基本全部失效。这时候你花大价钱买了全量规则，真正能跑的只有握手相关的少数几条，投入产出比非常差。如果一定要做，先解决解密或者改在网关/应用层做检测。
第二类是没有镜像能力的环境。云主机拿不到镜像口、交换机不支持 SPAN、又不想买分光器，那 Snort 只能装到业务机本机抓自己的流量。这能挡一部分东西，但视野只有一台主机，跟"网络侧监测"完全不是一回事，别拿它当合规材料里的"网络入侵检测措施"交上去。
第三类是想拦但扛不起故障面的。业务不能接受任何中断、又没有 bypass 网卡、也没有回滚演练的习惯，那就别内联。内联部署的可用性要求远高于检测能力要求，扛不住就老实待在旁路。
第四类是最容易被忽视的：没人看告警。装了不看，等于没装，而且比没装更糟——因为你会以为自己有防护。如果团队里没有能每周花几小时过告警的人，先把人和流程解决，再谈工具。
这五条是我每次上机前必查的，每条都按"问题—为什么—怎么判断—怎么避"说清楚。
其一，镜像口超配。问题：拿小带宽口收大带宽流量。为什么：SPAN 在拥塞时优先丢镜像流量，超配必然丢。怎么判断：对比镜像源端口的实际吞吐与镜像口带宽，再看接口统计的丢包计数是否随业务高峰同步上涨。怎么避：镜像口带宽不小于被镜像流量的峰值，或者改用物理分光。
其二，网卡 offload 没关。问题：TSO/GRO/LRO 让 Snort 看到巨型包或校验和错误的包。为什么：卸载发生在网卡，Snort 拿到的是重组后的结果，检测逻辑失准。怎么判断：抓包看到远大于 MTU 的帧，或者规则明明该命中却不响。怎么避：上机前统一执行关闭 offload 的操作，写进部署脚本。
其三，内联没有 bypass 和回滚。问题：进程异常或处理不过来时业务中断。为什么：内联是串联单点。怎么判断：问自己"Snort 挂掉的那一刻链路上会发生什么"，答不上来就是没准备好。怎么避：独立管理口、可用的 bypass 路径、书面回滚步骤，并且在低峰期实测一次停进程。
其四，规则全量开启加无主 suppress。问题：告警洪水，然后被粗暴地压制掉。为什么：社区规则集本来设计得比任何单一部署该跑的都大。怎么判断：看 suppress 条目有没有主人和过期日期，没有就是失控了。怎么避：从 Balanced 起步，按类目逐步开，每条抑制必须带主人和复审日期。
其五，日志盘写满或留存期没算。问题：磁盘满导致检测异常或历史数据丢失。为什么：告警量按天累积，没人算过总量。怎么判断：用日均条数 × 单条字节 × 留存天数算一遍，跟实际磁盘容量比。怎么避：独立日志盘、按天轮转、容量告警、冷数据压缩归档。
1. 一台普通的租用服务器能跑多大流量的 Snort？
这个问题没有通用答案，因为决定因素是 PPS 而不是带宽，还叠加规则集大小、包长分布和抓包方式。我给的估法是这样：先拿你的真实流量 pcap 在候选机型上做回读压测，看 DAQ 什么时候开始丢包，那个点乘 0.6 到 0.7 就是比较稳妥的长期运行水位。同样的带宽下，全是小包和全是大包能差好几倍，所以别按带宽估。如果压测不方便，至少按"千兆满速小包约一百多万 PPS"这个量级去对照机器的处理能力，并留足余量。另外这类估算跟机房位置关系不大，大陆节点与中国香港节点的差异主要体现在链路与合规边界上，而不是计算能力；机型、内存与带宽的具体组合在一万网络官网按通用服务器租用选型，监测型配置未单列报价，需询价、以官方实时报价为准。
2. Snort 2.9 还有必要升到 3 吗？
取决于你卡在哪。如果卡在内存——规则集一大、多进程一开内存就吃紧，那 Snort 3 的共享配置能直接解决问题，这是架构级收益。如果卡在抓包性能，DAQ 3.X 的向量输入和 Hyperscan 原生支持也值得升。但如果你的 2.9 跑得好好的、流量不大、规则集不大，那升级的收益有限，反而要承担 snort2lua 转换后语义漂移的风险。我的建议是先做一次并行验证：同一份 pcap 分别跑两套，比对告警差异，再决定。
3. 免费规则够用吗，一定要买订阅吗？
看你的目标。做合规留痕、覆盖常见攻击类型，免费的 Talos 社区加注册档、叠加 ETOpen 里几个你能本地验证的类目，基本够用。需要拦新出现的东西就不够——注册档比订阅档晚 30 天，而 0day 类规则一般不向注册用户分发，这个窗口对防御来说非常关键。价格上公开渠道常见口径是商业档每传感器每年数百美元级，具体以 snort.org 官方报价为准，各渠道口径不完全一致。
4. 旁路部署怎么确认它真的在检测？
不能只看进程在跑。我的验证方法是三层：第一层，确认抓包口真的有流量进来，看接口计数；第二层，用一条你知道一定会命中的本地规则（比如针对某个测试请求的自定义规则）产生告警，证明检测链路通；第三层，用 pcap 回读一批已知攻击样本，看告警条数是否符合预期。三层都过了才算在检测。只跑 snort -T 是不够的，它只检查配置语法。
5. 内联部署万一 Snort 挂了会不会断网？
取决于你用的方式和配置。NFQUEUE 模式下，如果 iptables 把流量送进队列而 Snort 进程不在，默认行为是包被丢弃，也就是 fail-closed，会断；除非显式加了 queue-bypass，那就变成 fail-open，包直接放行。afpacket 内联桥接模式下，进程停了桥就断了，同样影响转发。所以这不是"会不会"的问题，是"你要哪种失败行为"的问题——上线前必须明确选定并实测一次，同时保证管理通道独立于被检测流量。
6. 告警太多了，能不能直接关掉最吵的几条规则？
能，但顺序不对。直接禁用是最粗暴的手段，等于放弃了这条检测能力。正确顺序是：先判断到底是不是误报（抓包复现加关联其他日志），然后优先用 threshold 或 event_filter 限流，能按源或目的 CIDR 收窄就收窄，实在不行再考虑改规则内容，最后才是整条禁用。而且每一条 suppress 都要有主人和过期日期，否则它会变成永久盲区。关掉之前还要问一句：这类攻击从别的地方来，还有别的规则会响吗？
7. 加密流量占绝大多数，还有必要上 Snort 吗？
要谨慎评估。没有解密能力时，Snort 只能看到 TLS 握手的元数据，比如 SNI、证书特征、客户端指纹这类信息，payload 检测规则基本全部失效。这时候买全量规则的实际利用率很低。可行的替代是把检测点前移到能做解密的网关，或者放到主机侧和应用层。如果坚持在网络侧做，就把预期调低——握手指纹类检测能发现一部分异常 C2 通信，但不是完整的入侵检测。
8. 日志要留多久，怎么算要多大盘？
留存期以你所在地区的测评要求和备案等级为准，各地执行尺度不同，正式方案里建议写"按测评要求确认"而不是写死数字。磁盘用这个公式估：日均告警条数 × 单条平均字节 × 留存天数 × 副本数。选输出格式时记得 fast 一行几百字节，full 带 payload 可能到 KB 级，差一个数量级。我一般建议热数据近 30 天进可检索的库，更早的压缩归档，payload 不全留，别让日志盘和业务盘抢 IO。
1. Snort 官网「Why Snort 3?」（snort.org/snort3）：Snort 2 与 Snort 3 的完整特性对照表，包括包线程数、配置内存模型、DAQ 2.X 与 3.X 差异、插件数量、Hyperscan 加速下的 pcap 回读倍率、代码规模等。
2. Snort 官方《Snort 3 Upgrade Manual》（snort.org/downloads/snortplus/snort_upgrade.html）：多线程架构、共享配置与属性表、LuaJIT 配置、Hyperscan 支持、HTTP Evader 漏检用例数、可伸缩内存模型、snort2lua 转换说明。
3. Snort 官网 FAQ「What does having a Snort Subscriber Rule Set subscription entitle me to?」：订阅规则集相对注册用户提前 30 天的官方口径，以及误报漏报提交通道。
4. Snort 官网（snort.org）规则集说明页：Community Ruleset 与 Subscriber Ruleset 的定义、oinkcode 机制、Registered Rule Set 的获取方式。
5. Snort 官方文档《Snort IPS using DAQ AFPacket》：afpacket 内联部署的四项配置变更、-Q 参数、成对接口写法、buffer_size_mb 变量、snort --daq-list 输出格式示例。
6. Snort 官方博客《The major differences that set Snort 3 apart from Snort 2》（2020-08）：多包处理线程、共享配置与属性表、200+ 插件、Hyperscan、TCP 重写、新性能监控等特性综述。
7. Proofpoint 官方数据表《ETPro Ruleset Versus ETOpen Ruleset Comparison》：ETPro 与 ETOpen 的规则总数（71,500+ 对 28,500+）、日均新增签名数（30–50 对 5）、样本引爆与全球传感器网络、MAPP 覆盖、QA 与支持等级差异。
8. Emerging Threats 官网（emergingthreats.net）ET Intelligence 页面：威胁情报订阅的形态、分类与更新方式说明。
9. Cisco 官方文档关于系统预置入侵策略的说明：Balanced Security and Connectivity、Connectivity Over Security、Security Over Connectivity、Maximum Detection 四类预置策略的定位与适用场景。
10. Cyber Defence Kit《Test Inline Prevention》（docs.cyberdefencekit.org）：被动 IDS 与内联 IPS 的流量路径差异、AFPacket 内联与 NFQUEUE 内联的前置条件、裁决链路三阶段验证、queue-bypass 导致 fail-open 的说明、回滚与证据留存清单。
11. Linux 内核网络丢包排查公开技术资料（含 /proc/net/softnet_stat 字段释义、netdev_max_backlog 默认值与调优、netdev_budget、ethtool -g/-G ring buffer 调整及其对延迟的影响）：用于网卡队列、中断均衡与内核丢包计数部分的口径。
12. Snort 规则调优公开技术资料（threshold.conf 中 event_filter 的 limit/threshold/both 三种类型、suppress 按源或目的 CIDR 抑制、PulledPork 的 disablesid 机制）：用于告警收敛与误报处置流程部分。
13. 关于 ETOpen 是否存在 30 天更新延迟：公开资料口径不一，部分第三方材料称有延迟，Emerging Threats 团队在公开论坛回应其 Open 规则集每日更新、不存在 30 天延迟；本文按"口径不一"处理，未采用延迟说法。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
