In an earlier installment of this series, I made the point that all firewalls are implemented in software and that a so-called:

"hardware" firewall is simply a discreet hardware device that is dedicated to the purpose of running firewall software.

"Software" firewalls typically run on the same device that they are protecting. This may seem like a small distinction, but hardware firewalls provide much more reliable security than software firewalls precisely because they are running on a separate device. This is because:

- A firewall running on a separate device is relatively inaccessible to any walware that may be running on computers on the inside network.

In contrast, if malware does make it onto a Windows XP workstation, it can easily disable the Windows Firewall with a couple of registry entries, opening the computer up to more infections**. The much-maligned User Access Control (UAC) feature of Vista makes it more difficult for malware to make registry changes without explicit user consent.

Third party software products can protect against system modifications as well. The problem with these is that they require users to make informed decisions about which changes are allowed. Most users do not have enough information to make these decisions, and get into the habit of allowing changes in order to keep things working.
- A hardware firewall can run a specially hardened operating system that is specifically designed for that purpose and that purpose alone. Hardware firewalls typically run on either a proprietary OS (such as the Cisco IOS) or a hardened version of Linux.

This is not to suggest that a hardware firewall is sufficient protection and software firewalls are not necessary. Just because there is a guard at the front gate does not mean that there should not be another one at the front door. Here are a couple reasons that we need to maintain software firewalls on each device, in addition to a hardware firewall protecting the network gateway:
- Software firewalls can be individually "tuned" for each computer. For instance, the FTP server will certainly need to allow connections on ports 20 and 21, but these ports should be closed on other computers.

- A hardware firewall may be protecting the gateway from incoming connections, but not all threats come from the outside. Software firewalls can regulate connections between computers on the inside network to prevent the spread of worms or other malware from one machine to another.

It is not a matter of choosing between hardware and software firewalls - they serve different purposes and a the best way to secure a network is to run both.

** Viruses sometimes disable the Windows XP firewall by adding the following keys. To enable the firewall, you can delete these two keys:

* HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall
\DomainProfile \EnableFirewall=0 (DWORD data type)
* HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall
\StandardProfile \EnableFirewall=0 (DWORD data type)

Next: Why a UTM is much more than a firewall

Dennis H in West Virginia, US

February 9 - 2009

We install firewalls to prevent computers on the outside of the protected network from initiating connections to computers on the inside. The problem is that we sometimes WANT to allow computers on the outside to access services inside the network. Examples would be when we want to allow remote access to a computer, or when we want to make services (such as a web server, mail server, or ftp server) available to clients outside the network. VOIP and Peer-to-Peer protocols also require internal computers to offer services that can be accessed from the outside.

Offering these services means that we must "poke some holes" through our firewalls. We want to do this in a way that only allows the connections we want, but any "hole" that allows inbound connections can also be exploited by malicious programs.

The easiest way to get inbound packets through a firewall is to simply configure an inbound rule that allows packets that meet specific criteria to pass through. An example would be to allow incoming packets bound for port 80 to pass through the firewall so an incoming http connection can be established.

Most firewalls also provide Network Address Translation (NAT) or Port Address Translation (PAT), so firewall rules also need to change the packet's destination address to that of the internal host that is offering the service. This is generally known as "port forwarding". Incoming connections can be directed to any host that is offering a service on a well-known port. We can also move services to non-standard ports. This means that the connection can only be established if the connecting computer knows which port the service is running on.

Another common approach to solving this problem is to run a small program on the internal computer that maintains a constant OUTBOUND connection to server outside the network. This connection is established as soon as the computer boots. In this way, there is no need to allow an inbound connection. When we want to connect to the internal computer, we connect to the same server, which then relays communications.

NAT and PAT pose additional problems for IPSec, which has long been the preferred protocol for VPNs. IPSec and NAT do not work well together for two reasons.

1. The first one is that IPSec provides for message integrity, as well as confidentiality. When the IP address in the packet header is changed by NAT, this also changes the checksum for the packet. Since the checksum no longer matches the one calculated before the packet was sent, packet integrity has been compromised and the packet is dropped.
2. The second problem is that when the Encapsulating Security Protocol (ESP) is used, the packet headers are encrypted. The NAT service cannot change encrypted headers. The typical solution to this problem is to encapsulate the entire IPSec packet inside a UDP packet, which is then routed to the destination machine and un-encapsulated. The "IPSec Passthrough" feature on many routers automatically opens the UDP ports necessary for IPSec NAT traversal. As discussed in the series on VPNs, this IPSec / NAT incompatibility is the main reason that SSL VPNs have become more common and IPSec VPNs are falling from favor.

