iptables的状态检测机制Unix系统

iptables的状态检测机制Unix系统（精选2篇）

iptables的状态检测机制Unix系统 第1篇

1.什么是状态检测 每个 网络 连接包括以下信息：源地址、目的地址、源端口和目的端口，叫作套接字对(socket pairs);协议类型、连接状态(TCP协议)和超时时间等，防火墙把这些信息叫作状态(stateful)，能够检测每个连接状态的防火墙叫作状态包过滤防火墙。它

1.什么是状态检测每个网络连接包括以下信息：源地址、目的地址、源端口和目的端口，叫作套接字对(socket pairs);协议类型、连接状态(TCP协议)和超时时间等。防火墙把这些信息叫作状态(stateful)，能够检测每个连接状态的防火墙叫作状态包过滤防火墙。它除了能够完成简单包过滤防火墙的包过滤工作外，还在自己的内存中维护一个跟踪连接状态的表，比简单包过滤防火墙具有更大的安全性。

1.什么是状态检测

2.iptables的状态检测是如何工作的?

2.1.iptables概述

2.2.UDP连接

2.3.TCP连接

2.3.1.连接建立过程中状态表的变化

2.3.2.透视状态表

2.3.3.超时

2.3.4.连接的中断

2.4.ICMP

3.FTP协议的状态检测

每个网络连接包括以下信息：源地址、目的地址、源端口和目的端口，叫作套接字对(socket pairs);协议类型、连接状态(TCP协议)和超时时间等。防火墙把这些信息叫作状态(stateful)，能够检测每个连接状态的防火墙叫作状态包过滤防火墙。它除了能够完成简单包过滤防火墙的包过滤工作外，还在自己的内存中维护一个跟踪连接状态的表，比简单包过滤防火墙具有更大的安全性。

iptables中的状态检测功能是由state选项来实现的。对这个选项，在iptables的手册页中有以下描述：

state

这个模块能够跟踪分组的连接状态(即状态检测)。

--state state

这里，state是一个用逗号分割的列表，表示要匹配的连接状态。有效的状态选项包括：INVAILD，表示分组对应的连接是未知的;ESTABLISHED，表示分组对应的连接已经进行了双向的分组传输，也就是说连接已经建立;NEW，表示这个分组需要发起一个连接，或者说，分组对应的连接在两个方向上都没有进行过分组传输;RELATED，表示分组要发起一个新的连接，但是这个连接和一个现有的连接有关，例如：FTP的数据传输连接和控制连接之间就是RELATED关系。

对于本地产生分组，在PREROUTING或者OUTPUT链中都可以对连接的状态进行跟踪。在进行状态检测之前，需要重组分组的分片。这就是为什么在iptables中不再使用ipchains的ip_always_defrag开关。

UDP和TCP连接的状态表由/proc/net/ip_conntrack进行维护。稍后我们再介绍它的内容。

状态表能够保存的最大连接数保存在/proc/sys/net/ipv4/ip_conntrack_max中。它取决于硬件的物理内存。

2.iptables的状态检测是如何工作的?2.1.iptables概述

在讨论iptables状态检测之前，我们先大体看一下整个netfilter框架。如果要在两个网络接口之间转发一个分组，这个分组将以以下的顺序接收规则链的检查：

PREROUTING链

如果必要对这个分组进行目的网络地址转换(DNAT)和mangle处理。同时，iptables的状态检测机制将重组分组，并且以以下某种方式跟踪其状态：

分组是否匹配状态表中的一个已经实现(ESTABLISHED)的连接。

它是否是和状态表中某个UDP/TCP连接相关(RELATED)的一个ICMP分组。

这个分组是否要发起一个新(NEW)的连接。

如果分组和任何连接无关，就被认为是无效(INVALID)的。

FORWARD链

把分组的状态和过滤表中的规则进行匹配，如果分组与所有的规则都无法匹配，就使用默认的策略进行处理。

POSTROUTING链

如果有必要，就对分组进行源网络地址转换(SNAT)，

