SMB2协议特性之oplock与lease(下

news2025/1/18 17:08:10

前期回顾

上篇文章我们介绍了oplock/lease的相关概念及其基本工作原理，由于间隔时间较长，忘记的读者可以先去回顾一下。本篇文章带大家了解一下，在实际场景中，oplock/lease是如何工作的。

实际场景分析

在一些警匪影视剧中，我们可能看到过这类场景，警方通过监听嫌疑人的电话，来获取有用信息，从而为警方的下一步行动提供依据。类似地，我们可以通过网络抓包工具（如tcpdump，wireshark等）来“监听”SMB2协议的客户端与服务端的通信内容，然后对它们之间传递的控制信息加以分析，从而了解它们是如何工作的。

接下来分几个场景看看：

（1）单客户端场景

（2）多客户端场景

（3）oplock关闭场景

这里的每个场景都是独立的，它们之间互不干扰。

在上述场景中，客户端系统采用Windows 10（企业版），服务端系统采用CentOS 7.9，SMB2 协议服务端软件使用开源软件Samba。网络抓包工具使用tcpdump，分析网络数据包使用具有图形界面的wireshark。此外，为了区分只读类型和读写类型请求，我们以执行程序的方式来替代手动操作方式，客户端执行的Python程序代码如下（openfile.py）：

（一）单客户端场景

→ 场景描述

单客户端依次以只读和读写方式打开SMB2共享目录下的同一个文件。

→ 操作步骤

在一个Windows 10系统上，挂载SMB2共享目录到本地Z盘，分别打开两个命令提示符，依次执行python openfile.py ro和python openfile.py rw命令，抓取该过程的网络通信数据包截图如下（已过滤掉无关的非SMB2数据包）：

→ 数据包分析

首先对上图做下简单说明，整体一行代表一次SMB2请求或者响应，No.列代表网络数据包或数据帧编号，Source列是发送方地址，Destination列是接收方地址，Protocol列是协议版本，Info列是所执行操作的描述信息。

其中，客户端以只读方式打开文件时，发出的lease请求（作为SMB2 Create请求（即数据包4）的一部分，相当于子请求）的展开信息如下图：

其中Lease Key是客户端生成的唯一标识，用于表示lease的所有者。Lease State一行代表所请求的lease类型，可以看到，即使应用程序以只读方式打开文件，SMB2客户端协议也会请求最高类型的lease（即RWH lease）。对应的响应（数据包6）的展开信息如下图：

可以看到，服务端返回的也是最高类型的lease，这个比较好理解，因为当前只有一个进程访问这个文件，相当于独占这个文件。然后，客户端运行一个新进程以读写方式打开该文件时（注意此时之前的只读访问并未退出，而是处于睡眠中），lease请求的展开信息如下图，请求的同样是RWH lease：

该请求的响应信息展开如下图，可以看到，服务端返回的也是最高类型的lease。

总结一下，单客户端多次打开同一个文件，每次都会请求RWH lease，并且授予的也都是RWH lease，不论是以只读还是读写方式打开文件。

（二）多客户端场景

→ 场景描述

两个不同的客户端（比如A和B）依次对同一个SMB2共享目录下的同一个文件（如f1.txt）进行只读操作。

→ 操作步骤

在两个不同的Windows 10系统上，挂载同一个SMB2共享目录到各自本地Z盘，都打开一个命令提示符，依次执行python openfile.py ro命令，在服务端抓取该过程的网络通信数据包截图如下（已过滤掉无关的非SMB2数据包）：

→ 数据包分析

首先，客户端A（172.26.57.51）的lease请求展开如下图：

可以看到，申请的是最高类型lease，对应的服务端响应如下：

此时没有其他客户端访问该文件，相当于单客户端场景，服务端返回最高类型lease，并赋予lease epoch（即版本号）为1。客户端B（172.26.57.53）的lease请求信息如下：

可以看到，同样也是申请的最高类型lease。但是下一个数据包却是Lease break notification（如下图），而不是lease响应，这是为什么呢？原因是有其他客户端访问了同一个文件，“打破”了当前客户端A对文件的“独占”状态（RWH lease相当于独占），而为了保证多客户端数据访问的一致性，服务端必须先通知客户端A，调整其当前lease类型。