Firewalls: building safe off-ramps on the Info Highway

In the last year, only creatures on Mars have escaped the deluge of articles about the 21st century's "new frontier."

I'm referring, of course, to the Internet -- the I-way, Infobahn, Information Superhighway, the 'Net ... well, you get the idea.

So, you're probably thinking: "Gee, just what I don't want to read -- another article extolling the virtues of cyberspace."

Good news. This article is not laden with factoids about "how to get connected" or "where to find the greatest sites." There are enough of those pieces out there already.

Instead, I'd like to explain how I addressed a crucial but transparent Internet issue -- security. (Perhaps you'll pick up some useful ideas, or at least obtain a cheap laugh.)

As a systems person, paranoia about the outside world runs deep. All it takes is one bozo with too much time on his or her hands, and a desire to do evil, to cause havoc to your systems.

No Internet connection is valuable enough to ignore systems security. Even if 99 and 44/100 percent of the Internet population is honest, there are still the few (and I know some of them personally) who are immoral enough to do something bad -- and others who may do damage unintentionally if you don't guard against them.

The good news is that you can minimize the risks if you plan ahead, and realize that there might have to be some compromises made to keep things secure. And now there are some excellent turnkey security systems that are easy to install and maintain.

All this means that you can get good security with less hassle than I did by rolling my own. The system we concocted does work -- we know, because we've had hack attempts, both friendly (security consultants) and otherwise.

And no one has breached our wall.

I've been working on, with or around the Internet since I began college 10 years ago.

In that time, I've played various roles, not necessarily in this order, of quasi-hacker, systems administrator, network designer, systems analyst and network security supervisor.

I've seen the Internet grow from a loose collection of schools and government institutions to the commercial behemoth it is today. Along the way, I've seen the positive and negative aspects of having a global computer network.

I've also seen the good and bad sides of the people using it, and thus the very real need for first rate security at every site that cares about its integrity.

Since spring '93, I've been hanging my hat at TV Data, the largest producer of television listings and entertainment information there is.

When I arrived at TVD's offices in Queensbury, N.Y., I was surprised to find it was not connected to the Internet. I guess I had figured that any company as technically competent as TVD would've hooked in at the first chance.

As luck would have it, I happened to land in the right place at the right time. Unbeknownst to either me or my co-workers, TVD was on the brink of a change in management that would lead us all into waters never before charted.

When the officer at the helm changed, I was there, patiently waving my proposal to connect to the Internet. Of course, even forward-thinking management wants justification before spending money, and I was forced to rely on what few straws of fiscal justification I could harvest.

I argued, "We have international clients with bad phone lines who would love the ease of the Internet."

And, "We could get rid of some of our dedicated connections and have people telnet in from a local dial-up."

With the noteworthy help of some fellow employees, I was given the go-ahead to evaluate suppliers and solutions. After much soul-searching, agonizing, self-examination -- not to mention a raft of faxes -- I finally settled on a large, international provider and a 56K frame-relay connection.

Since the provider would take care of most of the connectivity details, I was free to turn my attention elsewhere.

"Elsewhere" turned out to be security, the one topic that always looms over your head when your company's prime resources are data. TV Data has the largest database dedicated to television program information, air times and cable systems in the world, spanning four different computer systems, primarily on DEC Alphas running OpenVMS.

While it would be pretty difficult to extract over the 'Net the massive amount of data we have, it would be far less difficult -- if we just hooked our network to the Internet directly -- to cause us grief by crashing one of our large production systems, intentionally or not.

With my paranoia glasses affixed to my face, I turned the page to the one issue that took the most time and effort to resolve: how to give TV Data the Internet connectivity we needed without risking our information systems in any way, shape or form.

The concept that seemed ideal was to install a firewall, a configuration of hardware and software that would monitor and control all traffic between two networks.