注意：所有的分组都必须和过滤表的规则进行比较。如果你修改了规则，要拒绝所有的网络流量，那么即使分组的状态匹配状态表中的一个ESTABLISHED条目，也将被拒绝。

下面，我们对UDP、TCP和ICMP三个协议分别进行分析。

2.2.UDP连接

UDP(用户数据包协议)是一种无状态协议，以为这个协议没有序列号。不过，这并不意味着我们不能跟踪UDP连接。虽然没有序列号，但是我们还可以使用其它的一些信息跟踪UDP连接的状态。下面是状态表中关于UDP连接的条目：

udp 17 19 src=192.168.1.2 dst=192.168.1.50 sport=1032 dport=53 [UNREPLIED] src=192.168.1.50 dst=192.168.1.2 sport=53 dport=1032 use=1

这个状态表项只有在iptables过滤规则允许建立新的连接时，才能建立。以下的规则可以产生这类状态表项，这两条规则只允许向外的UDP连接：

iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -P udp -m state --state NEW,ESTABLISHED -j ACCEPT

上面的状态表项包含如下信息：

连接的协议是UDP(IP协议号17)。

这个状态表项还有19秒中就超时。

发起连接方向上的源、目的地址和源、目的端口。

应答方向上的源、目的地址和源、目的端口。这个连接使用UNREPLIED标记，表示还没有收到应答。

UDP连接的超时时间在/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c文件中设置，如果改变了这个值，需要重新编译Linux内核源代码才能生效。下面是UDP连接超时时间的相关的源代码：

#define UDP_TIMEOUT (30*HZ)

#define UDP_STREAM_TIMEOUT (180*HZ)

一个UDP请求等待应答的时间是30*HZ(这个值一般是30秒)。在上面的例子中，等待的时间已经消耗了11秒，还剩余19秒，如果在这段时间之内没有收到应答分组，这个表项就会被删除。一旦收到了应答，这个值就被重置为30，UNREPLIED标志也被删除。这个表项编程如下形式：

udp 17 28 src=192.168.1.2 dst=192.168.1.50 sport=1032 dport=53 src=192.168.1.50 dst=192.168.1.2 sport=53 dport=1032 use=1

如果在这一对源、目的地址和源、目的端口上，发生了多个请求和应答，这个表项就作为一个数据流表项，它的超时时间是180秒。这种情况下，这个表项就变成如下形式：

udp 17 177 src=192.168.1.2 dst=192.168.1.50 sport=1032 dport=53 src=192.168.1.50 dst=192.168.1.2 sport=53 dport=1032 [ASSURED] use=1

这时我们看到这个表项使用ASSURED标志。一旦连接表项使用ASSURED标志，那么即使在网络负沉重的情况下，也不会被丢弃。如果状态表已经饱和，当新的连接到达时，使用UNREPLIED标志的表项会受被丢弃。

2.3.TCP连接

一个TCP连接是通过三次握手的方式完成的。首先，客户程序发出一个同步请求(发出一个SYN分组);接着，服务器端回应一个SYN|ACK分组;最后返回一个ACK分组，连接完成。整个过程如下所示：

Client Server

SYN --->

<--- SYN+ACK

ACK --->

<--- ACK

ACK --->

.........

.........

SYN和ACK是由TCP分组头的标志决定的。在每个TCP分组头还有32位的序列号和应答号用于跟踪会话。

为了跟踪一个TCP连接的状态，你需要使用下面这样的规则：

iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

2.3.1.连接建立过程中状态表的变化

下面，我们详细讨论在连接建立的每个阶段中，状态表发生的变化：

一旦一个初始SYN分组进入OUTPUT链，并且输出规则允许这个分组建立一个新的连接，状态表的相关表项将如下所示：

cp 6 119 SYN_SENT src=140.208.5.62 dst=207.46.230.218 sport=1311 dport=80 [UNREPLIED] src=207.46.230.218 dst=140.208.5.62 sport=80 dport=1311 use=1

其中，TCP连接状态是SYN_SENT，连接被标记为UNREPLIED。

