Some really weird ways of implementing firewalls on windows

Weird World Of Windows
Some really weird ways of implementing firewalls on windows.

--= Introduction =--

So, you just installed a fresh windows 2000 server, configured IIS server, FTP server , now its time to secure your windows machine. Securing a windows machine from outside attacks is a complex task. Just because of sheer market dominance of windows, attackers are more interested in attacking windows systems.

By taking a look at the exploits database we find that the number of exploits for windows system is greater than number of exploits developed for any other operating system. Service like IIS and SMB sharing are specially favorites of crackers. Groups like eEye spend a lot of time disassembling is server to find buffer/heap overflows. And a exploit found by this group was exploited by CodeRed worm to spread itself across the Internet.

Hardening a windows server is not an easy task. And we will mainly focus on packet filtering in this article .We cannot help you solve all your security related problems , but we sure can help you with a good tool which you can use to secure your network.

Here's some basic terminology you should be aware of:

(a) Bastion Host

This is the machine that is directly exposed to the outside world. Your whole network is behind this machine.

(b) DMZ ( Demilitarized Zone )

The outside network is generally termed as the DMZ

(c) Perimeter Network

As mentioned above, your network is completely dependent on the bastion host for security. But what if you bastion host is compromised ? Or if it has got undiscovered vulnerability. that can be exploited by an external cracker ?That's the reason we setup a perimeter network behind the bastion host for extra layer of security.

--=Blocking the packets =--

The first step for cracking into any machine is to obtain as much info as possible , about that machine. Most crackers try to discover your network topology and try to find the weakest point to attack.

A firewall employs various methods to block access to internal network:

(a) Packet Filtering

A firewall can employ the packet filtering technique to block / rejects depending upon source/destination , port and various other parameters like TCP flags etc. The firewall isn't aware of contents of packets. All it cares about is that the packet passes the predefined rules about source/destination, flags etc.

This method is definitely fast. Most firewall employ this technique to attain a very high filtering rate. But the problem with this approach is that since the firewall is not aware of contents of the packet, it don't know whether the packet contains valid data or some shell code targeted at your server. Most hardware firewall products use this technique. That's because it requires less hardware resources to process the packets.

This problem can be partially solved by deploying a NIDS ( Network Intrusion Detection System ).

On a windows 2000 system, you can run Snort, which scans the content of the packets and matches them with it's signature database.

However, the recent discovery of integer overflow in the de fragging code of snort indicates that we cannot rely 100% on any program. These programs are written by humans, and thus are error prone.

(b) Stateful inspection

This is a hybrid between packet filtering and NIDS. Some firewall employ this technique to maintain a state table and allow or reject the packets according to current state of a connection. A simple packet filtering is susceptible to packet spoofing. An attacker can simply change the IP address of a packet to fool a firewall and can pass through firewall filter rules.

But a Stateful packet filtering firewall makes it very hard for attacker to spoof the packets. So, the cracker cannot just simply change the source address to get into a network.

(c) Application Layer Filtering

This method employing various proxy servers to actively monitor the contents of packets before they finally reach the applications. Some recent products are Web proxy by atstake security.

This product, written in Java , actively monitors the contents of packets for shell code attacks, ;long strings, or dangerous URL's that tries to access potentially dangerous files.

It's very clear that no one product can solve all your problems. In your to secure your network, you will have to deploy one or more solution in tandem.

--=Implementing a firewall =--

On most *nix based operating systems, implementing a firewall is not a tough job. There are standard and open ways to develop firewall. For example, pf on OpenBSD is standard kernel module that can be used to block/ modify packets. Same goes for ipfilter / ipchains on Linux based machines.

However, in the Windows world, its a different story altogether. There is no standard way to write a firewall. Its such a shame that even the server products from Microsoft doesn't provide anything to effectively block packets. With the advent of windows 2000, Microsoft started providing developers with a standard interface to block packets. But its not very useful, since it cannot be used to block packets before it reaches the TCP stack.

Here I will discuss general methods used by various firewall vendors to develop there firewall products. Not all of them use "safe" methods. And in order to protect your windows machine, you should be aware of the protection technique used by your firewall.

(a) Layered Socket Providers ( LSP )

The most exciting feature of winsock 2.0 was LSP. LSP provided developers the ability to inject there own hooks into every processes that called winsock. This method allowed them to monitor the packets sent and received by a particular application. This method was generally preferred because it just requires a simple user mode DLL. And best of all , it can be deployed on every windows version after windows 95 ( Windows 95 need to be updated to winsock 2, which is available for download at Microsoft site ).

