分析Firepower防火墙捕获以排除网络故障

下载选项

PDF (18.1 MB)
在各种设备上使用 Adobe Reader 查看

已更新: 2024 年 7 月 31 日

文档 ID:215092

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

简介

本文档介绍旨在有效排查网络问题的各种数据包捕获分析技术。

先决条件

要求

Cisco 建议您了解以下主题：

Firepower平台架构
NGFW日志
NGFW packet-tracer

此外，在开始分析数据包捕获之前，强烈建议满足以下要求：

了解协议操作- 如果您不了解捕获的协议如何运行，请勿开始检查数据包捕获。
了解拓扑 -您必须了解端到端的传输设备。如果无法做到这一点，您必须至少了解上游和下游设备。
了解设备- 您必须了解设备如何处理数据包、涉及的接口（入口/出口）、设备架构是什么，以及各个捕获点是什么。
了解配置- 您必须了解数据包流应该如何由设备在以下方面处理：
- 路由/出口接口
- 应用的策略
- 网络地址转换 (NAT)
了解可用工具- 除了捕获之外，建议准备好应用其他工具和技术（例如日志记录和跟踪程序），如果需要，请将其与捕获的数据包相关联。

使用的组件

本文档中的信息基于以下软件和硬件版本：

大多数场景基于运行FTD软件6.5.x的FP4140。
FMC运行软件6.5.x。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

数据包捕获是当今最容易被忽视的故障排除工具之一。每天，Cisco TAC都可以通过分析捕获的数据来解决许多问题。

本文档的目标是帮助网络和安全工程师主要根据数据包捕获分析来识别和排除常见网络问题。

本文档中介绍的所有场景均基于思科技术支持中心(TAC)中看到的实际用户案例。

本文档从思科下一代防火墙(NGFW)的角度介绍了数据包捕获，但相同的概念也适用于其他设备类型。

如何收集和导出NGFW产品系列的捕获信息？

对于Firepower设备(1xxx、21xx、41xx、93xx)和Firepower威胁防御(FTD)应用，数据包处理可视化，如图所示。

数据路径

数据包进入入口接口，由机箱内部交换机处理。
数据包进入FTD Lina引擎，该引擎主要执行L3/L4检查。
如果策略要求数据包由Snort引擎进行检查（主要是L7检查）。
Snort引擎返回数据包的判定。
LINA 引擎根据 Snort 的判定丢弃或转发数据包.
数据包通过内部机箱交换机离开机箱。

根据所示架构，FTD捕获可在三(3)个不同位置进行：

FXOS
FTD Lina引擎
FTD Snort引擎

收集FXOS捕获

本文档介绍了该过程：

https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/fxos271/web-guide/b_GUI_FXOS_ConfigGuide_271/troubleshooting.html#concept_E8823CC63C934A909BBC0DF12F301DED

FXOS捕获只能从内部交换机的入口方向获取，如下图所示。

数据路径

此处显示，由于内部交换机架构的原因，每个方向有两个捕获点。

数据路径

在点2、3和4中捕获的数据包具有虚拟网络标记(VNTag)。

注意：FXOS机箱级别捕获仅在FP41xx和FP93xx平台上可用。FP1xxx和FP21xx不提供此功能。

启用并收集FTD Lina捕获

主要捕获点：

Ingress 接口
Egress 接口
加速安全路径(ASP)

数据路径

您可以使用Firepower管理中心用户界面(FMC UI)或FTD CLI启用和收集FTD Lina捕获。

在内部接口上从CLI启用捕获：

firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1

此捕获在两个方向上匹配IP 192.168.103.1和192.168.101.1之间的流量。

启用ASP捕获以查看FTD Lina引擎丢弃的所有数据包：

firepower# capture ASP type asp-drop all

将FTD Lina捕获导出到FTP服务器：

firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap

将FTD Lina捕获导出到TFTP服务器：

firepower# copy /pcap capture:CAPI tftp://192.168.78.73

从FMC 6.2.x版本开始，您可以从FMC UI启用并收集FTD Lina捕获。

从FMC管理的防火墙收集FTD捕获的另一种方法是。

第 1 步

对于LINA或ASP捕获，请将捕获复制到FTD磁盘。

firepower# copy /pcap capture:capin disk0:capin.pcap