现在，我们等待SYN+ACK分组的响应。一旦得到响应，这个TCP连接表项就变为：

tcp 6 57 SYN_RECV src=140.208.5.62 dst=207.46.230.218 sport=1311 dport=80 src=207.46.230.218 dst=140.208.5.62 sport=80 dport=1311 use=1

连接的状态变为SYN_RECV，UNREPLIED标志被清除。

现在我们需要等待完成握手的ACK分组。ACK分组到达后，我们首先对其序列号进行一些检查，如果正确，就把这个连接的状态变为ESTABLISHED，并且使用ASSURED标记这个连接，

这时，这个连接的状态如下所示：

cp 6 431995 ESTABLISHED src=140.208.5.62 dst=207.46.230.218 sport=1311 dport=80 src=207.46.230.218 dst=140.208.5.62 sport=80 dport=1311 [ASSURED] use=1

2.3.2.透视状态表

上面，我们涉及了很多CP连接的状态。现在，我们分析一下TCP连接的状态检测。实际上，状态表只知道NEW、ESTABLISHED、RELATED和INVALID。

要注意：状态检测的状态不等于TCP状态。当一个SYN分组的响应SYN+ACK分组到达，Netfilter的状态检测模块就会认为连接已经建立。但是，这时还没有完成三次握手，因此TCP连接还没有建立。

另外，包过滤规则不能删除状态表中的表项，只有连接超时，对应的状态表项才会被删除。ACK分组能够建立一个NEW状态表项。向防火墙之后一台并不存在主机发送ACK分组，并不会返回RST分组，可以证明这个结论。因此，你需要使用以下的规则明确新的TCP连接应该是SYN分组建立的：

iptables -A INPUT -p tcp !--syn -m state --state NEW -j DROP

这样可以阻止空会话的继续进行。

2.3.3.超时

所谓状态表项的超时值是指每个表项存在的最大时间，这些超时值的大小在/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c文件中设置。以下是相关的代码：

static unsigned long tcp_timeouts[]

= { 30MINS, /* TCP_CONNTRACK_NONE, */

5 DAYS, /* TCP_CONNTRACK_ESTABLISHED, */

2 MINS, /* TCP_CONNTRACK_SYN_SENT, */

60 SECS, /* TCP_CONNTRACK_SYN_RECV, */

2 MINS, /* TCP_CONNTRACK_FIN_WAIT, */

2 MINS, /* TCP_CONNTRACK_TIME_WAIT, */

10 SECS, /* TCP_CONNTRACK_CLOSE, */

60 SECS, /* TCP_CONNTRACK_CLOSE_WAIT, */

30 SECS, /* TCP_CONNTRACK_LAST_ACK, */

2 MINS, /* TCP_CONNTRACK_LISTEN, */

};

2.3.4.连接的中断

关闭一个TCP连接可以有两种方式。第一种类似于建立TCP连接的三次握手。一旦一个TCP会话完成，要终止会话的一方首先发出一个FIN为1的分组。接收方TCP确认这个FIN分组，并同志自己这边的应用程序不要在接收数据了。这个过程可以如下所示：

Client Server

.........

.........

FIN+ACK --->

<--- ACK

<--- FIN+ACK

ACK --->

在这个过程之中或者之后，状态表的连接状态变为TIME_WAIT。在默认情况下，2分钟之后从状态表删除。

除此之外，还有其它关闭中断的方式。TCP会话的任何一方发出一个RST标志为1的分组，可以快速断开一个TCP连接。而且，RST分组不需要应答。在这种情况下，状态表项的状态变为CLOSE，10秒之后被删除。和http连接经常通过这种方式中断，如果一个连接很长时间没有请求了，服务器端就会发出一个RST分组中断连接。

2.4.ICMP

在iptables看来，只有四种ICMP分组，这些分组类型可以被归为NEW、ESTABLISHED两类：

ECHO请求(ping,8)和ECHO应答(pong,0)。

时间戳请求(13)和应答(14)。

信息请求(15)和应答(16)。

地址掩码请求(17)和应答(18)。

