Welcome to the inaugural issue of The Internet Security Conference Newsletter. I decided (not reluctantly) to become a newsletter editor for several reasons:
About every 2 weeks, we'll present you with an original column from an expert affiliated with TISC. The editorial calendar at this time includes columns and contributions from:
TISC is about sharing clue. I promise you we will do our best to provide something *useful* each issue. If I don't, you know how to reach me. We'll also provide news tidbits about the program, exhibits, and demonstrations we plan to present in April at TISC.
'Nuf said. Now for our first "editorial" column. Marcus Ranum, currently CEO of Network Flight Recorder, is generally recognized as one of the most influential figures in the development of firewalls as we know them today. In his column, Marcus discusses the unnerving matter of obsolescence and firewalls.
Happy reading and warm regards,
Dave Piscitello
Now that almost everyone has a firewall:
First, let me confess; I am a recovering firewall-maker. I still think they are a useful technology, but I am concerned that, in the long term, technological change is going to render them obsolete. Obsolescence is not a new thing in this industry but I'm afraid that it could hit firewalls very fast and very hard and we won't be prepared with a viable alternative. That worries me.
How could it happen? The first generation of firewalls were very simple systems that only had to gateway a handful of services. The current generation of firewalls are extremely complex systems that gateway a bewildering array of application services, most of which rely on undocumented, vendor-proprietary protocols. But the biggest difference between the first generation firewalls and the current generation is in how they are deployed. The first generation systems supported simple protocols, and sophisticated users - users who were willing to authenticate outgoing FTP requests on a case-by-case basis. Most firewalls today try to be as "transparent" as possible; in other words they don't interfere at all with outgoing connections. This is because Web applications open loads of little connections at the click of a single button. We can't reasonably expect a user to enter a username/password each time they get a banner ad on their screen. As a result, firewalls have become extremely permeable to outgoing traffic. I call this "the outgoing traffic problem." It's exacerbated by the large number of applications that know how to "tunnel" their traffic over an HTTP connection, effectively bypassing the firewall.
It's not really a problem yet, but it can quickly become one. So far we've been spared. But what happens the first time some enterprising hacker melds an E-mail or macro virus like "Melissa" with some gatewaying software that knows how to punch its way out through a firewall via HTTP? Imagine if you had a user someplace in your network who clicked on an executable file or opened an Ms-Word document that had such a "firewall buster" built into it. Silently, it infects a few other files, then opens an HTTP connection to a random site and a special URL from a list of sites that are compromised by the hacker. Perhaps the hacker has already compromised the web server and is monitoring the logs to see what sites query for the URL. They then quietly make a list of all the sites they own connections to. The firewall buster wakes up every few hours and probes again for the special URLs (perhaps rotating its list to avoid showing in firewall logs) and when it gets data back, parses it looking for its victim's address and a destination IP address. If it sees its address, it opens an outgoing connection over HTTP to the destination, and invokes a command shell, allowing the hacker full access to whatever is behind the firewall. Coding a firewall buster is not a great deal of effort. Fortunately, we haven't seen them in use yet.
What can we do about it? That's the bad news. I don't know of a way toprevent this kind of attack except to require that all outgoing connections through the firewall be attached to a human being. That means authentication, and annoyance for the user. Perhaps virus scanner software would detect such a thing; it certainly could be made to, but, like with many macro viruses, it would mutate quickly. Intrusion detection systems could detect the signature patterns of the traffic on the control connection, and could record the destination(s) of the firewall buster. But by then it would be too late.
Normally I hate raising a problem that I don't have a solution for, but I'd like to encourage people to start thinking about what they'd do if such an attack tool became widely released. How will you adapt your firewall and your business to address the outgoing traffic problem? This problem genuinely scares me, and I think that the only answer is to begin fortifying hosts, rather than relying on boundary firewalls. That's a big reversal for me; it goes contrary to 5 years of professional work as a firewall builder. Let's hope it doesn't happen.