Snort规则详述

flow控制 可以减少误报率
有三个参数
定义方向 flow

（to _client,to_server,established）

flowbits 提供小型状态机， pcre也能做这样的事，不过这个更简单

(set,unset,isset,noalert)

其实是设置一些bit数组，哪个发生了，就set(1)
通过flowbit 可以做设置选项
isset 是否被设置
noalert==不发生警报

对负载进行匹配 ，包含规则选项，

规则后处理

官方文档
https://snort.org/faq/readme-filters
必要性：有可能会出发很多警报，这些警报有时是冗余，有时可能由一个漏洞产生数万个警报，正常的

rate filtering 根据事件速度，对规则采取新的动作
·new action of event
当事件报告速度超过一定值,采取新动作

Event Filtering
·reduce the number of event

Event Suppressing
·ignore it for specified target
针对特定地址（比如内网地址），发生这种事件我就不报了（比如认为内网可控制）

Example：

·头部五元组的定义
这个是做IRC服务的
flow：to_server，若发往其他方向就不管了
established，如果其他报文也有负载，但没有建立连接，也不管了
content：
“PRIVMSG”，把特定关键字匹配
并不是整个负载都要匹配，而是depth8，这里没有offset，说明从头开始
nocase 大小写无关
.DCC后的都是IRC协议内的东西

若6666：7000段内包含这些匹配项的话，就给它增加个上下文“flowbits内的内容” 且noalert

Example2:

黄色内容：
flowbits 减少误报
红色：
pcre的模式 把这个bot匹配出来
flowbits：
if（isset）发警报
content内是匹配内容 “http|3a|//”(3a代表冒号：)
\s 空格
*可以理解为闭包（0个多个）
+ 一个或多个
\x 表示/
这个正则表达式，不就是，编译原理讲过的

规则检测的报文如何联动？？留作作业

预处理器 The prprocessors of Snort

13：30录音
detect: sfportscan, reputation

reassemble: frag3, session, stream

decode & detect: http/smtp/pop3/dns/…·
解码的过程中也会检测
management: performance monitor
管理 性能管理，检测，监控
rewrite the packet: normalizer
这个比较特殊，并不用在IDS里，而是ADS里 因为rewrite，要重写了，上面四个并不改变报文，最多创建一个对象，

detect

sfportscan

based on statistics of packet
TCP/UDP/IP

one-one

many-one
从目的端口做宿端口统计，
如果有一个服务器，别人来访问我的80端口（web）就好了，但扫描的时候不知道我打开了哪些端口，就会扫描我所有端口，用1000个地址，此时发现问题

one-many
若445端口有漏洞，我就看哪些扫描了1000个机器的445端口，此时发现问题

reputation 黑名单

IP Blacklist/Whitelist
snort最核心的是负载部分的处理，ip地址里的东西很少，所以关键在端口 。检测时对非负载部分先头部，再负载，做成树状图，在每个叶节点都有负载的子集，检测content或pcre。
implemented in route table format
以路由表中的结构做ip地址的匹配
performance better than rule

the first pp where packet arrived

reassemble the flow

6：00
把不同ttl的分片
frag3 vs. Session vs. Stream
frags : IP fragment·
session & stream
Transport protocol fragment
stream5
memory cost
预处理器占用内存很多，重组这种事，把无状态-》有状态，占用大量内存

区别session vs stream：
Session
flow flowbits就是用session这个预处理器维护和支持的。
它为每个流创建上下文
provide context for rule detection(flow, flowbits)
·support TCP(default), UDP ICMPIP
·tcp session count: 256k(default), 1M(max)

14：05
·stream
·Target-Based
·Anomaly Detection
·Protocol Aware Flushing
·support application protocol decode
3和4相关，可以在了解协议时 tcp本身没有边界

Decode & Detect
Application Protocol
HTTP SMTP etc.
rule content options
improve detection accuracy