This method is generally used by various ad busters , spam busters and other products that block the packets at application layer. Even Microsoft IAS servers uses this technique for QoS etc. The basic theory is that we layer our own protocol service provider over existing service providers. Now we can modify or reject connections based on various rules .Another reason why programmers prefer LSP : Since the packet reassembly has already been done by the MSTCP stack, programmers have direct access to fully reassembled TCP streams. So, no more dirty job of reassembling TCP streams. This is really helpful for application that do things like regular expression search of streams.

Alas, there isn't too mc uh documentation available on LSP. There is just one good article on LSP, at Microsoft site, and there is just one sample source layered.exe available. If you are really interested in writing a LSP based app, check out this link

Unraveling the Mysteries of Writing a Winsock 2 Layered Service Provider

Download the sample source and be prepare to spend a _lot_ of time reading-, re-reading, re-re-reading the code. It can be very complex for anyone who hasn't worked with LSP before. go through the code a few times and you will eventually get it :)

However , the same method can be used by Trojans to hook themselves at a layer below the firewall. This allows the Trojan to access the packets before the firewall can. This allows the Trojan to piggyback various packets over existing packets, in a very stealth manner.

This is how most LSP Trojans work: They install a LSP _below_ the firewall LSP. This way, the firewall has no way of monitoring the packets sent and received by the Trojan LSP. The Trojan LSP can monitor the packets sent/received by various applications and then modify the packets to piggyback its own data. And, mind you , Trojans of these kinds can be quite difficult to remove.

And even if you do manage to get them removed, it's most likely that you have broken up your LSP chain. Now, no matter what you do, you just wont be able to go online. And you cant fix it simply by reinstalling windows. Nope, it is not that easy.

And for end users, this can become quite a headache. Fortunately, there are lots of helpful utilities available that can easily restore the LSP order. However, as a firewall programmer you have to be sure that you properly install the LSP and take proper action to restore the LSP to its original state when user uninstall your program.


Pros:
(a) Common interface for windows 9x and windows NT
(b) Provides access to reassembled TCP stream, so its easy to write filtering programs like spam cleaner etc

Cons:
(a) It can be really painful to install / uninstall
(b) Trojans can easily bypass the protection by installing a Lsp at lower level than firewall's LSP.




(b) TDI Hooking

The TDI layer is just one level below the winsock layer. Unlike winsock, TDI has a very generic interface. It was designed to interact with various protocol service providers like TCP, NetBios on the lower edge and various kernel level TDI clients on the upper edge. To most people , TDI interface seems to be overly complicated. But what most people don't realize is that TDI interface was designed by Microsoft, with a generic interface to support more than one kind of protocol service providers. So, TDI got to handle TCP/IP, NetBios, and some more protocols.

While writing code for TDI service provider one can avoid a of lot problems by concentrating on a particular protocol interface.

Ok, now back to TDI hooking. I think you are aware of TDI monitor by mark / sysinternal . TDI monitor provides an easy to use interface for monitoring TDI activity. Almost all TDI layer firewall employ the technique used by TDI monitor. Unfortunately, the source code for TDI monitor is not freely available. Anyways, i will provide you with some general idea to get you started with your own TDI hook driver.

Most people opt for TDI layer hooking because one can very easily get the name of the process that is trying to access the network. Most personal firewall employ this technique of TDI hooking to allow / deny access to internet based on process's name. By employing simple techniques, we can not only get the name of the process that generated the IRP, but also its full path.

Under windows 9x, TDI layer can be hooked by using the Hook_VxD_service function. Take a look at the tdihook sample provided with the VToolsD library. the example simply hooks the VTDI_GetInterface function , using Hook_VxD_service ,to modify the service table for MSTCP protocol. However, under windows ME, this technique wont work, because Microsoft started using WDM protocol drivers.

This is one of the most frequently asked question in the VxD newsgroups. And here is the solution to the problem :

since WDM drivers are generic PE image files , they cannot directly access the VxD services ( VxD are not PE images , they are LE images :) VxD writers have been using a well known technique to support WDM driver under win9 platform. Most people crated export tables that pointed to VxD services, using the PELDR__AddExportTable function. This allowed driver writers to have a common code base for NT and older win9x platform.

so, everyone i happy, except the firewall developers, since the firewall developed for win9 suddenly stopped working under ME, since microsoft employed the same technique mentioned above. However there is a simple solution to all these problems.

