Hi there,

I read that some firewalls are able to filter out network data before the data even reaches the operating system.

How is this possible? How can a program be sure that it has precedence over the OS?

Also, if a firewall is acting at this level, how does it know where the network device is and how does it know how to communicate with it given that its not going through the OS and, I presume, a driver?


Posted on 2004-01-15 11:19:22 by Station
Hrm, I have never heard of such a firewall.

Really, the network data hits the OS as soon as you make a winsock API call. Filtering before that would be a bit hard, and somewhat pointless too IMO - you really just need to do filtering before packets are sent on the wire, or when packets appear on the wire but before the upper OS layers processes them.

I'm going to totally ignore Win9x here since it's a POS and better off dead ^_^

On NT, the network model is pretty layered. Now, if I remember correctly... You have the hardware, a driver implemeting NDIS, the NDIS layer, the provider layer, and winsock on top of it all. By hooking NDIS, you have control at a pretty low layer - in a hardware independent way. For send, you can filter packets after the protocol layer but before the bytes go on the wire. For receive, you can inspect packets before they get to the protocol layer where there *potentially* could still be crash-exploitable bugs left (though I doubt it).

The above was off top of my head and it's been quite a while since I read about the NT networking model, so it might be flawed. It should, however, give some entrypoints for additional searching... look at the winsock documentation in the PlatformSDK, and google+boardsearch for NDIS.
Posted on 2004-01-15 12:22:32 by f0dder
You may have been reading about a Firewall Device. It is used by Network Administrators to control the Kind of traffic that reaches a network and therefore your PC, furthermore the OS on the PC.

Control is a word that's powerful to the knowlegdeable.

So you may wish to clarify your question, because there are hardware & software firewall solutions at different levels in the network scheme of things.

Regards, P1 :cool:
Posted on 2004-01-16 12:55:50 by Pone
Look here for example.

It says,
Professional firewall products catch each network packet before the operating system does


More recently, however, "...firewalls have moved down the protocol stack so far that the OS doesn't have to do much more than act as a bootstrap loader, file system and GUI". The author goes on to state that newer firewall code bypasses the operating system's IP layer altogether,

This sounds like a software firewall.
Posted on 2004-01-16 15:22:47 by Station
I'm rather new to windows assembly, and I'm not even sure if its possible on winodws at all. But on BSD systems, this is VERY possible. On bsd you are forced to work with kernel level raw sockets using the BPF library. This library is horrid at the least. There have been people who wanted to get away from using this feature of BSD.

I call it a feature because it was added to increase security.

These people are true die-hard coders at the least, I myself have programmed on BSD for over 10 years and I still refuse to try this. But here is the methodology at work...

The "simple" method for doing this is to create a file descriptor in the /dev directory that replaces the original that was created by the OS, these file descriptors are what the kernel accesses to get information about a device. For example, instead of handling pointers and drivers for a specific hard drive, the kernel creates /dev/hda as a file descriptor, then when you want data off of the hard drive, the kernel will access /dev/hda for that data. Same works for network data. By creating a new file descriptor for the network, the software engineer can then block specific data at the file descriptor, therefore it never reaches the kernel. But this also means that the firewall software must decrypt the data itself from the raw binary code since the kernel is not there to decypher it. That I know of, windows does not work like this, and I'm not sure if a software firewall on Windows systems could ever emulate such as to actually get below the kernel.

From the example page that you posted, and from the diagrams, I'm pretty sure this is the same method that is being discussed, and they are not refering to Windows firewalls, but BSD/Linux/UNIX software firewalls.

BTW, I've only seen two systems that used this method for packet filtering, both were custom firewall software, and both were while I was working as a Unix Systems Administrator.

The down side to such firewalls, is that they commonly cause rouge processes, and if not properly configured (eg the lo0 interface gets cloned) then your system won't work, since most software on *nix systems are network based (including X11)
Posted on 2004-04-19 00:23:32 by Synfire

That I know of, windows does not work like this, and I'm not sure if a software firewall on Windows systems could ever emulate such as to actually get below the kernel.

You don't go below kernel level on any OS to do firewalling.

The idea is to sit pretty low/early on the stack, though. Well below the protocol level. I'm not sure where a firewall sits in windows, but I assume it's right above NDIS, which is one of the lowest layers.

Of course, it will give the best performance results if you program your firewall as a kernel mode driver, so you don't have overly large amounts of ring3<->ring0 switches - user-mode firewall? Ick.
Posted on 2004-04-19 04:59:48 by f0dder