Source capture name [capin]?

Destination filename [capin.pcap]?
!!!!

步骤 2

导航到专家模式，找到保存的捕获，然后将其复制到/ngfw/var/common位置：

firepower#

Console connection detached.

> expert
admin@firepower:~$ sudo su
Password:
root@firepower:/home/admin# cd /mnt/disk0
root@firepower:/mnt/disk0# ls -al | grep pcap
-rwxr-xr-x 1 root root     24 Apr 26 18:19 CAPI.pcap
-rwxr-xr-x 1 root root  30110 Apr  8 14:10 capin.pcap
-rwxr-xr-x 1 root root   6123 Apr  8 14:11 capin2.pcap
root@firepower:/mnt/disk0# cp capin.pcap /ngfw/var/common

步骤 3

登录到管理FTD的FMC并导航到设备>设备管理。找到FTD设备并选择故障排除图标：

copy_pcap0

步骤 4

选择高级故障排除：

copy_pcap1

指定捕获文件名并选择Download：
copy_pcap2

有关如何启用/收集FMC UI捕获的更多示例，请阅读本文档：

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

启用和收集FTD Snort捕获

捕获点显示在此处的图像中。

数据路径

启用Snort级捕获：

> capture-traffic

Please choose domain to capture traffic from:
  0 - br1
  1 - Router

Selection? 1

Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n host 192.168.101.1

要将捕获写入名称为capture.pcap的文件并通过FTP将其复制到远程服务器，请执行以下操作：

> capture-traffic

Please choose domain to capture traffic from:
  0 - br1
  1 - Router

Selection? 1

Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -w capture.pcap host 192.168.101.1
CTRL + C <- to stop the capture

> file copy 10.229.22.136 ftp / capture.pcap
Enter password for ftp@10.229.22.136:
Copying capture.pcap
Copy successful.

>

有关包含不同捕获过滤器的更多Snort级捕获示例，请查看以下文档：

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

故障排除

例 1.出口接口没有TCP SYN

拓扑如图所示：

网络拓扑

问题说明：HTTP不起作用

受影响的流：

源IP：192.168.0.100

DST IP：10.10.1.100

协议：TCP 80

捕获分析

在FTD LINA引擎上启用捕获：

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100
firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

网络拓扑

捕获-功能场景：

作为基准，从功能场景获取捕获信息始终非常有用。

捕获在NGFW内部接口上获取，如图所示：

CAPI输出

要点:

TCP三次握手。
双向数据交换。
数据包之间无延迟（基于数据包之间的时间差）。
源MAC是正确的下游设备。

在NGFW外部接口上捕获的流量如下图所示：

CAPI输出

要点:

与CAPI捕获中的数据相同。
目的MAC是正确的上游设备。

捕获-非功能场景

从设备CLI捕获结果如下所示：

firepower# show capture
capture CAPI type raw-data interface INSIDE [Capturing - 484 bytes]
  match ip host 192.168.0.100 host 10.10.1.100
capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes]
  match ip host 192.168.0.100 host 10.10.1.100

CAPI内容：

firepower# show capture CAPI

6 packets captured

   1: 11:47:46.911482   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   2: 11:47:47.161902   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   3: 11:47:49.907683   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   4: 11:47:50.162757   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   5: 11:47:55.914640   192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,nop,sackOK>
   6: 11:47:56.164710   192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,nop,sackOK>

firepower# show capture CAPO

0 packet captured

0 packet shown

这是CAPI捕获在Wireshark中的图像：

CAPI输出

要点:

只看到TCP SYN数据包（无TCP三次握手）。
无法建立2个TCP会话（源端口3171和3172）。源客户端重新发送TCP SYN数据包。这些重新传输的数据包由Wireshark标识为TCP重新传输。
TCP重新传输每―3到6秒进行一次。
源MAC地址来自正确的下游设备。

根据这2条捕获信息，可以得出以下结论：

特定5元组（src/dst IP、src/dst port、协议）的数据包到达预期接口(INSIDE)上的防火墙。
数据包不会离开预期接口（外部）上的防火墙。

可能的原因和建议的操作摘要

如果仅在入口接口上看到TCP SYN数据包，但未从预期出口接口发送任何TCP SYN数据包，则可能的原因包括：