这些ICMP分组类型中，请求分组属于NEW，应答分组属于ESTABLISHED。而其它类型的ICMP分组不基于请求/应答方式，一律被归入RELATED。

我们先看一个简单的例子：

iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED, RELATED -j ACCEPT

iptables -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT

这链条规则进行如下的过滤：

一个ICMP echo请求是一个NEW连接。因此，允许ICMP echo请求通过OUTPUT链。

当对应的应答返回，此时连接的状态是ESTABLISED，因此允许通过INPUT链。而INPUT链没有NEW状态，因此不允许echo请求通过INPUT链。也就是说，这两条规则允许内部主机ping外部主机，而不允许外部主机ping内部主机。

一个重定向ICMP(5)分组不是基于请求/应答方式的，因此属于RELATED。INPUT和OUTPUT链都允许RELATED状态的连接，因此重定向(5)分组可以通过INPUT和OUTPUT链。

3.FTP协议的状态检测上面，我们比较详细地介绍了iptables的态检测机制。现在，我们以FTP状态检测为例介绍如何使用iptables进行连接状态检测。

首先，你需要加载ip_conntrack_ftp模块。使用如下规则就可以允许建立FTP控制连接(这里没有考虑IMCP问题):

iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLESED -j ACCEPT

iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISED -j ACCEPT

除了控制连接之外，FTP协议还需要一个数据通道，不过，数据连接可以通过主动和被动两种模式建立，我们需要分别讨论。

3.1.主动模式

在主动模式下，客户程序在控制通道上，使用PORT命令告诉FTP服务器自己这边的数据传输端口，然后FTP从20端口向这个端口发起一个连接。连接建立后，服务器端和客户端就可以使用这个连接传输数据了，例如：传诵的文件、ls等命令的结果等。因此，在主动模式下FTP数据传输通道是反向建立的，它从FTP服务器端向客户端发起。

在主动模式下，客户端使用的数据传输端口是不固定的，因此我们需要在规则中使用端口范围。由于客户端使用的端口都是大于1024的，这并不会降低系统的安全性。

在iptables中，有一个专门跟踪FTP状态的模块--ip_conntrack_ftp。这个模块能够识别出PORT命令，并从中提取端口号。这样，FTP数据传输连接就被归入RELATED状态，它和向外的FTP控制连接相关，因此我们不需要在INPUT链中使用NEW状态。下面的规则可以实现我们的意图：

iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISED,RELATED -j ACCEPT

iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISED -j ACCEPT

3.2.被动模式

和主动模式相反，在被动模式下，指定连接端口的PORT命令是服务器端发出的。FTP服务器通过PORT命令告诉客户端自己使用的FTP数据传输端口，然后等待客户端建立数据传输连接。在被动模式下，建立数据传输连接的方向和建立控制连接的方向是相同的。因此，被动模式具有比主动模式更好的安全性。

由于ip_conntrack_ftp模块能够从PORT命令提取端口，因此我们在OUTPUT链中也不必使用NEW状态，下面的规则可以实现对被动模式下的FTP状态检测：

iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT

综合以上的分析，我们可以得到FTP连接的状态检测规则，对于主动模式的FTP，需要下面的iptables规则：

iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLESED -j ACCEPT

iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISED -j ACCEPT

iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISED,RELATED -j ACCEPT

iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISED -j ACCEPT

对于被动模式的FTP连接，需要使用如下iptables规则

iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLESED -j ACCEPT

iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISED -j ACCEPT

iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT

本文中提到的状态检测，在iptables中实际叫作连接跟踪(Connection tracking)，出于自己的习惯，我在本文中一律改为状态检测:P

1.什么是状态检测

原文转自：www.ltesting.net

iptables的状态检测机制Unix系统 第2篇

随着网络技术和应用的快速发展, 网络安全问题日益成为关注的焦点。近年来, 针对网络攻击、网络入侵等安全问题产生了防火墙、入侵检测系统等多种网络安全技术。然而, 不同的安全技术主要解决网络中的某一安全问题, 它们各自为战, 不能互相进行信息交流[1]。

