Network Traffic Analysis (NTA) 可以描述为检查网络流量以表征所使用的常见端口和协议的行为，为我们的环境建立基线，监控和应对威胁，并确保对我们组织的网络有最大程度的了解。

此过程可帮助安全专家及早发现网络中的异常情况（包括安全威胁），并有效地查明威胁。网络流量分析还可以促进满足安全准则的要求。攻击者频繁更新策略以规避检测，并使用大多数公司允许在其网络中使用的工具来利用合法凭据，这使得检测和随后的响应对防御者来说极具挑战性。在这种情况下，网络流量分析再次证明其作用。NTA 的日常用例包括：

试想一下，一个威胁行为者瞄准并渗透我们的网络。如果他们想要攻破网络，攻击者必然会与我们的基础设施进行交互和通信。网络通信通过许多不同的端口和协议进行，所有这些端口和协议都被员工、设备和客户同时使用。为了发现恶意流量，我们需要利用我们对自身区域内典型网络流量的了解。这样做可以缩小搜索范围，并帮助我们快速发现并阻止敌对通信。

例如，如果我们SYN在网络中从未（或很少）使用的端口上检测到许多数据包，我们就可以得出结论，这很可能是有人试图确定我们主机上哪些端口是开放的。此类行为是典型的恶意行为portscan。进行此类分析并得出此类结论需要特定的技能和知识。

所需技能和知识

我们即将列出和描述的技能需要长期积累的理论和实践知识。我们不必熟记所有内容，但当某些内容看起来不熟悉时，我们应该知道该寻找什么。这不仅适用于NTA，也适用于我们在网络安全中处理的大多数其他主题。

TCP/IP 堆栈和 OSI 模型

这种理解将确保我们掌握网络流量和主机应用程序如何交互。

基本网络概念

要了解每个层级上会出现哪些类型的流量，需要理解构成 TCP/IP 和 OSI 模型的各个层级，以及交换和路由的概念。如果我们在骨干链路上接入网络，会看到比平时多得多的流量，这与在办公室交换机上接入网络时看到的流量截然不同。

常用端口和协议

快速识别标准端口和协议并从功能上了解它们的通信方式将确保我们能够识别潜在的恶意或畸形的网络流量。

IP 数据包和子层的概念

了解 TCP 和 UDP 通信的基础知识至少能确保我们理解所见或所搜索的内容。例如，TCP 是面向流的，使我们能够轻松跟踪主机之间的对话。UDP 速度很快，但不注重完整性，因此很难从这种数据包类型中重建某些内容。

协议传输封装

每一层都会封装上一层。能够读取或分析封装何时发生变化将有助于我们更快地处理数据。根据封装头信息很容易找到提示。

环境与设备

以下列表包含许多可用于执行网络流量分析的不同工具和设备类型。每种工具和设备都提供不同的流量捕获或解析方式。有些工具提供复制和捕获的方式，而另一些则提供读取和提取的方式。本模块将仅探讨其中几种（主要是Wireshark和tcpdump）。请记住，这些工具并非专门为管理员设计的。其中许多工具也可能被用于恶意目的。

常见的流量分析工具

BPF 语法

上面提到的许多工具都有各自的语法和命令可供使用，但它们之间有一个共同点，那就是伯克利包过滤器 (BPF)语法。我们将主要使用这种语法。本质上，BPF 是一种允许原始接口从数据链路层进行读写的技术。考虑到所有这些，我们之所以关注 BPF，是因为它提供了过滤和解码功能。我们将在本模块中使用 BPF 语法，因此了解 BPF 过滤器的基本设置方法会很有帮助。有关 BPF 语法的更多信息，请参阅此参考资料。

执行网络流量分析

执行分析可以像在我们的控制台中观看实时流量一样简单，也可以像使用水龙头捕获数据一样复杂，将其发送回 SIEM 进行提取，并分析 pcap 数据以获取与常见策略和技术相关的签名和警报。

为了进行被动监听，我们至少需要连接到想要监听的网段。 在交换环境中尤其如此，因为 VLAN 和交换机端口不会将流量转发到其广播域之外。因此，如果我们希望捕获特定 VLAN 的流量，我们的捕获设备应该连接到同一网络。诸如网络分接头之类的设备、Span 端口之类的交换机或路由器配置以及端口镜像可以让我们获取流经特定链路的所有流量的副本，无论该流量属于哪个网段或目标。

NTA工作流程

流量分析并非一门精确的科学。网络流量分析 (NTA) 可能是一个非常动态的过程，并非一个直接的循环。它很大程度上受到我们所寻找的内容（网络错误还是恶意操作）以及我们对网络的可见性的影响。执行流量分析可以提炼出一些基本原则。

