Snort规则分析举例

Posted 2021-01-05

*Snort规则分析举例

Snort一种开源*检测系统，当他作为NIDS模式运行时，可以分析网络传输的数据包，当它发现可以流量时就会根据事先定义好的规则发出报警，有关这些规则的介绍网上可以轻松找到，可对于具体规则分析却不多。下面分析了几个典型可疑流量报警规则。

.1.可疑流量的报警

假设一个场景：在内网中，你用Snort监控的VLAN中的若干网络交换机，并通过Telnet来管理它们。在这种情况下下面这条Snort规则所发出的警报就算是正常。我们要打开Ossim系统中/etc/suricata/rules/emerging-telnet.rules配置文件，查看第53行，如下

如果你把同样这条规则用在了监控一个受禁止使用Telnet进行访问的防火墙，那么它发出的报警就非常重要，应该引起管理员的注意。就是说你一定要注意产生报警的具体环境，而不能一概而论。
下面在看个例子，Web有些资源是不让访问的，当有人试图尝试访问一个Web服务器所禁止访问的资源时，就会由下面这条规则所触发报警。
打开emerging-misc.rules配置文件，查看第85行，如下

.2.空会话×××漏洞报警

早在Windows 2000系统时就发现了空会话×××漏洞（当然现在Windows 7/8系统已经消除此问题）在当时×××者可以很轻松地利用空会话完成×××，通过在主机上面建立一个空会话，再通过Enum枚举共享等方式，者可能会获得一个重命名管理员的帐户，这是因为这个空会话回加载到所有该计算机帐户组中。它使得不在域中的主机也能使用主机所使用的网络。

上图使用 Net命令发起的成功空会话连接
当你使用Snort监控这些主机时，这种方式就会立刻暴露出来。在Ossim系统中先打开emerging-netbios.rules，查看249行，Netbios Null会话的规则如下：

当一个×××者企图通过匿名方式连接枚举用户或其它系统信息时，该规则将会被触发。

.3.用户权限获取企图

有权使用一个普通用户账号的×××者，它可以利用系统的各种漏洞来提升自己的权限，直到最高权限。这样就能访问未授权的数据。比如可以通过修改.rhosts文件来获取全
局访问权限，下面是Snort规则检测这样的用户权限获取企图行为：　打开emerging-misc.rules，查看 139行

在一个具体应用中提权的目标很可能是数据库，用户可以访问一种类型的数据，但可能希望访问其它受限制的资源，另外，如果用户获得超级用户权限，它就可以控制主机。下面我们看看Snort中一个监控这种用户提权的例子是Microsoft SQL Server的xp_cmd shell规则：
打开emerging-exploit.rules，查看931

Xp_cmdshell可以被用于执行SQL Server的系统命令。×××者可使用xp_cmdshell安装×××或执行可以在Windows命令行下执行的任何程序。这个规则就能检测这种×××行为。

.4.失败的权限提升报警规则

×××者提升用户权限也不是一帆风顺，常常遇到问题，如果能在提权中，如果失败就报警，失败的登录行为就会触发系统大量报警，这样×××者的行为就会被发现。下面举的一个PCAnywhere失败登录规则就是一个是被的用户权限获取的例子，我们打开emerging-policy.rules文件，查看1706行

该规则检测登录PCAnywhere失败的尝试。

5.管理员权限获取企图

如果×××者可以访问Windows系统里的Admin$共享资源，它就可以访问Windows系统目录（c:winnt）但这么做的人有时候并不是真正的管理员，怎么发现呢？下面这条规则就可能检测这种行为，打开emerging-netbios.rules文件，查看第303行。

6.成功获取管理员权限

Unix系统的passwd文件传出是绝对不能发生在TFTP这样不安全协议上的，TFTP协议既不需要认证，也不加密，非常危险。所以在一些Unix系统中可以通过下面方式获取passwd
$tftp 1.1.1.1
tftp>connect 1.1.1.1
tftp>get /etc/passwd /tmp/passwd.cracker
tftp>quit
如果通过Snort就能检测到，通过TFTP传输 passwd文件的行为，例如：
打开 emerging-tftp.rules查看89行规则如下：