防火墙是一种访问控制安全技术, 主要是根据网络安全策略控制进出主机的网络流量, 阻断非法连接及访问。它的规则都事先设置, 对于实时的攻击无法实时调整策略, 它不能防范不经由防火墙的攻击, 不能防止感染了病毒的软件或文件的传输, 不能防止数据驱动式攻击。入侵检测系统通过对网络和系统记录的日志文件的分析来发现非法的入侵行为以及合法用户的滥用行为, 它对IP包的获取一般采用被动的基于包侦听的方式, 由于采用被动的方式, 即使检测到攻击, 也很难采取实时、有效的阻止或控制措施[2]。

因此, 通过联动机制把各种安全技术进行组合, 取长补短, 实现网络的全面安全保障。以入侵检测系统为中心的联动体系, 在提高入侵检测自身功能和性能的同时, 由其他技术完成入侵检测系统所缺乏的功能, 以适应网络安全整体化、立体化的要求。其主要有如下几种形式:与漏洞扫描系统的联动;与防病毒系统的联动;与防火墙的联动;与"蜜罐"系统的联动;与路由器、交换机的联动[3]。

本文设计了入侵检测系统和路由器及防火墙的联动系统, 在RedHat Linux9.0平台上, 采用Snort入侵检测系统, 实现了Cisco路由器的联动以及防火墙软件Iptables的联动功能。

2、联动系统设计

2.1 Snort入侵检测系统

Snort由Martin Roesch于1998年公开发表的, 是一个采用C语言编写的入侵检测系统, 具有截取网络数据报文, 进行网络数据实时分析、报警及日志的能力, 能够进行协议分析, 内容搜索/匹配, 能够用来检测各种攻击和探测, 并可以将报警信息写到syslog、指定的文件、UNIX套接字等。[4]

2.1.1 Snort工作机制

Snort将攻击事件定义为"规则", 并形成规则库。启动后, 完成初始化工作, 对命令行进行解释, 读入系统的规则数据库, 生成用于检测入侵的二维规则链表 (称为"规则树") , 然后进入循环抓包、进行解码封装为Packet结构、规则匹配过程, 判断是否包含攻击特征, 并做出响应。

2.1.2 Snort规则及其实现联动关键模块

(1) Snort规则。Snort是基于规则 (rule) 的IDS, 它在规则的基础上收集和关联数据包。规则文件是Snort的网络攻击知识库, 库中有了规则, Snort才能识别网络攻击。Snort使用的是简单的规则描述语言, 易于扩展。Snort规则划分为2个逻辑部分:规则头 (Rule Header) 和规则选项 (Rule Options) 。规则头定义了规则的行为、所匹配网络报文的协议、源地址、目标地址、网络掩码、源端口和目标端口信息。规则选项部分包含了所要显示给用户的警告信息以及用于确定是否触发规则响应行为而需检查的数据包区域位置信息。Snort规则语法的基本格式如下:

规则行为协议类型IP地址端口号-> (<-或<>) IP地址端口号 (规则选项) [5]

(2) 联动关键模块。检测模块:是NIDS的核心。Snort采用高层协议分析技术和灵活的插件形式来组织规则库, 即按照入侵行为的种类划分为相应的插件, 用户可以根据需要选取对应的插件进行检测。输出模块:Snort的输出模块是在版本1.6后引入的, 允许开发者扩展Snort的功能, 可以选择ASCII文本文件存储日志, 也可以选择存储到数据库中, 也可以使用IAP协议将信息传给管理器Manager或者使用XML的方式。

2.2 SnortSam联动框架

SnortSam[6]是开源社区的一个网络安全组织专门为Snort开发的一个实现与其他设备进行联动的程序框架, 通过它可以实现和目前大多数的防火墙以及Cisco路由器的联动功能。它分为逻辑上的两部分, 一个是嵌入Snort的一个输出插件, 另一个就是运行在于Snort发生联动的设备上或者附近的一个智能引擎, 其采用易于扩展的插件结构, 只要遵循统一的插件模型, 程序员可以自行设计与Snort联动的其他设备处理部分。

