Check+Point防火墙设备故障处理指导手册+V2.0

Check Point防火墙故障处理

指导手册V2.1

2012/03/30

文档修订记录

文档说明

此文档是由以色列捷邦安全软件科技公司于2012/3/30制定的内部文档。本文档仅就CheckPoint 内部与相关合作伙伴和CheckPoint最终用户使用。

版权说明

本文档中出现的任何文字叙述、文档格式、插图、照片、方法、代码等内容，除由特别注明，版权均属于以色列捷邦安全软件科技公司所有，受到有关产权及版权法保护。任何个人、机构未经以色列捷邦安全软件科技公司书面授权许可，不得以任何方式复制或引用本文档的任何片断。

2

目录

1文档描述 (5)

2故障排错流程 (6)

2.1防火墙故障处理流 (6)

2.2故障级别定义： (6)

3防火墙故障处理 (7)

3.1．防火墙一级故障处理： (7)

3.2．防火墙二级故障处理： (11)

3.3．防火墙三级故障处理： (14)

3.4．防火墙四级故障处理： (15)

3.5．防火墙路由故障处理： (15)

4故障现象检查 (16)

4.1问题节点确认 (16)

4.1.1防火墙硬件问题 (17)

4.1.2网络环境问题 (19)

4.1.3防火墙软件问题 (20)

4.1.4防火墙性能问题 (21)

5功能模块Debug过程 (22)

5.1防火墙Kernel Debug命令 (23)

5.1.1概述: (23)

5.1.2Debug flags and modules: (23)

5.1.3Debug的buffer: (23)

5.1.4参考的命令: (23)

5.2正常流量被拦截的排查流程 (25)

5.3VPN故障排查流程 (26)

5.4VPN Debug的排错流程 (28)

5.5Endopoint Connect 连接问题排错流程 (28)

5.6ClusterXL 排错流程 (32)

5.6.1开始ClusterXL debug前需要检查的项目 (35)

5.6.2CluseterXL问题的Kernel debug 命令 (35)

5.7防火墙日志问题排错流程 (37)

5.8策略下发失败的问题排错流程 (38)

5.9Voip协议的排错流程 (39)

6防火墙巡检报告 (40)

6.1防火墙(FW)信息输入 (43)

6.2管理服务器(SMC)信息输入 (43)

6.3防火墙物理层运行状况检查 (44)

6.3.1硬件资源使用情况 (44)

6.3.2硬件资源健康检查 (44)

6.4防火墙系统层运行状况检查 (45)

6.4.1系统运行日志分析 (45)

6.4.2系统安全配置检查 (45)

6.4.3系统与策略备份检查 (46)

6.4.4系统垃圾文件检查 (46)

6.5防火墙应用运行状态检查 (46)

6.5.1防火墙进程检查 (46)

6.5.2防火墙链接表检查 (47)

6.5.3ClusterXL状态检查 (47)

6.5.4SecureXL状态检查 (48)

6.5.5防火墙流量分析 (48)

6.5.6防火墙License检查 (49)

6.5.7管理服务器安全检查(Windows) (49)

1文档描述

本文档用于Check Point防火墙设备出现故障时作为判断及收集信息使用。在日常的排除故障过程中，除了必要的网络情况判断，拓扑信息描述等，还需要收集防火墙以及相关设备的有关信息，以下主要对防火墙的相关故障所需获取的信息及排错过程进行描述。

首先，防火墙设备存在的故障问题主要分如下几大类：

?设备崩溃问题

适用于设备出现无故重启、设备无响应或设备出现完全失去工作能力，即设备硬件或者软件导致的宕机等情况。

?性能处理问题

适用于防火墙出现性能处理问题的环境，如出现严重的丢包、极高的网络延时、所有业务出现访问缓慢等情况。

?业务访问问题

适用于业务数据流通过防火墙之后出现的业务不通，或访问缓慢等情况。

?OSPF问题

