共计 5363 个字符，预计需要花费 14 分钟才能阅读完成。
这篇文章给大家介绍 iptables 的状态机制如何分析，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
1.6 状态机制
状态机制是 iptables 中较为特殊的一部分，这也是 iptables 和比较老的 ipchains 的一个比较大的区别之一，运行状态机制（连接跟踪）的防火墙称作带有状态机制的防火墙，以下简称为状态防火墙。状态防火墙比非状态防火墙要安全，因为它允许我们编写更严密的规则。
在 iptables 上一共有四种状态，分别被称为 NEW、ESTABLISHED、INVALID、RELATED，这四种状态对于 TCP、UDP、ICMP 三种协议均有效。下面，我们来分别阐述四种状态的特性。
NEW：NEW 说明这个包是我们看到的 *** 个包。意思就是，这是 conntrack 模块看到的某个连接的 *** 个包，它即将被匹配了。比如，我们看到一个 SYN 包，是我们所留意的连接的 *** 个包，就要匹配它。
ESTABLISHED：ESTABLISHED 已经注意到两个方向上的数据传输，而且会继续匹配这个连接的包。处于 ESTABLISHED 状态的连接是非常容易理解的。只要发送并接到应答，连接就是 ESTABLISHED 的了。一个连接要从 NEW 变为 ESTABLISHED，只需要接到应答包即可，不管这个包是发往防火墙的，还是要由防火墙转发的。ICMP 的错误和重定向等信息包也被看作是 ESTABLISHED，只要它们是我们所发出的信息的应答。
RELATED：RELATED 是个比较麻烦的状态。当一个连接和某个已处于 ESTABLISHED 状态的连接有关系时，就被认为是 RELATED 的了。换句话说，一个连接要想是 RELATED 的，首先要有一个 ESTABLISHED 的连接。这个 ESTABLISHED 连接再产生一个主连接之外的连接，这个新的连接就是 RELATED 的了，当然前提是 conntrack 模块要能理解 RELATED。ftp 是个很好的例子，FTP-data 连接就是和 FTP-control 有关联的，如果没有在 iptables 的策略中配置 RELATED 状态，FTP-data 的连接是无法正确建立的，还有其他的例子，比如，通过 IRC 的 DCC 连接。有了这个状态，ICMP 应答、FTP 传输、DCC 等才能穿过防火墙正常工作。注意，大部分还有一些 UDP 协议都依赖这个机制。这些协议是很复杂的，它们把连接信息放在数据包里，并且要求这些信息能被正确理解。
INVALID：INVALID 说明数据包不能被识别属于哪个连接或没有任何状态。有几个原因可以产生这种情况，比如，内存溢出，收到不知属于哪个连接的 ICMP 错误信息。一般地，我们 DROP 这个状态的任何东西，因为防火墙认为这是不安全的东西。
每个状态相对于不同的第四层协议来讲，稍微有些区别，对于 TCP 协议来说，当防火墙收到 *** 个数据包，也就是 SYN 报文时，将该会话标记为 NEW 状态，在系统的 /proc/net/ 目录下，可以查阅文件 ip_conntrack，这是在内存空间里存放防火墙当前状态表的临时文件，对于 NEW 状态的记录如下：
tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1从上面的记录可以看出，SYN_SENT 状态被设置了，这说明连接已经发出一个 SYN 包，但应答还没发送过来，这可从 [UNREPLIED] 标志看出，当服务器端回应了 SYN/ACK 包后，状态表改写为：
tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1现在我们已经收到了相应的 SYN/ACK 包，状态也变为 SYN_RECV，这说明最初发出的 SYN 包已正确传输，并且 SYN/ACK 包也到达了防火墙。这就意味着在连接的两方都有数据传输，因此可以认为两个方向都有相应的回应。
接下来，TCP 三次握手的随后一个报文 ACK 包也到达了防火墙，防火墙上的状态表变成了：
tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1现在，我们来看看 UDP 协议的状态描述方法，从协议本身的特性来看，UDP 连接是无状态的，因为它没有任何的连接建立和关闭过程。以某个顺序收到的两个数据包是无法确定它们的发出顺序的。但内核仍然可以对 UDP 连接设置状态。我们来看看是如何跟踪 UDP 连接的，以及在核心目录 /proc/net/ip_conntrack 的相关记录。
当 *** 个 UDP 的数据包到达防火墙后，防火墙在他的状态表中留下了这样的记录：
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=1UNREPLIED 代表这是一个状态为 NEW 的数据包，当这条连接的回应数据包到达防火墙后，防火墙立即将修改这条状态记录：
udp 17 160 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 use=1在这条新的状态记录中，UNREPLIED 被删除了，这代表现在防火墙已经建立了一条 UDP 协议的会话，但这里并没有象 TCP 协议那样显示 ESTABLISHED 标记，这是 TCP 的状态记录和 UDP 的状态记录稍微不同的一个地方，当然，还有一个地方需要注意，在测试中，还需要有一些数据包经过，防火墙才会将状态记录改写成：
udp 17 179 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=1ASSURED 状态表示当前有数据在进行传输，表面当前连接的状态是 ACTIVE 的。如果，在这个状态下数据停止了传输，则这条记录会有一个计时器，也就是记录中的第三个字段，上面这条记录的第三个字段是 179，代表当前的 ASSURED 状态还能够保持 179 秒，如果还有新的数据包经过，那么计时器会被重新设置成缺省的 180 秒，如果在 180 秒内都没有流量，那么这条状态记录就会从状态表中被删除。
***，我们在来看看 Linux kernel 是如何标示 ICMP 协议的状态的，ICMP 也是一种无状态协议，它只是用来控制而不是建立连接。ICMP 包有很多类型，但只有四种类型有应答包，它们是回显请求和应答（Echo request and reply），时间戳请求和应答（Timestamp request and reply），信息请求和应答（Information request and reply），还有地址掩码请求和应答（Address mask request and reply），这些包有两种状态，NEW 和 ESTABLISHED。时间戳请求和信息请求已经废除不用了，回显请求还是常用的，比如 ping 命令就用的到，地址掩码请求不太常用，但是可能有时很有用并且值得使用。看看下面的图，就可以大致了解 ICMP 连接的 NEW 和 ESTABLISHED 状态了。
如图所示，主机向目标发送一个回显请求，防火墙就认为这个包处于 NEW 状态。目标回应一个回显应答，防火墙就认为包处于 ESTABLISHED 了。当回显请求被发送时，ip_conntrack 里就有这样的记录了：
icmp 1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 type=0 code=0 id=33029 use=1可以看到，ICMP 的记录和 TCP、UDP 的有点区别，协议名称、超时时间和源、目地址都一样，不同之处在于没有了端口，而新增了三个新的字段：type，code 和 id。字段 type 说明 ICMP 的类型。code 说明 ICMP 的代码，这些代码在附录 ICMP 类型里有说明。id 是 ICMP 包的 ID。每个 ICMP 包被发送时都被分配一个 ID，接受方把同样的 ID 分配给应答包，这样发送方能认出是哪个请求的应答。
[UNREPLIED] 的含义和前面一样，说明数的传输只发生在一个方向上，也就是说未收到应答。再往后，是应答包的源、目地址，还有相应的三个新字段，要注意的是 type 和 code 是随着应答包的不同而变化的，id 和请求包的一样。和前面一样，应答包被认为是 ESTABLISHED 的。然而，在应答包之后，这个 ICMP 连接就不再有数据传输了。所以，一旦应答包穿过防火墙，ICMP 的连接跟踪记录就被销毁了。因此，要想在 /proc/ip_conntrack 文件中抓到 ICMP 协议的状态记录实在不是一件容易的事。您可以用如下的命令来尝试获取这些记录：
#cat /proc/net/ip_conntrack | grep icmp如果没有输出，那么就不停的重复这个命令，直到发现 icmp 的记录为止。
以上各种情况，请求被认为 NEW，应答是 ESTABLISHED。换句话说，就是当防火墙看到一个请求包时，就认为连接处于 NEW 状态，当有应答时，就是 ESTABLISHED 状态。
—————————
state 匹配：state 匹配在防火墙配置过程中非常重要的，如果没有 state 的配置，那么需要配置双向的规则才能满足通讯的需要，但防火墙既然有状态检测功能，我们为什么不好好使用它呢？
–state：state 的状态有四种，指定要匹配包的的状态，当前有 4 种状态可用：INVALID，ESTABLISHED，NEW 和 RELATED。四种数据包的状态我们在前面已经做了详细的描述本节我们只进行 state 的用法描述，如下例所示：
#iptables ndash;A FORWARD ndash;p tcp ndash;m state --state RELATED,ESTABLISHED ndash;j ACCEPT本例表明凡是数据包状态为“RELATED”、“ESTABLISHED”的 tcp 包允许通过防火墙。在一般情况下，基于状态的策略都是配置在每一条 chain 的最前面，因为当包被匹配到以后，就能够直接被处理了，这是一种比较高效的配置方法。关键字 ESTABLISHED 比较容易理解，即匹配状态为“已经建立连接”的数据包，那么怎么理解“RELATED”呢，RELATED 表示不属于已经建立的那条连接，但和那条连接有关，比如 ftp，ftp 在建立连接的过程中会首先建立一条 ftp-control 连接用以传输指令等，真正传输数据的是一条叫做 ftp-data 的连接，而传输数据的连接是和传输控制信号的连接相关的，因此“RELATED”是用于类似这些特殊服务的。在正常情况下，对于每一种协议：TCP、UDP、ICMP 都可以单独的配置状态策略，但一种比较简单高效的做法是：
#iptables ndash;A INPUT ndash;p all ndash;m state --state RELATED,ESTABLISHED ndash;j ACCEPTmultiport: 这个匹配选项为我们解决了如何在一条策略种匹配那些端口不连续的服务，在一般情况下，一个公司或企业的安全策略是允许内部网络使用有限的 Internet 服务，如收发电子邮件、上网浏览网页、msn 聊天等，看看下面的例子：
#iptables ndash;A FORWARD ndash;i eth0 ndash;p tcp ndash;m multiport --dports 25,80,110,443,1863 ndash;j ACCEPT
#iptables ndash;A FORWARD ndash;i eth0 ndash;p udp --dport 53 ndash;j ACCEPT仅仅两条命令就解决了内部用户上网收发 E_mail、浏览网页、使用 msn 聊天等需求，怎么样，就这么简单~
关于 iptables 的状态机制如何分析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
