iptables conntrack

转载自https://www.idzn.cn/?post=206

 

 

-m conntrack --ctstate ESTABLISHED,RELATED -j ...
-m state --state ESTABLISHED,RELATED -j ... 

我们要对一条连接做处理,可以用以上两种match target来实现。

iptables是最常用的一种Linux主机防火墙,借助于netfilter优秀的性能和扩展,虽历经多年,但仍不落伍。OpenStack中安全组功能,floating IP的实现,以及fwaas的主流方案大多是依赖iptables而实现的。

与包过滤防火墙不同的是,iptables是一种状态防火墙,可以记录和跟踪数据流的状态。正是基于此,才会有以上优秀方案的落地。

从Linux2.6.15的内核版本后,iptables开始支持状态跟踪(conntrack),该功能依赖于netfilter的内核模块nf_conntrack。此后,iptables可以根据包的状态进行二次的过滤拦截和状态跟踪。它也是state/ctstate和nat的主要依赖模块。

状态跟踪
conntrack将数据流的状态信息以Hash表的形式储存在内存中,包括五元组信息以及超时时间等。这里说的状态跟踪并非是指状态协议(如TCP)中连接状态的跟踪,而是conntrack特有的与网络传输协议无关的状态的跟踪。

下面介绍一下conntrack中的状态分类以及在TCP和UDP这两种4层协议中,是如何进行状态跟踪的。

五种状态
conntrack共可以为连接标记五种状态,分别如下:

NEW:

新建连接请求的数据包,且该数据包没有和任何已有连接相关联。
判断的依据是conntrack当前“只看到一个方向数据包(UNREPLIED)”,没有回包。

ESTABLISHED:

该连接是某NEW状态连接的回包,也就是完成了连接的双向关联。

RELATED:

匹配那些属于helper模块定义的特殊协议的网络连接,该连接属于已经存在的一个ESTABLISHED连接的衍生连接。

简而言之,A连接已经是ESTABLISHED,而B连接如果与A连接相关,那么B连接就是RELATED。这部分不理解没有关系,也很难一句话说清,后面章节会用大量笔墨来阐明它。

INVALID:

匹配那些无法识别或没有任何状态的数据包。这可能是由于系统内存不足或收到不属于任何已知连接的ICMP错误消息,也就是垃圾包,一般情况下我们都会DROP此类状态的包。

UNTRACKED :

这是一种特殊状态,或者说并不是状态。它是管理员在raw表中,为连接设置NOTRACK规则后的状态。这样做,便于提高包过滤效率以及降低负载。

conntrack是一种状态跟踪和记录的机制,本身并不能过滤数据包,只是提供包过滤的依据。 有状态是一种过滤依据,无状态实际也是一种过滤依据。

因此,需要小心的是,设置了NOTRACK,不代表是放行,只是它的状态是UNTRACKED。所以如果想要对这种包放行或者处理,同样需要配置相应的规则。具体使用方法可以查看下面“设置NOTRACK”部分的内容。

TCP的状态跟踪
从TCP开始讨论的原因也是因为TCP本身是状态协议。TCP通过三次握手建立连接,分别是SYN,SYN/ACK和ACK,当完成之后连接成为ESTABLISHED状态。也就是说TCP完成ESTABLISHED的时候,C和S两端已经进行了三次交互。

对于iptables而言,每一次握手,都需要对连接过滤,如前面所说NEW和ESTABLISHED状态,分别指的是,当nf_conntrack第一次发现该连接的时候,会将其状态设置为NEW,当反方向也出现包的时候,即认为是ESTABLISHED。如下图,观察在TCP的三次握手过程(SYN,SYN/ACK,ACK)中,conntrack状态(NEW,ESTABLISHED)出现的时机。可以看到,第1次握手与第2次握手间是NEW,第2次握手之后就是ESTABLISHED。某种角度来说,可以认为两次握手对conntrack而言就已经完成了ESTABLISHED



讨论到这里,已经把本章节的两个主角(TCP和conntrack中的ESTABLISHED状态)请了出来,下面举个具体的例子,看下TCP状态的变化。

打开/proc/net/nf_conntrack,可以看到类似如下的内容。

先说下每行entry的意思,第1列是网络层协议名称;第2列是协议代号;第3列代表传输层协议名称;第4列是传输层协议代号,其中tcp是6,udp是17;第5列的117指的是TTL;第6列是TCP的状态;第7列是表示源目地址以及对应端口;第8列是表示是否收到回应包;第9列表示期望收到的回包的源目地址及端口。

ipv4   2   tcp      6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.7 sport=1031 dport=23 [UNREPLIED] src=192.168.1.7 dst=192.168.1.5 sport=23 dport=1031 use=1
1
第1次握手时(SYN),TCP的状态是SYN_SENT,且有 [UNREPLIED] 标记,意味着还没有收到回包。此时,连接是NEW的状态,这点很好理解。
接着往下看

