Network Defense by Rik Farrow [subhead] Your firewall may be doing you more harm than good Firewalls were developed to provide access control, authentication, and logging of network traffic back in the late eighties. The early firewall developers were a conservative bunch, and designed rigorous defenses. If you worked with these early products, you will likely remember how difficult they were to configure and use. Contemporary firewall vendors have learned to focus on ease-of-use as a means of capturing greater market share. And thus lies the crux of the problem. Where firewalls were originally designed as your first line of network defense, vendors have designed today's products with simple installation, configuration, and performance as the top goals. And while a modern firewall is much easier to install and use, it is also much likelier to be insecure. In a survey conducted by the Computer Security Institute (http://www.gocsi.com/) at the end of 1997, thirty percent of respondents reported Internet security breaches with a firewall installed. Of these sites, 51% replied that the cause was mis-configuration of the firewall, and 41% added that product weakness of the firewall contributed to the breach. "The biggest problem today is that firewalls are reviewed as if they were end-user products instead of IS security products," said Bill Stout, an independent security consultant (StoutB@pios.com). Firewall vendors quickly learned that the easiest to install and setup firewalls quickly gathered the largest market share. "Some (most) firewalls allow you to do things which actually make the firewall less secure," stated Fred Avolio, until recently Product Manager for the TIS Gauntlet firewall, and now also an independent consultant (fred@avolio.com). I vividly remember when a reviews editor at a UNIX magazine discovered the first firewall product with a graphical user interface during an InterOp show in Las Vegas. He was ecstatic. My own perspective was quite different. From a security point of view, the vendor had improved the state-of-the-art in packet filtering by inventing stateful packet filtering. Past approaches to packet filtering required leaving gaping holes in the firewall. The stateful packet filtering approach permitted the firewall to react dynamically to a handful of protocols that required additional ports to complete a transaction (such as FTP). Stateful packet filtering, called stateful inspection by Checkpoint, was indeed a great improvement over plain, old packet filtering. Unsafe at Any Speed But it was the GUI that had the editor excited, not the technical tweak to packet filtering. And it was the GUI that was the problem. By pointing and clicking, the firewall manager could permit over a hundred different Internet services __most of which were terribly insecure and should never be permitted through the firewall__. But because these services were included in the GUI, the firewall administrator would generally consider them safe, having been blessed by the designers of the firewall's user interface. In theory, your firewall is an implementation of your security policy. That means that you read your policy, then configure the firewall so that it enforces that policy (you do have a written security policy, don't you?) In practice, someone installed the software, and then point-and-clicked his or her way through the GUI enabling the things that he or she felt were needed. Later, more services would be permitted through the firewall, as constituencies within the organization demanded support for their pet service. Avolio stated that most organizations "get lax in following the security policy (should it exist), and punch holes in the firewall (or go around it) for business 'requirements'". Cavalier configuration of firewalls has resulted in firewalls that are less than secure. The firewall has become just another check mark on an audit: the firewall is there? Yes, okay, next item. Note that this is not necessarily the fault of the vendors. It is possible to use most firewall products in a way that will definitely improve the security of your networks. But most sites do not. Firewall Audit So, you want to use the firewall appropriately and want to know what you should be doing? Let's go through an audit of your firewall and see how well your organization rates. Here is a step-by-step approach to auditing your firewall: o Acquire a copy of your security policy o List permitted services o Check the configuration of the firewall to see if it complies with this list of services o Correct, if at all possible, the configuration of the firewall to comply with the policy o Check the configuration of the firewall host: are all security patches installed and unnecessary services disabled? o Scan your firewall to see what services appear o Probe for hosts that should be protected behind the firewall o Examine how firewall logs are maintained, and see who checks daily reports If you do not have a written security policy, you have failed the audit. Without clear goals in mind, most firewalls are simply network- based devices that cost money and slow down network traffic. No matter how secure a firewall's design may be, there are always ways to get around that security, included by firewall vendors to support oddball services in some cases, but more commonly simply to satisfy the market. The policy tells you which services may be permitted. Next, find the section that defines permitted services and access between untrusted networks and your own networks. Typically, the untrusted network with which you are concerned is the Internet, but any network that you do not have administrative control over should also not be trusted. Extract the list of permitted services and forms of access (such as one-time-password authenticated telnet). Hopefully, the list of services is a short one. In the world of security, small is beautiful. With this list in hand, compare the services permitted by the firewall to the services included in your security policy. If the list of services matches exactly, give your organization an A. In reality, less than 5% of all firewalls will be configured this way. Instead, you will discover a whole host of additional service that have been enabled. Your task now is to go through this list, and discover why they have been enabled. Words of Wisdom If you have documented the configuration of your firewall, discovering why the additional services are there will be easy. More likely, these services were enabled "on the fly" to solve the needs of a particular group within your organization. An easy, although terribly practical, method for uncovering who asked for a particular service is to shut it off and wait for the phone to ring. A less traumatic technique is to examine the firewall logs, and determine which subnets are using that service. The meticulous (and paranoid) organizations will at this point see about changing the security policy if there are additional services that need to be permitted through the firewall. A part of modifying your policy includes determining if the risk involved in permitting the service are greater than the rewards. If the rewards are nothing more than convenience, the risk will always be higher. In most cases, the group that wants the service must present the business requirement for the service, and you must provide the potential risk caused by that service. Good sources of information about risks include books and mailing lists (see sidebar). One issue deserves the utmost caution, what Marcus Ranum, CEO of Network Flight Recorder, Inc, and a past firewall developer, calls the "incoming traffic problem". Ranum describes this as the "biggest overall flaw with the firewall concept." If you permit traffic from outside your firewall to servers on the inside, there is no way to guarantee that a flaw in that server will never appear that permits the server to be compromised. Proxies, packet filters and stateful packet filters have no way of guarding against potential compromises at all (other than totally blocking access). Application gateways can guard against __known__ attacks, once the application gateway has be rewritten to block these attacks. But, there will always be a time lag. And most firewalls today do not even use application gateways, but use other mechanism (proxies or some form of packet filtering), and have no chance at all. If you plan on permitting non-authenticated access to one of your servers, such as a Web server, place the server outside of your firewall, or on a separate subnet connected to the firewall (and often called a DMZ). In the event of a successful attack of this server, it will be outside of your trusted network, and not a base for further attacks upon your site. Also, use your firewall to prevent a potentially compromised server from being the base for attacks on other sites. Straw Houses Most firewalls today are host based. That is, the firewalls were installed on an NT or UNIX system. "In nearly every case with NT firewalls, no attention is paid to hardening the base O.S. itself," claimed Stout. "Even installers from the vendor rely on firewall code or network 'shims' to protect the O.S. - a big mistake." The firewall, by design, sits in the most hostile position possible on your network - as the guard at your front gate. You must expect your firewall to be subject to attacks, and configure it to be as resistant to attack as possible. And relying on the firewall software itself is not enough. One technique for breaking in through a firewall involved crashing the firewall software itself. Once the firewall had stopped working, even momentarily, the host itself is attacked. If the host can be compromised, the entire network it is supposed to defend is now accessible. One vendor dealt with this problem by installing a daemon that would periodically check to see if the firewall software was still running. An attacker could take advantage of the interval between checks to probe and attack the host. Once the host is compromised, changing the firewall configuration to permit the attacker's access is easy. Instead of relying on a firewall vendor, check your host security yourself. Check to see that all security-related and TCP/IP stack patches have been installed. Some firewall vendors post a list of suitable patches on their web sites, while many others do not. You want to check for this list, as some OS patches might break your firewall software. Also, disable all unnecessary network services. On most UNIX-based firewalls, this will be all network services other than those that are included in the firewall software. You can check to see which services are running by using the ps and the netstat commands. On NT systems, the problem is trickier, as some services might be required by your firewall's configuration. For example, if your NT-based firewall authenticates users against a domain, you must leave the Server, Netlogon, and possibly other services enabled. If possible, pick a quiet time and experiment with disabling network services using the Services applet in the Control Panel. Many firewall products bundle in additional services, such as a Web, FTP, and/or news server as part of the firewall. As all of these services have been compromised (not once, but many times) in the past, it is not good policy to include extraneous servers as part of your firewall. Most firewalls have to struggle to keep up with heavy traffic loads as is, and it makes no sense at all to include a server that may provide an attacker with a backdoor to the firewall - and to your network. Put the additional server(s) on a different computer, preferably on a DMZ. Reconnaisance Now that you have battened down your firewall, you check it from the outside. In past columns, I have described good scanning software, such as Strobe and Nmap, and there are commercial tools for doing this as well. Scan the firewall itself. The only services the tools should find are those that are proxied by the firewall (presumably, nothing at all from the outside, or a very limited set). Also try scanning hosts on the inside, behind the firewall, and presumably protected, and see if you can reach them. Don't forget to try ICMP, for example, Ping. Ping is often used in probes, and there is a hacker tool that uses the ping protocol to send commands and receive replies - something that many firewalls will permit, and not log. Finally, check to see how logs are being maintained, and who (if anyone) actually reviews daily reports. "Some sites are very diligent (perhaps overly so, for the return on investment) while others quickly get slipshod and ignore them, never upgrade releases, and assume that they're safe for eternity," said Ranum. Firewalls should not be like toasters, used until they catch on fire, and then cleaned. The logs and daily reports (not all firewalls include reporting capabilities) are a critical part of a correctly configured firewall, and if your organization is ignoring these reports, you have lost half of the value of having a firewall. Reports can indicate attacks in progress, a breach in the firewall, use of your site for spamming, and even an internal user slipping vast quantities of confidential material to a competitor (all this has actually happened). The majority of sites today (over 80% according to the CSI survey) have firewalls. Of these sites, only a minority have correctly configured and maintained firewalls. The vendors are only partly to blame - they produced the products which the market has demanded. Due diligence on your part can make most firewall products secure through careful configuration and management. [sidebar] It is the rare firewall product which includes information about the dangers inherent in permitting particular services through a firewall, or certain configuration practices. The best book on Internet security remains Cheswick and Bellovin, although it is due for a revision. You can also get advice about the safety of particular services by subscribing to mail lists or via USENET news. ISS still maintains an excellent list of security related mailing lists (http://www.iss.net/vd/mail.html). Here are some books which I personaly recommend to help you improve the security of your firewalls and the host they are installed upon: Cheswick and Bellovin, Firewalls and Internet Security, Addison-Wesley, Reading, MA, 1994 (includes an extensive bibliography) Chapman, B., Zwicky, E., Building Internet Firewalls, O'Reilly and Associates, Inc., Sebastopol, CA, 1995 (too much focus on packet filters, but good otherwise) S. Garfinkle, G. Spafford, Practical UNIX Security, O'Reilly & Associates, Sebastopol. CA, 1996, second edition Sutton, Stephen, Windows NT Security Guide, Addison-Wesley, 1997 (ISBN 0-201-41969-6) [end sidebar]