可能的原因	推荐的操作
防火墙访问策略会丢弃数据包。	使用packet-tracer或capture w/trace查看防火墙如何处理数据包。检查防火墙日志。检查防火墙ASP丢弃(show asp drop或捕获类型asp-drop)。检查FMC连接事件。这假设规则已启用日志记录。
捕获过滤器错误。	使用packet-tracer或capture w/trace查看是否存在可修改源IP或目标IP的NAT转换。在这种情况下，请调整捕获过滤器。 show conn long 命令输出显示NATed IP。
将数据包发送到其他出口接口。	使用packet-tracer或capture w/trace查看防火墙如何处理数据包。请记住有关出口接口确定、当前连接、UN-NAT、PBR和路由表查找的操作顺序。检查防火墙日志。检查防火墙连接表(show conn)。如果由于数据包与当前连接匹配而发送到错误的接口，则使用clear conn address 命令并指定要清除的连接的5元组。
没有通往目的地的路由。	使用packet-tracer或capture w/trace查看防火墙如何处理数据包。检查防火墙ASP丢弃(show asp drop)以了解无路由丢弃的原因。
出口接口上没有ARP条目。	检查防火墙ARP缓存(show arp)。使用Packet-tracer查看是否存在有效的邻接关系。
出口接口关闭。	检查防火墙上show interface ip brief命令的输出，并验证接口状态。

案例 2.来自客户端的TCP SYN、来自服务器的TCP RST

下图显示拓扑：

网络拓扑

问题说明：HTTP不起作用

受影响的流：

源IP：192.168.0.100

DST IP：10.10.1.100

协议：TCP 80

捕获分析

在FTD LINA引擎上启用捕获。

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100
firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

网络拓扑

捕获-非功能场景：

以下是设备CLI中的捕获结果：

firepower# show capture
capture CAPI type raw-data trace interface INSIDE [Capturing - 834 bytes]
  match ip host 192.168.0.100 host 10.10.1.100
capture CAPO type raw-data interface OUTSIDE [Capturing - 878 bytes]
  match ip host 192.168.0.100 host 10.10.1.100

CAPI内容：