ipv4   2   tcp      6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.7 sport=1031 dport=23 src=192.168.1.7 dst=192.168.1.5 sport=23 dport=1031 use=1
1
第2次握手时(SYN/ACK),TCP连接的状态为SYN_RECV,也就是说,kernel收到了回复(replay), 在初次握手时候的[UNREPLIED]的tag被去除。需要注意的是,此时conntrack已经是ESTABLISHED,再往下看

ipv4   2  tcp      6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.7 sport=1031 dport=23 src=192.168.1.7 dst=192.168.1.5 sport=23 dport=1031 [ASSURED] use=1
1
第3次握手时(ACK),TCP连接的状态变为ESTABLISHED,也就是说,Client发出了ACK的确认标记包,此时三次握手完毕,TCP连接建立。

TCP总结: 对Client而言,TCP状态与conntrack状态对比是SYN_SENT(NEW),SYN_RECV(ESTABLISHED),ESTABLISHED(ESTABLISHED);

配置iptables规则
对于Client是192.168.1.5:1031,Server是192.168.1.7:23。需求是Client可以主动连接Server,而反向主动的连接不可以。Client上防火墙规则如下:


#iptables  -A  INPUT  -s 192.168.1.7  -p tcp --dport 1031  --sport 23  -m conntrack  --ctstate ESTABLISHED  -j ACCEPT


#iptables  -A  OUTPUT  -d 192.168.1.7  -p tcp --sport 1031  --dport 23  -m conntrack  --ctstate NEW,ESTABLISHED  -j ACCEPT

1
2
3
4
5
6
在这里顺便提及一下-m conntrack --ctstate与-m state --state的关系。
官方给的说法是这样:

The conntrack match is an extended version of the state match, which makes it possible to match packets in a much more granular way. It let’s you look at information directly available in the connection tracking system, without any “frontend” systems, such as in the state match.

大意是ctstate是state的扩展版本(内核版本>=2.5开始支持),包括状态参数也是基本相同,不用过多纠结,不过既然出了新的写法,个人还是推荐新的写法和规则。

UDP的状态跟踪
UDP是无状态的传输协议,不需要三次握手也没有SYN和ACK等各种标签和状态。虽然没有三次握手的概念,但是我们还是来看三次连接的状态记录。

如下图,观察在UDP连接过程中,conntrack状态(NEW,ESTABLISHED)出现的时机。可以看到,第1次连接与第2次连接间是NEW的状态,第2次连接之后就是ESTABLISHED。对UDP而言,也可以认为两次握手对conntrack而言就已经完成了ESTABLISHED



ipv4   2   udp      17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 use=1
1
首先可以看到的是UDP没有SYN_SENT这种TCP特有的状态标签,但是有 [UNREPLIED] 的标识,说明这个包是初次发出的包,还没有收到回应。此时conntrack中对应的状态是NEW,接着往下看。

ipv4   2   udp      17 170 src=192.168.1.2 dst=192.168.1.5 sport=137  dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 [ASSURED] use=1
1
同样还是没有标识,但是 [UNREPLIED] 变成了 [ASSURED] ,表明已经收到了回包,且连接建立完成。另外TTL变成了170,这时由于在该连接状态下,默认的TTL是180,而第一次连接时默认值是30。此时conntrack中定义的状态是ESTABLISHED。接着往下看

ipv4   2   udp      17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 dport=1025 [ASSURED] use=1
1
Client发出第3次包之后,可以发现TTL变为了175,说明TTL更新了,也同时说明第二次和第三次中包的状态或者说标签是一致的,所以TTL默认值才会相同。

UDP总结: 对Client而言,UDP过程与conntrack状态对比是,第一次连接(NEW),第二次连接(ESTABLISHED);

配置iptables规则
对于Client是192.168.1.5:1031,Server是192.168.1.7:23。需求是Client可以主动连接Server,而反向主动的连接不可以。Client上iptables规则如下:

#Client
#iptables  -A  INPUT  -s 192.168.1.7  -p udp --dport 1031  --sport 23  -m conntrack  --ctstate ESTABLISHED  -j ACCEPT


#iptables  -A  OUTPUT  -d 192.168.1.7  -p udp --sport 1031  --dport 23  -m conntrack  --ctstate NEW,ESTABLISHED  -j ACCEPT

1
2
3
4
5
6
回头再看
通过对以上知识的整理,iptables的状态跟踪(conntrack)思想若隐若现。

网络防火墙更关心的“进”和“出”,他有自己的考虑和规则,至于进出的包依循的是什么,他并不关心。

当连接初次出现的时候,该连接就是NEW,当出现了对应的反向连接的时候,那么该连接就是ESTABLISHED。看起来有点像UDP,是不是?

至于为什么会设计成这种模式,可能是考虑到防火墙只是涉及进出两个方向,而两次握手已经可以代表两次的方向,也可能考虑到对UDP以及ICMP的兼容等问题,在这就不去深入讨论了。

posted @ 2020-06-12 00:13  扫驴  阅读(7544)  评论(2编辑  收藏  举报