Evaluating Your Firewall
Are you an administrator or security analyst who watches over a firewall with a hundred or more rules? Or perhaps a hired gun who must review a firewall with years of crusty buildup? Are you creating a test lab that involves a wide variety of networks, servers, and risks? If you're interested in enterprise-level firewalls, this article will help you make sense of common failures in processes and tools. We'll focus on enterprise-grade business and networking issues that affect firewalls. (Penetration studies and piercing firewalls from the outside will be covered in a later article.)
This article doesn't discuss small-scale firewalls such as those built into Microsoft Windows XP Service Pack 2 or Mac OS X. The firewall on your personal computer or on your small test lab isn't covered here.
Various brands of firewalls implement the same principles in different ways. The most difficult task is not learning a particular brand of firewall's specific operations; it's setting up the firewall securely and then maintaining it securely.
The Value of Firewalls
Once upon a time, many major institutions felt that they could run without firewalls, concentrating instead on server security. It wasn't long before intruders used all kinds of low-level, network-type attacks against such institutions:
Intruders might start a TCP connection but never complete the dialogue. Soon the server's TCP connection table would fill with empty connections that must wait for connection timeout values to be exhausted. (Imagine someone phoning you and never saying a word; you would just have to wait until the caller hung up.)
The attacker might fake a message from one machine to another. The packet/message would tell the character generation (CHARGEN) service to send a return message to the impersonated machine's ECHO service. Much like the Abbott and Costello "Who's on first?" comedy routine, ECHO would echo back, CHARGEN would generate a character back to machine 1, whose ECHO routine would echo back, and so on. Soon, both machines would be locked in this two-way dialogue, like arguing politicians.
Within ICMP, a message can be sent to a server, directing the server to use the attacker's device as the default gateway. Intruders would send this message to a server to force the server to route through an attack machine that would sniff (review and record) packets. Plain-text protocols such as FTP and Telnet could be hacked even in a switched network. The ICMP redirect is one message that few people remember when securing networks.
Want more examples? How about splattering an attack program into a hundred small pieces and then passing those pieces right under the nose of your antivirus software scanner? How about putting codes into the packet that direct what address a packet uses to go to and from a server?
Many such attacks against servers succeeded because the server must take network communications at face value. Intruders could use the network itself to bluff the server into attacking other servers or giving up information. Inserting a firewall between the enterprise's network and such Internet intruders helped to keep the worst incidental attacks out of the enterprise's servers.
Configured well, a firewall helps to ensure that the servers in the network seldom see an intruder's packet. The firewall creates a boundary between external networks and the internal network. Yet, firewall boundaries are increasingly being crossed, which is the reason that firewall inspections are essential.