Snort规则分析举例

最新推荐文章于 2025-08-07 11:22:44 发布

weixin_33775582

最新推荐文章于 2025-08-07 11:22:44 发布

阅读量2.5k

点赞数 1

CC 4.0 BY-SA版权

文章标签：操作系统运维

原文链接：https://my.oschina.net/chenguang/blog/2048656

2019独角兽企业重金招聘Python工程师标准>>>

Snort规则分析举例

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

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:

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

08/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行，如下：