适用于防火墙启用动态OSPF路由协议的环境，如出现OSPF路由问题，邻居协商问题等。防火墙出现不同故障，必须使用不同的命令收集相应信息，在命令的使用过程中，基本信息命令收集是必须的，DEBUG的命令信息视具体情况而定，最好能够获取该类信息。

注意：运行命令过程中需启用终端软件的日志记录功能，记录所有操作会话。

2故障排错流程

2.1防火墙故障处理流

流程说明：从防火墙的排障的总体流程来看，首先必须确定故障点设备，再从故障点设备进行排错。流程主要集中在防火墙的问题进行说明，以下对流程进行说明：

2.2故障级别定义：

3防火墙故障处理

3.1．防火墙一级故障处理：

A:一级故障定义：

对业务运营造成灾难性影响

网络或系统停机，导致客户业务完全停止服务；

如：防火墙系统crash，且未发生切换，业务完全受阻。

B:信息内容搜集：

如无法快速判断故障问题，请抓取最基本数据：注意需要收集两台设备信息

如无法通过SSH登录设备，请通过原装console线登录设备命令行收集，所有会话需要记录到文件。

IP平台设备信息搜集:

设备宕机没有切换，硬关机，然后加电重启设备，使用Console线搜集重启的字符输出。 登录系统后搜集所有coredump文件，如下所示，通常在/var/crash目录 [admin]# find / -name "*core*"

/var/crash/vmcore.0.gz

/var/crash/vmcore.1.gz

/var/crash/vmcore.2.gz

搜集系统CST文件

CST是Configuration Summary Tool的简写，CST文件会包含系统配置、版本信息、系统运行情况、系统日志、甚至保存在本地硬盘上的防火墙日志，如果不需要搜集防火墙日志可以使用IPSO-A[admin]# cst –small命令，缩短搜集CST的时间，搜集完整的CST过程如下:

IPSO-A[admin]# cst

CST version 2007-09-26

=============== N O T I C E: VOYAGER LOCKS =========================

Please make sure you are logged out of Voyager.

CST gathers certain information from clish, which may not work

when there is a configuration lock in place established by an active

Voyager session.

=============== E N D O F N O T I C E =========================

Continue? [y] y

Output Directory? [.] /var/tmp #指定CST文件的存储目录注意:ECST文件，其路径在/opt/ecst_output。

如果设备完全挂起，接入console口没有任何输出的情况下，或者如下情况：System hang

Complete loss of connectivity

No console login prompt

Transient failure/performance conditions

Out of memory conditions

Out of swap conditions

请通过如下步骤搜集信息，首先准备如下设备，

一个DTE (Date Terminal Equipment) 支持数据通信标准EIA/TIA-232 的console线连接到 IPSO console接口.

必须通过如下Terminal工具登录:

HyperTerm,SecureCRT (Windows)

cu or tip (UNIX)

Serial console (terminal) server.

Dumb terminal.

DTE串口属性设置参数

9600 bps

8 data bits

1 stop bit

No parity

No flow control

---------------------------------------------------------------------------

1.在发生故障时，接入console线到设备，

2.在console工具上启用会话记录，

3.首先敲键盘“Break”键，然后立即执行”ddb”,屏幕上不会显示任何输出。

4.如果发生Crash你将会看到有输出，否则重复步骤1~3

5.如果有输出信息后，输入 ps 命令 (观察并且搜集进程信息)

6.输入 trace 命令 (观察并且搜集trace 信息)

7.输入一个 continue 命令返回 IPSO

8.重复3到6的步骤多次，直到输出信息相同。

9.输入 panic 命令 (系统将dump 一个 core 文件并且重启)

10.保存完整的会话日志和core文件并且上传给support。

到 ipso系统使用命令[admin]# find / -name "*core*"确认找到core 文件, 同时从$FWDIR/bin/boot/modules目录下尽量搜索并且得到所有的*.o 文件。

