The following article is excerpted from the Computer Security Journal, Vol. XI, No. 1, Spring 1995. All rights reserved.

CSI Special Report on Firewalls: How NOT to build a firewall

By Richard Power

Marcus Ranum is President and CEO of Network Flight Recorder (Baltimore, MD). Specializing in Internet and UNIX security, he is a leading authority on firewalls. Ranum was principle designer of the TIS Internet Firewall Toolkit and engineering managerfor the company's commercial firewall, Gauntlet. In this interview, he shares insights on the realworld problems involved in implementing firewalls.

A CSI member in charge of network security for a medical center recently asked, 'My users want Internet access. I guess I need a firewall. Where do I begin? How do I start the process?"

His people are doing the right thing, because they said "We want to connect to the Internet," but they haven't just gone out and done it. They've asked him first. Fairly often, someone wants to connect to the Internet and they bury it in a line item. It just sort of happens and none of the security issues get handled. The guys in the research lab just do it. At least, in this case, they're bringing it to his attention. Of course, the cynic in me wants to point out that this is a lot like a child saying, 'Daddy, can I go in the refrigerator.'They're not saying 'Can I go in the refrigerator to get ice cream?' Or'Can I go into the refrigerator to get the vitamins?' They're not really saying what they're going to do. The simple answer is, 'What is it you want to do with the Internet?'

Of course, the answer will probably be 'Well, everything.'That brings up the whole policy question. The best way to do it is to look at what Internet services you're planning on using and figure which of those services are ones you're going to want to secure in some way, shape or form and secure them. If the answer is 'everything' and 'we need complete security,' you can't do that. The other end is we need to do nothing and for that you can have complete security. Everything in between is up for negotiation. And it becomes a matter of looking at the business needs and the policy implications.

Give some examples of how different needs dictate different approaches?

90% of the people want to play Web, they want to get e-mail, they want to pull down all those cool, dirty gifts from Usenet. Those are the main things people want to do.

At the other end of the spectrum, you have the service providers. Those are the guys who truly know pain. Their customers are paying them for complete, unadulterated access so they can't put security in. Most people connecting up to the Internet fall into the first category. But people providing services require direct connectivity that a security system simply won't work with. Those guys have to do a really interesting dance. Let's say you have a mission critical application that requires a direct link to somebody else-for example, a stock brokerage firm that has a stock quotation system that runs on somebody else's machine. The only way for it to work is to drop a T I into the computer room that goes to the off-site machine. But meanwhile, on the other side of the off-site machine there's a TI going to the brokerage's main competitor. And everybody knows this.

Maybe the whole of Wall Street is linked into that one machine-well, whoever breaks that machine owns the 'Street.'You have to say, "It's a policy decision. We need this service. We can't shut it down. We need to secure it. So let's review what we need to put in place on this service."

I know of a pharmaceuticals company that discovered one of the scientists in its lab had an Internet connection. He just bought it and installed it himself, because he wanted to run some kind of tracing on a Cray at the Supercomputer Center. They said, "You gotta shut that down!" But the scientist responded, "Wait. You don't understand. I'm a Noble Laureate and I'll be working for your competition within 48 hours if you take this away." Now there's a case for instant policy review. Will it hurt you more to risk someone breaking into this guy's box over the Net or is it going to hurt you more to have one of your prize researchers go to your competition? That's a no-brainer. They wound up saying, "Okay, fine. We surrender, Doctor. Your machine is going to be on both networks, but we're going to have to concern ourselves with the security on your machine."They do a sweep of that machine every week. They set up the software a little more carefully on that machine than they would on an average workstation. And everybody is happy. That's a case in which there is a business need for a specific service. Provide that service, identify it as a risky service and put some extra security around it.

Here's a simple real-world analogy. We all accept the fact that it's dangerous to hurtle down the freeway at 80 miles an hour. But we got to get to work somehow. So we do this crazy thing, but we wear seat-belts. That's about the best we can do. Other people who are more cautious also have their cars fitted with air-bags. Someone who is really cautious could wear a four-point harness and a helmet.

The whole trick is how do you balance your business requirements against your security needs? But the problem often is that this dialogue never takes place. The engineers just drop the TI link in, hide it as a line item and they've got an Internet connection and the boss finds out about it years later when something bad happens.

