Which OS should I use?

This topic has been beaten to death on firewalls, comp.security.firewalls, and everywhere else. Here's my take on the argument.

Considerations

Regardless of which approach you take, you're going to have advantages and disadvantages, as compared to the other approaches. You need to find the one that best meets your organization's needs. There are a number of considerations in deciding on a firewall architecture, including the OS(es) that you run on host(s) within your DMZ. Security, stability, managability, and openness are particularly important to me. Different folks might have things to add to or take away from that list, depending on their needs, expertise, and faith in their vendors.

Security

Defining this is difficult, at best, since "security" means something different to everyone. What it means to me: I can turn anything I want on or off, and replace any part that I want. It has to have been around a while, already become the target of bad-guy attacks, and been able to fare reasonably well against them.

Despite what Microsoft's spin-doctors say and what the Microsoft-worshiping trade rags like to print, NT is a very young OS. (Regardless of the version numbers that Microsoft slaps on it, there have only been two major releases of the OS.) It is only now, as we enter the second quarter of 1997, becoming interesting to attackers. And the number of security problems with NT published since the release of 4.0 has been continuously increasing. This will only continue as more bad guys look at it as an attractive target. So far, Microsoft has done a good job of releasing patches for these problems, but there are still a huge number of sites that don't even know about these problems, much less understand how they're vulnerable to them.

Stability

I'm not into booting machines as any part of hourly, daily, weekly, or even monthly ritual. If there are memory leaks bad enough that the machine will crash after 38 days of uptime, I'm not going to use it. Misbehaving applications shouldn't be able to bring the whole system down. People shouldn't be able to telnet to some service port, type some stuff, disconnect, and have the system CPU utilization go through the roof because of it. The system must simply work, without any coaxing from me. I don't want to have to put a new patch on every day, and I'm not about to get into a mode where I have to babysit it in production mode.

Scalability

A picture is worth a thousand words.

Managability

Obviously, it's not a good idea for the system to be so unwieldy that an admin-type needs to meditate before using it. What "managability" means to different folks will depend on their background, experience, and competence. Remote access is something that's important to me: I don't want to have to go to the console to navigate some retarded GUI. I don't want to have to use a proprietary admin station. And I don't want a system that will let me telnet to it from the outside world in the clear. I want simple, direct, strong encrypted access. Get the blasted menus, GUIs, and all that the heck out of my way.

Every organization and every administrator is going to have a different idea of what "managability" means. Before spending any money, the organization needs to make the decision about what it means to them, based on the background of their own people who have to run the darn thing.

Of course, the nice thing about Unix is that GUIs do come with the systems, and others are available, so you can use a GUI that you like more than the others, or none at all. Those that are available are totally customizable, so you can make everything work in a way that's most efficient for you.

Another part of this is babysitting, which is something I don't want to do. I have software watch the system for me, and do all of the system operator type things. (Make sure we're not going to run out of disk space, check the queues for backlogs, watch the load average, keep an eye on the logs, watch the process table for badness, and that sort of thing. If it can, fix it, if not, or if it thinks the system is under attack, panic -- which means email and page the admins.) Any system that isn't reasonably programmable, or doesn't have the raw materials or building blocks to not require me to spend days programming every tweak or addition I make, isn't going to cut it.

Openness

This is important to me for a number of reasons, security only being one of them. In an open system -- that is, one where you aren't dependent upon a single vendor, one that you can make changes and additions to yourself, etc. -- there isn't as much cause for concern about the possibility of being locked into a single vendor's solution. (I'm always skeptical that I might somehow be saddled with a product that represents the best interests of the vendor, and not me.) This is especially important in security applications, because I don't want to have to be dependent on the vendor to fix the problem. If they're dragging their feet, I want to go out and grab the source, a fix (or write one myself), and drop it in place... all in less time than it takes to get a CERT advisory approved and readied for distribution.

It's entirely possible that this isn't a concern in your organization. On the other hand, if you're not concerned about this, you're accepting what your vendor gives you, and trusting them to be looking out for your interests. Not a position that makes me real comfortable. Especially given that there are pages dedicated to things like known NT exploits.

Conclusions

Every organization needs to make its own decisions about what is important to it. Things like certifications, vendor promises (especially regarding "the next version"), market share, mind share, and so on, are completely irrelevant. This is a firewall, not a user's workstation. The requirements are different: presumably, you have a firewall to block access to the user workstations because there are things that are left to be desired in the security of your internal network if it's exposed to the outside world. So why would you protect your internal network with the very same stuff that you're trying to protect? If it can't withstand attack when it's on a user's desktop, what makes you think it'll be able to withstand attack because someone slaps a "firewall" label and a $5,000 price tag on it?

This is security. Trust no one, especially anyone who stands to profit (monetarily or otherwise) from a gullible or wrong move on your part.


interhack | cmcurtin | vitals | the soap box | publications | perl | hackcam | links

C Matthew Curtin
Last modified: Mon Dec 8 22:50:26 EST 1997