firepower# show capture CAPI
   1: 05:20:36.654217   192.168.0.100.22195 > 10.10.1.100.80: S 1397289928:1397289928(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   2: 05:20:36.904311   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   3: 05:20:36.905043   10.10.1.100.80 > 192.168.0.100.22196: R 1850052503:1850052503(0) ack 2171673259 win 0
   4: 05:20:37.414132   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   5: 05:20:37.414803   10.10.1.100.80 > 192.168.0.100.22196: R 31997177:31997177(0) ack 2171673259 win 0
   6: 05:20:37.914183   192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,nop,sackOK>
...

CAPO内容：

firepower# show capture CAPO
   1: 05:20:36.654507   802.1Q vlan#202 P0 192.168.0.100.22195 > 10.10.1.100.80: S 2866789268:2866789268(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   2: 05:20:36.904478   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4785344:4785344(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   3: 05:20:36.904997   802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4785345 win 0
   4: 05:20:37.414269   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4235354730:4235354730(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   5: 05:20:37.414758   802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4235354731 win 0
   6: 05:20:37.914305   802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4118617832:4118617832(0) win 8192 <mss 1380,nop,nop,sackOK>

下图显示了Wireshark中的CAPI捕获。

CAPI输出

要点:

源设备发送TCP SYN数据包。
向源设备发送TCP RST。
源设备重新传输TCP SYN数据包。
MAC地址正确（在入口数据包上，源MAC地址属于下游路由器，目标MAC地址属于防火墙内部接口）。

下图显示Wireshark中的CAPO捕获：

CAPI输出

要点:

源设备发送TCP SYN数据包。
TCP RST到达外部接口。
源设备重新传输TCP SYN数据包。
MAC地址正确（在出口数据包上，防火墙OUTSIDE是源MAC，上游路由器是目标MAC）。

根据这2条捕获信息，可以得出以下结论：

客户端和服务器之间的TCP三次握手没有完成
有一个到达防火墙出口接口的TCP RST
防火墙与适当的上游和下游设备“通信”（基于MAC地址）

案例 3.来自一个终端的TCP三次握手+ RST

下图显示拓扑：

网络拓扑

问题说明：HTTP不起作用

受影响的流：

源IP：192.168.0.100

DST IP：10.10.1.100

协议：TCP 80

捕获分析

在FTD LINA引擎上启用捕获。

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100
firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

网络拓扑

捕获-非功能场景：

此问题在捕获中可能表现为几种不同的方式。

3.1 -来自客户端的TCP三次握手+延迟RST

如图所示，防火墙捕获CAPI和CAPO包含相同的数据包。

CAPI输出

要点:

TCP三次握手会通过防火墙。
服务器重新传输SYN/ACK。
客户端重新传输ACK。
大约20秒后，客户端放弃并发送TCP RST。

3.2 - TCP三次握手+来自客户端的延迟FIN/ACK +来自服务器的延迟RST

如图所示，防火墙捕获CAPI和CAPO包含相同的数据包。

CAPI GUI

要点:

TCP三次握手会通过防火墙。
约5秒后，客户端发送FIN/ACK。
大约20秒后，服务器会放弃并发送TCP RST。

根据捕获结果，可以断定，虽然存在通过防火墙的TCP三次握手，但似乎在一个终端上从未真正完成握手（重新传输表明此情况）。

3.3 -来自客户端的TCP三次握手+延迟RST

如图所示，防火墙捕获CAPI和CAPO包含相同的数据包。

CAPI GUI

要点:

TCP三次握手会通过防火墙。
大约20秒后，客户端放弃并发送TCP RST。

根据这些捕获信息，可以得出以下结论：

5-20秒后，一个终端放弃并决定终止连接。

3.4 -来自服务器的TCP三次握手+即时RST

如图所示，防火墙捕获CAPI和CAPO都包含这些数据包。

CAPI GUI

要点:

TCP三次握手会通过防火墙。
在ACK数据包过几毫秒后，服务器会发出一个TCP RST。

案例 4.来自客户端的TCP RST

下图显示拓扑：

网络拓扑

问题说明：HTTP不起作用。

受影响的流：

源IP：192.168.0.100

DST IP：10.10.1.100

协议：TCP 80

捕获分析

在FTD LINA引擎上启用捕获。

firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100
firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100

网络拓扑

捕获-非功能场景：

以下是CAPI内容。

firepower# show capture CAPI

14 packets captured

   1: 12:32:22.860627   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   2: 12:32:23.111307   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   3: 12:32:23.112390   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0
   4: 12:32:25.858109   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   5: 12:32:25.868698   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0
   6: 12:32:26.108118   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
   7: 12:32:26.109079   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0
   8: 12:32:26.118295   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0
   9: 12:32:31.859925   192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,nop,sackOK>
  10: 12:32:31.860902   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0
  11: 12:32:31.875229   192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0
  12: 12:32:32.140632   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0
  13: 12:32:32.159995   192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,nop,sackOK>
  14: 12:32:32.160956   192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0
14 packets shown

以下是CAPO内容：

firepower# show capture CAPO

11 packets captured

   1: 12:32:22.860780   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   2: 12:32:23.111429   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3000518857:3000518857(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   3: 12:32:23.112405   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 3514091874:3514091874(0) win 0
   4: 12:32:25.858125   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   5: 12:32:25.868729   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 2968892337:2968892337(0) win 0
   6: 12:32:26.108240   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3822259745:3822259745(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK>
   7: 12:32:26.109094   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 40865466:40865466(0) win 0
   8: 12:32:31.860062   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 4294058752:4294058752(0) win 8192 <mss 1380,nop,nop,sackOK>
   9: 12:32:31.860917   802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 1581733941:1581733941(0) win 0
  10: 12:32:32.160102   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 4284301197:4284301197(0) win 8192 <mss 1380,nop,nop,sackOK>
  11: 12:32:32.160971   802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 502906918:502906918(0) win 0
11 packets shown

防火墙日志显示：

firepower# show log | i 47741
Oct 13 2019 13:57:36: %FTD-6-302013: Built inbound TCP connection 4869 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)
Oct 13 2019 13:57:36: %FTD-6-302014: Teardown TCP connection 4869 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE
Oct 13 2019 13:57:39: %FTD-6-302013: Built inbound TCP connection 4870 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)
Oct 13 2019 13:57:39: %FTD-6-302014: Teardown TCP connection 4870 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE
Oct 13 2019 13:57:45: %FTD-6-302013: Built inbound TCP connection 4871 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80)
Oct 13 2019 13:57:45: %FTD-6-302014: Teardown TCP connection 4871 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE

这些日志表明有一个到达防火墙INSIDE接口的TCP RST

Wireshark中的CAPI捕获：

第一个TCP数据流之后，如图所示。

CAPI GUI

在Wireshark下，导航到编辑>首选项>协议> TCP ，取消选择相对序列号选项（如图所示）。

CAPI GUI

下图显示CAPI捕获中的第一个流的内容：

CAPI GUI

要点:

客户端发送TCP SYN数据包。
客户端发送TCP RST数据包。
TCP SYN数据包的序列号值等于4098574664。

CAPO捕获中的同一流包含：

CAPI GUI

要点:

客户端发送TCP SYN数据包。防火墙随机分配ISN。
客户端发送TCP RST数据包。

根据这两个捕获结果，可以得出以下结论：

客户端和服务器之间没有TCP三次握手。
有一个来自客户端的TCP RST。CAPI捕获中的TCP RST序列号值为1386249853。

案例 5.缓慢TCP传输（场景1）

问题说明:

主机10.11.4.171和主机10.77.19.11之间的SFTP传输缓慢。虽然两台主机之间的最小带宽(BW)为100 Mbps，但传输速度不超过5 Mbps。

同时，主机10.11.2.124和172.25.18.134之间的传输速度要快得多。

背景理论:

单个TCP流的最大传输速度由带宽延迟积(BDP)决定。图中显示所使用的公式：

数据流量

有关BDP的更多详细信息，请点击此处查看资源：

为什么即使链路为1Gbps，您的应用程序也只使用10Mbps？
BRKSEC-3021 -高级-最大化防火墙性能

场景 1.缓慢传输

下图显示拓扑：

网络拓扑

受影响的流：

源IP：10.11.4.171

DST IP：10.77.19.11

协议：SFTP(FTP over SSH)

捕获分析

在FTD LINA引擎上启用捕获：

firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11
firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11

警告：FP1xxx和FP21xx捕获上的LINA影响通过FTD的数据流的传输速率。排除性能（通过FTD传输缓慢）故障时，请勿在FP1xxx和FP21xxx平台上启用LINA捕获。除了在源主机和目的主机上捕获数据外，还应使用SPAN或HW分路器设备。思科漏洞ID CSCvo30697中记录了此问题。

firepower# capture CAPI type raw-data trace interface inside match icmp any any
WARNING: Running packet capture can have an adverse impact on performance.

场景 2：快速传输

现在，让我们来看看好方案（通过同一网络快速传输）：

拓扑：

网络拓扑

利益流向：

源IP：10.11.2.124

DST IP：172.25.18.134

协议：SFTP(FTP over SSH)

在FTD LINA引擎上启用捕获

firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134
firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134

往返时间(RTT)计算：在这种情况下，RTT≈300毫秒。

CLI输出

TCP窗口大小计算：服务器通告TCP窗口缩放系数7。

CLI输出

服务器的TCP窗口大小为≈ 1600000字节：

CLI输出

根据这些值，带宽延迟乘积公式可得出：

1600000*8/0.3 = 43 Mbps最大理论传输速度

案例 6.缓慢TCP传输（场景2）

问题描述：通过防火墙的FTP文件传输（下载）速度缓慢。

下图显示拓扑：

网络拓扑

受影响的流：

源IP：192.168.2.220

DST IP：192.168.1.220

协议：FTP

捕获分析

在FTD LINA引擎上启用捕获。

firepower# capture CAPI type raw-data buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220
firepower# cap CAPO type raw-data buffer 33554432 interface OUTSIDE match tcp host 192.168.2.220 host 192.168.1.220

选择FTP-DATA数据包，然后按照FTD内部捕获(CAPI)的FTP数据信道操作：

CLI输出

FTP-DATA流内容：

CLI输出

CAPO捕获内容：

CLI输出

要点:

存在TCP乱序(OOO)数据包。
存在TCP重新传输。
存在数据包丢失（丢弃的数据包）的指示。

提示：导航到File > Export Specified Packets时保存捕获。然后仅保存显示的数据包范围

CAPI GUI

导出捕获检查入口数据包与出口数据包之间的时间差异

案例 7.TCP连接问题（数据包损坏）

问题说明:

无线客户端(192.168.21.193)尝试连接到目标服务器(192.168.14.250 - HTTP)，但有2种不同的场景：

当客户端连接到接入点(AP)“A”时，HTTP连接不起作用。
当客户端连接到接入点(AP)“B”时，HTTP连接会正常工作。

下图显示拓扑：

网络拓扑

受影响的流：

源IP：192.168.21.193

DST IP：192.168.14.250

协议：TCP 80

捕获分析

在FTD LINA引擎上启用捕获：

firepower# capture CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250
firepower# capture CAPO int OUTSIDE match ip host 192.168.21.193 host 192.168.14.250

捕获-功能场景：

作为基准，使用已知良好场景中的捕获信息总是非常有用。

下图显示了在NGFW内部接口上捕获的流量

CLI输出

下图显示了在NGFW外部接口上捕获的流量。

CLI输出

要点:

2个捕获几乎相同（考虑ISN随机化）。
没有数据包丢失的迹象。
无乱序(OOO)数据包
有3个HTTP GET请求。第一个收到404“Not Found”，第二个收到200“OK”，第三个收到304“Not Modified”重定向消息。

捕获-已知故障场景：

入口捕获(CAPI)内容。

CLI输出

要点:

存在TCP三次握手。
有TCP重新传输和数据包丢失指示。
Wireshark发现一个数据包(TCP ACK)存在格式错误。

下图显示了出口捕获(CAPO)内容。

CLI输出

要点:

2个捕获几乎相同（考虑ISN随机化）：

存在TCP三次握手。
有TCP重新传输和数据包丢失指示。
Wireshark发现一个数据包(TCP ACK)存在格式错误。

检查格式错误的数据包：

CLI输出

要点:

数据包被识别为Wireshark的格式错误。
长度为2个字节。
有2个字节的TCP负载。
负载是4个额外的零(00 00)。

案例 8.UDP连接问题（缺少数据包）

问题说明：在目标Syslog服务器上看不到Syslog (UDP 514)消息。

下图显示拓扑：

网络拓扑

受影响的流：

源IP：192.168.1.81

DST IP：10.10.1.73

协议：UDP 514

捕获分析

在FTD LINA引擎上启用捕获：

firepower# capture CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514
firepower# capture CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514

FTD捕获显示无数据包：

firepower# show capture
capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes]
  match udp host 192.168.1.81 host 10.10.1.73 eq syslog
capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes]
  match udp host 192.168.1.81 host 10.10.1.73 eq syslog

捕获分析

在FTD LINA引擎上启用捕获：

由于端口地址转换配置，OUTSIDE捕获中使用的IP不同。

firepower# capture CAPI int INSIDE match ip host 192.168.201.111 host 192.168.202.111
firepower# capture CAPO int OUTSIDE match ip host 192.168.202.11 host 192.168.202.111

下图显示了在NGFW内部接口上捕获的流量：

CLI输出

要点:

存在TCP三次握手。
SSL协商开始。客户端发送Client Hello消息。
向客户端发送了TCP ACK。
有一个发送到客户端的TCP RST。

下图显示了在NGFW外部接口上捕获的流量。

CLI输出

要点:

存在TCP三次握手。
SSL协商开始。客户端发送Client Hello消息。
防火墙会向服务器发送TCP重新传输。
有一个发送到服务器的TCP RST。

案例 10.HTTPS连接问题（场景2）

问题说明：FMC智能许可证注册失败。

GUI

下图显示拓扑：

网络拓扑

受影响的流：

源IP：192.168.0.100

Dst：tools.cisco.com

协议：TCP 443 (HTTPS)

捕获分析

在FMC管理接口上启用捕获：

网络拓扑

尝试重新注册。出现错误消息后，按CTRL-C停止捕获：