Now let's backtrack to the people other than service software-those who just want to surf the Net, send and receive e-mail. What are their options?

That's a case in which firewalls certainly can help. Most firewalls provide some variation of those capabilities with a reasonable degree of security. But you still have to ask the question, "What are you risking?"

I used to work at a medical center that had a LAN covering six city blocks; it was one big, bridged network. We were broadcasting confidential patient information on that network all the time. If someone had dropped an Internet connection into that environment, they would have been doing the medical center a legal disservice, because they'd be putting it at tremendous risk. If, however, you have a big mainframe crouching down in the basement and that's the only place with critical, confidential information and the rest of the medical center's system is desktops with Word Perfect, you may not need a firewall. If the data is all that needs to be protected, just protect the data and don't worry too much about the whole network.

So the first step is to take a look at your enterprise, identify the possible risks of Internet access, then examine the needfor Internet access and make some policy decisions based on the trade-offs between those risks and needs?

Right. When a customer comes to me and says, "We want to connect to the Internet." I say, "Great, so does everyone else. What have you got to lose?" And then, "What do you want to do with it?"The order of those two questions is really important. The first one leads to the second one. What usually happens is: "We want it, now what do we have to do to secure it?" But the correct order is: "What have we got to worry about?" followed by "What does the implementation have to provide to give us a degree of assurance that security is adequate?" This is a really important distinction. It's the dialogue that usually doesn't happen.

Don't do things in the wrong order. The right order is to go to upper management and say, "We'd like an Internet connection, can you please tell us what kind of assurances you need to know that we're going to meet the business security needs of the organization." Then, whoever owns data security for the organization is going to have to say, "These are the things we're afraid of. And we need to get assurances from you that your implementation is going to prevent those things from happening." If you engage in that dialogue, you're not going to have as many problems.

Unfortunately, what usually happens is someone says, "We want an Internet connection." Then someone else says, "You need a firewall."And that's as far as the dialogue goes. What happens then-and this is really important-is that the guys in engineering go out and pick whatever firewall that lets them do the stuff they want and damn what the organization needs! That's why so many people out there are connected up with just a dumb old router. They say, "Oh, we need a firewall? Okay, I'll get a firewall. I'm going to take a box, wave a dead chicken over it and we'll have a firewall."

Do you suggest bringing in an outsider, a third-party consultant to run the firewall drill with?

Well, I have to be a little careful in answering that question, because I'm one of those third-parties. In general, it doesn't hurt to bring somebody in. But I don't believe it's necessary. If that dialogue is carried on clearly enough and the goals are straight forward, it's not going to be that hard to implement.

Then how do you evaluate which product best suits your proposed implementation?

That's a tricky one. If you carry on the dialogue, you're going to come away from it with a list of the sort of things you need the firewall to do. And then you have to go around and ask the vendors, "Does your firewall do this? Does your firewall do that?" And then depending on how badly a security incident could hurt you, the next question is: "How much assurance do you need that the firewall does what it claims it does?"

Let's say you have your dialogue with upper management and they want you to convince them that the firewall will never let any data leak out. And then you go to a firewall vcndor and ask, "Does your firewall do that?" Maybe they'll say, "Sure, no problem." And you follow-up with "It lets you do anything you want with absolute security." "Oh, yeah. No problem."Well, the next question you have to ask is: "How can you convince me that your product does that?" Unfortunately, this is a question you have to ask a lot in the computer industry. Because there are a lot of products that just flat-out don't live up to their claims. With security products in particular, that's a serious problem.

You do need to educate yourself, which is another really important issue. You have to learn what the options are and what the terms are.

That sounds like an intermin step between the primary one of evaluating your risks and needs and the subsequent one of choosing the best product for you? So how would suggest someone go about educating themselves?

Well, read some books. Firewalls and the Internet by Cheswick and Bellovin is a goodplace to start. Maybe bring in the third-party. Right now, everybody in the world is a firewalls expert. Any conference you go to is going to have a talk on firewalls. Some of these guys actually know what they're talking about and some of them don't. But if you listen to enough people and you read all you can, you're going to start getting a picture of what your options are. This responsibility falls on the shoulders of a whoever is going to deploy the firewall. Of course, if that person is dishonest then management has a problem. If all that guy wants is something to cover his butt, that's what he's going to put in and management is not going to know until it's too late. Somebody has to honestly tell management these are the things that could happen and that you will want us to guard against. At that point, management can say "Oh, that's really bad." Or, "Oh, we don't care about that."And, of course, the real bad news comes if the lawyers get involved in the process. They're going to say "Don't do it. Don't do it." Because it's always easier to say "no,î than to say "yes."

Well, since everybody's an expert on how to build firewahs these days, what about some suggestions on how NOT to build a firewall?

Yes, that's a great idea.

Here's a few nots. Of course, they're all inverted, because I'm being sarcastic.

Don't use tools that you know.

If you're a UNIX shop, use a router to build your firewall.

If you don't understand networking at all, you're completely safe.

These are very real issues. For example, used to be that the correct answer to any on one side, I've seen people with a giant question is: "What are you trying to do?" DECnet shop who said they had a firewall. Somebody says, "I need a blah-blah-blah." "Well, it's a VMS machine that's running And you say, "What are you trying to do?" TCP/IP and its running DECnet on one And he answers, "I'm trying to do ABC." side. We must be safe, because you can't Then, you say "Well, you actually don't need break in over DECnet, right?"Yeah, right. a blah-blah-blah, you need an XYZ." But on the flipside, there are people who say. "I've been told by management to build a firewall. I know nothing about UNIX but I'm going to grab the TIS Firewalls Toolkit and install it and then we'll have a firewall." And that scares me. It should scare his boss too.

So ifyou're basically maintaining a network that you don't really understand, you can't begin to secure it in terms of Internet access?

It's the same as doing anything in real life that's dangerous or life-threatening. If you don't understand what you're doing, you're going to hurt yourself. If you don't know how to drive on snow and ice, you could kill yourself the first time you go around a curve. You have to understand what you're doing, or you're going to run into trouble. And that's one of the things that really concerns me.

Of course, the Internet is the hot place to be. There are people saying, "We need a World-Wide Web server, so we need an Internet connection. Well, if all you need is a Web server, you don't really need an Internet connection to your private network. You can just stick it out there by itself. The joke among hardcore programmers used to be that the correct answer to any question is: "What are you trying to do?" Somebody says, "I need blah-blah-blah.î And you say, "What are you trying to do?" And he answers, "I"m trying to do ABC." Then, you say, ìWell, you actually don"t need a blah-blah-blah, you need an XYZ."

Okay. Let's talk about this guy who thinks a firewall. he needs a Web server. Can you give us an example of some of the issues involved?

Let's say you want to put a Web server up for your organization, so that people can sign up over the Internet and they can pull down publications from you.

One option is just to find someone who's got a Web server already out there and get a Domain Name Server (DNS) record that claims that WWWyou.org is on that machine and just put it on the Web server. Then, you're not connected to the Internet at all, but people can pull all your stuff down. Now, of course, that's sort of a halfassed measure because many people are also going to want to send and receive e-mail.

The other option is maybe you do want to put in a firewall. But you don't have to jump right into putti ng in a firewall. You can get an account with someone else and have three or four of your guys monitor that account to get a feel for what's going on before you dive in.

I've been to customers where the vice-president says "We want to be on the Internet tomorrow. Go buy us some security." It's great for our business, but it's kind of unfortunate. There's this notion that someone's going to get a big grey box with "Security"written on it in red letters, plop into the network and everything's going to be okay.

We've been talking aboutfolks who have the luxury of dealing with some of the problems upfront, but what about folks that find themselves in a corporatio where there already is an Internet connection and there are assets at risk?

Ah, that person truly knows pain. They soon find themselves in the wonderful arena of techno-politics, which brings me to few more items on our inverted checklist.

Security is a democratic process.

When everybody agrees that they're secure, they're secure.

If you have a large network and a diverse user community with wildly different security needs, make a political decision, not a technical one.

This happens all the time. Something we see a lot on the "Firewalls" mailing list is: "I'd love to put some security in, but my users would lynch me." The answer is: "Wait a minute. Your management should decide whether or not you put security in. Then, anyone not putting it in will get lynched."

For us, the easy sells and easy installs are the ones that currently don't have Internet access. We go in there and provide them with e-mail, Web, FTP, Usenet news, all that stuff-and they're thrilled. The hard sell is a customer that has already had Internet access for the last six years, they've suddenly shown up on 60 Minutes as having been hacked up real badly. They're sick of it and want some security put in. I've to a customer's site and the first thing out of his mouth was, "We don't really want this thing, but..." The gist of their comments is "Can't you sort of install the firewall so that it doesn't do anything?"

