Writing driver to intercept network communication (IDS/IPS)

NTDEV
1

Hello to everybody.

I am trying to write a small host based IDS/IPS software.
I have a few questions about the possibility of writing a windows kernel driver that would be able to intercept all of the network communication for user mode applications. So that driver sees all of the data coming from and going to the network.

Is it possible to create such a driver that would work at a higher level from examining every packet? For example, I want the driver to see just the raw data before it gets sent to user mode application after the packets that contain the data have been assembled. Is something like that possible without using any undocumented “features”?

I was searching on google for some kind of similar solution but came up with nothing, so i was wandering if anyone here has some interesting tips.

Driver is for 2000, XP and Windows 2003.

2

On Windows 2000, XP and Windows Server 2003 you can use:

1.) A NDIS Intermediate (IM) filter driver for per-packet inspection below
the kernel TCP/IP driver. The WDK “PassThru” sample and samples at
http://wd-3.com are starting points.
2.) If process information and inspection of complete datagrams is required,
then you need a filter above the kernel TCP/IP driver. This would be a
"Transport Driver Interface (TDI) or AFD filter driver. These are poorly
documented and tough to get right and to make co-exist with other
third-party software (e.g., FW, A).

On Vista and later platforms there the network stack was completely
re-written and provides better tools such as the Windows Filtering Platform
(WFP).

Good luck!

Thomas F. Divine
http://www.pcausa.com

From:
Sent: Thursday, January 14, 2010 5:20 PM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] Writing driver to intercept network communication (IDS/IPS)

> Hello to everybody.
>
> I am trying to write a small host based IDS/IPS software.
> I have a few questions about the possibility of writing a windows kernel
> driver that would be able to intercept all of the network communication
> for user mode applications. So that driver sees all of the data coming
> from and going to the network.
>
> Is it possible to create such a driver that would work at a higher level
> from examining every packet? For example, I want the driver to see just
> the raw data before it gets sent to user mode application after the
> packets that contain the data have been assembled. Is something like that
> possible without using any undocumented “features”?
>
> I was searching on google for some kind of similar solution but came up
> with nothing, so i was wandering if anyone here has some interesting tips.
>
> Driver is for 2000, XP and Windows 2003.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

3

Thank you for you’re answer.

So it’s either doing analysis packet by packet which is not so great for IDS/IPS systems, or getting my hand dirty with some poorly documented interface.

Wish I could work with Vista and later, WFP seems like a really cool feature.

I’ll try it with TDI. Seems it’s somewhat easier to find examples for it than for AFD.

4

I would assume that the “D” in IDS (Detection) means you only need to
‘observe’ the packet flow.

You might still find it simpler to keep the relatively small amount of
book-keeping required to re-assemble IP fragments and handle TCP stream
segments simpler than building a TDI filter.

All I can say is don’t assume that the TDI filter ‘samples’ you can get with
a google search are actually any good and robust. A robust TDI filter
that even just ‘observes’ the data is still quite a bit of work and
frustratingly difficult to get right when you consider needing to
interoperate with all of those other TDI filters out there, many of which
are subtly *not* correct (but come from really big companies and therefore
win the ‘its your problem’ contest).

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, January 14, 2010 6:09 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Writing driver to intercept network communication
(IDS/IPS)

Thank you for you’re answer.

So it’s either doing analysis packet by packet which is not so great for
IDS/IPS systems, or getting my hand dirty with some poorly documented
interface.

Wish I could work with Vista and later, WFP seems like a really cool
feature.

I’ll try it with TDI. Seems it’s somewhat easier to find examples for it
than for AFD.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Oh, and one more thing: If all you need to do is ‘see’ the packets, an NDIS
protocol may be just fine. You can request a packet filter including
NDIS_PACKET_TYPE_ALL_LOCAL and get both the ‘send’ and ‘receive’ packets.

And if you are only interested in IP packets that are delivered to local
endpoints (sockets) you can consider the (deprecated) “Firewall Hook” in NT5
too. It is not present in NT6 but WFP is which is much nicer.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Thursday, January 14, 2010 6:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Writing driver to intercept network communication
(IDS/IPS)

I would assume that the “D” in IDS (Detection) means you only need to
‘observe’ the packet flow.

You might still find it simpler to keep the relatively small amount of
book-keeping required to re-assemble IP fragments and handle TCP stream
segments simpler than building a TDI filter.