NTA工作流程

网络 - 第 1-4 层

本节将快速回顾网络知识，以及我们在执行流量捕获时可以看到的一些标准协议的工作原理。 这些概念是捕获和解析流量的核心。 如果不了解典型的网络流程以及所使用的端口和协议，我们就无法准确分析捕获的任何流量。

OSI / TCP-IP 模型

上图并排展示了开放系统互连 ( OSI) 模型和传输控制协议 - 互联网协议 ( TCP-IP) 模型。这两个模型以图形方式展示了联网计算机之间如何处理通信。让我们花点时间比较一下这两个模型：

在研究这两个模型时，我们会注意到 OSI 模型比 TCP-IP 模型更加细分。这是因为它被分解成更小的功能块。OSI 模型的第一层到第四层专注于控制主机之间的数据传输。这种控制涵盖了从用于传输的物理介质到用于管理数据传输过程中对话（或不对话）的协议的方方面面。 第五层到第七层负责对呈现给最终用户的封装数据进行解释、管理和呈现。 OSI 模型可以理解为万物运作背后的理论，而 TCP-IP 模型则更贴近网络的实际功能。TCP-IP 模型则更加融合，规则也更加灵活。TCP-IP 模型包含四层，其中 OSI 模型的第五层、第六层和第七层与 TCP-IP 模型的第四层相对应。第三层负责传输，第二层是互联网层，与 OSI 模型中的网络层相对应，第一层是链路层，涵盖了 OSI 模型的第二层和第一层。

在本模块中，我们将学习许多不同的协议数据单元 ( PDU，Protocol Data Units)，因此需要对其在理论上和实际应用中的功能性理解。PDU 是由 OSI 模型中各层封装的控制信息和数据组成的数据包。下面的分解部分将展示这两个模型中的各层如何与 PDU 进行匹配。

在检查 PDU 时，我们需要牢记封装的概念。随着数据在协议栈中向下移动，每一层都会将前一层的数据封装在一个我们称之为封装的新气泡中。这个气泡会将该层的必要信息添加到 PDU 的报头中。这些信息可能因层级而异，但都包含前一层的数据、操作标志、协商通信所需的任何选项、源 IP 地址和目标 IP 地址、端口、传输层协议以及应用层协议。

上图并排展示了 PDU 的构成以及 Wireshark 数据包详细信息窗格中数据包的分解。请注意，在 Wireshark 中查看分解时，顺序是相反的。Wireshark 反向显示 PDU，因为它的顺序与解封装时的顺序一致。

寻址机制

既然我们已经了解了驱动网络行为的基本概念，接下来让我们花点时间讨论一下如何将数据包传送到正确的主机。我们首先从媒体访问控制 (MAC) 地址开始。

MAC地址

连接到主机的每个逻辑或物理接口都有一个媒体访问控制 ( MAC) 地址。该地址是一个 48 位six octet地址，以十六进制格式表示。如下图所示，红色箭头处就是一个示例

MAC 寻址用于the data-link or link-layer depending on which model you look at主机之间的第二层 ( ) 通信。它通过广播域内的主机间通信实现。如果第二层流量需要跨越第三层接口，则该 PDU 将被发送到第三层出口接口，并路由到正确的网络。在第二层，这看起来像是将 PDU 发送到路由器接口，路由器在确定下一步将其发送到何处时会考虑第三层地址。一旦做出选择，它会剥离第二层的封装，并用指示路由中下一个物理地址的新信息替换它。

IP 寻址

互联网协议 ( IP) 的开发是为了跨越网络边界，将数据从一个主机传送到另一个主机。IP 负责路由数据包、封装数据，以及在数据报到达目标主机后对其进行分片和重组。IP 本质上是一种无连接协议，无法保证数据一定能够到达预期的接收者。为了确保数据传输的可靠性和有效性，IP 依赖于 TCP 等上层协议。目前，IP 主要有两个版本：IPv4（当前主流标准）和 IPv6（旨在取代 IPv4）。

IPv4

最常见、最熟悉的寻址机制是互联网协议地址版本 4 (IPv4)。IPv4 寻址是跨网络将数据包路由到我们周边区域以外的主机的核心方法。下图中绿色箭头所示的是一个 IPv4 地址示例。

IPv4 地址由一个 32 位的四字节数字组成，以十进制格式表示。在我们的示例中，我们可以看到地址 192.168.86.243。IP 地址的每个八位字节可以用一个从 0 到 255 的数字表示。在检查 PDU 时，我们会在 OSI 模型的第三层（网络层）和 TCP-IP 模型的第二层（互联网层）找到 IP 地址。我们不会在这里深入探讨 IPv4，但为了本模块的目的，我们先了解一下这些地址是什么，它们的作用是什么，以及它们在哪一层使用。

