Linux 下iptables使用以及简单原理

最新推荐文章于 2024-09-02 16:28:22 发布

kai_ding

最新推荐文章于 2024-09-02 16:28:22 发布

阅读量960

点赞数

分类专栏： linux网络

本文链接：https://blog.youkuaiyun.com/kai_ding/article/details/22995371

版权

linux网络专栏收录该内容

2 篇文章

订阅专栏

前言

最近由于工作需要经常会使用iptables，故而整理了下iptables的简单使用方法以及一些原理方面的东西，写的很浅，以备自己将来需要的时候可以随时翻看，节省时间。

原理简介

这里简单介绍下iptables的简单原理以及其功能。iptables的功能非常丰富，一般我们也用不了太多。这里所写的内容大都来自网上，因为自己没有那么多的精力去深入研究。只能作些简单了解，有所不准确的地方还请谅解并不吝指责。

iptables的状态机

状态机制是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=1

UNREPLIED代表这是一个状态为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=1

ASSURED状态表示当前有数据在进行传输，表面当前连接的状态是ACTIVE的。如果，在这个状态下数据停止了传输，则这条记录会有一个计时器，也就是记录中的第三个字段，上面这条记录的第三个字段是179，代表当前的ASSURED状态还能够保持179秒，如果还有新的数据包经过，那么计时器会被重新设置成缺省的180秒，如果在180秒内都没有流量，那么这条状态记录就会从状态表中被删除。

iptables的表和链

1) 在iptables 中一共有4张表，其中每张表中又分出不同的链：

filter表

主要是对进入、发出、转发的数据包进行过滤，该表由input、output、forward链组成。其中：

1.input链主要是由发送给本防火墙设备本地进程或服务的数据包进行过滤（目的地址为本设备的某一口地址）；

2.output表主要是对由本防火墙设备进程或服务发出去的数据包进行过滤（源地址为本设备的某一接口地址）。

nat表

主要是对要转发的数据包进行源地址或目的地址转换，该表主要由prerouting、postrouting表组成；需要注意的是只有流的第一个包会被这个表中的链匹配，其后的包会自动被做相同的处理。其中：

1.prerouting表主要是对要转发的数据包做目的地址转换；DNAT操作主要用在这样一种情况，你有一个合法的IP地址，要把对防火墙的访问重定向到其他的机子上(比如DMZ)。也就是说，我们改变的是目的地址，以使包能重路由到某台主机。

2.postrouting主要是对要转发的数据包做源地址转换；SNAT改变包的源地址，这在极大程度上可以隐藏你的本地网络，使LAN能连接到Internet

3.还有一种情况就是MASQUERADE：MASQUERADE是要查找可用的IP地址，而不象SNAT用的IP地址是配置好的。当然，这也有好处，就是我们可以使用通过

PPP、 PPPOE、SLIP等拨号得到的地址，这些地址可是由ISP的DHCP随机分配的。

mangle表

主要对数据包的相关的协议字段做改变以作他用，可做的操作如TOS、TTL、MARK等。该表由intput、forward、output、prerouting、postrouting链组成。该表虽然在iptables中实现，但是在实际网络环境中使用较少。个人感觉用的比较多的地方应该是做QOS和策略路由。

raw表

暂时不知道干啥用，看官方的man手册貌似要和conntrack状态机有关。

2) 由于防火墙最主要的功能是做数据包的转发及地址转换，所以先看看数据包进过防火墙是做如何处理的：

1. 以本地为目标的数据包：【进入接口】->【mangle(PREROUTING)】->【nat(PREROUTING)】->【路由】->【mangle(INPUT)】->【filter(INPUT)】->【到达本地程序端口】

在实际使用中：【进入接口】->【nat(PREROUTING)】->【路由】->【filter(INPUT)】->【到达本地程序端口】

2.以本地为源的数据包：【本地程序端口】->【路由】->【mangle(OUTPUT)】->【nat(OUTPUT)】->【filter(OUTPUT)】->【mangle(POSTROUTING)】-

>【nat(POSTROUTING)】->【离开接口】

实际使用中：【本地程序端口】->【路由】->【nat(OUTPUT)】->【filter(OUTPUT)】->【nat(POSTROUTING)】->【离开接口】

3.经防火墙转发的数据包：【进入接口】->【mangle(PREROUTING)】->【nat(PREROUTING)】->【路由】->【mangle(FORWARD)】->【filter(FORWARD)】-

>【mangle(POSTROUTING)】->【nat(POSTROUTING)】->【离开接口】

实际使用中：【进入接口】->【nat(PREROUTING)】->【路由】->【filter(FORWARD)】->【nat(POSTROUTING)】->【离开接口】

使用

iptables规则的配置比较简单，以下面测试中常用的规则为例说明

iptables -I INPUT -p tcp -m state --state ESTABLISHED -s $IP --sport $PORT -j DROP(PORT = 6379，IP=172.17.2.201)
iptables -I OUTPUT -p tcp -m state --state ESTABLISHED -s $IP --sport $PORT -j DROP(PORT = 6379，IP=172.17.2.201)

第一个表示向iptables的filter表的INPUT链中插入一条过滤规则，且是插入第一个，对所有来自172.17.2.201且到本地6379端口且处于ESTABLISHED状态的数据包均丢弃。第二条就不再多费口舌了。

关于--state的理解

state匹配：state匹配在防火墙配置过程中非常重要的，如果没有state的配置，那么需要配置双向的规则才能满足通讯的需要，但防火墙既然有状态检测功能，我们为什么不好好使用它呢？

--state：state的状态有四种，指定要匹配包的的状态，当前有4种状态可用：INVALID，ESTABLISHED，NEW和RELATED。四种数据包的状态我们在前面已经做了详细的描述本节我们只进行state的用法描述，如下例所示：

iptables –A FORWARD –p tcp –m state--state RELATED,ESTABLISHED –j ACCEPT

本例表明凡是数据包状态为“RELATED”、“ESTABLISHED”的tcp包允许通过防火墙。在一般情况下，基于状态的策略都是配置在每一条 chain的最前面，因为当包被匹配到以后，就能够直接被处理了，这是一种比较高效的配置方法。关键字ESTABLISHED比较容易理解，即匹配状态为“已经建立连接”的数据包，那么怎么理解“RELATED”呢，RELATED表示不属于已经建立的那条连接，但和那条连接有关，比如ftp，ftp在建立连接的过程中会首先建立一条ftp-control连接用以传输指令等，真正传输数据的是一条叫做ftp-data的连接，而传输数据的连接是和传输控制信号的连接相关的，因此“RELATED”是用于类似这些特殊服务的。在正常情况下，对于每一种协议：TCP、UDP、ICMP都可以单独的配置状态策略，但一种比较简单高效的做法是：

iptables –A INPUT –p all –m state --stateRELATED,ESTABLISHED –j ACCEPT

使用过程中遇到的问题

1) 配置了规则但不生效

可能原因：规则冲突。比如我使用Iptables -A 来设置一条规则，而前面已经有了可以匹配数据包的规则，此时会导致直接匹配前面的规则而不是匹配我们设置的，因此建议使用 -i 选项。