本文转载自朱双印个人日志
一、iptables概念
防火墙相关概念
此处先描述一些相关概念。
从逻辑上讲。防火墙可以大体分为主机防火墙和网络防火墙。
主机防火墙:针对于单个主机进行防护。
网络防火墙:往往处于网络入口或边缘,针对于网络入口进行防护,服务于防火墙背后的本地局域网。
网络防火墙和主机防火墙并不冲突,可以理解为,网络防火墙主外(集体), 主机防火墙主内(个人)。
从物理上讲,防火墙可以分为硬件防火墙和软件防火墙。
硬件防火墙:在硬件级别实现部分防火墙功能,另一部分功能基于软件实现,性能高,成本高。
软件防火墙:应用软件处理逻辑运行于通用硬件平台之上的防火墙,性能低,成本低。
那么在此处,我们就来聊聊Linux的iptables。
iptables其实不是真正的防火墙,我们可以把它理解成一个客户端代理,用户通过iptables这个代理,将用户的安全设定执行到对应的”安全框架”中,这个”安全框架”才是真正的防火墙,这个框架的名字叫netfilter
netfilter才是防火墙真正的安全框架(framework),netfilter位于内核空间。
iptables其实是一个命令行工具,位于用户空间,我们用这个工具操作真正的框架。
netfilter/iptables(下文中简称为iptables)组成Linux平台下的包过滤防火墙,与大多数的Linux软件一样,这个包过滤防火墙是免费的,它可以代替昂贵的商业防火墙解决方案,完成封包过滤、封包重定向和网络地址转换(NAT)等功能。
Netfilter是Linux操作系统核心层内部的一个数据包处理模块,它具有如下功能:
网络地址转换(Network Address Translate)
数据包内容修改
以及数据包过滤的防火墙功能
所以说,虽然我们使用service iptables start启动iptables”服务”,但是其实准确的来说,iptables并没有一个守护进程,所以并不能算是真正意义上的服务,而应该算是内核提供的功能。
iptables基础
我们知道iptables是按照规则来办事的,我们就来说说规则(rules),规则其实就是网络管理员预定义的条件,规则一般的定义为”如果数据包头符合这样的条件,就这样处理这个数据包”。规则存储在内核空间的信息包过滤表中,这些规则分别指定了源地址、目的地址、传输协议(如TCP、UDP、ICMP)和服务类型(如HTTP、FTP和SMTP)等。当数据包与规则匹配时,iptables就根据规则所定义的方法来处理这些数据包,如放行(accept)、拒绝(reject)和丢弃(drop)等。配置防火墙的主要工作就是添加、修改和删除这些规则。
这样说可能并不容易理解,我们来换个容易理解的角度,从头说起.
当客户端访问服务器的web服务时,客户端发送报文到网卡,而tcp/ip协议栈是属于内核的一部分,所以,客户端的信息会通过内核的TCP协议传输到用户空间中的web服务中,而此时,客户端报文的目标终点为web服务所监听的套接字(IP:Port)上,当web服务需要响应客户端请求时,web服务发出的响应报文的目标终点则为客户端,这个时候,web服务所监听的IP与端口反而变成了原点,我们说过,netfilter才是真正的防火墙,它是内核的一部分,所以,如果我们想要防火墙能够达到”防火”的目的,则需要在内核中设置关卡,所有进出的报文都要通过这些关卡,经过检查后,符合放行条件的才能放行,符合阻拦条件的则需要被阻止,于是,就出现了input关卡和output关卡,而这些关卡在iptables中不被称为”关卡”,而被称为”链”。
其实我们上面描述的场景并不完善,因为客户端发来的报文访问的目标地址可能并不是本机,而是其他服务器,当本机的内核支持IP_FORWARD时,我们可以将报文转发给其他服务器,所以,这个时候,我们就会提到iptables中的其他”关卡”,也就是其他”链”,他们就是 “路由前”、”转发”、”路由后”,他们的英文名是
PREROUTING、FORWARD、POSTROUTING
也就是说,当我们启用了防火墙功能时,报文需要经过如下关卡,也就是说,根据实际情况的不同,报文经过”链”可能不同。如果报文需要转发,那么报文则不会经过input链发往用户空间,而是直接在内核空间中经过forward链和postrouting链转发出去的。
所以,根据上图,我们能够想象出某些常用场景中,报文的流向:
到本机某进程的报文:PREROUTING –> INPUT
由本机转发的报文:PREROUTING –> FORWARD –> POSTROUTING
由本机的某进程发出报文(通常为响应报文):OUTPUT –> POSTROUTING
链的概念
现在,我们想象一下,这些”关卡”在iptables中为什么被称作”链”呢?我们知道,防火墙的作用就在于对经过的报文匹配”规则”,然后执行对应的”动作”,所以,当报文经过这些关卡的时候,则必须匹配这个关卡上的规则,但是,这个关卡上可能不止有一条规则,而是有很多条规则,当我们把这些规则串到一个链条上的时候,就形成了”链”,所以,我们把每一个”关卡”想象成如下图中的模样 ,这样来说,把他们称为”链”更为合适,每个经过这个”关卡”的报文,都要将这条”链”上的所有规则匹配一遍,如果有符合条件的规则,则执行规则对应的动作。
表的概念
我们再想想另外一个问题,我们对每个”链”上都放置了一串规则,但是这些规则有些很相似,比如,A类规则都是对IP或者端口的过滤,B类规则是修改报文,那么这个时候,我们是不是能把实现相同功能的规则放在一起呢,必须能的。
我们把具有相同功能的规则的集合叫做”表”,所以说,不同功能的规则,我们可以放置在不同的表中进行管理,而iptables已经为我们定义了4种表,每种表对应了不同的功能,而我们定义的规则也都逃脱不了这4种功能的范围,所以,学习iptables之前,我们必须先搞明白每种表 的作用。
iptables为我们提供了如下规则的分类,或者说,iptables为我们提供了如下”表”
filter表:负责过滤功能,防火墙;内核模块:iptables_filter
nat表:network address translation,网络地址转换功能;内核模块:iptable_nat
mangle表:拆解报文,做出修改,并重新封装 的功能;iptable_mangle
raw表:关闭nat表上启用的连接追踪机制;iptable_raw
也就是说,我们自定义的所有规则,都是这四种分类中的规则,或者说,所有规则都存在于这4张”表”中。
表链关系
但是我们需要注意的是,某些”链”中注定不会包含”某类规则”,就像某些”关卡”天生就不具备某些功能一样,比如,A”关卡”只负责打击陆地敌人,没有防空能力,B”关卡”只负责打击空中敌人,没有防御步兵的能力,C”关卡”可能比较NB,既能防空,也能防御陆地敌人,D”关卡”最屌,海陆空都能防。
那让我们来看看,每个”关卡”都有哪些能力,或者说,让我们看看每个”链”上的规则都存在于哪些”表”中。
我们还是以图为例,先看看prerouting”链”上的规则都存在于哪些表中。
注意:下图只用于说明prerouting链上的规则存在于哪些表中,并没有描述表的顺序。
这幅图是什么意思呢?它的意思是说,prerouting”链”只拥有nat表、raw表和mangle表所对应的功能,所以,prerouting中的规则只能存放于nat表、raw表和mangle表中。
那么,根据上述思路,我们来总结一下,每个”关卡”都拥有什么功能,
或者说,每个”链”中的规则都存在于哪些”表”中。
PREROUTING 的规则可以存在于:raw表,mangle表,nat表。
INPUT 的规则可以存在于:mangle表,filter表,(centos7中还有nat表,centos6中没有)。
FORWARD 的规则可以存在于:mangle表,filter表。
OUTPUT 的规则可以存在于:raw表mangle表,nat表,filter表。
POSTROUTING 的规则可以存在于:mangle表,nat表。
但是,我们在实际的使用过程中,往往是通过”表”作为操作入口,对规则进行定义的,之所以按照上述过程介绍iptables,是因为从”关卡”的角度更容易从入门的角度理解,但是为了以便在实际使用的时候,更加顺畅的理解它们,此处我们还要将各”表”与”链”的关系罗列出来,
表(功能)<–> 链(钩子):
raw 表中的规则可以被哪些链使用:PREROUTING,OUTPUT
mangle 表中的规则可以被哪些链使用:PREROUTING,INPUT,FORWARD,OUTPUT,POSTROUTING
nat 表中的规则可以被哪些链使用:PREROUTING,OUTPUT,POSTROUTING(centos7中还有INPUT,centos6中没有)
filter 表中的规则可以被哪些链使用:INPUT,FORWARD,OUTPUT
其实我们还需要注意一点,因为数据包经过一个”链”的时候,会将当前链的所有规则都匹配一遍,但是匹配时总归要有顺序,我们应该一条一条的去匹配,而且我们说过,相同功能类型的规则会汇聚在一张”表”中,那么,哪些”表”中的规则会放在”链”的最前面执行呢,这时候就需要有一个优先级的问题,我们还拿prerouting”链”做图示。
prerouting链中的规则存放于三张表中,而这三张表中的规则执行的优先级如下:
raw –> mangle –> nat
但是我们知道,iptables为我们定义了4张”表”,当他们处于同一条”链”时,执行的优先级如下。
优先级次序(由高而低):
raw –> mangle –> nat –> filter
但是我们前面说过,某些链天生就不能使用某些表中的规则,所以,4张表中的规则处于同一条链的目前只有output链,它就是传说中海陆空都能防守的关卡。
为了更方便的管理,我们还可以在某个表里面创建自定义链,将针对某个应用程序所设置的规则放置在这个自定义链中,但是自定义链接不能直接使用,只能被某个默认的链当做动作去调用才能起作用,我们可以这样想象,自定义链就是一段比较”短”的链子,这条”短”链子上的规则都是针对某个应用程序制定的,但是这条短的链子并不能直接使用,而是需要”焊接”在iptables默认定义链子上,才能被IPtables使用,这就是为什么默认定义的”链”需要把”自定义链”当做”动作”去引用的原因。这是后话,后面再聊,在实际使用时我们即可更加的明白。
数据经过防火墙的流程
结合上述所有的描述,我们可以将数据包通过防火墙的流程总结为下图:
我们在写Iptables规则的时候,要时刻牢记这张路由次序图,灵活配置规则。
我们将经常用到的对应关系重新写在此处,方便对应图例查看。
链的规则存放于哪些表中(从链到表的对应关系):
PREROUTING 的规则可以存在于:raw表,mangle表,nat表。
INPUT 的规则可以存在于:mangle表,filter表,(centos7中还有nat表,centos6中没有)。
FORWARD 的规则可以存在于:mangle表,filter表。
OUTPUT 的规则可以存在于:raw表mangle表,nat表,filter表。
POSTROUTING 的规则可以存在于:mangle表,nat表。
表中的规则可以被哪些链使用(从表到链的对应关系):
raw 表中的规则可以被哪些链使用:PREROUTING,OUTPUT
mangle 表中的规则可以被哪些链使用:PREROUTING,INPUT,FORWARD,OUTPUT,POSTROUTING
nat 表中的规则可以被哪些链使用:PREROUTING,OUTPUT,POSTROUTING(centos7中还有INPUT,centos6中没有)
filter 表中的规则可以被哪些链使用:INPUT,FORWARD,OUTPUT
下图中nat表在centos7中的情况就不再标明。
规则的概念
说了一圈又说回来了,在上述描述中我们一直在提规则,可是没有细说,现在说说它。
先说说规则的概念,然后再通俗的解释它。
规则:根据指定的匹配条件来尝试匹配每个流经此处的报文,一旦匹配成功,则由规则后面指定的处理动作进行处理;
那么我们来通俗的解释一下什么是iptables的规则,之前打过一个比方,每条”链”都是一个”关卡”,每个通过这个”关卡”的报文都要匹配这个关卡上的规则,如果匹配,则对报文进行对应的处理,比如说,你我二人此刻就好像两个”报文”,你我二人此刻都要入关,可是城主有命,只有器宇轩昂的人才能入关,不符合此条件的人不能入关,于是守关将士按照城主制定的”规则”,开始打量你我二人,最终,你顺利入关了,而我已被拒之门外,因为你符合”器宇轩昂”的标准,所以把你”放行”了,而我不符合标准,所以没有被放行,其实,”器宇轩昂”就是一种”匹配条件”,”放行”就是一种”动作”,”匹配条件”与”动作”组成了规则。
了解了规则的概念,那我们来聊聊规则的组成部分,此处只是大概的将规则的结构列出,后面的文章中会单独对规则进行总结。
规则由匹配条件和处理动作组成。
匹配条件
匹配条件分为基本匹配条件与扩展匹配条件
基本匹配条件:
源地址Source IP,目标地址 Destination IP
上述内容都可以作为基本匹配条件。
扩展匹配条件:
除了上述的条件可以用于匹配,还有很多其他的条件可以用于匹配,这些条件泛称为扩展条件,这些扩展条件其实也是netfilter中的一部分,只是以模块的形式存在,如果想要使用这些条件,则需要依赖对应的扩展模块。
源端口Source Port, 目标端口Destination Port
上述内容都可以作为扩展匹配条件
处理动作
处理动作在iptables中被称为target(这样说并不准确,我们暂且这样称呼),动作也可以分为基本动作和扩展动作。
此处列出一些常用的动作,之后的文章会对它们进行详细的示例与总结:
ACCEPT:允许数据包通过。
DROP:直接丢弃数据包,不给任何回应信息,这时候客户端会感觉自己的请求泥牛入海了,过了超时时间才会有反应。
REJECT:拒绝数据包通过,必要时会给数据发送端一个响应的信息,客户端刚请求就会收到拒绝的信息。
SNAT:源地址转换,解决内网用户用同一个公网地址上网的问题。
MASQUERADE:是SNAT的一种特殊形式,适用于动态的、临时会变的ip上。
DNAT:目标地址转换。
REDIRECT:在本机做端口映射。
LOG:在/var/log/messages文件中记录日志信息,然后将数据包传递给下一条规则,也就是说除了记录以外不对数据包做任何其他操作,仍然让下一条规则去匹配。
二、iptables实际操作之规则查询
在进行iptables实验时,请务必在测试机上进行。
之前在iptables的概念中已经提到过,在实际操作iptables的过程中,是以”表”作为操作入口的,如果你经常操作关系型数据库,那么当你听到”表”这个词的时候,你可能会联想到另一个词—-“增删改查”,当我们定义iptables规则时,所做的操作其实类似于”增删改查”,那么,我们就先从最简单的”查”操作入手,开始实际操作iptables。
在之前的文章中,我们已经总结过,iptables为我们预定义了4张表,它们分别是raw表、mangle表、nat表、filter表,不同的表拥有不同的功能。
filter负责过滤功能,比如允许哪些IP地址访问,拒绝哪些IP地址访问,允许访问哪些端口,禁止访问哪些端口,filter表会根据我们定义的规则进行过滤,filter表应该是我们最常用到的表了,所以此处,我们以filter表为例,开始学习怎样实际操作iptables。
怎样查看filter表中的规则呢?使用如下命令即可查看。
上例中,我们使用-t选项,指定要操作的表,使用-L选项,查看-t选项对应的表的规则,-L选项的意思是,列出规则,所以,上述命令的含义为列出filter表的所有规则,注意,上图中显示的规则(绿色标注的部分为规则)是Centos6启动iptables以后默认设置的规则,我们暂且不用在意它们,上图中,显示出了3条链(蓝色标注部分为链),INPUT链、FORWARD链、OUTPUT链,每条链中都有自己的规则,前文中,我们打过一个比方,把”链”比作”关卡”,不同的”关卡”拥有不同的能力,所以,从上图中可以看出,INPUT链、FORWARD链、OUTPUT链都拥有”过滤”的能力,所以,当我们要定义某条”过滤”的规则时,我们会在filter表中定义,但是具体在哪条”链”上定义规则呢?这取决于我们的工作场景。比如,我们需要禁止某个IP地址访问我们的主机,我们则需要在INPUT链上定义规则。因为,我们在理论总结中已经提到过,报文发往本机时,会经过PREROUTING链与INPUT链(如果你没有明白,请回顾前文),所以,如果我们想要禁止某些报文发往本机,我们只能在PREROUTING链和INPUT链中定义规则,但是PREROUTING链并不存在于filter表中,换句话说就是,PREROUTING关卡天生就没有过滤的能力,所以,我们只能在INPUT链中定义,当然,如果是其他工作场景,可能需要在FORWARD链或者OUTPUT链中定义过滤规则。
话说回来,我们继续聊怎样查看某张表中的规则。
刚才提到,我们可以使用iptables -t filter -L命令列出filter表中的所有规则,那么举一反三,我们也可以查看其它表中的规则,示例如下。
iptables -t raw -L
iptables -t mangle -L
iptables -t nat -L
其实,我们可以省略-t filter,当没有使用-t选项指定表时,默认为操作filter表,即iptables -L表示列出filter表中的所有规则。
我们还可以只查看指定表中的指定链的规则,比如,我们只查看filter表中INPUT链的规则,示例如下(注意大小写)。
上图中只显示了filter表中INPUT链中的规则(省略-t选项默认为filter表),当然,你也可以指定只查看其他链,其实,我们查看到的信息还不是最详细的信息,我们可以使用-v选项,查看出更多的、更详细的信息,示例如下。
可以看到,使用-v选项后,iptables为我们展示的信息更多了,那么,这些字段都是什么意思呢?我们来总结一下,看不懂没关系,等到实际使用的时候,自然会明白,此处大概了解一下即可。
其实,这些字段就是规则对应的属性,说白了就是规则的各种信息,那么我们来总结一下这些字段的含义。
pkts:对应规则匹配到的报文的个数。
bytes:对应匹配到的报文包的大小总和。
target:规则对应的target,往往表示规则对应的”动作”,即规则匹配成功后需要采取的措施。
prot:表示规则对应的协议,是否只针对某些协议应用此规则。
opt:表示规则对应的选项。
in:表示数据包由哪个接口(网卡)流入,即从哪个网卡来。
out:表示数据包将由哪个接口(网卡)流出,即到哪个网卡去。
source:表示规则对应的源头地址,可以是一个IP,也可以是一个网段。
destination:表示规则对应的目标地址。可以是一个IP,也可以是一个网段。
细心如你一定发现了,上图中的源地址与目标地址都为anywhere,看来,iptables默认为我们进行了名称解析,但是在规则非常多的情况下如果进行名称解析,效率会比较低,所以,在没有此需求的情况下,我们可以使用-n选项,表示不对IP地址进行名称反解,直接显示IP地址,示例如下。
如上图所示,规则中的源地址与目标地址已经显示为IP,而非转换后的名称。
当然,我们也可以只查看某个链的规则,并且不让IP进行反解,这样更清晰一些,比如 iptables -nvL INPUT
如果你习惯了查看有序号的列表,你在查看iptables表中的规则时肯定会很不爽,没有关系,满足你,使用–line-numbers即可显示规则的编号,示例如下。
–line-numbers选项并没有对应的短选项,不过我们缩写成–line时,centos中的iptables也可以识别。
我知道你目光如炬,你可能早就发现了,表中的每个链的后面都有一个括号,括号里面有一些信息,如下图红色标注位置,那么这些信息都代表了什么呢?我们来看看。
上图中INPUT链后面的括号中包含policy ACCEPT ,0 packets,0bytes 三部分。
policy表示当前链的默认策略,policy ACCEPT表示上图中INPUT的链的默认动作为ACCEPT,换句话说就是,默认接受通过INPUT关卡的所有请求,所以我们在配置INPUT链的具体规则时,应该将需要拒绝的请求配置到规则中,说白了就是”黑名单”机制,默认所有人都能通过,只有指定的人不能通过,当我们把INPUT链默认动作设置为接受(ACCEPT),就表示所有人都能通过这个关卡,此时就应该在具体的规则中指定需要拒绝的请求,就表示只有指定的人不能通过这个关卡,这就是黑名单机制,但是,你一定发现了,上图中所显示出的规则,大部分都是接受请求(ACCEPT),并不是想象中的拒绝请求(DROP或者REJECT),这与我们所描述的黑名单机制不符啊,按照道理来说,默认动作为接受,就应该在具体的规则中配置需要拒绝的人,但是上图中并不是这样的,之所以出现上图中的情况,是因为IPTABLES的工作机制导致到,上例其实是利用了这些”机制”,完成了所谓的”白名单”机制,并不是我们所描述的”黑名单”机制,我们此处暂时不用关注这一点,之后会进行详细的举例并解释,此处我们只要明白policy对应的动作为链的默认动作即可,或者换句话说,我们只要理解,policy为链的默认策略即可。
packets表示当前链(上例为INPUT链)默认策略匹配到的包的数量,0 packets表示默认策略匹配到0个包。
bytes表示当前链默认策略匹配到的所有包的大小总和。
其实,我们可以把packets与bytes称作”计数器”,上图中的计数器记录了默认策略匹配到的报文数量与总大小,”计数器”只会在使用-v选项时,才会显示出来。
当被匹配到的包达到一定数量时,计数器会自动将匹配到的包的大小转换为可读性较高的单位,如下图所示。
如果你想要查看精确的计数值,而不是经过可读性优化过的计数值,那么你可以使用-x选项,表示显示精确的计数值,示例如下。
每张表中的每条链都有自己的计数器,链中的每个规则也都有自己的计数器,没错,就是每条规则对应的pkts字段与bytes字段的信息。
小结
好了,我们已经会使用命令简单的查看iptables表的规则了,为了方便以后回顾,我们将上文中的相关命令总结一下。
iptables -t 表名 -L
查看对应表的所有规则,-t选项指定要操作的表,省略”-t 表名”时,默认表示操作filter表,-L表示列出规则,即查看规则。
iptables -t 表名 -L 链名
查看指定表的指定链中的规则。
iptables -t 表名 -v -L
查看指定表的所有规则,并且显示更详细的信息(更多字段),-v表示verbose,表示详细的,冗长的,当使用-v选项时,会显示出”计数器”的信息,由于上例中使用的选项都是短选项,所以一般简写为iptables -t 表名 -vL
iptables -t 表名 -n -L
表示查看表的所有规则,并且在显示规则时,不对规则中的IP或者端口进行名称反解,-n选项表示不解析IP地址。
iptables --line-numbers -t 表名 -L
表示查看表的所有规则,并且显示规则的序号,–line-numbers选项表示显示规则的序号,注意,此选项为长选项,不能与其他短选项合并,不过此选项可以简写为–line,注意,简写后仍然是两条横杠,仍然是长选项。
iptables -t 表名 -v -x -L
表示查看表中的所有规则,并且显示更详细的信息(-v选项),不过,计数器中的信息显示为精确的计数值,而不是显示为经过可读优化的计数值,-x选项表示显示计数器的精确值。
实际使用中,为了方便,往往会将短选项进行合并,所以,如果将上述选项都糅合在一起,可以写成如下命令,此处以filter表为例。
iptables --line -t filter -nvxL
当然,也可以只查看某张表中的某条链,此处以filter表的INPUT链为例
iptables --line -t filter -nvxL INPUT
三、iptables规则管理
首先,我们来回顾一下什么是iptables的规则。
之前打过一个比方,每条”链”都是一个”关卡”,每个通过这个”关卡”的报文都要匹配这个关卡上的规则,如果匹配,则对报文进行对应的处理,比如说,你我二人此刻就好像两个”报文”,你我二人此刻都要入关,可是城主有命,只有器宇轩昂之人才能入关,不符合此条件的人不能入关,于是守关将士按照城主制定的”规则”,开始打量你我二人,最终,你顺利入关了,而我已被拒之门外,因为你符合”器宇轩昂”的标准,所以把你”放行”了,而我不符合标准,所以没有被放行,其实,”器宇轩昂”就是一种”匹配条件”,”放行”就是一种”动作”,”匹配条件”与”动作”组成了规则。
只不过,在iptables的世界中,最常用的匹配条件并不是”器宇轩昂”,而是报文的”源地址”、”目标地址”、”源端口”、”目标端口”等,在iptables的世界中,最常用的动作有ACCEPT(接受)、DROP(丢弃)、REJECT(拒绝),其中ACCEPT就与我们举例中的”放行”类似,但是,我们刚才提到的这些并不是全部的匹配条件与动作,只是最常用的一些罢了,具体的匹配条件与动作不是我们今天讨论的重点,我们会在以后的文章中再做总结。
好了,我们已经回顾了规则的概念,并且已经明白了,规则大致由两个逻辑单元组成,匹配条件与动作,那么多说无益,我们来动手定义一条规则,此处仍然以filter表中的INPUT链为例,因为filter表负责”过滤”功能,而所有发往本机的报文如果需要被过滤,首先会经过INPUT链(PREROUTING链没有过滤功能),这与我们所比喻的”入关”场景非常相似,所以,使用filter表的INPUT链为例,有助于我们进行理解。
首先,查看一下filter表中的INPUT链中的规则,查看规则的相关命令在前文已经总结了,此处不再赘述,如果你忘了,请回顾前文。
使用如下命令查看filter表INPUT链的规则,下图中的规则为centos6默认添加的规则。
注意:在参照本文进行iptables实验时,请务必在个人的测试机上进行。
为了准备一个从零开始的环境,我们将centos6默认提供的规则清空,以便我们进行实验,使用iptables -F INPUT命令清空filter表INPUT链中的规则,后面我们会单独对清除规则的相关命令进行总结,此处不用纠结此命令。
清空INPUT链以后,filter表中的INPUT链已经不存在任何的规则,但是可以看出,INPUT链的默认策略是ACCEPT,也就是说,INPUT链默认”放行”所有发往本机的报文,当没有任何规则时,会接受所有报文,当报文没有被任何规则匹配到时,也会默认放行报文。
那么此刻,我们就在另外一台机器上,使用ping命令,向当前机器发送报文,如下图所示,ping命令可以得到回应,证明ping命令发送的报文已经正常的发送到了防火墙所在的主机,ping命令所在机器IP地址为146,当前测试防火墙主机的IP地址为156,我们就用这样的环境,对iptables进行操作演示。
增加规则
那么此处,我们就在156上配置一条规则,拒绝192.168.1.146上的所有报文访问当前机器,之前一直在说,规则由匹配条件与动作组成,那么”拒绝192.168.1.146上的所有报文访问当前机器”这条规则中,报文的”源地址为192.168.1.146″则属于匹配条件,如果报文来自”192.168.1.146″,则表示满足匹配条件,而”拒绝”这个报文,就属于对应的动作,好了,那么怎样用命令去定义这条规则呢?使用如下命令即可
上图中,使用 -t选项指定了要操作的表,此处指定了操作filter表,与之前的查看命令一样,不使用-t选项指定表时,默认为操作filter表。
使用-I选项,指明将”规则”插入至哪个链中,-I表示insert,即插入的意思,所以-I INPUT表示将规则插入于INPUT链中,即添加规则之意。
使用-s选项,指明”匹配条件”中的”源地址”,即如果报文的源地址属于-s对应的地址,那么报文则满足匹配条件,-s为source之意,表示源地址。
使用-j选项,指明当”匹配条件”被满足时,所对应的动作,上例中指定的动作为DROP,在上例中,当报文的源地址为192.168.1.146时,报文则被DROP(丢弃)。
再次查看filter表中的INPUT链,发现规则已经被添加了,在iptables中,动作被称之为”target”,所以,上图中taget字段对应的动作为DROP。
那么此时,我们再通过192.168.1.146去ping主机156,看看能否ping通。
如上图所示,ping 156主机时,PING命令一直没有得到回应,看来我们的iptables规则已经生效了,ping发送的报文压根没有被156主机接受,而是被丢弃了,所以更不要说什么回应了,好了,我们已经成功的配置了一条iptables规则,看来,我们已经入门了。
还记得我们在前文中说过的”计数器”吗?此时,我们再次查看iptables中的规则,可以看到,已经有24个包被对应的规则匹配到,总计大小2016bytes。
此刻,我们来做一个实验。
现在INPUT链中已经存在了一条规则,它拒绝了所有来自192.168.1.146主机中的报文,如果此时,我们在这条规则之后再配置一条规则,后面这条规则规定,接受所有来自192.168.1.146主机中的报文,那么,iptables是否会接受来自146主机的报文呢?我们动手试试。
使用如下命令在filter表的INPUT链中追加一条规则,这条规则表示接受所有来自192.168.1.146的发往本机的报文。
上图中的命令并没有使用-t选项指定filter表,我们一直在说,不使用-t选项指定表时表示默认操作filter表。
上图中,使用-A选项,表示在对应的链中”追加规则”,-A为append之意,所以,-A INPUT则表示在INPUT链中追加规则,而之前示例中使用的-I选项则表示在链中”插入规则”,聪明如你一定明白了,它们的本意都是添加一条规则,只是-A表示在链的尾部追加规则,-I表示在链的首部插入规则而已。
使用-j选项,指定当前规则对应的动作为ACCEPT。
执行完添加规则的命令后,再次查看INPUT链,发现规则已经成功”追加”至INPUT链的末尾,那么现在,第一条规则指明了丢弃所有来自192.168.1.146的报文,第二条规则指明了接受所有来自192.168.1.146的报文,那么结果到底是怎样的呢?实践出真知,在146主机上再次使用ping命令向156主机发送报文,发现仍然是ping不通的,看来第二条规则并没有生效。
而且从上图中第二条规则的计数器可以看到,根本没有任何报文被第二条规则匹配到。
聪明如你一定在猜想,发生上述情况,会不会与规则的先后顺序有关呢?测试一下不就知道了,我们再添加一条规则,新规则仍然规定接受所有来自192.168.1.146主机中的报文,只是这一次,我们将新规则添加至INPUT链的最前面试试。
在添加这条规则之前,我们先把146上的ping命令强制停止了,然后使用如下命令,在filter表的INPUT链的前端添加新规则。
好了,现在第一条规则就是接受所有来自192.168.1.146的报文,而且此时计数是0,此刻,我们再从146上向156发起ping请求。
146上已经可以正常的收到响应报文了,那么回到156查看INPUT链的规则,第一条规则的计数器已经显示出了匹配到的报文数量。
看来,规则的顺序很重要。
如果报文已经被前面的规则匹配到,iptables则会对报文执行对应的动作,即使后面的规则也能匹配到当前报文,很有可能也没有机会再对报文执行相应的动作了,就以上图为例,报文先被第一条规则匹配到了,于是当前报文被”放行”了,因为报文已经被放行了,所以,即使上图中的第二条规则即使能够匹配到刚才”放行”的报文,也没有机会再对刚才的报文进行丢弃操作了。这就是iptables的工作机制。
之前在总结查看命令时提到过,使用–line-number选项可以列出规则的序号,如下图所示
我们也可以在添加规则时,指定新增规则的编号,这样我们就能在任意位置插入规则了,我们只要把刚才的命令稍作修改即可,如下。
仍然使用-I选项进行插入规则操作,-I INPUT 2表示在INPUT链中新增规则,新增的规则的编号为2,好了,自己动手试试吧。
删除规则
注意:在参照本文进行iptables实验时,请务必在个人的测试机上进行。
此刻,如果我们想要删除filter表中INPUT中的一条规则,该怎么做呢?
有两种办法
方法一:根据规则的编号去删除规则
方法二:根据具体的匹配条件与动作删除规则
那么我们先看看方法一,先查看一下filter表中INPUT链中的规则
假如我们想要删除上图中的第3条规则,则可以使用如下命令。
上例中,使用了-t选项指定了要操作的表(没错,省略-t默认表示操作filter表),使用-D选项表示删除指定链中的某条规则,-D INPUT 3表示删除INPUT链中的第3条规则。
当然,我们也可以根据具体的匹配条件与动作去删除规则,比如,删除下图中源地址为192.168.1.146,动作为ACCEPT的规则,于是,删除规则的命令如下。
上图中,删除对应规则时,仍然使用-D选项,-D INPUT表示删除INPUT链中的规则,剩下的选项与我们添加规则时一毛一样,-s表示以对应的源地址作为匹配条件,-j ACCEPT表示对应的动作为接受,所以,上述命令表示删除INPUT链中源地址为192.168.1.146,动作为ACCEPT的规则。
而删除指定表中某条链中的所有规则的命令,我们在一开始就使用到了,就是”iptables -t 表名 -F 链名”
-F选项为flush之意,即冲刷指定的链,即删除指定链中的所有规则,但是注意,此操作相当于删除操作,在没有保存iptables规则的情况下,请慎用。
其实,-F选项不仅仅能清空指定链上的规则,其实它还能清空整个表中所有链上的规则,不指定链名,只指定表名即可删除表中的所有规则,命令如下
iptables -t 表名 -F
不过再次强调,在没有保存iptables规则时,请勿随便清空链或者表中的规则,除非你明白你在干什么。
修改规则
注意:在参照本文进行iptables实验时,请务必在个人的测试机上进行。
那么,我们怎样修改某条规则中的动作呢?比如,我想把如下规则中的动作从DROP改为REJECT,改怎么办呢?
我们可以使用-R选项修改指定的链中的规则,在修改规则时指定规则对应的编号即可(有坑,慎行),示例命令如下
上例中,-R选项表示修改指定的链,使用-R INPUT 1表示修改INPUT链的第1条规则,使用-j REJECT表示将INPUT链中的第一条规则的动作修改为REJECT,注意:上例中, -s选项以及对应的源地址不可省略,即使我们已经指定了规则对应的编号,但是在使用-R选项修改某个规则时,必须指定规则对应的原本的匹配条件(如果有多个匹配条件,都需要指定)。
如果上例中的命令没有使用-s指定对应规则中原本的源地址,那么在修改完成后,你修改的规则中的源地址会自动变为0.0.0.0/0(此IP表示匹配所有网段的IP地址),而此时,-j对应的动作又为REJECT,所以在执行上述命令时如果没有指明规则原本的源地址,那么所有IP的请求都被拒绝了(因为没有指定原本的源地址,当前规则的源地址自动变为0.0.0.0/0),如果你正在使用ssh远程到服务器上进行iptables设置,那么你的ssh请求也将会被阻断。
既然使用-R选项修改规则时,必须指明规则原本的匹配条件,那么我们则可以理解为,只能通过-R选项修改规则对应的动作了,所以我觉得,如果你想要修改某条规则,还不如先将这条规则删除,然后在同样位置再插入一条新规则,这样更好,当然,如果你只是为了修改某条规则的动作,那么使用-R选项时,不要忘了指明规则原本对应的匹配条件。
好了,上例中,我们已经将规则中的动作从DROP改为了REJECT,那么DROP与REJECT有什么不同呢?从字面上理解,DROP表示丢弃,REJECT表示拒绝,REJECT表达的意思好像更坚决一点,我们再次从146主机上向156主机上发起ping请求,看看与之前动作为DROP时有什么不同。
如上图所示,当156主机中的iptables规则对应的动作为REJECT时,从146上进行ping操作时,直接就提示”目标不可达”,并没有像之前那样卡在那里,看来,REJECT比DROP更加”干脆”。
其实,我们还可以修改指定链的”默认策略”,没错,就是下图中标注的默认策略。
每张表的每条链中,都有自己的默认策略,我们也可以理解为默认”动作”。
当报文没有被链中的任何规则匹配到时,或者,当链中没有任何规则时,防火墙会按照默认动作处理报文,我们可以修改指定链的默认策略,使用如下命令即可。
使用-t指定要操作的表,使用-P选项指定要修改的链,上例中,-P FORWARD DROP表示将表中FORWRD链的默认策略改为DROP。
保存规则
在默认的情况下,我们对”防火墙”所做出的修改都是”临时的”,换句话说就是,当重启iptables服务或者重启服务器以后,我们平常添加的规则或者对规则所做出的修改都将消失,为了防止这种情况的发生,我们需要将规则”保存”。
centos7与centos6中的情况稍微有些不同,我们先说centos6中怎样保存iptables规则。
centos6中,使用”service iptables save”命令即可保存规则,规则默认保存在/etc/sysconfig/iptables文件中,如果你刚刚安装完centos6,在刚开始使用iptables时,会发现filter表中会有一些默认的规则,这些默认提供的规则其实就保存在/etc/sysconfig/iptables中, 保存规则的示例如下。
如上图所示,文件中保存了filter表中每条链的默认策略,以及每条链中的规则,由于其他表中并没有设置规则,也没有使用过其他表,所以文件中只保存了filter表中的规则。
当我们对规则进行了修改以后,如果想要修改永久生效,必须使用service iptables save保存规则,当然,如果你误操作了规则,但是并没有保存,那么使用service iptables restart命令重启iptables以后,规则会再次回到上次保存/etc/sysconfig/iptables文件时的模样。
从现在开始,最好养成及时保存规则的好习惯。
centos7中,已经不再使用init风格的脚本启动服务,而是使用unit文件,所以,在centos7中已经不能再使用类似service iptables start这样的命令了,所以service iptables save也无法执行,同时,在centos7中,使用firewall替代了原来的iptables service,不过不用担心,我们只要通过yum源安装iptables与iptables-services即可(iptables一般会被默认安装,但是iptables-services在centos7中一般不会被默认安装),在centos7中安装完iptables-services后,即可像centos6中一样,通过service iptables save命令保存规则了,规则同样保存在/etc/sysconfig/iptables文件中。
此处给出centos7中配置iptables-service的步骤
#配置好yum源以后安装iptables-service
# yum install -y iptables-services
#停止firewalld
# systemctl stop firewalld
#禁止firewalld自动启动
# systemctl disable firewalld
#启动iptables
# systemctl start iptables
#将iptables设置为开机自动启动,以后即可通过iptables-service控制iptables服务
# systemctl enable iptables
上述配置过程只需一次,以后即可在centos7中愉快的使用service iptables save命令保存iptables规则了。
其他通用方法
还可以使用另一种方法保存iptables规则,就是使用iptables-save命令
使用iptables-save并不能保存当前的iptables规则,但是可以将当前的iptables规则以”保存后的格式”输出到屏幕上。
所以,我们可以使用iptables-save命令,再配合重定向,将规则重定向到/etc/sysconfig/iptables文件中即可。
iptables-save > /etc/sysconfig/iptables
我们也可以将/etc/sysconfig/iptables中的规则重新载入为当前的iptables规则,但是注意,未保存入/etc/sysconfig/iptables文件中的修改将会丢失或者被覆盖。
使用iptables-restore命令可以从指定文件中重载规则,示例如下
iptables-restore < /etc/sysconfig/iptables
再次提醒:重载规则时,现有规则将会被覆盖。
命令小结
上文已经详细的举例并描述了怎样进行iptables规则管理,为了以后能够快速的回顾,我们把上述命令总结一下。
添加规则
注意点:添加规则时,规则的顺序非常重要
在指定表的指定链的尾部添加一条规则,-A选项表示在对应链的末尾添加规则,省略-t选项时,表示默认操作filter表中的规则
命令语法:iptables -t 表名 -A 链名 匹配条件 -j 动作
示例:iptables -t filter -A INPUT -s 192.168.1.146 -j DROP
在指定表的指定链的首部添加一条规则,-I选型表示在对应链的开头添加规则
命令语法:iptables -t 表名 -I 链名 匹配条件 -j 动作
示例:iptables -t filter -I INPUT -s 192.168.1.146 -j ACCEPT
在指定表的指定链的指定位置添加一条规则
命令语法:iptables -t 表名 -I 链名 规则序号 匹配条件 -j 动作
示例:iptables -t filter -I INPUT 5 -s 192.168.1.146 -j REJECT
设置指定表的指定链的默认策略(默认动作),并非添加规则。
命令语法:iptables -t 表名 -P 链名 动作
示例:iptables -t filter -P FORWARD ACCEPT
上例表示将filter表中FORWARD链的默认策略设置为ACCEPT
删除规则
注意点:如果没有保存规则,删除规则时请慎重
按照规则序号删除规则,删除指定表的指定链的指定规则,-D选项表示删除对应链中的规则。
命令语法:iptables -t 表名 -D 链名 规则序号
示例:iptables -t filter -D INPUT 3
上述示例表示删除filter表中INPUT链中序号为3的规则。
按照具体的匹配条件与动作删除规则,删除指定表的指定链的指定规则。
命令语法:iptables -t 表名 -D 链名 匹配条件 -j 动作
示例:iptables -t filter -D INPUT -s 192.168.1.146 -j DROP
上述示例表示删除filter表中INPUT链中源地址为192.168.1.146并且动作为DROP的规则。
删除指定表的指定链中的所有规则,-F选项表示清空对应链中的规则,执行时需三思。
命令语法:iptables -t 表名 -F 链名
示例:iptables -t filter -F INPUT
删除指定表中的所有规则,执行时需三思。
命令语法:iptables -t 表名 -F
示例:iptables -t filter -F
修改规则
注意点:如果使用-R选项修改规则中的动作,那么必须指明原规则中的原匹配条件,例如源IP,目标IP等。
修改指定表中指定链的指定规则,-R选项表示修改对应链中的规则,使用-R选项时要同时指定对应的链以及规则对应的序号,并且规则中原本的匹配条件不可省略。
命令语法:iptables -t 表名 -R 链名 规则序号 规则原本的匹配条件 -j 动作
示例:iptables -t filter -R INPUT 3 -s 192.168.1.146 -j ACCEPT
上述示例表示修改filter表中INPUT链的第3条规则,将这条规则的动作修改为ACCEPT, -s 192.168.1.146为这条规则中原本的匹配条件,如果省略此匹配条件,修改后的规则中的源地址可能会变为0.0.0.0/0。
其他修改规则的方法:先通过编号删除规则,再在原编号位置添加一条规则。
修改指定表的指定链的默认策略(默认动作),并非修改规则,可以使用如下命令。
命令语法:iptables -t 表名 -P 链名 动作
示例:iptables -t filter -P FORWARD ACCEPT
上例表示将filter表中FORWARD链的默认策略修改为ACCEPT
保存规则
保存规则命令如下,表示将iptables规则保存至/etc/sysconfig/iptables文件中,如果对应的操作没有保存,那么当重启iptables服务以后
service iptables save
注意点:centos7中使用默认使用firewalld,如果想要使用上述命令保存规则,需要安装iptables-services,具体配置过程请回顾上文。
或者使用如下方法保存规则
iptables-save > /etc/sysconfig/iptables
可以使用如下命令从指定的文件载入规则,注意:重载规则时,文件中的规则将会覆盖现有规则。
iptables-restore < /etc/sysconfig/iptables
四、匹配条件总结之一
匹配条件的更多用法
还是从我们最常用的”源地址”说起吧,我们知道,使用-s选项作为匹配条件,可以匹配报文的源地址,但是之前的示例中,我们每次指定源地址,都只是指定单个IP,示例如下。
其实,我们也可以在指定源地址时,一次指定多个,用”逗号”隔开即可,示例如下。
可以看出,上例中,一次添加了两条规则,两条规则只是源地址对应的IP不同,注意,上例中的”逗号”两侧均不能包含空格,多个IP之间必须与逗号相连。
除了能指定具体的IP地址,还能指定某个网段,示例如下
上例表示,如果报文的源地址IP在10.6.0.0/16网段内,当报文经过INPUT链时就会被DROP掉。
其实,我们还可以对匹配条件取反,先看示例,如下。
上图中,使用”! -s 192.168.1.146″表示对 -s 192.168.1.146这个匹配条件取反, -s 192.168.1.146表示报文源IP地址为192.168.1.146即可满足匹配条件,使用 “!” 取反后则表示,报文源地址IP只要不为192.168.1.146即满足条件,那么,上例中规则表达的意思就是,只要发往本机的报文的源地址不是192.168.1.146,就接受报文。
此刻,你猜猜,按照上例中的配置,如果此时从146主机上向防火墙所在的主机发送ping请求,146主机能得到回应吗?(此处不考虑其他链,只考虑filter表的INPUT链)
为了给你思考的空间,我把答案写的远一点。
答案是:能,也就是说,按照上例的配置,146主机仍然能够ping通当前主机,为什么呢?我们来分析一下。
上例中,filter表的INPUT链中只有一条规则,这条规则要表达的意思就是:
只要报文的源IP不是192.168.1.146,那么就接受此报文,但是,某些小伙伴可能会误会,把上例中的规则理解成如下含义,
只要报文的源IP是192.168.1.146,那么就不接受此报文,这种理解与上述理解看似差别不大,其实完全不一样,这样理解是错误的,上述理解才是正确的。
换句话说就是,报文的源IP不是192.168.1.146时,会被接收,并不能代表,报文的源IP是192.168.1.146时,会被拒绝。
上例中,因为并没有任何一条规则指明源IP是192.168.1.146时,该执行怎样的动作,所以,当来自192.168.1.146的报文经过INPUT链时,并不能匹配上例中的规则,于是,此报文就继续匹配后面的规则,可是,上例中只有一条规则,这条规则后面没有其他可以匹配的规则,于是,此报文就会去匹配当前链的默认动作(默认策略),而上例中,INPUT链的默认动作为ACCEPT,所以,来自146的ping报文就被接收了,如果,把上例中INPUT链的默认策略改为DROP,那么,146的报文将会被丢弃,146上的ping命令将得不到任何回应,但是如果将INPUT链的默认策略设置为DROP,当INPUT链中没有任何规则时,所有外来报文将会被丢弃,包括我们ssh远程连接。
好了,我们通过上例,不仅了解到了怎样对匹配条件取反,还加深了我们对默认策略的了解,一举两得,我们继续聊。
匹配条件:目标IP地址
除了可以通过-s选项指定源地址作为匹配条件,我们还可以使用-d选项指定”目标地址”作为匹配条件。
源地址表示报文从哪里来,目标地址表示报文要到哪里去。
除了127.0.0.1回环地址以外,当前机器有两个IP地址,IP如下。
假设,我们想要拒绝146主机发来的报文,但是我们只想拒绝146向156这个IP发送报文,并不想要防止146向101这个IP发送报文,我们就可以指定目标地址作为匹配条件,示例如下。
上例表示只丢弃从146发往156这个IP的报文,但是146发往101这个IP的报文并不会被丢弃,如果我们不指定任何目标地址,则目标地址默认为0.0.0.0/0,同理,如果我们不指定源地址,源地址默认为0.0.0.0/0,0.0.0.0/0表示所有IP,示例如下。
上例表示,所有IP发送往101的报文都将被丢弃。
与-s选项一样,-d选项也可以使用”叹号”进行取反,也能够同时指定多个IP地址,使用”逗号”隔开即可。
但是请注意,不管是-s选项还是-d选项,取反操作与同时指定多个IP的操作不能同时使用。
需要明确的一点就是:当一条规则中有多个匹配条件时,这多个匹配条件之间,默认存在”与”的关系。
说白了就是,当一条规则中存在多个匹配条件时,报文必须同时满足这些条件,才算做被规则匹配。
就如下例所示,下图中的规则包含有两个匹配条件,源地址与目标地址,报文必须同时能被这两个条件匹配,才算作被当前规则匹配,也就是说,下例中,报文必须来自146,同时报文的目标地址必须为101,才会被如下规则匹配,两个条件必须同时满足。
我们除了能够使用-s选项和-d选项匹配源IP与目标IP以外,还能够匹配”源端口”与”目标端口”,但是我们一会儿再聊怎样匹配端口,我们先聊聊其他选项。
匹配条件:协议类型
我们可以使用-p选项,指定需要匹配的报文的协议类型。
假设,我们只想要拒绝来自146的tcp类型的请求,那么可以进行如下设置
上图中,防火墙拒绝了来自146的tcp报文发往156这个IP,那么我们来测试一下,我们在146上使用ssh连接101这个IP试试(ssh协议的传输层协议属于tcp协议类型)
如上图所示,ssh连接被拒绝了,那么我们使用ping命令试试 (ping命令使用icmp协议),看看能不能ping通156。
可以看到,PING命令可以ping通156,证明icmp协议并没有被规则匹配到,只有tcp类型的报文被匹配到了。
那么,-p选项都支持匹配哪些协议呢?我们总结一下
centos6中,-p选项支持如下协议类型
tcp, udp, udplite, icmp, esp, ah, sctp
centos7中,-p选项支持如下协议类型
tcp, udp, udplite, icmp, icmpv6,esp, ah, sctp, mh
当不使用-p指定协议类型时,默认表示所有类型的协议都会被匹配到,与使用-p all的效果相同。
匹配条件:网卡接口
我们再来认识一个新的匹配条件,当本机有多个网卡时,我们可以使用 -i 选项去匹配报文是通过哪块网卡流入本机的。
我们先动手做个小例子,对-i选项有一个初步的了解以后,再结合理论去看。
当前主机的网卡名称为eth4,如下图
假设想要拒绝由网卡eth4流入的ping请求报文,则可以进行如下设置。
上图中,使用-i选项,指定网卡名称,使用-p选项,指定了需要匹配的报文协议类型,上例表示丢弃由eth4网卡流入的icmp类型的报文。
是不是很容易理解,但是,我们需要考虑一个问题,-i选项是用于匹配报文流入的网卡的,也就是说,从本机发出的报文是不可能会使用到-i选项的,因为这些由本机发出的报文压根不是从网卡流入的,而是要通过网卡发出的,从这个角度考虑,-i选项的使用是有限制的。
为了更好的解释-i选项,我们回顾一下在理论总结中的一张iptables全局报文流向图,如下。
既然-i选项是用于判断报文是从哪个网卡流入的,那么,-i选项只能用于上图中的PREROUTING链、INPUT链、FORWARD链,这是-i选项的特殊性,因为它只是用于判断报文是从哪个网卡流入的,所以只能在上图中”数据流入流向”的链中与FORWARD链中存在,而上图中的”数据发出流向”经过的链中,是不可能使用-i选项的,比如上图中的OUTPUT链与POSTROUTING链,他们都不能使用-i选项。
理解完-i选项,再来理解-o选项就好办了。
当主机有多块网卡时,可以使用-o选项,匹配报文将由哪块网卡流出,没错,-o选项与-i选项是相对的,-i选项用于匹配报文从哪个网卡流入,-o选项用于匹配报文将从哪个网卡流出。
聪明如你,一定想到了,-i选项只能用于PREROUTING链、INPUT链、FORWARD链,那么-o选项只能用于FORWARD链、OUTPUT链、POSTROUTING链。
因为-o选项是用于匹配报文将由哪个网卡”流出”的,所以与上图中的”数据进入流向”中的链没有任何缘分,所以,-o选项只能用于FORWARD链、OUTPUT链、POSTROUTING链中。
看来,FORWARD链属于”中立国”,它能同时使用-i选项与-o选项。
扩展匹配条件
好了,现在,我们就要聊聊,怎样匹配报文的”源端口”与”目标端口”。
在上文中,我们总结了”源地址”与”目标地址”以后,就顺便提到了”源端口”与”目标端口”,但是,为什么刚才不介绍”源端口”与”目标端口”,非要现在介绍呢?这是因为”源端口”与”目标端口”属于扩展匹配条件,”源地址”与”目标地址”属于基本匹配条件,上文中介绍到的匹配条件,都属于基本匹配条件,所以,我们单独把”源端口”与”目标端口”,放在后面总结,是为了引出扩展匹配条件的概念。
那么,先来了解一下,什么是扩展匹配条件。
不是基本匹配条件的就是扩展匹配条件,这样说好像是句废话,我们可以这样理解,基本匹配条件我们可以直接使用,而如果想要使用扩展匹配条件,则需要依赖一些扩展模块,或者说,在使用扩展匹配条件之前,需要指定相应的扩展模块才行,这样说不容易明白,我们做个例子,就能够明白。
我们知道,sshd服务的默认端口为22,当我们使用ssh工具远程连接主机时,默认会连接服务端的22号端口,假设,我们现在想要使用iptables设置一条规则,拒绝来自192.168.1.146的ssh请求,我们就可以拒绝146上的报文能够发往本机的22号端口,这个时候,就需要用到”目标端口”选项。
使用选项–dport可以匹配报文的目标端口,–dport意为destination-port,即表示目标端口。
注意,与之前的选项不同,–dport前有两条”横杠”,而且,使用–dport选项时,必须事先指定了使用哪种协议,即必须先使用-p选项,示例如下
上图中,我们就使用了扩展匹配条件–dport,指定了匹配报文的目标端口,如果外来报文的目标端口为本机的22号端口(ssh默认端口),则拒绝之,而在使用–dport之前,我们使用-m选项,指定了对应的扩展模块为tcp,也就是说,如果想要使用–dport这个扩展匹配条件,则必须依靠某个扩展模块完成,上例中,这个扩展模块就是tcp扩展模块,最终,我们使用的是tcp扩展模块中的dport扩展匹配条件。
现在,我们再回过头来看看扩展匹配条件的概念,就更加明白了。
扩展匹配条件被使用时,则需要依赖一些扩展模块,或者说,在使用扩展匹配条件之前,需要指定相应的扩展模块才行。
现在你明白了吗? -m tcp表示使用tcp扩展模块,–dport表示tcp扩展模块中的一个扩展匹配条件,可用于匹配报文的目标端口。
注意,-p tcp与 -m tcp并不冲突,-p用于匹配报文的协议,-m 用于指定扩展模块的名称,正好,这个扩展模块也叫tcp。
其实,上例中,我们可以省略-m选项,示例如下。
当使用-p选项指定了报文的协议时,如果在没有使用-m指定对应的扩展模块名称的情况下,使用了扩展匹配条件, iptables默认会调用与-p选项对应的协议名称相同的模块。
上例中,我们使用-p选项指定了协议名称,使用扩展匹配条件–dport指定了目标端口,在使用扩展匹配条件的时候,如果没有使用-m指定使用哪个扩展模块,iptables会默认使用”-m 协议名”,而协议名就是-p选项对应的协议名,上例中,-p 对应的值为tcp,所以默认调用的扩展模块就为-m tcp,如果-p对应的值为udp,那么默认调用的扩展模块就为-m udp。
所以,上例中,其实”隐式”的指定了扩展模块,只是没有表现出来罢了。
所以,在使用扩展匹配条件时,一定要注意,如果这个扩展匹配条件所依赖的扩展模块名正好与-p对应的协议名称相同,那么则可省略-m选项,否则则不能省略-m选项,必须使用-m选项指定对应的扩展模块名称,这样说可能还是不是特别明了,在后续的举例中,我们会更加明了的理解这些概念。
有”目标端口”,就有”源端口”,代表”源端口”的扩展匹配条件为–sport
使用–sport可以判断报文是否从指定的端口发出,即匹配报文的源端口是否与指定的端口一致,–sport表示source-port,即表示源端口之意。
因为我们已经搞明白了dport,那么sport我就不再赘述了,示例如下
上例中,隐含了”-m tcp”之意,表示使用了tcp扩展模块的–sport扩展匹配条件。
扩展匹配条件是可以取反的,同样是使用”!”进行取反,比如 “! –dport 22″,表示目标端口不是22的报文将会被匹配到。
不管是–sport还是–dsport,都能够指定一个端口范围,比如,–dport 22:25表示目标端口为22到25之间的所有端口,即22端口、23端口、24端口、25端口,示例如下
也可以写成如下图中的模样,下图中第一条规则表示匹配0号到22号之间的所有端口,下图中的第二条规则表示匹配80号端口以及其以后的所有端口(直到65535)。
刚才聊到的两个扩展匹配条件都是tcp扩展模块的,其实,tcp扩展模块还有一个比较有用的扩展匹配条件叫做”–tcp-flags”,但是由于篇幅原因,以后再对这个扩展匹配条件进行总结。
借助tcp扩展模块的–sport或者–dport都可以指定一个连续的端口范围,但是无法同时指定多个离散的、不连续的端口,如果想要同时指定多个离散的端口,需要借助另一个扩展模块,”multiport”模块。
我们可以使用multiport模块的–sports扩展条件同时指定多个离散的源端口。
我们可以使用multiport模块的–dports扩展条件同时指定多个离散的目标端口。
示例如下
上图示例表示,禁止来自146的主机上的tcp报文访问本机的22号端口、36号端口以及80号端口。
上图中,”-m multiport –dports 22,36,80″表示使用了multiport扩展模块的–dports扩展条件,以同时指定了多个离散的端口,每个端口之间用逗号隔开。
上图中的-m multiport是不能省略的,如果你省略了-m multiport,就相当于在没有指定扩展模块的情况下,使用了扩展条件(”–dports”),那么上例中,iptables会默认调用”-m tcp”,但是,”–dports扩展条件”并不属于”tcp扩展模块”,而是属于”multiport扩展模块”,所以,这时就会报错。
综上所述,当使用–dports或者–sports这种扩展匹配条件时,必须使用-m指定模块的名称。
其实,使用multiport模块的–sports与–dpors时,也可以指定连续的端口范围,并且能够在指定连续的端口范围的同时,指定离散的端口号,示例如下。
上例中的命令表示拒绝来自192.168.1.146的tcp报文访问当前主机的22号端口以及80到88之间的所有端口号,是不是很方便?有没有很灵活?
不过需要注意,multiport扩展只能用于tcp协议与udp协议,即配合-p tcp或者-p udp使用。
再回过头看之前的概念,我想,你应该就更加明白了。
今天,我们只是初步的认识了扩展模块,以及扩展匹配条件,还有一些模块我们并没有总结,好饭不怕晚,后续会有对它们的总结。
小结
这篇文章中,我们主要总结了一些常用的”基础匹配条件”,并且初步的认识了两个”扩展模块”以及这两个扩展模块中一些常用的扩展条件,为了方便以后回顾,我们将它们总结如下。
首先我们要明确一点,当规则中同时存在多个匹配条件时,多个条件之间默认存在”与”的关系,即报文必须同时满足所有条件,才能被规则匹配。
基本匹配条件总结
-s用于匹配报文的源地址,可以同时指定多个源地址,每个IP之间用逗号隔开,也可以指定为一个网段。
#示例如下
iptables -t filter -I INPUT -s 192.168.1.111,192.168.1.118 -j DROP
iptables -t filter -I INPUT -s 192.168.1.0/24 -j ACCEPT
iptables -t filter -I INPUT ! -s 192.168.1.0/24 -j ACCEPT
-d用于匹配报文的目标地址,可以同时指定多个目标地址,每个IP之间用逗号隔开,也可以指定为一个网段。
#示例如下
iptables -t filter -I OUTPUT -d 192.168.1.111,192.168.1.118 -j DROP
iptables -t filter -I INPUT -d 192.168.1.0/24 -j ACCEPT
iptables -t filter -I INPUT ! -d 192.168.1.0/24 -j ACCEPT
-p用于匹配报文的协议类型,可以匹配的协议类型tcp、udp、udplite、icmp、esp、ah、sctp等(centos7中还支持icmpv6、mh)。
#示例如下
iptables -t filter -I INPUT -p tcp -s 192.168.1.146 -j ACCEPT
iptables -t filter -I INPUT ! -p udp -s 192.168.1.146 -j ACCEPT
-i用于匹配报文是从哪个网卡接口流入本机的,由于匹配条件只是用于匹配报文流入的网卡,所以在OUTPUT链与POSTROUTING链中不能使用此选项。
#示例如下
iptables -t filter -I INPUT -p icmp -i eth4 -j DROP
iptables -t filter -I INPUT -p icmp ! -i eth4 -j DROP
-o用于匹配报文将要从哪个网卡接口流出本机,于匹配条件只是用于匹配报文流出的网卡,所以在INPUT链与PREROUTING链中不能使用此选项。
#示例如下
iptables -t filter -I OUTPUT -p icmp -o eth4 -j DROP
iptables -t filter -I OUTPUT -p icmp ! -o eth4 -j DROP
扩展匹配条件总结
我们来总结一下今天认识的两个扩展模块,以及其中的扩展条件(并非全部,只是这篇文章中介绍过的)
tcp扩展模块
常用的扩展匹配条件如下:
-p tcp -m tcp –sport 用于匹配tcp协议报文的源端口,可以使用冒号指定一个连续的端口范围
-p tcp -m tcp –dport 用于匹配tcp协议报文的目标端口,可以使用冒号指定一个连续的端口范围
#示例如下
iptables -t filter -I OUTPUT -d 192.168.1.146 -p tcp -m tcp --sport 22 -j REJECT
iptables -t filter -I INPUT -s 192.168.1.146 -p tcp -m tcp --dport 22:25 -j REJECT
iptables -t filter -I INPUT -s 192.168.1.146 -p tcp -m tcp --dport :22 -j REJECT
iptables -t filter -I INPUT -s 192.168.1.146 -p tcp -m tcp --dport 80: -j REJECT
iptables -t filter -I OUTPUT -d 192.168.1.146 -p tcp -m tcp ! --sport 22 -j ACCEPT
multiport扩展模块
常用的扩展匹配条件如下:
-p tcp -m multiport –sports 用于匹配报文的源端口,可以指定离散的多个端口号,端口之间用”逗号”隔开
-p udp -m multiport –dports 用于匹配报文的目标端口,可以指定离散的多个端口号,端口之间用”逗号”隔开
#示例如下
iptables -t filter -I OUTPUT -d 192.168.1.146 -p udp -m multiport --sports 137,138 -j REJECT
iptables -t filter -I INPUT -s 192.168.1.146 -p tcp -m multiport --dports 22,80 -j REJECT
iptables -t filter -I INPUT -s 192.168.1.146 -p tcp -m multiport ! --dports 22,80 -j REJECT
iptables -t filter -I INPUT -s 192.168.1.146 -p tcp -m multiport --dports 80:88 -j REJECT
iptables -t filter -I INPUT -s 192.168.1.146 -p tcp -m multiport --dports 22,80:88 -j REJECT
五、iptables匹配条件总结之二(常用扩展模块)
iprange扩展模块
之前我们已经总结过,在不使用任何扩展模块的情况下,使用-s选项或者-d选项即可匹配报文的源地址与目标地址,而且在指定IP地址时,可以同时指定多个IP地址,每个IP用”逗号”隔开,但是,-s选项与-d选项并不能一次性的指定一段连续的IP地址范围,如果我们需要指定一段连续的IP地址范围,可以使用iprange扩展模块。
使用iprange扩展模块可以指定”一段连续的IP地址范围”,用于匹配报文的源地址或者目标地址。
iprange扩展模块中有两个扩展匹配条件可以使用
–src-range
–dst-range
没错,见名知意,上述两个选项分别用于匹配报文的源地址所在范围与目标地址所在范围。
示例如下:
上例表示如果报文的源IP地址如果在192.168.1.127到192.168.1.146之间,则丢弃报文,IP段的始末IP使用”横杠”连接,–src-range与–dst-range和其他匹配条件一样,能够使用”!”取反,有了前文中的知识作为基础,此处就不再赘述了。
string扩展模块
使用string扩展模块,可以指定要匹配的字符串,如果报文中包含对应的字符串,则符合匹配条件。
比如,如果报文中包含字符”OOXX”,我们就丢弃当前报文。
首先,我们在IP为146的主机上启动http服务,然后在默认的页面目录中添加两个页面,页面中的内容分别为”OOXX”和”Hello World”,如下图所示,在没有配置任何规则时,126主机可以正常访问146主机上的这两个页面。
那么,我们想要达到的目的是,如果报文中包含”OOXX”字符,我们就拒绝报文进入本机,所以,我们可以在126上进行如下配置。
上图中,’-m string’表示使用string模块,’–algo bm’表示使用bm算法去匹配指定的字符串,’ –string “OOXX” ‘则表示我们想要匹配的字符串为”OOXX”
设置完上图中的规则后,由于index.html中包含”OOXX”字符串,所以,146的回应报文无法通过126的INPUT链,所以无法获取到页面对应的内容。
那么,我们来总结一下string模块的常用选项
–algo:用于指定匹配算法,可选的算法有bm与kmp,此选项为必须选项,我们不用纠结于选择哪个算法,但是我们必须指定一个。
–string:用于指定需要匹配的字符串。
time扩展模块
我们可以通过time扩展模块,根据时间段区匹配报文,如果报文到达的时间在指定的时间范围以内,则符合匹配条件。
比如,”我想要自我约束,每天早上9点到下午6点不能看网页”,擦,多么残忍的规定,如果你想要这样定义,可以尝试使用如下规则。
上图中”-m time”表示使用time扩展模块,–timestart选项用于指定起始时间,–timestop选项用于指定结束时间。
如果你想要换一种约束方法,只有周六日不能看网页,那么可以使用如下规则。
没错,如你所见,使用–weekdays选项可以指定每个星期的具体哪一天,可以同时指定多个,用逗号隔开,除了能够数字表示”星期几”,还能用缩写表示,例如:Mon, Tue, Wed, Thu, Fri, Sat, Sun
当然,你也可以将上述几个选项结合起来使用,比如指定只有周六日的早上9点到下午6点不能浏览网页。
聪明如你一定想到了,既然有–weekdays选项了,那么有没有–monthdays选项呢?必须有啊!
使用–monthdays选项可以具体指定的每个月的哪一天,比如,如下图设置表示指明每月的22号,23号。
前文已经总结过,当一条规则中同时存在多个条件时,多个条件之间默认存在”与”的关系,所以,下图中的设置表示匹配的时间必须为星期5,并且这个”星期5″同时还需要是每个月的22号到28号之间的一天,所以,下图中的设置表示每个月的第4个星期5
除了使用–weekdays选项与–monthdays选项,还可以使用–datestart 选项与-datestop选项,指定具体的日期范围,如下。
上图中指定的日期范围为2017年12月24日到2017年12月27日
上述选项中,–monthdays与–weekdays可以使用”!”取反,其他选项不能取反。
connlimit扩展模块
使用connlimit扩展模块,可以限制每个IP地址同时链接到server端的链接数量,注意:我们不用指定IP,其默认就是针对”每个客户端IP”,即对单IP的并发连接数限制。
比如,我们想要限制,每个IP地址最多只能占用两个ssh链接远程到server端,我们则可以进行如下限制。
上例中,使用”-m connlimit”指定使用connlimit扩展,使用”–connlimit-above 2″表示限制每个IP的链接数量上限为2,再配合-p tcp –dport 22,即表示限制每个客户端IP的ssh并发链接数量不能高于2。
centos6中,我们可以对–connlimit-above选项进行取反,没错,老规矩,使用”!”对此条件进行取反,示例如下
上例表示,每个客户端IP的ssh链接数量只要不超过两个,则允许链接。
但是聪明如你一定想到了,上例的规则并不能表示:每个客户端IP的ssh链接数量超过两个则拒绝链接(与前文中的举例原理相同,此处不再赘述,如果你不明白,请参考之前的文章)。也就是说,即使我们配置了上例中的规则,也不能达到”限制”的目的,所以我们通常并不会对此选项取反,因为既然使用了此选项,我们的目的通常就是”限制”连接数量。
centos7中iptables为我们提供了一个新的选项,–connlimit-upto,这个选项的含义与”! –commlimit-above”的含义相同,即链接数量未达到指定的连接数量之意,所以综上所述,–connlimit-upto选项也不常用。
刚才说过,–connlimit-above默认表示限制”每个IP”的链接数量,其实,我们还可以配合–connlimit-mask选项,去限制”某类网段”的链接数量,示例如下:
(注:下例需要一定的网络知识基础,如果你还不了解它们,可以选择先跳过此选项或者先去学习部分的网络知识)
上例中,”–connlimit-mask 24″表示某个C类网段,没错,mask为掩码之意,所以将24转换成点分十进制就表示255.255.255.0,所以,上图示例的规则表示,一个最多包含254个IP的C类网络中,同时最多只能有2个ssh客户端连接到当前服务器,看来资源很紧俏啊!254个IP才有2个名额,如果一个IP同时把两个连接名额都占用了,那么剩下的253个IP连一个连接名额都没有了,那么,我们再看看下例,是不是就好多了。
上例中,”–connlimit-mask 27″表示某个C类网段,通过计算后可以得知,这个网段中最多只能有30台机器(30个IP),这30个IP地址最多只能有10个ssh连接同时连接到服务器端,是不是比刚才的设置大方多了,当然,这样并不能避免某个IP占用所有连接的情况发生,假设,报文来自192.168.1.40这个IP,按照掩码为27进行计算,这个IP属于192.168.1.32/27网段,如果192.168.1.40同时占用了10个ssh连接,那么当192.168.1.51这个IP向服务端发起ssh连接请求时,同样会被拒绝,因为192.168.1.51这个IP按照掩码为27进行计算,也是属于192.168.1.32/27网段,所以他们共享这10个连接名额。
聪明如你一定明白了,在不使用–connlimit-mask的情况下,连接数量的限制是针对”每个IP”而言的,当使用了–connlimit-mask选项以后,则可以针对”某类IP段内的一定数量的IP”进行连接数量的限制,这样就能够灵活许多,不是吗?
limit扩展模块
刚才认识了connlimit模块,现在来认识一下limit模块。
connlimit模块是对连接数量进行限制的,limit模块是对”报文到达速率”进行限制的。
用大白话说就是,如果我想要限制单位时间内流入的包的数量,就能用limit模块。
我们可以以秒为单位进行限制,也可以以分钟、小时、天作为单位进行限制。
比如,限制每秒中最多流入3个包,或者限制每分钟最多流入30个包,都可以。
那么,我们来看一个最简单的示例,假设,我们想要限制,外部主机对本机进行ping操作时,本机最多每6秒中放行一个ping包,那么,我们可以进行如下设置(注意,只进行如下设置有可能无法实现限制功能,请看完后面的内容)
上例中,”-p icmp”表示我们针对ping请求添加了一条规则(ping使用icmp协议),”-m limit”表示使用limit模块, “–limit 10/minute -j ACCEPT”表示每分钟最多放行10个包,就相当于每6秒钟最多放行一个包,换句话说,就是每过6秒钟放行一个包,那么配置完上述规则后,我们在另外一台机器上对当前机器进行ping操作,看看是否能够达到限制的目的,如下图所示。
我们发现,刚才配置的规则并没有如我们想象中的一样,ping请求的响应速率完全没有发生任何变化,为什么呢?我们一起来分析一下。
我们再来回顾一下刚才配置的规则。
其实,我们可以把上图中的规则理解为如下含义。
每6秒放行一个包,那么iptables就会计时,每6秒一个轮次,到第6秒时,达到的报文就会匹配到对应的规则,执行对应的动作,而上图中的动作是ACCEPT。
那么在第6秒之前到达的包,则无法被上述规则匹配到。
之前总结过,报文会匹配链中的每一条规则,如果没有任何一条规则能够匹配到,则匹配默认动作(链的默认策略)。
既然第6秒之前的包没有被上述规则匹配到,而我们又没有在INPUT链中配置其他规则,所以,第6秒之前的包肯定会被默认策略匹配到,那么我们看看默认策略是什么。
现在再想想,我想你应该明白为什么刚才的ping的响应速率没有变化了。
因为,上例中,第六秒的报文的确被对应的规则匹配到了,于是执行了”放行”操作,第6秒之前的报文没有被上图中配置的规则匹配到,但是被默认策略匹配到了,而恰巧,默认动作也是ACCEPT,所以,相当于所有的ping报文都被放行了,怪不得与没有配置规则时的速率一毛一样了。
那么,知错就改,聪明如你一定想到了,我们可以修改INPUT链的默认策略,或者在上例限制规则的后面再加入一条规则,将”漏网之鱼”匹配到即可,示例如下。
如上图所示,第一条规则表示每分钟最多放行10个icmp包,也就是6秒放行一个,第6秒的icmp包会被上例中的第一条规则匹配到,第6秒之前的包则不会被第一条规则匹配到,于是被后面的拒绝规则匹配到了,那么,此刻,我们再来试试,看看ping的报文放行速率有没有发生改变。
如下图所示
刚开始还真吓我一跳,难道配置的规则还是有问题?
结果发现,只有前5个ping包没有受到限制,之后的ping包已经开始受到了规则的限制了。
从上图可以看出,除了前5个ping包以外,之后的ping包差不多每6秒才能ping通一次,看来,之后的ping包已经受到了规则的控制,被限制了流入防火墙的速率了,那么,前5个ping包是什么鬼?为什么它们不受规则限制呢?其实,这个现象正好引出另一个话题,出现上图中的情况,是因为另一个选项:”–limit-burst”
limit-burst选项是干什么用的呢?我们先用不准确的大白话描述一遍,”–limit-burst”可以指定”空闲时可放行的包的数量”,其实,这样说并不准确,但是我们可以先这样大概的理解,在不使用”–limit-burst”选项明确指定放行包的数量时,默认值为5,所以,才会出现上图中的情况,前5个ping包并没有受到任何速率限制,之后的包才受到了规则的限制。
如果想要彻底了解limit模块的工作原理,我们需要先了解一下”令牌桶”算法,因为limit模块使用了令牌桶算法。
我们可以这样想象,有一个木桶,木桶里面放了5块令牌,而且这个木桶最多也只能放下5块令牌,所有报文如果想要出关入关,都必须要持有木桶中的令牌才行,这个木桶有一个神奇的功能,就是每隔6秒钟会生成一块新的令牌,如果此时,木桶中的令牌不足5块,那么新生成的令牌就存放在木桶中,如果木桶中已经存在5块令牌,新生成的令牌就无处安放了,只能溢出木桶(令牌被丢弃),如果此时有5个报文想要入关,那么这5个报文就去木桶里找令牌,正好一人一个,于是他们5个手持令牌,快乐的入关了,此时木桶空了,再有报文想要入关,已经没有对应的令牌可以使用了,但是,过了6秒钟,新的令牌生成了,此刻,正好来了一个报文想要入关,于是,这个报文拿起这个令牌,就入关了,在这个报文之后,如果很长一段时间内没有新的报文想要入关,木桶中的令牌又会慢慢的积攒了起来,直到达到5个令牌,并且一直保持着5个令牌,直到有人需要使用这些令牌,这就是令牌桶算法的大致逻辑。
那么,就拿刚才的”令牌桶”理论类比我们的命令,”–limit”选项就是用于指定”多长时间生成一个新令牌的”,”–limit-burst”选项就是用于指定”木桶中最多存放几个令牌的”,现在,你明白了吗??示例如下
上例表示,令牌桶中最多能存放3个令牌,每分钟生成10个令牌(即6秒钟生成一个令牌)。
之前说过,使用”–limit”选项时,可以选择的时间单位有多种,如下
/second
/minute
/hour
/day
比如,3/second表示每秒生成3个”令牌”,30/minute表示没分钟生成30个”令牌”。
我不知道我到底解释清楚没有,我感觉我解释清楚了,哥们儿你赶紧动手试试吧。
小结
老规矩,为了方便以后回顾,我们将上文中提到的命令总结如下。
iprange模块
包含的扩展匹配条件如下
–src-range:指定连续的源地址范围
–dst-range:指定连续的目标地址范围
#示例
iptables -t filter -I INPUT -m iprange --src-range 192.168.1.127-192.168.1.146 -j DROP
iptables -t filter -I OUTPUT -m iprange --dst-range 192.168.1.127-192.168.1.146 -j DROP
iptables -t filter -I INPUT -m iprange ! --src-range 192.168.1.127-192.168.1.146 -j DROP
string模块
常用扩展匹配条件如下
–algo:指定对应的匹配算法,可用算法为bm、kmp,此选项为必需选项。
–string:指定需要匹配的字符串
#示例
iptables -t filter -I INPUT -p tcp --sport 80 -m string --algo bm --string "OOXX" -j REJECT
iptables -t filter -I INPUT -p tcp --sport 80 -m string --algo bm --string "OOXX" -j REJECT
time模块
常用扩展匹配条件如下
–timestart:用于指定时间范围的开始时间,不可取反
–timestop:用于指定时间范围的结束时间,不可取反
–weekdays:用于指定”星期几”,可取反
–monthdays:用于指定”几号”,可取反
–datestart:用于指定日期范围的开始日期,不可取反
–datestop:用于指定日期范围的结束时间,不可取反
#示例
iptables -t filter -I OUTPUT -p tcp --dport 80 -m time --timestart 09:00:00 --timestop 19:00:00 -j REJECT
iptables -t filter -I OUTPUT -p tcp --dport 443 -m time --timestart 09:00:00 --timestop 19:00:00 -j REJECT
iptables -t filter -I OUTPUT -p tcp --dport 80 -m time --weekdays 6,7 -j REJECT
iptables -t filter -I OUTPUT -p tcp --dport 80 -m time --monthdays 22,23 -j REJECT
iptables -t filter -I OUTPUT -p tcp --dport 80 -m time ! --monthdays 22,23 -j REJECT
iptables -t filter -I OUTPUT -p tcp --dport 80 -m time --timestart 09:00:00 --timestop 18:00:00 --weekdays 6,7 -j REJECT
iptables -t filter -I OUTPUT -p tcp --dport 80 -m time --weekdays 5 --monthdays 22,23,24,25,26,27,28 -j REJECT
iptables -t filter -I OUTPUT -p tcp --dport 80 -m time --datestart 2017-12-24 --datestop 2017-12-27 -j REJECT
connlimit 模块
常用的扩展匹配条件如下
–connlimit-above:单独使用此选项时,表示限制每个IP的链接数量。
–connlimit-mask:此选项不能单独使用,在使用–connlimit-above选项时,配合此选项,则可以针对”某类IP段内的一定数量的IP”进行连接数量的限制,如果不明白可以参考上文的详细解释。
#示例
iptables -I INPUT -p tcp --dport 22 -m connlimit --connlimit-above 2 -j REJECT
iptables -I INPUT -p tcp --dport 22 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j REJECT
iptables -I INPUT -p tcp --dport 22 -m connlimit --connlimit-above 10 --connlimit-mask 27 -j REJECT
limit模块
常用的扩展匹配条件如下
–limit-burst:类比”令牌桶”算法,此选项用于指定令牌桶中令牌的最大数量,上文中已经详细的描述了”令牌桶”的概念,方便回顾。
–limit:类比”令牌桶”算法,此选项用于指定令牌桶中生成新令牌的频率,可用时间单位有second、minute 、hour、day。
#示例 #注意,如下两条规则需配合使用,具体原因上文已经解释过,忘记了可以回顾。
iptables -t filter -I INPUT -p icmp -m limit --limit-burst 3 --limit 10/minute -j ACCEPT
iptables -t filter -A INPUT -p icmp -j REJECT
六、iptables扩展匹配条件之’–tcp-flags’
如果你看过前文,那么你一定知道,前文已经对”tcp扩展模块”做过总结,但是只总结了tcp扩展模块中的”–sport”与”–dport”选项,并没有总结”–tcp-flags”选项,那么此处,我们就来认识一下tcp扩展模块中的”–tcp-flags”。
注:阅读这篇文章之前,需要对tcp协议的基础知识有一定的了解,比如:tcp头的结构、tcp三次握手的过程。
见名知义,”–tcp-flags”指的就是tcp头中的标志位,看来,在使用iptables时,我们可以通过此扩展匹配条件,去匹配tcp报文的头部的标识位,然后根据标识位的实际情况实现访问控制的功能。
既然说到了tcp头中的标志位,那么我们就来回顾一下tcp头的结构,如下图所示。
在使用iptables时,使用tcp扩展模块的”–tcp-flags”选项,即可对上图中的标志位进行匹配,判断指定的标志位的值是否为”1″,而tcp header的结构不是我们今天讨论的重点,我们继续聊tcp的标识位,在tcp协议建立连接的过程中,需要先进行三次握手,而三次握手就要依靠tcp头中的标志位进行。
为了更加具象化的描述这个过程,我们可以抓包查看ssh建立连接的过程,如下图所示(使用wireshark在ssh客户端抓包,跟踪对应的tcp流):
上图为tcp三次握手中的第一次握手,客户端(IP为98)使用本地的随机端口54808向服务端(IP为137)发起连接请求,tcp头的标志位中,只有SYN位被标识为1,其他标志位均为0。
在上图的下方可以看到”[TCP Flags: ··········S·]”,其中的”S”就表示SYN位,整体表示只有SYN位为1。
上图为tcp三次握手中第一次握手的tcp头中的标志位,下图是第二次握手的,服务端回应刚才的请求,将自己的tcp头的SYN标志位也设置为1,同时将ACK标志位也设置为1,如下图所示。
上图中的下方显示的标志位列表也变成了,[TCP Flags: ·······A··S·],表示只有ACK标志位与SYN标志位为1,如上图所示,第三次握手我就不再截图了,说到这里,就已经能够引出我们今天要说的话题了,就是”–tcp-flags”选项,假设,我现在想要匹配到上文中提到的”第一次握手”的报文,则可以使用如下命令:
上图中,”-m tcp –dport 22″的含义在前文中已经总结过,表示使用tcp扩展模块,指定目标端口为22号端口(ssh默认端口),”–tcp-flags”就是我们今天要讨论的扩展匹配条件,用于匹配报文tcp头部的标志位,”SYN,ACK,FIN,RST,URG,PSH SYN”是什么意思呢?这串字符就是用于配置我们要匹配的标志位的,我们可以把这串字符拆成两部分去理解,第一部分为”SYN,ACK,FIN,RST,URG,PSH”,第二部分为”SYN”。
第一部分表示:我们需要匹配报文tcp头中的哪些标志位,那么上例的配置表示,我们需要匹配报文tcp头中的6个标志位,这6个标志位分别为为”SYN、ACK、FIN、RST、URG、PSH”,我们可以把这一部分理解成需要匹配的标志位列表。
第二部分表示:第一部分的标志位列表中,哪些标志位必须为1,上例中,第二部分为SYN,则表示,第一部分需要匹配的标志位列表中,SYN标志位的值必须为1,其他标志位必须为0。
所以,上例中的”SYN,ACK,FIN,RST,URG,PSH SYN”表示,需要匹配报文tcp头中的”SYN、ACK、FIN、RST、URG、PSH”这些标志位,其中SYN标志位必须为1,其他的5个标志位必须为0,这与上文中wireshark抓包时的情况相同,正是tcp三次握手时第一次握手时的情况,上文中第一次握手的报文的tcp头中的标志位如下:
其实,–tcp-flags的表示方法与wireshark的表示方法有异曲同工之妙,只不过,wireshark中,标志位为0的用”点”表示,标志位为1的用对应字母表示,在–tcp-flags中,需要先指明需要匹配哪些标志位,然后再指明这些标志位中,哪些必须为1,剩余的都必须为0。
那么,聪明如你一定想到了,如果我想要匹配tcp头中的第二次握手时的标志位的情况,该怎么表示呢?
示例如下(此处省略对源地址与目标地址的匹配,重点在于对tcp-flags的示例)
上图中,第一条命令匹配到的报文是第一次握手的报文,第二条命令匹配到的报文是第二次握手的报文。
综上所述,只要我们能够灵活的配置上例中的标志位,即可匹配到更多的应用场景中。
其实,上例中的两条命令还可以简写为如下模样
没错,我们可以用ALL表示”SYN,ACK,FIN,RST,URG,PSH”。
其实,tcp扩展模块还为我们专门提供了一个选项,可以匹配上文中提到的”第一次握手”,那就是–syn选项
使用”–syn”选项相当于使用”–tcp-flags SYN,RST,ACK,FIN SYN”,也就是说,可以使用”–syn”选项去匹配tcp新建连接的请求报文。
示例如下:
小结
结合之前的文章,我们把tcp模块的常用扩展匹配条件再总结一遍,方便以后回顾。
tcp扩展模块常用的扩展匹配条件如下:
–sport
用于匹配tcp协议报文的源端口,可以使用冒号指定一个连续的端口范围
#示例
iptables -t filter -I OUTPUT -d 192.168.1.146 -p tcp -m tcp --sport 22 -j REJECT
iptables -t filter -I OUTPUT -d 192.168.1.146 -p tcp -m tcp --sport 22:25 -j REJECT
iptables -t filter -I OUTPUT -d 192.168.1.146 -p tcp -m tcp ! --sport 22 -j ACCEPT
–dport
用于匹配tcp协议报文的目标端口,可以使用冒号指定一个连续的端口范围
#示例
iptables -t filter -I INPUT -s 192.168.1.146 -p tcp -m tcp --dport 22:25 -j REJECT
iptables -t filter -I INPUT -s 192.168.1.146 -p tcp -m tcp --dport :22 -j REJECT
iptables -t filter -I INPUT -s 192.168.1.146 -p tcp -m tcp --dport 80: -j REJECT
–tcp-flags
用于匹配报文的tcp头的标志位
#示例
iptables -t filter -I INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,ACK,FIN,RST,URG,PSH SYN -j REJECT
iptables -t filter -I OUTPUT -p tcp -m tcp --sport 22 --tcp-flags SYN,ACK,FIN,RST,URG,PSH SYN,ACK -j REJECT
iptables -t filter -I INPUT -p tcp -m tcp --dport 22 --tcp-flags ALL SYN -j REJECT
iptables -t filter -I OUTPUT -p tcp -m tcp --sport 22 --tcp-flags ALL SYN,ACK -j REJECT
–syn
用于匹配tcp新建连接的请求报文,相当于使用”–tcp-flags SYN,RST,ACK,FIN SYN”
#示例
iptables -t filter -I INPUT -p tcp -m tcp --dport 22 --syn -j REJECT
七、iptables扩展之udp扩展与icmp扩展
前文中总结了iptables的tcp扩展模块,此处,我们来总结一下另外两个跟协议有关的常用的扩展模块,udp扩展与icmp扩展。
udp扩展
我们先来说说udp扩展模块,这个扩展模块中能用的匹配条件比较少,只有两个,就是–sport与–dport,即匹配报文的源端口与目标端口。
没错,tcp模块中也有这两个选项,名称都一模一样。
只不过udp扩展模块的–sport与–dport是用于匹配UDP协议报文的源端口与目标端口,比如,放行samba服务的137与138这两个UDP端口,示例如下
前文说明过,当使用扩展匹配条件时,如果未指定扩展模块,iptables会默认调用与”-p”对应的协议名称相同的模块,所以,当使用”-p udp”时,可以省略”-m udp”,示例如下。
udp扩展中的–sport与–dport同样支持指定一个连续的端口范围,示例如下
上图中的配置表示137到157之间的所有udp端口全部对外开放,其实与tcp扩展中的使用方法相同。
但是udp中的–sport与–dport也只能指定连续的端口范围,并不能一次性指定多个离散的端口,没错,聪明如你一定想到,使用之前总结过的multiport扩展模块,即可指定多个离散的UDP端口,如果你忘了multiport模块怎样使用,请回顾前文。
总之有了前文的基础,再理解上述示例就容易多了,此处不再对udp模块的–sport与–dport进行赘述。
icmp扩展
最常用的tcp扩展、udp扩展已经总结完毕,现在聊聊icmp扩展,没错,看到icmp,你肯定就想到了ping命令,因为ping命令使用的就是icmp协议。
ICMP协议的全称为Internet Control Message Protocol,翻译为互联网控制报文协议,它主要用于探测网络上的主机是否可用,目标是否可达,网络是否通畅,路由是否可用等。
我们平常使用ping命令ping某主机时,如果主机可达,对应主机会对我们的ping请求做出回应(此处不考虑禁ping等情况),也就是说,我们发出ping请求,对方回应ping请求,虽然ping请求报文与ping回应报文都属于ICMP类型的报文,但是如果在概念上细分的话,它们所属的类型还是不同的,我们发出的ping请求属于类型8的icmp报文,而对方主机的ping回应报文则属于类型0的icmp报文,根据应用场景的不同,icmp报文被细分为如下各种类型。
从上图可以看出,所有表示”目标不可达”的icmp报文的type码为3,而”目标不可达”又可以细分为多种情况,是网络不可达呢?还是主机不可达呢?再或者是端口不可达呢?所以,为了更加细化的区分它们,icmp对每种type又细分了对应的code,用不同的code对应具体的场景, 所以,我们可以使用type/code去匹配具体类型的ICMP报文,比如可以使用”3/1″表示主机不可达的icmp报文。
上图中的第一行就表示ping回应报文,它的type为0,code也为0,从上图可以看出,ping回应报文属于查询类(query)的ICMP报文,从大类上分,ICMP报文还能分为查询类与错误类两大类,目标不可达类的icmp报文则属于错误类报文。
而我们发出的ping请求报文对应的type为8,code为0。
了解完上述概念,就好办了,我们来看一些应用场景。
假设,我们现在想要禁止所有icmp类型的报文进入本机,那么我们可以进行如下设置。
上例中,我们并没有使用任何扩展匹配条件,我们只是使用”-p icmp”匹配了所有icmp协议类型的报文。
如果进行了上述设置,别的主机向我们发送的ping请求报文无法进入防火墙,我们向别人发送的ping请求对应的回应报文也无法进入防火墙。所以,我们既无法ping通别人,别人也无法ping通我们。
假设,此刻需求有变,我们只想要ping通别人,但是不想让别人ping通我们,刚才的配置就不能满足我们了,我们则可以进行如下设置(此处不考虑禁ping的情况)
上图中,使用”-m icmp”表示使用icmp扩展,因为上例中使用了”-p icmp”,所以”-m icmp”可以省略,使用”–icmp-type”选项表示根据具体的type与code去匹配对应的icmp报文,而上图中的”–icmp-type 8/0″表示icmp报文的type为8,code为0才会被匹配到,也就是只有ping请求类型的报文才能被匹配到,所以,别人对我们发起的ping请求将会被拒绝通过防火墙,而我们之所以能够ping通别人,是因为别人回应我们的报文的icmp type为0,code也为0,所以无法被上述规则匹配到,所以我们可以看到别人回应我们的信息。
因为type为8的类型下只有一个code为0的类型,所以我们可以省略对应的code,示例如下
除了能够使用对应type/code匹配到具体类型的icmp报文以外,我们还能用icmp报文的描述名称去匹配对应类型的报文,示例如下
没错,上例中使用的 –icmp-type “echo-request”与 –icmp-type 8/0的效果完全相同,参考本文最上方的表格即可获取对应的icmp类型的描述名称。
注意:名称中的”空格”需要替换为”-“。
小结
udp扩展
常用的扩展匹配条件
–sport:匹配udp报文的源地址
–dport:匹配udp报文的目标地址
#示例
iptables -t filter -I INPUT -p udp -m udp --dport 137 -j ACCEPT
iptables -t filter -I INPUT -p udp -m udp --dport 137:157 -j ACCEPT
#可以结合multiport模块指定多个离散的端口
icmp扩展
常用的扩展匹配条件
–icmp-type:匹配icmp报文的具体类型
#示例
iptables -t filter -I INPUT -p icmp -m icmp --icmp-type 8/0 -j REJECT
iptables -t filter -I INPUT -p icmp --icmp-type 8 -j REJECT
iptables -t filter -I OUTPUT -p icmp -m icmp --icmp-type 0/0 -j REJECT
iptables -t filter -I OUTPUT -p icmp --icmp-type 0 -j REJECT
iptables -t filter -I INPUT -p icmp --icmp-type "echo-request" -j REJECT
八、iptables扩展模块之state扩展
当我们通过http的url访问某个网站的网页时,客户端向服务端的80端口发起请求,服务端再通过80端口响应我们的请求,于是,作为客户端,我们似乎应该理所应当的放行80端口,以便服务端回应我们的报文可以进入客户端主机,于是,我们在客户端放行了80端口,同理,当我们通过ssh工具远程连接到某台服务器时,客户端向服务端的22号端口发起请求,服务端再通过22号端口响应我们的请求,于是我们理所应当的放行了所有22号端口,以便远程主机的响应请求能够通过防火墙,但是,作为客户端,如果我们并没有主动向80端口发起请求,也没有主动向22号端口发起请求,那么其他主机通过80端口或者22号端口向我们发送数据时,我们可以接收到吗?应该是可以的,因为我们为了收到http与ssh的响应报文,已经放行了80端口与22号端口,所以,不管是”响应”我们的报文,还是”主动发送”给我们的报文,应该都是可以通过这两个端口的,那么仔细想想,这样是不是不太安全呢?如果某些与你敌对的人,利用这些端口”主动”连接到你的主机,你肯定会不爽的吧,一般都是我们主动请求80端口,80端口回应我们,但是一般不会出现80端口主动请求我们的情况吧。
你心里可能会这样想:我知道哪些主机是安全的,我只要针对这些安全的主机放行对应的端口就行了,其他IP一律拒绝,比如,我知道IP为123的主机是安全的,所以,我对123主机开放了22号端口,以便123主机能够通过22号端口响应我们的ssh请求,那么,如果你需要管理的主机越来越多呢?你是不是每次都要为新的主机配置这些规则呢?如果有30台主机呢?如果有300台主机呢?80端口就更别提了,难道你每次访问一个新的网址,都要对这个网址添加信任吗?这显然不太合理。
你心里可能又会想:针对对应的端口,我用–tcp-flags去匹配tcp报文的标志位,把外来的”第一次握手”的请求拒绝,是不是也可以呢?那么如果对方使用的是UDP协议或者ICMP协议呢?似乎总是有一些不完美的地方。
那么我们仔细的思考一下,造成上述问题的”根源”在哪里,我们为了让”提供服务方”能够正常的”响应”我们的请求,于是在主机上开放了对应的端口,开放这些端口的同时,也出现了问题,别人利用这些开放的端口,”主动”的攻击我们,他们发送过来的报文并不是为了响应我们,而是为了主动攻击我们,好了,我们似乎找到了问题所在?
问题就是:怎样判断这些报文是为了回应我们之前发出的报文,还是主动向我们发送的报文呢?
我们可以通过iptables的state扩展模块解决上述问题,但是我们需要先了解一些state模块的相关概念,然后再回过头来解决上述问题。
从字面上理解,state可以译为状态,但是我们也可以用一个高大上的词去解释它,state模块可以让iptables实现”连接追踪”机制。
那么,既然是”连接追踪”,则必然要有”连接”。
咱们就来聊聊什么是连接吧,一说到连接,你可能会下意识的想到tcp连接,但是,对于state模块而言的”连接”并不能与tcp的”连接”画等号,在TCP/IP协议簇中,UDP和ICMP是没有所谓的连接的,但是对于state模块来说,tcp报文、udp报文、icmp报文都是有连接状态的,我们可以这样认为,对于state模块而言,只要两台机器在”你来我往”的通信,就算建立起了连接,如下图所示
而报文在这个所谓的链接中是什么状态的呢?这是我们后面讨论的话题。
对于state模块的连接而言,”连接”其中的报文可以分为5种状态,报文状态可以为NEW、ESTABLISHED、RELATED、INVALID、UNTRACKED
那么上述报文的状态都代表什么含义呢?我们先来大概的了解一下概念,然后再结合示例说明。
注意:如下报文状态都是对于state模块来说的。
NEW:连接中的第一个包,状态就是NEW,我们可以理解为新连接的第一个包的状态为NEW。
ESTABLISHED:我们可以把NEW状态包后面的包的状态理解为ESTABLISHED,表示连接已建立。
或许用图说话更容易被人理解
RELATED:从字面上理解RELATED译为关系,但是这样仍然不容易理解,我们举个例子。
比如FTP服务,FTP服务端会建立两个进程,一个命令进程,一个数据进程。
命令进程负责服务端与客户端之间的命令传输(我们可以把这个传输过程理解成state中所谓的一个”连接”,暂称为”命令连接”)。
数据进程负责服务端与客户端之间的数据传输 ( 我们把这个过程暂称为”数据连接” )。
但是具体传输哪些数据,是由命令去控制的,所以,”数据连接”中的报文与”命令连接”是有”关系”的。
那么,”数据连接”中的报文可能就是RELATED状态,因为这些报文与”命令连接”中的报文有关系。
(注:如果想要对ftp进行连接追踪,需要单独加载对应的内核模块nf_conntrack_ftp,如果想要自动加载,可以配置/etc/sysconfig/iptables-config文件)
INVALID:如果一个包没有办法被识别,或者这个包没有任何状态,那么这个包的状态就是INVALID,我们可以主动屏蔽状态为INVALID的报文。
UNTRACKED:报文的状态为untracked时,表示报文未被追踪,当报文的状态为Untracked时通常表示无法找到相关的连接。
好了,我们已经大致了解了state模块中所定义的5种状态,那么现在,我们回过头想想刚才的问题。
刚才问题的根源就是:怎样判断报文是否是为了回应之前发出的报文。
刚才举例中的问题即可使用state扩展模块解决,我们只要放行状态为ESTABLISHED的报文即可,因为如果报文的状态为ESTABLISHED,那么报文肯定是之前发出的报文的回应,如果你还不放心,可以将状态为RELATED或ESTABLISHED的报文都放行,这样,就表示只有回应我们的报文能够通过防火墙,如果是别人主动发送过来的新的报文,则无法通过防火墙,示例如下。
当前主机IP为104,当放行ESTABLISHED与RELATED状态的包以后,并没有影响通过本机远程ssh到IP为77的主机上,但是无法从77上使用22端口主动连接到104上。
对于其他端口与IP来说,也是相同的,可以从104主动发送报文,并且能够收到响应报文,但是其他主机并不能主动向104发起请求。
九、iptables的黑白名单机制
注意:在参照本文进行iptables实验时,请务必在个人的测试机上进行,因为如果iptables规则设置不当,有可能使你无法连接到远程主机中。
前文中一直在强调一个概念:报文在经过iptables的链时,会匹配链中的规则,遇到匹配的规则时,就执行对应的动作,如果链中的规则都无法匹配到当前报文,则使用链的默认策略(默认动作),链的默认策略通常设置为ACCEPT或者DROP。
那么,当链的默认策略设置为ACCEPT时,如果对应的链中没有配置任何规则,就表示接受所有的报文,如果对应的链中存在规则,但是这些规则没有匹配到报文,报文还是会被接受。
同理,当链的默认策略设置为DROP时,如果对应的链中没有配置任何规则,就表示拒绝所有报文,如果对应的链中存在规则,但是这些规则没有匹配到报文,报文还是会被拒绝。
所以,当链的默认策略设置为ACCEPT时,按照道理来说,我们在链中配置规则时,对应的动作应该设置为DROP或者REJECT,为什么呢?
因为默认策略已经为ACCEPT了,如果我们在设置规则时,对应动作仍然为ACCEPT,那么所有报文都会被放行了,因为不管报文是否被规则匹配到都会被ACCEPT,所以就失去了访问控制的意义。
所以,当链的默认策略为ACCEPT时,链中的规则对应的动作应该为DROP或者REJECT,表示只有匹配到规则的报文才会被拒绝,没有被规则匹配到的报文都会被默认接受,这就是”黑名单”机制。
同理,当链的默认策略为DROP时,链中的规则对应的动作应该为ACCEPT,表示只有匹配到规则的报文才会被放行,没有被规则匹配到的报文都会被默认拒绝,这就是”白名单”机制。
如果使用白名单机制,我们就要把所有人都当做坏人,只放行好人。
如果使用黑名单机制,我们就要把所有人都当成好人,只拒绝坏人。
白名单机制似乎更加安全一些,黑名单机制似乎更加灵活一些。
那么,我们就来做一个简单的白名单吧,也就是说,只放行被规则匹配到的报文,其他报文一律拒绝,那么,我们先来配置规则。
假设,我想要放行ssh远程连接相关的报文,也想要放行web服务相关的报文,那么,我们在INPUT链中添加如下规则。
如上图所示,我们已经放行了特定的报文,只有上述两条规则匹配到的报文才会被放行,现在,我们只要将INPUT链的默认策略改为DROP,即可实现白名单机制。
示例如下。
上图中,我们已经将INPUT链的默认策略改为DROP,并且已经实现了所谓的白名单机制,即默认拒绝所有报文,只放行特定的报文。
如果此时,我不小心执行了”iptables -F”操作,根据我们之前学到的知识去判断,我们还能够通过ssh工具远程到服务器上吗?
我想你已经判断出了正确答案,没错,按照上图中的情况,如果此时执行”iptables -F”操作,filter表中的所有链中的所有规则都会被清空,而INPUT链的默认策略为DROP,所以所有报文都会被拒绝,不止ssh远程请求会被拒绝,其他报文也会被拒绝,我们来实验一下。
如上图所示,在当前ssh远程工具中执行”iptables -F”命令后,由于INPUT链中已经不存在任何规则,所以,所有报文都被拒绝了,包括当前的ssh远程连接。
这就是默认策略设置为DROP的缺点,在对应的链中没有设置任何规则时,这样使用默认策略为DROP是非常不明智的,因为管理员也会把自己拒之门外,即使对应的链中存在放行规则,当我们不小心使用”iptables -F”清空规则时,放行规则被删除,则所有数据包都无法进入,这个时候就相当于给管理员挖了个坑,所以,我们如果想要使用”白名单”的机制,最好将链的默认策略保持为”ACCEPT”,然后将”拒绝所有请求”这条规则放在链的尾部,将”放行规则”放在前面,这样做,既能实现”白名单”机制,又能保证在规则被清空时,管理员还有机会连接到主机,示例如下。
因为刚才的ssh连接已经被拒绝,所以,此时直接在控制台中设置iptables规则
如上图所示,先将INPUT链的默认策略设置为ACCEPT
然后继续配置需要放行的报文的规则,如下图所示,当所有放行规则设置完成后,在INPUT链的尾部,设置一条拒绝所有请求的规则。
上图中的设置,既将INPUT链的默认策略设置为了ACCEPT,同时又使用了白名单机制,因为如果报文符合放行条件,则会被前面的放行规则匹配到,如果报文不符合放行条件,则会被最后一条拒绝规则匹配到,此刻,即使我们误操作,执行了”iptables -F”操作,也能保证管理员能够远程到主机上进行维护,因为默认策略仍然是ACCEPT。
十、iptables自定义链
前文中,我们一直在定义规则,准确的说,我们一直在iptables的默认链中定义规则,那么此处,我们就来了解一下自定义链。
你可能会问,iptables的默认链就已经能够满足我们了,为什么还需要自定义链呢?
原因如下:
当默认链中的规则非常多时,不方便我们管理。
想象一下,如果INPUT链中存放了200条规则,这200条规则有针对httpd服务的,有针对sshd服务的,有针对私网IP的,有针对公网IP的,假如,我们突然想要修改针对httpd服务的相关规则,难道我们还要从头看一遍这200条规则,找出哪些规则是针对httpd的吗?这显然不合理。
所以,iptables中,可以自定义链,通过自定义链即可解决上述问题。
假设,我们自定义一条链,链名叫IN_WEB,我们可以将所有针对80端口的入站规则都写入到这条自定义链中,当以后想要修改针对web服务的入站规则时,就直接修改IN_WEB链中的规则就好了,即使默认链中有再多的规则,我们也不会害怕了,因为我们知道,所有针对80端口的入站规则都存放在IN_WEB链中,同理,我们可以将针对sshd的出站规则放入到OUT_SSH自定义链中,将针对Nginx的入站规则放入到IN_NGINX自定义链中,这样,我们就能想改哪里改哪里,再也不同担心找不到规则在哪里了。
但是需要注意的是,自定义链并不能直接使用,而是需要被默认链引用才能够使用,空口白话说不明白,等到示例时我们自然会明白。
说了这么多,我们来动手创建一条自定义链,使用-N选项可以创建自定义链,示例如下
如上图所示,”-t filter”表示操作的表为filter表,与之前的示例相同,省略-t选项时,缺省操作的就是filter表。
“-N IN_WEB”表示创建一个自定义链,自定义链的名称为”IN_WEB”
自定义链创建完成后,查看filter表中的链,如上图所示,自定义链已经被创建,而且可以看到,这条自定义链的引用计数为0 (0 references),也就是说,这条自定义链还没有被任何默认链所引用,所以,即使IN_WEB中配置了规则,也不会生效,我们现在不用在意它,继续聊我们的自定义链。
好了,自定义链已经创建完毕,现在我们就可以直接在自定义链中配置规则了,如下图所示,我们配置一些规则用于举例。
如上图所示,对自定义链的操作与对默认链的操作并没有什么不同,一切按照操作默认链的方法操作自定义链即可。
现在,自定义链中已经有了一些规则,但是目前,这些规则无法匹配到任何报文,因为我们并没有在任何默认链中引用它。
既然IN_WEB链是为了针对web服务的入站规则而创建的,那么这些规则应该去匹配入站的报文,所以,我们应该用INPUT链去引用它。
当然,自定义链在哪里创建,应该被哪条默认链引用,取决于实际的工作场景,因为此处示例的规则是匹配入站报文,所以在INPUT链中引用自定义链。
示例如下。
上图中,我们在INPUT链中添加了一条规则,访问本机80端口的tcp报文将会被这条规则匹配到
而上述规则中的”-j IN_WEB”表示:访问80端口的tcp报文将由自定义链”IN_WEB”中的规则进行处理,没错,在之前的示例中,我们使用”-j”选项指定动作,而此处,我们将”动作”替换为了”自定义链”,当”-j”对应的值为一个自定义链时,就表示被当前规则匹配到的报文将交由对应的自定义链处理,具体怎样处理,取决于自定义链中的规则,当IN_WEB自定义链被INPUT链引用以后,可以发现,IN_WEB链的引用计数已经变为1,表示这条自定义链已经被引用了1次,自定义链还可以引用其他的自定义链,感兴趣的话,动手试试吧。
在之前的文章中,我们说过,”动作”在iptables中被称为”target”,这样描述并不准确,因为target为目标之意,报文被规则匹配到以后,target能是一个”动作”,target也能是一个”自定义链”,当target为一个动作时,表示报文按照指定的动作处理,当target为自定义链时,表示报文由自定义链中的规则处理,现在回过头再理解之前的术语,似乎更加明了了。
那么此刻,我们在192.168.1.139上尝试访问本机的80端口,已经被拒绝访问,证明刚才自定义链中的规则已经生效了。
过了一段时间,我们发现IN_WEB这个名字不太合适,我们想要将这条自定义链重命名,把名字改成WEB,可以吗?必须能啊,示例如下
如上图所示,使用”-E”选项可以修改自定义链名,如上图所示,引用自定义链处的名称会自动发生改变。
好了,我们已经能够创建自定义了,那么怎样删除自定义链呢?
使用”-X”选项可以删除自定义链,但是删除自定义链时,需要满足两个条件:
1、自定义链没有被任何默认链引用,即自定义链的引用计数为0。
2、自定义链中没有任何规则,即自定义链为空。
那么,我们来删除自定义链WEB试试。
如上图所示,使用”-X”选项删除对应的自定义链,但是上例中,并没有成功删除自定义链WEB,提示:Too many links,是因为WEB链已经被默认链所引用,不满足上述条件1,所以,我们需要删除对应的引用规则,示例如下。
如上图所示,删除引用自定义链的规则后,再次尝试删除自定义链,提示:Directory not empty,是因为WEB链中存在规则,不满足上述条件2,所以,我们需要清空对应的自定义链,示例如下
如上图所示,使用”-X”选项可以删除一个引用计数为0的、空的自定义链。
小结
为了方便以后回顾,我们将上述命令进行总结。
创建自定义链
#示例:在filter表中创建IN_WEB自定义链
iptables -t filter -N IN_WEB
引用自定义链
#示例:在INPUT链中引用刚才创建的自定义链
iptables -t filter -I INPUT -p tcp --dport 80 -j IN_WEB
重命名自定义链
#示例:将IN_WEB自定义链重命名为WEB
iptables -E IN_WEB WEB
删除自定义链
删除自定义链需要满足两个条件
1、自定义链没有被引用
2、自定义链中没有任何规则
#示例:删除引用计数为0并且不包含任何规则的WEB链
iptables -X WEB
十一、iptables之网络防火墙
我们一起来回顾一下之前的知识,在第一篇介绍iptables的文章中,我们就描述过防火墙的概念,我们说过,防火墙从逻辑上讲,可以分为主机防火墙与网络防火墙。
主机防火墙:针对于单个主机进行防护。
网络防火墙: 往往处于网络入口或边缘,针对于网络入口进行防护,服务于防火墙背后的本地局域网。
在前文的举例中,iptables都是作为主机防火墙的角色出现的,那么,iptables怎样作为网络防火墙呢?这就是我们今天要聊的话题。
回到刚才的概念,网络防火墙往往处于网络的入口或者边缘,那么,如果想要使用iptables充当网络防火墙,iptables所在的主机则需要处于网络入口处,示意图如下。
上图中,橘黄色主机为iptables所在主机,此时iptables充当的角色即为网络防火墙,上图中的浅蓝色圆形表示网络防火墙所防护的网络区域,圆形内的蓝色矩形表示网络内的主机。
当外部网络中的主机与网络内部主机通讯时,不管是由外部主机发往内部主机的报文,还是由内部主机发往外部主机的报文,都需要经过iptables所在的主机,由iptables所在的主机进行”过滤并转发”,所以,防火墙主机的主要工作就是”过滤并转发”,那么,说到这里,我们则不得不再次回顾之前的iptables报文流程图了,如下:
前文中,iptables都是作为”主机防火墙”的角色出现的,所以我们举例时,只用到了上图中的INPUT链与OUTPUT链,因为拥有”过滤功能”的链只有3条,INPUT、OUTPUT、FORWARD,当报文发往本机时,如果想要过滤,只能在INPUT链与OUTPUT链中实现,而此时,iptables的角色发生了转变,我们想要将iptables所在的主机打造成”网络防火墙”,而刚才已经说过,网络防火墙的职责就是”过滤并转发”,要想”过滤”,只能在INPUT、OUTPUT、FORWARD三条链中实现,要想”转发”,报文则只会经过FORWARD链(发往本机的报文才会经过INPUT链),所以,综上所述,iptables的角色变为”网络防火墙”时,规则只能定义在FORWARD链中。
环境准备
那么为了能够进行实验,我们来设置一下实验场景,如下图所示(后面有对图的解释)
我们假设,上图中圆形所示的网络为内部网络
注:此处所描述的内网、外网与我们平常所说的公网、私网不同。
此处描述的内外部网络你可以理解成两个网段,A网络与B网络,为了方便描述,我们把圆形内的主机称为内部主机,把上图中圆形所表示的网络称为内部网络,把圆形外的网络称为外部网络。
假设,内部网络的网段为10.1.0.0/16,此内部网络中存在主机C,主机C的IP地址为10.1.0.1。
上图中的主机B充当了网络防火墙的角色,主机B也属于内部网络,同时主机B也能与外部网络进行通讯,如上图所示,主机B有两块网卡,网卡1与网卡2,网卡1的IP地址为10.1.0.3,网卡2的IP地址为192.168.1.146,所以,防火墙主机在内部网络中的IP地址为10.1.0.3,防火墙主机与外部网络通讯的IP地址为192.168.1.146。
上图中的主机A充当了”外部网络主机”的角色,A主机的IP地址为192.168.1.147,我们使用主机A访问内部网络中的主机C,但是需要主机B进行转发,主机B在转发报文时会进行过滤,以实现网络防火墙的功能。
我已经准备了3台虚拟机,A、B、C
虚拟机A与虚拟机B的网卡2都使用了桥接模式。
为了能够尽量模拟内部网络的网络入口,我们将虚拟机B的网卡1与虚拟机C同时放在”仅主机模式”的虚拟网络中,虚拟机设置如下图所示
点击vmware编辑菜单,打开虚拟网络编辑器,点击更改设置按钮,添加一个仅主机模式的虚拟网络,下图中的vmnet6为已经添加过的虚拟网络,此处不再重复添加。
由于B主机现在的角色是10.1.0.0中的”网络防火墙”,那么,我们直接将C主机的网关指向B主机的内部网络IP,如下图所示
同时,为了尽量简化路由设置,我们直接将A主机访问10.1网络时的网关指向B主机的网卡2上的IP,如下图所示。
注:route命令配置的路由条目在网络重启后将会失效
现在A主机通往10.1网络的网关已经指向了B主机,那么,现在A主机能够达到10.1.0.0/16网络吗?我们来试试
如下图所示,我们直接在A主机上向C主机发起ping请求,并没有得到任何回应。
那么,我们再来试试B主机上的内部网IP,如下图所示,直接在A主机上向B主机的内部网IP发起ping请求,发现是可以ping通的,这是为什么呢?
按照道理来说,10.1.0.1与10.1.0.3都属于10.1.0.0/16网段,为什么B主机上的IP就能通,C主机上的IP却不通呢?
咱们先来聊聊为什么10.1.0.1没有回应。
A主机通过路由表得知,发往10.1.0.0/16网段的报文的网关为B主机,当报文达到B主机时,B主机发现A的目标为10.1.0.1,而自己的IP是10.1.0.3,这时,B主机则需要将这个报文转发给10.1.0.1(也就是C主机),但是,Linux主机在默认情况下,并不会转发报文,如果想要让Linux主机能够转发报文,需要额外的设置,这就是为什么10.1.0.1没有回应的原因,因为B主机压根就没有将A主机的ping请求转发给C主机,C主机压根就没有收到A的ping请求,所以A自然得不到回应。
现在再来聊聊为什么10.1.0.3会回应。
这是因为10.1.0.3这个IP与192.168.1.146这个IP都属于B主机,当A主机通过路由表将ping报文发送到B主机上时,B主机发现自己既是192.168.1.146又是10.1.0.3,所以,B主机就直接回应了A主机,并没有将报文转发给谁,所以A主机得到了10.1.0.3的回应。
我想我应该说明白了,那么,我们应该怎样设置,才能让Linux主机转发报文呢?我们一起来设置一遍就好了。
首先,我们可以查看/proc/sys/net/ipv4/ip_forward文件中的内容,如果文件内容为0,则表示当前主机不支持转发。
如果我们想要让当前主机支持核心转发功能,只需要将此文件中的值设置为1即可,示例如下。
好了,现在我们就开启了B主机的核心转发功能。
除了上述方法,还能使用sysctl命令去设置是否开启核心转发,示例如下。
上述两种方法都能控制是否开启核心转发,但是通过上述两种方法设置后,只能临时生效,当重启网络服务以后,核心转发功能将会失效。
如果想要永久生效,则需要设置/etc/sysctl.conf文件(centos7中配置/usr/lib/sysctl.d/00-system.conf文件),添加(或修改)配置项 net.ipv4.ip_forward = 1 即可,示例如下。
现在,B主机已经具备了核心转发功能,已经可以转发报文了,现在,我们再次回到A主机中,向C主机发起ping请求,如下图所示,已经可以ping通。
注:如果你仍然无法ping通,可能是因为你使用route命令配置了C主机的默认网关,这种情况下,请查看C主机的路由配置是否自动消失了,如果没有对应的路由条目,请重新配置,同时,如果你的主机C如果有多块网卡,可以暂时禁用其他网卡试试
同时,从主机C向主机A发起ping请求,也可以ping通,如下图所示
好了,我们的测试环境已经准备完毕,现在可以开始测试了。
但是在开始之前,请确定主机A与主机C上没有对应的iptables规则,因为此处我们主要是用来测试”网络防火墙”的,为了减少主机防火墙带来的影响,我们直接将主机A与主机C上的规则清空。
网络防火墙测试
之前说过,iptables作为网络防火墙时,主要负责”过滤与转发”,既然要过滤,则需配置filter表,既然要转发,则需在FORWAED链中定义规则,所以,我们应该在filter表中的FORWARD链中配置规则。
那么,我们先来看看主机B上的filter表中是否已经存在规则,如下
从上图可以看出,FORWARD链中没有任何规则,默认策略为ACCEPT,我们可以使用”白名单机制”(如果忘了请回顾前文:黑白名单机制)
在主机B中FORWARD链的末端添加一条默认拒绝的规则,然后将”放行规则”设置在这条”默认拒绝规则”之前即可。
示例如下
好了,配置完上述规则后,主机A与主机C已经无法通讯了,因为它们之间如果想要通讯,则需要靠主机B进行转发,而上述规则设置完成后,所有报文都无法通过FORWARD链了,所以任何经过转发的报文在经过FORWARD链时都会被拒绝,外部主机的报文无法转发到内部主机中,内部网主机的报文也无法转发到外部主机中,因为主机B已经拒绝转发所有报文。
现在,我们同时将A主机与C主机中的web服务启动,以便进行测试。
首先,我们启动A主机的httpd服务
同时,启动C主机的httpd服务
由于刚才已经在主机B中设置了默认拒绝的规则,所以此刻,A主机无法访问C主机的web服务,C主机同样无法访问A主机的web服务。
那么,如果我们想要使内部的主机能够访问外部主机的web服务,我们应该怎样做呢?没错,我们需要在FORWARD链中放行内部主机对外部主机的web请求,只需如下配置即可。
如上图所示,防火墙放行了内部主机的web请求,因为我们将来自内部网络中目标端口为80的报文都放行了,那么此时,我们在C主机上访问A主机的web服务试试
此时,在主机C上访问主机A的web服务,如下
可以看到,主机C并无法访问到主机A上的web服务,这是为什么呢?
聪明如你肯定已经想到了,我们只在主机B上放行了内部主机访问80端口的请求,但是并没有放行外部主机的回应报文,虽然内部主机的请求能够通过防火墙主机B转发出去,但是回应的报文则无法进入防火墙,所以,我们仍然需要在主机B上进行如下设置。
如上图所示,当外部主机中的web服务响应内部主机时,目标地址肯定为内部主机,所以,我们需要放行目标IP属于内部主机网段的报文,源端口为80,因为外部主机肯定会使用80端口进行回应。
完成上述配置后,再次回到C主机上,访问A主机的web服务,可以看到,已经能够正常访问了。
从上述示例可以看出,当iptables作为”网络防火墙”时,在配置规则时,往往需要考虑”双向性”,也就是说,我们为了达成一个目的,往往需要两条规则才能完成。
那么此时,A主机能够访问C主机中的web服务吗?我想你已经知道答案了,没错,A主机此时无法访问C主机中的web服务,因为B主机中并没有放行相关报文。
结合之前的知识,我们可以将上述规则配置进行优化,比如,不管是由内而外,还是由外而内,只要是”响应报文”,我们统统放行,配置如下
注:如果你没有明白如下配置的含义,请回顾之前的文章
如上图所示,先将”web响应报文放行规则”删除,同时增加了上图中的规则,只需要在网络防火墙主机的FORWARD链中添加如上一条规则,就可以将绝大多数响应报文放行了,不管是外部响应内部,还是内部响应外部,一条规则就能搞定,当iptables作为网络防火墙时,每次配置规则时都要考虑”双向”的问题,但是配置完上述规则后,我们只要考虑请求报文的方向就行了,而回应报文,上述一条规则就能搞定,这样配置,即使以后有更多服务的响应报文需要放行,我们也不用再去针对响应报文设置规则了(具体原因前文已经详细的总结过),应该会让我们省去不少规则吧。
比如,我们除了想要让内部主机能够访问外部的web服务,还想让内部主机能够访问外部的sshd服务,那么,我们则可以进行如下设置。
如上图所示,我们只要考虑内部主机的请求方向的报文规则即可,因为响应报文的规则已经被之前配置的规则”承包了”。
此刻,使用C主机即可访问A主机的22端口。
目前,我们只允许内部主机访问外部主机的web服务与sshd服务,但是外部主机还无法访问内部主机的服务,那么具体怎么配置我们就不赘述了,就由客官你去负责实现吧。
备注:在之前的一次实验中,使用centos6.8作为网络防火墙,出现了即使开启核心转发,也无法转发报文的情况,具体原因仍未查明,遇到过类似场景的朋友如果有解决方法,欢迎赐教。
小结
为了方便以后回顾,我们将上述过程提炼总结一下。
#如果想要iptables作为网络防火墙,iptables所在主机开启核心转发功能,以便能够转发报文。
#使用如下命令查看当前主机是否已经开启了核心转发,0表示未开启,1表示已开启
cat /proc/sys/net/ipv4/ip_forward
#使用如下两种方法均可临时开启核心转发,立即生效,但是重启网络配置后会失效。
方法一:echo 1 > /proc/sys/net/ipv4/ip_forward
方法二:sysctl -w net.ipv4.ip_forward=1
#使用如下方法开启核心转发功能,重启网络服务后永久生效。
配置/etc/sysctl.conf文件(centos7中配置/usr/lib/sysctl.d/00-system.conf文件),在配置文件中将 net.ipv4.ip_forward设置为1
#由于iptables此时的角色为"网络防火墙",所以需要在filter表中的FORWARD链中设置规则。
#可以使用"白名单机制",先添加一条默认拒绝的规则,然后再为需要放行的报文设置规则。
#配置规则时需要考虑"方向问题",针对请求报文与回应报文,考虑报文的源地址与目标地址,源端口与目标端口等。
#示例为允许网络内主机访问网络外主机的web服务与sshd服务。
iptables -A FORWARD -j REJECT
iptables -I FORWARD -s 10.1.0.0/16 -p tcp --dport 80 -j ACCEPT
iptables -I FORWARD -d 10.1.0.0/16 -p tcp --sport 80 -j ACCEPT
iptables -I FORWARD -s 10.1.0.0/16 -p tcp --dport 22 -j ACCEPT
iptables -I FORWARD -d 10.1.0.0/16 -p tcp --sport 22 -j ACCEPT
#可以使用state扩展模块,对上述规则进行优化,使用如下配置可以省略许多"回应报文放行规则"。
iptables -A FORWARD -j REJECT
iptables -I FORWARD -s 10.1.0.0/16 -p tcp --dport 80 -j ACCEPT
iptables -I FORWARD -s 10.1.0.0/16 -p tcp --dport 22 -j ACCEPT
iptables -I FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
一些注意点:
1、当测试网络防火墙时,默认前提为网络已经正确配置。
2、当测试网络防火墙时,如果出现问题,请先确定主机防火墙规则的配置没有问题。
十二、iptables动作总结之一
前文一直在介绍iptables的匹配条件,并没有对动作进行过总结,那么此处,我们就来总结一下iptables中的动作。
之前的举例中已经用到了一些常用动作,比如ACCEPT、DROP、REJECT等。
其实,”动作”与”匹配条件”一样,也有”基础”与”扩展”之分。
同样,使用扩展动作也需要借助扩展模块,但是,扩展动作可以直接使用,不用像使用”扩展匹配条件”那样指定特定的模块。
之前用到的ACCEPT与DROP都属于基础动作。
而REJECT则属于扩展动作。
之前举过很多例子,我们知道,使用-j可以指定动作,比如
-j ACCEPT
-j DROP
-j REJECT
其实,”动作”也有自己的选项,我们可以在使用动作时,设置对应的选项,此处以REJECT为例,展开与”动作”有关的话题。
动作REJECT
REJECT动作的常用选项为–reject-with
使用–reject-with选项,可以设置提示信息,当对方被拒绝时,会提示对方为什么被拒绝。
可用值如下
icmp-net-unreachable
icmp-host-unreachable
icmp-port-unreachable,
icmp-proto-unreachable
icmp-net-prohibited
icmp-host-pro-hibited
icmp-admin-prohibited
当不设置任何值时,默认值为icmp-port-unreachable。
我们来动手实践一下,在主机139上设置如下规则,如下图所示,当没有明确设置–reject-with的值时,默认提示信息为icmp-port-unreachable,即端口不可达之意。
此时在另一台主机上向主机139发起ping请求,如下图所示,提示目标端口不可达。
那么我们将拒绝报文的提示设置为”主机不可达”,示例如下
如上图所示,我们在设置拒绝的动作时,使用了–reject-with选项,将提示信息设置为icmp-host-unreachable,完成上述操作后,我们再次在在另一台主机上向主机139发起ping请求。
如下图所示。
可以看到,ping请求被拒绝时,提示信息已经从”目标端口不可达”变成了”目标主机不可达”。
动作LOG
在本博客中,前文并没有对LOG动作进行示例,此处我们来了解一下LOG动作。
使用LOG动作,可以将符合条件的报文的相关信息记录到日志中,但当前报文具体是被”接受”,还是被”拒绝”,都由后面的规则控制,换句话说,LOG动作只负责记录匹配到的报文的相关信息,不负责对报文的其他处理,如果想要对报文进行进一步的处理,可以在之后设置具体规则,进行进一步的处理。
示例如下,下例表示将发往22号端口的报文相关信息记录在日志中。
如上图所示,上述规则表示所有发往22号端口的tcp报文都符合条件,所以都会被记录到日志中,查看/var/log/messages即可看到对应报文的相关信息,但是上述规则只是用于示例,因为上例中使用的匹配条件过于宽泛,所以匹配到的报文数量将会非常之多,记录到的信息也不利于分析,所以在使用LOG动作时,匹配条件应该尽量写的精确一些,匹配到的报文数量也会大幅度的减少,这样冗余的日志信息就会变少,同时日后分析日志时,日志中的信息可用程度更高。
注:请把刚才用于示例的规则删除。
从刚才的示例中我们已经了解到,LOG动作会将报文的相关信息记录在/var/log/message文件中,当然,我们也可以将相关信息记录在指定的文件中,以防止iptables的相关信息与其他日志信息相混淆,修改/etc/rsyslog.conf文件(或者/etc/syslog.conf),在rsyslog配置文件中添加如下配置即可。
#vim /etc/rsyslog.conf
kern.warning /var/log/iptables.log
加入上述配置后,报文的相关信息将会被记录到/var/log/iptables.log文件中。
完成上述配置后,重启rsyslog服务(或者syslogd)
#service rsyslog restart
服务重启后,配置即可生效,匹配到的报文的相关信息将被记录到指定的文件中。
LOG动作也有自己的选项,常用选项如下(先列出概念,后面有示例)
–log-level选项可以指定记录日志的日志级别,可用级别有emerg,alert,crit,error,warning,notice,info,debug。
–log-prefix选项可以给记录到的相关信息添加”标签”之类的信息,以便区分各种记录到的报文信息,方便在分析时进行过滤。
注:–log-prefix对应的值不能超过29个字符。
比如,我想要将主动连接22号端口的报文的相关信息都记录到日志中,并且把这类记录命名为”want-in-from-port-22″,则可以使用如下命令
完成上述配置后,我在IP地址为192.168.1.98的客户端机上,尝试使用ssh工具连接上例中的主机,然后查看对应的日志文件(已经将日志文件设置为/var/log/iptables.log)
如上图所示,ssh连接操作的报文的相关信息已经被记录到了iptables.log日志文件中,而且这条日志中包含”标签”:want-in-from-port-22,如果有很多日志记录,我们就能通过这个”标签”进行筛选了,这样方便我们查看日志,同时,从上述记录中还能够得知报文的源IP与目标IP,源端口与目标端口等信息,从上述日志我们能够看出,192.168.1.98这个IP想要在14点11分连接到192.168.1.139(当前主机的IP)的22号端口,报文由eth4网卡进入,eth4网卡的MAC地址为00:0C:29:B7:F4:D1,客户端网卡的mac地址为F4-8E-38-82-B1-29。
除了ACCEPT、DROP、REJECT、LOG等动作,还有一些其他的常用动作,比如DNAT、SNAT等,我们会在之后的文章中对它们进行总结。
十三、iptables动作总结之二
概述
阅读这篇文章需要站在前文的基础上,如果你在阅读时遇到障碍,请参考之前的文章。
前文中,我们已经了解了如下动作
ACCEPT、DROP、REJECT、LOG
今天,我们来认识几个新动作,它们是:
SNAT、DNAT、MASQUERADE、REDIRECT
在认识它们之前,我们先来聊聊NAT,如果你对NAT的相关概念已经滚瓜烂熟,可以跳过如下场景描述。
NAT是Network Address Translation的缩写,译为”网络地址转换”,NAT说白了就是修改报文的IP地址,NAT功能通常会被集成到路由器、防火墙、或独立的NAT设备中。
为什么要修改报文的IP地址呢?我们来描述一些场景,即可知道为什么有这方面的需求了。
场景1:
假设,网络内部有10台主机,它们有各自的IP地址,当网络内部的主机与其他网络中的主机通讯时,则会暴露自己的IP地址,如果我们想要隐藏这些主机的IP地址,该怎么办呢?可以这样办,如下。
当网络内部的主机向网络外部主机发送报文时,报文会经过防火墙或路由器,当报文经过防火墙或路由器时,将报文的源IP修改为防火墙或者路由器的IP地址,当其他网络中的主机收到这些报文时,显示的源IP地址则是路由器或者防火墙的,而不是那10台主机的IP地址,这样,就起到隐藏网络内部主机IP的作用,当网络内部主机的报文经过路由器时,路由器会维护一张NAT表,表中记录了报文来自于哪个内部主机的哪个进程(内部主机IP+端口),当报文经过路由器时,路由器会将报文的内部主机源IP替换为路由器的IP地址,把源端口也映射为某个端口,NAT表会把这种对应关系记录下来。
示意图如下:
于是,外部主机收到报文时,源IP与源端口显示的都是路由的IP与端口,当外部网络中的主机进行回应时,外部主机将响应报文发送给路由器,路由器根据刚才NAT表中的映射记录,将响应报文中的目标IP与目标端口再改为内部主机的IP与端口号,然后再将响应报文发送给内部网络中的主机。整个过程中,外部主机都不知道内部主机的IP地址,内部主机还能与外部主机通讯,于是起到了隐藏网络内主机IP的作用。
上述整个过程中,就用到了NAT功能,准确的说是用到了NAPT功能,NAPT是NAT的一种,全称为Network Address Port Translation,说白了就是映射报文IP地址的同时还会映射其端口号,就像刚才描述的过程一样。
刚才描述的过程中,”IP地址的转换”一共发生了两次。
内部网络的报文发送出去时,报文的源IP会被修改,也就是源地址转换:Source Network Address Translation,缩写为SNAT。
外部网络的报文响应时,响应报文的目标IP会再次被修改,也就是目标地址转换:Destinationnetwork address translation,缩写为DNAT。
但是,上述”整个过程”被称为SNAT,因为”整个过程”的前半段使用了SNAT,如果上述”整个过程”的前半段使用了DNAT,则整个过程被称为DNAT,也就是说,整个过程被称为SNAT还是DNAT,取决于整个过程的前半段使用了SNAT还是DNAT。
其实刚才描述的场景不仅仅能够隐藏网络内部主机的IP地址,还能够让局域网内的主机共享公网IP,让使用私网IP的主机能够访问互联网。
比如,整个公司只有一个公网IP,但是整个公司有10台电脑,我们怎样能让这10台电脑都访问互联网呢?我们可以为这10台电脑都配置上各自的私网IP,比如”192.168″这种私网IP,但是互联网是不会路由私网IP的,如果想要访问互联网,则必须使用公网IP,那么,我们就需要想办法,能让这10台主机共享公司仅有的一个公网IP,没错,这与刚才描述的场景其实完全一致,我们只要在路由器上配置公网IP,在私网主机访问公网服务时,报文经过路由器,路由器将报文中的私网IP与端口号进行修改和映射,将其映射为公网IP与端口号,这时,内网主机即可共享公网IP访问互联网上的服务了,NAT表示意图如下
综上所述,SNAT不仅能够隐藏网内的主机IP,还能够共享公网IP,这在IPV4地址较为紧张的今天,是非常有用的。
场景2:
场景1中,我们描述的过程为SNAT的过程,虽然其过程中也牵扯到DNAT,但是由于整个过程的前半段使用了SNAT,所以整个过程称之为SNAT,那么在什么情况下,整个过程能称之为DNAT呢?
没错,当整个过程的前半段使用了DNAT时,整个过程被称为DNAT,具体场景如下。
公司有自己的局域网,网络中有两台主机作为服务器,主机1提供web服务,主机2提供数据库服务,但是这两台服务器在局域网中使用私有IP地址,只能被局域网内的主机访问,互联网无法访问到这两台服务器,整个公司只有一个可用的公网IP,怎样通过这个公网IP访问到内网中的这些服务呢?我们可以将这个公网IP配置到公司的某台主机或路由器上,然后对外宣称,这个IP地址对外提供web服务与数据库服务,于是互联网主机将请求报文发送给这公网 IP地址,也就是说,此时报文中的目标IP为公网IP,当路由器收到报文后,将报文的目标地址改为对应的私网地址,比如,如果报文的目标IP与端口号为:公网IP+3306,我们就将报文的目标地址与端口改为:主机2的私网IP+3306,同理,公网IP+80端口映射为主机1的私网IP+80端口,当私网中的主机回应对应请求报文时,再将回应报文的源地址从私网IP+端口号映射为公网IP+端口号,再由路由器或公网主机发送给互联网中的主机。
上述过程也牵扯到DNAT与SNAT,但是由于整个过程的前半段使用了DNAT,所以上述过程被称为DNAT
其实,不管是SNAT还是DNAT,都起到了隐藏内部主机IP的作用。
实验环境准备
好了,我们已经了解了SNAT与DNAT的相关概念,那么现在,我们可以动动手了,首先,准备一下实验环境
大致的实验环境是这样的,公司局域网使用的网段为10.1.0.0/16,目前公司只有一个公网IP,局域网内的主机需要共享这个IP与互联网上的主机进行通讯。
由于我们没有真正的公网IP,所以,我们使用私网IP:192.168.1.146模拟所谓的公网IP,示意图如下
如上述示意图所示,实验使用4台虚拟机,A、B、C、D
主机A:扮演公网主机,尝试访问公司提供的服务,IP地址为192.168.1.147
主机B:扮演了拥有NAT功能的防火墙或路由器,充当网关,并且负责NAT,公网、私网通讯的报文通过B主机时,报文会被NAT
主机C:扮演内网web服务器
主机D:扮演内网windows主机
上图中圆形所示的逻辑区域表示公司内网,网段为10.1.0.0/16,主机B、C、D都属于内网主机,主机B比较特殊,同时扮演了网关与防火墙,主机B持有公司唯一的公网IP(我们用了一个假的公网IP),局域网内主机如果想与公网主机通讯,需要共享此公网IP,由B主机进行NAT,所以,我们为主机B准备了两块网卡,公网IP与私网IP分别配置到这两块网卡中,同时,在虚拟机中设置了一个”仅主机模式”的虚拟网络,以模拟公司局域网。
聪明如你,应该已经发现了,上述实验环境与之前描述的”网络防火墙”的实验环境相差无几,只不过之前的环境并没有公网,私网的概念,而此刻,圆形逻辑区域之内为私网,圆形逻辑区域之外为公网。
环境具体准备过程如下
首先,创建一个虚拟网络,模拟公司内网。
点击vmware虚拟机的编辑菜单,打开”虚拟网络编辑器”,点击更改设置,添加”仅主机模式”的虚拟网络,下图中的VMnet6为已经添加过的虚拟网络,此处不再重复操作。
主机C与主机D的网关都指向主机B的私网IP,如下图所示
主机B有两块网卡,分别配置了私网IP与公网IP,私网IP为10.1.0.3,私网IP所在的网卡也存在于vmnet6中,模拟公网的IP为192.168.1.146,B主机的公网IP所在的网卡与A主机都使用桥接模式的虚拟网络,所以,B主机既能与私网主机通讯,也能与公网主机通讯。
由于B主机此时需要负责对报文的修改与转发,所以,需要开启B主机中的核心转发功能,Linux主机默认不会开启核心转发,这在前文中已经详细的描述过,此处不再赘述,如果你还不明白为什么,请回顾前文,使用临时生效的方法开启B主机的核心转发功能,如下图所示。
A主机的IP地址如下,可以与B主机进行通讯,但是不能与C、D进行通讯,因为此刻,A是公网主机,B既是公网主机又是私网主机,C、D是私网的主机,A是不可能访问到C和D的。
为了能够更好的区分公网服务与私网服务,我们分别在主机A与主机C上启动httpd服务,如下图所示。
好了,实验环境准备完毕,我们来一起动动手,实际操作一下。
动作:SNAT
在文章开头的场景中,我们已经描述过,网络内部的主机可以借助SNAT隐藏自己的IP地址,同时还能够共享合法的公网IP,让局域网内的多台主机共享公网IP访问互联网。
而此时的主机B就扮演了拥有NAT功能的设备,我们使用iptables的SNAT动作达到刚才所说的目的。
连接到B主机,添加如下规则。
如上图所示,上图中的规则表示将来自于10.1.0.0/16网段的报文的源地址改为公司的公网IP地址。
“-t nat”表示操作nat表,我们之前一直在灌输一个概念,就是不同的表有不同的功能,filter表的功能是过滤,nat表的功能就是地址转换,所以我们需要在nat表中定义nat规则。
“-A POSTROUTING”表示将SNAT规则添加到POSTROUTING链的末尾,在centos7中,SNAT规则只能存在于POSTROUTING链与INPUT链中,在centos6中,SNAT规则只能存在于POSTROUTING链中。
你可能会问,为什么SNAT规则必须定义在POSTROUTING链中,我们可以这样认为,POSTROUTING链是iptables中报文发出的最后一个”关卡”,我们应该在报文马上发出之前,修改报文的源地址,否则就再也没有机会修改报文的源地址了,在centos7中,SNAT规则也可以定义在INPUT链中,我们可以这样理解,发往本机的报文经过INPUT链以后报文就到达了本机,如果再不修改报文的源地址,就没有机会修改了。
“-s 10.1.0.0/16″表示报文来自于10.1.0.0/16网段,前文中一直在使用这个匹配条件,我想此处应该不用赘述了。
“-j SNAT”表示使用SNAT动作,对匹配到的报文进行处理,对匹配到的报文进行源地址转换。
“–to-source 192.168.1.146″表示将匹配到的报文的源IP修改为192.168.1.146,前文中,我们已经总结过,某些动作会有自己的选项,”–to-source”就是SNAT动作的常用选项,用于指定SNAT需要将报文的源IP修改为哪个IP地址。
好了,只要站在前文的基础上,理解上述语句应该是分分钟的事情,聪明如你应该已经学会了,那么我们来测试一下。
目前来说,我们只配置了一条SNAT规则,并没有设置任何DNAT,现在,我们从内网主机上ping外网主机,看看能不能ping通,登录内网主机C,在C主机上向A主机的外网IP发送ping请求(假外网IP),示例如下
如上图所示,”内网主机”已经可以依靠SNAT访问”互联网”了。
为了更加清晰的理解整个SNAT过程,在C主机上抓包看看,查看一下请求报文与响应报文的IP地址,如下,在C主机上同时打开两个命令窗口,一个命令窗口中向A主机发送ping请求,另一个窗口中,使用tcpdump命令对指定的网卡进行抓包,抓取icmp协议的包
从上图可以看到,10.1.0.1发出ping包,192.168.1.147进行回应,正是A主机的IP地址(用于模拟公网IP的IP地址)
看来,只是用于配置SNAT的话,我们并不用 手动的进行DNAT设置,iptables会自动维护NAT表,并将响应报文的目标地址转换回来。
那么,我们去A主机上再次重复一遍刚才的操作,在A主机上抓包看看,如下图所示,C主机上继续向A主机的公网IP发送ping请求,在主机A的网卡上抓包看看。
从上图可以看出,C主机向A主机发起ping请求时得到了回应,但是在A主机上,并不知道是C主机发来的ping请求,A主机以为是B主机发来的ping请求,从抓包的信息来看,A主机以为B主机通过公网IP:192.168.1.146向自己发起了ping请求,而A主机也将响应报文回应给了B主机,所以,整个过程,A主机都不知道C主机的存在,都以为是B主机在向自己发送请求,即使不是在公网私网的场景中,我们也能够使用这种方法,隐藏网络内的主机,只不过此处,我们所描述的环境就是私网主机共享公网IP访问互联网,那么可以看到,私网中的主机已经共享了192.168.1.146这个”伪公网IP”,那么真的共享了吗?我们使用内网主机D试试,主机D是一台windows虚拟机,我们使用它向主机A发送ping请求,看看能不能ping通。如下
windows主机也ping通了外网主机,在A主机上抓包,看到的仍然是B主机的IP地址。
那么,C主机与D主机能够访问外网服务吗?我们来看看。
在C主机上访问A主机的web服务,如下图所示,访问正常。
同理,在windows主机中访问A主机的web服务,如下图所示,访问正常。
好了,源地址转换,已经完成了,我们只依靠了一条iptables规则,就能够使内网主机能够共享公网IP访问互联网了。
动作DNAT
公司只有一个公网IP,但是公司的内网中却有很多服务器提供各种服务,我们想要通过公网访问这些服务,改怎么办呢?
没错,使用DNAT即可,我们对外宣称,公司的公网IP上既提供了web服务,也提供了windows远程桌面,不管是访问web服务还是远程桌面,只要访问这个公网IP就行了,我们利用DNAT,将公网客户端发送过来的报文的目标地址与端口号做了映射,将访问web服务的报文转发到了内网中的C主机中,将访问远程桌面的报文转发到了内网中的D主机中。
好了,理论说完了,来动手实践一下。
如果我们想要实现刚才描述的场景,则需要在B主机中进行如下配置。
如上图所示,我们先将nat表中的规则清空了,从头来过,清空nat表规则后,定义了一条DNAT规则。
“-t nat -I PREROUTING”表示在nat表中的PREROUTING链中配置DNAT规则,DNAT规则只配置在PREROUTING链与OUTPUT链中。
“-d 192.168.1.146 -p tcp –dport 3389″表示报文的目标地址为公司的公网IP地址,目标端口为tcp的3389号端口,而我们知道,windows远程桌面使用的默认端口号就是3389,当外部主机访问公司公网IP的3389号端口时,报文则符合匹配条件。
“-j DNAT –to-destination 10.1.0.6:3389″表示将符合条件的报文进行DNAT,也就是目标地址转换,将符合条件的报文的目标地址与目标端口修改为10.1.0.6:3389,”–to-destination”就是动作DNAT的常用选项。
那么综上所述,上图中定义的规则的含义为,当外网主机访问公司公网IP的3389时,其报文的目标地址与端口将会被映射到10.1.0.6:3389上。
好了,DNAT规则定义完了,现在能够直接使用外网主机访问私网中的服务了吗?
理论上只要完成上述DNAT配置规则即可,但是在测试时,只配置DNAT规则后,并不能正常DNAT,经过测试发现,将相应的SNAT规则同时配置后,即可正常DNAT,于是我们又配置了SNAT
示例如下。
注:理论上只配置DNAT规则即可,但是如果在测试时无法正常DNAT,可以尝试配置对应的SNAT,此处按照配置SNAT的流程进行。
没错,与刚才定义SNAT时使用的规则完全一样。
好了,完成上述配置后,我们则可以通过B主机的公网IP,连接D主机(windows主机)的远程桌面了,示例如下。
找到公网中的一台windows主机,打开远程程序
输入公司的公网IP,点击连接按钮
注意:没有指定端口的情况下,默认使用3389端口进行连接,同时,为了确保能够连接到windows虚拟主机,请将windows虚拟主机设置为允许远程连接。
输入远程连接用户的密码以后,即可连接到windows主机
连接以后,远程连接程序显示我们连接到了公司的公网IP,但是当我们查看IP地址时,发现被远程机器的IP地址其实是公司私网中的D主机的IP地址。
上图证明,我们已经成功的通过公网IP访问到了内网中的服务。
同理,使用类似的方法,我们也能够在外网中访问到C主机提供的web服务。
示例如下。
如上图所示,我们将公司公网IP的801号端口映射到了公司内网中C主机的80端口,所以,当外网主机访问公司公网IP的801端口时,报文将会发送到C主机的80端口上。
这次,我们不用再次定义SNAT规则了,因为之前已经定义过SNAT规则,上次定义的SNAT规则只要定义一次就行,而DNAT规则则需要根据实际的情况去定义。
好了,完成上述DNAT映射后,我们在A主机上访问B主机的801端口试试,如下
可以看到,我们访问的是B主机的公网IP,但是返回结果显示的却是C主机提供的服务内容,证明DNAT已经成功。
而上述过程中,外网主机A访问的始终都是公司的公网IP,但是提供服务的却是内网主机,但是我们可以对外宣称,公网IP上提供了某些服务,快来访问吧!
我觉得我说明白了,你听明白了吗?
动作MASQUERADE
上文中,我们已经描述了SNAT,也就是源地址转换,那么我们现在来认识一个与SNAT类似的动作:MASQUERADE
当我们拨号网上时,每次分配的IP地址往往不同,不会长期分给我们一个固定的IP地址,如果这时,我们想要让内网主机共享公网IP上网,就会很麻烦,因为每次IP地址发生变化以后,我们都要重新配置SNAT规则,这样显示不是很人性化,我们通过MASQUERADE即可解决这个问题,MASQUERADE会动态的将源地址转换为可用的IP地址,其实与SNAT实现的功能完全一致,都是修改源地址,只不过SNAT需要指明将报文的源地址改为哪个IP,而MASQUERADE则不用指定明确的IP,会动态的将报文的源地址修改为指定网卡上可用的IP地址,示例如下:
如上图所示,我们指定,通过外网网卡出去的报文在经过POSTROUTING链时,会自动将报文的源地址修改为外网网卡上可用的IP地址,这时,即使外网网卡中的公网IP地址发生了改变,也能够正常的、动态的将内部主机的报文的源IP映射为对应的公网IP。
可以把MASQUERADE理解为动态的、自动化的SNAT,如果没有动态SNAT的需求,没有必要使用MASQUERADE,因为SNAT更加高效。
动作REDIRECT
使用REDIRECT动作可以在本机上进行端口映射
比如,将本机的80端口映射到本机的8080端口上
iptables -t nat -A PREROUTING -p tcp –dport 80 -j REDIRECT –to-ports 8080
经过上述规则映射后,当别的机器访问本机的80端口时,报文会被重定向到本机的8080端口上。
REDIRECT规则只能定义在PREROUTING链或者OUTPUT链中。
小结
为了方便以后回顾,我们对上述命令进行总结。
如果想要NAT功能能够正常使用,需要开启Linux主机的核心转发功能。
echo 1 > /proc/sys/net/ipv4/ip_forward
SNAT相关操作
配置SNAT,可以隐藏网内主机的IP地址,也可以共享公网IP,访问互联网,如果只是共享IP的话,只配置如下SNAT规则即可。
iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -j SNAT --to-source 公网IP
如果公网IP是动态获取的,不是固定的,则可以使用MASQUERADE进行动态的SNAT操作,如下命令表示将10.1网段的报文的源IP修改为eth0网卡中可用的地址。
iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -o eth0 -j MASQUERADE
DNAT相关操作
配置DNAT,可以通过公网IP访问局域网内的服务。
注:理论上来说,只要配置DNAT规则,不需要对应的SNAT规则即可达到DNAT效果。
但是在测试DNAT时,对应SNAT规则也需要配置,才能正常DNAT,可以先尝试只配置DNAT规则,如果无法正常DNAT,再尝试添加对应的SNAT规则,SNAT规则配置一条即可,DNAT规则需要根据实际情况配置不同的DNAT规则。
iptables -t nat -I PREROUTING -d 公网IP -p tcp --dport 公网端口 -j DNAT --to-destination 私网IP:端口号
iptables -t nat -I PREROUTING -d 公网IP -p tcp --dport 8080 -j DNAT --to-destination 10.1.0.1:80
iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -j SNAT --to-source 公网IP
在本机进行目标端口映射时可以使用REDIRECT动作。
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
配置完成上述规则后,其他机器访问本机的80端口时,会被映射到8080端口。
十四、iptables小结之常用套路
此处,我们对前文中的一些注意点进行总结,我们可以理解为对”常用套路”的总结。
记住这些套路,能让我们事半功倍。
阅读这篇文章之前,请确定你已经阅读了之前的文章,否则你有可能会不理解为什么要这样做。
1、规则的顺序非常重要。
如果报文已经被前面的规则匹配到,IPTABLES则会对报文执行对应的动作,通常是ACCEPT或者REJECT,报文被放行或拒绝以后,即使后面的规则也能匹配到刚才放行或拒绝的报文,也没有机会再对报文执行相应的动作了(前面规则的动作为LOG时除外),所以,针对相同服务的规则,更严格的规则应该放在前面。
2、当规则中有多个匹配条件时,条件之间默认存在”与”的关系。
如果一条规则中包含了多个匹配条件,那么报文必须同时满足这个规则中的所有匹配条件,报文才能被这条规则匹配到。
3、在不考虑1的情况下,应该将更容易被匹配到的规则放置在前面。
比如,你写了两条规则,一条针对sshd服务,一条针对web服务。
假设,一天之内,有20000个请求访问web服务,有200个请求访问sshd服务,
那么,应该将针对web服务的规则放在前面,针对sshd的规则放在后面,因为访问web服务的请求频率更高。
如果将sshd的规则放在前面,当报文是访问web服务时,sshd的规则也要白白的验证一遍,由于访问web服务的频率更高,白白耗费的资源就更多。
如果web服务的规则放在前面,由于访问web服务的频率更高,所以无用功会比较少。
换句话说就是,在没有顺序要求的情况下,不同类别的规则,被匹配次数多的、匹配频率高的规则应该放在前面。
4、当IPTABLES所在主机作为网络防火 墙时,在配置规则时,应着重考虑方向性,双向都要考虑,从外到内,从内到外。
5、在配置IPTABLES白名单时,往往会将链的默认策略设置为ACCEPT,通过在链的最后设置REJECT规则实现白名单机制,而不是将链的默认策略设置为DROP,如果将链的默认策略设置为DROP,当链中的规则被清空时,管理员的请求也将会被DROP掉。