All I can say is don’t assume that the TDI filter ‘samples’ you can get with
a google search are actually any good and robust. A robust TDI filter
that even just ‘observes’ the data is still quite a bit of work and
frustratingly difficult to get right when you consider needing to
interoperate with all of those other TDI filters out there, many of which
are subtly *not* correct (but come from really big companies and therefore
win the ‘its your problem’ contest).

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, January 14, 2010 6:09 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Writing driver to intercept network communication
(IDS/IPS)

Thank you for you’re answer.

So it’s either doing analysis packet by packet which is not so great for
IDS/IPS systems, or getting my hand dirty with some poorly documented
interface.

Wish I could work with Vista and later, WFP seems like a really cool
feature.

I’ll try it with TDI. Seems it’s somewhat easier to find examples for it
than for AFD.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

Problem is with the other part of my task. IPS - Intrusion prevention. For example, let’s say I build the NDIS protocol driver that sees all of the traffic, and, at some time it detects a known shellcode being sent to some of the application, is there any way to stop it from reaching an application. Because, if that malicious traffic gets to user mode application - game over, system is compromised and my IDS is useless.

But, let say that because this TDI stuff is so hard to get right, I decide to go with NDIS. Is there any way to implement the “prevention” part to stop the malicious traffic from going “up” to the user application? It doesn’t have to be inside a kernel driver. Maybe some user mode service that would, upon being notified of the possible threat, stop the traffic? Is something like that possible or it’s just too late to do anything?

I have experience with writing kernel drivers but not one of them was related to networking so I am a little in the dark with this stuff.

7

A NDIS Intermediate (IM) filter driver can filter packets - including
blocking unwanted incoming packets.

However, the problem is that at the NDIS level there is no association
between the received packet and the ultimate user-mode client process. I
would expect that the prevention logic would need this association
information.

Thomas F. Divine
http://www.pcausa.com

From:
Sent: Friday, January 15, 2010 10:59 AM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] Writing driver to intercept network communication
(IDS/IPS)

> Problem is with the other part of my task. IPS - Intrusion prevention. For
> example, let’s say I build the NDIS protocol driver that sees all of the
> traffic, and, at some time it detects a known shellcode being sent to some
> of the application, is there any way to stop it from reaching an
> application. Because, if that malicious traffic gets to user mode
> application - game over, system is compromised and my IDS is useless.
>
> But, let say that because this TDI stuff is so hard to get right, I decide
> to go with NDIS. Is there any way to implement the “prevention” part to
> stop the malicious traffic from going “up” to the user application? It
> doesn’t have to be inside a kernel driver. Maybe some user mode service
> that would, upon being notified of the possible threat, stop the traffic?
> Is something like that possible or it’s just too late to do anything?
>
> I have experience with writing kernel drivers but not one of them was
> related to networking so I am a little in the dark with this stuff.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

8

Sure you can drop packets from an IM filter. Have a look at the “extending
passthru” stuff from Thomas et al.

wrote in message news:xxxxx@ntdev…
> Problem is with the other part of my task. IPS - Intrusion prevention. For
> example, let’s say I build the NDIS protocol driver that sees all of the
> traffic, and, at some time it detects a known shellcode being sent to some
> of the application, is there any way to stop it from reaching an
> application. Because, if that malicious traffic gets to user mode
> application - game over, system is compromised and my IDS is useless.
>
> But, let say that because this TDI stuff is so hard to get right, I decide
> to go with NDIS. Is there any way to implement the “prevention” part to
> stop the malicious traffic from going “up” to the user application? It
> doesn’t have to be inside a kernel driver. Maybe some user mode service
> that would, upon being notified of the possible threat, stop the traffic?
> Is something like that possible or it’s just too late to do anything?
>
> I have experience with writing kernel drivers but not one of them was
> related to networking so I am a little in the dark with this stuff.
>

9

In either the NDIS IM filter model or the TDI filter model or the FW hook
model you have the opportunity to ‘inspect’ and then ‘block’ the delivery of
network data. Simply ‘dropping’ the data is an option but taking a more
complete action terminating the flow, for instance, or the application, or
locking out the entire network interface are possible.

So what do you want to do in the ‘P’ part - how big a hammer is it you
intend to use?

