网络防火墙开发二三事

网络防火墙开发二三事
- haoxg -

花了近一个月的时间研究 Windows 平台下的网络防火墙相关技术，并实现了一个简单的防火墙。在独自摸索的过程中，由于以往的开发经历从未涉及此领域，所以碰到了不少困难，也走了些弯路。现此项目暂告一段，遂将相关心得整理成文。文章以归纳总结为主，没有创新性技术，高手免看。

◎ 防火墙的数据包拦截方式小结

网络防火墙都是基于数据包的拦截技术之上的。在 Windows 下，数据包的拦截方式有很多种，其原理和实现方式也千差万别。总的来说，可分为“用户级”和“内核级”数据包拦截两大类。

用户级下的数据包拦截方式有：

* Winsock Layered Service Provider (LSP)。
* Win2K 包过滤接口 (Win2K Packet Filtering Interface)。
* 替换 Winsock 动态链接库 (Winsock Replacement DLL)。

内核级下的数据包拦截方式有：

* TDI过滤驱动程序 (TDI-Filter Driver)。
* NDIS中间层驱动程序 (NDIS Intermediate Driver)。
* Win2K Filter-Hook Driver。
* Win2K Firewall-Hook Driver。
* NDIS-Hook Driver。

在这么多种方式面前，我们该如何决定采用哪一种作为自己项目的实现技术？这需要对每一种方式都有一个大致的了解，并清楚它们各自的优缺点。技术方案的盲目选用往往会带来一些技术风险。以自己为例，我需要在截包的同时得到当前进程文件名，也就是说，需向用户报告当前是哪个应用程序要访问网络。在选用 Win2K Filter-Hook Driver 这一方案之后(很多小型开源项目都采用这一方案)，便开始编码。但之后发现 Win2K Filter-Hook Driver 的截包上下文处于内核进程中，即 IRQL >= DISPATCH_LEVEL，根本无法知道当前应用程序的名字。相比之下，TDI-Filter Driver 和 NDIS-Hook Driver 则可以得知这些信息。其中 TDI-Filter Driver比 NDIS-Hook Driver 更能准确地获知当前应用程序文件名，后者的接收数据包和少数发送数据包的场景仍然处于内核进程中。

下面列出了各种截包方式的特点：

* Winsock Layered Service Provider (LSP)
  该方式也称为 SPI (Service Provider Interface) 截包技术。SPI是由 Winsock2 提供的一个
  接口，它需要用户机上安装有 Winsock 2.0。Winsock2 SPI 工作在 API 之下的 Driver 之上，可以截获所有基于 Socket 的网络数据包。
  优点：
  * 以DLL形式存在，编程方便，调试简单。
  * 数据封包比较完整，未做切片，便于做内容过滤。
  缺点：
  * 拦截不够严密，对于不用 Socket 的网络通讯则无法拦截 (如 ICMP)，木马病毒很容易绕过。

* Win2K Packet Filtering Interface
  这是 Win2K 中一组 API 提供的功能 (PfCreateInterface, PfAddFiltersToInterface, …)。
  优点：
  * 接口简单，实现起来没什么难度。
  缺点：
  * 功能过于简单，只能提供IP和端口的过滤，可能无法满足防火墙的复杂需求。
  * 处于 API 层，木马病毒容易绕过。
  * 只能在 Win2K 以上(含)系统中使用。

* Winsock Replacement DLL
  这种方法通过替换系统 Winsock 库的部分导出函数，实现数据报的监听和拦截。
  缺点：
  * 由于工作在 Winsock 层，所以木马病毒容易绕过。

* TDI-Filter Driver
  TDI 的全称是 Transport Driver Interface。传输层过滤驱动程序通过创建一个或多个设备对象  直接挂接到一个现有的驱动程序之上。当有应用程序或其它驱动程序调用这个设备对象时，会首先映射到过滤驱动程序上，然后由过滤驱动程序再传递给原来的设备对象。
  优点：
  * 能获取到当前进程的详细信息，这对开发防火墙尤其有用。
  缺点：
  * 该驱动位于 tcpip.sys 之上，所以没有机会得到那些由 tcpip.sys 直接处理的包，比如ICMP。
  * TDI驱动需要重启系统方能生效。

* NDIS Intermediate Driver
  也称之为 IM Driver。它位于协议层驱动和小端口驱动之间，它主要是在网络层和链路层之间对所有的数据包进行检查，因而具有强大的过滤功能。它能截获所有的数据包。可参考DDK中附带的例子 Passthru。
  优点：
  * 功能非常强大，应用面广泛，不仅仅是防火墙，还可以用来实现VPN，NAT 和 VLan 等。
  缺点：
  * 编程复杂，难度较大。
  * 中间层驱动的概念是在 WinNT SP4 之后才有的，因此 Win9X 无法使用。
  * 不容易安装，自动化安装太困难。

* Win2K Filter-Hook Driver
  这是从 Win2K 开始提供的一种机制，该机制主要利用 ipfiltdrv.sys 所提供的功能来拦截网络数据包。Filter-Hook Driver 的结构非常简单，易于实现。但是正因为其结构过于简单，并且依赖于 ipfiltdrv.sys，微软并不推荐使用。可参考 CodeProject 上的例子：http://www.codeproject.com/KB/IP/drvfltip.aspx
  优点：
  * 结构简单，易于实现。
  * 能截获所有的IP包(包括ICMP包)。
  缺点：
  * 工作于内核进程中，无法取得当前应用程序进程的信息。
  * 虽能截获所有IP包，但无法取得数据包的以太帧(Ethernet Frame)。
  * 只能在 Win2K 以上(含)系统中使用。

* Win2K Firewall-Hook Driver
  这是一种和 Win2k Filter-Hook Driver 差不多的机制，所不同的是，Firewall-Hook Driver
  能在 IP Driver 上挂接多个回调函数，所以和前者相比，它引起冲突的可能性更小一些。
  可参考 CodeProject 上的例子：http://www.codeproject.com/KB/IP/FwHookDrv.aspx
  这种方式的优缺点和 Win2K Filter-Hook Driver 基本相同。

* NDIS-Hook Driver
  这是一种要重点讲述的截包方式。它是目前大多数网络防火墙所使用的方法。这种方式的做法是安装钩子到 ndis.sys 中，替换其中的某些关键函数，从而达到截包的目的。在下一节中我们将详细地介绍它的实现方法。
  优点：
  * 安装简单，可即时安装和卸载驱动，无需重启系统。
  * 能截获所有的IP包，同时能取得数据包的以太帧(Ethernet Frame)。
  * 安全性高，木马病毒不容易穿透。
  * 在大多数情况下，能获取到当前应用程序的进程信息。
  * 能在 Win98 以上(含)系统中使用。
  缺点：
  * 接收数据包、或偶尔发送数据包时，驱动工作在内核进程中，无法获得应用程序进程信息。

◎ NDIS-Hook 技术

微软和 3COM 公司在1989年制定了一套开发 Windows 下网络驱动程序的标准，称为 NDIS。NDIS 的全称是 Network Driver Interface Specification。NDIS为网络驱动的开发提供了一套标准的接口，使得网络驱动程序的跨平台性更好。

NDIS提供以下几个层次的接口：
1. NDIS 小端口驱动 (NDIS Miniport Driver)。这也就是我们常说的网卡驱动。
2. NDIS 协议驱动 (NDIS Protocol Driver)。用来实现某个具体的协议栈，如 TCP/IP 协议栈，并向上层导出 TDI 接口。
3. NDIS 中间层驱动 (NDIS Intermediate Driver)。这是位于小端口驱动和协议驱动之间的驱动。

NDIS为了给出上述三种接口，提供了一个系统的、完整的 Wrapper。这个 Wrapper 即 ndis.sys。上面提到的 Miniport Driver、Protocol Driver、Intermediate Driver 均属于插入到这个Wrapper 中的“模块”，它们调用 Wrapper 提供的函数，同时也向 Wrapper 注册回调函数。

