Windows
Network Data and Packet Filtering
 

The purpose of this topic is to provide a brief introduction to various techniques that can be used to filter network data and network packets on the Microsoft Windows platforms..

Network Architecture Diagram

Preliminary...

 Windows Network Data Filtering Techniques

Other Information

User-Mode Network Data Filtering

Winsock Layered Service Provider (LSP)

See documentation and LSP samples in the Microsoft Platform SDK.

 There are several versions of the Microsoft LSP sample available. However, the latest (and most bug-free) is always on the Platform SDK.

Understand that it is possible to call the kernel-mode TCP/IP driver via the Transport Data Interface (TDI), and completely bypass Winsock. This limitation does not matter in many cases. For example, implementation of QOS could be done in a Winsock LSP.

However, products that absolutely must inspect or manipulate every packet cannot rely on Winsock LSP. They must be implemented using a kernel-mode approach.

Windows 2000 Packet Filtering Interface

The Windows 2000 Packet Filtering Interface provides a mechanism that allows a user-mode application or service to specify a set of "filter descriptors" that are used by lower-level TCP/IP components to filter packets. Filtering is controls pass/drop of packets based on IP source and destination address and port numbers (and port number range).

Windows Developer's Journal

Packet Filtering with iphlpapi.dll, Windows Developer's Journal, Ton Plooy, Windows Developers Journal, October, 2000, Volume 11, Number 10.

Windows 2000 offers a finer degree of programmatic control over TCP/IP, including the ability to perform packet filtering. Unfortunately, the documentation for this new API doesn't make it easy to figure out. This article demonstrates how you can programmatically install filters to block packets going to or from specific IP addresses, on some or all TCP ports.

[ Windows Developer's Journal Home...  ]
[ Download Ton Plooy's Sample Code from WDJ...  ]

Hollis Technology Solutions

The HTS W2K IpHook! sample demonstrates the semi-documented IP filter driver and its Hook API. Source code included, and its Free! Also requires requires HtsCpp runtime library (Freeware).

[ Hollis Technology Solutions ]

Winsock Replacement DLL

Before the introduction of the Winsock Layered Service Provider (LSP) facility, the only way to extend the functionality of Winsock was to replace certain Microsoft-provided Winsock DLLs with replacement DLLs.

If properly implemented, the replacement DLLs would filter the Winsock API and call functions in the original Winsock DLL as necessary.

There are a variety of reasons why development of a robust Winsock replacement DLL is difficult to accomplish. Among these difficulties is the fact that the Microsoft Winsock DLL includes private internal support functions that are not documented. A Winsock replacement DLL must deal with at least some of these undocumented functions.

The Windows system architecture is migrating to include enhancements, such as System File Protection, that make it impractical to use this technique.

Overall, use of the Winsock replacement DLL in now a bad idea.

More when I get a chance...

Kernel-Mode Network Data Filtering

Transport Data Interface (TDI) Filter Driver

This is basically a filter driver immediately above the kernel-mode TCP/IP driver.

Through Windows XP the TDI driver is a classical NT-style "legacy" driver that uses an I/O Request Packet (IRP) based API. There are two basic ways to filter an IRP-based API:

1. Use the IoAttachDeviceXYZ family of kernel mode services to layer a filter above TDI.
2. Filter the TDI driver IRP dispatch table.

The use of IoAttachDeviceXYZ API is described in most books on advanced Windows NT driver development.

Both techniques for filtering TDI require a thorough understanding on Windows NT device driver programming techniques as well as a thorough understanding of the TDI API that is to be filtered.

NDIS Intermediate (IM) Driver

See the NDIS Intermediate (IM) Driver FAQ for some information.

[ NDIS IM FAQ ]

Windows 2000 Filter-Hook Driver

See Windows 2000 DDK documentation.

Only one Filter-Hook may be active. This appears to severely limit the usefulness of this mechanism.

Windows 2000 Firewall-Hook Driver

The Firewall-Hook Driver API introduced briefly in some Windows 2000 Betas proved inadequate for use. See Microsoft's comments about Fire-Wall Hook API.

More when I get a chance...

NDIS-Hooking Filter Driver

NDIS-hooking filter drivers intercept or "hook" selected functions exported by the NDIS wrapper.  Although conceptually "drastic" approach, a systematically implemented NDIS-hooking filter can be quite effective.

In addition, a NDIS-hooking filter driver is:

The PCAUSA NDIS Pseudo-Intermediate (PIM) Driver is an example of a NDIS-Hooking Filter Driver.

The NDIS-hooking technique is equally  effective and practical on Windows NT, Windows 2000 and Windows XP. However, the hooking techniques are more akin to the techniques used by kernel-mode debuggers. That is, they are less well documented and may be difficult to be certified by WHQL for driver signing.

PCAUSA is provides a suite of NDIS PIM driver samples that operate successfully over the entire range of current Windows platforms (Windows 95 through Windows XP).

[ PCAUSA NDIS-Hooking Driver Samples... ]

More when I get a chance...

Other Considerations

Network Operations And Process Information

It may be desired to make a correlation between network operations and the Windows process (application) associated with those operations. For example, it may be of interest to know which process (application) is sending or receiving data on a particular IP port.

Without exploring the real problem of whether or not this is actually useful or reliable we can say that filters above the kernel-mode TCP/IP driver can correlate network operations with the associated Windows process. Filters below the kernel-mode TCP/IP driver do not have visibility to process information.

It should also be noted that some network services operate by creating a thread attached to the system process. In this case the process information that is available does not specifically identify the actual process that initially created the thread. This is especially true of Windows services that exist solely in kernel-mode (kernel-mode TDI clients).

Finally, one should examine the following Patent before considering use of process information to filter internet access:

United States Patent 5,987,611; "System and methodology for managing internet access on a per application basis for client computers connected to the internet ".

PCAUSA does not know the merits of this Patent or how it may apply to any intended use in packet filtering. Details can be found by searching for U.S. Patent 5,987,611 at the U.S. Patent Office website.