Question

测试环境是：

在VirtualBox上安装了2个操作系统ubuntu server 10.04

iptables v1.4.4

加载了ip_conntrack模块

这些是我的测试规则：

    $IPTABLES -A INPUT -p TCP -m state --state NEW -j LOG --log-prefix "[-IPT-]NEW:"
    $IPTABLES -A INPUT -p TCP -m state --state ESTABLISHED -j LOG --log-prefix "[-IPT-]ESTABLISHED:"
    $IPTABLES -A INPUT -p TCP -m state --state RELATED -j LOG --log-prefix "[-IPT-]RELATED:"
    $IPTABLES -A INPUT -p TCP -m state --state INVALID -j LOG --log-prefix "[-IPT-]INVALID:"

使用

hping3 -c 1 192.168.0.1 -p 80 [flags combination]

我明白了：

no flag     INVALID
syn         NEW
ack         NEW
rst         INVALID
fin         INVALID
syn ack INVALID
syn rst INVALID
syn fin INVALID
ack rst INVALID
ack fin INVALID
rst fin INVALID
syn ack rst INVALID
syn rst fin INVALID
ack rst fin INVALID
syn ack rst fin INVALID

我已经阅读了更多教程，说netfilter看到的第一个数据包必须是新的（在用户区）。我不明白我的电脑中是否有什么东西不起作用。

然后，在互联网上，有很多规则过滤考虑连接状态和tcp标志。这些都错了吗？原因很简单：如果他们丢弃匹配新的和！ --syn，结果很痛苦......很多数据包通过“防火墙”（如果可以命名的话）

新版本的iptables可能有不同的行为吗？

拜托，如果你在你的电脑上得到相同的结果，你能否确认一下？谢谢，我会很感激的！

Answer 1

看看你的结果，他们几乎是我所期待的。一些决定是基于conntrack模块做出的，其他一些我认为基于TCP RFC中允许的行为（即标志组合）。

如果没有标记，则根据RFC完全无效。

我相信您知道SYN被归类为NEW的原因并且非常符合预期：）

ACK被归类为新的，因为conntrack模块（afaik）在三次握手的第三步之前不会开始跟踪连接。

RST和FIN两者仅作为实时，当前TCP连接的一部分有效，因此此拒绝基于此处跟踪连接的conntrack模块。

当你组合TCP标志时，作为一个“新”数据包，在某些情况下（例如，应该是以前的连接），而在其他情况下，它们都是根据RFC的明显无效的组合（再次）。例如，TCP段不应该设置RST和FIN标志，对于ACK和RST设置应该有一个当前的TCP连接已经设置将某些内容拆除的命令（再次提及conntrack模块正在跟踪此处的连接）。

您是否尝试在Ubuntu 12.04或RHEL上运行相同的测试？我会看看我是否可以稍后尝试，但我相信您的计算机正在按预期工作。不错的测试虽然：）

然后，在互联网上，有很多规则过滤考虑连接状态和tcp标志。这些都错了吗？

我不相信，我认为每个人的用例都不同，通过两者结合，人们通常都很谨慎。然而，大多数人并没有像你所做的那么多（kudos），也没有人都有这种理解。

新版本的iptables是否可能有不同的行为？

不，不是我所知道的。

iptables NEW STATE的“定义”

1 个答案: