面向网络专家的 Linux（四）

原文：zh.annas-archive.org/md5/A72D356176254C9EA0055EAB3A38778D

译者：飞龙

协议：CC BY-NC-SA 4.0

第十一章：Linux 中的数据包捕获和分析

在本章中，我们将讨论在 Linux 中使用数据包捕获。在许多方面，数据包是数据中心中最接近真相的东西；经常引用的谚语是数据包不会说谎。无论主机或防火墙上存在什么样的策略或复杂的配置，主机和应用程序数据包始终会反映发生的情况。这使得数据包捕获，更重要的是对这些数据包进行分析成为网络管理员工具箱中的关键问题解决和故障排除技能。

特别是，我们将涵盖以下主题：

• 数据包捕获简介-寻找正确的地方

• 在进行捕获时的性能考虑

• 捕获工具

• 过滤捕获的流量

• 解决应用程序问题-捕获 VoIP 电话呼叫

让我们开始吧！

技术要求

在本章中，我们将捕获数据包。初始设置和数据包捕获使用了一个您可能无法访问的物理交换机。不过，一旦我们开始查看数据包本身，所有捕获文件都可以下载。由于本章的大部分内容都是关于分析和解释捕获的数据包，我们现有的 Linux 主机应该可以很好地完成工作，而不需要进行过多的修改。这也是我们确保当您按照本章的示例进行操作时，您的显示与我们描述的内容匹配的好方法。

当然，您可以在实验室中构建数据包捕获，或者更好地集成到您的工作环境中。这是一个非常有价值的工具，可以用来排除故障，或者更好地了解我们每天使用的各种协议和应用程序！

本章引用的捕获文件可以在本书的 GitHub 存储库的C11文件夹中找到：github.com/PacktPublishing/Linux-for-Networking-Professionals/tree/main/C11。

数据包捕获简介-寻找正确的地方

有多种方法可以在两个主机之间拦截和捕获数据包，以及在通信路径中进行捕获的多个位置。让我们讨论一些更受欢迎的选择。

从任一端进行捕获

这绝对是最简单的选择，因为一切正常时，对话的两端主机都将接收或发送所有数据包。不过，这也有一些缺点：

• 您可能无法访问任一端。根据情况，其中一个端点主机可能根本不在您的组织中。

• 即使有，您可能无法在您的环境中对主机（或主机）进行管理访问。特别是在企业环境中，常见的情况是，网络团队和/或安全团队可能无法在服务器上进行管理访问（或任何访问）。

• 安装新的系统软件通常不是大多数组织可以随意进行的事情。大多数公司对可能影响工作站或服务器操作的任何事物都需要严格的变更控制程序。

• 即使安装数据包捕获应用的变更请求得到批准，像这样的奇怪应用程序在安装后可能会成为数月甚至数年的争议焦点，服务器上出现的任何奇怪情况都可能被归咎于“网络团队在服务器上安装的那个奇怪的应用程序”。

• 如果您正在解决问题，您可能无法从您可以访问的端点看到问题。例如，如果一些或所有数据包未到达服务器（或客户端），那么在问题站点进行捕获可能无法帮助您解决问题-除了确认这些数据包未到达之外。

因此，通常更倾向于在路径的某个中间点捕获数据包。一个受欢迎的选择是配置交换机端口来镜像或监视流量。

切换监控端口

常见情况是，我们需要捕获发送到或从主机的数据包，但我们无法访问任何主机，无法中断服务，或无法获得安装数据包捕获软件所需的权限。由于这些情况非常普遍，交换机供应商已经实施了一些功能来帮助我们。大多数交换机都有将流量镜像或监视到或从端口的功能。这通常被称为交换端口分析器（SPAN）配置。从交换机上，我们只需配置要监视的端口，我们是要发送（Tx）、接收（Rx）还是双向流量，以及我们要将数据发送到哪个端口。

例如，在思科交换机上，在这种配置中，我们正在监视GigabitEthernet 1/0/1端口（发送和接收），我们的数据包捕获主机位于GigabitEthernet 1/0/5端口上：

monitor session 1 source g1/0/1 both
monitor session 1 destination g1/0/5

正如您所看到的，这些都是为monitor session 1定义的，这意味着是的，大多数交换机将支持同时进行多个监视会话。这可以通过监视整个 VLAN（因此源可能是 VLAN 7）或将数据包捕获发送到远程目的地，称为远程交换端口分析器（RSPAN）目的地来扩展。

如果混合中有防火墙或负载均衡器，请注意您定义的源端口 - 例如，如果在 NAT 之前或之后捕获数据包，您的数据包捕获数据将有很大不同。

在哪里还可以查找特定对话中的数据包？网络设备在这里也是一个受欢迎的选择。

中间的内联主机

在这种情况下，中间主机，如路由器、交换机或防火墙，可以捕获流量。特别是防火墙非常方便，因为在许多情况下，您可以在 NAT 之前和之后捕获流量。如果您正在解决一个明确定义的问题，这种方法非常合理。但是，必须考虑以下问题：

• 网络设备通常具有有限的存储空间，因此您需要将数据包的总体量保持在捕获设备的存储容量范围内。在某些设备上，您可以实时将捕获发送到远程目的地，以解决这个问题，但这也会带来其他问题。

• 无论哪种情况，数据包速率都应该很低。在许多情况下，这些设备上的本地存储相对较慢，如果数据包速率很高，实时将数据包捕获发送到网络目的地可能会导致捕获中丢失数据包。

• 捕获数据包会对捕获设备的 CPU 产生不利影响。在考虑在此设备上增加数据包捕获负载之前，请确保您的整体 CPU 利用率较低。

• 如果您将捕获的数据包发送到远程目的地，请确保有足够的带宽来做到这一点 - 如果超出端口的带宽，您将在捕获端或发送端丢失数据包。

• 总之，在许多情况下，您正在寻找流中非常特定的数据包以排除问题，以便制作一个过滤器来仅收集该流量。

有关使用思科路由器作为数据包收集器的更完整描述，请参阅：https://isc.sans.edu/forums/diary/Using+a+Cisco+Router+as+a +Remote+Collector+for+tcpdump+or+Wireshark/7609/。

其他平台的数据包捕获设施通常非常相似 - 它们创建一个列表来定义感兴趣的流量，然后开始捕获过程。无论您的设备是什么，您的供应商都会比我们在这里提到的更全面地记录这一点。

最后，我们将看看“纯粹”的方法；也就是使用网络监听器。

网络监听器

tap 是一种硬件设备，插入到流量中，允许在任一方向或两个方向进行全面监控。因为它传统上是一个电气/硬件解决方案，所以没有关于数据包容量的争论；任何方向上的每一位都简单地被电气地复制到监听站。然而，tap 需要花钱，并且需要您在现场。您还必须断开相关的以太网电缆以将 tap 放在线。因此，tap 仍然是非常方便的，但通常不再经常使用。

Michael Ossmann 的 Typical low-end tap（10或10/100）是以太网“Throwing Star”，可以在greatscottgadgets.com/throwingstar/找到。以下图表显示了这样一个典型的低端（10/100）的 tap 是如何操作的。请注意，有两种构建 tap 的方法 - 如下图所示，您可以构建一个具有两个端口的仅监听 tap，每个端口只“监听”一个方向的流量：

图 11.1 - 两个 tap 端口，每个方向一个

您还可以使用更传统的 tap，它将在单个端口上“听到”两个方向的流量：

图 11.2 - 一个 tap 端口看到所有流量（只有引脚）

这一切都是有效的，直到 1GB 以太网出现，此时像这样的 tap 的信号损失成为了一个问题。10Gbps 甚至更复杂，因为实际的第 1 层信号不再匹配标准以太网。因此，在 10Gbps 或以上的情况下，tap 是主动设备，更像是具有一个或多个 SPAN 端口的交换机，而不是被动设备。信号仍然完全复制到目标端口，但背后有更多的电路来确保发送到实际源、目的地和捕获主机的信号仍然可以被所有方可靠地读取。

我们仍然可以看到 tap 在一些特定的安全设置中使用，其中需要捕获 1G、10G 或更快的流量，但我们也需要电气隔离来防止任何传输。

在某种程度上，tap 仍然是一种方便的故障排除设备，可以放在您的笔记本电脑包中，以备需要时使用，但正如前面所述，它们在普通数据包捕获中不经常使用。

到目前为止，我们已经描述了各种合法的捕获数据包的方法，但是犯罪分子和他们的恶意软件是如何完成这项工作的呢？

恶意数据包捕获方法

到目前为止，我们已经考虑了如何合法地捕获数据包。然而，如果你考虑恶意意图，你如何防御可能使用其他方法的攻击者？为了做到这一点，让我们像攻击者一样思考，看看他们可能如何在没有对任何东西进行管理访问的情况下建立一个数据包捕获站。

第一种方法在第七章中已经涵盖过，Linux 上的 DHCP 服务。攻击者可以挂载一个恶意的 DHCP 服务器，并将他们的主机设置为目标计算机的默认网关或代理服务器（使用 WPAD 方法）。在任何一种方法中，受害者的数据包都会通过攻击者的主机并被捕获。如果协议是明文的（例如，使用 HTTP，TFTP，FTP 或 SIP，正如我们将在本章的故障排除 应用程序 - 捕获 VoIP 电话呼叫部分中看到的那样），这些数据包可以被存储以供以后分析，甚至可以实时修改。我们可以通过保护 DHCP 服务来防御这种类型的攻击（正如我们在第七章中讨论的那样，Linux 上的 DHCP 服务）。

类似地，攻击者可以劫持路由协议来捕获特定子网或主机的流量。我们偶尔在互联网上看到这种情况，其中一个子网可能会被劫持，利用 BGP 路由协议的信任性质。在这些情况下，我们经常看到信用卡门户被重定向到意想不到的国家，人们的凭据在他们登录到那里准备好的假网站时被收集。在这种情况下，受害者如何保护自己？实际上，这比你想象的要简单和不可靠。如果受害者收到无效证书的警告，他们应该关闭该会话，不要继续。不幸的是，虽然这确实是一个简单的解决方案（警告屏幕几乎是整页的，而且有很多红色），但它也不是很可靠，因为许多人会简单地点击任何可以解除警告并继续访问网站的按钮。

攻击者可以使用的另一种常见方法是 ARP 缓存中毒来捕获数据包。要理解这一点，您可能需要复习一下 ARP 的工作原理（第三章，使用 Linux 和 Linux 工具进行网络诊断）。在高层次上，攻击者使用 ARP 数据包向每个受害者“说谎” - 这在下图中很容易看出：

图 11.3 - ARP 缓存中毒

在这个图中，两个受害者是3333.3333.3333，并告诉3333.3333.3333。交换机并没有看到任何这些；它只是路由各种数据包，因为它们在技术上都是有效的。现在，当3333.3333.3333。

如果受害者 2恰好是子网的默认网关，攻击者可以扩展到脱网捕获。

这似乎有些复杂，但多年来已经实现了自动化 - 这种类型攻击的第一个工具是Dug Song在 2000 年编写的dSniff。一个更现代的工具，使用图形界面，允许您图形化选择各种受害者的工具是 Ettercap。Ettercap 及其后继者 Bettercap 的优势在于，它们一旦发现“感兴趣的痕迹”，如凭据或密码哈希，它们将自动收集这些信息。

过程完成后，当 Ettercap 关闭时，它会优雅地重新填充所有受害者站点的 ARP 表，以正确的值。这意味着如果 Ettercap 以非优雅的方式关闭（例如，被踢出网络或被过多的流量“淹没”），受害站点将被“困”在错误的 ARP 条目中，通常持续到每个工作站的 ARP 计时器到期。如果攻击者站点在其列表中有子网的默认网关，这种情况将隔离整个子网，持续时间为网关的 ARP 计时器（最长可达 4 小时）。

我们如何保护自己免受这种攻击？日志记录是一个很好的起点。大多数现代交换机和路由器在看到两个不同的 MAC 地址声称拥有相同的 IP 地址时会记录重复 IP 地址错误。对这种类型的日志条目进行警报（参见第十二章，使用 Linux 进行网络监控）可以帮助启动积极的事件响应计划。

我们还能做些更“积极”的事情吗？大多数交换机都有一个名为动态 ARP 检查（DAI）的功能，可以查找这种类型的攻击。当发现攻击时，攻击者的以太网端口将被禁用。不过，要注意实施这个功能的位置 - 不要在具有下游交换机或无线接入点的交换机端口上配置 DAI；否则，当他们的端口被禁用时，攻击者将带走许多无辜的旁观者。通常会将具有下游交换机或 AP 的端口配置为“受信任”，期望下游设备将处理其自己连接的站点的检查。

DAI 看起来与 DHCP 检查和信任配置非常相似：

ip arp inspection vlan <number>
ip arp inspection log-buffer entries <some number, try 1024 to start>
ip arp inspection log-buffer logs 1024 interval 10

正如我们之前提到的，在具有下游交换机、AP 等的交换机端口上，你可以使用以下方法禁用 DAI：

int g1/0/x
  ip arp inspection trust

要将 DAI ARP 阈值从默认的每秒 15 个数据包降低到更低的值（例如 10），可以执行以下操作：

int g 1/0/x
  ip arp inspection limit 10

如果在攻击中启用了 ARP 检查，使用 Ettercap 等工具，该工具通常会向受害者发送一系列稳定的 ARP 数据包，以确保他们的 ARP 缓存保持被感染状态。在这种情况下，受影响的交换机将生成DAI-4-"DHCP_SNOOPING_DENY" "Invalid ARPs"错误消息，因为端口阈值已超过。端口还将创建ERR-DISABLE状态，完全使攻击者下线。

然而，在当今不断增长的网络速度世界中，你可能会发现你所捕获的数据超出了你工作站的容量 - 但不要放弃，有一些优化可以帮助你！

在捕获时的性能考虑

正如我们在前一节中提到的，一旦数据速率开始上升，即使是高端 Linux 主机或虚拟机，捕获数据包也会对主机产生影响。在设置数据包捕获时，还有一些网络决策需要考虑。

需要考虑的因素包括：

• 如果你使用 SPAN 或监视端口，根据交换机型号，你的目的地端口（你的嗅探器站插入的端口）可能不在网络上 - 它可能只能看到源端口的来往流量。这意味着通常情况下，你必须使用你最快的内置网卡进行数据包捕获，然后如果该主机需要同时在网络上活动（例如，如果你远程连接到它），则使用性能较低的 USB 网卡。

• 在所有情况下，确保你的网卡足够快，可以真正“看到”所有目标数据包。特别是在监视端口设置中，你可以配置一个 10 Gbps 的源和一个 1 Gbps 的目的地。这样做是可以的，直到你开始看到流量超过 1 Gbps。在那时，交换机将开始排队和/或丢弃数据包，这取决于交换机型号。换句话说，你的结果可能是不可预测的（或可预测的糟糕）。

• 一旦在网卡上，确保网卡的上行能够处理流量。例如，如果你在笔记本上使用了一个 10 Gbps 的雷电适配器，请确保它插入了一个雷电端口（而不是 USB-C 端口），并且你有足够的带宽来添加这个新的带宽。例如，如果你在同一台笔记本上有两个 4K 屏幕，很可能你的雷电上行没有剩余的 10 Gbps 来进行高速数据包捕获。

• 向上移动，确保你的硬盘既有足够的速度又有足够的容量。如果你要捕获 10 Gbps，你可能会想要选择 NVME 固态硬盘进行存储。你可能还希望它是内置的，而不是插在你的网络适配器上的同一个雷电或 USB-C 适配器上。另外，如果你要使用服务器进行捕获，可以查看 RAID 或 SAN 的吞吐量。特别是如果存储是 iSCSI，确保你的数据包捕获不会“饿死”其他 iSCSI 客户端的对 SAN 的带宽。

• 考虑您的环形缓冲区的大小 - 特别是 tcpdump 在这方面具有很好的灵活性。环形缓冲区是捕获的数据包存储在内存中的临时区域，在发送到磁盘或捕获应用程序的内存之前。在大多数 Linux 系统上，默认值为 2 MB，通常是足够的。但是，如果您发现捕获会话似乎丢失了数据包，增加这个值可能会解决这个问题。在 tcpdump 中，可以使用-B参数轻松调整这个值 - 这使得 tcpdump 成为在您知道或怀疑可能会推动数据包捕获极限时使用的理想工具。请注意，tcpdump 没有记录此的默认大小; 2 MB 默认值只是通常看到的。

• 考虑到您需要整个数据包。如果您只需要数据包头来排除故障（换句话说，您不需要实际有效载荷），您可以调整snaplen - 每个数据包中要捕获的字节数。例如，将此值从1500减少到64可以大大增加适合环形缓冲区的数据包数量。您将希望确保snaplen值足够大，以捕获所有数据包头信息。

• 最后，如果您作为授权的安全演练（如渗透测试）中的攻击者工作，还有一些事情需要牢记。如果您在参与中使用 ARP 缓存中毒，请注意此攻击存在一定的风险。确保您的工作站具有足够的接口带宽、CPU 和内存容量，以便成功进行此类攻击 - 如果中间人（MiTM）流量超过您的工作站的容量，您的机器可能会下线。对受害者（可能是整个 VLAN）的影响是，他们将留下无效的 ARP 缓存，并且基本上在其 ARP 计时器的持续时间内被困住（在某些平台上长达 4 小时）。

在我们讨论的理论之后，我们将使用哪些工具来捕获和分析数据包？

捕获工具

许多不同的工具可以用于从网络中捕获数据包，并直接分析数据包数据，或将它们存储在pcap文件中。甚至有更多的工具可以使用这些pcap文件，并允许您对其进行进一步的离线分析。

tcpdump

我们已经多次提到了 tcpdump。这是一个命令行数据包捕获工具，这意味着它可以在没有图形用户界面的系统上使用，或者如果您正在使用非图形用户界面，如 SSH。因为它不涉及任何图形，并且不会为您查看（例如告诉您任何协议的具体信息）预处理数据包，所以它是您在数据包捕获中找到的性能最高、影响最小的工具之一。

tcpdump 使用Berkely Packet Filter（BPF）语法来决定要捕获哪些数据包。这可以用于按 IP 地址、MAC 地址、协议甚至 TCP 数据包中的特定标志进行过滤。

Wireshark

Wireshark 是更常用的数据包捕获工具之一。它有一个图形用户界面，每个数据包都被分类、颜色编码和处理，以便尽可能显示更多信息。与 tcpdump 类似，Wireshark 使用 BPF 语法在捕获期间过滤数据包。它使用不同的过滤语法来过滤显示的数据包。

TShark

TShark 与 Wireshark 应用程序捆绑在一起，本质上是 Wireshark 的命令行/文本版本。如果您在 SSH 会话中并且想要比 tcpdump 更灵活的东西，那么拥有 TShark 会非常方便。

其他 PCAP 工具

有数百甚至数千种工具可用于捕获数据包或分析数据包捕获。在攻击者方面，我们已经讨论过 Ettercap、Bettercap 和 dsniff 作为中间人攻击工具。像 NetworkMiner 这样的工具非常适合捕获数据包或处理现有的数据包捕获。这样的工具可以帮助您节省分析可能迅速变得非常庞大的数据包捕获文件所需的时间。NetworkMiner 将从pcap文件中提取有价值的工件，如凭据、凭据哈希、证书和在捕获会话期间传输的数据文件。

我们将讨论更多使用数据包捕获的高级工具，即入侵检测系统（IDS）、入侵防御系统（IPS）和被动流量监控，在接下来的章节中（第十三章，Linux 上的入侵防御系统，和第十四章，Linux 上的蜜罐服务）。

您可能会发现，您进行数据包捕获的原因是为了解决问题。让我们讨论如何捕获或查看只与您正在解决的问题相关的数据包。

过滤捕获的流量

使用数据包捕获工具时，您将注意到显示屏上出现的数据包数量之多。由于数据包捕获通常是为了故障排除目的而进行的，通常希望将数据包限制在需要解决的问题上。为此，您通常要么在捕获过程中“过滤”这些数据包，要么在捕获后过滤这些数据包的显示。让我们讨论这两种情况。

Wireshark 捕获过滤器（捕获您的家庭网络流量）

在没有特定的交换配置的情况下，在您的家庭网络上进行数据包捕获将发现比您想象的更多。如今，许多家庭都有一小群连接到网络的基于 Linux 的设备-如果连接的话，您的电视、恒温器、门铃、跑步机和冰箱很可能都是 Linux 主机。这些通常被称为物联网（IoT）设备。几乎所有物联网主机都可能在有线和无线网络上广播和多播一系列不断的“发现”数据包，它们这样做是为了找到可能想要与它们交谈甚至控制它们的控制器和中心。

让我们快速看一下-我们将使用 Wireshark 工具进行此操作。

启动工具并选择连接到您的网络的网络适配器。

在点击开始之前，让我们添加一个捕获过滤器。我们将排除我们的地址，并且还将排除 ARP 数据包的捕获。请注意，您的 IP 地址将不同：

图 11.4-向 Wireshark 添加捕获过滤器

现在，点击开始捕获按钮，位于左上角的蓝色鲨鱼鳍图标，或选择捕获/开始。

在典型的家庭网络上，您应该在几秒内就能探索到数十个数据包-以下屏幕截图显示了我家网络上 10 秒后的数据包。您可能会看到广播和多播流量的混合-根据定义，这些流量是发送到所有站点的。虽然这可能被视为有限的捕获，但您可以用它来开始对您的网络上的内容进行清点：

图 11.5-典型家庭网络捕获

即使不探索数据包的内容，也有一些关键事项需要注意前面的屏幕截图：

• 一些 IPv4 设备正在169.254.0.0/16范围内运行（自动私有 IP 地址范围）。这些地址无法路由到您的网络之外，但对于诸如电视遥控器或门铃与本地网络上的控制器通信等事情来说，这是完全可以的。