-----------------------------------------------------------------------------------

Power-1与UTM-1平台信息搜集:

如无法快速判断故障问题，请抓取最基本数据：注意需要收集两台设备信息

如无法通过SSH登录设备，请用原装console线登录设备命令行收集，所有会话需要记录到文件。 设备宕机没有切换，硬关机，然后加电重启设备，使用Console线搜集重启的字符输出。 登录系统后搜集所有coredump文件，操作过程如下所示:

SecurePlatform OS 2.4

启用生成 User Mode core dump文件:

进入 Expert 模式

# expert

设置core dump文件的大小为'unlimited'

# ulimit -a

# ulimit -c unlimited

# ulimit -a

注意: 如需禁用则允许'ulimit -c 0'命令

确认'/etc/sysctl.conf' 文件中如下行的输出为1

# Controls whether core dumps will append the PID to the core filename.

# Useful for debugging multi-threaded applications.

kernel.core_uses_pid = 1

校验 LKCD（Linux Kernel Crash Dump）工具的级别设置如下

# less -N -M /etc/sysconfig/dump

到输出信息的最后查看如下输出的参数一直，如果数值不一致则使用vi编辑工具修改为如下值。DUMP_ACTIVE=1

DUMPDEV=/dev/vmdump

DUMPDIR=/var/log/dump

DUMP_SAVE=1

DUMP_LEVEL=8

DUMP_FLAGS=0

DUMP_COMPRESS=0

PANIC_TIMEOUT=5

保存LKCD工具的参数设置

# /sbin/lkcd config

确认如下目录已经存在

/var/log/dump/usermode

如果没有，需要创建一个目录。

# mkdir -p /var/log/dump/usermode

保存配置，重启设备

# reboot

当下次设备发生挂起或者重启时，系统会记录下core dump信息到如下文件。

/var/log/dump/usermode/ProcessName.PID.core

SecurePlatform OS 2.6 启用core dump的步骤

启用生成 User Mode core dump文件:

进入 Expert 模式

# expert

设置core dump文件的大小为'unlimited'

# ulimit -a

# ulimit -c unlimited

# ulimit -a

注意: 如需禁用则允许'ulimit -c 0'命令

确认'/etc/sysctl.conf' 文件中如下行的输出为1

# Controls whether core dumps will append the PID to the core filename.

# Useful for debugging multi-threaded applications.

kernel.core_uses_pid = 1

确认如下目录已经存在

/var/log/dump/usermode

如果没有，需要创建一个目录。

# mkdir -p /var/log/dump/usermode

保存配置，重启设备

# reboot

当下次设备发生挂起或者重启时，系统会记录下core dump信息到如下文件。

/var/log/dump/usermode/ProcessName.PID.core

也可以通过命令搜索core dump文件，如下所示。

[admin]# find / -name "*core*"

/var/crash/vmcore.0.gz

/var/crash/vmcore.1.gz

/var/crash/vmcore.2.gz

Core dump 文件搜集到后将文件上传给TAC做进一步分析。

搜集系统cpinfo文件

Cpinfo是SecurePlatform(SPLAT)的配置文件、系统日志以及设备当前运行状态的[R71-FWA]# expert #登入专家模式

Enter expert password:

You are in expert mode now.

[Expert@R71-FWA]# cpinfo -n -z -o /var/tmp/FWA.cpinfo #执行命令导出cpinfo cpinfo (I:0110): Beginning ...

cpinfo (I:0116): Latest cpinfo version: https://www.360docs.net/doc/3d4116961.html,/downloads/

cpinfo (I:0112): Embedding files ...

cpinfo (I:0117): Zipping output file ...

cpinfo (I:0118): Zipping output file - done (/var/tmp/FWA.cpinfo.gz) cpinfo (I:0111): Done

[Expert@R71-FWA]#

[Expert@R71-FWA]# ls

[Expert@R71-FWA]# cd /var/tmp

