经典讨论："NDIS Hooking" and "NDIS IM Driver"

"NDIS Hooking" and "NDIS IM Driver"

----- Original Message -----
From: <xgchent@y...>
To: <discussion-pcausa@yahoogroups.com>
Sent: Thursday, August 30, 2001 10:01 PM
Subject: [discussion-pcausa] "NDIS Hooking" and "NDIS IM Driver"


I will develop a personal firewall under Windows NT/2000. From
the survey I've done, I find that "NDIS Hooking" is adopted by most
products for personal firewall。To develop the personal firewall for
Windows NT/2000, can "NDIS IM Driver" be adopted instead of "NDIS
Hooking"? Which is better？Why do most personal firewalls use "NDIS
Hooking" instead of "NDIS IM Driver"？
Expect to reply.

Thanks
xianguo chen
 


The Figure at the URL below illustrates the Windows Network Architecture:

http://www.pcausa.com/resources/winpktfilter.htm

Here are some rambling comments that may help you.

NDIS Intermediate (IM) Drivers
---------------------------------
Generally NDIS IM drivers are installed using the Network Control Panel. On
Windows 2000 and higher the process of installing NDIS IM drivers can be
automated to some extent using the NetCFG and SetupDi APIs. This probably
can be done in a way that is "invisible" to the user. However, it cannot be
done at all unless the user installing the NDIS IM driver (or any driver for
that matter) has Administrative priviledges.

On Windows NT it is difficult to filter WAN in an IM driver because of the
propritary nature of the internal APIs of some Microsoft drivers. In
addition, the WAN API differs between some versions of NT. For example the
"Steelhead" Terminal server APIs are different from the normal NT
workstation APIs.

NDIS Hooking
----------------
Now the question about NDIS hooking.

A hooking solution has at least these four possible benefits:

1.) It is easy (or can be made to appear easy) to install.
2.) It allows filtering of WAN/PPP adapter.
3.) It does not require re-wrapping of passthru packets.
4.) It provides total control of packets being sent or received.

NDIS hooking the Windows 95/98/ME platforms can be implemented using hooking
services provided by Microsoft and usually employs only documented system
services and documented structure definitions.

NDIS hooking is not quite as straight forward on Windows NT and Windows 2000
(and higher).

In particular, there is no Microsoft-provided hooking API. Instead, the NDIS
hooking code may need to use undocumented methods and undocumented data
structures. One would at least say that the techniques used for NDIS hooking
on Windows NT are similar to the techniques used to implement a debugger.
One could also say the thechniques are similar to kernel "hacking" methods.
In any case, if properly done the Windows NT and Windows 2000 NDIS hooks can
be quite reliable and provide the same benefits mentioned above.

Why would one NOT consider NDIS hooking?

For one thing, since the Window NT and Windows 2000 NDIS hooking techniques
are not documented you must learn them for yourself. You must be familiar
with both NDIS and the undocumented details of the Windows kernel
implementation. A NDIS hooking product is certainly be sensitive to changes
that Microsoft might introduce in new product releases. For example, the
NDIS hooking method used for Windows NT does not work without change on
Windows 2000.

It would certainly be difficult to get a Microsoft logo for any product
known to use the undocumented hooking techniques.

Other Thoughts
----------------
A firewall may, in fact, perform filtering at more then one point in the
network stack.

For example, process information (i.e., information about the application
performing a network operation) can be determined most reliably above the
TCP/IP transport driver; here one would use a Transport Data Interface (TDI)
filter. Per-packet filtering is done below the TCP/IP transport driver; here
one would use a NDIS Intermediate (IM) driver or a NDIS-hooking filter.

There are other things to consider. The so called "user experiance' is a
factor. Consider the apparently trivial idea of blocking access to a
specific IP address. Obviously, this could be done either in a TDI filter
above the TCP/IP transport or in drivers below the TCP/IP transport.
However, the user will see a difference. If the IP address is blocked by a
TDI filter the connection attempt will fail immediately (because the TDI
filter fails it immediately); however, if outgoing packets to the specificed
IP address are dropped below the TCP/IP transport, the connection attempt
won't fail until TCP/IP transport performs several re-try attempts - which
can be several seconds of wasted user time.

One must also consider fragmentation. Filters (or firewall components) above
the TCP/IP transport driver can examine unfragmented or re-assembled
portions of a data stream. Filters below the TCP/IP transport driver examine
individual packets; they must be re-assembled in the filter if unfragmented
stream data must be examined.

If the propose of the firewall is to "protect" the TCP/IP transport from
receiving malformed packets known to cause failures in the stack, then the
firewall must include filtering below the TCP/IP transport driver.

Hope this helps a little.

Good luck,

Thomas F. Divine

PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client
<http://www.pcausa.com> - <http://www.rawether.net>

呵呵，好贴！

我考虑此问题已经很久很久了，可是一直都没找到关于它们之间比较的详细资料，也就没有搞清楚。现在能够好好看看了。


Many thanks!   ^_^

呵呵，好贴！

经典！

好东西

确实谈了些网上那些重复帖子中没有的特性