小锐常常接到客户的反馈是,防火墙部署好了但是业务还是不通,往往束手无策。今天小锐,不藏着掖着了,把收藏多年的佳酿,故障小窍门拿出来让喜欢小锐的大家细品细品。
防火墙的安全检查特性
网络源于生活却又高于生活,作为网络世界大门的鼎鼎大名的“安全检查官“下一代防火墙,有他自己特有的“安全属性”,遵守网络世界的“安全规则”,我们就能更好的在防火墙的故障排查过程中游刃有余。这些“安全属性”倒成了我们在实施防火墙过程中的“绊脚石”,虽然排查故障过程是痛苦的,但解决问题后的快乐是永远铭记值得回味的。
防火墙为了相信数据包是可信的,在收到数据包的时候设置了两个“安全检查点”:
1反向路径检查Reverse Path Forwarding (RPF)
2异步检查(asymroute,也就是大家常说的连接完整性检查)
两项检查只有都符合,才会继续其他模块检查,否则直接丢弃数据包,那针对这两个检查特性我们展开聊聊:
反向路径检查
所谓反向路径检查,简单举例,就是如果从内网口port31收到一个数据包,反向的回包必须从内网口port31回去,也就是要确保源进源出,反之认为此数据包为欺骗包执行丢弃动作。假设,防火墙收到数据包是src_addr_ip->dst_addr_ip为172.16.1.16->219.222.191.72,防火墙不会执行其他模块检查(这些模块会涉及到源目的地址转换、UTM等),而是先执行反向路径检查,根据反向流量219.222.191.72->172.16.1.16,在查找路由表后如果也是从port31出去的,说明流量是正常的,继续处理其他模块检查;如果存在另一个路由通路比如从port32出去或者甚至没有查找到相应路由,这个将导致反向路径检查失败防火墙执行丢弃动作。
使用debug flow抓包命令,会发现有个提示为:reverse path check fail, drop,特别显眼,这个提示就是因反向路径检查失败直接执行了丢弃动作了,这种情况建议是查一下防火墙上的路由配置问题。
异步路由检查
所谓异步路由检查,就是要确保来回路径要一致,保证数据连接的完整性。如:tcp的三次握手的数据包都要过防火墙,正常的tcp三次握手交互过程如下:
如果出现来回路径不一致的情况,防火墙认为报文有问题直接丢弃。
小锐现在就说说这流量转发哪里出现问题了,从流量转发来看PC1访问服务器的流量tcp syn报文转发路径是
PC1->RouterA->NGFW->RouterB->internet->Server,回包syn ack的转发路径是Internet>RouterB>RouterA->PC1,未经过防火墙,ack报文PC1->RouterA->NGFW(丢弃报文不转发),防火墙发现会话状态不完整(我没有看到syn ack,我不信任你),执行丢弃动作。
使用debug flow命令对数据流分析一般会提示为:“org dir, ack in state syn_sent, drop”
当然这里还有更为奇葩的数据转发路径,如果是syn包转发路径不过防火墙,syn ack的回复报文经过防火墙,这种情况下防火墙是无法找到对应的会话(我没有看到syn,我压根就没有你的会话),直接丢弃,这种也属于异步路由的一种特殊场景。使用debug flow抓包命令,会发现有个提示为:“no session matched”。
还有一种就是来回的二层mac不一致问题也是异步路由检查的一种特例了,一般这种场景常见于防火墙透明模式部署的时候。也就是如果过防火墙的数据包是mac1->mac2[pc1->pc2],回包的时候是mac3->mac1[pc2->pc1],这种数据包也是有问题的防火墙不会允许过的。
那可能大家会问小锐,异步路由检查可以关闭吗,实际业务场景不建议关闭的,最好的做法是找到导致来回路径不一致的原因,将异步问题终结掉,因为防火墙关闭异步检查后,多链路出口的场景源进源出功能将不生效,代理防护类utm功能将无法正常工作。
方法是:
#config system settings
#set asymroute enable
#end
此命令就是允许防火墙存在异步,这样防火墙可以不检查数据包的连接完整性了。
#config system settings
#set tcp-session-without-syn enable (默认disable)
#end
此命令是告诉防火墙如果不是syn的报文一样也可以创建会话。
数据包穿越防火墙处理过程详解
正常的数据包穿越防火墙,需要经过哪些过程呢?可以通过debug flow命令查看整个完整过程。
#diagnose debug enable //开启debug
#diagnose debug flow show console enable //启用debug flow显示打印,有些版本不需要敲
#diagnose debug flow show function-name enable //显示debug flow 功能名称,便于打印信息输出,有些版本可以不用敲
#diagnose debug flow filter addr 192.168.1.110 //过滤条件,避免抓包无用信息过多,这里过滤地址,filter ?可以查看过滤哪些条件
#diagnose debug flow trace start 100 //开始抓100条数据流
下面是数据包穿越防火墙的全部过程,我们一起来看看
id=36871 trace_id=1 msg="vd-root received a packet(proto=6, 192.168.
1.110:51661->119.253.62.131:80) from internal. "id=36871 trace_id=1 msg="allocate a new session-00016920" //internal口收到数据,建立新会话
id=36871 trace_id=1 msg="find a route: gw-192.168.118.1 via wan1" //查找到路由表
id=36871 trace_id=1 msg="find SNAT: IP-192.168.118.28, port-43333" //检测存在NAT配置
id=36871 trace_id=1 msg="Allowed by Policy-1: SNAT" //匹配策略,ID1
id=36871 trace_id=1 msg="SNAT 192.168.1.110->192.168.118.28:43333"//做NAT
id=36871 trace_id=3 msg="vd-root received a packet(proto=6,
119.253.62.131:80->192.168.118.28:43333) from wan1." // Wan1口收到返回数据包
id=36871 trace_id=3 msg="Find an existing session, id-00016920, reply direction" //数据包匹配会话id-0001692
id=36871 trace_id=3 msg="DNAT 192.168.118.28:43333->192.168.1.110:51661" //做反向的DNAT
id=36871 trace_id=3 msg="find a route: gw-192.168.1.110 via internal" //查找路由,发送到internal口
id=36871 trace_id=5 msg="vd-root received a
packet(proto=6,192.168.1.110:51661->119.253.62.131:80) frominternal." //internal口收到后续数据包
id=36871 trace_id=5 msg="Find an existing session, id-00016920, original direction" //匹配会话id-0001692
id=36871 trace_id=5 msg="enter fast path" //直接转发
id=36871 trace_id=5 msg="SNAT 192.168.1.110->192.168.118.28:43333" //NAT
抓完数据流后可以通过以下命令关闭。
#diagnose debug flow trace stop //停止
#diagnose debug disable //关闭
#diagnose debug reset //重置
#diagnose debug flow filter clear //可以清空debug的过滤条件设置
通过debug flow命令我们可以看到一个数据包流入防火墙后,各个模块的详细处理情况,整理成数据包处理流程图如下:
下面也一并介绍一些小锐常常遇到的debug flow关键信息提示,现总结如下:
如果是策略拒绝了数据包访问,会看到“Denied by forward policy check”,需要重点确认是否是安全策略拦截所致。
如果无法正常管理防火墙的时候,debug flow往往会出现提示,msg="iprope_in_check() check failed, drop",一般会有下列三种可能原因所致:
1、当访问NGFW进行远程管理(ping, telnet, ssh ...)时,正在访问的服务未在接口上启用。
2、当访问NGFW进行远程管理时(ping, telnet, ssh ...),正在访问的服务在接口上启用,但是配置了受信任的主机,这些主机与入站数据包的源IP不匹配;
3、当通过同一NGFW的另一个接口访问用于远程管理的NGFW接口(ping,telnet,ssh ...)时,不存在防火墙策略。
策略动作拒绝,或命中隐含策略, 数据包被拒绝,一般会提示:msg="Denied by forward policy check"
如果涉及ALG相关会话(这类流量一般是动态多通道协议如ftp、sip等,此类协议较复杂,小锐下次再跟大家分享,嘻嘻)将送至 session-helper 模块处理,一般会提示:msg="run helper-ftp(dir=original)"
看到这里,小锐相信您也和小锐一样get 了不少防火墙的抓包命令了吧?那么接下来我们继续深入看下进阶版案例分析吧。
进阶案例展示一下命令有多么神奇^-^
现场反馈的拓扑简单描述如下:
全新下一代防火墙做端口映射,部分ISP专网IP访问端口映射的业务不通。基础的配置检查也没有看出问题所在,那接下来使用强大的debug flow对其数据流进行捕获,在信息输出中发现防火墙本地回复了RST报文(也就是图中的...from local. flag [R]),这点甚是可疑,说明问题还是出在防火墙的哪个模块处理环节上。
那我们一起开动脑筋思考一下什么情况下防火墙会主动发送RST包?
从数据包转发上我们注意到tcp syn将通过防火墙,但是当接收到tcp syn / ack时,NGFW会将tcp rst发送回tcp syn / ack的始发者。
即使存在允许流量通过NGFW的策略,配置错误的IPpool或VIP[l7] 也会给TCP连接造成连接问题。(名词解释:这里的ippool一般是用在上网做源地址转换的时候,一个地址不够用,可以把内网的源地址转换成一个地址段范围内的地址,VIP是防火墙的端口映射,也就是大家常说的目的地址转换关系)
一般这种问题的可能性是:本地有相应的IP地址(比如是源地址)了,因为没有对应的服务在监听,会去响应RST报文,按照这种排查思路去检查配置。
那我们把问题点锁定在IPPool或VIP上重点排查,通过配置查看找到了这个始作俑者。将对应错误的策略配置删除问题解决。
经确认现场源地址10.85.40.3也加到了虚拟ip映射里了。对于防火墙配置不太熟悉的往往可能会出现这种奇怪的配置,有时候策略一多真的用肉眼很不好看出问题出在哪儿。
一般出现防火墙回复...from local. flag [R]的情况有如下三种:
1、将服务器地址配置到了IPpool里;
2、将客户端IP地址配置到了IPpool里;
3、将客户端IP地址配置到了VIP里。
总结
Debug flow命令是防火墙实施部署过程中使用频率极高,而且故障诊断问题定位率可达80%左右,真的是算上是爱说大实话的命令了,提示什么原因一般故障就定位出来 了,是小锐力荐需掌握的命令,学会了就是掌握了上乘武功了哦,一起修炼起来吧。