这条规则的报警就可以表示×××者获得了对根正虎和其它用户的控制权。
像这样的例子还有用于检测BSD Telnet守护进程×××的规则。打开Ossim 2.3系统的Snort规则库中telnet.rules文件，查看第38行

7).拒绝服务

举例：发现Chargen/echo DOS×××，chargen服务端口为UDP 19，echo 为UDP 7，如果UDPchargen server 收到了一个封包就会回一个封包回去，而且如果发现与客户端连接存在就会不断发送。如果是被利用为ddos×××，这样就会被放大占用整个网络带宽。这里×××者伪造了数据包，将两台开放Chargen/echo的服务器互指，结果造成资源耗尽而导致网络不可用。

图 拒绝服务×××的例子
打开dos.rules的第1行

该特征检测的DOS条件是一个Chargen/echo服务的无限循环。
还有一些DOS×××会出现一些异常的数据输入，这些输入的内容会是服务器瘫痪，当然，这是个比较老的漏洞，Microsoft FTP STAT globbing DOS就是一个典型，当×××者在Windows 2000 IIS 5.0的FTP服务器上发送STAT命令之后再追加一些异常的文件名匹配字符（$g.*?等）时，顿时没有打补丁的FTP服务器将会立即崩溃。我们看看Snort应对此种×××的规则代码，打开ftp.rules规则，查看66行：

除此之外，其它DOS的规则用来检测DDOS，DDOS×××利用大量的受害主机向目标主机发送大量请求，造成其瘫痪。这种行为也可以用Snort规则来检测，以下是在收到DDOS×××时，在ACID系统里发出的事件日志。
#(2 - 10994) [2012-08-21 09:58:06] [arachNIDS/253] DDOS shaft synflood
IPv4: 195.27.218.62 -> 123.xxx.yyy.252
hlen=5 TOS=0 dlen=40 ID=28789 flags=0 offset=0 TTL=19 chksum=17659
TCP: port=13000 -> dport: 13000 flags=**S* seq=674711609
ack=39679596 off=5 res=0 win=25622 urp=39897 chksum=44744
Payload: none

#(2 - 10993) [2012-08-21 09:58:06] [arachNIDS/253] DDOS shaft synflood
IPv4: 195.27.218.62 -> 123.xxx.yyy.250
hlen=5 TOS=0 dlen=40 ID=28789 flags=0 offset=0 TTL=19 chksum=17661
TCP: port=13000 -> dport: 13000 flags=**S* seq=674711609
ack=1883199726 off=5 res=0 win=20738 urp=46580 chksum=22367
Payload: none
以下是Snort得到的数据包分析
Snort:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
21-09:37:16.080331 195.27.218.62:13000 -> 12.82.128.178:13000
TCP TTL:16 TOS:0x0 ID:39977 IpLen:20 DgmLen:40 DF
**S* Seq: 0x28374839 Ack: 0x26917D08 Win: 0x2240 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Snort processed 1 packets.
Breakdown by protocol:
Action Stats:
TCP: 1 (100.000%) ALERTS: 0
UDP: 0 (0.000%) LOGGED: 0
ICMP: 0 (0.000%) PASSED: 0
ARP: 0 (0.000%)
IPv6: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 0 (0.000%)
原本发起一个序列号为SYN包674711609，将产生一个SYN/ACK 674711610或者ACK 674711610，也许是shaft的程序员疏忽或者太懒了，当实际情况是发起一个SYN包，它们为每个数据包使用了相同的TCP序列号。所以简单的通过检测6747116909的序列号，就能检测这种×××，另外你还会发现序列号变成了0x28374839，为什么?其实十进制的674711609，表示为十六进制为0x28374839.
接下来我们就要看看Snort规则如何防范这种×××，首先打开deleted.rules的第105行，如下：