root@firepower:/Volume/home/admin# tcpdump -i eth0 port 443 -s 0 -w CAP.pcap
HS_PACKET_BUFFER_SIZE is set to 4.
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C264 packets captured				<- CTRL-C
264 packets received by filter
0 packets dropped by kernel
root@firepower:/Volume/home/admin#

从FMC收集捕获(System > Health > Monitor，选择设备并选择Advanced Troubleshooting)，如图所示：

GUI

下图显示了Wireshark上的FMC捕获：

CLI输出

提示：要检查捕获的所有新TCP会话，请在Wireshark上使用tcp.flags==0x2显示过滤器。这将过滤捕获的所有TCP SYN数据包。

CLI输出

提示：将SSL客户端Hello中的Server Name字段应用为列。

CLI输出

提示：应用此显示过滤器以仅查看客户端Hello消息ssl.handshake.type == 1

CLI输出

注意：在撰写本文时，智能许可门户(tools.cisco.com)使用以下IP：72.163.4.38、173.37.145.8

按照其中一个TCP流操作(Follow > TCP Stream)，如图所示。

CLI输出

要点:

存在TCP三次握手。
客户端(FMC)向智能许可门户发送SSL客户端Hello消息。
SSL会话ID为0。这意味着它不是续会。
目标服务器回复服务器Hello、证书和服务器Hello完成消息。
客户端发送有关“Unknown CA”的SSL严重警报。
客户端发送TCP RST以关闭会话。
整个TCP会话持续时间（从建立到关闭）约为0.5秒。

选择Server Certificate，然后展开issuer字段以查看commonName。在本例中，公用名显示执行中间人(MITM)的设备。

CLI输出

如下图所示：

网络拓扑

捕获分析

在FTD LINA引擎上启用捕获。

firepower# capture CAPI int INSIDE match ip any6 any6
firepower# capture CAPO int OUTSIDE match ip any6 any6

网络拓扑

捕获-非功能场景

这些捕获与从IP fc00:1：1:1：：100（内部路由器）到IP fc00:1：1:2：：2（上游路由器）的ICMP连接测试并行执行。

防火墙INSIDE接口上的捕获包含：

CLI输出

要点:

路由器发送IPv6邻居请求消息并请求上游设备的MAC地址(IP fc00:1：1:1：：1)。
防火墙以IPv6邻居通告作为回应。
路由器发送ICMP回应请求。
防火墙发送IPv6邻居请求消息并请求下游设备的MAC地址(fc00:1：1:1：：100)。
路由器会以IPv6邻居通告做出响应。
路由器发送额外的IPv6 ICMP回应请求。

防火墙OUTSIDE接口上的捕获包含：

CLI输出

要点:

防火墙发送IPv6邻居请求消息，请求上游设备的MAC地址(IP fc00:1：1:2：：2)。
路由器会以IPv6邻居通告做出响应。
防火墙发送IPv6 ICMP回应请求。
上游设备（路由器fc00:1：1:2：：2）发送IPv6邻居请求消息，该消息请求IPv6地址fc00:1：1:1：：100的MAC地址。
防火墙发送额外的IPv6 ICMP回应请求。
上游路由器发送另一个IPv6邻居请求消息，要求获取IPv6地址fc00:1：1:1：：100的MAC地址。

第四点很有意思。通常，上游路由器会要求防火墙OUTSIDE接口(fc00:1：1:2：：2)的MAC地址，但实际上它要求的是fc00:1：1:1：：100。这表示配置错误。

案例 12.间歇性连接问题（ARP毒化）

问题描述：内部主机(192.168.0.x/24)与同一子网中的主机存在间歇性连接问题

下图显示拓扑：

网络拓扑

受影响的流：

源IP：192.168.0.x/24

目标IP：192.168.0.x/24

协议：任意

内部主机的ARP缓存似乎已中毒：

CLI输出

捕获分析

在FTD LINA引擎上启用捕获

此捕获仅捕获内部接口上的ARP数据包：

firepower# capture CAPI_ARP interface INSIDE ethernet-type arp

网络拓扑

捕获-非功能场景：

防火墙INSIDE接口上的捕获包含。

CLI输出

要点:

防火墙接收192.168.0.x/24网络内IP的各种ARP请求
防火墙使用自己的MAC地址对所有设备（代理ARP）做出应答

案例 13.标识导致CPU占用的SNMP对象标识符(OID)

本例演示了如何根据SNMP版本3 (SNMPv3)数据包捕获的分析，将内存轮询的某些SNMP OID标识为CPU大量占用（性能问题）的根本原因。

问题描述：数据接口上的超限持续增加。进一步的研究表明，还有CPU大量占用（由SNMP进程引起）是接口超负荷运行的根本原因。

