lisapaper.txt文件.

释放双眼,带上耳机,听听看~!

lisapaper.txt,lisapaper.txt,

文本版本的“Snort-网络轻量级入侵检测”由Martin Roesch!本文讨论了Snort的体系结构、性能和用途。If将Snort与其他一些用于类似目的的著名程序进行了比较分析。文档中还包含了一个很好的规则教程,供想知道规则系统如何工作的人使用。

,Snort-网络轻量级入侵检测Martin Roesch Roesch@clark.net抽象网络入侵检测系统(NIDS)是任何网络安全体系结构的重要组成部分。它们提供了一个防御层,用于监视网络流量以确定预定义的可疑活动或模式,并在检测到潜在的恶意流量时向系统管理员发出警报。商业NIDS有许多不同之处,但信息系统部门必须面对它们所共有的共同点,如系统占用空间大、部署复杂和资金成本高。Snort旨在解决这些问题。Snort填补了网络安全领域中一个重要的“生态位”:一个跨平台、轻量级的网络入侵检测工具,可以用来监视小型TCP/IP网络,检测各种可疑的网络流量以及直接的攻击。它可以为管理员提供足够的数据,以便在面对可疑活动时,就正确的行动方针作出知情的决定。Snort还可以快速部署,以填补网络安全覆盖范围中的潜在漏洞,例如出现新的攻击时,以及商业安全供应商发布新的攻击识别签名的速度缓慢时。本文讨论了Snort的背景及其基于规则的流量收集引擎,以及Snort作为集成网络安全基础设施的一部分非常有用的新的和不同的应用。Snort是一个用于小型、利用率低的网络的工具。Snort在部署商用NIDS传感器不经济时非常有用。现代商业入侵检测系统至少要花费数千美元,在极端情况下甚至要花费几十万美元。Snort是在GNU通用公共许可证[GNU89]下提供的,可以在任何环境中免费使用,这使得Snort作为网络安全系统的使用更多地是一个网络管理和协调问题,而不是一个负担得起的问题。什么是“轻量级”入侵检测?轻量级入侵检测系统可以轻松地部署在网络的大多数节点上,对操作的干扰最小。轻量级id应该是跨平台的,具有较小的系统占用空间,并且易于由需要在短时间内实现特定安全解决方案的系统管理员配置。它们可以是任意一组软件工具,可以根据不断变化的安全情况进行组装并付诸实施。轻量级IDS很小,功能强大,并且足够灵活,可以作为网络安全基础设施的永久性元素使用。Snort非常适合担任这些角色,在其压缩的源代码分布中大约有100千字节。在大多数现代架构中,Snort只需要几分钟就可以编译并安装到位,而配置和激活可能需要十分钟。相比之下,许多商业NIDS需要专门的平台和用户培训才能以有意义的方式部署。Snort可以在不需要监视或管理维护的情况下配置并长时间运行,因此也可以作为大多数网络安全基础设施的组成部分使用。什么是Snort?Snort是一个基于libpcap的[PCAP94]包嗅探器和记录器,可以用作轻量级网络入侵检测系统(NIDS)。它具有基于规则的日志记录功能,可以执行内容模式匹配并检测各种攻击和探测,例如缓冲区溢出[ALE96]、隐形端口扫描、CGI攻击、SMB探测等等。Snort具有实时警报功能,警报将发送到syslog、服务器消息块(SMB)“WinPopup”消息,或单独的“警报”文件。Snort使用命令行开关和可选的Berkeley Packet Filter[BPF93]命令进行配置。检测引擎使用一种简单的语言进行编程,该语言描述每个包的测试和操作。易用性简化并加快了新的漏洞检测规则的开发。例如,当在Bugtraq邮件列表[BTQ99]中发现IIS Showcode[IISBT99]web漏洞时,可以在几个小时内使用Snort规则来检测探测。呼噜对世界!Snort与嗅探器和NIDS有共同点。本节将研究和对比两个可以直接与Snort、tcpdump和Network Flight Recorder进行比较的程序[NFR97]。在许多情况下,Snort在财务、技术和/或管理上比其他开源[OSS98]或商用工具更容易实现。Snort和tcpdump有何不同?Snort在外形上类似于tcpdump[TCPD91],但它更关注于包嗅探的安全应用。Snort具有tcpdump没有的主要特性是包有效负载检查。Snort对数据包的应用层进行解码,并可以给出规则来收集其应用层中包含特定数据的通信量。这使得Snort能够检测许多类型的恶意活动,包括缓冲区溢出、CGI扫描或包有效负载中的任何其他数据,这些数据可以用唯一的检测指纹来表示。Snort的另一个优点是,它的解码输出显示比tcpdump的输出更为用户友好。Snort当前在运行时不查找主机名或端口名,这是tcpdump可以执行的功能。Snort的重点是尽快收集数据包,并在Snort检测引擎中处理它们。执行运行时主机名查找不利于高性能数据包分析。图1显示了telnet横幅显示的典型Snort输出,图2显示了tcpdump显示的相同数据包。图1-典型的Snort telnet数据包显示:———-20:59:49.153313 0:10:4B:D:A9:66->0:60:97:7:C2:8E类型:0x800 len:0x7D 192.168.1.3:23->192.168.1.4:1031 TCP TTL:64 TOS:0x10 DF***PA*序列:0xDF4A6536 Ack:0xB3A6FD01 Win:0x446A FF FA 22 03 E2 03 04 82 0F 07 E2 1C 08 8204。。。。。。。。。。。。。09 C2 1A 0A 82 7F 0B 82 15 0F 82 11 10 82 13 FF。。。。。。。。。。。。。。。。F0 0D 0A 46 72 65 65 42 53 44 20 28 65 6C 72 69…免费BSD(elri 63 2E 68 6F 6D 65 2E 6E 65 74 29 20 28 74 74 79 c.home.net)(tty 70 30 29 0D 0A 0A p0)。。。。—————————————————————————图2-由tcpdump显示的同一telnet数据包:———-20:59:49.153313 0:10:4b:d:a9:66 0:60:97:7:c2:8e 0800 125:192.168.1.3.23>192.168.1.4.1031:P 76:147(71)ack 194 win 17514(DF)[tos0x10](ttl 64,id 660)4510 006f 0294 4000 4006 b48d c0a8 0103 c0a8 0104 0017 0407 df4a 6536 b3a6 fd01 5018 446a d2ad 0000 fffa 2203 03e2 0304 820f 07e2 1c08 8204 09c2 1A 827f 0b82 150f 8211 1082 FF f00d 0a46 7265 6542 5344 2028 656c 7269 632e 686f 6d65 2e6e 6574 2920 2874 7479 7030 290d 0a—————————————————————————Snort和tcpdump共享的一个强大功能是使用Berkeley Packet filter(BPF)命令过滤流量。这允许基于各种特定分组字段收集通信量。例如,可以通过BPF命令指示这两个工具仅处理TCP通信量。虽然TCPDUMP将收集所有TCP业务,但Snort可以利用其灵活的规则集来执行附加功能,例如搜索和记录那些具有特定TCP标志的分组,或者包含包含CGI漏洞探测的Web请求。来自海军水面作战中心的SHADOW IDS[SHD98]基于tcpdump并使用广泛的BPF滤波。在这篇文章的末尾,我们将更详细地讨论阴影呃。Snort和NFR也许Snort和NFR最好的比较是将Snort比喻为NFR大学时代的足球英雄的弟弟。Snort与NFR共享一些相同的功能概念,但NFR是一种更灵活和完整的网络分析工具。也就是说,小弟弟的想法可以扩展到Snort更适合小地方,而且比NFR更“灵活”。例如,NFR的包过滤n代码语言是一种严肃的、功能齐全的脚本语言,而Snort的规则更为一维。另一方面,一旦确定了攻击特征,编写Snort规则来检测新的攻击只需几分钟。有关用n代码编写的简单web检测规则和类似Snort规则的示例,请参见附录A。NFR还有一个比Snort更完整的特性集,包括IP碎片重组和TCP流解码。这些特性在任何执行任务关键型入侵检测的商业产品中都是必不可少的,NFR是第一个能够击败Ptacek和Newsham[PTA98]概述的反NIDS攻击的产品。目前,Snort没有实现TCP流重组,但将来的版本将实现这一功能。Snort当前使用一个规则选项来处理IP碎片,该选项为碎片数据包设置最小大小阈值。这个规则选项利用了这样一个事实:市场上几乎没有任何商业网络设备可以对小于256字节的数据包进行分段。通过将此阈值设置为某个合理的值(例如128字节),可以记录碎片化的数据包探测和攻击,并通过Snort自动发送警报。完整的IP片段和TCP流重组和分析将在以后版本的Snort中讨论。在引擎盖Snort的架构下,专注于性能、简单性和灵活性。Snort主要由三个子系统组成:包解码器、检测引擎和日志和警报子系统。这些子系统位于libpcap混杂包嗅探库之上,该库提供可移植的包嗅探和过滤功能。程序配置、规则解析和数据结构生成在嗅探器部分初始化之前进行,将每个包的处理量保持在实现基本程序功能所需的最小值。包解码器解码引擎是围绕支持的数据链路和TCP/IP协议定义中的协议栈层组织的。解码器中的每个子程序通过在原始网络流量上叠加数据结构来对分组数据施加顺序。这些解码例程按顺序通过协议栈调用,从数据链路层到传输层,最后在应用层结束。本节强调速度,解码器的大部分功能包括将指针设置到分组数据中,以便检测引擎稍后进行分析。Snort为以太网、SLIP和raw(PPP)数据链路协议提供解码功能。ATM支持正在开发中。检测引擎Snort将其检测规则维护在一个二维链表中,这个链表被称为链头和链选项。这些规则列表已压缩为链标题中的公共属性列表,其中检测修饰符选项包含在链选项中。例如,如果在给定的Snort检测库文件中指定了45个CGI-BIN探测规则,它们通常都共享公共的源和目标IP地址和端口。为了加快检测处理速度,这些共性被压缩成一个单链报头,然后将单个检测签名保存在链选项结构中。图3-规则链逻辑结构—————————————————————–链头| | |链头| | | Chai | | | | | | |源IP地址| | | Sour |目的地I| | | | | |内容| | TCP标志|| ICMP代码/类型| |负载大小| | | | | | | | | | | | | | | | | | | TCP标志| | ICMP代码/类型| |负载大小| | | | | | | | | | | | | | | | | |在两个方向上递归地为每个包。检测引擎只检查规则解析器在运行时设置的那些链选项。与检测引擎中解码包匹配的第一条规则触发规则定义中指定的操作并返回。检测引擎的一次大修目前正处于规划和开发阶段。下一个版本的引擎将包括用户编写和分发插件模块并将它们绑定到检测引擎规则语言的关键字的功能。这将允许具有适当插件模块的任何人向Snort添加重要的检测功能,并为特定作业自定义程序。日志/警报子系统在运行时使用命令行开关选择警报和日志子系统。目前有三个日志记录和五个警报选项。日志记录选项可以设置为将数据包以解码的可读格式记录到基于IP的目录结构中,或将数据包以tcpdump二进制格式记录到单个日志文件中。解码格式日志允许对系统收集的数据进行快速分析。tcpdump格式记录到磁盘的速度要快得多,应该在需要高性能的情况下使用。日志记录也可以完全关闭,使警报处于启用状态,以获得更大的性能改进。警报可以发送到syslog,以两种不同的格式记录到警报文本文件,或者使用Samba smbclient程序作为WinPopup消息发送。系统日志警报以安全/授权消息的形式发送,这些消息很容易通过swatch[SWT93]等工具进行监控。WinPopup警报允许将事件通知发送到运行WinPopup软件的Microsoft Windows控制台的用户指定列表。向纯文本文件发送警报有两个选项:完全警报和快速警报。完全警报通过传输层协议写入警报消息和数据包头信息。快速警报选项将头信息的压缩子集写入警报文件,允许在负载下比完全模式下更高的性能。有第五个选项可以完全禁用警报,当警报不必要或不适当时(例如正在执行网络渗透测试时),此选项非常有用。编写Snort规则Snort规则编写起来很简单,但功能强大,足以检测各种恶意或可疑的网络流量。当包与指定的规则模式匹配时,Snort可以使用三个基本操作指令:pass、log或alert。传递规则只是丢弃数据包。日志规则将完整数据包写入用户在运行时选择的日志记录例程。警报规则使用用户在命令行指定的方法生成事件通知,然后使用选定的日志记录机制记录完整数据包,以便以后进行分析。最基本的规则只包含协议、方向和感兴趣的端口,如图4所示。图4-一个简单的Snort规则————————————————————记录tcp any->10.1.1.0/24 79—————此规则将记录端口79(finger)到10.1.1 C类网络地址空间的所有入站流量。Snort将括号中的关键字解释为“选项字段”。选项字段可用于所有rule可以用来从程序中生成复杂的行为,如图5所示。图5 -选项允许增加规则复杂度———————————————————————————————1.1.1.0/24 80(内容:“/CGIN BI/PHF”);MSG:“PHF探针!”;)——————————————————————————————————————————————————————————————————————————————————。如果在网络上检测到此类数据包,则生成事件通知警报,然后通过在运行时选择的日志记录机制记录整个数据包。规则IP地址和端口说明符有几个可用的功能。CIDR块网络掩码可以设置为1到32之间的任何值。端口范围可以使用冒号“:”修饰符指定。例如,要监视运行X Windows服务的所有端口(通常是6000到6010),可以使用冒号修饰符指定端口范围,如图6所示。图6-端口范围的示例—–alert tcp any->10.1.1.0/24 6000:6010(msg:“X traffic”;)operator,这在图7中描述的规则中很有用,它可以检测来自网络外部源的X个Windows流量。图7-按源IP地址上的异常匹配-警报tcp!10.1.1.0/24 any->10.1.1.0/24 6000:6010(消息:“X traffic”;)—————————————————————————————————————————————————————————————————————————————。Snort版本1.2.1有14个可用的选项字段:1。内容:搜索指定模式的数据包负载。2。标志:测试指定设置的TCP标志。三。ttl:检查IP头的生存时间(ttl)字段。四。itype:在ICMP类型字段上匹配。5个。icode:ICMP代码字段上的匹配。6。minfrag:设置IP片段大小的阈值。7号。id:测试指定值的IP头。8个。ack:查找特定的TCP报头确认号。9号。seq:特定TCP头序列号的日志。10个。Log to:将规则与指定文件名匹配的日志包。11号。dsize:匹配数据包负载的大小。12岁。offset:内容选项的修饰符,将偏移设置到数据包负载中以开始内容搜索。13岁。深度:内容选项的修饰符,设置从起始位置开始搜索的字节数。14岁。msg:设置数据包生成事件时要发送的消息。这些选项可以以任何方式组合以检测和分类感兴趣的包。规则选项使用逻辑“AND”在它们之间进行处理;规则中的所有测试选项必须为true,以便规则生成“found”响应并让程序执行规则操作。规则开发Snort对于快速开发新的Snort规则非常有用。该工具显示数据的方式简洁明了,非常适合编写新规则。开发的一般方法包括获取感兴趣的漏洞,例如新的缓冲区溢出,在Snort记录目标和攻击主机之间的所有流量的测试网络上运行漏洞,然后分析数据以获得唯一的签名,并将该签名压缩为规则。图8显示了Snort对概念上的“IMAP缓冲区溢出”的视图,该视图刚刚被“脚本小子”社区广泛使用。图8-概念上的“IMAP缓冲区溢出”数据包———————————–052499-22:27:58.403313 192.168.1.4:1034->192.168.1.3:143 TCP TTL:64 TOS:0x0 DF***PA*序列:0x5295B44E Ack:0x1B4F8970 Win:0x7D78 90 90 90 90 90 90 90 90 90 90 90 EB 3B……………;5E 89 76 08 31 ED 31 C9 31 C0 88 6E 07 89 6E 0C^.v.1.1.1..n..n.B0 0B 89 F3 8D 6E 08 89 E9 8D 6E 0C 89 EA CD 80…..n…..n。。。。。31分贝89 D8 40 CD 80 90 90 90 90 90 90 90 90 1…@。。。。。。。。。。。90 90 90 90 90 90 90 90 90 90 90 90 E8 C0 FF FF FF FF。。。。。。。。。。。。。。。。2F 62 69 6E 2F 73 68 90 90 90 90 90 90 90 90 90/箱/箱。。。。。。。。。—————————————————————————应用层中唯一的签名数据是/bin/sh文本字符串之前的机器代码,以及字符串本身。使用这些信息,可以快速开发新规则,如图9中定义的规则。图9-新缓冲区溢出的警报规则———————————–向tcp any发出警报->192.168.1.0/24 143(内容:“| E8C0 FFFF FF |/bin/sh”;消息:“检测到新的IMAP缓冲区溢出!”;)————————————————————————————————————————————————————————————————————————————————。在运行时,这些数据被转换成其二进制表示,如图8中解码后的数据包转储所示,然后由Snort存储在规则的内部列表中。因此,只要检测到包含新IMAP缓冲区溢出“指纹”的数据包,图9中包含的规则就会发出警报。编写高性能的模式匹配规则当前的规则系统在大多数情况下都具有高性能,但是在编写Snort规则时可以应用一些通用概念,以尽可能地保持处理速度。在计算上,内容匹配选项是检测引擎中执行的最昂贵的过程。因此,它在所有其他规则测试之后执行。通过结合指定其他规则选项和内容选项,可以利用此事实。例如,几乎所有对web服务器的请求都设置了TCP PUSH和ACK标志。利用这些知识,在运行计算量更大的模式匹配测试之前,编写一个规则来执行一个简单的TCP标志测试是相对容易的。其他选项可以与内容规则结合使用,以限制必须搜索的数据量。偏移量和深度关键字是专门为实现此功能而设置的。使用这些选项,可以本地化用于搜索攻击模式的数据包负载区域。应注意避免过度限制搜索。例如,许多缓冲区溢出使用变量偏移量来调整利用漏洞机器代码的大小和位置。对Snort规则的调整过于严格,以至于无法确定数据包有效负载的特定区域,这可能会忽略已转移到数据包中其他区域的实际利用率。另一方面,web CGI的探测和攻击通常都发生在数据包的开头,在前30到50个字节内。这是一个优化Snort内容搜索的好地方。内容规则中使用的实际搜索模式是可能进行性能调整的另一个领域。Snort使用Boyer-Moore[SEDG97]算法来执行其模式匹配,这是可用于该任务的最佳算法之一。当要匹配的模式由不重复的唯一字节集组成时,它实现了最大的效率。例如,英特尔x86体系结构使用十六进制值0x90来表示机器代码中的NOP。缓冲区溢出通常使用大区域的nop来填充实际的利用漏洞代码,并使利用漏洞的程序员更容易进行返回跳跃计算。在指定内容匹配模式时,最好避免在匹配模式中包含任何nop,否则会导致Boyer-Moore例程在实际找到正确的匹配模式之前完成许多部分匹配。先进的打鼾Snort是一种灵活的工具,用途广泛。它的目的是在网络入侵检测系统的最经典的意义上使用。它根据一组规则检查网络流量,并且提醒管理员注意可疑的网络活动,以便他们做出适当的反应。还有很多其他领域Snort也很有用。支持商业IDS的Snort可以用来填补商业供应商基于网络的入侵检测工具的漏洞,例如当一个新的攻击在黑客/破解者社区首次出现时,供应商的签名更新速度很慢。在这种情况下,Snort可以通过在测试网络上本地运行并确定其特征来描述新攻击。一旦签名被写入snort规则,BPF命令行过滤就可以用来限制snort分析到感兴趣的服务或协议的流量。在这种模式下,Snort可以用作单个攻击或一系列攻击的非常专用的检测器。L0pht最近发现的IRDP拒绝服务攻击[IRDP99]就是一个很好的例子。在宣布攻击的同一天,用户社区提供了Snort规则,这些攻击是可以检测到的。被动陷阱Snort非常适合的另一个应用程序是蜜罐监视器。蜜罐是专门用来欺骗对网络感兴趣的敌对方的程序或计算机。大多数蜜罐系统,例如Fred Cohen&Associates欺骗工具包[DTK98],都是在服务器级记录数据的,使用一个假的“服务”,比如一个FTP服务器实际记录发送给它的数据。这个概念的问题是,在记录任何内容之前,必须启动进行记录的服务。这意味着,诸如隐形端口扫描或二进制数据流之类的事件将在不执行数据包级别监视的蜜罐上丢失或混淆。另一个问题是,由这样一个系统生成的数据由于其性质而趋于复杂。蜜罐里的数据需要一个熟练的分析师来正确解释结果。Snort通过其数据包分类和自动警报功能对分析员/管理员非常有帮助。有了这些能力,蜜罐可以作为一个独立的入侵检测机制建立起来。它不需要其他监视或维护,因为Snort可以设置为在到达蜜罐的第一个数据包上记录和生成事件通知。Snort可以用来实现今天提倡的另一个概念:“被动陷阱”[MJR99]。被动陷阱利用了网络管理员在保护网络安全时所享有的“主场优势”。这个概念的一个方面是,管理员知道哪些服务在其网络上不可用。Snort规则可以被写入,用于观察那些不存在的服务的流量。发现使用这些端口的数据包可能表示端口扫描、后门或其他恶意通信。例如,不使用TFTP的网络可以配置Snort警报规则,用于连接端口69的网络上任何节点的所有数据包。这可能是一个很好的方法来检测隐蔽的通信信道,如Loki或后门,如后门孔口。另一个易于实现的概念是为已知在网络上运行的所有服务设置传递规则,并记录到其他端口或端口范围的入站连接。在阴影上照射一些光线被设计成一种廉价的商业NIDS替代品。另外,SHADOW可能是第一个真正的轻量级入侵检测系统。tcpdump用作这些系统中的传感器,这些系统通常使用广泛的BPF命令进行配置。所有没有用这些BPF规则过滤掉的流量都被收集到一个文件中,这个文件在很长一段时间内会变得很大。一旦传感器收集到数据,就会使用各种外部第三方工具进行后处理。该系统存在一些局限性,包括完全缺乏实时警报,以及缺乏良好的数据分类工具来帮助分析员识别传感器产生的数据。Snort使用与tcpdump相同的BPF过滤语言规则,并且可以用作完全替代tcpdump传感器的环境中,阴影是选择的ID。使用Snort作为替代传感器的优点包括实时自动交通分类和实时报警。这使得管理人员能够更及时地检测和处理安全事件,并大大减少日志文件的大小。同时,Snort可以将它收集到的数据记录到TCPDUMP格式化的文件中,这样系统生成的数据就可以用现有分析器舒适使用的工具进行深度分析后处理。集中监视“集中监视”是指监视网络上的单个关键节点或服务,以发现敌对活动的迹象。例如,Sendmail[ALMN99]SMTP服务器有一个广为人知的漏洞和攻击列表。单个Snort传感器可以部署一个规则集,该规则集涵盖所有已知的Sendmail攻击,并提供对网络上特定流量的高度集中监视。这些规则甚至可以被扩展,以提供进入和离开受保护网络上的SMTP服务器的所有命令和响应的运行说明。这可以让收集引擎(Snort)描述命令和响应以及攻击的正常流程,从而使网络安全分析人员的工作更容易一些。在现有NIDS提供不充分覆盖的情况下,集中监视尤其有用。例如,可以开发一组规则来监视对web或数据库服务器的SQL数据库查询。这将提供比目前市场上任何商业nid更完整的CGI和ODBC SQL攻击和探测覆盖范围。这一概念可以扩展到任何网络通信技术,这是不足的商业NIDS代表。结论Snort的设计满足了典型的轻量级网络入侵检测系统的要求。它已经成为一个小型的、灵活的、高性能的系统,它在世界各地都在大型和小型网络中使用。它已经达到了最初的设计目标,是一个完全有能力替代商业入侵检测系统的地方,它的成本低,安装功能齐全的商业系统。可用性和需求Snort将在libpcap运行的任何平台上运行。Snort的当前版本是1.2.1,编译和运行该软件需要libpcap。众所周知,Snort运行在RedHat Linux 5.1/5.2/6.0、Debian Linux、MkLinux、S/Linux、HP-UX、Solaris 2.5.1-2.7(x86和Sparc)、x86 Free/Net/OpenBSD、M68k NetBSD,关于snort的信息可以直接从作者的网站http://www.clark.net/~roesch/security.html上获取snort可以从作者的网站http://www.clark.net/~roesch/snort-1.2.1.tar.gz上下载snort有一个增长缓慢的snort规则库,可在http://www.clark.net/~roesch/snort lib上找到Snort最初使用Mike Borella的ipgrab程序作为开发模板,并举例说明如何正确地编写libpcap程序和包解码器。ipgrab可以在http://www.borella.net上找到。对于任何基于libpcap的项目来说,Mike的代码都是一个很好的起点。网络安全向导的Ron Gula提供了关于日志记录方法和一些初始程序逻辑的宝贵建议,并为系统提供了示例规则。Ken Williams在Snort的整个开发过程中都非常支持Snort,为其他特性提供了鼓励和想法,并为Snort的发布提供了一个友好的论坛。Snort用户社区自程序最初发布以来,一直非常乐于与之合作,为库提供bug报告、新开发方向的想法和新规则。他们的支持和热情使这个至关重要的、不断发展的合作项目远远超出了我的想象!参考文献[SHD98]SHADOW,Steven Northcutt等人,海军水面作战中心达尔格伦实验室,1998年。[TCPD91]tcpdump、Van Jacobson、Craig Leres和Steven McCanne,劳伦斯伯克利国家实验室,1991年。[PCAP94]libpcap、Van Jacobson、Craig Leres和Steven McCanne,劳伦斯伯克利国家实验室,1994年。[DTK98]欺骗工具包,弗雷德·科恩和协会,1998年。[GNU89]GNU通用公共许可证,Richard Stallman,1989年。[BPF93]BSD数据包过滤器:用户级数据包捕获的新架构,Steven McCanne,Van Jacobson,USENIX技术会议记录,1993年。[ALE96]为了乐趣和利润粉碎堆栈,Aleph1,Phrack#491996。[BTQ99]Bugtraq邮件列表、存档和漏洞数据库可从安全焦点获得。[IISBT99]NT IIS Showcode ASP漏洞(Bugtraq ID#167),Parcens/L0pht,1999年5月。[OSS98]大教堂和集市,埃里克·S·雷蒙德,1998年。[FYD97]端口扫描艺术,Fyodor,Phrack#511997年。[SWT92]使用Swatch进行集中系统监控,Stephen E.Hansen和E.Todd Atkins,USENIX第七届系统管理会议,1993年,[SEDG97]C中的算法:基础,数据结构,排序,搜索,Robert Sedgewick,Addison Wesely出版公司,1997年[IRDP99]L0pht安全咨询,矽肺和Mudge,1999年8月[ALMN99]Sendmail,Eric Allman,1999年[PTA98]插入、规避和拒绝服务:逃避网络入侵检测,Thomas Ptacek和Timothy Newsham,安全网络公司,1998年[MJR99]用于检测入侵的防盗警报器,Marcus Ranum,NFR公司,1999年作者信息Martin Roesch是斯坦福电信公司的网络安全工程师。他拥有克拉克森大学计算机工程学士学位。他在入侵检测系统方面有着丰富的经验,并专业开发了多个系统。他是GTE Internetworking全球网络基础设施ID开发期间的主要软件工程师,并设计和开发了GTE新的商业蜜罐/欺骗系统“哨兵”。他也是Trinux Linux安全工具包发行开发团队的成员。Snort是他的第一个开源软件项目,对他来说是一次极好的学习经历。联系他。附录A.用于检测web服务器CGI探测器的NFR规则示例(n代码示例摘自L0pht的NFR ID模块网页)。—————————————————————————badweb_schema=library_schema:new(1,[“time”,“int”,“ip”,“ip”,“str”],scope());#要监视的web服务器列表。列出服务器的IP地址或与所有服务器匹配的网络掩码。使用0.0.0.0:0.0.0.0匹配任何服务器da_web_servers=[0.0.0.0:0.0.0.0];query_list=[“/cgi bin/nph test cgi?”,“/cgi-bin/测试cgi?”,“/cgi-bin/perl.exe?”,“/cgi-bin/phf?”];筛选bweb-tcp(客户端,dport:80){如果(!(tcp.connDst inside daúweb戋servers)return;在tcp.connSym中声明$blob;if($blob==null)$blob=tcp.blob;else$blob=cat($blob,tcp.blob);while(1==1){$x=index($blob,“\n”);if($x<0)#如果没有完整的行,则中断循环;$t=substr($blob,$x-1,1);#如果($t='\r')$t=substr($blob,0,$x-1);#删除行else$t=substr($blob,0,$x);$counter=0;foreach$y inside(查询列表){$z=index($blob,$y);if($z>=0){$counter=1;#节省时间、连接哈希、客户端、服务器和直方图记录系统的命令。time,tcp.connHash,tcp.connSrc,tcp.connDst,$t to badweb_hist;}if($counter)break;}如果数据中没有新行if(strlen($blob)>4096)$blob=“;”保存blob以进行下一次传递$blob=substr($blob,$x+1);}badweb_hist=recorder(“bin/histogram packages/test/badweb.cfg”,“badweb_schema”);———————————————————————————Snort规则检测相同的web CGI探测。———————————————————————————向tcp发出任何警报->任何80(消息:“CGI nph tst CGI”;内容:“CGI bin/nph test CGI?”;flags:PA;)警告tcp any any->any 80(消息:“CGI test CGI”;内容:“CGI bin/test CGI?”;flags:PA;)警告tcp any any->any 80(消息:“CGI perl.exe”;内容:“CGI bin/perl.exe?”;flags:PA;)警告tcp any any->any 80(消息:“CGI phf”;内容:“CGI bin/phf?”;标志:PA;)——————————————————————————–,网络安全教程lisapaper.txt,