在简单了解了NDIS的机制之后，不难得知，网络防火墙只需要将自己的函数挂钩(Hook)到 ndis.sys中即可截获网络数据包。NDIS-Hook 技术有两种实现方案：

1. 修改 ndis.sys 的 Export Table。

在 Win32 下，可执行文件(EXE/DLL/SYS)都遵从PE格式。所有提供接口的驱动都有 Export Table，因此只要修改 ndis.sys 的 Export Table，就可实现对关键函数的挂接。在实现步骤中，首先需要得到 ndis.sys 的内存基址，再根据PE格式得到DOS头部结构(IMAGE_DOS_HEADER)，进一步得到NT头部结构(IMAGE_NT_HEADER)，最后从头部结构中查得 Export Table 的地址。

由于协议驱动程序(NDIS Protocol Driver)在系统启动时会调用 NdisRegisterProtocol() 来向系统注册协议，因此这种方法关键在于修改 ndis.sys 所提供的 NdisRegisterProtocol、
NdisDeRegisterProtocol、NdisOpenAdapter、NdisCloseAdapter、NdisSend 这几个函数的地址。对于处于系统核心的 ndis.sys 而言，要修改它的内存区域，只有驱动程序才能做到，所以我们必须编写驱动程序来达到这个目的。

该方案的缺点是加载或卸载驱动后无法立即生效，必须重启系统。且挂钩方法较为复杂。早期凡使用 NDIS-Hook 的防火墙都采用这一方法，包括著名的费尔防火墙的早期版本(v2.1)。直到 2004 年，www.rootkit.com 上一名黑客公布了一种全新的 NDIS-Hook 技术(即下文即将提到的第2种方法)，诸多防火墙产品才都悄悄对自己的核心技术进行了升级。由于新的挂钩技术更好，故本文不打算详述修改 Export Table 这一方法的具体细节。

2. 向系统注册假协议(Bogus Protocol)。

NDIS提供了一个API: NdisRegisterProtocol()，这个API的职责是向系统注册一个协议(如TCPIP)，并将该协议作为一个链表节点插入到“协议链表”的头部，最后返回该链表头节点(即新节点)的地址。正常情况下，只有NDIS协议驱动程序(NDIS Protocol Driver)才会调用这个API。

既然如此，如果我们也调用 NdisRegisterProtocol() 向系统注册一个新的协议，我们也就能轻易地得到“协议链表”的首地址，通过走访这个链表，就能修改其中的某些关键信息，比如关键函数的地址。修改完毕后，再调用 NdisDeRegisterProtocol() 注销掉新协议。这看似一切都没发生，但事实上目的已经达到了。这个新协议我们称之为假协议(Bogus Protocol)。

通过这种方法，我们可以不用重启系统就能轻松挂接截包函数。当今大多数网络防火墙都采用了这一方法。近来网上又有人提出了获取协议链表首地址的新的怪异途径，比如获取 tcpip.sys 中全局变量 _ARPHandle 值的方法。不管怎样，相比之下，注册假协议仍不失为一种经典且简单的方法。

本文将详细叙述第2种方案的内部原理和实现细节，即通过注册假协议获取协议链表首地址，遍历链表并修改其中的函数地址，挂钩自己的函数，从而实现网络截包。在这么做之前，需要先对NDIS内部维护的几个结构有清楚的认识。另外，由于历史原因，NDIS存在诸多并不完全向下兼容的版本，不同的版本中关键数据域的偏移地址也不尽相同。微软并没有以文档形式提供这些变化的列表。本文稍后给出这些变化。

* NDIS_PROTOCOL_BLOCK 和 NDIS_OPEN_BLOCK

在NDIS中，所有已注册的协议是通过一个单向的协议链表来维护的。这个单向链表保存了所有已注册的协议，每个协议对应一个节点。链表节点由 NDIS_PROTOCOL_BLOCK 结构来描述，在这个结构中保存了注册协议驱动时所指定的各种信息，如支持协议即插即用的回调函数地址等。同时，每个协议驱动还对应一个 NDIS_OPEN_BLOCK 节点结构的单向链表来维护其所绑定的网卡信息，协议驱动发送和接收数据包的回调函数地址就保存在这个结构中，是我们要重点修改的对象。

