What does a Firewall not protect against?

This section includes the following topics:


Security means much more than just firewalls. However, in most cases, installing a firewall is a necessary first step towards securing your network and computers.

This section is not specifically devoted to Amaranten Firewall; instead it discusses firewalls in general. The problems described here will occur no matter which firewall you choose to install.

A common misconception is that all communication is immediately made safe and secure once it passes through a firewall.

This is not true.

Many marketing executives and salespeople smile and claim that "our firewall will protect you against everything". We hope that this is just sheer ignorance on their part and not a conscious attempt to mislead potential buyers.

A firewall can only protect against that for which it was designed. Unfortunately, it is impossible to predict all the bugs other software may have. In addition, there are a large number of situations where a firewall quite simply cannot provide protection since not all communication passes through it.

The following is a selection of security problems that firewalls are often unable to deal with, and in some instances we have provided solutions to combat these.

Please note that this only scratches the surface in terms of the number of existing problems.

Complete protection can only be achieved through thorough understanding of all possible weaknesses in network protocols and in the software used, and by implementing appropriate measures to compensate for these.

Attacks on Insecure pre-installed Components

A very common problem is the fact that operating systems and applications usually contain insecure pre-installed components. Such components include undocumented services present on computers connected to the Internet, allowing inbound external network connections. One example of this form of vulnerability is the "simplifying" components that allow direct ODBC access via HTTP in web servers.

The common feature of most of these components is that they are not intended for use on a public network, where intruders can utilize the extra functionality at hand to easily break into the system. However, modern systems are frequently supplied with such components pre-installed in order to make the system easier to use.

A good precaution to take is to review all Internet-connected systems, clients and servers, and remove all unnecessary functionality.

Inexperienced Users on protected Networks

No firewall in the world can protect against the damage that inexperienced users can do to a protected network.

If they "assist" an intruder in one way or another, e.g. by opening an unrecognized program sent to them by email such as "merryxmas2001.exe", they can do more damage than all the bugs in applications and operating systems put together.

All attempts to secure the networks of an organization should be preceded by a thorough investigation of what should and should not be permitted. The result of this should be a security policy that applies to all parts of the organization, from management down. In order for such a policy to work, all users must be made aware of this policy and why it must be enforced.

Data-Driven Network Attacks

Normally, a firewall will only protect a system against data-driven attacks in exceptional circumstances. Such attacks include:

At present, the most common targets for data-driven attacks are:

Internal Attacks

A firewall can only filter data that passes through it. Therefore it can offer no protection from internal attacks on local networks, where all computers communicate directly with each other.

In addition, firewalls cannot provide protection against local users introducing harmful software to the network from a floppy disk, or by exporting sensitive information in the same manner.

This may seem obvious. However, most people underestimate the impact of such damage.

Although different sources provide different figures, it is clear that more than 50% of all data security problems are the results of internal attacks. Some sources put this figure as high at 80%.

Modems and VPN Connections

A common misconception is that modems and VPN gateways are equally secure as the protected network and can be connected directly to it without protection.

Modem pools can be subject to direct attack and, in extreme cases, telephone lines can be tapped. Switches, located at any point in the telecommunications network or in the office, can be reprogrammed without the intruder needing to be anywhere near them.

When it comes to VPN connections, it is important to remember that although the connection itself may be secure, the total level of security is only as high as the security of the tunnel endpoints.

It is becoming increasingly common for users on the move to connect directly to their company? network via VPN from their laptops. However, the laptop itself is often not protected. In other words, an intruder can gain access to the protected network through an unprotected laptop and already-opened VPN connections.

A basic precaution to take in protecting your network against modem and VPN connection attacks is to ensure that mobile computers never communicate directly with the Internet. Instead, they should always be routed through the VPN or modem connection and the company? network, regardless of whom they wish to communicate with. This way, they enjoy more or less the same level of protection as the rest of the network. For VPN connections, a competent VPN client that can block all inbound Internet traffic, aside from that which passes through the VPN connection, must be installed on each laptop.

A VPN connection or modem pool should never be regarded as a direct part of a protected network. The VPN endpoints should instead be located in a special DMZ or outside a firewall dedicated to this task. By doing this, you can restrict which services can be accessed via VPN and modem and therefore ensure that these services are well protected against intruders.

In instances where the firewall features an integrated VPN gateway, it is usually possible to dictate the types of communication permitted. The Amaranten Firewall IPsec VPN module features just such a facility.

Holes between DMZs and Internal Networks

Although the advent of extranets and e-commerce has served to drive development forwards, and as more and more companies begin to make internal data available via web servers, security hazards are increasing as a result.

It is now common practice to locate web servers in demilitarized zones, where they communicate with data sources on protected networks. In such cases, data-driven attacks pose a huge threat.

The problem with holes between DMZs and internal networks is not really a problem in itself. Rather, it is a consequence of the problems discussed above. Many people open up these holes without being aware of the problems they may cause, which is why we have chosen to highlight this problem in a separate section.

The reason for locating a web server in a DMZ is simple ?the server cannot be relied upon to be completely secure. What happens if someone gains control over the server and there is an open hole through which access can be gained to data sources on the internal network? The result is that the "protected" network is open to attack from the Internet, using the web server as an intermediate.

Do not underestimate the effects of this vulnerability! In our experience, even the most inexperienced of attackers need only a few minutes to gain access to protected networks using standardized and well-known techniques, specifically developed to exploit this type of hole.

The simplest defense against this is increased segmentation of the network. By locating the data source, e.g. an SQL server, in a separate network segment and preventing it from communicating directly with the rest of the network, you can limit the damage caused by such an attack.

Note: The problem here is not IP packets being routed via the servers in the DMZ, so therefore disabling "IP forwarding" would not provide any protection. The problem is that intruders can execute commands on these servers the same way that anyone at the keyboard could.

It should also be noted that your internal network would still be vulnerable to attack even if the channel between the DMZ and the internal network is made up of a non-routable protocol such as NetBEUI. Again, the problem is not IP packets traversing from insecure networks to the internal network. Rather, the problem is that insecure machines can execute commands on "protected" machines.

Another form of protection worth considering is to set up a separate data source that contains limited information to which the web server has access. It should only contain information deemed sufficiently insensitive to be accessed from the web server. This process requires an automatic export of data from the internal data source to the external data source, to be executed when information needs to be updated, or at fixed times of the day. An insurmountable problem may arise when the web server needs to update the data source. The best way of tackling such a problem is to move the affected data source to a separate network segment, thereby decreasing the potential damage in the case of intrusion.