How to build a kind of firewall.

Question

Actually what i am trying to build is like a kind of firewall. It should be able to get to know all the requests going from my machine. It should be able to stop selected ones. I am not sure how to even start about with this. I am having VS 2008/2005 with framework 2.0. Please let me know if there is any particular class i can start with and is there any samples i can get.

Answer 1

Firewalls really should be implemented fairly low in the networking stack; I'd strongly suggest NDIS. This article may be of interest.

Answer 2

Something like this may help you get started: http://www.mentalis.org/soft/projects/pmon/

This C# project allows Windows NT administrators to intercept IP packets sent through one of the network interfaces on the computer. This can be very handy to debug network software or to monitor the network activity of untrusted applications.

Answer 3

As Matt said, it really has to be NDIS.

Be sure to allocate a lot of time to develop the driver, I'd recommend 6 - 12 months just to get it to alpha-release stage. Having dealt with NDIS I can assure you it is a pain like no other.

If you plan to release your product to the public you'll need to cough up a few grand to microsoft to get the driver approved (WHQL) otherwise your users will be hit with multiple nasty dialogs upon installation (of the "this software is critically unsafe" variety). The approval process is slow and no longer available for Windows 2000, likely gone for XP soon. 64 bit approval is a separate payment.

You are locked into using C yet any tiny mistake is amplified into the form of a blue screen (e.g. a null reference or a slight buffer overflow). You can't create threads, your API is 100% different than the normal user-mode API and actually trying to communicate with user-mode means dealing with the spine-tingling IRP system.

NDIS itself is over-engineered in a bad, MFC-style way. You are restricted to a subset of the kernel API (which makes some things very difficult, like registry access). Failure to do so results in instant WHQL disqualification (no you don't get your money back!).

Every line of code needs to be checked thoroughly to ensure it is behaving correctly for the IRQL level it is running at (it basically determines whether your code can be interrupted by other processes). Calling an API function at the wrong level results in a blue screen. Also, creating a struct on the stack that is more than 500 - 1000 bytes results in a stack overflow (blue screen of course). That alone can produce some fun debugging sessions when you have a call-stack 15 lines deep with a few small allocations in each function.

Despite all that, and despite that NDIS has gone through 6 revisions, it really is worth doing if you want a challenge. The reward is a software product that'll sell well because not many others dare to get tangled up with that sort of thing. One important requirement is knowledge of assembly language (for debugging). Reading about the workings of the windows kernel is also very helpful (not just NDIS).

Answer 4

Some years ago I needed to know about the network bandwidth being used by all the applications on a Windows system.

Without a clue as to the magnitude of the task I was undertaking, I proceeded to learn how to write a TDI filter driver.

It took about two years. Two years full time, since I was living off some stock options. NDIS is easier than TDI, though. Prolly as the man says, one year full time.

You can do firewall stuff at the TDI level and it's nice there, since you can associate sockets with applications (which you can't do at NDIS). You can also block and/or bandwidth shape sends. You can block receives, but you can't really shape receives at TDI, because you're not allowed to pause (the receive code path executes at DISPATCH_LEVEL). I figured out a way around that and took a patent out on it, but I wouldn't recommend it from a technical POV.

OTOH a real hacker will simply bypass TDI and talk directly to the NDIS driver; a TDI firewall is bypassable.