协议与网卡绑定的示意图如下：

              ┌───┐
              │ Head │
              └─┬─┘
                      ↓
    ┌──────────────┐      ┌───────────┐
    │ TCPIP Protocol Block                 ├→│ RTL8168 Open Block      │
    └──────┬───────┘      └─────┬─────┘
                              ↓                                                           ↓
    ┌──────────────┐      ┌───────────┐
    │ TCPIP_WANARP Protocol Block│      │ Wireless Open Block       │
    └──────┬───────┘      └─────┬─────┘
                              ↓                                                           ↓         
                     ┌───┐                                           ┌───┐
                     │ NULL │                                           │ NULL │
                     └───┘                                            └───┘

* 得到 NDIS_PROTOCOL_BLOCK 链表的首地址

上文已提到，通过向系统注册假协议，我们即可得到协议链表的首地址。从DDK中可查到 NdisRegisterProtocol() 的原型：

EXPORT
    VOID
    NdisRegisterProtocol(
        OUT PNDIS_STATUS   Status,
        OUT PNDIS_HANDLE   NdisProtocolHandle,
        IN  PNDIS_PROTOCOL_CHARACTERISTICS ProtocolCharacteristics,
        IN  UINT           CharacteristicsLength
        );

可以看出，我们在调用它时需要传入一个结构 NDIS_PROTOCOL_CHARACTERISTICS，这个结构是我们在注册协议时必须填写的一张表格，这个表格描述了协议的相关信息。不过既然我们注册的是一个假协议，所以可以尽量简单地填写它。

NDIS_STATUS
    DummyNdisProtocolReceive(
        IN NDIS_HANDLE ProtocolBindingContext,
        IN NDIS_HANDLE MacReceiveContext,
        IN PVOID HeaderBuffer,
        IN UINT HeaderBufferSize,
        IN PVOID LookAheadBuffer,
        IN UINT LookAheadBufferSize,
        IN UINT PacketSize
        )
    {
        return NDIS_STATUS_NOT_ACCEPTED;
    }

NDIS_HANDLE
    RegisterBogusNdisProtocol(void)
    {
        NTSTATUS Status = STATUS_SUCCESS;
        NDIS_HANDLE hBogusProtocol = NULL;
        NDIS_PROTOCOL_CHARACTERISTICS BogusProtocol;
        NDIS_STRING ProtocolName;

NdisZeroMemory(&BogusProtocol, sizeof(NDIS_PROTOCOL_CHARACTERISTICS));
        BogusProtocol.MajorNdisVersion = 0×04;
        BogusProtocol.MinorNdisVersion = 0×0;

NdisInitUnicodeString(&ProtocolName, L”BogusProtocol”);
        BogusProtocol.Name = ProtocolName;
        BogusProtocol.ReceiveHandler = DummyNdisProtocolReceive;

NdisRegisterProtocol(&Status, &hBogusProtocol, &BogusProtocol,
            sizeof(NDIS_PROTOCOL_CHARACTERISTICS));

if (Status == STATUS_SUCCESS) return hBogusProtocol;
        else return NULL;
    }

函数 RegisterBogusNDISProtocol() 的返回值即是我们想要的协议链表首地址。不过须注意的是，在函数挂钩完成后，应调用 NdisDeregisterProtocol() 将假协议注销。另外，在遍历协议链表进行函数挂钩时，应从首节点的下一个节点开始，因为首节点是我们的假协议节点。

* 修改原有函数地址值实现函数挂钩

上文已提到了和NDIS相关的三个结构：
NDIS_PROTOCOL_BLOCK,
NDIS_OPEN_BLOCK,
NDIS_PROTOCOL_CHARACTERISTICS。