I should also point out that and NDIS IM driver cannot filter ‘loopback’
data (where the threat is from a process on your own machine) or data
protected by IPSec privacy (ESP encryption). For these, a TDI filter or FW
hook is the better approach.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Friday, January 15, 2010 11:00 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Writing driver to intercept network communication
(IDS/IPS)

Problem is with the other part of my task. IPS - Intrusion prevention. For
example, let’s say I build the NDIS protocol driver that sees all of the
traffic, and, at some time it detects a known shellcode being sent to some
of the application, is there any way to stop it from reaching an
application. Because, if that malicious traffic gets to user mode
application - game over, system is compromised and my IDS is useless.

But, let say that because this TDI stuff is so hard to get right, I decide
to go with NDIS. Is there any way to implement the “prevention” part to stop
the malicious traffic from going “up” to the user application? It doesn’t
have to be inside a kernel driver. Maybe some user mode service that would,
upon being notified of the possible threat, stop the traffic? Is something
like that possible or it’s just too late to do anything?

I have experience with writing kernel drivers but not one of them was
related to networking so I am a little in the dark with this stuff.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

10

> But, let say that because this TDI stuff is so hard to get right, I decide to go with NDIS. Is there any way

to implement the “prevention” part to stop the malicious traffic from going “up” to the user application?

Handicraft a RST packet and send up.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

11

> But, let say that because this TDI stuff is so hard to get right, I decide

to go with NDIS. Is there any way to implement the “prevention” part to
stop the malicious traffic from going “up” to the user application?

The maximum you can do at NDIS level is to check source and destination IP addresses and ports,
However, this info alone does not seem to be sufficient to relate it to a particular process, does it. This is why PF/FW/etc normally work at both TDI and NDIS levels. TDI-level part relates IP address and port to a particular process so that NDIS-level part of the solution can take advantage on this info when deciding what has to be done with the packet…

Concerning the complexity of TDI filter, it depends on what you want to do in it. As long as you want to simply relate a port number to a process there is nothing particularly complex about it. However, if you want to do ACTUAL filtering at this level, i.e. write a modifying TDI filter, think again - this is “not the easiest”, so to say, project one can possibly imagine…

Anton Bassov

12

Ok, I’ll start this project one step at a time.

For now, I will go with NDIS IM filter that checks each packet for known signatures and if it detects anything suspicious it’ll log the IP address the port number, drop the packet, and inform some user mode GUI application. This GUI application will warn the user of the event and it might try to figure out what application is using that port number.

After that I’ll see about implementing something more advanced.

Thank you all for your suggestions, they’ve been very helpful.

Just one more thing. Since I am not experienced with network driver programming.

Dave Cattley said:
“You might still find it simpler to keep the relatively small amount of book-keeping required to re-assemble IP fragments and handle TCP stream segments simpler than building a TDI filter.”

How complex is this “book-keeping” ?

13

I suggest that you get a good book on TCP/IP networking that explains how
IPv4 and IPv6 network packets are formed, forwarded, fragmented, and
re-assembled. That same book will also explain how TCP uses IP and thus how
to ‘receive’ a flow of TCP packets and re-construct the TCP stream being
carried.

There are many such books out there. I am partial to “Internetworking with
TCP/IP” by Comer only because I have had it forever on my bookshelf. But I
understand that “TCP/IP Illustrated” by Stephens is also very good and may
be a better choice. My edition of the Comer books is, well, ancient :slight_smile: - I
have had them for 19 years. That is some serious “keeping books”.

The organization of the processing is basically a pipeline:

Receive IP packets -> Re-assemble into IP Datagrams containing TCP segments
-> buffer into a window on the TCP stream.

It is not a ‘driver’ problem, just a ‘network programming’ challenge.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Saturday, January 16, 2010 4:14 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Writing driver to intercept network communication
(IDS/IPS)

Ok, I’ll start this project one step at a time.

For now, I will go with NDIS IM filter that checks each packet for known
signatures and if it detects anything suspicious it’ll log the IP address
the port number, drop the packet, and inform some user mode GUI application.
This GUI application will warn the user of the event and it might try to
figure out what application is using that port number.

After that I’ll see about implementing something more advanced.

Thank you all for your suggestions, they’ve been very helpful.

Just one more thing. Since I am not experienced with network driver
programming.

Dave Cattley said:
“You might still find it simpler to keep the relatively small amount of
book-keeping required to re-assemble IP fragments and handle TCP stream
segments simpler than building a TDI filter.”

How complex is this “book-keeping” ?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer