Marcus J. Ranum
"Terror in cyberspace," "A million break-ins a year," "Most attacks go undetected." Many organizations are looking at connecting to the Internet but are terrified of the risk of being broken into by hackers, industrial spies, or other electronic miscreants. It's very hard to get an accurate picture of the size of the threat, or the real risk that any individual oganization runs by connecting. These days, however, it's becoming equally clear that not being connected to the Internet is also a business risk which may also equate to lost revenue, time-to-market, or customer perception. If you are not currently facing these unpleasant trade-offs, you will be within the next few years, as Internet connectivity becomes a common business infrastructure requirement like FAX has.
What's important to remember when dealing with Internet security is that it's not that much different from other security problems that we deal with every day. It is the newness of the Internet that makes it seem different and dangerous, more than anything else. When you approach Internet security, consider it as a (small!) fraction of the entire computer security requirements of your entire organization. Above all else, be consistent in how computer security is handled across the entire enterprise. Remember that you are every bit as likely to be attacked via dial-up access, social engineering, dumpster diving, or PBX/toll fraud as you are over the Internet! It's sad to see organizations that invest a huge amount of money and effort in securing their Internet connection, but which still have unprotected modem pools without even passwords or dial-back, which allow access into the network behind the firewall. To achieve a consistent security approach, you need to have management support and an architectural view of your entire enterprise; without it, you may have a secure firewall protecting a wide-open network behind it. Whenever you're not sure what to do with respect to Internet security, try to chart your course based on comparable approaches for "real world" systems that have worked in practice.
Probably the most expensive cost in a break-in will be downtime, system manager's time, time-to-market, and clean-up costs. In some cases, public embarassment may also be a significant factor. Before you approach anything that may affect the security of your systems, first ask yourself:
1) What do I need to protect?
2) How likely is it that someone will want to break/steal/alter it?
3) How badly will it hurt me if they succeed?
In some cases, the potential damage might be so high that no justfication for Internet connectvity exists. But, be careful before you conclude that, and examine your existing security practices. Frequently, organizations that have decided "no Internet connectivity ever" permit dial-in access or have other practices that are every bit as risky (often more!) than a well-secured Internet connection!
Often, organizations with very restrictive firewalls or "no Internet" policies have dial-out modems scattered around the network, as individuals who need access simply obtain it through Internet service providers. These links are potentially avenues of attack, just like other Internet links.
Many managers do not understand the level of sophistication that attackers are showing. As a result, they either over or under estimate the likelihood that their existing security (if they have any) will be compromised. In the last 4 years we have been under increasingly sophisticated attacks, including exploiting protocol level flaws, cryptographic flaws, and sophisticated social engineering. A pattern has emerged wherein highly skilled attackers ("ueberhackers") develop tools for exploiting specific weaknesses, and eventually the tools find their way into the hands of less skilled or completely unskilled novices ("ankle biters") who can still employ them to penetrate sophisticated defenses. Attackers are also persistent and understand how to exploit the often tangled interconnections between corporate networks, modem pools, and other networks (such as X.25 networks or PC LAN software). In the last year, there have been at least 3 cases of firewalls being compromised from the inside by attackers who gained access to management networks via dial-in modems left unattended on users' desktops.
What does this mean for the would-be connected site? If you have a firewall in place it does not mean you are invulnerable to attack. Other routes of attack into the network must be secured as well, and constant security awareness is mandated. Organizations with extremely critical data should put it behind internal firewalls and should further compartment their networks to make it harder for an attacker to succeed once they are in. In some cases, if your data is extremely sensitive or you have mission critical systems, you should consider not having an Internet connection at all, or having it only on a physically isolated network that is separate from your corporate backbone.
A number of organizations have concluded that security is not a problem for them because "nobody will bother attacking us." Unfortunately, when an attacker is choosing a target, he usually doesn't bother researching the target to see if they may be valuable; it is easier to smash in and look around. Attacks seem to be pretty much random as a result. Systems that have important data are ignored in favor of systems that simply catch the attacker's eye. Recently, attackers that broke into a financial database system were observed to completely ignore the financial data (worth millions of dollars) in favor of exploiting a back-door connection to a local university's computing center. It's unfortunate, but the unpredictable nature of attacks makes it very hard to place a value on defenses. One site with a very strong firewall and no important data might come under ferocious attack while another with no security at all in front of mission critical systems may be completely ignored. You can't rely on attackers to ignore you, though, unless your data is unimportant and your job is secure.
The first thing to ask yourself when considering Internet connectivity is, "if something happens to our network, will it put us out of business?" Connecting to public networks greatly increases that chance of "something" happening, and you must be prepared to weigh that in your design. Regardless of whether or not a security problem could put you out of business, try to estimate the kind of business damage that downtime or system clean-up might cost.
Organizations with intellectual property or private data must also consider the potential for disclosure of trade secrets, or the liability if a customer's private information is divulged. If you handle patient records, customer financial or credit card information, personal data, customer home addresses and demographic information, you should consult an attourney for information about best business practices in your field, and protect that data accordingly.
One approach that is effective in determining what your firewall
should do is the process of service-oriented requirements analysis.
Rather than simply jumping to technical details about what a firewall
should provide, take a step back and list the network services
that you want to take advantage of. A typical set is:
Based on the list of services you want to provide to your users, consider whether or not you have any special requirements that may mandate additional security services. Determine what kinds of audit trail or records (if any) you require relating to transactions through your network. Model your requirements on other "real life" services your organization uses, and try to keep the security policies consistent. For example, if you have a security policy that users cannot FTP data out, then you should also require that staff not Email data out, or mail floppy disks with data via the postal system. Consistently approaching security is key.
One other important thing to consider when approaching security is the growth plan for your network. If you install a firewall or Internet connection that provides a few services today, will your solution work 3 years from now? That does not mean that you'll be using the same physical hardware - the lifecycles of network equipment for Internet connections are fairly short - but make sure that the basic architecture that you put in place is likely to be viable in the long term.
Essentially, a firewall should be thought of as a gap between two networks, filled with something that lets only a few selected forms of traffic through. The designers of the firewall should be able to explain the mechanism that enforces the separation, as well as the mechanisms that carry data back and forth. Another important aspect of a firewall is how well it protects itself against attack: the firewall itself should not be easy to break into, since breaking into the firewall will give an attacker a foothold on your network.
The simplest and most popular form of firewalling is "router screening." Most commercial routers have some kind of capability built into them to restrict traffic between destinations, while permitting other traffic, etc. Screening routers operate only at the network level, and make all their permit/deny decisions based on the contents of the TCP/IP packet header. They are very fast, very flexible, and quite inexpensive, but they lack the ability to provide detailed audit information about traffic they transmit. Screening routers have often proven vulnerable to attack since they also rely on software being correctly configured on the hosts behind them. Many experts, for this reason, prefer to avoid screening routers as a sole defense.
A second form of firewall is the "dual-homed gateway" which is a system with two network interfaces that sits on both the protected network and on the public network. Since the gateway can communicate with both networks, it is an ideal place to install software for carrying data back and forth. Such software agents are called "proxies" and are usually customized for the service they are intended to provide. For example, a dual-homed gateway that has a proxy for WWW traffic will have some form of agent running on it that manages making requests to the remote networks on behalf of the user. Proxy firewalls (also known as "application firewalls") are attractive to many sites, since the proxies are able to perform detailed audit of data passing through them. They are also felt by many experts to be more secure, since the software proxies can be customized to specifically deflect known attacks that the host software behind the firewall might be vulnerable to. The main disadvantage of proxy firewalls is that they are sometimes not completely transparent, and they do not support protocols for which a proxy has not been developed.
Recently a number of firewalls based on "dynamic packet filtering" have appeared on the market. A dynamic packet filter firewall is like a cross between a proxy firewall and a screening router. To the end user it looks like it is operating only at the network level, but in fact the firewall is examining the traffic as it passes by, just like a proxy firewall's proxy application does. When a user connects out through the firewall, it records that fact and allows data to come back in to the user, for the duration of that session. Dynamic packet screening firewalls are an attractive technology that is still evolving, but which shows a great deal of promise for the future.
Firewalls, like many other security systems, are not perfect. The trade-off they usually represent is between ease of use and security. The more rigorously the firewall checks the user's identity and activity, the more likely the user is to feel interrupted, pestered, and resentful. When you choose a firewall, don't discount user resentment as a factor in your decision. Many sites with firewalls have internal networks festooned with uncontrolled dial-in/dial-out modems installed by users to bypass the firewall by subscribing to online services. If the security system you choose is not useful and easy to use, your end users will bypass it, unless you have sufficient authority to prevent them.
Proxy firewalls provide better auditing and finer access control than screening router firewalls, but many do not have sufficient capacity to support network connections faster than ethernet speed. If you are planning on using ATM networks or T3 lines, you may not have a choice available to you other than to use a screening router type firewall.
Academic organizations such as universities typically have the most trouble setting up a firewall. This is due to notions of academic freedom and to the fact that the user community usually wants to experiment with a wide variety of features of the network, and will tend to actively resent or circumvent a firewall that interferes with them. Additionally, academic organizations often have independent departmental budgets and semi-autonomous use of the campus network, which makes it difficult to enforce a common security approach. If one department in the university installs a security system that interferes with the others, they can and will simply purchase new network links to bypass it. One approach that seems to work for academia is to isolate critical computing systems behind internal firewalls. Systems where student records, loan information, and paychecks are processed should be isolated from the main campus networks by placing them behind screening routers or commercial firewalls.
Research labs are often another difficult case. Scientists expect to use the network for collaboration and research access to late-breaking information. In many cases, however, the research may be economically significant and should be protected. Systems where patent applications, designs for proprietary products, etc, should be isolated and protected - or consider adding a second network which is Internet accessible and keeping it physically separate from the internal research network. Research labs suffer many of the same problems as academia, since they tend to have user communities that want to be on the cutting edge and will not tolerate interference. Perhaps more than anything else, it is important to get staff to recognize the need to protect intellectual property. Many research labs are connected to the Internet behind commercial proxy-based firewalls that are fairly conservative but which permit access to the Web and other sources of information. Other research labs rely on separated networks or isolated systems for storing proprietary information.
As electronic commerce becomes more important, the need to pass commercial traffic into and out of firewalls will become more crucial. Service-oriented requirement analysis is a useful tool for designing and implementing such systems. Suppose an organization wants to put a Web server on an external network, and to provide database access of some sort to a system behind a firewall. In this case, our requirement is to get data back and forth for SQL only. We might choose a screening router firewall, configured to just allow the SQL data between the outside web server and the inside. A commercial firewall that permitted some kind of generic proxy or which supported an SQL service might be another option.
Typical firewalls require about an hour a week to maintain. That's only if you don't count the other Internet-related time that the firewall administrator (or someone) will spend. Internet connectivity brings with it the requirement for someone to act as postmaster for Email, Webmaster (potentially), FTP maintainer, and USENET news manager. These things are all time consuming and can become a full-time job for a single person. Often the firewall administrator winds up being responsible for a lot of tasks in addition to the firewall, and is usually the first person who is called or interrupted when someone detects a problem, cannot get their web browser to talk to the firewall, etc.
There are a number of tools available for building your own firewall. Trusted Information Systems, Inc.'s Internet Firewall Toolkit (fwtk) is a freely available reference implementation of a set of firewall application proxies. It is available via anonymous FTP from ftp://ftp.tis.com/pub/firewalls/toolkit. If you're building your own firewall using a router or a router and the toolkit, you can take advantage of the router's built-in screening. Brent Chapman and Elizabeth Zwicky's new book on firewalls describes some approaches to setting up a screening router.
What's important to weigh when deciding whether to build or buy is the cost of staff time. Unless your time is free, having an employee spend a week building a firewall may not be cost effective. You'll also wind up providing your own support in the long term, which will further increase costs. Before there were such a variety of commercial firewalls available, many companies hired consultants to build their firewalls. Nowadays that is not a cost-effective option, since the consultant eventually costs more than a commercial firewall and may not be able to support or enhance it over time.
How do you know if a firewall is secure? It's very difficult, since there are no formal tests that can be easily applied to something as flexible as a firewall. A safe rule of thumb is that the more the firewall lets in and out, the less likely it is to be resistant to attack. The only firewall that is absolutely secure is one that is turned off!
If you're worried about the quality of a firewall from particular vendor, use common sense and ask the same kinds of questions you would about any other mission critical product you buy: ask how long they've been in the business, the size of their installed base, and whether they have had independent experts review their design and implementation. A vendor should be able to clearly articulate how the design of their firewall leads to its security. Don't just accept hand-waving or insinuations that their competitors' products are insecure.
A common misconception in firewalls is that you get what you pay for and therefore that the more expensive a firewall is, the more secure it is. Unlike PC hardware, which is a commodity market, the firewall market has not yet settled down enough for consistent and competitive pricing to evolve. Most firewalls available commercially cost $10,000-$20,000 but the more expensive offerings can cost as much as $80,000 and up. A firewall buyer should show some healthy skepticism when it comes to cost versus value. If a firewall costs twice as much as another, the seller should be able to clearly explain why their product is twice as good.
Most firewalls used to be sold as consulting packages. When a firewall was sold, part of its cost was installation and support, usually involving a consultant from the vendor arriving onsite and assisting with the installation. In the "bad old days" many of the sites that were connecting to the Internet had no local TCP/IP expertise, so the firewall installer's job often also encompassed configuring routing, and tasks like setting up internal DNS and sendmail. Some vendors still provide such a level of service, while others simply ship a power-on-and-configure turnkey solution.
Typically, when you install a firewall, the Internet connection must be ready, but not connected to the protected network. The firewall installer arrives, tests the machine's basic function, and then may lead a meeting in which to work out the details of how the firewall will be configured: what access control policy you want to put in place, where Email will be routed to, where should logging information be forwarded, and so forth. Once the installer has a good idea how the firewall is to be configured, it is connected to the Internet side, and tested for correct operation with the network. Then the firewall's access control rules are installed and checked, and it is connected to the protected network. Typically, some basic interoperation tests are performed, such as Web access, Email sending and reciept. When everything checks out OK, you're on the Internet!
Most vendors provide some kind of support period for basic questions pertaining to the firewall. Many provide an installation service such as described, which is valuable since you get an opportunity to tailor your firewall in a way that makes sense for you, while you have qualified vendor support ready to help. Often, a difficult part of setting up a firewall is getting various packages behind the firewall to talk correctly to it. Some vendors provide direct support as far as hooking PC LAN mail systems into the firewall's mailer or configuring DNS. If you do not have technical skills in these areas, having a vendor that is able and willing to support your configuration is a big time and energy saver.
Some Internet Service Providers (ISPs) offer a supported firewall as part of their connectivity service. For organizations that are new to TCP/IP or that are in a hurry, this is an attractive option, since the network support, leased line support, and firewall support are all through the same vendor.
The single most important thing that a vendor can provide with their firewall is an understanding of how to make a sensible security policy. Unless you are sure that you understand what you're letting into and out of your network, you may not be safe if you just install a firewall that lets you point and click and decide what to allow through. Some firewalls can be configured to allow through things that they normally should not, on the assumption that the user is an expert and know what they are doing. Support from the vendor in getting everything set up with a reasonable baseline helps keep you from having a firewall that you've accidentally configured to allow an attack through it.
Vendors typically do not configure internal legacy systems to work with the firewall. For example, most firewalls assume that they are talking to Internet on one side and a TCP/IP network on the other. Usually, it is the customer's responsibility to have TCP/IP capable systems on the inside network, which the firewall can interact with. For Email, firewalls mostly support only SMTP (Simple Mail Transfer Protocol) and it is the customer's responsibility to have an SMTP compatible system someplace on the inside, and often it is the customer's responsibility to know any system specific configuration changes necessary to get that internal SMTP system to forward all Internet outbound mail to the firewall. Unless you're buying your firewall from an ISP, it is usually your responsibility to have a class C IP network address and domain name allocated.
Some of the questions to ask firewall vendors (other than just price and delivery times) are as follows:
Choosing a firewall is a lot like choosing a car. We assume chosing a car is easy because by the time most of us can afford one, we already have a lot of the information we need to be able to quickly and easily assess the cost/benefit performance/convenience tradeoffs that different cars represent. The best way to make sure you get a firewall that suits you is to educate yourself enough on the topic that you can choose wisely. Some good books for more information are:
"Firewalls and Internet Security: pursuing the wily hacker" by Bill Cheswick and Steve Bellovin, published by Addison-Wesley.
"Building Internet Firewalls" by Brent Chapman and Elizabeth Zwicky, published by O'Rielly and Associates.