All we have got to do is to hook the PELDR_AddExportTable function. since we have hooked the PELDR_AddExportTable function , we can now modify the export table address for various TDI functions.

Under windows NT , hooking the TDI is very easy. The hooking technique works on all NT platforms ( from NT 4 to XP ). This technique involves creating and attaching a filter device objects over TCP devices ( //Device//UDP , //Device//TCP, //Device//RawIp) . Please note that the raw IP device is used by winsock if raw sockets feature of winsock is used. Very few applications make use of raw sockets, but nevertheless, we have to filter this device too. By attaching a filter driver we can now monitor all IRP.

This technique of attaching a filter driver has got its own share of advantages and disadvantages.

This technique of attaching a filter device on top of an existing device object is well known and is described in detail in various driver programming books. so, you can get started with writing your own filter driver quickly.

However this technique suffers from one drawback. The driver cannot be unloaded unless and until all pending IRP are processed. And if you forcefully unload the driver, please be prepared to face the BSOD :D

since most firewall are not meant to be unloaded dynamically, this shouldn't be much of a problem.

Take a look at the MSDN to determine which functions to hook. Its pretty easy . The only time you may face problem is when de terming how to hook the event handler functions. not all network I/O uses IRP. If I/O must happen in response to some event, such as a datagram arrival, the system invokes an event handler function rather than a dispatch routine.

we intercept and change any request that sets a new event handler for a file object ( requests with minor function code TDI_SET_HANDLER ) Each of these requests contains the location of the event-handling function, the type of event it handles, and a four-byte context value to pass to that function. All the driver must do, then, is allocate a structure to store this information, then modify the request so that instead of containing the location of the real event-handling function and the real four-byte context value, it contains the location of our hook function.


Pros:
(a) One can monitor the name of the process trying to access the network.
(b) One has direct access to TCP stream, so filtering can be done.

Cons:
(a) Don't have access to actual network packets. Cannot filter icmp packets etc...
(b) Cannot protect the TCP stack from external attacks ( eg Dos attacks )




(c) Ndis Hooking

Now lets get down one layer below the transport layer.NDIs was designed by Microsoft and 3com to provide a portable interface for writing network device drivers that will be source compatible with different platforms ( windows , Os/2 etc )

However, as time passed, NDIS was restricted to Microsoft platforms only. It still makes a driver writer's life easy by providing a common ( well..almost :) interface for writing network device drivers.

One can hook various NDIs layer functions to monitor the incoming and outgoing packets. Hooking the NDIs layer function has some distinct advantages. we have direct access to raw network packets. And not only that , we can block these packets before they reach the TCP/IP stack.

And that the reason why most firewall hook the TDI layer as well as the NDIs layer.

NDIs hooking is somewhat complicated process. But just like TDI hooking method , it involves hooking NDIS functions.

Under win9x we can make use of Hook_VxD_service. Under ME , hook the PELDR_AddExportTable function.

However, under windows NT , we will have to employ a different technique. since we don't have the equivalent of Hook_VxD_service under NT, we will have to find a wa to emulate that functionality.

The best way of hooking under NT is by modifying the export table of ndis.sys. For more information on how to modify the export table,click here.



Pros:
(a) Direct access to raw packets
(b) Can block packets before they reach the TCP stack

Cons:
(a) No way to find the name of the process which generated the packet.





(d) Miniport Hooking

welcome to the lowest level of all. You are in the Miniport land ! You guessed it right. we can hook into Miniport functions to monitor the incoming and outgoing packets. well, i haven't written any code like this, but i have seen some weird code that does this. I have seen some really odd miniport hook code from a chinese message forum. However the code actually worked :)

(e) IM Filter ( Intermediate Filters )

This is the legal , and the most preferred way of writing a packet filter. The API is well documented in the MSDN, and it will a waste of time to repeat all the stuff that's already been described well in the MSDN. Please refer to the documents that came with your DDK to get started with writinng an IM packet filter driver. If you are having doubts about the hooking methods of developing a firewall, you can write an IM driver.

--= Application Layer Filtering =--

As i previously mentioned, packet filtering alone cannot protect your network. There's got to be some provision for application layer filtering. The best way to do this is redirecting the packets to another port. This method involves changing the port of a packet ( and if required , destination too ) , recomputing the checksum and then sending the packet to the MSTCP stack.

By employing this technique , we can create transparent proxy, and many application layer proxy. However, for personal firewall, we can filter the TCP stream at the transport layer ( TDI layer ) or by using LSP.

That's it for now. If you have any questions, feel free to email me.