Alright, given this already existing Internet connection (they"re sending and receiving e-mail, etc.), what would the impact on the user be if you put a firewall in?

If they're just sending and receiving e-mail, it's not going to do much. You can bounce that stuff through firewalls or dial-up or whatever. That's completely invisible.

But let's say an academic or scientific organization has guys kicking funds into the organization through their grants. They need to get into resources inside from outside. Putting a firewall in is going to send these guys non-linear. Of course, these guys are also going to go non-linear if somebody breaks in and pre-publishes their research. But they don't want anything to prevent them from getting into the network effortlessly. I've talked to folks that run systems in astronomy labs. When Dr. Kabooznik comes in, somebody just creates him an account. That's the level of security. Anything more than that is an imposition, which brings me to another point-part of setting up a security system is accepting the fact that you may have to change the way you do business! And this isn't a bad thing. Sometimes the way you're doing business is the reason you need to put a security system in the first place.

I've run into many cases where a customer says, "We need a firewall that will allow us to run this through it."And I ask, "Why? That's a huge hole?" The answer that comes back is: "We'd have to change if we stopped doing that."

Then I say, "Well, maybe this is an opportunity to reassess just why you're doing it that way in the first place." Hopefully, they reply, "Oh. I guess we could do that."

It might cost you $200 to change the way you do business, but $6,000 to hire us to modify the firewall so you can keep doing it the old way.

A perfect example is a company that wants to put in a firewall, but they can't because they have a gigabyte network and people pull down astronomy data. They want security, but there's no firewall in the world that can handle gigabyte throughput. I suggested they put a copy of their astronomy data on a public machine outside. Once a day, they can copy it to that outside machine through the firewall. All that traffic for getting that gigabyte's worth of stuff many times a day won't be going over their local network anymore. If they do that they not only can install the firewall, they've optimized their network for the cost of a couple of hard disks, a machine and some extra stuff. They also wouldn't need a high-end firewall at that point, they would need only a mid-range firewall and it's going to be a lot faster because they're not pumping the same 100MB file through it 70 times a day. They're just pumping it through once a day at three o'clock in the morning. Of course, it usually turns into a political battle, because the guys who are doing it one way now don't want to change no matter what.

You mentioned 'high-range' and 'midrange.'I assume there's also a 'low-range.' How would delineate them?

I was speaking in terms of performance issues. A real question a lot of people ask is, "If I put in a firewall, is it going to slow me down?"Well, if you've got a security hole, do you want it to be a really fast one or a really slow one? Most people don't have big fat pipes to the network, so the machine doesn't need to be too powerful. We have a 386 box here that we use as a router and its got a T I board in it and it doesn't even use half its processing power. So a 486 or a Pentium is going to be able to handle a T I pretty easily. Of course, there are people out there who will sell you firewalls built on 250 Mhz systems built on RISC chips. It just depends on how much processing you want to do. Other people say you need fault-tolerant machines. You have two or three machines so that if one dies another takes over. That's all perfectly reasonable. These implementation details fall out of having a feeling for what you're doing. You can't really judge that stuff if you don't really know what you're doing. And many people don't.

Anything else on your list of Don'ts that we didn't get to?

Yeah. Here's another important item on the "How NOT to build a firewall" checklist.

Don't know who you connect to and who they connect to.

I've seen many cases where one organization has a backdoor connection to a business partner with a wide-open connection to the Internet. I see this all the time and it's a really nasty problem. I've gone up to Wall Street and given talks on firewalls and said, "One of the things you've got to remember is that many break-ins occur because someone you know has a wide-open hole and thus there's a wide-open backdoor into your network."Those holes often exist because people refuse to change business habits. They say, "We own this division of Mumble Co. and we've always had a wide-open network connection going to Mumble Co. so we can't put a firewall in. And now Mumble Co.'s got its own Internet connection and what are we going o do?"

Often, the reason they have this wide-open connection is to run e-mail through or some other single, simple service that could either run through a firewall or even over the Internet. It's not that hard to run it through some other non-trusted network.

Maybe since we're doing everything backwards and we're at the end of our discussion, we should define what a firewall is?

The definition of a firewall I give these days is pretty vague. Basically, a firewall is the system that enforces access between a network you trust and a network you don't to trust. The system may not be a box, it maybe be a pile of boxes, it could be some software running on a single box-a firewall is whatever does that. A firewall is designed to accomplish a clear goal. A pseudo-firewall is one that's designed to cover your butt in case something goes wrong.

Another way I answer the "What is a firewall?" question is: "A firewall is the implementation of your Internet security policy." If you ain't got a security policy, you ain't just got a firewall! Instead, you've got a thing that's sort of doing something, but you don't know what it's trying to do because no on has told you what it should do.

Let me ask youfor a couple more definitions. Screening router?

As we said, a firewall is an implementation of security policy. It's a system that does something. Now for some of the ways you can build it. Just about every commercial router in the world now has the ability to put some network-level screening in it. You say, "Allow traffic between here and there. Don't allow traffic between there and there."There are two ways you can set up a router. The first paradigm is "That which is not expressly permitted is prohibited."The second paradigm is "That which is not expressly prohibited is permitted." Some people turn off all the services that they think are dangerous, other people turn on all the services that they think they can do safely. The issue is that it's at the network level and so, it can't be particularly smart about what's going through it. It still relies to a great degree on the security of the end-host. Let's pretend you have a screening router. Your company only wants to do e-mail. So you have a screening router and you only allow e-mail in and you only allow it in to one machine. Now let's say that one machine is running a version of sendmail with a security hole in it-oops, you're dead! But suppose you want to carry this further and make sure you I ve got a secure firewall. You only run e-mail through to one point and you run a version of sendmail that's been swept really carefully and you run it so it's carefully configured. You can be pretty confident you've done things right. That's basic screening router stuff. The problem with a screening router is it does rely on software running on end-point nodes as well as the router itself. The router itself can't protect you, it can just sort of protect you.

Dual-homed gateway?

Dual-homed gateway: You take a box running UNIX or VMS and you put one network interface on the inside and one network interface on the outside. And then you disable the ability for traffic to flow between the two. That's the way the original firewalls were built. They weren't really firewalls. They were just big boxes. Everybody logs into one side and logs out on the other. That's a really good way to build a firewall. Because you I ve got this degree of assurance. You can say, "I can assure you that nothing is going through the network that doesn't go through some software running on this box. And I can show you how I can secure each one of those pieces of software. There are only six programs running on the box and here's how we've secured each one of them." Beyond that, there are various combinations of those two approaches and that's about it.

Applications gateway?

With a dual-homed gateway, you've got this box and its two network interfaces. In the old days, everybody was logging into that machine and logging out the other side. But people would sniff the passwords on either side, break into the machine and then, boom, they would break into the network. I actually invented this stuff when I was back with DEC. I wrote a small shim program called a "proxy" that talks to both sides. Instead of logging into the firewall machine, you connect to this process that connects to machines on the other side on your behalf. It looks like a terminal server, basically. You telnet to the firewall and the firewall says, "Who would you like to connect to?" and it connects you out through the other side. Once that connection is made it starts copying data back and forth for you. What's nice about it is that the program running on the firewall is a very small program. Maybe 2,000 lines of code. And it can run in a restricted environment. You don't have users logging into the firewall.

The firewall becomes a black box that only supports these service processes that you've configured to support a particular service. That's how we do our firewalls. We have services for FTP, telnet, rlogin, http, etc. and for each of the services we can exhaustively detail how we've secured the implementation for that one service. That's an application gateway, other people call it a proxy gateway.

Marcus Ranum is President and CEO of Network Flight Recorder, Inc., a security startup which he founded early in 1997. As Chief Scientist for V-One Corporation, Ranum worked as an executive manager for a high-tech security product startup, with duties including strategic market analysis, technology evolution, software engineering process management, reseller and business partner relationships, and corporate positioning.
At Trusted Information Systems, Inc., as senior scientist and development manager for Internet security products, Marcus designed and implemented the TIS Internet Firewall Toolkit under a grant from ARPA on behalf of the Executive Office of The President of the United States, and configured and managed whitehouse.gov for its first year of operation. Marcus architected and managed the implementation of the TIS Gauntlet Internet Firewall product, and acted as a senior consultant and trainer for managing reseller relationships and training reseller marketing and technical staff.