Juniper防火墙常见故障应急预案
Juniper防火墙常见故障快速处理指南
应急启动条件:
故障一:CPU负载突发升高 故障二:并发会话突发升高 故障三:防火墙主备关系紊乱
应急操作步骤:
故障一:CPU负载突发升高
如果CPU持续升高,并且影响了业务的正常通信,而在规定时间内无法找到原因(例如找不到突发数据源、因为软硬件故障造成的CPU升高),可在收集完信息后,通过三层交换机替代防火墙,进行防火墙旁路的应急操作。(注意:在外联区与Internet区等需要NAT的地方不能使用此替代方案)
收集的信息至少包括如下内容: request support information set cli timestamp
show chassis routing-engine show system processes extensive
show security monitoring performance session
show security monitoring session fpc 故障二:并发会话突发升高 一般在会话总数升高时,可通过命令clear security flow session及时关闭无用的会话,此命令可以基于源/目标地址、源/目标端口、IP协议来关闭会话。 另外,可以通过命令 delete security flow tcp-session no-syn-check 打开对建立会话的包头syn标志位检测,以避免有攻击流量(例如rst flood)在防火墙上建立无用会 - ii - 话。 同时,可通过以下命令,临时降低每个ip允许的会话,以保证大部分的业务通讯: set security screen ids-option set security zones security-zone 如果会话持续升高,并且影响了业务的正常通信,而在规定时间内无法找到原因(例如找不到突发数据源、因为软硬件故障造成的会话升高),可在收集完信息后,通过三层交换机替代防火墙,进行防火墙旁路的应急操作。(注意:在外联区与Internet区等需要NAT的地方不能使用此替代方案) 收集的信息至少包括如下内容: request support information set cli timestamp monitor interface show security flow session summary show security flow cp-session summary show security flow session destination-prefix 故障三:防火墙主备关系紊乱 当两台防火墙都变成Master状态时,网络并不会中断,所有的流量会指向最后一台变成Master的防火墙。此时只要恢复主备防火墙之间的连线,网络即可恢复正常如果没有备用的线缆或者光线模块可以恢复主备防火墙的连接,可以强行将其中一台防火墙的连线拔下,以保证只有一台防火墙处在Master状态。 - iii - 目 录 1 CPU负载突发升高 ................................................................................................... 1 1.1 基础概念 .......................................................................................................................... 1 1.2 故障定位 .......................................................................................................................... 3 1.2.1 Flow CPU .................................................................................................................. 3 1.2.2 Task CPU .................................................................................................................. 5 1.3 监控管理 .......................................................................................................................... 5 1.4 应急操作 .......................................................................................................................... 6 2 并发会话突发升高 .................................................................................................... 7 2.1 基础概念 .......................................................................................................................... 7 2.2 故障定位 .......................................................................................................................... 7 2.2.1 检查新建会话 ........................................................................................................... 7 2.2.2 检查会话关闭情况 .................................................................................................... 8 2.3 监控管理 .......................................................................................................................... 9 2.4 应急操作 .......................................................................................................................... 9 3 防火墙主备关系紊乱 .............................................................................................. 10 3.1 基础概念 ........................................................................................................................ 10 3.2 故障定位 ........................................................................................................................ 10 3.3 监控管理 ......................................................................................................................... 11 3.4 应急操作 ......................................................................................................................... 11 - iv - 1 CPU负载突发升高 1.1 基础概念 Juniper SRX防火墙内有两类CPU:转发 CPU和控制CPU。 转发CPU也称为SPU,位于防火墙的SPC板卡,负责处理经过防火墙的业务流量,例如新建会话连接和基于session的转发;控制CPU位于防火墙的RE板卡,负责处理管理防火墙的任务流量,比如syslog/telnet等等。Flow CPU没有进程的概念,而Task CPU有进程可以通过get os task命令查看进程。 防火墙CPU突发升高时,要判断是哪类CPU升高,可通过如下命令查看SPU和RE CPU的利用率: SPU利用率: root@SRX# run show security monitoring performance spu node0: -------------------------------------------------------------------------- fpc 8 pic 0 Last 60 seconds: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 28: 0 29: 0 30: 0 31: 0 32: 0 33: 0 34: 0 35: 0 36: 0 37: 0 38: 0 39: 0 40: 0 41: 0 42: 0 43: 0 44: 0 45: 0 46: 0 47: 0 48: 0 49: 0 50: 0 51: 0 52: 0 53: 0 : 0 55: 0 56: 0 57: 0 58: 0 59: 0 fpc 8 pic 1 - 1 - Last 60 seconds: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 7: 0 8: 0 9: 0 10: 0 11: 0 12: 0 13: 0 14: 0 15: 0 16: 0 17: 0 18: 0 19: 0 20: 0 21: 0 22: 0 23: 0 24: 0 25: 0 26: 0 27: 0 28: 0 29: 0 30: 0 31: 0 32: 0 33: 0 34: 0 35: 0 36: 0 37: 0 38: 0 39: 0 40: 0 41: 0 42: 0 43: 0 44: 0 45: 0 46: 0 47: 0 48: 0 49: 0 50: 0 51: 0 52: 0 53: 0 : 0 55: 0 56: 0 57: 0 58: 0 59: 0 可以看到最近60秒的SPU利用率记录。 RE CPU利用率: root@SDTF01# run show chassis routing-engine node0: -------------------------------------------------------------------------- Routing Engine status: Slot 0: Current state Master Election priority Master (default) Temperature 39 degrees C / 102 degrees F CPU temperature 33 degrees C / 91 degrees F DRAM 2048 MB Memory utilization 15 percent CPU utilization: User 0 percent Background 0 percent Kernel 5 percent Interrupt 4 percent Idle 91 percent Model RE-S-1300 - 2 - Serial ID 90090071 Start time 2013-01-17 13:12:24 HKT Uptime 4 days, 23 hours, 1 minute, 36 seconds Last reboot reason 0x2:watchdog Load averages: 1 minute 5 minute 15 minute 0.17 0.08 0.06 其中idle CPU空闲资源,其他几项(User, Background, Kernel, Interrupt)相加即为当前RE CPU的利用率。 1.2 故障定位 1.2.1 Flow CPU 如果是SPU利用率较高,可能会影响到会话的建立,导致业务中断。一般来说,SPU升高,原因是有大量新建会话的突发,正常的业务流量和攻击流量(例如病毒产生的flood)都有可能导致大量的新建会话。如果流量命中了ALG、配置不够优化(最常匹配的策略放在最后、过低的会话、策略中打开logging或shaping)、流量命中了防火墙的screen选项等等也会导致CPU升高。 在判断出是SPU较高时,可按如下几个方面进行分析: 检查新建会话数 执行此可以看到过去96秒的每秒新建会话的数量平均值: {primary:node0} root@SRX3600-1> show security monitoring fpc 7 node0: -------------------------------------------------------------------------- FPC 7 PIC 0 CPU utilization : 0 % Memory utilization : 57 % - 3 - Current flow session : 0 Max flow session : 524288 Current CP session : 0 Max CP session : 2359296 Session Creation Per Second (for last 96 seconds on average): 0 一般来说当前显示的SPU每秒新建数量在30000以上,会导致该SPU在60%以上。按照防火墙的流量、配置方式的不同,SPU负载会有相应的变化。 在出现新建会话数大量增加时,请确认是否为正常流量,一般可通过与历史数据进行比对。如果和历史数据相比,有大量的突发,可以认为是有异常流量存在,可在防火墙上进行会话(在第3节介绍),同时查找攻击点。 查看日志 如果有攻击发生,匹配到防火墙的内置安全策略,在防火墙的日志中可查看到攻击源、攻击方式的相关信息,可助于定位攻击点。 show system alarms show log messages 查看流量最大的源 通过show security flow session | save ftp://x.x.x.x 获取完整session表,然后 使用软件分析。 同时在防火墙上下级联的交换机上进行镜像抓包,以便于后期模拟流量重放攻击。 查看是否匹配ALG ALG用以协商要动态打开的端口,防火墙在处理ALG流量时会耗费大量CPU的资源。如果配置错误,使本无需ALG干预的数据流都进行ALG处理,会导致防火墙CPU急剧升高。 - 4 - 通过show security alg / show security flow session resource-manager来查看ALG的开关状态以及是否有流量匹配到ALG 查看接口信息 查看是否有队列丢包,以确认是否有拥塞发生。 SRX> show interfaces ge-3/1/0 extensive | find gress Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 0 0 0 1 expedited-fo 0 0 0 2 assured-forw 0 0 0 3 network-cont 0 0 0 show interface 如果在某条policy中启用了logging、count等功能,在大量流量匹配此policy时,会导致CPU升高。并且,如果大量流量匹配的policy条目放在所有policy的最后,当policy总体条目较多时(5000条policy以上),也会消耗部分CPU的资源。 如果在启用了screen、session limit等功能,在设置不当时,会导致流量频繁触发告警,也会导致CPU升高。 1.2.2 RE CPU RE CPU升高一般是系统有管理行为时出现短暂的升高,例如防火墙在收集request support information信息时,会有1-2秒瞬间的升高。 要查看RE CPU升高的原因,可以通过show system process extension查看。 1.3 监控管理 通过网管软件监控防火墙CPU的利用率: - 5 - jnxJsSPUMonitoringCPUUsage(.1.3.6.1.4.1.2636.3.39.1.12.1.1.1.4.x)—最后1分钟CPU利用率(建议每分钟采样)。 通过命令的方式监控防火墙SPU的利用率: show security monitor performance spu 请注意收集平时防火墙的CPU数据基线,以便于平时对比查看是否有CPU负载突发的情况,以便于预警。 1.4 应急操作 如果CPU持续升高,并且影响了业务的正常通信,而在规定时间内无法找到原因(例如找不到突发数据源、因为软硬件故障造成的CPU升高),可在收集完信息后,通过三层交换机替代防火墙,进行防火墙旁路的应急操作。(注意:在外联区与Internet区等需要NAT的地方不能使用此替代方案) 收集的信息至少包括如下内容: SRX> request support information ###输出较多,建议用命令SRX> request support information | save /var/tmp/filename将输出保存在本地再用FTP方式获取 SRX> show log message ###message为默认log文件名 SRX> show chassis routing-engine SRX> show security monitoring fpc 7 SRX> show security monitoring performance spu SRX> show security monitoring performance session SRX>show security flow session SRX> show system processes extensive SRX> show chassis fpc SRX> show interfaces extensive - 6 - 2 并发会话突发升高 2.1 基础概念 Juniper防火墙采用的是状态检测技术,对每一个通过防火墙的连接,都需要建立并维持会话状态信息,对于所有需要经过防火墙的数据包,都必须先经过状态表的检查,如果状态表中无对应条目,再去检查规则(Access Control Policy )表,如果在规则表中找到了对应条目,并允许此数据包通过,则防火墙将此数据包转发,并同时在内存中建立起会话条目,因此会话条目的存在是数据报文快速转发的前提。 在防火墙上可以通过命令show security flow cp-session 来查看已经建立好的会话总数,命令输出如下: root@SDTF01# run show security flow cp-session node0: -------------------------------------------------------------------------- Total sessions: 0 可以看到目前并发为0,。当标示的会话总数达到防火墙性能容量后,防火墙将无法再建立新的会话,此时需要新建连接的业务数据就会中断。 2.2 故障定位 在出现防火墙会话总数突发时,一般是两种情况,一种是有大量的新建会话突发,还有一种是会话没有正常关闭。 2.2.1 检查新建会话 异常的流量不一定是攻击流量,网络设备或主机如果设置不当,也可能出现发起大量无用新建连接的故障。 - 7 - 在防火墙上执行show security flow cp-session查看新建会话的数量。 一般来说占用CPU资源较多的数据源,也是新建会话较大的数据源。所以当发现新建会话较高时,请参照会话表内容及告警日志,找到可能有问题的数据源。 可通过命令 set security screen ids-option 进行基于源的会话; set security screen ids-option 进行基于目标的会话。需要注意此命令是基于zone全局生效的,在配置时不要将number设置过小,导致影响正常业务通讯。 2.2.2 检查会话关闭情况 业务在正常关闭时会发送Fin或Rst包,防火墙在收到此类包后会拆除对应的会话。如果防火墙没有收到Fin或Rst包,也没有任何流量(双向)命中已建立会话条目,在达到超时时间后(倒记时方式),该会话将被系统自动清除。如果此间一旦有流量命中已建会话,会话超时值将立即恢复到系统缺省值。缺省的超时时间为: TCP 30分钟/ UDP 1分钟/ ICMP 1分钟。 需要注意的是,Juniper防火墙允许用户自定义服务超时时间,该自定义服务超时时间将优先于协议的超时时间,自定义服务的超时机制与协议超时机制保持一致。如果配置中设定了过长的超时时间,导致防火墙的会话无法及时关闭,万一会话有突发情况,就会出现会话总数到达防火墙上限的情况。 - 8 - 2.3 监控管理 通过网管软件监控防火墙会话的利用率: jnxJsSPUMonitoringCurrentFlowSession(.1.3.6.1.4.1.2636.3.39.1.12.1.1.1.6.x) 通过命令的方式监控防火墙会话的利用率: show security flow cp-session 请注意收集平时防火墙的会话数据基线,以便于平时对比查看是否有会话突发的情况,以便于预警。 2.4 应急操作 一般在会话总数升高时,可通过命令clear security flow session 及时关闭无用的会话,此命令可以基于源/目标地址、源/目标端口、IP协议来关闭会话。 另外,可以通过命令 delete security flow tcp-session no-syn-check 打开对建立会话的包头syn标志位检测,以避免有攻击流量(例如rst flood)在防火墙上建立无用会话。 同时,可通过上节讲解过的命令 set security screen ids-option 临时降低每个ip允许的会话,以保证大部分的业务通讯。 如果会话持续升高,并且影响了业务的正常通信,而在规定时间内无法找到原因(例如找不到突发数据源、因为软硬件故障造成的会话升高),可在收集完信息后,通过三层交换机替代防火墙,进行防火墙旁路的应急操作。(注意:在外联区与Internet区等需要NAT的地方不能使用此替代方案) - 9 - 收集的信息至少包括如下内容: SRX> show chassis routing-engine SRX> show security monitoring fpc 7 SRX> show security monitoring performance spu SRX> show security monitoring performance session SRX>show security flow session SRX> show system processes extensive SRX> show chassis fpc SRX> show interfaces extensive 3 防火墙主备关系紊乱 3.1 基础概念 目前民生银行防火墙的配置为主备(即Master/Backup)关系,同一时间只有主防火墙进行数据处理;备防火墙的接口状态为up,但是不会发送任何数据包。主备防火墙之间通过两条心跳线来检测对端,主防火墙在出现端口中断、异常告警(例如温度过高)、Track IP不可达或手工切换时,备墙会接管主墙工作,由backup变为Master状态。 3.2 故障定位 防火墙利用两条心跳线,一条是传输控制信息,一条传输数据信息。如果两条心跳线缆同时出现问题,会导致两台防火墙分别使用不同的接口传输控制信息,从而会误判对端防火墙已经宕机,此时两台防火墙都会变成Master状态。 当两台防火墙都变成Master状态时,网络并不会中断,所有的流量会指向最后一台变成Master的防火墙。此时只要恢复主备防火墙之间的连线,网络即可恢复正常。如果未能及时发现主备防火墙的状态改变,没有及时恢复连线,在防火墙上下联的交换机arp/mac table更新后,可能会导致流量分别指向不同的防火墙,此时业务通讯可能 - 10 - 会受到影响。 3.3 监控管理 通过命令的方式监控防火墙的主备状态: show chassis cluster status 3.4 应急操作 当两台防火墙都变成Master状态时,网络并不会中断,所有的流量会指向最后一台变成Master的防火墙。此时只要恢复主备防火墙之间的连线,网络即可恢复正常如果没有备用的线缆或者光线模块可以恢复主备防火墙的连接,可以强行将其中一台防火墙的连线拔下,以保证只有一台防火墙处在Master状态。 - 11 - 因篇幅问题不能全部显示,请点此查看更多更全内容
Copyright © 2019- sarr.cn 版权所有 赣ICP备2024042794号-1
违法及侵权请联系:TEL:199 1889 7713 E-MAIL:2724546146@qq.com
本站由北京市万商天勤律师事务所王兴未律师提供法律服务