那么我们要替换的函数在哪儿呢？答案是在 NDIS_OPEN_BLOCK 和 NDIS_PROTOCOL_CHARACTERISTICS 这两个结构中，而且重点是前者，因为前者是协议驱动和网卡绑定的纽带。现在的主流网卡都只调用 NDIS_OPEN_BLOCK 中的收发函数进行发送和接收数据包。但据试验，虚拟机 VMware 有时会调用NDIS_PROTOCOL_CHARACTERISTICS 中的函数进行数据包收发。所以为了严谨，我们应该对两个结构中的函数进行替换。关于这两个结构的定义，读者可以自行查阅DDK文档和头文件。下面给出示意性代码。简单起见，下列代码均假设当前NDIS的版本为5.0。

BOOLEAN
    InstallHook(void)
    {
        NDIS_STATUS nStatus;
        NDIS_HANDLE hBogusProtocol = NULL;
        BYTE *pProtocolChain;

        // Get the address of the first NDIS_PROTOCOL_BLOCK node.
        hBogusProtocol = RegisterBogusNDISProtocol();
        if (hBogusProtocol == NULL) return FALSE;

        pProtocolChain = (BYTE*)hBogusProtocol;
        while (TRUE)
        {
            // Get the address of the next node.
            DWORD dwOffset = 0×10;  // for NDIS 5.0
            pProtocolChain = ((BYTE **)(pProtocolChain + dwOffset))[0];
            if (!pProtocolChain) break;

            HookNdisProtocolBlock(pProtocolChain);
        }

        NdisDeregisterProtocol(&nStatus, hBogusProtocol);
        return TRUE;
    }

void
    HookNdisProtocolBlock(
        IN  BYTE *pProtocolBlock
        )
    {
        PNDIS_PROTOCOL_CHARACTERISTICS pProtoChar;
        PNDIS_OPEN_BLOCK pOpenBlock;

        pProtoChar = (PNDIS_PROTOCOL_CHARACTERISTICS)(pProtocolBlock + 0×14);

        HookNdisProc(MyReceive, (PVOID *)&pProtoChar->ReceiveHandler);
        HookNdisProc(MyReceivePacket, (PVOID *)&pProtoChar->ReceivePacketHandler);
        HookNdisProc(MyBindAdapter, (PVOID *)&pProtoChar->BindAdapterHandler);

        pOpenBlock = ((PNDIS_OPEN_BLOCK *)pProtocolBlock)[0];
        while (pOpenBlock)
        {
            HookNdisProc(MySend, (PVOID *)&pOpenBlock->SendHandler);
            HookNdisProc(MyReceive, (PVOID *)&pOpenBlock->ReceiveHandler);
            HookNdisProc(MyReceivePacket, (PVOID *)&pOpenBlock->ReceivePacketHandler);
            HookNdisProc(MySendPackets, (PVOID *)&pOpenBlock->SendPacketsHandler);

            pOpenBlock = pOpenBlock->ProtocolNextOpen;
        }
    }

void
    HookNdisProc(
        IN  PVOID pMyProc,
        IN  PVOID *ppOrgProc
        )
    {
        // TODO: Save the address of the original proc.

        *ppOrgProc = pMyProc;
    }

InstallHook() 首先得到协议链表的首地址，接着遍历链表，针对系统中的每个(第一个除外)
NDIS_PROTOCOL_BLOCK 调用 HookNdisProtocolBlock() 函数。HookNdisProtocolBlock() 对 NDIS_PROTOCOL_BLOCK 中 NDIS_PROTOCOL_CHARACTERISTICS 和NDIS_OPEN_BLOCK 链表的每个节点进行函数挂接。HookNdisProc() 用于替换函数地址。给出的代码中它只是简单地替换函数地址，在实际应用中，它还应当保存原始函数的地址值，以供新的函数调用。

* 关键数据域在不同NDIS版本中的差异

由于 NDIS-Hook 并非受微软官方支持的技术，所以相关文档非常缺乏。不仅如此，操作系统的每次升级，都会同时升级NDIS，而NDIS中的某些数据结构并没有保持向下兼容。最需要注意的是 NDIS_PROTOCOL_BLOCK。

