How to build a secure Enterprise Firewall?

Firewalls and their architecture are a critical part of sound network security, but they are only the beginning to a secure enterprise network. In this paper, we will cover the fundamentals of good firewall design using a single multi-homed firewall design with stateful failover. The end result will be a network that is simple to manage, high performance, high availability, high security, and budget saving.

What is the most important aspect?

There has been some fierce debate in design philosophy on whether it is best to have one brand of firewall or more. I personally subscribe to the idea that two are usually not better than one because firewall vulnerabilities are rarely the problem in vast majority of break-ins. Hackers typically don’t need to hack the firewall because they come in through the ports that are already open and exploit the weaknesses on the servers behind the firewall. Additionally, there usually is nothing there for the hacker to hack on the firewall, because any smart administrator will lock that firewall down to drop all connections to the firewall it self except for the designated firewall management stations. Even if for example there is a known vulnerability in Apache or SSH on your firewall, the threat can only come from the designated management stations which are well protected or even turned off

1. Human factors comprises 99% of all firewall compromises
2. The cost of running multiple vendor firewalls may even force you to give up on the very things you need to be most concerned about.
3. Finite resources are usually much better spent hardening a single platform.
4. The biggest problem in firewall security is poor maintenance, bad policy and bad network design

Firewall design goals:

A good firewall policy and network design can mitigate (but not eliminate) the following security risks:

• The Internet attacking your DMZ servers
• Any part of your network attacking the Internet
• Your users or servers attacking your DMZ servers
• Your DMZ servers attacking your users, servers or even further harming them selves
• Threats from business partners and extranets
• Threats from remote offices via WAN connections

The first point is rather obvious; simply by limiting the service port access from the Internet to your DMZ servers, you can greatly reduce the chances that they will be hacked. On an SMTP mail server for example, only TCP port 25 is permitted from the Internet. Therefore, if that SMTP server happened to have a vulnerability in it’s web server service or daemon, it would not be exposed to the Internet where worms and hackers are always on the prowl for port 80 vulnerabilities.

The next point may seem a bit odd, why would one be concerned about protecting the public Internet with one’s own network? While this may seem to be just a good exercise in Netizenship (Internet citizenship), it is also for the selfish purpose of protecting one’s own Internet connection. Take the recent SQL slammer worm for instance; it managed to decimate large segments of the Internet for an entire day. Had there been better firewall policies in place, you could have prevented the DoS (Denial of Service) effect on your Internet connection and also saved the Internet.

One of the least recognized dangers in security is the internal threat. The most expensive firewall on the planet cannot protect your network from “Sneaker net” with conventional designs, a phenomenon where your user walks in to your network with a laptop or disk infected with a virus or worm from home or some other source. A good network design and firewall policy would protect your DMZ servers from your servers and users the same way it protects them from the Internet.

The reverse situation of the above is also a potential threat. Since DMZ servers are exposed to the public Internet, there is a chance that they can be compromised by a hacker or worm. It is essential that you limit the damage that your DMZ servers can do to your internal servers or user stations. Additionally, a tight firewall policy can also prevent DMZ servers from further damaging them selves. If a server is compromised by a hacker through some known or unknown vulnerability, the first thing they will try to do is down load a “root kit”. The firewall policy should prevent the downloading of this deadly payload and make life harder on the attacker.

Additional threats from Extranet partners and Remote office WANs can also be mitigated. Routers that connect these networks using WAN technologies such as frame relay, ISDN, private lease line, or VPN tunnels can be secured by the firewall. Trying to implement security with firewall enabled routers on each and every one of those routers is expensive not only in terms of hardware/software costs, but setup and administration as well. An enterprise firewall can provide simple and centralized management of WAN and Extranet security with additional zones beyond the conventional triple homed design.

The bottom line is that firewalls can limit the flow of traffic between network zones which are broken down by logical organization and functional purposes. A firewall cannot however limit and protect hosts from other hosts within the same subnet because data never passes the firewall for inspection. This is why the more zones a firewall supports, the more useful it is in a well designed enterprise network. This is now easier than ever to accomplish since all of the major players like Cisco and Nokia support trunking of interfaces. A single gigabit port can easily support as many zones as you like and still perform much better than several fast Ethernet ports.

Implementing a good firewall policy:
1. The first critical component of secure firewall architecture is policy design.

In firewall policies, this simply means that unless there is a specific reason that a service needs to be used, that service should be blocked by default.

To implement this default service blocking policy, only one simple firewall rule needs to be implemented globally at the end of all policy sets, the any-any-any-drop rule. This simply means that the default behavior of the firewall will drop all packets from any source to any destination on any service. It is important that this rule is the last rule in any policy set because firewalls act from top to bottom.
==> The narrower these rules are made, the more secure the network is.