IPv6

在使用 IPv4 十多年后，我们发现可用的 IP 地址池很快就耗尽了。由于大量地址被划分为特殊用途或私有地址，全球的可用空间很快就被耗尽了。为了解决这个问题，我们采取了两项措施。首先是实施可变长度子网掩码 (VLSM) 和无类别域间路由 (CIDR)。这使我们能够重新定义 v4 格式的可用 IP 地址，从而改变地址分配给用户的方式。其次是创建并持续开发 IPv6 作为 IPv4 的后续版本。

IPv6 为我们提供了更大的地址空间，可用于任何网络用途。IPv6 是一个 128 位地址，以十六进制格式表示，包含 16 个八位字节。下图中蓝色箭头所示的是一个缩短的 IPv6 地址示例。

除了更大的地址空间外，IPv6 还提供：更好地支持多播（将流量从一个设备发送到多个设备）；每台设备全局寻址；以 IPSec 形式实现的协议内部安全性；简化的数据包报头，使处理和在连接之间移动更加轻松，而无需重新分配地址。 IPv6 在其架构中使用四种主要类型的地址：

IPv6 寻址类型

在思考每种地址类型时，记住单播流量是主机到主机的，多播是一对多的，而任播是群组中的一对多，只有一个会应答数据包（类似负载平衡）。 尽管 IPv6 目前比 IPv4 具有许多优势，但其普及速度却很慢。

IPv6的采用

在撰写本文时，根据谷歌发布的统计数据，全球采用率仅为 45% 左右。

TCP/UDP，传输机制

传输层拥有多种机制，有助于确保数据从源到目标的无缝传输。不妨将传输层视为一个控制中心。来自较高层级的应用数据必须沿着协议栈向下传输到传输层。该层指示如何封装流量并将其发送到较低层级的协议（IP 和 MAC）。数据到达目标接收者后，传输层将与网络层协议协同工作，按正确的顺序重新组装封装的数据。用于完成此任务的两种机制是传输控制协议 (TCP) 和用户数据报协议 (UDP)。

TCP VS. UDP

通过查看上表，我们可以看到 TCP 和 UDP 提供了两种截然不同的数据传输方式。TCP 被认为是一种更可靠的协议，因为它允许将错误检查和数据确认作为常规功能。相比之下，UDP 是一种快速、即发即弃的协议，最适合于我们更注重速度而非质量和验证的情况。

具体来说，TCP 用于传输对完整性而非速度要求更高的数据。例如，当我们使用安全外壳 (SSH) 从一个主机连接到另一个主机时，会打开一个连接，该连接在您发出命令和执行操作时保持活动状态。这是 TCP 的一项功能，确保我们与远程主机的对话不会中断。如果由于某种原因中断，TCP 不会重新组装数据包的部分片段并将其发送给应用程序。我们可以通过这种方式避免错误。如果我们在远程主机上执行类似 sudo passwd user 的命令来更改用户密码，并且在更改过程中部分消息丢失，会发生什么情况？如果通过 UDP 进行传输，我们将无法知道该消息的其余部分发生了什么，并可能弄乱用户的密码，甚至发生更糟的情况。TCP 协议通过确认收到的每个数据包来帮助防止这种情况发生，以确保目标主机在组装命令并将其发送给应用程序执行操作之前已获取每个数据包。

另一方面，当我们需要快速响应或使用对速度而非完整性要求更高的应用程序时，UDP 就是我们的答案。以流式传输视频为例。用户不会注意到流式传输视频中丢失了一两个像素。 我们更关心的是观看视频，而不是让它不断停下来缓冲下一个片段。另一个例子是 DNS。当主机请求 inlanefreight.com 的记录条目时，该主机希望快速响应以继续其正在执行的进程。如果 DNS 请求被丢弃，最糟糕的情况是它会被重新发出。这没有损害，也没有犯规。用户不会因为这种丢弃而收到损坏的数据。 UDP 流量看起来像常规流量；它是一个单独的数据包，没有响应或确认已发送或接收，因此这里没有太多可展示的内容。但是，我们可以看看 TCP 以及它是如何建立连接的。

TCP 三次握手

TCP 确保数据从服务器传输到客户端的方法之一是利用会话。这些会话通过所谓的三次握手建立。为了实现这一点，TCP 在 TCP 报头中使用了一个名为“标志”的选项。我们现在不会深入探讨 TCP 标志；只需了解三次握手中常见的标志是同步 ( SYN) 和确认 ( ACK)。当主机请求通过 TCP 与服务器进行对话时；