Snort输出插件负责与SnortSam的智能引擎进行通信, 当一条入侵信息触发了Snort的一条入侵规则时, 它能够及时的向主程序传送具体信息。SnortSam智能引擎接收到入侵信息时, 可以通过它自动生成一条阻断规则, 并在防火墙或路由器上实现, 在一定的时间间隔后, 取消阻断。Snort、SnortSam和Router的关系如图1所示。SnortSam与Snort之间采用C/S结构, 采用这种结构智能处理操作仅发生在联动方, 降低了与Snort的依赖性, 减少了Snort的负载, 提高了它的性能, 即增强了Snort对规则的匹配的核心处理能力, 而且一个Snort探测器可以同时向多个SnortSam智能引擎发送信息, 同时一个SnortSam智能引擎可以同时接受多个Snort探测器的信息, 所以可以不断进行联动系统的扩展, 建立一个更复杂的分布式的入侵检测联动系统。

3、系统工作原理

3.1 SnortSam的通信机制

3.1.1 SnortSam与Snort的通信原理。

SnortSam通过输出插件实现与Snort通信。由于对输出插件的扩展, 从而实现对规则的扩展, 使得规则中的新关键词能够被解析, 同时在规则匹配的时候, 通过Snort的输出插件向SnortSam发送相应的信息。在通信过程中, 引入TwoFish算法对通信信息进行加密和通过在SnortSam内存储的一个通过认证的Snort探测器列表来保证安全。这样在网络数据包触发Snort探测器上的相应规则时, Snort就按照配置文件中预设的IP地址向多个对应的SnortSam引擎发送面向连接的TCP加密包, 在SnortSan引擎上获得认证通过后该数据被解密, 进而向对应的防火墙或者Router对该IP地址发送阻断请求。

3.1.2 SnortSam与Cisco路由器的通信原理。

在联动过程中SnortSam和Cisco路由器的通信内容包括两个方面:一是SnortSam到Cisco路由器的验证过程, 二是SnortSam向Cisco路由器的阻断信息的传送。验证过程是在路由器上设置允许telnet或SSH通信的配置, 同时在SnortSam中有解析配置文件中的telnet或SSH验证信息的参数, 并向路由器发起连接请求, 其方式有telnet和SSH两种方式, 其中SSH是加密的安全连接方式。阻断信息的传送是在SnortSam和Cisco路由器的通信连接建立后进行, 有单条语句和整个访问控制列表文件传送的两种方式, 前者适合于少量的访问控制列表信息传送, 后者适合于大量的访问控制列表信息传送, 一般用文件传送 (tftp) 的方式。

3.1.3 SnortSam与Iptables的通信原理。

Iptables是Linux内核 (2.4.x版本) 集成的IP信息包过滤系统的组件, Iptables组件被称为用户空间 (User Space) , 可用于添加、编辑和除去在做信息包过滤决定时防火墙所遵循和组成的规则。SnortSam智能引擎在工作时与Iptables运行在用一台主机上, SnortSam直接调用Iptables即可[7]。

3.2 SnortSam的阻断机制

SnortSam采用的阻断机制是:首先对接受到的阻断请求进行必要的验证, 判断是否来至预设的受信任的Snort探测器;接着对这个请求数据包进行解码, 如果其中的密码或密钥等于SnortSam相匹配, 则SnortSam此时认定它是一个合法的阻断请求;然后SnortSam会从数据包中计算出触发Snort规则的那台主机的对应IP地址, 并在列表中进行查找该对应IP地址是否存在, 如不存在, 则查看Snort探测器请求的阻断时间是否应该被SnortSam默认的阻断时间覆盖;最后向对应的防火墙或路由器发送阻断请求, 这种阻断可以通过发送数据包或通过运行在防火墙上的执行程序完成实现。

