Pokin' holes in the firewall

How can I configure the firewall to let users access AOL?

This is a pretty common question on the Firewalls mailing list, comp.security.firewalls and similar places these days. It's also unfortunate, because it's a pretty good example of exactly the wrong mindset for running a firewall.

A better question

A more important question is whether you should allow such connectivity. (That is, after all, why you installed a firewall in the first place: to control the sort of connectivity your organization has with the outside world, isn't it?) What you are doing is allowing a direct connection between a proprietary client -- whose source you presumably can't see and whose protocol is largely a secret -- and someone else's server. Do you know that the client software won't accept commands from the server? Do you know that the client won't take information about its environment, the network, etc., and send that up to the server? Are you willing to be at the mercy of the service's technical or support group(s) in the event of some sort of security bug being discovered?

How does providing such a connection fit in with your security policy? (Remember that? It's what you wrote before you implemented a firewall solution, so you could articulate your organization's acceptable level of risk.) If you don't have a security policy, stop now. Go write one, and come back then. Really. Bookmark this page, go write your policy, and come back in a few weeks, when you've got it done. I'll wait.

OK, so you're back, and your security policy says that it's OK for you to make nearly unauditable connections between your networks and untrusted ones. Despite the fact that such a policy completely undermines the entire purpose for having a firewall in the first place, let's just consider the following scenario a moment. After it's finished, consider again whether this is an acceptable level of risk.

My experience

I've posted a few times on the firewalls mailing list about my experiences in evaluating whether we should do this for AOL and Compuserve. I was unable to even get response from AOL about the technical details of their client (so, why, would I want to rely on these folks to respond to security problems?) An admin for another group used to work for Compuserve, and knew some of the folks that worked on their client. Rumor had it that a "feature" was incorporated into the client without the knowledge of their management where the server and client could switch roles. I asked about this, and they would neither confirm nor deny that feature's existence.

More rumors here ... I don't remember the details, or if anything was found to be behind this, but didn't the MSN client send information about what is installed on the user's hard drive up to the MSN server?

Whether that was malicious, intentionally Orwellian, or simply the result of poor coding, it is threatening to the security of your internal network, and can even serve to undermine the effectiveness of your firewall.

When you're dealing with black boxes (that is, software whose implementors neither offer a good technical description of what's going on under the hood nor offer you the opportunity to see the source, and build your own clients), you simply can't be sure what threat you're exposing yourself to. Not a terribly comforting feeling, if you ask me.

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

C Matthew Curtin
Last modified: Mon Dec 8 22:48:55 EST 1997