• 您可能会在本地交换机上看到生成树流量，如果等待足够长的时间，您可能会看到链路层发现协议 (LLDP) 或Cisco 发现协议 (CDP) 数据包（我们稍后在本节中将看到一个示例）。

• 您还很可能会看到 IPv6 流量 – 在这个捕获中，我们可以看到DHCPv6和ICMPv6数据包。

所有这些来自 10 秒的收听！有趣的是，深入研究您的家庭网络，甚至简单地查看您看到的 MAC 地址，并使用其 OUI 标识每个供应商。

让我们从数据包的角度深入研究一组特定设备 – Voice over IP (VoIP) 电话。

tcpdump 捕获过滤器 – VoIP 电话和 DHCP

让我们通过查看典型 VoIP 电话的启动序列来探索 tcpdump 和 Wireshark 中的捕获过滤器。我们的网络非常简单；有四个站点和两个 VLAN：

图 11.6 – 数据包捕获的实验室设置

请注意，我们设置了一个监视会话，其中端口5接收端口1的所有数据包。

VoIP 电话启动和通信涉及的站点总结如下：

请注意，当我们从表的左侧向右侧移动时，我们正在沿着 ISO 模型表示的“堆栈”向下移动 – 扩展在应用层表示，IP 地址是第 4 层，MAC 地址和 VLAN 是第 2 层，最后是接口本身。

首先，让我们使用 tcpdump 在 DHCP 服务器上捕获 DHCP 序列。使用这个主机很方便，因为 DHCP 服务器是 DHCP“对话”的一端，所以如果一切正常，它应该能看到双向的所有数据包。

此外，使用 tcpdump 意味着我们不依赖于任何 GUI – 如果您正在从 SSH 会话中操作，您仍然得到充分的支持。tcpdump 几乎被普遍支持。tcpdump 默认安装在几乎每个 Linux 发行版上，此外，您可以在大多数防火墙、路由器和交换机上调用 tcpdump（使用一种或另一种语法） – 这并不奇怪，考虑到这些平台中有多少是基于 Linux 或 BSD Unix 的。

让我们继续捕获。因为源站点尚未具有 IP 地址，所以我们需要根据电话的 MAC 地址和 DHCP 使用的两个 UDP 端口67/udp（bootps）和68/udp（bootpc）来指定流量。我们将捕获完整的数据包并将它们写入文件 – 请注意，实际捕获需要sudo权限。

首先，列出接口，以便我们正确获取源：

$ tcpdump -D
1.ens33 [Up, Running]
2.lo [Up, Running, Loopback]
3.any (Pseudo-device that captures on all interfaces) [Up, Running]
4.bluetooth-monitor (Bluetooth Linux Monitor) [none]
5.nflog (Linux netfilter log (NFLOG) interface) [none]
6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
7.bluetooth0 (Bluetooth adapter number 0) [none]

现在，让我们捕获一些数据包！

$ sudo tcpdump -s0 -l -i ens33 udp portrange 67-68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens33, link-type EN10MB (Ethernet), capture size 262144 bytes
08:57:17.383672 IP 192.168.123.1.bootps > 192.168.122.113.bootps: BOOTP/DHCP, Request from 80:5e:c0:57:bc:91 (oui Unknown), length 548
08:57:18.384983 IP 192.168.122.113.bootps > 192.168.123.1.bootps: BOOTP/DHCP, Reply, length 332

我们的论点包括以下内容：

在输出中，我们可以看到交换中的前几个数据包 – 我们想要将其写入文件，因此让我们添加-w：

$ sudo tcpdump -s0 -l -i ens33 udp portrange 67-68 -w DHCPDora-Phone.pcap

现在，假设我们无法访问 DHCP 服务器。或者，如果 DHCP 工作不正常，我们可能希望从网络视角来交换，也许看看为什么服务器或客户端没有接收或发送 DHCP 数据包。在这种情况下，请记住客户端是电话，因此虽然它很可能是基于 Linux 的，但供应商可能没有让它轻松地通过 SSH 到该平台运行 tcpdump。

在这种情况下，典型的解决方案是设置一个 SPAN 端口，也称为监视或镜像端口（取决于交换机供应商）。在这种情况下，我们的数据包捕获主机位于端口5，因此将成为监视会话目的地。电话位于端口1，因此将成为我们的监视会话源。在 Cisco 交换机上，此设置语法如下：

monitor session 1 source interface Gi1/0/1
monitor session 1 destination interface Gi1/0/5

要查看正在进行的各种监视会话，show命令如下：

rvlabsw01#sho monitor
Session 1
---------
Type                   : Local Session
Source Ports           :
    Both               : Gi1/0/1
Destination Ports      : Gi1/0/5
    Encapsulation      : Native
          Ingress      : Disabled

让我们在 Wireshark 中设置这个。这对我们有很多优势 - 它不仅会对我们的过滤器进行语法检查（注意当它有效时会变成绿色），而且我们还可以以图形方式选择我们的网络适配器，并且在捕获过程中以图形方式显示数据包。同样，在选择捕获接口后，过滤器将如下所示：

图 11.7 - 在 Wireshark 中定义捕获过滤器

请注意，捕获过滤器的语法与 Wireshark 和 tcpdump 相同；它使用所谓的 BPF 语法。在这个例子中，我们在过滤器中添加了ether host，以仅捕获发送到或从该 MAC 地址的 DHCP 数据包。按下开始捕获按钮（窗口左上角的蓝色鲨鱼鳍图标）；我们将看到电话启动时的 DHCP 序列：

图 11.8 - 捕获的完整 DHCP“DORA”序列

如果您没有设置实验室，您可以从我们的 GitHub 页面收集这个pcap文件（github.com/PacktPublishing/Linux-for-Networking-Professionals/tree/main/C11）；文件名为DHCP DORA Example.pcapng。

我们可以简单地展开数据包中的各种数据字段，以显示各种诊断值。展开第一个帧的 DHCP 部分：

图 11.9 - 探索 DHCP“Discover”数据包

向下滚动并展开一些 DHCP Option字段 - 特别是Parameter Request List：

图 11.10 - “Discover”数据包中的 DHCP 选项

请注意电话的请求列表中有多少项目。这为攻击者提供了一些很好的选项。特别是，如果恶意的 DHCP 服务器可以响应并给电话一个不同的 TFTP 服务器和 Bootfile 名称，那么 TFTP 服务器上的文件将包含电话的整个配置，包括其分机和呼叫者 ID - 几乎所有内容。

此外，像这样的配置服务器几乎总是 TFTP 或 HTTP 服务器。对于攻击者来说，这意味着如果他们可以在客户端和服务器之间获得 MiTM 位置（使用 Ettercap、Bettercap 或类似工具），他们不仅可以收集配置数据以供以后在攻击中使用 - 他们还可以在电话下载数据时实时修改这些数据。

这强调了保护 DHCP 服务和 VoIP 配置服务的重要性！让我们来看一个更通用的协议，我们可以用于善良和邪恶 - LLDP 和 CDP。

更多的捕获过滤器 - LLDP 和 CDP

当一个站点启动时，我们还能看到什么？CDP 和 LLDP 是大多数环境中会看到的主要二层发现协议。这些协议将为我们提供各种有用的信息，用于故障排除或自动记录我们的网络和站点。它们还会为攻击者提供相同的信息，这意味着在您可以的地方，您将希望限制这些协议，通常是在连接到其他公司的任何通信链路上。

LLDP 几乎对所有 VoIP 实现都是必需的 - 这是电话知道大多数情况下应该在哪个 VLAN 上的方法（除非 VLAN 在 DHCP 中设置），这也是大多数电话协商它们的PoE（Power over Ethernet）功率级别的方法。没有 LLDP，所有电话将接收完整的 15 瓦电力，这意味着任何给定的交换机都需要提供比它所需的电力多 6-7 倍（大多数电话的功率范围在 2-4-6 瓦之间）。

让我们来看看 CDP（它以01:00:0c:cc:cc:cc的二层地址进行多播）和 LLDP（它以01:80:C2:00:00:0E进行多播，并且以0x88cc的以太网协议）。在这种情况下，我们的捕获过滤器将如下所示：

ether host 01:00:0c:cc:cc:cc or ether proto 0x88cc

或者，它将如下所示：

ether host 01:00:0c:cc:cc:cc or ether host 01:80:C2:00:00:0E

结果捕获显示 LLDP 和 CDP 都在起作用，但我们可以从电话发送的 LLDP 数据包中看到什么？

我们正在寻找的信息都在 Wireshark 显示的应用程序部分（此捕获的示例文件同时包括 LLDP 和 CDP - Phone Example.pcapng）。打开文件并突出显示 LLDP 数据包的链路层发现协议部分。请注意，以下数据包含许多十六进制字符，但有足够的 ASCII 转换内容，您已经可以看到一些有用的数据！

图 11.11 - 捕获的 LLDP 帧

现在，展开 LLDP 选项卡，以便我们可以查看该部分的一些详细信息：

图 11.12 - 更详细查看 LLDP 数据包

电话已设置为自动速度和双工，并协商到 100/全双工。

电话是 Yealink，型号 T21P-E2，序列号为805ec086ac2c。它运行的固件版本是 52.84.0.15。

它在未标记的（本地）VLAN 中（VLAN ID 为0），并且没有0，所以是 L2 优先级）。

请随时从捕获文件中的 CDP 数据包中收集相同的信息 - 请记住我们过滤了 CDP 和 LLDP。

这可能看起来像一个简单的例子，但是网络往往是多年来“有机”地组合在一起的，几乎没有文档记录。在某个时候，网络将变得足够复杂，或者知道如何连接所有内容的人将离开公司 - 在那时，记录网络将变得重要。如果启用了 CDP 或 LLDP，这将为您提供一个重要的工具，以获取所有 IP 地址，型号，固件和连接端口的良好起点。

从攻击者的角度来看，这些信息可以用来识别可能适合利用的主机。您可以使用相同的方法来收集这些数据，寻找具有已知漏洞的固件版本的基础设施。然后，这个设备可以成为攻击者将要转移到的下一个平台，使用该主机收集更多信息，以在下一次攻击中使用。这种方法可以轻松地用于将他们的攻击延伸到下一个连接的组织，也许是针对我们 ISP 在我们的互联网或 MPLS 上行链路上的路由器或交换机。

现在，让我们看一下从数据包捕获中提取特定工件，比如文件。

从数据包捕获中收集文件

如果您正在处理一组捕获的数据包，或者正在进行数据包捕获，如果看到文件传输，您有哪些选项？如果它使用任何 TCP 协议或众所周知的 UDP 协议（如 TFTP 或 RTP），那就太容易了！

在这里，我们可以看到一个数据包捕获（在我们的 GitHub 存储库中的file-transfer-example.pcapng）。Wireshark 正确识别这是一个 TFTP 文件传输：

图 11.13 - 包含文件传输的数据包捕获

知道这个网络上有 VoIP 电话，我们怀疑这些可能是配置文件 - 在启动/初始化过程中传输到电话的配置文件。让我们仔细看一下。

从第一行开始，我们可以看到对名为SIPDefault.cnf的文件的读取请求。这确实是一个高价值目标，因为它为 Cisco SIP 电话提供了默认设置，如果它们是集中配置的。突出显示标记为数据包的第一个数据包（数据包 3）。右键单击它，然后选择跟随| UDP 流。正如您所记得的，UDP 协议中没有会话数据，但是 Wireshark 内置了许多协议的解码，TFTP 只是其中之一：

图 11.14 - 从 PCAP 中收集传输文件 - 步骤 1

太棒了！我们找到了我们要找的文件！选择**另存为…**以“收集”此文件。现在，让我们看看还有什么：

图 11.15 - 从 PCAP 中收集转移文件 - 步骤 2

关闭此窗口并清除 Wireshark 中的显示过滤器行，以便我们可以再次看到整个捕获（清除文本，显示udp stream eq 1）。

在数据包 15 下面，我们看到对第二个名为SIP0023049B48F1.cnf的文件的请求。重复我们之前对此文件的处理过程 - 传输从数据包 17 开始，因此跟随从那里开始的 UDP 流。有了这个文件，我们现在拥有了 MAC 地址为0023.049B.48F1的电话的 SIP 配置。查看此文件，我们可以看到这是分机1412的配置文件，呼叫者 ID 为Helpdesk Extension 2。该文件包含该电话的整个配置，包括 SIP 密码。有了这些信息，攻击者可以轻松冒充帮助台分机，并通过社会工程学从打电话给帮助台的人那里收集机密信息 - 这确实是一条宝贵的信息！

现在，让我们深入研究我们的电话系统，并捕获实际 VoIP 电话呼叫的音频。

故障排除应用程序 - 捕获 VoIP 电话呼叫

为此，我将保持我们相同的捕获设置，并从客户端电话的端口G1/0/1拨打到G1/0/2的帮助台呼叫。捕获G1/0/1进出的所有数据包应该得到我们需要的内容 - 在此间隔内，进出G1/0/2的流量应与G1/0/1完全相同（只是方向相反）。

为了捕获我们的文本，我们将简单地进行全面捕获；在这种情况下不需要过滤器。我们开始了捕获，确保捕获了通话的开始和结束（因此我们在拨号之前开始捕获，并在挂断后结束）。

捕获完成后，我们可以在 Wireshark 中查看我们的 PCAP - 本实验室的示例文件是HelpDesk Telephone Call.pcapng，位于我们的 GitHub 存储库中github.com/PacktPublishing/Linux-for-Networking-Professionals/tree/main/C11。

让我们看一下标记为Ringing的数据包 6。探索此数据包中的应用程序数据说明了在许多情况下理解这些数据是多么容易 - 特别是 SIP（在呼叫设置中使用时）遵循了您可能期望从电子邮件中使用的内容：

图 11.16 - 探索 SIP“响铃/邀请”数据包

看一下其他几个 SIP 数据包，并探索每个应用程序数据中的一些字段。

接下来，我们将查看通话本身。请注意，在数据包 15 上，协议从 SIP（在5060/udp上）更改为IP部分，然后展开46已设置：

图 11.17 - RTP（语音）数据包中的 DSCP 位

DSCP 是数据包中的一个 6 位字段，告诉中间网络设备如何对该数据包进行优先处理。在这种情况下，该值设置为46或Expedited Forwarding，简称EF。这告诉交换机，如果有几个数据包排队等待，这个（以及其他具有相同标记的数据包）应该优先处理。事实上，EF 标记是独特的，因为它告诉网络设备尽量不要排队处理这个数据包。

EF 标记是独特的，因为它不排队，而是首先转发以保持语音流的完整性，并防止出现“回声”等现象。它还是独特的，因为如果缓冲区填满到必须排队此数据包的程度，通常，中间的网络设备会丢弃其中的一些数据包，而不是延迟它们。这是因为人耳对于一些数据包被丢弃的 VoIP 呼叫更宽容，而不是这些相同的数据包被延迟。

如果您检查设置呼叫时使用的 SIP 数据包之一，这些数据包的 DSCP 值都为 26（有保证的转发）-换句话说，并非加速，但它被标记为一种重要的 UDP 数据包。这些标记请求，如果接口或路径拥塞，那么这个数据包应该被缓冲而不是丢弃。

接下来，让我们再次深入研究此 RTP 数据包中的应用数据：

图 11.18–RTP 应用数据

请注意，这些数据要简单得多。在大多数情况下，有一些引导数据，用于标识此数据包是正在进行的电话呼叫的一部分。这是呼叫的数据包（和帧）4。编解码器被识别，以便远端设备知道如何解码数据。数据包的大部分内容在Payload字段中，这是语音数据。

您可以通过突出显示呼叫中的一个 RTP 数据包，右键单击它，然后选择跟踪 UDP 数据流来“跟踪”此流。这样可以提取呼叫中的所有 RTP/语音数据，以便进行分析。在其他协议中，您可能会选择跟踪 TCP 数据流或跟踪 UDP 数据流，然后能够恢复整个文件（例如从 FTP 或 TFTP 会话中）。

要恢复语音对话，Wireshark 已经添加了一个特殊的处理程序。打开此 PCAP 文件后，选择R（右）正在拨打电话，而L（左）正在接听电话。如果选择播放按钮，可以回放整个对话：

图 11.19–回放捕获的 VoIP 对话

或者，选择任何 RTP 数据包，并选择电话| RTP|流分析。现在，选择保存并选择任何同步选项（例如-0），非同步前向和反向音频。这将文件保存为“AU”（Sun 音频）文件，可以由大多数媒体播放器播放，或者转换为所需的任何其他音频格式：

图 11.20–将 VoIP 对话保存为可播放的媒体文件

这对于运行 VoIP 解决方案的任何人都有一些明显的影响。默认情况下，大多数 VoIP 配置不会加密语音流量。这是为了消除加密/解密作为延迟或抖动的来源，这是语音质量下降的两个主要原因。这意味着在这些情况下，语音数据不能被视为“安全”。

另外，注意在我们的求助台呼叫中，求助台人员使用来电显示来验证来电者的身份。这在一切正常时可能有效，但我们已经描述了一种可能被破坏的方法。甚至更简单的方法是攻击者使用数据包捕获来识别 VoIP 基础设施的工作原理，然后在他们的计算机上建立一个“软电话”。在这种情况下，攻击者可以为来电者 ID 定义任何他们想要的内容；这是一个简单的文本字段。通常，来电者 ID 是由手柄提供而不是 PBX，所以在这种情况下，求助台被欺骗执行密码重置。

通常，电话启动序列使用基于 TFTP 或 HTTP 的配置服务。这将根据电话机的“名称”下载一个配置文件。在许多情况下，电话机的“名称”是单词SIP，后跟电话机的 MAC 地址 - 您还可以在电话机的 LLDP 广告中看到这些名称。这种约定会因不同的电话机供应商而异，但几乎总是一个简单的文本字符串，结合电话机的 MAC 地址。攻击者只需在配置/提供服务器和电话机之间进行中间人攻击，就可以破坏电话机的配置。加上配置文件的明文性质，使得攻击者可以在文件下载时修改关键字段。

Wireshark 显示过滤器 - 在捕获中分离特定数据

继续使用我们的帮助台呼叫文件，我们可以轻松地将此文件过滤为仅显示特定流量。例如，在故障排除时，通常需要仅查看 SIP 流量 - SIP 网关经常属于云提供商，他们经常设置错误，导致 SIP 认证问题甚至 ACL 设置错误，因此登录甚至初始连接失败。您可以在数据包中看到所有这些问题，因此让我们过滤 SIP 协议：

图 11.21 - 仅过滤 SIP 流量（呼叫设置/拆除）

这显示了整个呼叫设置，响铃，接听和最终挂断（BYE数据包在底部的第二行处于7848）。我们还可以通过指定udp.port==5060来进行过滤。与数据包捕获过滤器相比，显示过滤器使用不同的语法，这最终更加灵活。通常，您会使用一个过滤器进行捕获以获取所需的内容，然后在 Wireshark 中再次进行过滤，从而允许您使用多个过滤器串联在一起，深入挖掘以获取确切所需的内容。

请注意14和5896之间缺少的5882个数据包；那就是对话本身。让我们只过滤这个：

图 11.22 - 过滤 RTP 流量（语音对话）

通常只通过协议名称过滤 RTP，因为 RTP 端口会因呼叫而异，在 SIP 设置期间进行协商。通过深入研究 RTP 数据包，我们可以看到端口为12200的192.168.123.55和端口为12830的192.168.123.53（您可以从 SIP 数据包中获取名称和扩展名）：

图 11.23 - 用于此对话的 RTP 端口

这两个端口是在哪里协商的？这些是在 SIP 交换的一部分 SDP 中设置的。第一个 SDP 数据包在数据包 4 中，x1234 处的呼叫者标识其 RTP 端口。展开此数据包，然后滚动到会话初始协议（INVITE）|消息正文|会话描述协议|媒体描述部分：

图 11.24 - 呼叫者设置其 RTP 端口

SDP 回复在数据包 13 中，当远端的电话被接听时。这是接收方（扩展1411在192.168.123.53）回复其端口的地方；即12830：

图 11.25 - 通话接收方设置其 RTP 端口

您可以通过查找SIP 和 SDP作为显示过滤器（数据包 4 和 15）来仅过滤 SDP 数据包：

图 11.26 - 仅过滤 SIP/SDP 数据包

请注意，如果您查看第一个数据包，它是一个失败的邀请。如果您感兴趣，可以深入了解失败的原因！

希望您可以将您在本节中学到的分析各种 VoIP 协议的方法应用到生产环境中的具体问题解决中。

总结

到目前为止，我们已经介绍了如何使用数据包捕获工具，无论是从合法的故障排除角度还是从攻击者的角度。特别是，我们已经介绍了如何定位和配置以便捕获数据包，使用什么工具，以及如何将“消防栓”式的信息过滤到您需要解决问题的内容。过滤特别有用，这就是为什么 Wireshark 中有一个两阶段的过滤方法（在捕获时和在显示数据包时）。

我们已经深入介绍了 VoIP 呼叫的操作，从启动电话到拨打电话，再到捕获和收听呼叫的音频回放。到目前为止，您应该对这些工具为网络、系统和应用程序管理员提供的功能深有体会。您应该已经做好了将这种体会转化为真正掌握的准备——只需记住，学习 Wireshark 或 tcpdump 等工具的最佳方法是使用它来解决问题，或者至少使用它来学习其他东西（比如 DHCP 的工作原理，或者电话呼叫在网络上的工作原理）。

在下一章中，我们将讨论网络监控，其中将包括使用 SNMP 的日志记录、使用 NetFlow 和其他基于流的协议来监控和故障排除网络。

问题

在我们结束时，这里有一些问题供您测试对本章材料的了解。您将在附录的评估部分找到答案：

1. 为什么您会使用端点主机，而不是 SPAN 端口上的中间设备进行数据包捕获？

2. 在什么情况下您会使用 tcpdump 而不是 Wireshark？

3. RTP 使用的端口是多少，用于 VoIP 通话？

进一步阅读

要了解本章涵盖的内容，请参考以下参考资料：

• Wireshark 用户指南：www.wireshark.org/docs/wsug_html_chunked/

• tcpdump 手册页面：www.tcpdump.org/manpages/tcpdump.1.html

• SANS（2019 年 1 月）TCPIP 和 tcpdump 备忘单：www.sans.org/security-resources/tcpip.pdf

• Wireshark 显示过滤器备忘单：packetlife.net/media/library/13/Wireshark_Display_Filters.pdf

• Green, T.（2012 年 11 月 16 日）。使用基本 Linux 工具分析网络流量：www.sans.org/reading-room/whitepapers/protocols/paper/34037

• Cheok, R.（2014 年 7 月 3 日）。Wireshark：彩色数据包指南：www.sans.org/reading-room/whitepapers/detection/paper/35272

• VandenBrink R（2009 年 11 月 18 日），使用 Cisco 路由器作为 tcpdump 或 Wireshark 的远程收集器：https://isc.sans.edu/forums/diary/Using+a+Cisco+Router+as+a+Remote+Collector+for+tcpdump +or+Wireshark/7609/

第十二章：使用 Linux 进行网络监控

在本章中，我们将讨论各种网络监控和管理协议、工具和方法。我们将介绍使用 syslog 进行日志记录，它可以用于记录各种主机上感兴趣的事件。这将扩展到基于云的 syslog 事件收集，允许你总结防火墙流量并将你的流量模式与互联网上的流量进行比较。

我们将讨论使用 SNMP 来收集各种网络设备和主机的性能统计数据，这在故障排除和容量规划中都很有用。

最后，我们将使用 NetFlow 和其他流量收集协议来寻找流量异常——我们将使用 NetFlow 来进行典型的事件调查，揭示一个大规模的数据外泄事件。

具体来说，我们将涵盖以下主题：

• 使用 Syslog 进行日志记录

• Dshield 项目

• 在 Linux 上收集 NetFlow 数据

技术要求

在这一章中，我们将讨论网络管理的几个方面。虽然你可以在本章中重新创建示例构建，但请注意你的数据将会不同。因此，虽然使用各种数据类型进行监控或故障排除的方法将保持不变，但要在你的环境中使用你的数据（以及任何需要解决的问题），你将需要不同的搜索词。

也就是说，你现有的 Linux 主机或 VM 可以用来构建本章中描述的任何一个或所有示例系统。然而，在生产中，你会将这些功能分开部署在一个、两个甚至更多的专用服务器上。如果你在实验室中使用 VM，我最好的建议是从一个新的、干净的映像开始，并从那里开始构建——这样，如果你发现我们使用的各种网络管理系统（NMSes）有用，你可以直接将它们移植到生产中。

NMS 部分侧重于 LibreNMS 应用程序。对于那组示例，建议下载并安装该应用程序的预构建 Linux VM 映像（OVA 格式）。

使用 Syslog 进行日志记录

日志记录是管理任何系统的关键方面，几乎普遍建议进行中央日志记录。中央日志记录允许你将来自多台服务器或服务（例如防火墙、负载均衡器和 Web 服务器）的日志合并到一个按时间顺序排列的文件中。这通常可以加快任何故障排除或诊断，因为你可以看到事件从一个平台移动到下一个。从安全的角度来看，这在事件响应（IR）中尤为重要。在响应事件时，你可能会看到恶意软件通过电子邮件到达，然后作为一个进程执行，然后横向移动（通常称为“东/西”）到其他工作站主机，或向“北”向你的服务器移动。再加上定期（通常每小时）更新后，你的工具的当前版本很可能能够从日志中找出可能在昨天被忽略的恶意软件。

此外，从安全的角度来看，将日志记录到中央位置可以将这些日志条目的副本从源主机中移出。如果源主机受到攻击，这可以给你一个“更可信”的真相版本。在初始受损后，攻击者必须付出更多的努力来找到并攻击中央日志服务器。在很多情况下，这种延迟可以被用于你的优势，以识别并警告攻击已经发生。通常，防御都是关于延迟攻击者，并在此延迟期间向防御者提供尽可能多的细节。中央日志记录，以及对日志条目进行接近实时的分析或触发器，是这一点的一个很好的例子。

那么，在部署和使用中央日志记录时，我们应该考虑哪些设计和可用性考虑？

日志大小、轮换和数据库

你会注意到关于日志的第一件事是它们增长得非常快。如果你在防火墙上进行全面日志记录，即使在一个小组织中，这些日志也会很快增长到每天几 GB。再加上路由器、交换机、服务器以及这些服务器上的服务的日志，日志可能会变得非常复杂和难以搜索。

人们经常做的第一件事是分离日志。保留“全部日志”总是明智的，但将每个设备或服务日志的副本分开并分成单独的较小日志可能会很方便。虽然防火墙日志可能有几 GB 大小，但同一时期的路由器日志很可能只有几 KB 大小，通常是个位数。日志大小通常可以成为问题的指标 - 例如，如果你有一个典型每天 3-5KB 的日志，突然增长到每天 2-3MB，这通常表明出现了问题。或者，如果你有 15 个分支办公室应该是相同的，但其中一个路由器或防火墙日志的大小是其他的 3 倍或 10 倍，那也是一个很大的箭头指向“这里看看！”

通常，人们会采取混合方法 - 保留包含所有内容的单一日志，为所有内容保留单独的日志，然后合并那些不那么“啰嗦”的东西 - 例如，只删除防火墙日志以及 Linux 和 Hypervisor 主要 syslog 日志可以大大减少日志大小，但仍保留一个合理的合并日志文件。

所有这些都占用了磁盘空间，每次你以不同的方式切割数据，都很可能会大幅增加空间需求。要注意数据的整体大小和存储它的容量 - 你绝不希望处于攻击者可以填满日志容量的位置。这种情况可能会完全停止日志记录过程，因此你不知道攻击者去了哪里。它还可以覆盖事件的初始集，因此你不知道攻击者是如何首次立足的。在最坏的情况下，它可能两者兼而有之。

解决这个空间问题的一种方法是归档日志 - 保留 1-5-7-10 天的日志以便轻松搜索，但在那之后，可能会归档和压缩主要日志并删除其余部分。这可以保留传统的文本文件，以及传统的grep/cut/sort/uniq 搜索方法，但保持大小可管理。

更现代的方法可能是保留那个单一的“全部”日志文件，并进行定期的离线存储，这样可以轻松地保留几个月甚至几年的日志 - 根据你的政策、程序或合规要求。然后，你可以根据需要从这个中央位置重新转发流量到你的 SIEM。所有这些日志都可以使用命令行工具进行搜索。

对于日常故障排除，解析日志数据并将其存储在数据库中。这样可以实现更快的搜索，尤其是在应用了战略索引之后，还可以更轻松地管理数据的整体大小。这种方法的关键不是管理磁盘空间，而是（尽可能地）通过目标时间间隔来管理日志容量，以便实现可预测、可重复的故障排除和报告窗口。

让我们深入探讨如何在故障排除时逐步添加搜索项以找到最终答案。

日志分析 - 寻找“关键”

人们一旦将日志存储在磁盘上，面临的主要挑战是如何使用它们。特别是在故障排除或处理安全事件时，你知道日志中有很好的信息，但要知道在哪里搜索、如何搜索以及使用什么工具是一个艰巨的任务，如果你刚开始进行日志分析的话。

要查找的地方

通常，确定你正在寻找问题的 OSI 堆栈的哪个位置是有意义的。诸如重复的 IP 地址之类的问题是第 3 层的问题 - 你会在路由器或交换机日志中寻找它们。然而，同样的问题可能会从最终用户报告开始，他们声称“Web 服务器不稳定”，所以你可能会从 Web 服务器的应用程序日志开始 - 你可能需要一些时间来通过各种服务器和设备日志逐步解决这个问题，找到根本问题。最近的一个例子中，我与帮助台合作部署了一台新打印机，我不小心错误地在打印机配置中使用了 Web 服务器集群地址之一。

虽然在更大的日志中查找这些问题可能会更快，但在一个多 GB 的文本日志中搜索可能需要 5-10-15 分钟每次“尝试”，因为你需要交互式地得到最终的搜索词组。同样，在文本日志的情况下，你通常会从“最有可能的”日志开始搜索，而不是“在这里搜索，它包含所有内容”的日志。

既然我们正在寻找正确的地方，我们如何缩小所有这些日志条目以找到“答案”呢？

如何搜索

在大多数情况下，搜索日志将包括一系列“找到这个”和“排除那个”的子句。如果你在搜索文本日志，这通常是grep -i "包含文本"或grep -i -v "排除文本"。请注意，使用-i会使你的搜索不区分大小写。如果你按正确的顺序串联足够多的这些内容，通常就足够了。

然而，如果你想“计算”特定事件，uniq -c可能会有所帮助，它将计算唯一事件。然后，你可以使用sort -r将它们按降序排序。

例如，要查找到外部 DNS 服务器的 DNS 查询，你需要搜索防火墙日志。如果防火墙是 Cisco ASA，查询可能类似于这个序列：

我们的最终命令？让我们来看一下：

cat logfile.txt | grep –v  "a.a.a.a" | grep –v "b.b.b.b" | grep "/53 " | sed s/\t/" "/g | tr –s " " | cut -d " " -f 13 | sed s/:/" "/g | sed s/\//" "/g | cut -d " " -f 2 | sort | uniq –c | sort –r

这看起来很复杂，但请记住，这是迭代完成的 - 我们分别解决每个请求中的“子句”，然后按顺序将它们串联在一起。此外，在许多情况下，我们可能会花费几分钟甚至几个小时来完善一个查询，但然后在以后的几年中以自动化的方式使用该查询，所以这是值得花费的时间！

此外，虽然我们展示了使用 Linux 命令行文本处理命令进行查询，但相同的方法可以用于数据库日志存储库，甚至用于针对不同防火墙的查询。无论目标设备、日志存储库类型或我们要解决的问题是什么，方法通常是这样的：

• 使用一些广泛的查询或选择（包括或排除）来将数据减少到更可管理的量。

• 做任何必要的工作来处理数据，以便可以更具体地查询。

• 使用一些更具体的查询来进一步缩小范围。

• 如果我们正在寻找计数或最常见的事件，就要总结数据以匹配所需的内容。

• 测试最终的查询/选择标准。

• 将最终的搜索词组插入到所需的自动化中，以便以所需的频率对此信息进行总结或报告。

这涵盖了如何通过日志搜索过去的事件来诊断过去的问题，但我们不能使用日志立即告诉我们已知的问题何时发生吗？简短的答案是“是的，绝对可以”。让我们探讨一下这是如何做到的。

特定事件的警报

这是“寻找事物”对话的延伸 - 也许是“何时寻找”的话题。当然，找到问题的最佳时间是它发生的瞬间 - 或者甚至是在它发生之前，这样你就可以尽快修复它。

为此，通常会定义简单的文本字符串，这些字符串可能会指示问题并在发生时警报相关人员。您可能会在发生此类警报时发送电子邮件警报或短信，或者可能会收集一天的警报并发送每日摘要-您的方法可能取决于您的环境以及所见到的警报的严重程度。

搜索常见术语包括以下内容（几乎总是建议不区分大小写搜索）：

在所有这些情况下，您可能希望添加一个not子句来过滤可能正在浏览或搜索这些术语的用户-例如，“batter”将找到所有电池事件，但它也会找到搜索蛋糕食谱和棒球新闻故事的用户。如果从搜索术语中排除“http”，那通常会得到您所需的内容。

有了这些触发器，您可以在问题变成问题之前解决一堆问题-这总是一件好事。

现在我们已经讨论了搜索和触发器，让我们建立一个日志服务器并尝试这些方法！

Syslog 服务器示例-Syslog

要在 Linux 主机上运行基本的 syslog 服务，我们将配置rsyslog服务。默认情况下，此服务侦听端口514/udp，尽管端口和协议都是可配置的。

日志事件以各种优先级或严重级别出现，通常由发送设备设置：

• emerg, panic（紧急）-级别0：这是最低的日志级别。系统无法使用。通常这些是在系统崩溃之前您将看到的最后消息。

• alert（警报）：级别1：必须立即采取行动。这些通常会影响整个系统的操作。

• crit（临界）：级别2：与警报一样，必须立即采取行动。系统的主要功能可能无法正常运行。

• err（错误）：级别3：重要错误，但系统仍在运行。系统的主要功能可能受到影响。

• warn（警告）：级别4：警告条件。

• notice（通知）：级别5：正常但重要的条件。

• info（信息）：级别6：信息消息。

• debug（调试）：级别7：这是最高级别-调试级别消息。

通常，当您配置一个日志记录级别时，所有较低的日志记录级别都会包括在内。因此，如果您在主机上配置了级别 4 的 syslog，则也会包括 0、1、2 和 3。这就解释了为什么在大多数情况下，您只为任何给定的主机配置一个日志记录级别。

很可能rsyslog已经安装并在您的 Linux 主机上运行。让我们来检查一下：

~$ sudo systemctl status rsyslog
• rsyslog.service - System Logging Service
     Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor prese>
     Active: active (running) since Tue 2021-06-15 13:39:04 EDT; 11min ago
TriggeredBy: • syslog.socket
       Docs: man:rsyslogd(8)
             https://www.rsyslog.com/doc/
   Main PID: 783 (rsyslogd)
      Tasks: 4 (limit: 9334)
     Memory: 4.1M
     CGroup: /system.slice/rsyslog.service
             └─783 /usr/sbin/rsyslogd -n -iNONE
