这些防火墙命令都爱说大实话,让排障少走弯路 -运维实战家

2021-08-06 17:20:00 0

图片关键词


图片关键词

本文作者:阿昌


小锐常常接到客户的反馈是,防火墙部署好了但是业务还是不通,往往束手无策。今天小锐,不藏着掖着了,把收藏多年的佳酿,故障小窍门拿出来让喜欢小锐的大家细品细品。




防火墙的安全检查特性



网络源于生活却又高于生活,作为网络世界大门的鼎鼎大名的“安全检查官“下一代防火墙,有他自己特有的“安全属性”,遵守网络世界的“安全规则”,我们就能更好的在防火墙的故障排查过程中游刃有余。这些“安全属性”倒成了我们在实施防火墙过程中的“绊脚石”,虽然排查故障过程是痛苦的,解决问题后的快乐是永远铭记值得回味的。


防火墙为了相信数据包是可信的,在收到数据包的时候设置了两个“安全检查点”:


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%左右,真的是算上是爱说大实话的命令了,提示什么原因一般故障就定位出来 了,是小锐力荐需掌握的命令,学会了就是掌握了上乘武功了哦,一起修炼起来吧。



    首页
    产品
    新闻
    联系