让我们快速看一下它的运行情况，以便在模块稍后出现在数据包输出中时熟悉它。

检查此输出时，我们可以在第一行看到握手的开始。查看红框中突出显示的信息，我们可以看到初始 Syn 标志已设置。如果我们查看绿色下划线的端口号，我们可以看到两个数字：57678 和 80。第一个数字是客户端正在使用的随机高端口号，第二个数字是服务器用于监听传入 Web 请求连接的 HTTP 公认端口。在第二行，我们可以看到服务器向客户端发送了一个 SYN/ACK 数据包，该数据包发送到相同的端口。在第三行，我们可以看到客户端确认了服务器的同步数据包以建立连接。

数据包 4 显示 HTTP 请求已发送，并且已建立会话以流式传输所请求图像的数据。我们可以看到，随着数据流的继续，TCP 会对发送的每个数据块发送确认。这是一个典型的 TCP 通信示例。

我们已经了解了如何使用 TCP 建立会话；现在，让我们研究一下如何结束会话。

TCP 会话拆除

实际上应该是四次挥手

详细可以看我的这篇文章Nginx开发实战——网络通信（一）Wireshark监视数据包

网络 - 第 5-7 层

我们已经了解了底层网络的功能，现在让我们看看一些处理应用程序的上层协议。维护网络连接并确保数据在主机之间传输需要许多不同的应用程序和服务。本节将概述其中几个重要的协议。

HTTP

超文本传输协议 (HTTP) 是一种无状态的应用层协议，自 1990 年开始使用。HTTP 支持通过 TCP 在客户端和服务器之间以明文传输数据。客户端会向服务器发送 HTTP 请求，请求资源。会话建立后，服务器会响应请求的媒体（HTML、图像、超链接、视频）。HTTP 在正常操作期间通过 TCP 使用端口 80 或 8000。在特殊情况下，可以修改为使用其他端口，有时甚至使用 UDP。

HTTP 方法

要执行诸如获取网页、请求下载项目或发布最新推文等操作，都需要使用特定的方法。这些方法定义了请求 URI 时执行的操作。方法：

请注意，我们在每个方法旁边都列出了必需或可选。根据标准要求，GET 和 HEAD 必须始终与标准 HTTP 实现兼容并存。这仅适用于它们。trace、options、delete、put 和 post 方法则是可选功能，可以允许使用。例如，只读网页（例如博客文章）。客户端 PC 可以从页面请求资源，但不能修改、添加或删除资源。

有关 HTTP 作为协议及其运作方式的更多信息，请参阅 RFC:2616。

HTTPS

HTTP 安全协议 (HTTPS) 是对 HTTP 协议的一种改进，旨在利用传输层安全性 (TLS，Transport Layer Security) 或安全套接字层 (SSL，Secure Sockets Layer) 与旧应用程序配合使用，以保障数据安全。TLS 是一种加密机制，用于保护客户端和服务器之间的通信。TLS 可以将常规 HTTP 流量封装在 TLS 中，这意味着我们可以加密整个会话，而不仅仅是发送或请求的数据。在 TLS 机制出现之前，我们很容易受到中间人攻击和其他类型的侦察或劫持攻击，这意味着与客户端或服务器位于同一局域网中的任何人如果在线监听，都可以查看网络流量。现在，我们可以在浏览器中实施安全措施，使每个人都可以加密他们的网络行为、搜索请求、会话或数据传输、银行交易等等。

尽管 HTTPS 是基于 HTTP 的，但它使用 443 和 8443 端口，而不是标准的 80 端口。这是一种客户端向服务器发出信号以表明其希望建立安全连接的方式。让我们看一下 HTTPS 流量的输出，并了解一下 TLS 握手是如何运作的。

通过 HTTPS 进行 TLS 握手

在前几个数据包中，我们可以看到客户端使用蓝色方框中标示的 443 端口与服务器建立了会话。这向服务器发出信号，表明它希望使用 HTTPS 作为应用程序通信协议。

通过 TCP 发起会话后，接下来会发送 TLS ClientHello 消息，开始 TLS 握手。在握手过程中，双方会协商几个参数，包括会话标识符、对端 x509 证书、要使用的压缩算法、密码规范加密算法（如果会话可恢复），以及客户端和服务器之间共享的用于验证会话的 48 字节主密钥。

会话建立后，所有数据和方法都将通过 TLS 连接发送，并显示为红色方框中所示的 TLS 应用程序数据。 TLS 仍然使用 TCP 作为传输协议，因此我们仍然会看到来自流的确认数据包通过端口 443 发送。 握手过程总结：