[Expert@R71-FWA]# ls -alt

total 7380

drwxrwxrwt 4 root root 4096 Nov 6 17:10 .

-rw-rw---- 1 root root 7527853 Nov 6 17:10 FWA.cpinfo.gz

drwxrwxrwt 2 root root 4096 Nov 3 22:22 vi.recover

然后使用FTP工具将文件传出去供Check Point技术工程师分析。

C：完成相关故障信息收集后，进行故障恢复处理

1：进行防火墙倒换（故障设备为主设备，故障时未发生切换）

如果是IPSO（IP）平台，做主备切换通过登录系统Web管理页面，修改备机所有VRRP接口的priority值高于主机即可实现切换。

如果是SPLAT平台(Power-1或者UTM-1)，通过命令可以clusterXL_admin off做主备切换。

物理切换操作：拔除故障防火墙设备业务连线，console连接到备机，观察备机的HA状态，状态变为Master后，观察业务。

2: 若拔线后，防火墙双机未发生切换，则重启故障防火墙。

注意：此时请将console线连接故障防火墙console口，记录输出。

D:请将相关信息提交给Check Point支持人员。

3.2．防火墙二级故障处理：

A:二级故障定义：

严重影响业务运营。

对最终客户造成间歇影响的网络或系统事件；

如：防火墙系统拦截重要应用，或者部分网络不通。

B:信息内容搜集：

首先收集SmartView Tracker中存在问题源地址或者协议的日志截图

如无法快速判断故障问题，请抓取最基本数据：注意需要收集主用(或故障)设备信息

使用kernel debug在故障期间进行debug数据收集

使用抓包命令和工具对故障业务进行抓包

IP平台设备信息搜集:

从SmartView Tracker中收集故障信息

打开SmartDashboard→选择SmartView Tracker然后过滤出存在问题的网段和协议，双击存在问题的日志记录，将日志信息截图保存下来。

搜集系统CST文件

CST是Configuration Summary Tool的简写，CST文件会包含系统配置、版本信息、系统运行情况、系统日志、甚至保存在本地硬盘上的防火墙日志，如果不需要搜集防火墙日志可以使用IPSO-A[admin]# cst –small命令，缩短搜集CST的时间，搜集完整的CST过程如下:

IPSO-A[admin]# cst

CST version 2007-09-26

=============== N O T I C E: VOYAGER LOCKS =========================

Please make sure you are logged out of Voyager.

CST gathers certain information from clish, which may not work

when there is a configuration lock in place established by an active Voyager session.

=============== E N D O F N O T I C E =========================

Continue? [y] y

Output Directory? [.] /var/tmp #指定CST文件的存储目录

搜集fw monitor信息

fw monitor是Check Point软件自带的抓包工具，主要用于检测数据包在通过防火墙时的状态，确认问题是发生在系统层，还是防火墙本身拦截了报文。

[IPSO]#fw monitor -e "accept sport=21 or dport=21 and src=192.168.0.190 or dst=192.168.0.253;" -o /var/tmp/monitor.cap

如上fw monitor抓取源地址是192.168.0.190访问到192.168.0.253的任何源端口与目标端口都是21的流量，并且将输出的内容记录在var/tmp/monitor.cap文件中。以上命令是一个较全的例子，可以根据实际环境精简命令。

[IPSO]#fw monitor -e 'PROTO_tcp,dport=8001 or sport=8001;' -o /var/tmp/monitor.cap

如上所示，是针对TCP 8001协议进行的抓包，假如客户8001协议通过防火墙时访问不通，

则通过fw monitor针对该协议进行针对性的抓包，并将文件保存在/var/tmp/目录。

如果协议属性是udp协议，使用如下命令，修改PROTO_udp即可，然后制定端口。

[IPSO]# fw monitor -e 'PROTO_udp,dport=8001 or sport=8001;' -o /var/tmp/monitor.cap

搜集tcpdu mp抓包信息