Jun 15 13:39:04 ubuntu systemd[1]: Starting System Logging Service...
Jun 15 13:39:04 ubuntu rsyslogd[783]: imuxsock: Acquired UNIX socket '/run/syst>
Jun 15 13:39:04 ubuntu rsyslogd[783]: rsyslogd's groupid changed to 110
Jun 15 13:39:04 ubuntu rsyslogd[783]: rsyslogd's userid changed to 104
Jun 15 13:39:04 ubuntu rsyslogd[783]: [origin software="rsyslogd" swVersion="8.>
Jun 15 13:39:04 ubuntu systemd[1]: Started System Logging Service.
Jun 15 13:39:05 ubuntu rsyslogd[783]: origin software="rsyslogd" swVersion="8.

如果您尚未安装此服务，只需运行以下命令即可：

$ sudo apt-get install rsyslog 

安装并运行服务后，让我们继续配置。编辑/etc/rsyslog.conf文件，确保您具有sudo权限进行此操作。

您会发现控制监听端口的行如下。取消注释 UDP 的行，如下所示（其中包含imudp的两行）。如果您还想在514/tcp上接受 syslog，请随时取消注释（这两个在此处都取消了注释）：

# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")

如果您想将 syslog 客户端限制为特定的子网或 DNS 域集，可以通过在此文件中添加AllowedSender行来实现，如下所示，在我们刚刚取消注释的“input”行之后（请务必根据您要添加此行的部分使用正确的协议）：

$AllowedSender UDP, 127.0.0.1, 192.168.0.0/16, *.coherentsecurity.com

接下来，我们将向下滚动到同一文件的“全局指令”部分。就在那一行之前，我们将添加一行作为“模板”，以命名传入的文件并标识它们的位置。我们可以使用几个以“％”分隔的变量，其中最常见的如下：

在我们的配置中，我们将使用主机 IP 作为文件名，然后按日期拆分日志：

$template remote-incoming-logs, "/var/log/%$year%-%$month%-%$day%/%FROMHOST-IP%.log"*.* ?remote-incoming-logs

使用以下命令检查文件语法：

$ rsyslogd -N 1
rsyslogd: version 8.2001.0, config validation run (level 1), master config /etc/rsyslog.confrsyslogd: End of config validation run. Bye.

可以用于模板化 syslog 文件的其他变量名称包括以下内容：

现在，保存文件并重新启动rsyslog服务：

$ sudo systemctl restart rsyslog

现在，我们只需要配置我们的各种服务器和设备，将日志转发到这台服务器，对吧？

有点像 - 这给我们带来的是一个非常昂贵（以磁盘空间计算）的日志堆。我们实际想要的是一种方法，从这些日志中实时获取一些警报。我们将使用一个名为tail命令的过程来实现这一点，该命令将使用以下命令将行回显到文本文件中：

tail –f < filename.txt

这会回显文本，但不会给我们任何警报。为此，我们必须安装一个名为swatch（用于“syslog watch”）的软件包：

Apt-get install swatch

安装完成后，我们将创建一个配置文件来告诉工具要查找什么。回顾我们的常见警报列表，像这样的swatch.conf文件可能是一个很好的开始：

watchfor /batter/i
echo red
mail=facilities@coherentsecurity.com, subject="ALERT: Battery Issue"
watchfor /temperature|fan|water/i
echo environmental
mail=rob@coherentsecurity.com, subject="ALERT: Environmental Alert"
watchfor /BGP/
echo routing_issue
mail=rob@coherentsecurity.com, subject="ALERT: Routing Issue"
watchfor /SEC_LOGIN_FAILED/
echo security_event
mail=rob@coherentsecurity.com, subject="ALERT: Administrative Login Failed"
continue
watchfor /SEC_LOGIN_FAILED/
threshold type=threshold,count=5,seconds=600
echo security_event
mail=rob@coherentsecurity.com, subject="ALERT: Possible Password Stuffing Attack in Progress"

这里有几点需要注意 - 我们要查找的文本在watchfor子句中。请注意，在每种情况下，被监视的文本都是“正则表达式”或regex。regex语法非常灵活，既可以非常简单（如前面所示），也可以非常复杂，难以理解。我在本章末尾包含了一些正则表达式参考资料。

在我们的示例中，第一个正则表达式以/I结尾，这告诉watchfor命令这是一个不区分大小写的搜索。请注意，这会消耗相当多的 CPU 资源，因此如果您知道匹配文本的大小写，最好将其正确地放入正则表达式中。

在第二个子句中，请注意我们有三个不同的搜索项，用|字符分隔，这是一个逻辑或 - 换句话说，“温度”或“风扇”或“水”。

最后两个示例是相关的。第一个示例查找失败的登录并为每个登录提供警报。但然后它有一个continue命令，告诉 swatch 继续。下一个子句匹配相同的文本，但有一个阈值 - 如果 swatch 在 5 分钟内看到五次失败的登录尝试，它将识别可能的密码填充攻击。

您还可以使用exec命令而不是mail来触发匹配的日志语句执行脚本。

最后，我们将要开始样本过程：

$swatchdog –c /path/swatch.conf –t /path/logfile.log

这个命令提出了两个观点：

• 我们已经提到日志大小是一个问题，因此我们存储日志的当前路径不应该与/var/log在同一个分区中，后者仅用于本地日志。它绝对不应该与引导或任何其他系统分区在同一个分区中。填满 syslog 分区将导致日志丢失，还可能导致服务器崩溃或无法引导！我们希望我们的日志在一个单独的、专用的分区中，大小合适以存储我们需要的内容。归档日志可以在同一个分区中，也可以在第二个分区中，专门用于存档（很可能是 ZIP 压缩）日志。

• 我们为rsyslog配置的当前配置需要 sudo 权限来查看日志。因此，我们要么需要修改文件和目录权限，要么需要使用 sudo 运行我们的swatchdog。这两种方法都带有一定程度的风险，但为了便于使用日志进行故障排除，让我们更改文件权限。这可以在/etc/rsyslog.conf文件中通过修改这些行来完成：

$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
*.*
$DirCreateMode 0755
*.*
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup syslog

在大多数情况下，您可以将FileGroup命令更改为不同的组，并将各种管理员放入该组，以及您从中运行“swatch”设置的任何帐户。

或者，您可以更改文件和目录CreateMode行，甚至包括"everyone"，使用0777。由于日志条目始终包含敏感信息，我不建议这样做 - 作为一名渗透测试人员，发现密码在日志文件中是相当常见的 - 令人惊讶的是，人们经常在userid字段中输入密码，然后再次尝试正确的信息！

您仍然可以在目录名称中使用日期，但通常，保持一致的文件和目录名称对于实时文件更容易。这使得日志监控工具和解决问题的人更容易找到“今天”。在您的归档脚本中使用日期值意味着历史日志文件将位于“日期”目录中或具有“日期”ZIP 文件名。

话虽如此，我们修改后的 swatch 命令将类似于以下内容：

$swatchdog –c /path/swatch.conf –t /path/logfile.log --daemon

请注意，我们在命令中添加了-d - 一旦一切都调试和正常工作，您将希望在后台运行该命令（作为守护进程）。

您可能需要做更多的工作才能使 swatch 在生产中运行 - 例如，为您的环境获得那些权限，检查您的网络清单，并确保您的所有设备都有中央日志记录，调整日志分区大小，并使日志轮换工作。我们已经涵盖的内容应该足以让您上路，尽管这些其他工作大部分将是针对您的环境的。

在我们组织的日志得到覆盖后，现在出现了其他问题：我们的事件如何与其他组织相比？我们是否看到与其他人相同的攻击，或者我们可能是特定事物的目标？我们如何获得这些信息？我们将在下一节中讨论这个问题。

Dshield 项目

Dshield 项目由互联网风暴中心（isc.sans.edu）的人员维护，允许参与者将他们的（匿名化的）日志转发到一个中央存储库，这些日志被聚合起来，以提供一个关于“互联网上发生了什么”的良好图景。

具体来说，转发的信息是由您的防火墙阻止的连接尝试。如果您不想使用实际的防火墙日志，还可以使用专用的 Dshield 传感器。参与说明可以在这里找到：isc.sans.edu/howto.html。

这些聚合数据让我们了解恶意行为者正在寻找哪些端口，以便利用它们。参与者的地址是匿名化的信息。各种高级报告可以在这里查看：isc.sans.edu/reports.html。

特别是，您可以深入研究该页面上的任何“前 10 个端口”，以查看最受欢迎的端口上随时间的活动。例如，您可以转到isc.sans.edu/port.html?port=2222，如下图所示：

图 12.1 - 一个端口的 Dshield 数据

通过这种模式，您可以看到如何查询任何端口，如果您有特定的流量需要进行取证。

此外，如果您更愿意使用脚本或应用程序来消耗这些聚合信息，这些信息也可以通过 API 查询。 Dshield API 的文档在这里：isc.sans.edu/api/。

例如，要收集端口2222的摘要信息，我们可以使用curl（只是一个例子）：

$ curl –s –insecure https://isc.sans.edu/api/port/2222 | grep –v encoding\= | xmllint –format –
<?xml version="1.0"?>
<port>
  <number>2222</number>
  <data>
    <date>2021-06-24</date>
    <records>122822</records>
    <targets>715</targets>
    <sources>3004</sources>
    <tcp>100</tcp>
    <udp>0</udp>
    <datein>2021-06-24</datein>
    <portin>2222</portin>
  </data>
  <services>
    <udp>
      <service>rockwell-csp2</service>
      <name>Rockwell CSP2</name>
    </udp>
    <tcp>
      <service>AMD</service>
      <name><![CDATA[[trojan] Rootshell left by AMD exploit]]></name>
    </tcp>
  </services>
</port>

因为在此示例中返回的数据是 XML 格式，所以您可以使用标准库或语言组件来消耗它。您还可以将返回的格式更改为 JSON、文本或 PHP。在某些情况下，数据适合逗号或制表符分隔的格式（CSV、制表符）。

要更改格式，只需将?format_type添加到查询中，其中format_type可以是 JSON、文本、PHP，或者在某些情况下可以是 CSV 或制表符。

每个用户都有自己的网络门户，显示他们自己设备的相同统计数据 - 这些数据在故障排除时可能很有价值，或者与聚合数据进行对比，以查看您的组织是否可能受到攻击。但这种方法的强大之处在于聚合数据，它可以很好地反映特定日期的互联网“天气”情况，以及整体“气候”趋势。

现在我们已经配置了本地日志记录，并将我们的防火墙日志聚合以进行更好的互联网流量分析，让我们考虑其他网络管理协议和方法，首先是简单网络管理协议（SNMP）管理/性能和正常运行时间。

使用 SNMP 进行网络设备管理

在本质上，SNMP 是从目标网络设备收集信息的一种方式。通常，这是通过基于服务器的应用程序完成的，但您当然也可以从命令行查询 SNMP。目前有几个版本的 SNMP，其中有两个是常用的。

SNMPv2c（第 2c 版）是对初始 v1 协议的轻微改进，但仍然是一种“老派”数据收集方法 - SNMP 查询和响应都是通过 UDP 以明文传输的。它使用密码短语（称为社区字符串）进行安全保护，但这也是以明文发送的，因此工具如 Ettercap 可以轻松收集这些信息 - 即使通常建议使用“长且复杂”的字符串，也无法保护您，如果攻击者可以轻松地复制并重用它们。此外，默认的社区字符串（只读访问为 public，读写访问为 private）通常保持不变，因此只需使用这些字符串进行查询，通常就可以为攻击者带来良好的结果。通常建议在目标设备上使用 ACL 来保护对 SNMP 的访问。但是，考虑到进行 ARP 欺骗攻击的简单性，位置良好的攻击者也可以轻松绕过这些 ACL。

SNMPv3 是该协议的最新版本，增加了一个非常受欢迎的加密功能。与 SNMPv2c 提供的“只读或读/写”访问控制相比，它还具有更加细致的访问控制方法。

正如我们之前提到的，SNMP（任一版本）可用于向目标设备“轮询”信息。此外，该设备可以向 SNMP 服务器或日志收集器发送未经请求的 SNMP“陷阱”。SNMP 轮询使用161/udp，而 SNMP 陷阱发送到162/udp（尽管可以配置为使用 TCP）。

在涵盖了一些背景知识之后，让我们来做一些示例查询。

基本的 SNMP 查询

在 Linux 中进行命令行查询之前，您可能需要安装snmp软件包：

$ sudo apt-get install snmp

现在，我们可以进行一个示例查询。在我们的第一个示例中，我正在收集实验室交换机的 IOS 版本：

$ snmpget –v2c –c <snmpstring> 192.168.122.7 1.3.6.1.2.1.1.1.0
iso.3.6.1.2.1.1.1.0 = STRING: "SG550XG-8F8T 16-Port 10G Stackable Managed Switch"

要收集系统正常运行时间，以秒和人类可读的时间戳，使用以下命令：

$ snmpget -v2c -c <snmpstring> 192.168.122.7 1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timeticks: (1846451800) 213 days, 17:01:58.00

接口的统计数据呢？让我们从名称开始：

snmpget -v2c -c <snmpstring> 192.168.122.7 .1.3.6.1.2.1.2.2.1.2.2
iso.3.6.1.2.1.2.2.1.2.2 = STRING: "TenGigabitEthernet1/0/2"

然后，我们可以获取进出的数据包（单播）：

$ snmpget -v2c -c <snmpstring> 192.168.122.7 .1.3.6.1.2.1.2.2.1.11.2
iso.3.6.1.2.1.2.2.1.11.2 = Counter32: 4336153
$ snmpget -v2c -c public 192.168.122.7 .1.3.6.1.2.1.2.2.1.17.2
iso.3.6.1.2.1.2.2.1.17.2 = Counter32: 5940727

您明白了吧 - 几乎每个常见参数都有一个 OID。但我们如何保持这些参数的清晰？

首先，这是在 RFC 1213 中标准化的，MIB-2 是大多数供应商支持的最新一组定义，作为“最低公共分母”实现。其次，该定义是分层的。这显示了基本树的“顶部”，其中突出显示了mib-2的 OID：

图 12.2 - SNMP OID 树，显示 mib-2

当有一组接口时，将会有一个计数，然后是每个接口统计的表（按接口索引）。如果使用snmpwalk而不是snmpget，您可以收集整个列表，以及每个条目的所有子参数。这显示了 mib-2 的ifTable（接口表）部分的开头：

图 12.3 - SNMP OID 树，显示接口信息（ifTable）

此外，他们维护了每个供应商的 OID 起始点列表，每个供应商都有其自定义的项目树。 OID 树的private分支的顶部显示在此处。请注意，在树的顶部，您往往会发现一些可能已被收购或由于某种原因在企业环境中不再常见的组织：

图 12.4 - SNMP OID 树，显示供应商 OID 部分

这个模型或多或少地很好地结合在一起，各种设备维护着它们的各种计数器，等待一个有效的服务器来查询这些值。

如果您有一个起点，您可以使用snmpwalk命令遍历从该点向下的 OID 树（请参阅SNMPv3部分以获取示例）。不用说，这可能会变成一个混乱的业务，“找到我真正想要的数字”，分散在数百行文本中。

此外，正如您所看到的，SNMP 树中的每个“节点”都有名称。如果您有适当的定义，您可以按名称而不是 OID 进行查询。您可能已经在 Linux 主机上安装了 MIB-2 定义，因此您也可以导入和管理供应商的 MIB 定义。安装或管理各种 MIB 定义的简单方法是使用snmp-mibs-downloader软件包（使用我们熟悉的apt-get install方法安装此软件包）。

要安装供应商的 MIB，我们可以使用 Cisco（作为示例）。安装snmp-mibs-downloader后，编辑/etc/snmp-mibs-downloader/snmp-mibs-downloader.conf文件，并将cisco指示符添加到AUTOLOAD行。现在这行应该是这样的：

AUTOLOAD="rfc ianarfc iana cisco"

cisco MIB 的收集位置和方式的定义在/etc/snmp-mibs-downloader/cisco.conf中：

# Configuarions for Cisco v2 MIBs download from cisco.com
#
HOST=ftp://ftp.cisco.com
ARCHIVE=v2.tar.gz
ARCHTYPE=tgz
ARCHDIR=auto/mibs/v2
DIR=pub/mibs/v2/
CONF=ciscolist
DEST=cisco

各个 MIB 定义在/etc/snmp-mibs-downloader/ciscolist中 - 正如您所看到的，这个文件太长了，无法在这里列出：

# cat :/etc/snmp-mibs-downloaderciscolist | wc -l
1431

更新了snmp-mibs-downloader.conf文件后，只需运行以下命令：

# sudo download-mibs

您将看到每个 MIB 文件都被下载（共 1,431 个文件）。

现在加载了 MIB 文本描述（默认在安装snmp-mibs-downloader后加载），您现在可以使用文本描述查询 SNMP - 在这种情况下，我们将查询实验交换机的sysDescr（系统描述）字段：

snmpget -Os -c <snmpstring> -v2c   192.168.122.5 SNMPv2-MIB::sysDescr.0
sysDescr.0 = STRING: SG300-28 28-Port Gigabit Managed Switch

即使使用描述性字段名称，这个过程也会非常快速地变得非常复杂 - 这就是网络管理系统（NMS）的用武之地。大多数 NMS 系统都有一个点对点的 Web 界面，您可以从 IP 开始，然后通过接口或其他统计数据深入查询所需的信息。然后以图形方式呈现这些信息，通常随着时间的推移。大多数更好的 NMS 系统将弄清楚设备是什么，并创建您通常想要的所有图表，而无需进一步提示。

这是哪里出了问题？

SNMPv2 的明文性质是一个持续的问题 - 许多组织简单地没有转向更安全的传输 SNMPv3。

更糟糕的是，许多组织仍然继续使用默认的 SNMP 社区字符串；也就是说，“public”和“private”。在几乎所有情况下，没有必要对 SNMP 进行读写访问，但人们还是进行了配置。这种情况变得更糟糕的是，不仅可以通过读/写访问关闭接口或重新启动设备，而且还可以通过该访问通常检索完整的设备配置 - 甚至有一个 nmap 脚本来检索 Cisco IOS 运行配置。

在操作上，如果您查询设备上的每个接口和统计信息，通常会影响该设备的 CPU。从历史上看，特别是在交换机上，如果您查询每个接口，您将（在操作系统的某个版本上）发现内存泄漏错误。这些错误可能非常严重，以至于您可以绘制内存利用率并看到这些查询不返回几个字节的情况下直线增加，最终导致设备没有足够的内存运行。

因此，这些是明显的建议。使用 SNMPv3，限制对已知服务器的 SNMP 访问，并仅查询您需要的接口。在防火墙和路由器上，这可能包括所有接口，但在交换机上，您通常只查询上行链路和关键服务器的接口 - 特别是虚拟化程序。

有了一些理论知识，让我们来构建一个流行的基于 Linux 的 NMS - LibreNMS。

SNMP NMS 部署示例 - LibreNMS

LibreNMS 是一个从 Nagios NMS 分叉出来的 NMS（现在主要是商业产品），对于一个免费的 NMS 应用来说，它相当全面。更重要的是，将您的设备注册的学习曲线非常简单，安装也可以大大简化。

首先，LibreNMS 的安装文档非常完整，涵盖了各种数据库、网站和其他依赖组件。我们不会在这里涵盖这些说明，因为它们会随着版本的更改而改变；最好的来源是供应商下载页面。

但与其从头开始安装，通常更简单的方法是使用任何一个预安装的映像并从那里开始。VMware 和 Hyper-V 都是非常普遍的虚拟化程序，并且是许多企业的主要计算平台。对于这些，LibreNMS 在预打包的Open Virtualization Format（OVA）文件中有一个完整的 Ubuntu 安装。实际上，正如其名称所示，该文件类型几乎普遍支持部署预构建的 VM 映像。

在本章的示例中，您可以下载并导入 LibreNMS 的 OVA 文件。您要查询的设备可能与示例中的不同，这取决于您的环境中有什么，但核心概念将保持不变。部署 NMS 的一个很大的副作用是，就像日志和日志警报一样，您可能会发现您不知道的问题 - 从过热的 CPU 到接口以最大或“接近最大”容量运行的一切问题。

虚拟化程序的具体信息

确保您部署 LibreNMS VM 的网络可以访问您将要监视的设备。

在 VMware 中，该 VM 的默认磁盘格式为“thin provisioned”。这意味着虚拟磁盘将从足够容纳其上的文件的大小开始，并且随着文件存储的需求增加而增长。这对于实验/测试 VM 来说是可以的，但在生产中，您几乎总是希望有一个“thick provisioned”磁盘 - 您不希望服务器意外“增长”并耗尽存储空间。这永远不会有好结果，特别是如果您在同一数据存储中有多个 thin-provisioned 服务器！

部署后，您需要使用librenms帐户登录 - 该密码会随着版本的更改而更改，因此请务必参考您下载的文档。登录后，请注意该帐户具有 root 权限，因此请使用passwd命令更改librenms的密码。

使用ip address命令获取当前 IP 地址（参见第二章，基本 Linux 网络配置和操作 - 使用本地接口）。考虑到这台主机将使用 SNMP 监视关键设备，并且您可能希望为这些设备中的每一个添加 ACL 以限制对 SNMP 的访问 - 鉴于您可能希望手动设置 IP 地址、子网掩码、网关和 DNS 服务器为静态值。您可以使用静态 DHCP 预留或者在服务器上静态分配它 - 选择您组织的标准方法。

完成后，使用 HTTP 而不是 HTTPS 浏览到该地址。考虑到该服务器上的信息的敏感性，我建议安装证书并强制使用 HTTPS，但我们不会在本章中涵盖这一点（尽管 LibreNMS 文档在这方面做得很好）。Web 登录也是librenms，但是默认密码将不同；同样，请查阅您下载的文档。

现在您应该看到一个编辑仪表板的启动屏幕：

图 12.5 - LibreNMS 编辑仪表板启动屏幕

在继续之前，请点击屏幕右上角的librenms账户图标：

图 12.6 - LibreNMS“账户”和“系统”图标

然后，也更新 Web 账户的密码：

图 12.7 - 在 LibreNMS 中更改默认密码

服务器已经运行起来了，让我们来看看如何添加一些设备进行管理。

设置基本的 SNMPv2 设备

要添加最基本的设备，您需要转到该设备。您需要启用 SNMP（在本例中是第 2 版），然后添加一个社区字符串，希望还添加一个 ACL 来限制访问。例如，在典型的思科交换机上，会是这样的：

ip access-list standard ACL-SNMP
 permit 192.168.122.174
 deny   any log
snmp-server community ROSNMP RO ACL-SNMP

就是这样！请注意，我们在 SNMP 社区字符串中使用了ROSNMP - 这对于生产环境来说太简单了。另外，请注意RO参数确保该字符串只允许只读权限。

现在，在 LibreNMS 中，从主仪表板中选择设备 > 添加设备：

图 12.8 - 在 LibreNMS 中添加设备

填写您设备的 IP 地址，以及社区字符串。您的屏幕应该看起来像这样（当然要用您自己设备的 IP 地址）：

图 12.9 - 在 LibreNMS 中添加设备详细信息

现在，您可以通过选择设备 > 所有设备，然后点击您的设备来浏览刚刚添加的设备。

请注意，LibreNMS 已经开始绘制 CPU 和内存利用率，以及每个已启用接口的流量。这里显示了网络设备（在本例中是防火墙）的默认页面：

图 12.10 - 在 LibreNMS 中收集的设备统计信息

当您深入了解任何特定的可点击链接或图表时，将显示有关收集统计信息的更多详细信息。通常，甚至将鼠标悬停在链接上也会显示详细信息 - 在这种情况下，将鼠标悬停在vmx0链接上，将显示有关该特定接口的详细信息：

图 12.11 - 在 LibreNMS 中悬停在接口上以获取接口详细信息

我们已经讨论过部署 SNMPv2 是有风险的，因为它是明文传输和简单认证。让我们通过改用 SNMPv3 来解决这个问题。

SNMPv3

配置 SNMP 版本 3 并不复杂。在大多数情况下，我们采用默认的“只读”SNMP 视图，只需添加用于身份验证的密码和加密密钥。在设备端，这是 Cisco IOS 配置的一个示例：

ip access-list standard ACL-SNMP
    permit 192.168.122.174
    deny   any log
snmp-server view ViewDefault iso included 
snmp-server group GrpMonitoring v3 priv read ViewDefault access ACL-SNMP
snmp-server user snmpadmin GrpMonitoring v3 auth sha AuthPass1 priv aes 128 somepassword

关键参数如下：

我们可以使用snmpwalk或snmpget命令进行测试。例如，snmpwalk命令提取系统描述值（请注意，我们将需要 ACL-SNMP 访问列表中的调用站点的 IP）：

$ snmpwalk -v3 -l authPriv -u snmpadmin -a SHA -A AuthPass1 -x AES -X somepassword 192.168.122.200:161 1.3.6.1.2.1.1.1.0
iso.3.6.1.2.1.1.1.0 = STRING: "Cisco IOS Software, CSR1000V Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.5(2)S, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Sun 22-Mar-15 01:36 by mcpre"

在 NMS 端，只需匹配我们在设备上使用的各种配置密码和参数即可：

图 12.12 - 使用 SNMPv3 将设备添加到 LibreNMS 库存中

注册后，我们可以通过编辑设备来修复设备名称，然后将设备名称更改为更容易记住的内容，并添加 IP 覆盖（NMS 将使用该 IP 进行访问）。当然，如果设备有 DNS 名称，那么使用其 FQDN 进行注册也可以。但是，如果您需要 NMS 进行故障排除时 DNS 可能不可用，依赖 DNS 可能会成为一个问题 - 实际上，您可能正在解决 DNS 问题！

图 12.13 - 在 LibreNMS 中更改设备名称并添加"覆盖 IP"

请注意，即使我们已经添加了真正的身份验证（在传输中使用哈希密码）和授权（通过添加授权到访问级别），以及对实际数据的加密，我们仍然添加了一个普通的访问列表来保护路由器上的 SNMP 服务。 "深度防御"的口头禅让我们认为，最好总是假设一个或多个保护层可能在某个时候被破坏，因此向任何目标服务添加更多的防御层将更好地保护它。

我们可以通过使用 SNMPv3 将其用于发送加密的 SNMP 陷阱消息来扩展 SNMPv3 的使用，以替换明文 syslog 日志记录。这在某种程度上使我们的日志服务变得复杂，但是非常值得！

SNMPv3 还提供了其他安全配置；您的平台的 CIS 基准通常是一个很好的参考。如果您只想深入了解，或者如果您的路由器或交换机没有基准或来自供应商的良好安全指导，那么 Cisco IOS 的 CIS 基准是一个很好的起点。

除了提供额外的保护之外，SNMP 版本 2 和 3 之间的基本 SNMP 功能几乎保持不变。一旦在 NMS 中注册，使用 SNMPv2 和 SNMPv3 的设备在系统中的操作或外观方式没有任何显着的不同。

现在我们正在使用 SNMP 监视所有各种网络连接的设备和服务器，我们可以使用 NMS 的轮询引擎添加警报以监视关闭的设备或服务吗？

警报

您将想要做的主要事情之一是添加一些警报以配合您的统计数据。例如，如果您转到警报 > 警报规则并单击从收集创建规则，您将看到此屏幕：

图 12.14 - LibreNMS 中的默认警报收集

让我们添加一个警报，当任何接口利用率超过 80%时触发。要查看默认收集中是否有类似的内容，请在搜索字段中键入utili - 随着您的输入，搜索结果将被缩小：

图 12.15 - 在 LibreNMS 中添加警报

选择规则；我们将得到一些选项：

图 12.16 - LibreNMS 中的警报规则选项

从顶部开始，您应该重命名规则。如果您决定导入默认规则集，您不希望因为尝试使用重复的规则名称而导致失败。通常，我会将自定义规则命名为以下划线字符开头；这可以确保它们在排序时始终位于规则列表的顶部。由于我们正在复制收集中的内容，我们也可以轻松地更改触发警报的百分比。

关于匹配设备、组和位置列表，情况变得棘手。目前，匹配列表中没有任何内容，除列表中的所有设备设置为关闭，因此此规则不会匹配任何内容。让我们选择我们的设备：

图 12.17-在 LibreNMS 中匹配设备和组的警报规则

现在，保存规则。是的，就是这么简单！

你是否注意到前面菜单中的组选择了吗？使用设备组是将一个规则分配给所有相似设备的好方法 - 例如，您可能对路由器或交换机端口设置不同的端口阈值。这是因为增加路由器的 WAN 链路速度可能需要几周的时间，而改变交换机端口可能只涉及将电缆从 1G 端口移动到 10G 端口（例如）。因此，在这种情况下，对所有路由器设置一个规则（可能为 60%），对所有交换机设置一个不同的规则（设置为更高的数字）是很有道理的。

探索规则 - 您会看到许多您可能想要启用的规则 - 用于设备或服务宕机的警报，CPU、内存或接口利用率，以及温度或风扇警报。其中一些警报依赖于 syslog - 是的，LibreNMS 确实内置了一个 syslog 服务器。您可以在概述 > Syslog中探索这一点：

图 12.18-在 LibreNMS 中的 Syslog 显示

请注意，您可以进行一些简单的搜索，但这相当简单。这个 syslog 服务器是一个很好的东西，可以用来监视警报 - 这将比我们在本章早些时候设置的警报简单得多。但是，您仍然希望保留我们设置的文本日志，既可以进行更好的搜索，也可以进行长期存储。

当我们向我们的 NMS 添加设备，或者说当我们部署设备并对其进行命名时，有一些事情我们应该牢记。

在添加设备时要牢记的一些事情

在添加设备和组时，请务必对其进行命名，特别是设备，以便它们可以逻辑排序。命名约定通常会使用设备类型（例如 FW、SW 或 RT）、位置名称的标准（例如分公司编号）或城市名称的简称（例如 CHI、TOR 和 NYC 代表芝加哥、多伦多和纽约市）。重要的是要保持一致性，规划如何对事物进行排序，并保持名称中各种术语的简短 - 记住，您将要输入这些内容，它们最终也会出现在电子表格列中。

到目前为止，我们已经专注于使用 SNMP 来监视统计信息。现在，让我们监视设备上运行的服务。

监视服务

请记住，主机上的服务是需要监视的关键事项。通常会使用 NMS 中类似 nmap 的功能来监视数据库访问、API 和 Web 和 VPN 服务的端口。更高级的监视器将轮询服务并确保从轮询返回的数据是正确的。

在我们监视服务之前，我们需要启用服务检查。SSH 到您的 LibreNMS 主机并编辑/opt/librenms/config.php文件。添加以下行：

$config['show _services']             =1;

您可能还希望取消注释这些$config行中的一些或全部内容（以便您可以扫描子网，而不是一次添加一个设备）：

### List of RFC1918 networks to allow scanning-based discovery
#$config['nets'][] = "10.0.0.0/8";
#$config['nets'][] = "172.16.0.0/12";
$config['nets'][] = "192.168.0.0/16";

现在，我们将通过向/etc/cron.d/librenms文件添加以下行来更新应用程序的 cron 调度程序：

*/5  *    * * *   librenms    /opt/librenms/services-wrapper.py 1

默认情况下，并非所有插件都已安装——事实上，在我的安装中，没有一个插件被安装。像这样安装它们：

apt-get install nagios-plugins nagios-plugins-extra

现在，我们应该能够添加一个服务。选择22）：

图 12.19–LibreNMS 中监控基本服务

你可以扩展这一点——你是否注意到当你添加第一个服务时，列表中有多少服务检查？让我们为 HTTP 服务添加一个监视器。在这种情况下，我们将在我们的防火墙上观察它。这对于监视 SSL VPN 服务也很方便：

图 12.20–使用参数在 LibreNMS 中监控 HTTPS 服务

请注意，这里的参数很重要。-S表示检查应该使用 SSL（或更具体地说是 TLS）。–p 443表示轮询的端口。

现在，当我们导航到服务页面时，我们将看到我们刚刚添加的两个服务。你可能需要给 LibreNMS 一些时间来轮询它们：

图 12.21–LibreNMS 中的服务显示

可以直接从服务配置页面的下拉菜单中查看所有可用插件的完整列表：

图 12.22–LibreNMS 中可用的服务检查

一些常用的检查包括以下内容：

所有这些检查的参数文档位于www.monitoring-plugins.org/doc/man/index.html。

这大致涵盖了 LibreNMS 系统的基本操作。现在，让我们继续收集和分析流量。我们不会使用数据包捕获，而是使用 NetFlow 协议系列将高级流量信息聚合成“流”。

在 Linux 上收集 NetFlow 数据

当查看接口吞吐量不够时，你该怎么办？很多时候，那些 SNMP 吞吐量图表会告诉你有问题，但不会带你迈出下一步——是哪种协议或哪些人在消耗所有的带宽？这是我可以通过配置解决的问题，还是我需要制定政策来帮助控制组织中人们的视频习惯，还是我真的需要更多的带宽？

我们如何获得这些信息？这并不像 SNMP 那样容易，但 NetFlow 收集了你可能需要的所有信息，以帮助成为“带宽侦探”。让我们讨论一下它是如何工作的，以及涉及哪些协议。

什么是 NetFlow 及其“表兄弟”SFLOW、J-Flow 和 IPFIX？

如果你回忆一下第三章，使用 Linux 和 Linux 工具进行网络诊断，以及第十一章，Linux 中的数据包捕获和分析，我们在那里讨论了数据包“元组”，这就是我们将那个概念用于几乎所有事情的地方。NetFlow 是一项服务，它从已识别的接口（通常是路由器、交换机或防火墙）收集流量并对其进行汇总。它几乎总是包括我们在本书前面讨论过的核心元组值的信息：

• 源 IP

• 目标 IP

• 协议（TCP、UDP、ICMP 或其他协议）

• 源端口

• 目标端口

然而，正如我们将在后面看到的，现代 NetFlow 配置可以通过添加以下内容来扩展标准元组值：

• QOS 信息（TOS 或 DSCP 位）

• BGP 自治系统（AS）号码

• TCP 标志（SYN，ACK 等）

TCP 标志是至关重要的，因为第一个数据包（只设置了 SYN 标志）定义了在任何对话中哪个主机是客户端，哪个是服务器。

NetFlow 最初由思科开发，但在 RFC 过程下进行了开发，以允许行业更广泛地采用，除了思科之外，许多供应商也支持 NetFlow。NetFlow 有两个常见的版本-5 和 9-主要区别在于支持的字段数量。经常见到一些“表兄弟”协议：

• sFlow 由 InMon 开发为开放标准，并有支持 RFC。通常会看到支持 NetFlow 和 sFlow 的网络设备。

• IPFIX（IP 流信息导出）是另一个开放标准，它建立在 NetFlow v9 的基础上，几乎是 NetFlow v9 的超集。

• J-Flow 是 Juniper 设备的 NetFlow 等效物，尽管在其最新版本（J-Flow v9）中，它似乎与 IPFIX 相同，并且在 Juniper 的设备特定文档中是这样记录的。

无论您使用哪种协议来导出流信息，接收此信息的系统通常会接收任何或所有这些信息。导出通常在 UDP 端口上进行。虽然在某些情况下，端口将在规范中定义，但它总是可以更改，并且通常会因供应商而异。例如，NetFlow 通常出现在端口2055、2056、4432、9995或9996上。sFlow 正式定义为端口6343，但通常部署在其他端口上。IPFIX 目前并不常见（除了作为 J-Flow v9），但被指定为4739端口。

虽然有一些细微差别（特别是 sFlow 在数据收集和汇总方面有一些差异），但结果是相同的。在被汇总后，数据被发送到后端服务器，可以进行查询。在这些数据存储库中，网络管理员寻找与警察侦探相同的事物：

• 谁发送了数据，发送到哪里？（源和目的地 IP）

• 数据是什么（源和特别是目的地端口）

• 它是何时发送的？

• 通常通过定义用于发送数据的应用程序来推断原因-思科的基于网络的应用程序识别（NBAR）附加组件在这方面可能有所帮助，或者您通常可以从目的地端口（在流的服务器端）推断应用程序。

• 每个时间间隔发送了多少数据。

让我们深入了解一下收集、汇总和发送流量数据的工作方式，以及这可能如何影响您在组织网络中的设计和实施。

流量收集实施概念

所有这些流量收集协议中的一个关键概念是抽样。所有这些协议在其配置中都具有“每 y 个数据包抽样 x 个数据包”的属性，各种供应商和平台具有不同的默认值。例如，较新的路由器通常会将默认采样率设置为 100％，因为它们通常是较低带宽平台（通常低于 100 Mbps），并且具有 CPU 来支持该收集速率。在 1G、10G 或更快的交换机上，这种速率通常不实用-在这些情况下，以合理的速率进行抽样变得至关重要。

在实施方面，选择接口也很关键。与 SNMP 一样，在大型交换机的所有端口上收集流量信息可能会严重影响交换机的 CPU（以及其整体吞吐量）。不过，您的情况可能有所不同，因为高端交换机通常会将遥测功能卸载到专用硅上，以减少主机机箱 CPU 的使用。

选择收集拓扑结构也很重要。例如，在数据中心/总部/分公司的情况下，如果大部分流量是“中心和辐射”（即，分公司之间的通信很少），您可能只会在中心位置收集流量数据，并将流量收集器放在同一中心位置。在这种情况下，分公司流量简单地是总部流量的倒数，因此第二次发送该流量，通过您为带宽付费的 WAN，通常是不明智的。

唯一的例外是 VoIP。如果您回忆一下第十一章《Linux 中的数据包捕获和分析》，呼叫设置使用 SIP 协议，位于电话机和 PBX 之间。但呼叫本身使用 RTP，直接从一个电话机到另一个电话机。如果分支之间的 VoIP 通信量很大，您可能还会选择监视分支路由器的 WAN 接口。

最后，请记住，虽然这些数据是抽样和聚合的，但最终它们会到达服务器并且必须存储在磁盘上，这往往会很快积累起来。您可能会发现，随着您在保留多少信息以创建有意义的报告方面的“摸索”，您可能需要经常增加您的分区或数据库大小（不幸的是，总是增加）。

同样地，随着数据量的增长，对内存和 CPU 的需求也会增加。您可能会发现，在数据库中偶尔添加索引可以加快报告或 Web 界面本身的速度。不幸的是，添加索引通常会增加额外的磁盘和内存需求，所以也要记住这一点。随着您深入研究这一需求的过程，您会发现您的数据库管理技能会随着时间的推移而增长，并且最终可能会帮助您优化其他以数据库为中心的应用程序。

总是会有一种诱惑，即将 syslog、SNMP 和流量收集合并到一个单一的网络管理服务器上。虽然合并 syslog 和 SNMP 是一件常见的事情，但如果 NMS 使用数据库来记录信息，您可能会希望有一个单独的基于文本的日志存储库，这样可以使您的长期日志存储过程变得简单。关于流量收集，您几乎总是会将其放在一个单独的服务器上。在较小的环境中，您可能会采用“一体化”方法，但即使在许多小型环境中，您会发现流量收集的资源远远超过其他两个功能。此外，对后端数据库的依赖和入站数据的高速率意味着这可能会使您的流量收集服务器异常“脆弱” - 您可能会发现您需要每年一两次重建此服务器以解决“无法解释”的问题。此外，由于这个原因，您会发现组织普遍会在发生这种情况时切换到不同的应用程序或数据库平台（除非涉及商业许可），只是因为到那时，他们会知道他们不喜欢以前的构建，而且由于有了重建，测试下一个解决方案的门槛很低。

在涵盖了所有这些基本流信息之后，让我们为真实情况构建一个 NetFlow 解决方案，从一个典型的路由器开始。

配置路由器或交换机进行流量收集

首先，我们将定义我们要收集的内容。首先，我们想要我们的标准元组信息 - 源和目的 IP、协议和端口信息。我们还将添加 QoS 信息（ipv4 tos行），以及方向和路由信息（如果可能的话，as信息是 BGP 自治系统信息）。在这个定义中，我们还有应用程序名称。这主要是用于如果您还在运行 Cisco 的 NBAR 附加组件。NBAR 设置在接口上（您将在下一页看到），并帮助通过其组成的网络流量识别应用程序的名称。

flow record FLOW-RECORD-01
  match ipv4 tos
  match ipv4 protocol
  match ipv4 source address
  match ipv4 destination address
  match transport source-port
  match transport destination-port
  match application name
  match flow direction
  match interface input
  match interface output
  collect routing source as
  collect routing destination as
  collect transport tcp flags
  collect counter bytes
  collect counter packets

接下来，我们将定义流出口。这告诉系统从哪里发送流信息以及从哪个接口发送。流源很重要，因为如果发生变化，它将看起来像 NetFlow 服务器上的另一个设备。还要注意，我们在此部分中定义了一个接口表，它将发送足够的接口信息以帮助定义服务器上的主机和接口特性。请注意，流目的地端口几乎总是 UDP，但端口号没有标准化。供应商通常有自己的默认值，并且在我看到的所有实现中，该端口号是可配置的：

flow exporter FLOW-EXPORT-01
  destination 10.17.33.187
  source GigabitEthernet0/0/0
  transport udp 9996
  template data timeout 120
  option interface-table
  option exporter-stats timeout 120
  option application-table timeout 120

如您在定义中所见，流量监视器将出口和流记录绑定在一起，以便可以将其作为一个“整体”应用于接口：

flow monitor FLOW-MONITOR-01
  exporter FLOW-EXPORT-01
  cache timeout active 60
  record FLOW-RECORD-01

在接口上，您将看到我们定义了一个既入站又出站的流量监视器。请注意，您可以定义多个记录器和监视器。通常，只有一个流出口（因为通常对于任何给定的设备，只有一个流目的地）：

带宽语句通常用于帮助定义 OSPF 或 EIGRP 路由协议中的路由器指标。在流量收集的情况下，定义带宽通常会自动配置各种流图的每个接口的总带宽。定义每个物理接口的总带宽是关键的，这样每个图表都有准确的上限，并且随后将显示聚合和特定元组统计的准确百分比：

Interface Gigabit 0/0/1
  bandwidth 100000
  ip nbar protocol-discovery
  ip flow monitor FLOW-MONITOR-01 input
  ip flow monitor FLOW-MONITOR-01 output

第 2 层流量收集-例如，在单个交换机端口上-通常要简单得多。例如，在 HP 交换机上，在一个交换机端口上收集 sFlow 数据可能看起来像以下示例。

请注意端口号为6343。与 NetFlow 相比，sFlow 将6343/udp分配为其默认端口。当然，客户端和服务器端都可以配置为其他值：

sflow 1 destination 10.100.64.135 6343
interface <x>
 sflow 1 sampling 23 50
 sflow 1 polling 23 20
interface <y>
 sflow 1 sampling 23 50
 sflow 1 polling 23 20

请注意定义的采样率和轮询间隔。还要注意，由于在这种情况下在第 2 层收集流量数据，因此您的元组可能会受到限制，这取决于交换机型号。这也有助于解释为什么配置要简单得多-除非交换机解构采样帧以获取每个数据包的 L3/L4 信息，否则要收集的信息就会更少。

构建了路由器配置后，让我们继续构建和配置此方程式的服务器端。

使用 NFDump 和 NFSen 的示例 NetFlow 服务器

NFDump 和NetFlow Sensor（NFSen）是流量收集世界的良好入门级工具。特别有趣的是，NFDump 使用自己的文件格式，并且命令行工具在操作上与 tcpdump 非常相似（我们在第十一章中介绍了 Linux 中的数据包捕获和分析）。因此，如果您喜欢我们在该章节中的过滤讨论和示例，那么使用 NFDump 工具进行“top n”类型的统计和报告将非常合适！

NFCapd 是一个流量收集器应用程序。我们将在前台和后台运行它。

NFSen 是 NFDump 的简单 Web 前端。

我们将在独立的 Linux 主机上运行此操作；您可以使用我们在整本书中一直在使用的 Ubuntu VM 或物理主机。让我们首先安装nfdump软件包（这将为我们提供几个与 NetFlow 相关的命令）：

$ sudo apt-get install nfdump

现在，编辑/etc/nfdump/.default.conf文件并更改顶部的options行：

options='-l /var/cache/nfdump/live/source1 -S 1 -p 2055'

这将把数据放在我们的 NFSen 服务器稍后期望的位置。-S参数告诉 NFCapd 进程（我们将作为守护进程运行）将日期戳附加到路径上。因此，对于 2021 年 6 月 23 日，我们捕获的所有 NetFlow 数据将在目录中：

/var/cache/nfdump/live/source1/2021/06/23

正如您所期望的那样，这些数据往往会迅速积累，这可能会有风险，因为/var也是存储日志和其他重要系统数据的地方。在生产中，我建议您为此单独设置一个分区，并将路径的根目录设置为不同的内容，也许是/netflow。这样，如果您的 NetFlow 容量填满，其他系统服务不会直接受到影响。

-p参数定义了我们的nfcapd进程将监听的端口-默认的2055在大多数情况下应该很好用，但根据需要进行更改。

现在，我们可以开始将 NetFlow 流量定向到此收集器 IP，使用端口2055/udp。几分钟后，我们可以使用nfdump查看 NetFlow 数据。数据文件存储在/var/cache/nfdump/live/source1/中（从那里跟踪到今天的日期）。

让我们查看一个文件的前几行：

nfdump -r nfcapd.202106212124 | | head
Date first seen          Event  XEvent Proto      Src IP Addr:Port          Dst IP Addr:Port     X-Src IP Addr:Port        X-Dst IP Addr:Port   In Byte Out Byte
1970-01-01 00:00:00.000 INVALID  Ignore TCP     192.168.122.181:51702 ->     52.0                                      .134.204:443            0.0.0.0:0     ->          0.0.0.0:0           460                                              0
1970-01-01 00:00:00.000 INVALID  Ignore TCP      17.57.144.133:5223  ->  192.168                                      .122.140:63599          0.0.0.0:0     ->          0.0.0.0:0          5080                                              0

请注意，每行都换行了。让我们只看元组信息和每个样本间隔移动的数据量。我们将去掉列标题：

$ nfdump -r nfcapd.202106212124 | head | tr -s " " | cut -d " " -f 5,6,7,8,10,12,13 | grep –v Port
TCP 192.168.122.181:51702 -> 52.0.134.204:443 -> 460 0
TCP 17.57.144.133:5223 -> 192.168.122.140:63599 -> 5080 0
TCP 192.168.122.140:63599 -> 17.57.144.133:5223 -> 980 0
TCP 192.168.122.181:55679 -> 204.154.111.118:443 -> 6400 0
TCP 192.168.122.181:55080 -> 204.154.111.105:443 -> 920 0
TCP 192.168.122.151:51201 -> 151.101.126.73:443 -> 460 0
TCP 31.13.80.8:443 -> 192.168.122.151:59977 -> 14500 0
TCP 192.168.122.151:59977 -> 31.13.80.8:443 -> 980 0
TCP 104.124.10.25:443 -> 192.168.122.151:59976 -> 17450 0

现在，我们开始看起来像是信息了！让我们通过添加-b来聚合双向流量。我们还将从目录中可用的所有文件中读取。现在的列是Protocol，Src IP:Port，Dst IP:Port，Out Pkt，In Pkt，Out Byte，In Byte和Flows。请注意，在某些情况下，我们在该时间段有一个活动流，但没有数据进出：

$  nfdump -b -R /var/cache/nfdump | head | tr -s " " | cut -d " " -f 4,5,6,7,8,10,12,13 | grep -v Port
UDP 192.168.122.174:46053 <-> 192.168.122.5:161 0 0 1
TCP 52.21.117.50:443 <-> 99.254.226.217:44385 20 1120 2
TCP 172.217.1.3:443 <-> 99.254.226.217:18243 0 0 1
TCP 192.168.122.181:57664 <-> 204.154.111.113:443 0 0 1
TCP 192.168.122.201:27517 <-> 52.96.163.242:443 60 4980 4
UDP 8.8.8.8:53 <-> 192.168.122.151:64695 0 0 1
TCP 23.213.188.93:443 <-> 99.254.226.217:39845 0 0 1
TCP 18.214.243.14:443 <-> 192.168.122.151:60020 20 1040 2
TCP 40.100.163.178:443 <-> 99.254.226.217:58221 10 2280 2

让我们查看来自一个 IP 地址的流量：

$  nfdump -b -s ip:192.168.122.181 -R /var/cache/nfdump | grep -v 1970
Command line switch -s overwrites -a
Top 10 IP Addr ordered by -:
Date first seen          Duration Proto           IP Addr    Flows(%)     Packets(%)       Bytes(%)         pps       bps   bpp
2021-06-21 21:42:19.468   256.124 UDP      34.239.237.116        2( 0.0)       20( 0.0)     1520( 0.0)        0       47    76
2021-06-21 21:29:40.058    90.112 TCP      204.79.197.219        4( 0.1)       80( 0.0)    12000( 0.0)        0     1065   150
2021-06-21 21:31:15.651   111.879 TCP      204.79.197.204        6( 0.1)      110( 0.0)    44040( 0.0)        0     3149   400
2021-06-21 21:39:42.414    58.455 TCP      204.79.197.203        7( 0.1)      150( 0.0)    92530( 0.0)        2    12663   616
2021-06-21 21:28:21.682  1046.074 TCP      204.79.197.200       18( 0.2)      570( 0.1)   288990( 0.1)        0     2210   507
2021-06-21 21:31:24.158    53.392 TCP     209.191.163.209       13( 0.2)      180( 0.0)    86080( 0.0)        3    12897   478

数据已经包装，但您可以看到这变得越来越有用。这不是完整的数据包捕获，但在许多天里，这是您可能需要的所有数据包捕获信息！

-s（统计）参数非常有用，因为您可以查询扩展元组中收集的任何可能的 NetFlow 信息。-A允许您在相同的扩展信息上进行聚合，而-a仅在基本的 5 元组上进行聚合。请注意，当您设置了-b时，您无法对源 IP 或目标 IP 进行聚合（因为-b已经对这两个进行了聚合）。

通常，您需要收集特定时间窗口的信息；也就是说，在出现问题或症状时。在这些情况下，-t（timewin）是您的朋友-让我们在 21:31 和 21:32 之间查看，仍然只针对该 IP 地址。再次注意，您需要根据您的日期和流量模式进行修改：

$  nfdump -b -s ip:192.168.122.181 -t 2021/06/21.21:31:00-2021/06/21.21:32:59 -R /var/cache/nfdump
Command line switch -s overwrites -a
Top 10 IP Addr ordered by -:
Date first seen          Duration Proto           IP Addr    Flows(%)     Packets(%)       Bytes(%)         pps       bps   bpp
2021-06-21 21:32:43.075     0.251 IGMP         224.0.0.22        1( 0.1)       20( 0.0)      920( 0.0)       79    29322    46
2021-06-21 21:32:09.931     0.000 UDP     239.255.255.251        1( 0.1)       10( 0.0)      640( 0.0)        0        0    64
2021-06-21 21:31:07.030    47.295 UDP     239.255.255.250        4( 0.3)       60( 0.1)    18790( 0.0)        1     3178   313
2021-06-21 21:31:15.651     0.080 TCP      204.79.197.204        3( 0.2)       60( 0.1)    21220( 0.0)      750    2.1 M   353
2021-06-21 21:31:24.158    53.392 TCP     209.191.163.209       13( 0.9)      180( 0.2)    86080( 0.1)        3    12897   478
2021-06-21 21:31:09.920     0.252 TCP      52.207.151.151        4( 0.3)      170( 0.2)   142280( 0.2)      674    4.5 M   836
2021-06-21 21:32:12.799    11.421 TCP       52.95.145.171        7( 0.5)      110( 0.1)    22390( 0.0)        9    15683   203
2021-06-21 21:31:53.512     0.054 TCP     162.159.136.232        4( 0.3)       50( 0.1)     5250( 0.0)      925   777777   105
2021-06-21 21:31:11.890    51.148 TCP        209.15.45.65        5( 0.4)       60( 0.1)    32020( 0.1)        1     5008   533
2021-06-21 21:31:07.531    69.964 TCP        69.175.41.15       22( 1.6)      460( 0.5)   222720( 0.4)        6    25466   484
Summary: total flows: 1401, total bytes: 58.9 M, total packets: 85200, avg bps: 4.0 M, avg pps: 716, avg bpp: 691
Time window: 2021-06-21 21:26:17 - 2021-06-21 21:58:40
Total flows processed: 8052, Blocks skipped: 0, Bytes read: 516768
Sys: 0.003s flows/second: 2153517.0  Wall: 0.002s flows/second: 3454311.5 

在一条命令行中，我们总结了一个主机在 2 分钟内进出的所有流量！

在我们的基本功能正常工作后，让我们安装收集器的 Web 界面。这是 NetFlow 数据最常见的消耗方式-通过眼睛很容易看到协议模式中的异常。

以下说明来自github.com/mbolli/nfsen-ng（正在安装的应用程序是nfsen-ng）：

首先，让我们提升我们的权限到 root-几乎这里的所有内容都需要这些权限：

sudo su -

安装我们需要的所有软件包：

apt install apache2 git nfdump pkg-config php7.4 php7.4-dev libapache2-mod-php7.4 rrdtool librrd-dev

启用 Apache 模块：

a2enmod rewrite deflate headers expires

为 PHP 安装rrd库：

pecl install rrd 

配置 RRD 库和 PHP：

echo "extension=rrd.so" > /etc/php/7.4/mods-available/rrd.ini
phpenmod rrd

配置虚拟主机以便它可以读取.htaccess文件。编辑/etc/apache2/apache2.conf文件，并编辑/var/www部分中的Allow Override行：

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

最后，重新启动 Apache 服务器：

systemctl restart apache2

现在，我们准备安装nfsen-ng并设置文件/目录标志：

cd /var/www/html
git clone https://github.com/mbolli/nfsen-ng
chown -R www-data:www-data .
chmod +x nfsen-ng/backend/cli.php

仍然使用 root 权限，将默认设置复制到设置文件：

cd /var/www/html/nfsen-ng/backend/settings
cp settings.php.dist settings.php

编辑生成的settings.php文件。

在nfdump部分，更新以下行以匹配：

    'nfdump' => array(
        'profiles-data' => '/var/cache/nfdump/',
        'profile' => '',

请注意，您可以更改这一点，特别是如果您计划按nfdump文件的日期进行日志轮换，但这不是我们目前的范围。

现在，让我们测试我们的配置（仍然作为 root 用户）：

cd /var/www/html/nfsen-ng/backend
./cli.php -f import
2021-06-22 09:03:35 CLI: Starting import
Resetting existing data...
Processing 2 sources...                                         0.0% 0/2194 ETC: ???. Elapsed: < 1 sec [>                              ]
Processing source source1 (1/2)...
Processing 2 sources...                                 50.0% 1097/2194 ETC: < 1 sec. Elapsed: < 1 sec [===============>               ]
Processing source source2 (2/2)...
Processing 2 sources...                                100.0% 2194/2194 ETC: < 1 sec. Elapsed: < 1 sec [===============================]

如果这个过程没有错误，您的配置将看起来很好！

现在，将各种网络设备指向将它们的 NetFlow 结果发送到此主机的 IP 地址，端口为2055/udp（请注意，您可以通过编辑/etc/nfdump/default.conf来更改此监听端口）。

让我们收集一些数据。您可以通过观察目标目录中的文件大小来验证它是否正常工作。一个“空”文件大小为 276 字节，但一旦开始接收数据，您应该会看到更大的文件。

现在，浏览到您的服务器。由于我们在 apache 中没有做任何花哨的东西，您的 URL 将如下：

http://<your server's IP address>/nfsen-ng/frontend/ 

现在，让我们看看图形方面的东西。浏览到您的服务器 IP 地址 - URL 应该看起来像192.168.122.113/nfsen-ng/frontend/。当然，您可以通过配置 Apache 重新指向主页来简化此 URL。

您的显示现在应该看起来像这样（您的数据值将有所不同）：

图 12.23 - 图形显示中的基本流数据，带有 NFSen 中的显示/过滤控件

一个好的方法是选择一个合理的时间尺度，然后使用滑块来扩大或缩小窗口。在这种情况下，我们从一个 24 小时的图表开始，最终显示了大约 6 小时。

这个显示通常会突出显示可能引起关注的时间 - 您可以在这些时间上“放大”这个图表以获得更多细节。

下一站将是流量按钮（在显示的右上角）。在这里，一个合理的起始窗口将是一个很好的选择。接下来，选择各种聚合。

通常，您会希望使用目标端口聚合进行协议聚合。接下来，您通常会希望将 IP 地址按源 IP 和目标 IP 进行聚合。添加 NFDUMP 过滤器以获取确切的时间窗口通常也很有帮助。如果可能的话，您可以将显示限制在尽可能短的时间内 - 如果可能的话，几分钟内，您将从这些显示中获得最大的价值：

图 12.24 - NFSen 中聚合和过滤的流显示控件

最终的选择将取决于您要解决的问题，可能需要尝试几次才能获得您需要的显示以进行最终诊断。

当您的选择完成后，选择处理数据以在屏幕的下半部分获得结果：

图 12.25 - NFSen 中的过滤结果

您可能希望将其导出为 CSV，以便在电子表格中进一步操作您的数据。

在真实的事件中，这是什么样子？让我们打开默认窗口，在那里我们会注意到流量可能可疑的“峰值”。我们还可以从帮助台或桌面团队那里获得这个时间段，他们可能有取证信息，IPS 事件（见[第十三章]（B16336_13_Final_NM_ePub.xhtml#_idTextAnchor236），Linux 上的入侵防范系统），或来自桌面保护应用程序或反恶意软件应用程序的事件。在这个每日视图中，我们可以看到在下午 2:30 之前出现了一个可疑的峰值。请注意，我们使用滑块来放大感兴趣的时间窗口。还要注意，我们正在查看“流量”或“字节”视图 - 数据外泄通常只会发生在一两个流中，因此这些攻击通常会在默认显示中显眼：

图 12.26 - 发现异常流量“峰值”

让我们切换到协议显示并稍微浏览一下。在这个显示中，我们已经将事情简化，只显示 UDP，我们可以看到一些可疑的东西 - 这种 UDP 流量的数量对于这个组织来说并不正常：

图 12.27 - 协议显示中的显示调整，仅显示 UDP

有了那个在 14:20 出现的可疑流量峰值，让我们深入一点。让我们添加一个 nfdump 过滤器来查看 UDP，但提取我们在内部 DNS 服务器上配置的所有 DNS 转发器的请求：

图 12.28 – UDP 搜索结果 – 删除合法的 DNS 流量

现在，让我们深入挖掘一下，只看那个可疑的 IP 地址：

图 12.29 – 过滤可疑 IP 地址

这给我们以下结果，显示了防火墙上 NAT 之前和之后的相同传输，除了这一大数据传输之外没有其他流量：

图 12.30 – 防火墙上 NAT 之前和之后的可疑流量

观察53/udp中的总数，我们知道这通常用于 DNS。

使用 DNS，甚至可以使用有效的查询来外泄数据 – 首先，使用 base64 对数据进行编码，然后以已知的“块”大小进行顺序的“A”记录查询。接收服务器然后重新组装数据并将其解码为原始的二进制格式。如果担心数据包的顺序问题，甚至可以将序列号编码到传输中。

既然我们发现了这次攻击，我们如何在网络层面进行防御呢？

一个很好的起点是为出站流量创建一个合理的访问列表，通常称为出口过滤器。它可能是这样工作的：

• 允许从我们的 DNS 服务器到它们已知的转发器 IP 的53/udp和tcp。

• 拒绝所有其他的53/udp和tcp，并将该流量记录为警报。

• 允许ssh，scp，ftp和其他已知的流量通过协议和端口到已知的目标主机。

• 拒绝所有其他主机的这些协议，并将其记录为警报。

• 允许 HTTP 和 HTTPS 到任何 IP（但另外增加一层保护，也许是声誉过滤或内容控制）。

• 拒绝所有其他流量，并将该流量记录为警报。

关键是总会有“下一次攻击” – 但是记录和警报你知道的攻击通常至少会在攻击开始时给你一些警告，通常足够让你采取行动，防止攻击者达到最终目标。

到目前为止，您对使用 NFDUMP 和 NFSEN 组合有一些了解。但是还有哪些开源 NetFlow 收集器应用程序可供您选择？

其他开源 NetFlow 替代方案

nProbe 是由 ntop 团队编写的，托管在www.ntop.org/products/netflow/nprobe/#。这允许您在任何主机上安装 NetFlow 收集器。ntop 工具（www.ntop.org/products/traffic-analysis/ntop/）是他们的收集器，在 NetFlow 流行之前就为我们提供了许多 NetFlow 的好处，但使用了数据包捕获和分析方法。它已经扩展到支持所有版本的 NetFlow 和 IPFIX。选择 ntop 最吸引人的因素是它是一个单一的安装，所有东西都打包在一起 – 大部分繁琐的配置都已经处理好了。它还以更详细的方式分解数据，甚至在初始的图形界面上也是如此。不足之处是没有命令行工具集；它是一个“一体化”的应用程序，提供了一个网页/图形界面。ntop 工具套件是免费下载的。在这个免费级别上，它通过论坛和“尽力而为”的邮件列表享有“社区支持”。

互联网级别知识系统（SILK）是最古老的流量收集工具之一，但它仍然支持所有较新的协议。它由 CERT 的网络态势感知组开发，文档和下载托管在这里：tools.netsa.cert.org/silk/。SILK 是一个免费工具，没有商业提供。

说到这一点，这个领域还有哪些商业产品？

商业产品

几乎每个拥有商业 NMS 的供应商都会有一个流量收集模块与该 NMS 相配套。然而，当你深入研究他们的文档时，几乎所有的供应商都只建议你在与 SNMP 和 syslog 功能相同的服务器上部署流量收集。正如我们之前讨论的，随着流量数据量的增长和数据保留时间的增加，流量收集服务往往会压倒已经繁忙的系统。此外，由于大多数流量收集服务对数据库的依赖性，通常会看到人们不得不定期清除数据，作为修复破损的流量收集服务器的“当所有其他故障排除失败时”的步骤。这些因素往往会迅速导致 NetFlow 或其相关服务在大多数组织中被移至自己的服务器和数据库。

话虽如此，在商业产品中，你经常会看到更多关于应用程序“外观和感觉”的工作。例如，当为 NetFlow 添加设备接口时，接口名称通常会从接口的description值中读取，并且图表的最大带宽将最初从接口的吞吐量值或路由器的“带宽”度量（如果设置）中设置。图表通常会包括应用程序名称和工作站名称，甚至用户 ID。图表还将从一开始就深入到目标端口值和数据速率，因为那通常是你想要最终到达的地方。总的来说，大多数商业产品往往更容易设置，无论是在初始应用程序还是在添加设备时。

总结

在这一点上，你应该意识到可以从各种系统的日志中收集到大量有用的数据，以及如何使用命令行工具来“挖掘”这些数据，以找到可以帮助你解决特定问题的信息。日志警报的使用也应该是熟悉的领域，允许你在问题的早期阶段主动发送警报。

然后，介绍了 Dshield 项目。我们欢迎你的参与，但即使你不贡献数据，它也可以成为一个快速的“互联网天气报告”的宝贵资源，以及有助于定义“互联网气候”的趋势，就恶意流量（按端口和协议）而言。

你现在应该熟悉 SNMP 的工作原理，以及如何使用基于 SNMP 的 NMS 来管理网络设备甚至 Linux 或 Windows 服务器的性能指标。我们在示例中使用了 LibreNMS，但几乎任何你可能使用的 NMS 的方法甚至实现都会非常相似。

在更高级别上，你应该对 NetFlow 协议非常熟悉，包括在网络设备和 Linux 收集器上配置它。在本章中，我们使用 NetFlow 作为侦探工具，对网络流量进行高级取证，以找到可疑的流量，最终找到恶意数据外泄事件。

在下一章中，我们将探讨入侵防范系统（IPS），这将建立在本书的几章材料基础上，以寻找并经常阻止恶意网络活动。

问题

在我们结束时，这里有一些问题供你测试对本章材料的了解。你可以在附录的评估部分找到答案：

1. 为什么启用 SNMP 的读写社区访问是一个坏主意？

2. 使用 Syslog 的风险是什么？

3. NetFlow 也是一个明文协议。这会带来什么风险？

进一步阅读

有关本章内容的更多信息，请参阅以下资源：

• 处理 Syslog 数据的方法：

• isc.sans.edu/diary/Syslog+Skeet+Shooting+-+Targetting+Real+Problems+in+Event+Logs/19449

• isc.sans.edu/forums/diary/Finding+the+Clowns+on+the+Syslog+Carousel/18373/

• Swatch 手册：

• manpages.ubuntu.com/manpages/bionic/man1/swatchdog.1p.html

• linux.die.net/man/1/swatch

• Swatch 主页：

• github.com/ToddAtkins/swatchdog

• sourceforge.net/projects/swatch/

• 各种正则表达式备忘单：

• www.rexegg.com/regex-quickstart.html

• developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions/Cheatsheet

• www.sans.org/security-resources/posters/dfir/hex-regex-forensics-cheat-sheet-345

• 在线正则表达式“构建器”：

• regexr.com/

• https://gchq.github.io/CyberChef/#recipe=Regular_expression(‘User%20defined’,‘’,true,true,false,false,false,false,‘Highlight%20matches’)&input=Ig

• 出口过滤器：isc.sans.edu/forums/diary/Egress+Filtering+What+do+we+have+a+bird+problem/18379/

• 相关的 RFC：

• Syslog：datatracker.ietf.org/doc/html/rfc5424

• SNMP：

1. datatracker.ietf.org/doc/html/rfc3411

2. datatracker.ietf.org/doc/html/rfc3412

3. datatracker.ietf.org/doc/html/rfc3413

4. datatracker.ietf.org/doc/html/rfc3415

5. datatracker.ietf.org/doc/html/rfc3416

6. datatracker.ietf.org/doc/html/rfc3417

7. datatracker.ietf.org/doc/html/rfc3418

• SNMP MIB II：datatracker.ietf.org/doc/html/rfc1213

• SNMPv3：

1. datatracker.ietf.org/doc/html/rfc3414

2. datatracker.ietf.org/doc/html/rfc6353

• NetFlow：datatracker.ietf.org/doc/html/rfc3954.html

• sFlow：datatracker.ietf.org/doc/html/rfc3176

• IPFIX：datatracker.ietf.org/doc/html/rfc7011

• 各种供应商的SNMP OID：请查阅您的供应商文档；以下是您通常会看到的一些 OID。

常用的 SNMP OID

• 监控路由器 CPU：1.3.6.1.4.1.9.2.1.58.0

• 监控路由器内存：1.3.6.1.4.1.9.9.48.1.1.1.6.1

• 1.3.6.1.2.1.1

• 接口：1.3.6.1.2.1.2

• IP：1.3.6.1.2.1.4

• 内存：1.3.6.1.2.1.4.1.9.9.48

• CPU：1.3.6.1.2.1.4.1.9.9.109

• 防火墙：1.3.6.1.2.1.4.1.9.9.147

• 缓冲区：1.3.6.1.2.1.4.1.9.9.147.1.2.2.1

• 连接：1.3.6.1.2.1.4.1.9.9.147.1.2.2.2

• SSL 统计：1.3.6.1.4.1.3076.2.2.26

• IPSec 统计：1.3.6.1.2.1.4.1.9.9.171

• 远程访问统计：1.3.6.1.2.1.4.1.9.9.392

• FIPS 统计：1.3.6.1.2.1.4.1.9.9.999999

• PIX/ASA 防火墙中的活动连接：1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7

• 当前活动的 IPsec Phase-2 隧道总数：1.3.6.1.4.1.9.9.171.1.3.1.1.0

您将需要以下 MIB：

• IF-MIB，RFC1213-MIB，CISCO-MEMORY-POOLMIB，CISCO-PROCESS-MIB，ENTITY-MIB，CISCO-SMI，CISCO-FIREWALL-MIB。ASA 还添加了 CISCO-IPSEC-FLOW-MONITOR-MIB，CISCO-FIPS-STAT-MIB 和 ALTIGA-SSL-STATS-MIB。

• 堆叠交换机的序列号：1.3.6.1.2.1.47.1.1.1.1.11.1

• 堆叠交换机的 IOS 版本：1.3.6.1.2.1.47.1.1.1.1.9.1

• 路由器上的 ARP 缓存：1.3.6.1.2.1.3.1.1.2

• 接口的最后状态更改：1.3.6.1.2.1.2.2.1.9。[接口编号]

第十三章：Linux 上的入侵防范系统

在本章中，我们将在数据包捕获和日志记录的基础上，探讨 Linux 平台上的入侵防范选项。入侵防范系统（IPS）确切地做了它听起来的事情-它监视流量，并且要么警报要么阻止可疑或已知的恶意流量。这可以通过各种方式来实现，具体取决于您要监视的流量。

特别是，我们将涵盖以下主题：

• 什么是 IPS？

• 架构/IPS 位置

• Linux 的经典 IPS 解决方案-Snort 和 Suricata

• IPS 回避技术

• Suricata IPS 示例

• 构建 IPS 规则

• 被动流量监控

• Zeek 示例-收集网络元数据

让我们开始吧！

技术要求

在本章的示例中，我们将使用预打包的虚拟机，基于Suricata-Elasticsearch-Logstash-Kibana-Scurius（SELKS）或 Security Onion（两种不同的预打包 Linux 发行版）。与我们的数据包捕获示例一样，IPS 解决方案通常针对捕获的流量进行操作，因此您可能需要参考第十一章，Linux 中的数据包捕获和分析，以确保您具有适当的 SPAN 端口配置。然而，IPS 解决方案通常与数据包流一起运行，通常具有一些解密功能-因此，您可能会发现自己更多地将架构与我们在第十章中的负载均衡器示例进行比较，Linux 的负载均衡器服务。

由于 IPS 安装经常更改，这反映在这两个发行版的安装中。因此，在本章中，我们不会详细介绍安装软件包等内容，请参考在线安装，以了解您想在实验室中探索的任何解决方案。或者，像往常一样，您可以选择跟随我们在本章中进行。虽然您可能确实想要实施我们将在本章中讨论的一些工具，但它们大多是复杂的-例如，您可能不想构建一个测试 IPS，直到您接近为生产构建一个 IPS。

什么是 IPS？

IPS 始于 20 世纪 90 年代的入侵检测系统。从一开始（早在 20 世纪 90 年代），最常用的 IDS/IPS 产品是 Snort，它仍然是一个产品（开源和商业），许多其他现代 IPS 产品现在都是基于它的。

IPS 监视已知攻击的网络流量，然后阻止它们。当然，在这个过程中有一些失败：

• 列举恶意行为是一个不错的失败命题，这是反病毒行业长期以来意识到的。无论您为何种签名模式列举，攻击者都可以进行相同的攻击，只需稍作修改即可逃避基于签名的检测。

• 误报是这些产品的一个负担。如果它们没有正确配置，签名可能会错误地标记正常流量为恶意并将其阻止。

• 在光谱的另一端，如果配置过于宽松，很容易不会警报或阻止攻击流量。

正如您所看到的，部署 IPS 通常需要频繁的调整。幸运的是，现代 IPS 系统通常设置了良好的默认值，可以阻止已知攻击的合理部分，并且存在误报。

调整组织的规则时，通常会看到每个规则都有一个严重性评级，这给您一些关于相关攻击有多严重的指示。规则还将具有忠实度评级，告诉您规则在检测攻击方面有多“可靠”，即这个规则在正常流量中误报的可能性有多大。您通常可以使用这两个评级来决定在您的情况下启用哪些规则。

既然我们已经提供了 IPS 解决方案的一些背景，让我们看看您可能希望在数据中心中插入 IPS 的位置。

架构选项 - 入侵防御系统在数据中心的位置？

在数据中心中放置入侵防御系统是一个重要的决定，因此我们将在提供入侵防御系统/入侵检测系统历史的同时讨论这个决定。

回顾过去，数据中心配置为“脆壳，软心”架构。换句话说，保护重点放在边缘，以防范外部攻击。内部系统大多是受信任的（通常是过于信任）。

这将使入侵检测系统处于边缘位置，通常在 SPAN 端口或网络监听器上。如果您回顾我们在《第十一章》中讨论的监听选项，Linux 中的数据包捕获和分析，如果以这种方式部署，通常是单向监听，电气上阻止入侵检测系统发送流量。这是为了最大程度地减少入侵检测系统本身可能被 compromise 的可能性。

第二个受信任的接口将用于管理入侵检测系统。

这种配置逐渐发展，最终包括入侵检测系统发送RST（TCP 复位）数据包给攻击者、防御者或两者，以终止任何攻击流量，如下图所示：

图 13.1 - 入侵防御系统位于防火墙外部，SPAN 端口用于流量收集，并发送 RESET 数据包以阻止检测到的攻击

随着攻击变得更加被理解和互联网变得更加敌对，这种配置也发生了变化。在互联网上观察恶意流量变得不再那么有效，因为观察外部流量很可能只会产生持续的警报，因为攻击者开始将恶意软件和相关攻击商品化。

您仍然希望监视入站攻击，但在可能的情况下，您只希望监视可以应用于任何给定主机的攻击。例如，如果您的防火墙只允许邮件流量进入邮件服务器，那么寻找并警报针对该主机的基于网络的攻击就不再有意义。有了这种入站攻击的方法，我们现在看到入侵检测系统和入侵防御系统更频繁地部署在防火墙后面。

在同一时间段，我们开始看到恶意软件更多地通过电子邮件分发 - 特别是作为办公文档中的宏。有效地保护组织免受这些攻击变得困难，特别是因为许多组织已经围绕宏构建了工作流程，并拒绝禁用它们。这意味着非常有效地寻找来自受 Compromise 的工作站和服务器的出站流量，这将表明攻击成功。通常，这种流量采取命令和控制（C2）流量的形式，其中受 Compromise 的工作站联系攻击者以获取下一步的指示：

图 13.2 - 防火墙内部的入侵防御系统检测 C2 流量。此外，一些互联网“噪音”被过滤掉

加密的兴起意味着将入侵防御系统置于半被动模式变得越来越不够有效。为了有效地检测攻击流量，在今天的互联网上，至少有一部分需要被解密。这意味着入侵防御系统必须处于线路中，通常在防火墙上运行。这种架构的变化与更便宜的处理器相配，使人们能够为他们的防火墙分配更多的 CPU（通常还有匹配的磁盘和内存）。

对于入站流量，这意味着 IPS 现在托管与目标服务器匹配的证书。它在 IPS 上解密，检查可疑内容，然后转发（通常重新加密）如果它得到绿灯。这应该看起来很熟悉，因为当我们讨论第十章中的负载均衡器时，我们讨论了一个非常相似的架构，Linux 的负载均衡器服务：

图 13.3-周边防火墙上的 IPS。Web 服务器证书允许入站 HTTPS 解密

出站解密要复杂一些。为了使其工作，IPS 需要托管在其上的证书颁发机构（CA），内部工作站必须信任。当出站流量传输时，IPS 动态创建目标的证书，这就是用户现在在浏览器中查看的 HTTPS 证书。

这允许 IPS 解密出站流量。然后，从 IPS 到目标主机的出站流量将按照新的加密会话正常进行，使用目标主机上的真实证书。

当检测到攻击时，任何产生的警报都将具有客户工作站的 IP 地址。在 Windows/Active Directory 环境中，通常，IPS 将具有一个匹配的“代理”，用于监视每个域控制器的安全日志。这允许 IPS 将 IP 地址与在任何给定时间在该站点上使用的用户帐户名称进行匹配。

如果 IPS 和防火墙共享一个公共平台，这也允许防火墙根据用户帐户、组、证书信息（其中包括域名和通常是目标主机的 FQDN），以及基于源和目标 IP 地址、端口等的传统规则添加规则：

图 13.4-周边防火墙上的 IPS。CA 证书允许出站客户端流量解密

在同一时间，IPS 的一个特殊情况也在增长，被称为Web 应用防火墙（WAFs）。这些是主要专注于入站基于 Web 的攻击的设备。随着互联网几乎完全转向用于 Web 目的地的 HTTPS 内容，这些 WAF 解决方案也需要解密来检测大多数攻击。

起初，这些 WAF 解决方案采用专用设备的形式，但后来已经转变为大多数负载均衡器上可用的功能。最常见的开源 WAF 解决方案包括 ModSecurity（适用于 Apache 和 Nginx），但还有许多其他解决方案：

图 13.5-入站 IPS（WAF）和解密托管在负载均衡器上，防火墙内

WAF 解决方案的主要问题与我们在传统 IPS 中看到的问题相同-覆盖范围要么太过激进，要么太过松散。在光谱的一端，有一些 WAF 解决方案不需要太多的配置-这些解决方案倾向于保护特定攻击，如跨站脚本或 SQL 注入，其中语法通常是可预测的，但不包括其他常见攻击。在光谱的另一端，我们有一些产品需要针对应用程序中的各个字段进行配置，以全面验证输入。这些产品工作得很好，但需要与应用程序匹配，因为更改和新功能的实施。如果不这样做，应用程序可能会被用来保护它的工具破坏。

新的 WAF 选项考虑到较大的基于云的网站通常不使用负载均衡器设备或防火墙。在某些情况下，它们通过内容交付网络（CDN）提供其内容，但即使它们直接从较大的云服务提供商中运行，它们也可能在互联网上。此外，对于上行速率为 10、40 或 100 Gbps 的较大站点，WAF 设备解决方案的扩展性并不那么好。

对于这些站点，防火墙被推送到主机本身（正如我们在第四章中讨论的那样，Linux 防火墙），WAF 也移动到主机上。在这里，每个主机或容器都成为一个独立的工作单元，扩展站点的容量只是添加另一个工作单元的问题。

对于这些情况，我们的 WAF 已经演变成了运行时应用自我保护（RASP）解决方案。顾名思义，RASP 软件不仅在与应用程序相同的平台上，而且与应用程序更紧密地联系在一起。RASP 代码出现在站点的每个页面上，通常作为一个简单的标记，每个页面都加载 RASP 组件。这不仅可以防止已知攻击，而且在许多情况下，还可以防止“异常”输入和流量，甚至防止站点或站点代码被修改：

图 13.6–云 Web 服务托管本地防火墙和 RASP IPS 解决方案

这些 RASP 解决方案已被证明非常有效，它们正在取代许多企业站点中的传统 WAF 产品。在这些情况下，防火墙通常位于周边而不是主机上：

图 13.7–RASP 在企业环境中显示了周边防火墙

RASP 解决方案包括在自由/开源方面的 OpenRASP，以及商业方面的 Signal Sciences 或 Imperva 等产品。

现在您对各种 IPS 系统有了一些背景知识，让我们花点时间从攻击者或渗透测试人员的角度来看一下它们。

IPS 规避技术

入站规避利用 IPS（基于 Linux）解释恶意数据包和数据流的方式与目标解释这些数据包的方式之间的差异。这对传统 IPS 系统和 WAF 系统都是如此。

检测 WAF

对于 WAF，攻击者知道 WAF 正在起作用以及其基础是很方便的。Wafw00f 是一个很好的起点。Wafw00f 是一个免费的扫描程序，可以检测超过 150 种不同的 WAF 系统，其中许多也是负载均衡器。它是用 Python 编写的，托管在github.com/EnableSecurity/wafw00f，但也打包在 Kali Linux 中。

通过测试一些站点，我们可以看到托管提供商托管的不同 WAF 解决方案：

└─$ wafw00f isc.sans.edu
[*] Checking https://isc.sans.edu
[+] The site https://isc.sans.edu is behind Cloudfront (Amazon) WAF.
[~] Number of requests: 2
└─$ wafw00f www.coherentsecurity.com
[*] Checking https://www.coherentsecurity.com
[+] The site https://www.coherentsecurity.com is behind Fastly (Fastly CDN) WAF.
[~] Number of requests: 2

对于第三个站点，我们可以看到一个商业 WAF（也是基于云的）：

└─$ wafw00f www.sans.org
 [*] Checking https://www.sans.org
[+] The site https://www.sans.org is behind Incapsula (Imperva Inc.) WAF.
[~] Number of requests: 2

正如我们所指出的，如果您知道正在使用哪种 WAF，那么您就有更好的机会规避该 WAF。当然，如果您是攻击者或渗透测试人员，您仍然必须 compromise WAF 后面的网站，但这是另一回事。

由于入站目标通常是 Web 服务器，而且通常也是 Windows 主机，因此这些流量上的规避通常利用处理分段数据包。

分段和其他 IPS 规避方法

人为分段数据包，然后以无序方式发送它们，并且在某些情况下，发送具有不同信息的重复片段号码是规避或检测 IPS 的一种常用方法。

这利用了 IPS 操作系统（通常是 Linux 变体）处理片段的方式与操作系统背后的主机处理片段的方式之间的差异，后者可能是完全不同的操作系统。

即使是简单地将maliciousdomain.com分解为malic和iousdomain.com也可能产生重大影响，如果 IPS 根本不重新组装片段。然而，更常见的是，你会看到一系列类似于以下的数据包片段：

攻击者的目标是管理重复片段的重新组装方式。如果 Linux 将其重新组装为MalicASDFdomain.com，而 Windows 将其重新组装为mailicousdomain.com，那么攻击者就有了一种通过基于 Linux 的 IPS 从恶意域渗透或向其渗透的方法。大多数现代 IPS 将以几种不同的方式重新组装片段，或者将识别目标主机的操作系统，并根据那个操作系统进行重新组装。

这是一种较早的攻击，由Dug Song在他的fragroute工具中在 21 世纪初首创。虽然这个工具在配置正确的现代 IPS 上将不再起作用，但一些供应商在其商业产品中默认情况下没有启用片段重组的正确设置。因此，虽然它不应该起作用，但对于渗透测试人员来说，有时尝试一下总是一个方便的事情，因为有时候你会幸运地绕过 IPS。

出站逃避通常会利用在安装和配置 IPS 时做出的决定；以下是一些例子：

• IPS 系统可能会绕过任何看起来像 Windows 更新的东西 - 这可以让攻击者使用 BITS 协议绕过 IPS 来传输文件。

• 有时，出于性能原因，流媒体服务将被绕过。这种设置可以让攻击者将 C2 信息嵌入到特定 YouTube 视频的评论中。

• 如果没有进行解密，攻击者可以简单地使用 HTTPS 并顺利通过，只要他们的外部主机没有被其 IP 或 DNS 名称标记为可疑。

• 即使解密正在进行，如果攻击者使用有效的固定证书，解密将失败，这通常意味着 IPS 将退回到“允许”而不是“拒绝”的响应。

• 总会有一些协议在解密和重新签名机制方面处理得不好；这些也经常是选项。

• “自行加密”也是我们看到攻击者使用的一种方法。

• 使用 DNS 进行数据隧道传输也是一个古老的选择。你可以简单地在端口53/udp上传输数据，你会惊讶地发现这种方法经常有效，即使数据包本身看起来与 DNS 数据包完全不同。然而，即使 IPS 检查 DNS 数据包以确保有效性，你也可以使用有效的 DNS 查询来传输大量数据 - 尤其是对于入站传输（数据在TXT响应中）特别是TXT查询，或者对于出站查询（数据在被查询的 DNS 主机名中）特别是A查询。

• 或者，最常见的是，攻击者将简单地使用C 和 C 框架来建立他们的通道。有几种选项可供选择，商业、盗版或开源工具的受欢迎程度会不断变化，取决于它们在任何特定时间的有效性。

长话短说，如果你的 IPS 不理解特定的数据流，你可能会考虑将其设置为阻止该流量。这种方法会阻止一些生产流量，但你会发现这是一个需要权衡的持续的紧绷绳索，权衡你所保护的社区的需求与 IPS 的有效性。

在攻击者的角度得到了涵盖（至少在高层次上），让我们来看一些实际应用 - 从网络 IDS/IPS 系统开始。

经典/基于网络的 IPS 解决方案 - Snort 和 Suricata

正如我们之前讨论的，传统的 IPS 故事始于 20 世纪 90 年代，当Martin Roesch编写了 Snort。当 Sourcefire 成立时，Snort 成为了一种商业产品，但即使在 Cisco 收购 Sourcefire 之后，Snort 仍然有一个可以安装在任何 Linux 平台上的开源版本。

由于 Snort 如此普遍，它既直接在 Sourcefire 产品中使用，也被许多（许多）下一代防火墙（NGFW）产品许可使用。在 Cisco 收购之后，这种情况发生了变化；没有商业防火墙希望在其平台上使用来自竞争公司的 IPS。

撇开营销不谈，“传统”的 Snort（2.x）版本存在一些缺陷：

• 它完全基于文本，没有 GUI。然而，Snort 有几个 Web 前端项目可用。

• 消息通常是神秘的-通常，您需要是安全专家才能完全理解 Snort 消息。

• 它是单线程的。随着网络带宽上行从数百 Mbps 到 Gbps，然后到 10、40 和 100 Gbps，这产生了巨大影响。无论 CPU、内存和磁盘的组合如何，Snort 都无法在这些容量上跟上。

然而，Snort 的方法，特别是 Snort 签名规则集，是非常宝贵的，几乎所有 IPS 解决方案都可以使用 Snort 签名。

这些因素的组合推动了行业向替代方案发展。在许多情况下，这就是 Suricata，这是一个在 2009 年发布的 IPS，自那以后一直在改进。Suricata 很有吸引力，因为从一开始它就是多线程的，因此更多的 CPU 核心有效地转化为更多可用的 CPU。这使得它比 Snort 更具可扩展性。Suricata 直接使用 Snort 规则而不进行修改，因此在创建签名和行业专业知识方面的多年工作仍然完整。

Suricata 还有许多其他安全产品的插件和集成，包括 Splunk、Logstash 和 Kibana/Elasticsearch。Suricata 可以直接集成到许多流行的防火墙中，如 pfSense 或 Untangle。

最后，许多发行版将 Suricata 与基础 Linux 操作系统、合理的 Web 界面和后端数据库捆绑在一起-如果您的硬件和网络已经准备就绪，您可以在几小时内安装 Suricata 并拥有一个可用的系统。

Snort 团队自那时发布了他们的 IPS 的 3.0 版本（2021 年 1 月）；然而，它仍然没有 GUI（除非您购买商业版本作为 Cisco Firepower 安装的一部分）。Snort 仍然是一个优秀的产品和行业最受欢迎的产品，但现在他们必须赶上 Suricata 解决方案。

足够的背景和理论-让我们构建和使用一个实际的 IPS！

Suricata IPS 示例

在这个例子中，我们将使用 Stamus Networks 的 SELKS（www.stamus-networks.com/selks）。 SELKS名称反映了它的主要组件：Suricata，Elasticsearch，Logstash，Kibana 和 Stamus Scirius 社区版。这是在 Debian Linux 上打包的，所以如果您一直在阅读本书，这些东西应该看起来很熟悉，因为 Ubuntu 根源于 Debian“父”发行版。

SELKS 有一个live选项和一个install选项。live选项从 ISO 映像运行整个解决方案。这对于小型实验室或快速评估工具非常方便，您可以选择在本章中采用这种方式。然而，在生产中，您将希望使用安装在真实磁盘上的图像（最好是 SSD 或其他快速存储选项）。

SELKS 的安装指南位于这里：github.com/StamusNetworks/SELKS/wiki/First-time-setup。由于这些内容经常更改，我们在本章中不会进行实际安装（如果我们这样做，它将在几个月内过时）。

对于大多数 IPS 解决方案来说，拥有两个网卡是一个要求。第一个网卡用于实际的 IPS 功能，需要混杂模式并进行数据包捕获-完成后，此适配器不应该有 IP。另一个网卡用于管理平台-通常，解决方案的 Web UI 在此网卡上。

在运行 Suricata 时，请确保它处于捕获数据包的位置，可以是 SPAN 端口、TAP 或启用了混杂模式的 hypervisor vSwitch。

在开始使用系统之前，最好定义一下定义您的环境的各种主机和子网。所有这些信息都在/etc/suricata/suricata.yaml中。

以下是需要设置的关键变量：

在许多环境中，这些默认设置都可以保持不变，但正如前面所述，定义各种服务器变量可以帮助优化规则处理。例如，如果您可以缩小范围，使得在域控制器或 SQL 服务器上不进行 HTTP 检查，这可以帮助降低处理不必要检查的 CPU 需求。

MODBUS 协议通常在 SCADA 系统中使用，并且通常在制造业或公共事业中很常见，通常是非常严格定义的。通常，这些服务器和客户端被隔离到它们自己的子网中。

此外，定义组织内部的各种 DNS 服务器也是有帮助的。

在这个文件中有许多其他选项，它们控制着 Suricata 及其相关产品的操作方式，但是为了演示 IPS（甚至在许多生产环境中），您不需要修改它们。不过，我建议您查看一下这个文件；它有很好的注释，这样您就可以看到每个变量的作用。

在一段正常活动的时间之后，可能在几分钟内，您将开始在 SELKS 的警报的 Web 界面 EveBox 中看到活动：

图 13.8 – Suricata 中的基本警报（EveBox 事件仪表板）

让我们来看一下伪装的 Firefox 字体更新警报：

图 13.9 – 规则详细信息（1）– 基本信息和地理 IP 信息

在这个显示中特别重要的是源 IP 和目标 IP – 如果这是出站流量，可能表明有受感染的主机。然而，在我们的情况中更重要的是签名 ID（通常缩写为SID），它唯一标识这个攻击签名。我们稍后会回到这个值。

在下面是远程地址的地理 IP 信息。这并不总是 100%准确，但如果您所在的企业关注间谍活动（企业或国家级），这些位置信息可能很重要。如果 IP 是本地的，您可能需要收集证据以供执法机构使用，特别是如果您怀疑攻击来自“内部人员”。

向下滚动一点；因为这次攻击是通过 HTTPS 进行的，我们将看到涉及的 TLS 信息：

图 13.10 – 规则详细信息（2）– TLS 和指纹信息以及有效载荷显示

在这里，我们可以看到self.events.data.microsoft.com，并且证书是由有效的 Microsoft Azure CA 颁发的。这些组合告诉我们，虽然使用伪装的字体更新的攻击是一个真正的问题，但这个签名一遍又一遍地被触发，是虚假的阳性。

仅供参考，再往下看一节，我们将看到有效载荷部分。左侧显示数据包中的字符串值，右侧显示数据包的十六进制表示。有趣的是PCAP按钮，让我们点击一下：

图 13.11 – 从事件显示中调用的数据包捕获

如预期的那样，点击server_name/SNI部分。

回到警报页面，继续向下滚动，我们将看到规则的 JSON 表示。回到规则名称，记住它是如何引用单词JA3的吗？JA签名是加密流量初始握手数据包中交换的各种值的哈希。使用JA值，我们可以识别源和目标应用程序，通常还可以识别服务器名称（在这种情况下，使用JA3签名是由 Salesforce 的John Althouse，Jeff Atkinson和Josh Atkins（因此称为 JA3）开创的。有关此方法的更多信息可以在本章末尾找到。HASSH 框架对 SSH 流量执行类似的功能。

查看 JSON 规则显示中的JA3部分，我们可以看到有关触发 IPS 警报的网络事件的详细信息：

图 13.12 - 触发 IPS 警报的网络事件的 JSON 详细信息

请注意，此 JSON 显示是“我们正在寻找的”和“我们看到的”混合体。您必须查看规则本身才能看到是什么触发了规则（尽管在这种情况下，它是 JA3 哈希）。

现在我们已经探索完这个警报并认为它是误报，我们有两种可能的行动方案：

• 我们可以禁用此警报。很可能，您会发现自己在新的 IPS 上经常这样做，直到事情平稳下来

• 您可以编辑警报，也许使其按预期触发，但不适用于以Microsoft.com结尾的 SNI。请注意，我们说的是以…结尾，而不是包含。攻击者通常会寻找定义错误 - 例如，foo.microsoft.com.maliciousdomain.com SNI 将符合包含 microsofot.com，而实际的self.events.data.microsoft.com只会符合以…结尾。如果您还记得我们在第十一章中的正则表达式讨论，以Microsoft.com结尾将看起来像*.microsoft.com$（一个或多个字符，后跟Microsoft.com，紧接着字符串的结尾）。

在这种情况下，我们将禁用警报。从命令行，编辑/etc/suricata/disable.conf文件并将 SID 添加到此文件。通常会添加注释，以便您可以跟踪删除各种签名的原因，何时以及由谁删除：

$ cat /etc/suricata/disable.conf
2028371    # firefox font attack false positive - disabled 7/5/2021 robv

要添加被忽略的规则，只需将 SID 添加到/etc/suricata/enable.conf文件中。

最后，再次运行suricata_update以更新 IPS 的运行配置。您将看到disable.conf文件已被处理：

$ sudo  suricata-update | grep disa
5/7/2021 -- 09:38:47 - <Info> -- Loading /etc/suricata/disable.conf

编辑 SID 的第二个选择是使其不会在特定 SNI 上触发更有意义，但你不能直接编辑 SID；下一个更新将简单地覆盖您的更新。要编辑 SID，请将其复制为“自定义”或“本地”范围内的 SID，然后进行编辑。将新的 SID 添加到enable.conf文件中。

回到我们的主要 EveBox 显示，打开任何事件并进行探索。您可以单击任何链接的值并获取有关其更多信息。例如，如果您怀疑内部主机已被入侵，您可以单击任何显示中该主机的 IP，并获取有关与该主机之间的所有流量的详细信息：

图 13.13 - EveBox 显示由一个目标主机触发的所有事件

请注意顶部的搜索字段 - 随着您对界面的熟悉程度越来越高，您可以根据需要手动输入这些内容。在这种情况下，我们可以看到一堆“无意义”的 DNS 请求（显示中的第 4、5 和 6 行，以及第 8、9 和 10 行）。这种无意义的查询经常出现在使用快速通道 DNS的攻击中，其中 C2 服务器的 DNS 名称一天内会多次更改。通常，客户端根据日期和时间计算 DNS 名称，或者定期检索它们。不幸的是，我们在广告世界的朋友们使用了许多与我们的恶意软件朋友们相同的技术，因此情况并不像以前那样清晰。

更改显示（单击用户 ID 旁边的右上角图标）可让您导航到Hunting显示。

在这个显示中，您将看到相同的警报，但是总结而不是按时间戳依次列出。这让您可以寻找最频繁的警报，或者寻找异常值 - 可能指示更不寻常情况的最不频繁的警报。

让我们再次查看我们的 Firefox 字体警报 - 打开该行以获取更多详细信息。特别是，您将看到一个时间轴显示：

图 13.14 – 搜索显示，主仪表板

请注意，这为我们提供了实际触发的规则：

alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"ET JA3 Hash - Possible Malware - Fake Firefox Font Update"; ja3_hash; content:"a0e9f5d64349fb13191bc781f81f42e1"; metadata: former_category JA3; reference:url,github.com/trisulnsm/trisul-scripts/blob/master/lua/frontend_scripts/reassembly/ja3/prints/ja3fingerprint.json; reference:url,www.malware-traffic-analysis.net; classtype:unknown; sid:2028371; rev:2; metadata:created_at 2019_09_10, updated_at 2019_10_29;)

基本上，这是“与此 JA3 哈希匹配的出站流量”。在ja3er.com上查找此哈希值，我们将发现这是来自以下用户代理的基本 Windows 10 TLS 协商：

• Excel/16.0（计数：375，最后查看：2021-02-26 07:26:44）

• WebexTeams（计数：38，最后查看：2021-06-30 16:17:14）

• Mozilla/5.0（Windows NT 6.1; WOW64; rv:40.0）Gecko/20100101 Firefox/40.1（计数：31，最后查看：2020-06-04 09:58:02）

这再次强调了这个签名的价值有限；我们最好是简单地禁用它。正如我们之前讨论的，您可能决定将其编辑为不同的规则，但在这种特殊情况下，您将永远在尝试获取正确的 SNI 字符串或 CA 的正确组合时进行捉迷藏。

另一个值得探索的显示是管理显示：

图 13.15 – 管理视图，所有警报

这以另一种格式显示相同的数据。点击相同的 Firefox 字体警报（2028371），我们将更全面地了解这个警报背后的活动：

图 13.16 – 示例 Firefox 字体警报的管理视图

请注意，在左侧列中，我们现在可以看到禁用规则和启用规则的选择。由于 IPS 界面主要在 UI 中，这更有可能成为您的主要规则管理方法，至少在禁用和启用规则方面是如此：

图 13.17 – 从 Web UI 禁用 Suricata 规则

正如之前提到的，IPS 功能是一个因人而异的领域。如果您在家庭网络上部署，不同的门铃、恒温器或游戏平台将极大地影响您的流量组合以及 IPS 将发现的结果。在企业环境中，情况更加戏剧性。

最好的建议是学习一些基础知识，其中我们在这里涵盖了一些，并探索您的 IPS 告诉您有关网络上发生的情况。您会发现一些要删除或修改的签名，您希望保留但从显示中抑制的消息，以及各种优先级的真实安全警报。

在这个平台上，您还会看到 Suricata 的严重级别可能与您的不匹配。我们探讨的规则就是一个很好的例子 - Suricata 将其标记为高优先级，但经过一些调查，我们将其归类为误报并将其禁用。

我们已经多次提到规则。因此，让我们深入了解规则是如何构建的，然后从头开始构建一个规则。

构建 IPS 规则

我们已经多次提到 IPS 签名，特别是 Snort 规则 - 让我们看看它们是如何构建的。让我们看一个示例规则，它会警报我们包含.cloud文本的可疑 DNS 请求：

alert dns $HOME_NET any -> any (msg:"ET INFO Observed DNS Query to .cloud TLD"; dns.query; content:".cloud"; nocase; endswith; reference:url,www.spamhaus.org/statistics/tlds/; classtype:bad-unknown; sid:2027865; rev:4; metadata:affected_product Any, attack_target Client_Endpoint, created_at 2019_08_13, deployment Perimeter, former_category INFO, signature_severity Major, updated_at 2020_09_17;)

规则分为几个部分。从规则的开头开始，我们有我们的规则头：

流部分不显示 - Suricata 通常只检测 TCP 数据的流。

接下来是规则的消息部分：

检测部分概述了规则正在寻找的内容以及将触发警报的流量：

参考部分通常包含 URL、CVE 编号或供应商安全公告：

签名 ID部分包含 SID 值和修订号：

元数据部分包括以下内容：

其中许多是可选的，在某些情况下，部分的顺序可以改变。有关 Suricata 规则格式的完整说明，产品文档是一个很好的起点：suricata.readthedocs.io/en/suricata-6.0.3/rules/intro.html。

由于 Suricata 规则基本上与 Snort 规则相同，因此您可能会发现 Snort 文档也很有用。

如果您为您的组织添加自定义规则，则本地规则的 SID 范围为1000000-1999999。

按照惯例，本地规则通常放在一个名为local.rules的文件中，或者至少放在反映此自定义状态的规则文件中。此外，规则消息通常以单词LOCAL、您的组织名称或其他使其明显是内部开发规则的指示符开头。填充规则元数据也被认为是一个良好的做法 - 添加规则的作者、日期和版本号可能非常有帮助。

例如，让我们创建一组规则，用于检测 telnet 流量 - 入站和出站。您可能已经添加了此规则，以解决组织中一群坚持部署启用 telnet 的敏感系统的管理员。使用 telnet 登录，然后运行或管理应用程序，是一种危险的方法，因为所有凭据和所有应用程序数据都以明文形式通过网络传输。

让我们将其分为两条规则：

alert tcp any -> $HOME_NET [23,2323,3323,4323] (msg:"LOCAL TELNET SUSPICIOUS CLEAR TEXT PROTOCOL"; flow:to_server; classtype:suspicious-login; sid:1000100; rev:1;)
alert tcp $HOME_NET any -> any [23,2323,3323,4323] (msg:"LOCAL TELNET SUSPICIOUS CLEAR TEXT PROTOCOL"; flow:to_server; classtype:suspicious-login; sid:1000101; rev:1;)

请注意，协议是 TCP，并且目标端口包括23/tcp，以及许多其他常见端口，人们可能会将 telnet 放入其中以“隐藏”它。

这些规则的文本被放入/etc/suricata/rules/local.rules（或者您想要存储本地规则的任何其他位置）。

更新/etc/suricata/suricata.yaml以反映这一点：

default-rule-path: /var/lib/suricata/rules
rule-files:
  - suricata.rules
  - local.rules

现在，要重新编译规则列表，请运行sudo selks-update。您可能还需要运行sudo suricata-update –local /etc/suricata/rules/local.rules。

更新后，您可以通过列出最终规则集并过滤您的 SID 来验证您的规则是否已就位：

$ cat /var/lib/suricata/rules/suricata.rules | grep 100010
alert tcp any -> $HOME_NET [23,2323,3323,4323] (msg:"LOCAL TELNET SUSPICIOUS CLEAR TEXT PROTOCOL"; flow:to_server; classtype:suspicious-login; sid:1000100; rev:1;)
alert tcp $HOME_NET any -> any [23,2323,3323,4323] (msg:"LOCAL TELNET SUSPICIOUS CLEAR TEXT PROTOCOL"; flow:to_server; classtype:suspicious-login; sid:1000101; rev:1;)

现在，要重新加载规则集，请执行以下操作之一：

• 通过执行sudo kill -USR2 $(pidof suricata)重新加载 Suricata。这不建议，因为它会重新加载整个应用程序。

• 使用suricatasc -c reload-rules重新加载规则。这是一个阻塞式的重新加载；Suricata 在重新加载期间仍然处于离线状态。如果您的 IPS 与流量处于一条线上，这是不建议的。

• 使用suricatasc -c ruleset-reload-nonblocking重新加载规则。这会在不阻止流量的情况下重新加载规则集，对于内联部署是“友好”的。

当触发时，此警报是什么样子？EveBox 中此规则的警报如下：

图 13.18 - 触发的自定义 IPS 规则生成的警报

在这里，我们可以看到警报中的一个是从内部到内部主机，而另一个是从内部到互联网的。第一个规则触发了两次 - 回顾一下规则定义；你能看出为什么吗？这表明，触发任何自定义规则并优化它们，使每个条件只触发一次警报或阻止，并且它们触发所有您能想到的条件和变化是很有意义的。

让我们扩展第一个（请注意 SID）：

图 13.19 - 警报 1 的事件详细信息

现在，让我们扩展第二个 - 请注意，这是相同的事件，但它以不同的 SID 触发了第二次：

图 13.20 - 警报 2 的事件详细信息

然后，扩展最后一个（再次，请注意 SID）：

图 13.21 - 警报 3 的事件详细信息

请注意，我们有这两个的完整数据包捕获 - 对这些要非常小心，因为您将在浏览这些 PCAP 文件时看到有效的凭据。

既然我们已经了解了网络 IPS 的工作原理，让我们看看通过被动监控数据包在网络中传递时我们能找到什么。

被动流量监控

另一种增强 IPS 解决方案的方法是使用被动漏洞扫描器（PVS）。与寻找攻击流量不同，PVS 解决方案收集数据包并寻找可能有助于识别正在使用的操作系统或应用程序的流量或握手数据（例如 JA3、SSH 指纹或任何可以以明文收集的数据）。您可以使用此方法来识别可能使用其他方法不会出现的问题应用程序，甚至使用其他清点方法可能会错过的主机。

例如，PVS 解决方案可能会识别过时的浏览器或 SSH 客户端。Windows 上的 SSH 客户端通常过时，因为许多更常见的客户端（如 PuTTY）没有自动更新功能。

PVS 解决方案也是发现可能没有被清点的主机的好工具。如果它连接到互联网甚至其他内部主机，PVS 工具可以仅从“流浪”数据包中收集令人惊讶的数据。

P0F 是更常见的开源 PVS 解决方案之一。在商业上，Teneble 的 PVS 服务器通常被部署。

使用 P0F 进行被动监控 - 示例

要运行 P0f，请将要使用的以太网接口设置为混杂模式。这意味着接口将读取和处理所有数据包，而不仅仅是目标为我们正在处理的主机的数据包。这是一个常见的模式，大多数依赖数据包捕获的实用程序会自动设置，但 P0F 仍然足够“老派”，需要手动设置。然后，运行该工具：

$ sudo ifconfig eth0 promisc
$ sudo p0f –i eth0
.-[ 192.168.122.121/63049 -> 52.96.88.162/443 (syn) ]-
|
| client   = 192.168.122.121/63049
| os       = Mac OS X
| dist     = 0
| params   = generic fuzzy
| raw_sig  = 4:64+0:0:1250:65535,6:mss,nop,ws,nop,nop,ts,sok,eol+1:df:0
|
`----
.-[ 192.168.122.160/34308 -> 54.163.193.110/443 (syn) ]-
|
| client   = 192.168.122.160/34308
| os       = Linux 3.1-3.10
| dist     = 1
| params   = none
| raw_sig  = 4:63+1:0:1250:mss*10,4:mss,sok,ts,nop,ws:df,id+:0
|
`----

更有用的是，您可以将p0f输出重定向到文件，然后处理文件的内容。请注意，我们需要 root 权限来捕获数据包：

$ sudo p0f -i eth0 -o pvsout.txt

接下来，我们可以收集在各个主机上收集的数据，使用grep来过滤只有p0f能够识别操作系统的主机。请注意，由于我们以 root 身份创建了pvsout.txt，我们将需要 root 权限来读取该文件：

$ sudo cat pvsout.txt | grep os= | grep -v ???
[2021/07/06 12:00:30] mod=syn|cli=192.168.122.179/43590|srv=34.202.50.154/443|subj=cli|os=Linux 3.1-3.10|dist=0|params=none|raw_sig=4:64+0:0:1250:mss*10,6:mss,sok,ts,nop,ws:df,id+:0
[2021/07/06 12:00:39] mod=syn|cli=192.168.122.140/58178|srv=23.76.198.83/443|subj=cli |os=Mac OS X|dist=0|params=generic fuzzy|raw_sig=4:64+0:0:1250:65535,6:mss,nop,ws,nop,nop,ts,sok,eol+1:df:0
[2021/07/06 12:00:47] mod=syn|cli=192.168.122.179/54213|srv=3.229.211.69/443|subj=cli |os=Linux 3.1-3.10|dist=0|params=none|raw_sig=4:64+0:0:1250:mss*10,6:mss,sok,ts,nop,ws:df,id+:0
[2021/07/06 12:01:10] mod=syn|cli=192.168.122.160/41936|srv=34.230.112.184/443|subj=cli|os=Linux 3.1-3.10|dist=1|params=none|raw_sig=4:63+1:0:1250:mss*10,4:mss,sok,ts,nop,ws:df,id+:0
[2021/07/06 12:01:10] mod=syn|cli=192.168.122.181/61880|srv=13.33.160.44/443|subj=cli |os=Windows NT kernel|dist=0|params=generic|raw_sig=4:128+0:0:1460:mss*44,8:mss,nop,ws,nop,nop,sok:df,id+:0

我们可以解析这个快速清单清单：

$ sudo cat pvsout.txt | grep os= | grep -v ??? | sed -e s#/#\|#g | cut -d "|" -f 4,9 | sort | uniq
cli=192.168.122.113|os=Linux 2.2.x-3.x
cli=192.168.122.121|os=Mac OS X
cli=192.168.122.129|os=Linux 2.2.x-3.x
cli=192.168.122.140|os=Mac OS X
cli=192.168.122.149|os=Linux 3.1-3.10
cli=192.168.122.151|os=Mac OS X
cli=192.168.122.160|os=Linux 2.2.x-3.x
cli=192.168.122.160|os=Linux 3.1-3.10
cli=192.168.122.179|os=Linux 3.1-3.10
cli=192.168.122.181|os=Windows 7 or 8
cli=192.168.122.181|os=Windows NT kernel
cli=192.168.122.181|os=Windows NT kernel 5.x

请注意，我们必须使用sed来删除每个主机的源端口，以便uniq命令能够工作。还要注意，主机192.168.122.181注册为三个不同的 Windows 版本 - 这个主机值得一看！

更令人担忧的是192.168.122.113、129和160上的主机，它们似乎在运行较旧的 Linux 内核。事实证明以下是真的：

• 192.168.122.160 是一个门铃摄像头 - 它启用了自动更新，所以它是一个较旧的内核，但是尽可能新。

• 192.168.122.129 是运营商的 PVR/电视控制器。这与之前的情况相同。

• 192.168.122.113是一个 Ubuntu 20.04.2 主机，所以这是一个误报。连接到该主机后，uname -r告诉我们正在运行内核版本 5.8.0.55。

现在我们已经安装了基本的 IPS 服务和 PVSes，所以让我们扩展一下，并添加一些元数据，使我们的 IPS 信息更有意义。我所说的“元数据”是什么？继续阅读，我们将描述这些数据，以及 Zeek 如何用于收集它。

Zeek 示例 - 收集网络元数据

Zeek（以前称为 Bro）实际上并不是 IPS，但它可以作为 IPS 的一个很好的附属服务器，用于日志记录平台以及网络管理。随着我们在本节中的进展，您将明白这是为什么。

首先，有几种安装选项：

• 您可以在现有的 Linux 主机上安装（docs.zeek.org/en/master/install.html）。

• 您可以安装安全 Onion 发行版并在安装过程中选择 Zeek（download.securityonion.net，docs.securityonion.net/en/2.3/installation.html）。安全 Onion 可能很有吸引力，因为它除了 Zeek 之外还安装了其他几个组件，这可能会为您提供更有用的工具集。

默认情况下，安全 Onion 安装时会与 Zeek 一起安装 Suricata，因此在较小的环境中，这是有道理的 - 同样，在同一主机上拥有这两个应用程序的信息也很方便。

记得我们说过 Zeek 是一个“元数据”收集器吗？一旦我们在实时网络上运行安全 Onion 几分钟，就会明白我的意思。为了种植一些“有趣”的数据，我启动了浏览器并导航到badssl.com。从那里，我测试了各种 SSL 错误条件：

图 13.22 - 使用 BADSSL.com 测试 SSL 错误检测

Bro 中显示了什么？从 Security Onion 主界面中，选择 Kibana，然后选择443中的 SSL 协议：

图 13.23 - 仅显示 SSL 数据

请注意，每个页面都可以独立翻页，并且原始日志立即显示在这些窗格下方。

在443中滚动，您将看到一些选项：

图 13.24 - 过滤出 443/tcp 端口

您可以单击**+仅过滤该值，或单击-从报告中删除此值。让我们将其删除，然后向下滚动到日志窗格。单击日志中的任何事件的>**图标以展开该特定会话的详细信息：

图 13.25 - 展开事件以显示完整元数据

向下滚动，您将看到地理位置数据（对于这个 IP 在地球上的确切位置的良好估计），以及此特定会话的 SSL 证书详细信息：

图 13.26 - 向下滚动，仅显示 SSL/TLS 证书元数据

在屏幕顶部，单击ssl以查看其中的内容：

图 13.27 - SSL 仪表板

选择Security Onion - SSL；我们将看到以下输出：

图 13.28 - 安全 Onion - SSL 仪表板

请注意，在页面中间，我们将看到实际的服务器名称。这些大部分都是从每次交互中涉及的 SSL 证书中收集的（尽管在其他仪表板中使用了反向 DNS）。让我们看看验证状态窗格 - 请注意我们有一些状态描述：

单击证书已过期，然后选择**+**以深入到只有该数据：

图 13.29 - 缩小搜索范围 - 仅过期的 SSL 证书

这使我们得到了涉及的确切交易，以及涉及人员的 IP！

请注意，当我们导航和深入时，您会看到许多屏幕上显示了搜索词字段，该字段显示了对 Elasticsearch 的原始查询。您可以随时手动添加它们，但使用 UI 可以在这方面提供很大的帮助。

让我们探索Kibana | Discover Analytics页面。一开始，我们将看到各种新信息：

图 13.30 - 流量的发现视图

在ssl中缩小搜索范围。您会看到它在您输入时给出匹配的搜索结果。

接下来，单击ssl.version和ssl.certificate.issuer，然后按更新：

图 13.31 - 显示所选的 SSL/TLS 信息

接下来，在字段区域中，输入source并将source.ip添加到我们的报告中：

图 13.32 - 通过添加更多信息构建我们的查询

您可以快速看到我们如何将显示范围缩小到我们想要的内容。

或者，我们可以按地理位置进行过滤。构建一个显示 TLS 版本、源 IP、目的 IP、国家和城市的列表：

图 13.33 - 将地理查找信息添加到查询中

现在，突出显示Country列中的US条目，并选择**-**以过滤掉美国目的地：

图 13.34 - 移除“US”目的地

这给我们提供了一个更有趣的列表：

图 13.35 - 最终查询

深入挖掘和处理数据可以迅速轻松地为您提供诸如“TLSv1.0 或更低版本，目的地在中国、俄罗斯或朝鲜”的显示。

甚至过滤 TLS 版本也可以迅速将您带到“未知”TLS 版本的候选名单。请注意，随时可以展开任何行以获取该会话的完整元数据：

图 13.36 - 仅未知的 TLS 版本

让我们探索第一行中的目的地 IP：

图 13.37 - 可疑 IP 的详细信息

还有谁使用 SSL 连接到该问题主机？在真实的安全事件中，您可以使用这种方法来回答重要的问题，比如“我们知道客户端 X 受到了影响；还有谁有类似的流量，以便我们可以看到这个问题是否更加普遍？”

图 13.38 - 具有相同可疑流量的其他内部主机

在这里，您可以看到诸如 SSL 版本、SSL 证书颁发者和目的地 IP 的国家代码等元数据如何可以快速为您提供一些有趣的信息。想象一下，有了成千上万个可用的搜索词，您可以挖掘得更深！

如果您正在探索流量以解决问题或正在处理安全事件，您可以看到收集流量元数据如何在获取有用信息方面非常有效 - 不仅关于已识别的主机和会话，还有关于可能受到影响的类似主机和会话的信息！

这只是冰山一角。您不仅可以深入研究 SSL/TLS 流量，还可以探索数百种其他协议！

总结

在本章中，我们讨论了几种检测和防止入侵事件的方法。我们首先讨论了这些各种技术在我们的架构中最适合的位置，然后进入了具体的解决方案。我们讨论了经典的基于网络的 IPS 解决方案，即 Snort 和 Suricata。我们还简要涉及了特定于 Web 的 IPS，特别是 WAF 和 RASP 解决方案。

在我们的示例中，我们介绍了 IPS（Suricata）如何被用来查找和防止安全问题，甚至创建自定义规则来检测或防止 telnet 会话。使用 P0f 来 passively 收集流量进行硬件和软件清单，以及安全问题的示例也得到了说明。最后，我们使用 Zeek 来获取我们收集的数据，并收集和计算元数据，使数据更有意义。特别是 Zeek 非常有用，可以深入研究网络流量，以找到可能指示安全事件或操作问题的异常情况。

在下一章中，我们将进一步扩展这种方法，从更被动的收集模型转向使用“蜜罐”方法，利用基于网络的“欺骗”来高度准确地找到恶意主机。

问题

最后，这里有一些问题供您测试对本章材料的了解。您将在附录的评估部分找到答案：

1. 如果我怀疑发生了数据外泄事件，并且使用了“未知”的 TLS 版本到特定国家，我应该使用哪个工具来查找受影响的内部主机？

2. 如果您知道您有大量使用 PuTTY SSH 客户端的 Windows 客户端机器，您如何进行清点而不搜索每台机器的本地存储？

3. 为什么您决定将 IPS 放在内部网络或实际防火墙上？

进一步阅读

在本章涵盖的主题上了解更多信息，您可以参考以下链接：

• SELKS 安装：github.com/StamusNetworks/SELKS/wiki/First-time-setup

• Security Onion 安装：docs.securityonion.net/en/2.3/installation.html

• Suricata 安装（6.0.0）：suricata.readthedocs.io/en/suricata-6.0.0/install.html

• Suricata 文档：suricata.readthedocs.io

• Snort 文档：www.snort.org/documents

• Snort 规则：snort.org/downloads/#rule-downloads

• JA3 指纹识别：ja3er.com

engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967

• HASSH：github.com/salesforce/hassh

• OpenRASP：github.com/baidu/openrasp

• ModSecurity：github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)modsemodse

• 负载均衡器上的 WAF 服务：www.haproxy.com/haproxy-web-application-firewall-trial/

• Zeek 文档：docs.zeek.org/en/master/

• Security Onion：securityonionsolutions.com/software