- The Methodical Approach and the Need for a Methodology
- Firewalls, Security, and Risk Management
- How to Think About Risk Management
- Computer Security Principles
- Firewall Recommendations and Definitions
- Why Do I Need a Firewall?
- Do I Need More Than a Firewall?
- What Kinds of Firewalls Are There?
- The Myth of "Trustworthy" or "Secure" Software
- Know Your Vulnerabilities
- Creating Security Policies
- Training
- Defense in Depth
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Firewall Recommendations and Definitions
A firewall is a device that provides secure separation of one or more networks from each other. In the ideal case, a firewall should provide physical separation between all networks. Virtual networks have become very popular, and there is a tendency to create "separation" between networks by using virtual abstractions. This is not a recommended configuration. One error in the configuration, a flaw in the software or hardware, or some other problem can cause your security to fail dramatically and completely with purely virtual network separation.
The best rule of thumb, especially given the availability of free firewalling technologies such as iptables and ipchains, is to always separate networks in a manner that you can physically verify. Color-coded wires running to networks on physically separated, not virtually or VLAN separated, switches and hubs is a wise investment. Nothing beats physical separation.
We also recommend that your routing scheme be organized in such a manner that if your firewall is misconfigured or fails for some reason, that traffic would not normally move from one domain of your network to the other. This might sound like common sense, but some commercial firewalls have been known to fail "open" and forward all traffic between networks.
For example, we were asked to look at a customer's network that was experiencing some "strange" behavior. After quickly looking at the company over the Internet, it was determined that their entire corporate network, every server and workstation, was completely exposed to the Internet. We knew that they had a firewall, and it was a reliable commercial grade product that should not have allowed this to occur. However, we also knew that they had been issued an Internet routable network by their ISP and were using that IP space for their internal network as well. When we arrived, we were amazed at what havoc a simple mistake could make. Our customer had installed their firewall on a switch and had plugged BOTH their internal and external interfaces into the same unmanageable switch! From their perspective, everything was working perfectly. They could get out to the Internet, mail worked, and everything was as it should be. You see, it turns out that they never bothered to check to see if anyone could get in! Sadly, this turns out to be the case with many organizations, which is why we recommend that your networks be configured in such a way as to make sure this is unlikely to occur if your firewall fails. One simple way to do this is to never, under any circumstances, use Internet routable IPs behind your firewalls. Thankfully, there is an entire IETF RFC dedicated to this, RFC 1918, and there are network blocks set aside for everyone to use for their internal use.
Briefly, they are:
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
If you use these addresses for your internal networks, they will not easily route over the Internet if you start to experience problems with your firewall.
You should also test your firewall—not to see if you can get out, but rather, start by testing to see if you can keep the bad guys out. We can't stress the importance of this enough. It's very easy to misconfigure a firewall and never know about it until it's too late.
Equally, this example serves to illustrate the value of using a private network for your internal and, where possible, DMZ networks. This is not a fool-proof solution, but it adds another layer of security to your risk management program.