1. 项目概述为什么你的Web服务器需要一个“看门狗”如果你负责维护一个对外提供服务的Web服务器无论是个人博客、电商网站还是企业内部系统最让你半夜惊醒的噩梦之一可能就是服务器突然“失联”了。用户访问不了业务中断而你登录服务器一看CPU和内存占用率爆表网络连接数高得离谱日志里充斥着大量来源不明的请求。这很可能就是遭遇了DoS拒绝服务攻击。DoS攻击的目的很简单就是用海量的垃圾请求耗尽服务器的资源带宽、连接数、CPU、内存让正常的用户请求无法得到响应。手动去分析日志、监控流量在攻击发生时往往是滞后的。我们需要一个7x24小时不间断的“看门狗”能实时分析进出服务器的网络流量一旦发现DoS攻击的苗头就立刻发出警报甚至自动采取行动。这就是Snort这类网络入侵检测系统NIDS的核心价值。Snort作为一款久经考验的开源IDS/IPS其强大之处在于它基于规则的检测引擎。你可以通过编写或调整规则告诉它“嘿如果发现来自同一个IP在1秒内向我的80端口发起了超过100个连接请求就立刻告诉我这很可疑”今天我们就来实战演练如何为你的Web服务器量身定制一条有效的Snort告警规则专门用于检测和预警最常见的DoS攻击模式。这不仅仅是写一行规则那么简单它涉及到对攻击原理的理解、对Snort规则语法的掌握、对网络环境的适配以及最重要的——如何避免误报让告警真正有意义。我会结合自己多年在运维和安全响应中的经验带你从零开始完成这条规则的构思、编写、测试和优化让你拥有一个真正能“听得懂人话”的自动化安全哨兵。2. 核心需求解析什么样的DoS攻击需要被预警在动手写规则之前我们必须先明确目标我们要检测什么样的DoS攻击DoS攻击种类繁多从简单的SYN Flood到复杂的应用层慢速攻击策略完全不同。一条试图“通吃”所有攻击的规则往往因为条件过于宽泛而产生海量误报最终被管理员忽略失去价值。因此我们的第一条原则是精准打击而非全面覆盖。对于典型的Web服务器我们需要重点关注以下几类高威胁、易实现的DoS攻击向量2.1 基于流量的洪水攻击Volumetric Attacks这是最传统、最粗暴的攻击方式。攻击者利用僵尸网络Botnet向目标服务器发送海量数据包旨在耗尽服务器的网络带宽。例如UDP Flood、ICMP Flood。对于Web服务器通常使用TCP 80/443端口更常见的是针对TCP协议的洪水攻击如SYN Flood。这种攻击在Snort中相对容易检测因为其特征是短时间内来自大量源IP的SYN包激增。2.2 基于连接耗尽的攻击Connection Exhaustion Attacks这类攻击更“聪明”一些它不追求巨大的带宽而是瞄准服务器维护连接的系统资源如套接字、内存。攻击者快速建立大量TCP连接并保持住半开连接或慢速连接占满服务器的连接池导致新用户无法连接。Slowloris攻击就是其中的典型代表它通过缓慢发送不完整的HTTP请求头来保持连接长时间打开。2.3 应用层洪水攻击Application Layer Flood这是当前最难防御的攻击之一因为它模拟的是正常用户行为。攻击者向服务器发送大量看似合法的HTTP请求例如频繁刷新首页、提交搜索、请求动态API接口。由于每个请求本身是合法的传统的基于异常协议的检测很难生效。检测的关键在于识别“行为的异常性”例如单个IP在极短时间内产生的请求频率远超人类极限。基于以上分析为我们的Web服务器配置第一条DoS告警规则一个理想的切入点是检测高频的HTTP/HTTPS请求洪水。这种攻击易于发动一个脚本即可效果直接打满服务器CPU或数据库且通过Snort的流量阈值检测功能可以相对准确地识别。我们的规则将聚焦于在极短时间内从单一源IP向我们的Web服务器端口发起超出合理阈值的TCP请求速率。实操心得不要一开始就追求复杂的、检测多种攻击的复合规则。从单一、明确的场景开始确保这条规则能稳定、准确地工作之后再考虑扩展。一条可靠的规则胜过十条不可靠的规则。3. 规则设计思路从攻击特征到Snort规则语法明确了要检测“高频HTTP请求洪水”后我们需要将其翻译成Snort能理解的语言。Snort规则的基本结构如下action protocol source_ip source_port - dest_ip dest_port (options)我们的设计思路拆解如下动作Action我们首先需要的是告警alert。在规则调试和验证阶段不建议直接使用drop或reject等动作以免误拦截正常流量。先确保能“看见”攻击。协议ProtocolWeb服务基于TCP。IP与端口源Sourceany。因为攻击可能来自任何IP。目的Destination$HOME_NET。这是一个Snort变量我们需要在配置文件中将其定义为我们的Web服务器IP或网段。例如192.168.1.100或192.168.1.0/24。源端口Source Portany。目的端口Dest Port$HTTP_PORTS。这是另一个Snort内置变量通常包含80, 8080, 8000等。我们需要确保它包含了我们Web服务器的实际监听端口例如还有443。规则选项Options这是规则的大脑定义了检测逻辑。流量阈值检测这是核心。我们需要使用flow、detection_filter或更新的threshold关键字来定义“在多长时间内达到多少次连接尝试”才触发告警。内容匹配可选为了更精确地限定为HTTP请求我们可以使用content关键字匹配HTTP方法如content:GET ;或content:POST ;。但这会增加处理开销且攻击者可能使用其他方法。初期可以不加以降低复杂度。告警信息使用msg关键字提供清晰的告警描述。分类与优先级使用classtype和priority对告警进行分类和分级便于在安全管理平台SIEM中处理。唯一标识使用sid规则ID和rev版本号唯一标识这条规则。一个初步的规则构想是“如果发现从任何一个IP地址在10秒内向我的Web服务器$HOME_NET的HTTP端口$HTTP_PORTS发起了超过150次TCP连接请求SYN包则生成一条告警。”这里的关键是“连接请求”的判定。在TCP层面一个新建连接的开始是一个SYN包。因此我们需要检测TCP标志位为SYN的数据包。4. 实操步骤编写、配置与测试你的第一条DoS告警规则下面我们进入实战环节。假设我们的Web服务器IP是192.168.1.100监听80和443端口。4.1 环境准备与Snort配置首先确保Snort已正确安装并运行在嗅探模式或NIDS模式。关键的配置文件是snort.conf通常位于/etc/snort/或/usr/local/etc/snort/。步骤一定义网络变量打开snort.conf找到定义变量的部分通常是开头部分。修改以下变量ipvar HOME_NET [192.168.1.100/32] # 如果你的服务器在一个网段可以写成 [192.168.1.0/24] ipvar EXTERNAL_NET any portvar HTTP_PORTS [80,443,8080,8000] # 根据你的实际情况调整端口列表将HOME_NET精确到你的服务器IP可以最大程度减少对无关流量的分析提升性能并减少误报。步骤二启用相关预处理器确保snort.conf中与流stream和阈值相关的预处理器已启用。检查以下配置可能默认已启用preprocessor stream5_global: track_tcp yes, track_udp yes, track_icmp no preprocessor stream5_tcp: policy first, use_static_footprint_sizesstream5预处理器用于跟踪TCP会话状态这对于准确识别新建连接SYN包至关重要。4.2 编写自定义规则我们不建议直接修改Snort自带的规则文件。最佳实践是在snort.conf指定的RULE_PATH目录下如/etc/snort/rules/创建一个自定义规则文件例如local_dos.rules。创建并编辑该文件sudo nano /etc/snort/rules/local_dos.rules将我们设计好的规则写入。这里我们使用detection_filter来实现阈值检测它是实现“时间窗口内超过次数”告警的常用方法。# 规则检测针对Web服务器的高频TCP SYN洪水攻击疑似DoS alert tcp $EXTERNAL_NET any - $HOME_NET $HTTP_PORTS ( \ msg:ET DOS Potential HTTP Flood Attack Inbound; \ flow:to_server,established; \ flags:S; \ detection_filter:track by_src, count 150, seconds 10; \ classtype:attempted-dos; \ priority:1; \ sid:1000001; \ rev:1; \ )规则逐行解析alert tcp $EXTERNAL_NET any - $HOME_NET $HTTP_PORTS 对从外部网络任何端口发往本机Web端口的TCP流量进行告警。flow:to_server,established;flow关键字指定流量方向和服务状态。to_server表示流向服务器established在这里的上下文与flags:S结合使用实际上Snort在处理新建连接时established参数可能不适用。对于SYN包检测更常见的写法是flow:to_server;。原规则中的established可能是个笔误对于SYN包应移除。修正后应为flow:to_server;。flags:S; 这是核心检测条件之一匹配TCP标志位为SYN同步的数据包即连接请求的第一个包。detection_filter:track by_src, count 150, seconds 10;这是阈值检测的灵魂。track by_src 以源IP地址攻击者IP为跟踪单位。count 150 阈值次数为150次。seconds 10 时间窗口为10秒。含义在10秒的时间窗口内如果从同一个源IP发往目标符合前面条件的数据包数量累计达到150次则触发一次告警。注意detection_filter会在达到阈值时触发告警并且在时间窗口内对于同一个追踪键值这里指源IP通常只生成一次告警避免告警风暴。classtype:attempted-dos; 将告警分类为“尝试的拒绝服务攻击”方便后续归类。priority:1; 设置告警优先级为1最高因为DoS攻击直接影响服务可用性。sid:1000001; rev:1; 自定义规则的SID安全标识符通常从1000000开始以避免与官方规则冲突。rev是版本号。修正后的规则应为alert tcp $EXTERNAL_NET any - $HOME_NET $HTTP_PORTS ( \ msg:ET DOS Potential HTTP Flood Attack Inbound; \ flow:to_server; \ flags:S; \ detection_filter:track by_src, count 150, seconds 10; \ classtype:attempted-dos; \ priority:1; \ sid:1000001; \ rev:1; \ )4.3 引入自定义规则并测试Snort配置步骤一在snort.conf中引用自定义规则文件在snort.conf文件中找到包含其他.rules文件的部分通常由include $RULE_PATH/*.rules这样的语句管理。确保添加一行来包含你的自定义规则文件。如果已有类似语句包含了整个目录则只需将local_dos.rules文件放入该目录即可。更推荐显式引用include $RULE_PATH/local_dos.rules步骤二测试Snort配置语法在启动Snort之前务必进行配置测试检查语法错误和变量引用是否正确。sudo snort -T -c /etc/snort/snort.conf -i 你的网卡名 # 例如sudo snort -T -c /etc/snort/snort.conf -i eth0参数-T表示测试模式。如果输出中包含 “Snort successfully validated the configuration!” 和 “Snort exiting” 字样说明配置正确。步骤三以NIDS模式运行Snort进行测试现在以后台进程方式启动Snort并将告警输出到控制台和系统日志便于观察sudo snort -A console -q -c /etc/snort/snort.conf -i eth0-A console 在控制台快速显示告警。-q 安静模式不显示常规数据包日志。-c 指定配置文件。-i 指定监听的网卡。4.4 模拟攻击与验证告警打开另一个终端我们需要模拟攻击来测试规则是否生效。可以使用简单的工具如hping3或nping。模拟SYN洪水攻击谨慎操作请在测试环境进行# 假设目标服务器是 192.168.1.100 我们模拟从本机攻击机发起攻击 sudo hping3 -S -p 80 --flood 192.168.1.100 # -S: 设置SYN标志位 # -p 80: 目标端口 # --flood: 洪水模式尽可能快地发送数据包运行几秒钟后观察运行Snort的终端。你应该能看到类似以下的告警信息快速刷屏[**] [1:1000001:1] ET DOS Potential HTTP Flood Attack Inbound [**] [Classification: Attempted Denial of Service] [Priority: 1] 08/15-10:23:45.123456 192.168.1.50:54321 - 192.168.1.100:80 TCP TTL:64 TOS:0x0 ID:54321 IpLen:20 DgmLen:40 ******S* Seq: 0xA1B2C3D4 Ack: 0x0 Win: 0x2000 TcpLen: 20这表示我们的规则成功触发了它检测到来自192.168.1.50攻击机IP在短时间内向服务器80端口发送了大量SYN包。停止测试 按CtrlC停止hping3。在Snort终端也按CtrlC停止Snort。重要注意事项此模拟攻击会产生大量网络流量务必在独立的测试环境如虚拟机隔离的网络中进行绝对不要在生产环境或他人的服务器上测试--flood参数会以最高速率发送数据包可能对网络设备造成压力。5. 规则优化与高级策略从“有效”到“精准”一条能触发告警的规则是“有效”的但一条“精准”的规则应该能最大程度地区分恶意攻击和正常业务高峰。我们刚才的规则还很基础可能存在误报例如遭遇搜索引擎爬虫的集中抓取或短时间内有大量真实用户访问某个热门链接。下面我们从几个维度进行优化。5.1 优化阈值寻找平衡点count 150, seconds 10这个阈值即15个请求/秒是拍脑袋决定的吗当然不是但它需要调整。如何确定一个合理的阈值基线测量在业务平稳期使用Snort或其他监控工具如iftop,ntopng统计正常访问情况下单个源IP到Web服务器的最高新建连接速率SYN包速率。观察一天或一周的数据找到峰值。设置安全边际在正常峰值的基础上乘以一个安全系数例如3倍到5倍。假设你观测到正常峰值是每秒5个新连接那么阈值可以设为每秒15-25个新连接即10秒内150-250个。我们的初始值150/10秒即15/秒在这个假设范围内。动态调整规则上线后密切观察告警日志。如果频繁误报则适当调高阈值或延长窗口时间。如果从未告警但在其他监控中发现异常时它却没反应则需调低阈值。优化示例假设经过基线测量我们将阈值调整为更宽松的count 300, seconds 1030个/秒。detection_filter:track by_src, count 300, seconds 10;5.2 排除可信IP白名单你的服务器可能允许一些特定的、行为类似“攻击”的合法服务访问例如CDN节点 Cloudflare、阿里云CDN等的回源IP。负载均衡器 上游的负载均衡健康检查。安全扫描器 公司内部或授权的第三方安全扫描IP。合作伙伴API调用 来自固定IP的、频率较高的API请求。Snort提供了ipvar变量来定义白名单。在snort.conf中定义ipvar WHITE_LIST [192.168.1.1, 10.0.0.0/8, 203.0.113.50]然后修改规则使用!$WHITE_LIST来排除这些IPalert tcp !$WHITE_LIST any - $HOME_NET $HTTP_PORTS ( \ msg:ET DOS Potential HTTP Flood Attack Inbound; \ flow:to_server; \ flags:S; \ detection_filter:track by_src, count 150, seconds 10; \ classtype:attempted-dos; \ priority:1; \ sid:1000001; \ rev:2; \ # 版本号更新为2 )注意源IP部分变成了!$WHITE_LIST表示“非白名单IP”。5.3 区分流量类型聚焦于新建连接我们之前的规则只检测了SYN包。但在一个完整的TCP连接中客户端发送SYN服务器回复SYN-ACK客户端再回复ACK。在流量洪水攻击中攻击者可能不会完成三次握手这就是SYN Flood也可能完成握手后立刻发送RST断开。为了更精确地检测“连接耗尽”型攻击我们可以尝试检测完整的“新建连接”事件。Snort的stream预处理器可以帮助我们跟踪会话状态。我们可以使用flowbits关键字来标记和检测会话的建立。但这种方法规则更复杂。一个更直接的优化是结合检测SYN包和短时间内的高频“SYN-ACK”响应从服务器角度但这需要更复杂的规则逻辑。对于初学者专注于SYN包的阈值检测是一个简单有效的起点。更高级的检测可以交给Snort社区规则集如Emerging Threats规则中现成的、更复杂的DoS规则。5.4 引入应用层检测可选进阶如果我们想更精准地检测HTTP层的洪水攻击而不仅仅是TCP层可以添加内容匹配。例如只对包含特定URI或频繁请求动态页面的行为进行阈值告警。alert tcp $EXTERNAL_NET any - $HOME_NET $HTTP_PORTS ( \ msg:ET DOS Potential HTTP GET Flood to Login Page; \ flow:to_server, established; \ content:GET /login; http_method; \ detection_filter:track by_src, count 50, seconds 10; \ classtype:attempted-dos; \ priority:1; \ sid:1000002; \ rev:1; \ )这条规则检测对/login页面的高频GET请求。http_method是一个content修饰符指定只在HTTP方法字段中匹配“GET”更准确。注意这里的阈值count 50要设得比通用SYN检测低得多因为针对单一页面的高频请求更可疑。实操心得应用层规则虽然精准但处理开销更大且容易被攻击者通过变换User-Agent、使用POST方法或请求不同URI来绕过。它更适合作为对特定关键端点如登录、搜索、API接口的补充防护而非主要防线。6. 告警集成与响应让规则产生实际价值规则触发了告警然后呢如果告警只是躺在Snort的日志文件里它的价值就大打折扣。我们需要将告警集成到现有的监控和响应流程中。6.1 配置告警输出Snort支持多种告警输出格式。对于生产环境推荐使用unified2格式它是一种二进制格式效率高可以被Barnyard2等工具读取并导入数据库。在snort.conf中配置output unified2: filename snort.alert, limit 128这会将告警输出到名为snort.alert的unified2格式文件中单个文件大小限制为128MB。6.2 使用Barnyard2或其它工具进行日志聚合Barnyard2是一个守护进程专门用来读取Snort生成的unified2日志并将其输出到其他系统如MySQL/PostgreSQL数据库、Syslog服务器等。这样你就可以用Grafana、ELK Stack等工具来可视化告警或者与SIEM安全信息和事件管理系统集成。安装并配置Barnyard2后告警就能实时进入数据库方便查询、统计和设置仪表盘。6.3 设置实时告警通知最直接的响应方式是邮件或即时通讯工具如Slack、钉钉、企业微信通知。基于数据库触发 如果你将告警存入了数据库可以编写一个简单的脚本Python/PHP等定期查询最近几分钟内的高优先级告警如classtype:attempted-dos并通过API发送通知。使用Swatch或Logwatch 这些是日志文件监控工具可以实时监控Snort的ASCII输出日志如果配置了alert_fast输出当匹配到特定关键词如“Potential HTTP Flood”时执行发送邮件的命令。集成SIEM/SOAR平台 在专业安全运营中告警会汇入SIEM平台如Splunk, QRadar, ELK。你可以在SIEM中为这类DoS告警创建更复杂的关联分析规则并联动SOAR安全编排、自动化与响应平台实现自动化的初步响应例如临时将该攻击IP加入防火墙黑名单。一个简单的Python脚本示例需配合数据库和邮件服务#!/usr/bin/env python3 import mysql.connector import smtplib from email.mime.text import MIMEText from datetime import datetime, timedelta # 数据库配置 db_config { host: localhost, user: snort, password: your_password, database: snort } # 查询最近5分钟内的DoS告警 query SELECT signature, timestamp, ip_src, ip_dst FROM event WHERE signature LIKE %Flood% OR signature LIKE %DOS% AND timestamp DATE_SUB(NOW(), INTERVAL 5 MINUTE) ORDER BY timestamp DESC LIMIT 10 try: conn mysql.connector.connect(**db_config) cursor conn.cursor() cursor.execute(query) alerts cursor.fetchall() cursor.close() conn.close() if alerts: # 构建邮件内容 msg_body 【Snort告警】检测到潜在的DoS攻击\n\n for sig, ts, src, dst in alerts: msg_body f时间: {ts}\n签名: {sig}\n源IP: {src} - 目标IP: {dst}\n{-*40}\n msg MIMEText(msg_body, plain, utf-8) msg[Subject] f[紧急] Snort DoS告警 - {datetime.now().strftime(%Y-%m-%d %H:%M:%S)} msg[From] snort_alertyourdomain.com msg[To] adminyourdomain.com # 发送邮件需配置SMTP服务器 with smtplib.SMTP(smtp.yourdomain.com, 587) as server: server.starttls() server.login(your_smtp_user, your_smtp_pass) server.send_message(msg) print(告警邮件已发送。) else: print(未发现近期DoS告警。) except Exception as e: print(f处理告警时出错: {e})6.4 制定应急响应流程告警来了之后人应该做什么这需要事先制定简单的流程确认告警 立即登录服务器使用netstat -an | grep :80 | wc -l、ss -s、top、iftop等命令确认服务器是否真的处于高负载、高连接数状态。定位攻击源 查看Snort告警详情获取攻击源IP。使用whois或威胁情报平台如微步在线、VirusTotal查询该IP是否已知恶意。初步缓解临时封禁 在服务器防火墙如iptables或网络边界防火墙如果可控上临时封禁攻击源IP或整个网段。sudo iptables -A INPUT -s 攻击者IP -j DROP启用云防护 如果服务器在云上如AWS, Azure, 阿里云立即启用云服务商提供的DDoS基础防护或高防IP服务。切换流量 如有CDN可通过CDN面板设置针对该IP的访问限制或人机验证。记录与复盘 记录攻击时间、持续时间、攻击特征、采取的措施。事后分析攻击模式思考是否需要调整Snort规则阈值、添加新的防护规则或升级基础设施。7. 常见问题与排查技巧实录在实际部署和运行这条DoS告警规则时你几乎一定会遇到下面这些问题。这里是我踩过坑后总结的排查思路。7.1 问题规则不告警可能原因及排查步骤Snort没有运行在正确的接口上 使用sudo snort -i命令查看所有可用网卡确保-i参数指定的是服务器接收外部流量的网卡通常是eth0或ens33。在虚拟化环境中注意网卡名称可能不同。流量没有经过Snort Snort需要能“看到”流量。如果Snort安装在Web服务器本机并以“嗅探模式”运行通常没问题。但如果Snort部署在独立的监控主机上你需要通过交换机端口镜像SPAN或网络分光器将Web服务器的流量复制一份发送给Snort。规则语法错误或未加载 再次运行snort -T -c /etc/snort/snort.conf测试配置。检查snort.conf中include local_dos.rules的路径是否正确。查看Snort启动日志确认自定义规则文件被成功加载。阈值设置过高 模拟攻击的强度可能未达到阈值。尝试降低阈值如count 30, seconds 5进行测试或者增加模拟攻击的速率。变量定义错误 确认$HOME_NET和$HTTP_PORTS在snort.conf中正确定义并且包含了你的服务器IP和端口。可以临时将$HOME_NET改为any进行测试看是否告警。7.2 问题告警太多误报可能原因及解决方案遭遇搜索引擎或爬虫 大型搜索引擎Google、Bing或恶意爬虫会以较高频率抓取网站。解决方案将已知的、可信的爬虫IP段可通过User-Agent或IP库识别加入白名单WHITE_LIST。或者针对爬虫行为编写更特定的规则例如检测User-Agent中包含“bot”、“spider”且频率高的请求而不是用通用的SYN洪水规则。正常业务高峰 网站促销、新内容发布可能导致真实用户访问激增。解决方案重新评估和调整阈值。参考历史流量基线将阈值设置在正常峰值的3-5倍以上。也可以考虑使用detection_filter的track by_dst模式检测针对目标IP的总连接数激增这更适合检测DDoS分布式拒绝服务而非单IP攻击。服务器自身服务或脚本产生循环请求 检查服务器上是否有配置错误的后台任务、健康检查脚本或微服务在疯狂调用自身。解决方案修正错误配置并将服务器自身回环地址127.0.0.1或内部管理网段加入白名单。7.3 问题Snort性能不佳丢包严重可能原因及优化建议硬件资源不足 Snort进行实时数据包分析是CPU密集型任务。在高流量环境下需要性能足够的CPU。建议监控Snort进程的CPU使用率。如果持续接近100%考虑升级硬件或者将Snort部署在专用硬件上。规则过多或过于复杂 每条规则都需要进行模式匹配规则集庞大或包含大量正则表达式PCRE会严重影响性能。建议只启用与你的环境相关的规则类别在snort.conf中注释掉不需要的include。优化自定义规则避免不必要的content匹配尤其是pcre正则表达式。使用Snort的perfmonitor预处理器监控性能找出瓶颈规则。未使用ACL访问控制列表预过滤 在snort.conf中可以使用config disable_decode_alerts、config disable_tcpopt_experimental_alerts等指令关闭一些你不关心的低优先级告警类型减少处理开销。更重要的是在规则层面通过精确的$HOME_NET和端口定义减少Snort需要检查的数据包范围。7.4 问题如何区分不同类型的DoS攻击我们这条规则主要检测“高频SYN”洪水。但DoS攻击花样繁多下表总结了几种常见攻击的Snort检测思路你可以据此编写更多规则攻击类型检测思路可能的Snort规则关键字/方法SYN Flood检测短时间内大量SYN包且没有后续的ACK半开连接。flags:S;detection_filter。更精确需结合flowbits跟踪不完整的握手。HTTP Flood检测高频的完整HTTP请求GET/POST。flow:established;content匹配HTTP方法 detection_filter。Slowloris检测长时间保持打开但不发送完整请求的HTTP连接。检测HTTP请求头不完整且连接保持时间过长。需使用stream5预处理器的client配置和flow的to_server, not_established状态结合pcre匹配不完整的头。社区规则集中通常有现成规则。UDP/ICMP Flood检测短时间内目标端口的大量UDP或ICMP包。协议改为udp或icmp使用detection_filter。注意目标端口可能是任意端口。DNS Amplification检测来自互联网的大量小查询包引发的大响应包涌向目标。检测源IP是伪造的非内网目的端口是53DNS且响应包远大于请求包。需要结合流量大小和协议分析规则较复杂。避坑技巧不要试图自己从头编写所有复杂攻击的检测规则。充分利用Snort社区规则集如Emerging Threats (ET) Open规则集。它们由安全专家维护覆盖了绝大多数已知攻击模式。你可以在snort.conf中下载并启用它们然后在此基础上针对你的特定环境编写自定义规则local rules进行补充和微调。你的第一条自定义规则就是迈出了从“使用者”到“定制者”的关键一步。