加密本身是一个复杂而冗长的话题，值得专门写一个模块来阐述。本节简单概述了 HTTP 和 TLS 如何在 HTTPS 应用协议中提供安全性。有关 HTTPS 的工作原理以及 TLS 如何执行安全操作的更多信息，请参阅 RFC:2246。

FTP

文件传输协议 (FTP) 是一种应用层协议，支持在计算设备之间快速传输数据。FTP 可以通过命令行、Web 浏览器或图形化 FTP 客户端（例如 FileZilla）使用。FTP 本身被认为是一种不安全的协议，大多数用户已转而使用 SFTP 等工具通过安全通道传输文件。展望未来，大多数现代 Web 浏览器已于 2020 年逐步停止支持 FTP。

当我们考虑主机之间的通信时，我们通常会想到客户端和服务器通过单个套接字进行通信。通过此套接字，客户端和服务器都通过同一条链路发送命令和数据。在这方面，FTP 的独特之处在于它同时使用多个端口。FTP 通过 TCP 使用端口 20 和 21。端口 20 用于数据传输，而端口 21 用于发出控制 FTP 会话的命令。在身份验证方面，FTP 支持用户身份验证，并且如果已配置，还允许匿名访问。

FTP 能够以两种不同的模式运行：主动模式和被动模式。主动模式是 FTP 的默认操作方式，这意味着服务器会监听来自客户端的控制命令 PORT，该命令指示使用哪个端口进行数据传输。被动模式使我们能够访问位于防火墙后面或启用了 NAT 的链路（这些链路无法建立直接 TCP 连接）的 FTP 服务器。在这种情况下，客户端会发送 PASV 命令，并等待服务器的响应，告知客户端使用哪个 IP 地址和端口进行数据传输通道连接。

FTP 命令和响应示例

上图展示了几个通过 FTP 命令通道发出的请求（绿色箭头）以及从 FTP 服务器返回的响应（蓝色箭头）的示例。这些都是非常标准的操作。要查看每个命令及其功能的列表，请查看下表。

查看 FTP 流量时，我们可以看到通过端口 21 传递的一些常见命令包括：

FTP 命令

以上并非可能出现的 FTP 控制命令的详尽列表。这些命令可能因所使用的 FTP 应用程序或 Shell 而异。有关 FTP 的更多信息，请参阅 RFC:959。

SMB

服务器消息块 (SMB) 是 Windows 企业环境中最常用的协议，它支持通过常见的网络架构在主机之间共享资源。SMB 是一种面向连接的协议，要求主机向资源进行用户身份验证，以确保用户拥有使用该资源或执行操作的正确权限。过去，SMB 使用 NetBIOS 作为通过 UDP 端口 137 和 138 的传输机制。经过现代化的改进，SMB 现在支持通过端口 445 的直接 TCP 传输、通过 TCP 端口 139 的 NetBIOS 传输，甚至支持 QUIC 协议。

作为用户，SMB 使我们能够轻松便捷地访问打印机、共享驱动器、身份验证服务器等资源。因此，SMB 对潜在攻击者也极具吸引力。

与任何其他使用 TCP 作为传输机制的应用程序一样，它会执行标准功能，例如三次握手和确认收到的数据包。让我们花点时间了解一些 SMB 流量，以便熟悉它。

SMB 线路

从上图可以看出，每次建立会话时，橙色框中的端口都会执行 TCP 握手。查看蓝色框中的源端口和目标端口，可以看到端口 445 正在被使用，这表明 SMB 流量通过 TCP 进行。查看绿色框中的信息字段，可以了解到 SMB 通信中发生的情况。此示例中存在许多错误，值得深入研究。用户身份验证失败一两次的情况比较常见，但大量错误重复出现可能表明潜在的未经授权的用户试图访问用户的帐户或使用其凭据进行移动。这是攻击者常用的策略，他们会获取已通过身份验证的用户，窃取其凭据，利用这些凭据进行横向移动，或访问通常被拒绝访问的资源。

这只是 SMB 使用情况的一个例子。我们经常看到的另一个情况是服务器和主机之间的文件共享访问。在大多数情况下，这是常规通信。但是，如果我们看到一个主机访问其他主机上的文件共享，则这种情况并不常见。请注意谁在请求连接、去往何处以及他们在做什么。

之后我会持续更新，如果喜欢我的文章，请记得一键三连哦，点赞关注收藏，你的每一个赞每一份关注每一次收藏都将是我前进路上的无限动力 ！！！↖(▔▽▔)↗感谢支持！