Text version of “Snort – Lightweight Intrusion Detection for Networks” by Martin Roesch! This paper discusses the architecture, performance, and uses of Snort. If makes a comparative analysis of Snort to some other wellknown programs used for similar purposes. There is also a nice rules tutorial contained in the document for those of you wanting to know how the rules system works.

, Snort - Lightweight Intrusion Detection for Networks

Martin Roesch
roesch@clark.net

ABSTRACT

Network intrusion detection systems (NIDS) are an important part of any
network security architecture. They provide a layer of defense which monitors
network traffic for predefined suspicious activity or patterns, and alert
system administrators when potential hostile traffic is detected. Commercial
NIDS have many differences, but Information Systems departments must face the
commonalities that they share such as significant system footprint, complex
deployment and high monetary cost. Snort was designed to address these issues.

Introduction

Snort fills an important "ecological niche" in the the realm of network
security: a cross-platform, lightweight network intrusion detection tool that
can be deployed to monitor small TCP/IP networks and detect a wide variety of
suspicious network traffic as well as outright attacks. It can provide
administrators with enough data to make informed decisions on the proper course
of action in the face of suspicious activity. Snort can also be deployed
rapidly to fill potential holes in a network's security coverage, such as when
a new attack emerges and commercial security vendors are slow to release new
attack recognition signatures. This paper discusses the background of Snort
and its rules-based traffic collection engine, as well as new and different
applications where it can be very useful as a part of an integrated network
security infrastructure.