With a proper firewall, only those data we wanted to allow in would be permitted to cross from one network (the 'Net) to another (inside TV Data) through our site on the World-Wide Web -- http://www.tvdata.com/. With this in mind, I designed a system around a Sun SPARCstation 5 with dual Ethernet interfaces.

This design lasted only a month or so, until I went to the UNIX expo, held every fall in New York City. There I saw a device to make a paranoiac's heart go flitter-flutter: a Livingston Firewall Router, made by Livingston Enterprises of Pleasanton, Calif.

Think of a router as a network traffic cop. It has two or more network interfaces, and sends traffic to the appropriate interface. In many cases, routers also are used to convert data crossing from one type of interface to another.

The Livingston router caught my attention because it offered a trio of network interfaces: one to connect to the internal, secure network; one to link to an external, unsecured network, and one to hook up to our dedicated line to the local Internet provider.

It also possessed the ability to filter (allow/deny) traffic between any of the interfaces -- truly a good weapon in the fight against forces arrayed on the dark side of the 'Net.

As it turned out, I needed one more item to make the secure firewall concept fly. Out came the purchase orders again (it sure helps to have an understanding CIO), this time for a small Sun SPARCstation 1+ to act as a bastion host.

In our model, the bastion host sits on the unsecured network and performs a number of important duties as part of an elaborate three-part masquerade.

First, it acts as a proxy, so any outgoing traffic from TVD's secure network shows up as coming from that system, even though it's not.

Second, it serves as a terminus for all tvdata.com services: e-mail, FTP and telnet.

Third, it feeds our Domain Name Service (DNS) information to the world, and supplies the internal network with answers to DNS requests.

This seems like a lot to ask of just one small workstation, but the combination of stripping down the operating system to remove unnecessary (or unsecure) components, as well as relying on a system inside the firewall to handle the decision-making -- which saves CPU cycles and enhances security -- leaves this machine with horsepower to spare.

For example, it doesn't handle e-mail directly -- it knows just enough to receive a message, check for hack attempts, and then push it on through to a UNIX system inside the firewall that routes the mail to the appropriate system, be it VMS or UNIX.

Our internal network supports a wide variety of hosts, the details of which I prefer not to explain in a public forum. (While the firewall protects us from unwarranted access, it's still good policy to avoid publishing details about your critical systems.)

Suffice it to say, we support a variety of systems, including VMS, UNIX, Macintosh, Windows, OS/400 and RSX-11M Plus. We also support a wide range of network protocols like Decnet, TCP/IP, IPX/SPX and AppleTalk, all over a combination of 100 megabit fiber and 10 megabit Ethernet.

Since we have little need for people telnetting in to our systems, we use a one-time password approach -- if a remote user's password is compromised, it is useless for the next session.

This leads me to the most important lesson I've learned about maintaining a secure environment: If you don't need it, don't allow it. With the exception of FTP, telnet and e-mail (Smtp), all traffic is blocked by our router.

Not even ping (echo requests) gets through, which caused some panic on the part of our provider when its ping-based mechanism for determining if we were up announced that we were down when we weren't. Unaware that the provider was using that as a verification mechanism (not that it would've changed the outcome), I had turned ping off using the filters.

With ping off, our Internet provider had to develop a whole new method of verification. Our provider checks the connection between the serial ports on our respective routers every five minutes. Granted, this only proves that the physical connection exists. (In fact, our provider would be happier if we turned ping back on, but between its vigilance and ours, we are aware of any difficulties within five minutes or less.)

My plan was moving along fine until about a week before we were scheduled to receive our connection.

In a call to the provider, I discovered that work on our setup had not been started, and that it would probably be another couple of months before a link would be in place.

This really put a crimp in my plans, since I had (of course) promised that we would have at least e-mail capability by Christmas 1994. Things looked pretty glum.

Salvation came about in the form of free enterprise. A local company, LogicalNET of Albany, N.Y., had approached me while we were still under contract with the national provider, and had asked for our business. At the time, I said no, but when the national provider fell short, we ended up getting a true 56K line for half the price of the original provider's frame-relay 56K.

I was promised access within a month, and I got it.

On start-up day, there was a brief panic when our respective service units at both ends of the phone line refused to talk to each other, but magically they started working after a call to the phone company.

Our on-ramp to the Infobahn was open, but shortly I discovered that pushing and pulling e-mail through a firewall is far more difficult than doing it without one. Some timely help from the folks at Livingston, as well as a consultant from Kaman Sciences, a multiplatform hardware/software VAR in Utica, N.Y., allowed me to keep my e-mail deadline by showing me how to configure sendmail (the UNIX mailer program) to move messages through the firewall without turning them into electronic spaghetti.

After that, implementing secure telnet and FTP got easier. The excellent wu-ftpd FTP daemon allows us to log all transfers, as well as maintain separate staff, client and anonymous FTP areas.

In deciding who would use our 'Net access, I resorted to the system manager's most useful tool: be arbitrary. I decided not to give inside users access to the World-Wide Web through our firewall, because proxy-based HyperText Transfer Protocol (Http) was at the time still not secure. I also decided that the bandwidth of our 56K line would be put to better use by our clients.

Thus, we contracted for low-cost dial-up accounts with a local provider, giving those TV Data staffers who needed to surf a secure means of doing so, while preserving our bandwidth for the paying customers.

TVD has become a full-fledged part of the Internet community. Staffers now use e-mail to communicate with clients, and more and more clients are turning to FTP as an easier way to pick up their listings.

We're already planning to upgrade the 56K line to a T1, and the bastion host/FTP server is being upgraded to handle future loads.

We also have redundant hardware in place; when the bastion host failed recently, we moved its disk to another system and fired it right up with minimal down time.

Additionally, newer and better Http proxy software, combined with the T1, will allow our internal users to browse the Web directly, without using a dial-up site. (Our WWW servers, however, will stay off-site for now. We keep them at the provider's site to allow for easy increases in bandwidth as necessary.)

For anyone into communications, the Internet is a gold mine. It's helped break down the barrier of physical location -- someone in Lima, Peru, can access information in the same manner as someone in Lima, Ohio.

And it is amazing how fast people have warmed up to the Internet, as shown by our site on the 'Net. At this point, we receive dozens of e-mail replies to the form on our Web site every week.

The good news is, as I found, that there are ways to start out small and scale your services as you need them.

By handling TVD's implementation in small bites, we were able to keep ourselves, and our users, on top of the emerging technology -- not buried under it.

-- Pete Wargo

Recommended reading: Firewalls and Internet Security by William R. Cheswick and Steven M. Bellovin of AT&T Bell Laboratories (ISBN 0-201-63357-4). This excellent book belongs on the desk of anyone concerned with or responsible for network security.

Livingston Enterprises,
(510) 426-0770

From THE COLE PAPERS, February 1996, Copyright © 1996, All Rights Reserved.