Tcpdump是系统抓包命令，通常是操作系统层的抓包，用来判断网络层数据包交互访问过程是否正常，所有使用的IP地址以真实环境中存在问题的IP或者协议来抓包。

[IPSO]#tcpdump -vv -e -w /var/tmp/test.cap -i eth-s1/s2p4c0 -nn src 192.168.203.19 and dst 192.168.203.17

如上tcpdump抓取接口eth-s1/s2p4c0上源地址为192.168.203.19访问到192.168.203.17的报文，通过-w命令将文件保存为/var/tmp/目录下test.cap文件。

[IPSO]# tcpdump -vv -e -w /var/tmp/test.cap -i eth0 port 80 and dst 192.168.0.1

如上是抓取接口eth0上端口为80目标地址192.168.0.1的命令，保存文件名为test.cap 的文件到/var/tmp/目录。

搜集防火墙kernel层debug信息

搜集zdebug信息对理解和找到报文被防火墙丢弃的原因很重要，zdebug启用后，默认的buffer size 是1024KB,主要对fw、h323、cluster、vpn、rtm模块的问题进行故障信息收集，所以是一个包含信息较全的命令，而且执行方便，强烈建议在问题发生期间进行debug，并开放1~2分钟。

[admin]# fw ctl zdebug + drop > /var/tmp/drops.txt

如上命令是指搜集zdebug中相关模块中所处理流量被drop掉的部分，保存为var/tmp目录的drop.txt文件。

注：防火墙开启Debug一定程度上会造成CPU的升高，但绝大部分情况下不会影响太大。注意不要长期在防火墙上开启DEBUG，关闭使用Ctrl+c按键结束。

所有信息搜集齐全后，打包交给Check Point TAC工程师进行分析排错。

Power-1与UTM-1平台信息搜集:

如无法快速判断故障问题，请抓取最基本数据：注意需要收集两台设备信息

如无法通过SSH登录设备，请用原装console线登录设备命令行收集，所有会话需要记录到文件。

从SmartView Tracker中收集故障信息

与IPSO系统过程一样

搜集系统cpinfo文件

Cpinfo是SecurePlatform(SPLAT)的配置文件、系统日志以及设备当前运行状态的

[R71-FWA]# expert #登入专家模式

Enter expert password:

[Expert@R71-FWA]# cpinfo -n -z -o /var/tmp/FWA.cpinfo #执行命令导出cpinfo 然后使用FTP工具将文件传出去供Check Point技术工程师分析。

搜集fw monitor信息

搜集fw monitor命令过程与上文IPSO系统过程一样。

搜集tcpdu mp抓包信息

搜集tcpdump命令与上文IPSO系统过程一样。

搜集防火墙kernel层debug信息

搜集debug信息与上文IPSO系统过程一样

SPLAT平台可以使用如下命令，将收集到/var/tmp目录的文件打包后通过ftp传出来;

[Expert@R71-FWA]# tar -cvf info.tar /var/tmp

如上信息收集完成后，将文件打包，上传到TAC ftp服务器。

C:请将相关信息提交给Check Point支持人员。

3.3．防火墙三级故障处理：

A:故障定义：

只对最终客户造成有限影响的网络事件；

?测试或试运行环境中发现的问题，通常会对运营网络造成负面影响；

?有现成的成功临时变通方法，可以用来解决优先级较高的问题

如：某应用无法访问到目标服务器

B: 单业务访问问题信息内容收集

基本信息：

从SmartView Tracker中收集故障信息

搜集报错日志过程与上文过程一样。

搜集系统cpinfo文件（IPSO平台）

搜集命令过程与上文过程一样。

搜集系统cpinfo文件（SPLAT平台）

搜集命令过程与上文过程一样。

搜集fw monitor信息

搜集命令过程与上文过程一样。

搜集tcpdu mp抓包信息

搜集命令过程与上文过程一样。