Snort is a tool for small, lightly utilized networks. Snort is useful
when it is not cost efficient to deploy commercial NIDS sensors. Modern
commercial intrusion detection systems cost thousands of dollars at minimum,
tens or even hundreds of thousands in extreme cases. Snort is available under
the GNU General Public License [GNU89], and is free for use in any environment,
making the employment of Snort as a network security system more of a network
management and coordination issue than one of affordability.

What is "lightweight" intrusion detection?

A lightweight intrusion detection system can easily be deployed on most
any node of a network, with minimal disruption to operations. Lightweight IDS'
should be cross-platform, have a small system footprint, and be easily
configured by system administrators who need to implement a specific security
solution in a short amount of time. They can be any set of software tools
which can be assembled and put into action in response to evolving security
situations. Lightweight IDS' are small, powerful, and flexible enough to be
used as permanent elements of the network security infrastructure.

Snort is well suited to fill these roles, weighing in at roughly 100
kilobytes in its compressed source distribution. On most modern architectures
Snort takes only a few minutes to compile and put into place, and perhaps
another ten minutes to configure and activate. Compare this with many
commercial NIDS', which require dedicated platforms and user training to deploy
in a meaningful way. Snort can be configured and left running for long
periods of time without requiring monitoring or administrative maintenance, and
can therefore also be utilized as an integral part of most network security
infrastructures.