For example, users should be permitted outbound ports for common services like HTTP, FTP, media services, but nothing else should be permitted unless there is a special case to allow such traffic. When there is a special case based on a business need, tightly targeted rules should be added when approved. A very common error that administrators make is that they extend user rights to server and DMZ networks. Outbound rules that are appropriate for users are generally not appropriate for servers. When you really think about it, there is no reason that your Web server needs to surf the Web. Servers should serve and are rarely a client. The bottom line is, the DMZ or Server farm should almost always never be permitted to initiate traffic. Servers typically take in requests, but almost never request services from the public Internet except for XML and EDI applications with business partners. Other exceptions can be things like legitimate vendor sites that provide drivers and software updates, but all exceptions should be narrowly defined. Following these strict guidelines can vastly reduce server compromises, to the point that even the intra-subnet spread of worms like Code Red and NIMDA could have been prevented had such policies been in place even if the servers were not patched.

Implementing a good firewall network design:

Figure 1 illustrates a Pix 525 with 2 Gigabit Ethernet ports and 6 100-Mbit Fast Ethernet ports. This is a great way to achieve physical separation of the different subnets needed for an Enterprise network, provided that each port is plugged in to a physically different Ethernet switch. How ever, I can tell you that this is rarely done and is often impractical to deploy more than half a dozen physical switches in the data center for each subnet. More often than not, enterprises employ virtual LANs by segmenting a single physical switch in to multiple bridge groups, which is extremely easy to provision addition ports for any existing subnet or future ones. Because of this and the fact that all the enterprise firewall vendors have added 802.1q trunking support (Cisco came late in February 2003), one can easily use a single Gigabit port to connect the Layer 3 core switch, DMZ, extranet, guest subnet, and any other VLAN subnets that an enterprise needs. Therefore, one can do with out the second Gigabit Ethernet card and 4 port Fast Ethernet card in the PIX 525 shown in figure 1. This has how ever raised need for Layer 2 switch security against things like “VLAN hopping” which is rarely discussed even among experts, but we shall leave that for another piece. But even with the trunked Gigabit port, you should continue using the two built in Fast Ethernet ports for public Internet and stateful failover synchronization. Bottom line, two firewalls in the same class as a PIX 525 can provide enough flexibility and throughput for most enterprise networks.

Figure 2 illustrates the use of the two firewalls in a stateful failover configuration. Network connections were only drawn to the logical firewall to avoid messy connectors in the drawing, but in reality there would be a physical connection to each firewall for each subnet. Those connections could be physically separate cables or a single trunked cable over a single Gigabit connection in to your 802.1q VLAN capable switch. The two built in fast Ethernet ports in a PIX 525 are used for the public Internet connection and the stateful failover synchronizing, and the remaining internal subnets can share the Gigabit port. This configuration is much faster than a configuration with separate fast Ethernet ports that often get congested when trying to do network intensive tasks like tape backup between zones.

The internal side of the firewall can connect the following subnets:

• Core layer 3 switch
• DMZ
• Extranet and WAN
• Guest zone
• Others

The core layer 3 connection typically goes to your core switch with routing capability between VLANs. Those VLANs from that core switch may contain hundreds of user VLANs with tens of thousands of users, and server farm VLANs with hundreds of servers that do not get direct Internet exposure. You must understand how ever that there is no firewall between the server farm VLANs and the user VLANs in this example, because user to server traffic is routed by the core L3 switch and never passes through the firewall. There are companies that go to the extreme of putting all of their servers directly behind the firewall and separated from the users, but the management of that many internal servers behind a firewall with a lot of port requirements can be very difficult, so this is not often done.

DMZ is used for servers that need to be accessed from the public Internet. This is directly behind the firewall and is always filtered for traffic.

The Extranet and WAN zone is for the internal interfaces of routers that connect the remote WAN sites and partner sites. Using this configuration allows you to secure against WAN and Extranet sites without having to buy or configure firewall feature sets on the routers them selves. One can even go to the extreme of putting the external interfaces of the routers in a non-NAT zone on the firewall, this helps prevent hackers from compromising the router from the outside. This approach allows the high availability enterprise firewall to secure countless routers.

The guest zone is something new, but this is actually a security feature. Instead of guests connecting to your internal LAN when they need access to VPN or the Internet, have them connect to a guest network with access to the Internet but not your internal LAN. This new zone is extremely useful in the wireless environment. With new Wi-Fi infrastructure technology supporting VLANs and 802.1q trunking, a single wireless Wi-Fi infrastructure can support multiple VLANs, one internal VLAN running it’s own SSID and 802.1x/EAP security, and a guest VLAN that runs a simple WEP password for Internet only access.