搜集防火墙kernel层debug信息

搜集命令过程与上文过程一样。

注：防火墙开启Debug一定程度上会造成CPU的升高，但绝大部分情况下不会影响太大。注意不要长期在防火墙上开启DEBUG，关闭使用Ctrl+c按键结束。

如上信息收集完成后，将文件打包，上传到TAC ftp服务器，交给Check Point TAC工程师进行分析排错。

C:请将相关信息提交给Check Point支持人员。

3.4．防火墙四级故障处理：

信息请求；

?有关设备配置或功能的标准问题。

请将相关需求信息邮件提交给Check Point维护人员。

3.5．防火墙路由故障处理：

A:故障定义：

路由无法学到，对最终客户造成影响的网络事件；

测试或试运行环境中发现路由的问题，通常会导致业务访问故障；

如：防火墙动态路由无法学到

B: 路由问题信息收集

从SmartView Tracker中过滤关于OSPF故障信息

打开SmartDashboard→选择SmartView Tracker然后过滤出OSPF协议，双击存在问题的日志记录，将日志信息截图保存下来。

从SPLAT系统平台收集故障信息

在故障发生期间，登录SPLAT系统命令行，进入/var/log目录搜集routing_messages文件。

[Expert@R71-FWA]# router #进入router模式，show出相关信息

localhost>en

localhost#show

access-list interface ipv6 log running-config version

history ip kernel memory task

localhost#show running-config

localhost#show ip ospf neighbors

从IPSO系统管理界面收集故障信息

在故障发生期间，登录IPSO系统管理Voyager界面, 选择 'Configuration > Routing >

Routing Options'. 在OSPF下拉表中，选择 "All"并且点击"Apply".将会在/var/log目录下生成 ipsrd.log.*的文件，搜集所有 ipsrd.log.*的文件搜集系统cpinfo文件（IPSO平台）

搜集fw monitor信息

[admin]#fw monitor -e 'accept ip_p=89;'

[admin]#fw monitor -e "host=x.x.x.x and dst=x.x.x.x and dport=21 ,accept;"

搜集tcpdu mp抓包信息

[admin]# tcpdump -i eth-s3p1 -s 0 -w dump.dat ip proto ospf

搜集IPSO系统OSPF相关信息

nokia[admin]# iclid

IPSO-A> show version

IPSO-A> show ospf database database-summary

IPSO-A> show ospf neighbors

IPSO-A> show ospf interfaces

IPSO-A> show ospf errors brief

IPSO-A> show ospf events

IPSO-A> show ospf packets

IPSO-A> show ospf

C:请将相关需求信息邮件提交给Check Point维护人员。

4故障现象检查

首先发生故障后，首先从现象上要检查如下几方面：

网关连通性：受影响范围的终端PC上进行Ping测试，确定直连网关是否可达，同时可以关联性地检查本地的ARP信息是否与网关对应，同时确定不同VLAN的终端现象是否相同。相关命令：ping x.x.x.x 及 arp –a（显示ARP列表）

防火墙连通性：受影响范围的终端PC上进行Ping测试，确定访问的到防火墙的网络连通性，可以测试到客户端同侧防火墙接口以及跨防火墙安全区接口，简单确定防火墙是否处理数据情况，同时确定不同VLAN的终端现象是否相同。相关命令：ping x.x.x.x 。

业务连通性：受影响范围的终端PC上进行针对业务IP的Ping测试和正常业务访问测试，简单从业务的网络层面和应用层面确定业务是否正常。

路由路径：受影响范围的终端PC上进行针对业务IP进行路径测试，测试出现中断的路由节点，相关命令：tracert –d x.x.x.x .

4.1问题节点确认

问题与火墙无关，则跳过下面章节，问题与火墙有关，则进入如下章节进行分析。

4.1.1防火墙硬件问题

发现问题与防火墙相关联后，首先确认设备硬件是否运行正常，通常需要到设备所处的物理