What is Snort?

Snort is a libpcap-based [PCAP94] packet sniffer and logger that can
be used as a lightweight network intrusion detection system (NIDS). It
features rules based logging to perform content pattern matching and detect
a variety of attacks and probes, such as buffer overflows [ALE96], stealth port
scans, CGI attacks, SMB probes, and much more. Snort has real-time alerting
capability, with alerts being sent to syslog, Server Message Block (SMB)
"WinPopup" messages, or a separate "alert" file. Snort is configured using
command line switches and optional Berkeley Packet Filter [BPF93] commands.
The detection engine is programmed using a simple language that describes per
packet tests and actions. Ease of use simplifies and expedites the development
of new exploit detection rules. For example, when the IIS Showcode [IISBT99]
web exploits were revealed on the Bugtraq mailing list [BTQ99], Snort rules to
detect the probes were available within a few hours.

Snort vs. The World!

Snort shares commonalities with both sniffers and NIDS. Two programs
that lend themselves to direct comparison with Snort, tcpdump and Network
Flight Recorder [NFR97], will be examined and contrasted in this section.
In many cases, Snort is financially, technically, and/or adminstratively easier
to implement than other Open Source [OSS98] or commercially available tools.

How is Snort different from tcpdump?

Snort is cosmetically similar to tcpdump [TCPD91] but is more focused
on the security applications of packet sniffing. The major feature that Snort
has which tcpdump does not is packet payload inspection. Snort decodes the
application layer of a packet and can be given rules to collect traffic that
has specific data contained within its application layer. This allows Snort to
detect many types of hostile activity, including buffer overflows, CGI scans,
or any other data in the packet payload that can be characterized in a unique
detection fingerprint.