There are at least five or six methods of NAT traversal, and the discussion above is greatly simplified. If you really want to dig into the details of NAT traversal, here is a Wikipedia article with links to the relevant RFCs and other articles describing the details of each method. Have fun nerding it up.

Next: Part 8 - Outbound Firewalls

Dennis H in West Virginia, US

January 26, 2009

Keeping Windows machines updated is always important, but it is especially important right now. The conficker worm (also known as downadup, downup, and kido) is estimated to have infected 9 million computers and is spreading rapidly (the number of infections has tripled in the past few days. This worm exploits a flaw in all recent versions of Windows, including server versions and Vista. Microsoft issued an out-of-cycle patch in OCTOBER to correct the flaw, but an estimated ONE-THIRD of Windows machines do not have the patch installed. AMAZING

This is worm, so it requires NO USER ACTION for the exploit - any un-patched Windows machine is a sitting duck if it is not protected by a properly-configured firewall. It can also spread through removable devices (another good reason to disable autorun). It also wages brute-force attacks against network passwords. It attaches itself to critical Windows processes and downloads additional malware. NASTY

The January version of Microsoft's Malicious Software Removal Tool (MSRT) is supposed to be able to detect and remove this threat. Microsoft recommends installing their emergency update, and then running the MSRT.

More details are available in this Wikipedia article.

Dennis H in West Virginia, US

January 19, 2009

A proxy server pretty much does what the name implies - it serves as a proxy for network connections. A client computer that wants to establish a connection to server through a proxy connects to the proxy, rather than to the actual server. The proxy then connects to the server. When the client wants to request something from the server, it sends this request to the proxy, which then requests it from the server. Responses from the server are sent to the proxy, which then sends them on to the client. The client does not have a direct connection to the server. The proxy maintains two connections  one to the client and one to the server. All packets traveling in either direction are received by the proxy. These packets can be sent back out on the other connection, dropped, or modified, depending upon the type of proxy and the rule set with which it is configured.

Application proxies have intimate knowledge of specific protocols  typically web protocols like http, ftp, and smtp. They have the ability to analyze the structure of the data in these packets for proper syntax of requests, queries, and commands, as well as the ability to analyze for specific errors or malicious content. Since they actually maintain the connections, rather than just inspect the contents of packets, track application behavio(u)r more closely than any firewall that simply uses deep packet inspection to analyze packets. Application proxies operate at the application layer of the OSI model.

Other proxies operate at lower layers of the OSI model and focus on the behavio(u)r of protocols at these layers. SOCKS (short of sockets) proxies are a good example. They can monitor a wider variety of protocols, but some protocols have to be SOCKS-aware (sometimes referred to as socksified) in order to pass properly.

Most proxy servers actually provide a number of proxy services at different layers. The most widely known examples of proxy servers are the Microsoft ISA (Internet Security and Acceleration) server and SQUID (Linux / open source)

Proxy servers are the most effective type of firewall, especially for web applications. They can be used to provide NAT (network address translation), web filtering (blocking out unwanted sites, such as porn, gambling, and job search sites), logging (a detailed record of who goes where), and many other security services.

Proxy servers can be hardened to be resistant to attacks. Since computers on the internal network never connect directly to computer on the outside, they cannot be attacked or compromised directly. However, if the proxy server becomes compromised, it then serves as a beachhead for further intrusion.

Proxy servers provide non-security benefits as well. They can speed internet connections by caching commonly-requested pages, thus eliminating the need to repeatedly download the same page over the WAN connection. This also conserves internet bandwidth.

The disadvantages are fairly obvious. There is a substantial overhead cost to setting up and maintaining proxy servers. These servers need a lot of horsepower in order to keep up with the tasks expected of them. Even with the fastest servers, internet connection speeds are likely to take a hit when multiple users are being routed through the server.

Of course, proxy servers cannot analyze SSL packets, since these are encrypted. This represents a HUGE hole, since it would be neither practical nor desirable to block SSL traffic. Any application, including malicious ones, can tunnel undesirable traffic over SSL connections to avoid analysis by the proxy server. That is, of course, unless the proxy server has the ability to decrypt the packets, analyze them, re-encrypt them, and then send them on to their destination. This is can be done by using an SSL proxy. That will be the subject of Part 6 of this series.

Dennis H in West Virginia, US

January 11, 2009