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.
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.
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.
Normally, a firewall will only protect a system against data-driven attacks in exceptional circumstances. Such attacks include:
HTML pages that link in the contents of local files when they are opened without scripts. Such pages can, often with the help of unsuspecting local users who are lured into "helping" the page by clicking on a button, send the linked file onwards to an unknown Internet server.
Documents sent by email that contain hostile scripts which are activated once the document is opened. Possible ways to protect your system against this form of attack include avoiding using browser-based email software or disabling scripting and introducing mail gateways that can block scripts and other executable code.
Buffer overruns, which firewalls only rarely provide protection against. Buffer overruns can occur in any application, with a net result of intruders being able to coax protected computers into executing any command. Here, the only solution is to ensure that only well-written applications, which are specifically designed to be immune to this form of attack are installed and used. Unfortunately, most current software is not written with this problem in mind. At the time of writing, we are of the opinion that this poses the greatest technical threat of all forms of network-based attack, as almost all software is susceptible to buffer overruns.
Viruses and Trojan horses. A firewall can of course be connected to virus scanners, mail gateways and other similar devices in order to increase security, but it should be noted that the fundamental functionality of a firewall does not normally provide such protection.
Even if the firewall is connected to a virus scanner, it is possible that attacking viruses could be so well hidden that the scanner would be unable to detect them. In addition, a virus scanner can only detect viruses it recognizes. If somebody designs a virus specifically for attacking your systems or those of a small group of people, or if the Trojan or virus in question has not been in circulation long enough for it to become well known, the virus scanner will not recognize it.
At present, the most common targets for data-driven attacks are:
Public servers such as mail servers, DNS servers and web servers. Web servers are clearly over-represented in this category due to their enormous complexity.
Customized scripts on web servers. It is now very easy to extend the functionality of your web server by writing small, customized programs to handle a multitude of tasks. However, insufficient awareness of potential problems can lead you, more often than not, to make small, difficult to detect mistakes that will enable an intruder to gain access to your system.
Web browsers. Automation of processes and simplifying operations for the benefit of users creates increased internal complexity and thereby increased risks of vulnerabilities.
Desktop software, primarily that which to a great extent support scripting languages, for the same reason as browsers. Scripting languages provide almost unlimited access to local computers and all connected network resources. As a result, intruders can cause all types of problems if they can get internal users to open documents containing malevolent scripts.
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%.
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.
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.