Another Snort advantage is that its decoded output display is
somewhat more user friendly than tcpdump's output. Snort does not currently
lookup host names or port names while running, which is a function that
tcpdump can perform. Snort is focused on collecting packets as quickly as
possible and processing them in the Snort detection engine. Performing
run-time host name lookup is not conducive to high performance packet
analysis. Figure 1 shows typical Snort output for a telnet banner display,
and Figure 2 shows the same packet as displayed by tcpdump.

Figure 1 - Typical Snort telnet packet display:
--------------------------------------------------------------------------
20:59:49.153313 0:10:4B:D:A9:66 -> 0:60:97:7:C2:8E type:0x800 len:0x7D
192.168.1.3:23 -> 192.168.1.4:1031 TCP TTL:64 TOS:0x10 DF
***PA* Seq: 0xDF4A6536 Ack: 0xB3A6FD01 Win: 0x446A
FF FA 22 03 03 E2 03 04 82 0F 07 E2 1C 08 82 04 ..".............
09 C2 1A 0A 82 7F 0B 82 15 0F 82 11 10 82 13 FF ................
F0 0D 0A 46 72 65 65 42 53 44 20 28 65 6C 72 69 ...FreeBSD (elri
63 2E 68 6F 6D 65 2E 6E 65 74 29 20 28 74 74 79 c.home.net) (tty
70 30 29 0D 0A 0D 0A p0)....
---------------------------------------------------------------------------

Figure 2 - The same telnet packet as displayed by tcpdump:
---------------------------------------------------------------------------
20:59:49.153313 0:10:4b:d:a9:66 0:60:97:7:c2:8e 0800 125: 192.168.1.3.23 >
192.168.1.4.1031: P 76:147(71) ack 194 win 17514 (DF) [tos 0x10] (ttl 64,
id 660)
4510 006f 0294 4000 4006 b48d c0a8 0103
c0a8 0104 0017 0407 df4a 6536 b3a6 fd01
5018 446a d2ad 0000 fffa 2203 03e2 0304
820f 07e2 1c08 8204 09c2 1a0a 827f 0b82
150f 8211 1082 13ff f00d 0a46 7265 6542
5344 2028 656c 7269 632e 686f 6d65 2e6e
6574 2920 2874 7479 7030 290d 0a0d 0a
---------------------------------------------------------------------------

One powerful feature that Snort and tcpdump share, is the capability
to filter traffic with Berkeley Packet Filter (BPF) commands. This allows
traffic to be collected based upon a variety of specific packet fields. For
example, both tools may be instructed via BPF commands to process TCP traffic
only. While tcpdump would collect all TCP traffic, Snort can utilize its
flexible rules set to perform additional functions, such as searching out and
recording only those packets that have their TCP flags set a particular way or
containing web requests that amount to CGI vulnerability probes. The SHADOW
IDS [SHD98] from the Naval Surface Warfare Center is based on tcpdump and uses
extensive BPF filtering. SHADOW is discussed in more detail near the end of
this paper.

Snort and NFR

Perhaps the best comparison of Snort to NFR is the analogy of Snort
as little brother to NFR's college-bound football hero. Snort shares some of
the same concepts of functionality as NFR, but NFR is a more flexible and
complete network analysis tool. That said, the little brother idea could be
extended in that Snort tends to fit into small places and is somewhat more
"nimble" than NFR. For example, NFR's packet filtering n-code language is
a serious, full featured scripting language, while Snort's rules are more one
dimensional. On the other hand, writing a Snort rule to detect a new attack
takes only minutes once the attack signature has been determined. See
Appendix A for an example of a simple web detection rule written in n-code and
the analogous Snort rule.

NFR also has a more complete feature set than Snort, including IP
fragmentation reassembly and TCP stream decoding. These features are essential
in any commercial product that is meant to perform mission critical intrusion
detection, and NFR was the first product which could defeat anti-NIDS attacks
outlined by Ptacek and Newsham [PTA98]. Presently, Snort does not implement TCP
stream reassembly, but future versions will implement this capability.
Snort currently addresses IP fragmentation with a rule option that sets a
minimum size threshold for fragmented packets. This rule option takes
advantage of the fact that there is virtually no commercial network equipment
on the market that fragments packets smaller than 256-bytes. By setting this
threshold value to some reasonable value, say 128-bytes, fragmented packet
probes and attacks can be logged and alerts can be sent by Snort automatically.
Full IP fragment and TCP stream reassembly and analysis will be addressed in
later versions of Snort.

Under the Hood

Snort's architecture is focused on performance, simplicity, and
flexibility. There are three primary subsystems that make up Snort: the
packet decoder, the detection engine, and the logging and alerting subsystem.
These subsystems ride on top of the libpcap promiscuous packet sniffing
library, which provides a portable packet sniffing and filtering capability.
Program configuration, rules parsing, and data structure generation takes place
before the sniffer section is initialized, keeping the amount of per packet
processing to the minimum required to achieve the base program functionality.

The packet decoder

The decode engine is organized around the layers of the protocol stack
present in the supported data-link and TCP/IP protocol definitions. Each
subroutine in the decoder imposes order on the packet data by overlaying data
structures on the raw network traffic. These decoding routines are called in
order through the protocol stack, from the data link layer up through the
transport layer, finally ending at the application layer. Speed is emphasized
in this section, and the majority of the functionality of the decoder consists
of setting pointers into the packet data for later analysis by the detection
engine. Snort provides decoding capabilities for Ethernet, SLIP, and raw (PPP)
data-link protocols. ATM support is under development.