一旦这些阻断操作运行起来, SnortSam会监视这条阻断信息的IP地址和阻断时间, 如果在一定的时间间隔内阻断请求的数量超过了预设的阀值, SnortSam会自动地对最后请求的一些阻断请求进行忽略处理, 并进入休眠模式直到阻断请求恢复到信任的水平为止[8]。

4、系统实现

4.1 系统拓扑结构

根据联动系统的设计和功能实现的需要, 搭建了联动系统实验环境平台, 见图2所示。图中Snort1监测全网, 主要实现和路由器的联动, 联动组件为SnortSam1;Snort2监测内网服务器区, 主要实现和Iptables的联动, 联动组件为SnortSam2。

联动系统工作网络环境:IDS1 (Snort1) 、IDS2 (Snort2) 、路由器 (1台) (F0/0和F0/1) 、服务器 (2台:web和ftp) 、主机 (5台) 、交换机 (2台) 、移动用户 (假设黑客) 。

4.2测试用例与结果

4.1.1测试用例。

系统采用典型的网络扫描进行测试, 使用X-Scan和NMAP (Network Mapper) 。X-Scan是由glacier主持开发一个Windows的网络扫描器图形化软件, 采用多线程方式对指定IP地址段 (或单机) 进行安全漏洞检测, 支持插件功能。NMAP是Linux环境下的网络扫描和嗅探工具包, 支持十几种扫描技术, 其中很多独特的技术目的是尽可能地绕过一些安全防护设备, 保护自己。

实际测试时, X-Scan对Snort监控的网络进行加载扫描, 而NMAP对Snort监控的网络进行扫描三种特殊形式的扫描, 分别为FIN、XMAS、NULL。使用路由器实现联动, 扫描方位于Router的FastEthernet0/1, 其上安装了X-Scan、NMAP和网络捕包工具, 扫描对象位于Router的FastEthernet0/0后的网络。使用Iptables实现联动时, 扫描方位于安装Iptables主机的eth0口侧的主机进行测试, 扫描对象为eth1口侧的服务器。测试时需注意的是, 通过开启攻击方的网络捕包工具进行捕包分析, 获得联动开启前后的扫描结果, 并在每次测试完毕, 清除路由器中的访问控制条目。

4.2.2 测试结果。

表1是X-Scan正常操作时的数据包信息片断, 表2是X-Scan被路由器阻断时的数据包信息片断;表3是NMAP的FIN扫描正常操作时的数据包信息片断, 表4是NMAP的FIN扫描被路由器阻断时的数据包信息片断。通过对攻击方网络数据流量的分析, 在这些特殊的网络数据包触发了Snort的规则集后, 会通过输出插件向SnortSam报告, 从而在Router上产生阻断的访问控制条目, 当这样的数据包再继续出现时, 会被这些访问控制列表或Iptables规则过滤, 从而达到联动的目的。

5、结语

入侵检测技术和路由器与Iptables的访问控制技术相结合, 实现联动, 解决了传统入侵检测不能进行主动控制的问题, 同时网络入侵检测的结果也为网络的安全管理策略提供了依据, 提高了路由器和Iptables防火墙的智能访问控制能力。入侵检测系统与其他网络设计的联动、联动系统阻断方式的多样化、联动策略的优化和降低误报和漏报率都是联动技术进一步需要研究的内容。

参考文献

[1]鲜继清, 谭丹, 陈辉.局域网中个人防火墙与入侵检测系统联运技术研究.计算机应用研究.2006, 5:105-106.

[2]王刚, 孙济洲, 崔康, 等.一种通用入侵检测与防火墙联运系统.微处理机.2008, 3:85-87, 90.

[3]谈文蓉, 谈进, 刘明志.联动防御机制的设计与实施.西南民族大学学报.2004, 12:.

[4]丁志芳, 李晓秋.Snort规则的分析.三峡大学学报.2002, 10:38-42.

[5]Snort 2.x数据区搜索规则选项的改进.http://www.xfocus.net/arti-cles/200509/824.html.

[6]SnortSam related.http://www.SnortSam.net/documentation.html.

[7]SnortSam and Portscanning Detection.http://kb.linuxnetworkcare.com/node/16.