故障排除过程中的下一步是确定由SNMP进程导致的CPU大量占用的根本原因，特别是缩小问题的范围，以确定SNMP对象标识符(OID)，在轮询时，OID可能会导致CPU大量占用。

目前，FTD LINA引擎不为实时轮询的SNMP OID提供“show”命令。

用于轮询的SNMP OID列表可以从SNMP监控工具中检索，但是，在这种情况下，存在以下预防因素：

FTD管理员没有访问SNMP监控工具的权限
在FTD上配置了具有身份验证和数据加密的SNMP第3版

捕获分析

由于FTD管理员拥有SNMP第3版身份验证和数据加密的凭证，因此建议以下行动计划：

获取SNMP数据包捕获
保存捕获并使用Wireshark SNMP协议首选项指定SNMP第3版凭证以解密SNMP第3版数据包。解密的捕获用于分析和检索SNMP OID

在用于snmp-server host配置的接口上配置SNMP数据包捕获：

firepower# show run snmp-server  | include host
snmp-server host management 192.168.10.10 version 3 netmonv3


firepower# show ip address management
System IP Address:
Interface                Name                   IP address      Subnet mask     Method
Management0/0            management             192.168.5.254   255.255.255.0   CONFIG
Current IP Address:
Interface                Name                   IP address      Subnet mask     Method
Management0/0            management             192.168.5.254   255.255.255.0   CONFIG

firepower# capture capsnmp interface management buffer 10000000 match udp host 192.168.10.10  host 192.168.5.254 eq snmp

firepower# show capture capsnmp

capture capsnmp type raw-data buffer 10000000 interface outside [Capturing - 9512 bytes]
  match udp host 192.168.10.10  host 192.168.5.254 eq snmp

snmpv3_authpriv

关键点

SNMP源地址和目的地址/端口。
无法解码SNMP协议PDU，因为Wireshark不知道privKey。
encryptedPDU基元的值。

版本	发布日期	备注
3.0	31-Jul-2024	重新认证、Alt Text、固定标题、标点符号和html SEO优化。
2.0	02-Jun-2023	重新认证
1.0	21-Nov-2019	初始版本

分析Firepower防火墙捕获以排除网络故障

下载选项

非歧视性语言

关于此翻译

目录

简介

先决条件

要求

使用的组件

背景信息

如何收集和导出NGFW产品系列的捕获信息？

收集FXOS捕获

启用并收集FTD Lina捕获

启用和收集FTD Snort捕获

故障排除

例 1.出口接口没有TCP SYN

捕获分析

推荐的操作

可能的原因和建议的操作摘要

案例 2.来自客户端的TCP SYN、来自服务器的TCP RST

捕获分析

推荐的操作

案例 3.来自一个终端的TCP三次握手+ RST

捕获分析

3.1 -来自客户端的TCP三次握手+延迟RST

推荐的操作

3.2 - TCP三次握手+来自客户端的延迟FIN/ACK +来自服务器的延迟RST

推荐的操作

3.3 -来自客户端的TCP三次握手+延迟RST

推荐的操作

3.4 -来自服务器的TCP三次握手+即时RST

推荐的操作

案例 4.来自客户端的TCP RST

捕获分析

推荐的操作

案例 5.缓慢TCP传输（场景1）

场景 1.缓慢传输

捕获分析

推荐的操作

场景 2：快速传输

案例 6.缓慢TCP传输（场景2）

捕获分析

推荐的操作

导出捕获检查入口数据包与出口数据包之间的时间差异案例 7.TCP连接问题（数据包损坏）

捕获分析

推荐的操作

案例 8.UDP连接问题（缺少数据包）

捕获分析

推荐的操作

捕获分析

推荐的操作

案例 10.HTTPS连接问题（场景2）

捕获分析

推荐的操作

捕获分析

推荐的操作

案例 12.间歇性连接问题（ARP毒化）

捕获分析

推荐的操作

案例 13.标识导致CPU占用的SNMP对象标识符(OID)

捕获分析

推荐的操作

相关信息

修订历史记录

由思科工程师提供

此文档是否有帮助?

联系我们

本文档适用于以下产品

导出捕获检查入口数据包与出口数据包之间的时间差异

案例 7.TCP连接问题（数据包损坏）