The detection engine

Snort maintains its detection rules in a two dimensional linked list of
what are termed Chain Headers and Chain Options. These are lists of rules that
have been condensed down to a list of common attributes in the Chain Headers,
with the detection modifier options contained in the Chain Options. For
example, if forty five CGI-BIN probe detection rules are specified in a given
Snort detection library file, they generally all share common source and
destination IP addresses and ports. To speed the detection processing, these
commonalities are condensed into a single Chain Header and then individual
detection signatures are kept in Chain Option structures.

Figure 3 - Rule Chain logical structure
-------------------------------------------------------------------------------
------------------------ ------------------------ -----
| Chain Header | | Chain Header | | Chai
| | | | |
| Source IP Address | | Source IP Address | | Sour
| Destination IP Address |--------->| Destination IP Address |--------->| Dest
| Source Port | | Source Port | | Sour
| Destination Port | | Destination Port | | Dest
| | | | |
------------------------ ------------------------ -----
| |
| |
| |
\|/ \|/
-----------V--------- -----------V---------
| Chain Option | | Chain Option |
| | | |
| Content |
| TCP Flags |
| ICMP Codes/types |
| Payload Size |
| etc. |
| |
---------------------
|
|
|
\|/
-----------V---------
| Chain Option |
| |
| Content |
| TCP Flags |
| ICMP Codes/types |
| Payload Size |
| etc. |
| |
---------------------
|
|

-------------------------------------------------------------------------------

These rule chains are searched recursively for each packet in both
directions. The detection engine checks only those chain options which have
been set by the rules parser at run-time. The first rule that matches a
decoded packet in the detection engine triggers the action specified in the
rule definition and returns.

A major overhaul of the detection engine is currently in the planning
and development stage. The next version of the engine will include the
capability for users to write and distribute plug-in modules and bind them to
keywords for the detection engine rules language. This will allow anyone with
an appropriate plug-in module to add significant detection functionality to
Snort and customize the program for specific jobs.

The logging/alerting subsystem

The alerting and logging subsystem is selected at run-time with command
line switches. There are currently three logging and five alerting options.
The logging options can be set to log packets in their decoded, human readable
format to an IP-based directory structure, or in tcpdump binary format to a
single log file. The decoded format logging allows fast analysis of data
collected by the system. The tcpdump format is much faster to record to the
disk and should be used in instances where high performance is required.
Logging can also be turned off completely, leaving alerts enabled for even
greater performance improvements.

Alerts may either be sent to syslog, logged to an alert text file in two
different formats, or sent as WinPopup messages using the Samba smbclient
program. The syslog alerts are sent as security/authorization messages that are
easily monitored with tools such as swatch [SWT93]. WinPopup alerts allow
event notifications to be sent to a user-specified list of Microsoft Windows
consoles running the WinPopup software. There are two options for sending the
alerts to a plain text file; full and fast alerting. Full alerting writes the
alert message and the packet header information through the transport layer
protocol. The fast alert option writes a condensed subset of the header
information to the alert file, allowing greater performance under load than
full mode. There is a fifth option to completely disable alerting, which is
useful when alerting is unnecessary or inappropriate, such as when network
penetrations tests are being performed.

Writing Snort Rules

Snort rules are simple to write, yet powerful enough to detect a wide
variety of hostile or merely suspicious network traffic. There are three base
action directives that Snort can use when a packet matches a specified rule
pattern: pass, log, or alert. Pass rules simply drop the packet. Log rules
write the full packet to the logging routine that was user selected at
run-time. Alert rules generate an event notification using the method specified
by the user at the command line, and then log the full packet using the
selected logging mechanism to enable later analysis.

The most basic rules contain only protocol, direction, and the port of
interest, such as in Figure 4.

Figure 4 - A simple Snort rule
---------------------------------------------------------------------------
log tcp any any -> 10.1.1.0/24 79
---------------------------------------------------------------------------

This rule would record all traffic inbound for port 79 (finger) going to
the 10.1.1 class C network address space.

Snort interprets keywords enclosed in parentheses as "option fields".
Option fields are available for all rule types and may be used to generate
complex behaviors from the program, such as in Figure 5.