在 Win9x/Me/NT 的DDK中，NDIS_PROTOCOL_BLOCK 都有明确的定义，但在Win2K/XP 的DDK中，并没有该结构的详细定义，也就是说该结构在 Win2K 以后(含)的系统中是非公开的。因此开发人员只能利用各种调试工具来发掘该结构的详细定义。也正是因为如此，NDIS-Hook 方法对平台的依赖性比较大，需要在程序中判断不同的操作系统版本而使用不同的结构定义。

NDIS_PROTOCOL_BLOCK 的定义可大致认为是这个样子：

typedef struct _NDIS_PROTOCOL_BLOCK
    {
        PNDIS_OPEN_BLOCK              OpenQueue;
        REFERENCE                     Ref;
        UINT                          Length;
        NDIS_PROTOCOL_CHARACTERISTICS ProtocolChars;

struct _NDIS_PROTOCOL_BLOCK*  NextProtocol;
        ULONG                         MaxPatternSize;

        // …
    } NDIS_PROTOCOL_BLOCK, *PNDIS_PROTOCOL_BLOCK;

其中 OpenQueue 为 PNDIS_OPEN_BLOCK 链表的首节点地址，NextProtocol 指向下一个
NDIS_PROTOCOL_BLOCK 节点。在不同的NDIS版本中，该结构中的某些域的偏移地址是不同的，现列于下：

┌───────┬───────────┬───────────┐
  │ NDIS Version │ ProtocolChars offset │ NextProtocol offset  │
  ├───────┼───────────┼───────────┤
  │   3.XX       │        0×14          │        0×04          │
  │   4.XX       │        0×14          │        0×60          │
  │   4.01       │        0×14          │        0x8C          │
  │   5.XX       │        0×14          │        0×10          │
  └───────┴───────────┴───────────┘

* 如何在驱动中得到当前NDIS版本？

有两种方法可得到当前NDIS版本。一种是先取得当前操作系统的版本信息，在根据操作系统的版本得到NDIS的版本。操作系统版本和NDIS版本有一个映射关系，读者可在DDK帮助中查到。

┌───────┬───────┐
  │ OS Version   │ NDIS Version │
  ├───────┼───────┤
  │ Win95        │     3.1      │
  │ Win95 OSR2   │     4.0      │
  │ Win98        │     4.1      │
  │ Win98 SE     │     5.0      │
  │ WinMe        │     5.0      │
  │ WinNT 3.5    │     3.0      │
  │ WinNT 4.0    │     4.0      │
  │ WinNT 4.0 SP3│     4.1      │
  │ Win2K        │     5.0      │
  │ WinXP        │     5.1      │
  │ WinVista     │     6.0      │
  └───────┴───────┘

还有一种方法，通过调用 NdisReadConfiguration() 直接获取NDIS版本。代码如下：

BOOLEAN
    GetNdisVersion(
        OUT DWORD *pMajorVersion,
        OUT DWORD *pMinorVersion
        )
    {
        NDIS_STATUS nStatus;
        NDIS_STRING VersionStr = NDIS_STRING_CONST(“NdisVersion”);
        PNDIS_CONFIGURATION_PARAMETER ReturnedValue;
        BOOLEAN bResult;

        NdisReadConfiguration(
            &nStatus,
            &ReturnedValue,
            NULL,
            &VersionStr,
            NdisParameterInteger);

        bResult = ((nStatus == NDIS_STATUS_SUCCESS)? TRUE : FALSE);
        if (bResult)
        {
            //
            // The returned value has the NDIS version of the form
            // 0xMMMMmmmm, where MMMM is major version and mmmm is minor
            // version so 0×00050000 is 5.0
            //
            DWORD dwVersion = ReturnedValue->ParameterData.IntegerData;
            if (pMajorVersion)
                *pMajorVersion = dwVersion >> 16;
            if (pMinorVersion)
                *pMinorVersion = dwVersion & 0xFFFF;
        }

        return bResult;
    }

须注意的是，GetNdisVersion() 必须在 PASSIVE_LEVEL 下运行。所以此函数适合于在
驱动的 DriverEntry() 中调用，因为 DriverEntry() 一定是处于 PASSIVE_LEVEL 的。