Figure 5 - Options allow increased rule complexity
---------------------------------------------------------------------------
alert tcp any any -> 10.1.1.0/24 80 (content: "/cgi-bin/phf"; msg: "PHF
probe!";)
---------------------------------------------------------------------------

The rule in Figure 5 would detect attempts to access the PHF service on any
of the local network's web servers. If such a packet is detected on the
network, an event notification alert is generated and then the entire packet
is logged via the logging mechanism selected at run-time.

The rule IP address and port specifiers have several features
available. The CIDR block netmask may be set to any value between one and
thirty-two. Port ranges can be specified using the colon ":" modifier. For
example, to monitor all ports upon which the X Windows service may run
(generally 6000 through 6010), the port range could be specified with the colon
modifier as shown in Figure 6.

Figure 6 - An example of port ranges
---------------------------------------------------------------------------
alert tcp any any -> 10.1.1.0/24 6000:6010 (msg: "X traffic";)
---------------------------------------------------------------------------

Both ports and IP addresses can be modified to match by exception with
the bang "!" operator, which would be useful in the rule described in Figure 7
to detect X Windows traffic from sources outside of the network.

Figure 7 - Matching by exception on the source IP address
---------------------------------------------------------------------------
alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 6000:6010 (msg: "X traffic";)
---------------------------------------------------------------------------

This rule would generate an alert for all traffic originating outside of the
host network that was bound for internal X Windows service ports.

Snort version 1.2.1 has fourteen option fields available:

1. content: Search the packet payload for the a specified pattern.

2. flags: Test the TCP flags for specified settings.

3. ttl: Check the IP header's time-to-live (TTL) field.

4. itype: Match on the ICMP type field.

5. icode: Match on the ICMP code field.

6. minfrag: Set the threshold value for IP fragment size.

7. id: Test the IP header for the specified value.

8. ack: Look for a specific TCP header acknowledgement number.

9. seq: Log for a specific TCP header sequence number.

10. logto: Log packets matching the rule to the specified filename.

11. dsize: Match on the size of the packet payload.

12. offset: Modifier for the content option, sets the offset into the
packet payload to begin the content search.

13. depth: Modifier for the content option, sets the number of bytes
from the start position to search through.

14. msg: Sets the message to be sent when a packet generates an event.

These options may be combined in any manner to detect and classify
packets of interest. The rule options are processed using a logical AND
between them; all of the testing options in a rule must be true in order
for the rule to generate a "found" response and have the program perform the
rule action.

Rule Development

Snort is extremely useful for rapidly developing new Snort rules. The
clear and concise manner in which the data is displayed by the tool makes it
perfect for writing new rules. The general method for development consists of
getting the exploit of interest, such as a new buffer overflow, running the
exploit on a test network with Snort recording all traffic between the target
and attack hosts, and then analyzing the data for a unique signature and
condensing that signature into a rule. Figure 8 shows Snort's view of a
notional "IMAP buffer overflow" that has just come into widespread use by the
"script kiddie" community.

Figure 8 - Notional "IMAP buffer overflow" packet
--------------------------------------------------------------------------
052499-22:27:58.403313 192.168.1.4:1034 -> 192.168.1.3:143
TCP TTL:64 TOS:0x0 DF
***PA* Seq: 0x5295B44E Ack: 0x1B4F8970 Win: 0x7D78
90 90 90 90 90 90 90 90 90 90 90 90 90 90 EB 3B ...............;
5E 89 76 08 31 ED 31 C9 31 C0 88 6E 07 89 6E 0C ^.v.1.1.1..n..n.
B0 0B 89 F3 8D 6E 08 89 E9 8D 6E 0C 89 EA CD 80 .....n....n.....
31 DB 89 D8 40 CD 80 90 90 90 90 90 90 90 90 90 1...@...........
90 90 90 90 90 90 90 90 90 90 90 E8 C0 FF FF FF ................
2F 62 69 6E 2F 73 68 90 90 90 90 90 90 90 90 90 /bin/sh.........
---------------------------------------------------------------------------

The unique signature data in the application layer is the machine
code just prior to the /bin/sh text string, as well as the string itself.
Using this information, a new rule can be developed quickly, such as the one
defined in Figure 9.

Figure 9 - Alert rule for the new buffer overflow
---------------------------------------------------------------------------
alert tcp any any -> 192.168.1.0/24 143 (content:"|E8C0 FFFF FF|/bin/sh";
msg:"New IMAP Buffer Overflow detected!";)
---------------------------------------------------------------------------

The content field of the rule contains mixed plain text and hex
formatted bytecode, which is enclosed in pipes. At run-time, this data is
converted into its binary representation, as displayed in the decoded packet
dump in Figure 8, and then stored in an internal list of rules by Snort. Thus,
the rule contained in Figure 9 will raise an alarm any time a packet containing
the "fingerprint" of the new IMAP buffer overflow is detected.

Writing high performance pattern matching rules

The current rules system lends itself to high performance under
most conditions, but there are some general concepts that can be applied when
writing Snort rules to keep the processing speeds as high as possible.
Computationally, the content matching option is the most expensive process that
can be performed in the detection engine. Accordingly, it is performed after
all other rule tests. This fact can be used to advantage by specifying other
rule options in combination with the content option. For example, almost all
requests to web servers have their TCP PUSH and ACK flags set. Using this
knowledge, it is relatively easy to write a rule which will perform a simple
TCP flag test before running the far more computationally intensive pattern
match test.

Other options can be combined with the content rules to limit the
amount of data that must be searched. The offset and depth keywords were made
specifically to fulfill this function. Using these options, the area of the
packet payload to search for an exploit pattern can be localized. Care should
be taken to avoid limiting the search too severely. For example, many buffer
overflows use variable offsets to tune the size and placement of the exploit
machine code. A Snort rule that has been tuned too tightly to key on a
specific area of a packet's payload may overlook the real exploit that has been
shifted to a different area within the packet. On the other hand, web CGI
probes and attacks generally all take place at the beginning of the packet
within the first thirty to fifty bytes. This can be a great place to optimize
Snort content searching.

The actual search pattern used in the content rule is another area
where performance tuning may take place. Snort uses a Boyer-Moore [SEDG97]
algorithm to perform its pattern matching, which is one of the best algorithms
available for that task. It achieves its greatest efficiency in cases where
the pattern to match consists of non-repeating sets of unique bytes. For
example, the Intel x86 architecture uses the hex value 0x90 to indicate a NOP
in machine code. Buffer overflows generally use large regions of NOPs to pad
the actual exploit code and make the return jump calculations easier for the
exploit programmer. When specifying content match patterns, it is best to
avoid including any NOPs in the match pattern, which will otherwise cause the
Boyer-Moore routine to complete many partial matches before actually finding
the correct match pattern.

Advanced Snorting

Snort is a flexible tool with a wide variety of uses. It is intended
to be used in the most classic sense of a network intrusion detection system.
It examines network traffic against a set of rules, and alerts administrators
to suspicious network activity so that they may react appropriately. There are
many other areas where Snort can be useful as well.

Shoring up commercial IDS'

Snort can be used to fill holes in commercial vendor's network-based
intrusion detection tools, such as when a new attack makes its debut in the
hacker/cracker community and signature updates are slow to come from the
vendor. In this case, Snort may be used to characterize the new attack by
running it locally on a test network and determining it's signature. Once the
signature is written into a snort rule, the BPF command line filtering may be
used to limit the traffic that Snort analyzes to the service or protocol of
interest. Snort can be used as a very specialized detector for a single attack
or family of attacks in this mode.

The recent IRDP denial of service attack [IRDP99] revealed by the L0pht
provides a good example of this concept. The same day that the attack was
announced, Snort rules were made available by the user community and these
attacks were detectable.

Passive traps

Another application to which Snort is very well suited is as a Honeypot
monitor. Honeypots are programs or computers that are dedicated to the notion
of deceiving hostile parties interested in a network. Most honeypot systems,
for example Fred Cohen & Associates Deception Toolkit [DTK98], record their
data at the server level, with a fake "service", such as an FTP server actually
recording the data sent to it. The problem with that concept is that the
services doing the recording have to be started before they will record
anything. This means that events such as stealth port scans or binary data
streams will be missed or garbled on honeypots that don't perform packet level
monitoring. Another problem is that the data generated by such a system
will tend to be complex by its nature.

The data coming out of a honeypot requires a skilled analyst to properly
interpret the results. Snort can be a great help to the analyst/administrator
with its packet classification and automatic alerting functionality. With
these capabilities a honeypot can be erected as a stand alone intrusion
detection mechanism. It requires no other monitoring or maintenance because
Snort can be set to record and generate event notification on the first packet
that arrives at the honeypot.

Snort can be used to implement another concept that is being advocated
today; that of "passive traps" [MJR99]. A passive trap uses the "home field
advantage" that network administrators enjoy when securing their networks. One
aspect of this concept is that administrators know which services are
<B>not</B> available on their networks. Snort rules can be written that watch
for traffic headed for these non-existent services. Packets which are found to
be using these ports may be an indication of port scanning, backdoors, or other
hostile traffic. For example, a network that is not using TFTP can be
configured with Snort alert rules for all packets headed to or from any node on
the network bound for port 69. This can be a good method for detecting covert
communications channels such as Loki or backdoors like Back Orifice. Another
easy concept to implement to set up pass rules for all of the services known to
be running on a network and log inbound connections to other ports or port
ranges.

Shining some light on SHADOW

SHADOW is designed to be a cheap alternative to commercial NIDS. As an
aside, SHADOW was probably the first true lightweight intrusion detection
system. tcpdump is used as the sensor in these systems, which are configured
using often extensive BPF commands. All traffic that is not filtered out with
these BPF rules is collected into a single file that can become quite large
over extended periods of time. Once the data is collected by the sensor, it is
post-processed using a variety of external third party tools. There are some
limitations to this system, including a complete lack of real-time alerts and a
lack of good data classification tools to aid the analyst in identifying the
data produced by the sensor.

Snort uses the same BPF filter language rules as tcpdump, and can
be used as a complete replacement for tcpdump sensors in environments where
SHADOW is the IDS of choice. The advantages of using Snort as a replacement
sensor include real-time automatic traffic classification as it is collected
and real-time alerting. This allows security events to be detected and acted
upon by the administrative staff in a more timely manner and log file sizes to
be reduced significantly. At the same time, Snort can record the data it
collects to tcpdump formatted files so that the data generated by the system
can be post-processed for in depth analysis with existing tools that analysts
are comfortable using.

Focused monitoring

"Focused monitoring" is the concept of watching a single critical node
or service on a network for signs of hostile activity. For example, the
Sendmail [ALMN99] SMTP server has an extensive and well known list of
vulnerabilities and exploits. A single Snort sensor could be deployed with a
rule set that covers all known Sendmail attacks and would provide highly
focused monitoring of that specific traffic on the network. These rules could
even be extended to provide a running narrative of all of the commands and
responses into and out of SMTP servers on the defended network. This can make
the network security analysts job somewhat easier by letting the collection
engine (Snort) describe the normal flow of commands and responses as well as
the attacks.

Focused monitoring can be especially useful in instances where existing
NIDS provide inadequate coverage. For example, a set of rules that monitor SQL
database queries to a web or database server could be developed. This would
provide more complete coverage of CGI and ODBC SQL attacks and probes than any
commercial NIDS on the market today. This concept can be extended to any
network communications technology that is under represented by commercial NIDS.

Conclusions

Snort was designed to fulfill the requirements of a prototypical lightweight
network intrusion detection system. It has become a small, flexible, and
highly capable system that is in use around the world on both large and small
networks. It has attained its initial design goals and is a fully capable
alternative to commercial intrusion detection systems in places where it is
cost inefficient to install full featured commercial systems.

Availability and Requirements

Snort will run on any platform where libpcap will run. The current
version of Snort is 1.2.1, and libpcap is required to compile and run the
software. Snort is known to run on RedHat Linux 5.1/5.2/6.0, Debian Linux,
MkLinux, S/Linux, HP-UX, Solaris 2.5.1 - 2.7 (x86 and Sparc), x86
Free/Net/OpenBSD, M68k NetBSD, and MacOS X.

Information about snort may be acquired directly from the author's
web site at http://www.clark.net/~roesch/security.html

Snort may be downloaded from the author's web site at
http://www.clark.net/~roesch/snort-1.2.1.tar.gz

There is a slowly growing library of Snort rules available at
http://www.clark.net/~roesch/snort-lib

Acknowledgements

Snort originally used Mike Borella's ipgrab program as a development
template and example for how to properly code libpcap programs and packet
decoders. ipgrab can be found at http://www.borella.net. Mike's code is an
excellent starting point for any libpcap-based project.

Ron Gula of Network Security Wizards <http://www.securitywizards.com>
provided valuable advice on logging methodologies and some of the initial
program logic, as well as contributing example rules to the system.

Ken Williams <jkw@frey.rapidnet.com> has been fantastically
supportive throughout the development of Snort, providing encouragement and
ideas for additional features as well as providing a friendly forum for the
distribution of Snort.

The Snort user community has been especially enjoyable to work with,
providing bug reports, ideas for new development directions, and new rules for
the library since the program's initial release. Their support and enthusiasm
has kept this a vital and growing collaborative project far past what I had
imagined was possible!

References

[SHD98] SHADOW, Steven Northcutt et al, Naval Surface Warfare Center
Dahlgren Laboratory, 1998. <http://www.nswc.navy.mil/ISSEC/CID/>

[TCPD91] tcpdump, Van Jacobson, Craig Leres and Steven McCanne, Lawrence
Berkeley National Laboratory, 1991. <http://www-nrg.ee.lbl.gov/>

[PCAP94] libpcap, Van Jacobson, Craig Leres and Steven McCanne, Lawrence
Berkeley National Laboratory, 1994. <http://www-nrg.ee.lbl.gov/>

[DTK98] Deception Toolkit, Fred Cohen & Associates, 1998.
<http://all.net/dtk/dtk.html>

[GNU89] GNU General Public License, Richard Stallman, 1989.
<http://www.gnu.org/copyleft/gpl.txt>

[BPF93] The BSD Packet Filter: A New Architecture for User-level Packet
Capture, Steven McCanne, Van Jacobson, USENIX Technical Conference
Proceedings, 1993.

[ALE96] Smashing the Stack for Fun and Profit, Aleph1, Phrack #49, 1996.
<http://www.phrack.com>

[BTQ99] Bugtraq Mailing List, archives and vulnerability data base are
available at Security Focus.
<http://www.securityfocus.com>

[IISBT99] NT IIS Showcode ASP Vulnerability (Bugtraq ID #167),
Parcens/L0pht, May 1999.
<http://www.securityfocus.com>

[OSS98] The Cathedral and the Bazaar, Eric S. Raymond, 1998.
<http://www.tuxedo.org/~esr/writings/cathedral-bazaar/>

[FYD97] The Art of Port Scanning, Fyodor, Phrack #51, 1997.
<http://www.insecure.org/nmap/p51-11.txt>

[SWT92] Centralized System Monitoring With Swatch, Stephen E. Hansen and
E. Todd Atkins, USENIX Seventh Systems Administration Conference, 1993
<http://www.stanford.edu/~atkins/swatch/lisa93.html>

[SEDG97] Algorithms in C: Fundamentals, Data Structures, Sorting, Searching,
Robert Sedgewick, Addison-Wesely Publishing Company, 1997

[IRDP99] L0pht Security Advisory, Silicosis and Mudge, August 1999
<http://www.l0pht.com/advisories/rdp.txt>

[ALMN99] Sendmail, Eric Allman, 1999
<http://www.sendmail.com>

[PTA98] Insertion, Evasion, and Denial of Service: Eluding Network Intrusion
Detection, Thomas Ptacek and Timothy Newsham, Secure Networks Inc, 1998
<http://www.nai.com/services/support/whitepapers/security/IDSpaper.pdf>

[MJR99] Burglar Alarms for Detecting Intrusions, Marcus Ranum, NFR Inc, 1999
<http://www.blackhat.com/html/bh-usa-99/bh3-speakers.html>

Author Information

Martin Roesch is a Network Security Engineer with Stanford
Telecommunications Inc. He holds a B.S. in Computer Engineering from
Clarkson University. He has extensive experience with intrusion detection
systems and has developed several systems professionally. He was a primary
software engineer during the development of GTE Internetworking's Global
Network Infrastructure IDS, and designed and developed GTE's new commercial
honeypot/deception system "Sentinel". He is also a member of the
Trinux Linux Security Toolkit distribution development team. Snort is his
first Open Source Software project, and has been an excellent learning
experience for him. Contact him at <roesch@clark.net>.

Appendix A.

Sample NFR rule to detect web server CGI probes (n-code sample excerpted from
the L0pht's NFR IDS Modules web page at <http://www.l0pht.com/NFR>).

---------------------------------------------------------------------------
badweb_schema = library_schema:new( 1, ["time", "int",
"ip", "ip", "str"], scope());

# list of web servers to watch. List IP address of servers or a netmask
# that matches all. use 0.0.0.0:0.0.0.0 to match any server

da_web_servers = [ 0.0.0.0:0.0.0.0 ] ;

query_list = [ "/cgi-bin/nph-test-cgi?",
"/cgi-bin/test-cgi?",
"/cgi-bin/perl.exe?",
"/cgi-bin/phf?"
] ;

filter bweb tcp ( client, dport: 80 )
{
if (! ( tcp.connDst inside da_web_servers) )
return;
declare $blob inside tcp.connSym;
if ($blob == null)
$blob = tcp.blob;
else
$blob = cat ( $blob, tcp.blob );
while (1 == 1) {
$x = index( $blob, "\n" );
if ($x < 0) # break loop if no complete line yet
break;
$t=substr($blob,$x-1,1); # look for cr at end of line
if ($t == '\r')
$t=substr($blob,0,$x-1); # tear off line
else
$t=substr($blob,0,$x);

$counter=0;
foreach $y inside (query_list) {
$z = index( $blob, $y );
if ( $z >= 0) {
$counter=1;
# save the time, the connection hash, the client,
# the server, and the command to a histogram
record system.time, tcp.connHash, tcp.connSrc, tcp.connDst, $t to badweb_hist;

}
}
if ($counter)
break;
}
# keep us from getting flooded if there is no newline in the data
if (strlen($blob) > 4096)
$blob = "";

# save the blob for next pass
$blob = substr($blob, $x + 1);

}

badweb_hist = recorder ("bin/histogram packages/test/badweb.cfg",
"badweb_schema" );
---------------------------------------------------------------------------------

Snort rules to detect the same web CGI probes.
---------------------------------------------------------------------------------
alert tcp any any -> any 80 (msg:"CGI-nph-tst-cgi"; content:"cgi-bin/nph-test-cgi?"; flags: PA;)
alert tcp any any -> any 80 (msg:"CGI-test-cgi"; content:"cgi-bin/test-cgi?"; flags: PA;)
alert tcp any any -> any 80 (msg:"CGI-perl.exe"; content:"cgi-bin/perl.exe?"; flags: PA;)
alert tcp any any -> any 80 (msg:"CGI-phf"; content:"cgi-bin/phf?"; flags: PA;)
---------------------------------------------------------------------------------

人已赞赏
安全工具

<p>用_LanMan.</p><p>doc打败_PGP_.</p>

2020-2-6 3:26:57

安全工具

<p>lisapaper.ps公司.</p>

2020-2-6 3:26:59

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索