Network Applications: A Security Guy’s Wish
by Fred Avolio, Avolio Consulting
 

Imagine that I provide an office cleaning service. I have about a thousand cleaners working for me, and my people will clean your office virtually for free, if you’re willing to overlook a few of my practices:

I cannot tell you who will be showing up on any given night, nor am I sure of the time they will show up — just sometime during the night. Any night.

I cannot tell you what office they will service what night.

I do not issue photo identification cards, because my people are so transient.

You need to leave all the doors and windows unlocked, because my workers might want to get in by any of them.

Actually, this illustration is unfair. The situation is actually much worse than this, because when we’re talking Internet, we’re talking about thousands of doors and windows, and millions of possible entities coming through those doors.

If we want to run our networks more securely, we have to lock as many of those doors and windows as possible. That’s tough enough to do in any corporation. But the people who develop the applications that we all use make it even tougher. This article alerts you to the issues, and contains my plea to developers to give security a chance.

What Lies Beneath
As I wrote in my previous editorial, “ One Size Never Fits All,” “We tend to set our firewalls up with coarse rather than fine granularity. If three people need access to an Internet service, we give every employee access to it. We can do better. In fact, we must.” Even if you close every unnecessary port you can, having a suitable security policy with matching firewall configuration is only the beginning. As an Internet security practitioner, you are always one step behind the next new whiz bang Internet service. And it seems that every new service introduces vulnerabilities or potential avenues of attack.

Internet applications use connections and ports to facilitate communication. TCP services make connections with more reliability than UDP, mainly because TCP has a notion of a connection including a handshake and response, while UDP merrily blasts away without any guarantee that something on the other end is listening. TCP packets usually make use of specific well-known ports that are related to the particular Internet service. So, for example, if you want Internet mail to work, you have your e-mail server listen for connections on port 25, and a client only works if it connects to port 25 of the target system.

The problems start when an application protocol developer creates a new service for which there are no registered or well-known ports, or when that service needs to make connections back to many client processes. Developers like to use UDP packets for the same reasons that make them less reliable communicators: their communication is simpler than TCP’s, so they’re smaller. They are most useful for communications where speed is more important than loss of data (streaming audio or video come to mind). So a vendor might utilize random UDP ports to make connections.

From a security guy’s standpoint, using random ports for communication is a Very Bad Thing. Remember, every service we allow through the firewall is a potential avenue of attack. If we must allow services through our firewall in order to meet our business requirements, and those services require large ranges of ports to be open, our job is more complicated, and an attacker’s job is easier.

The Bad and the Ugly: NetMeeting
One of the worst examples of this I can find is Microsoft NetMeeting. Fellow LiveSecurity™ Advisory Council member David Piscitello and I decided we would set up NetMeeting between our offices, then write about how to do it without compromising the security of either of our networks. It would have been a very short column.

We struggled for awhile, unable to make our two NetMeeting processes fully connect. So, I ran tcpdump (a packet sniffer) on my network. I found that NetMeeting was using the following ports: 1151, 1152, 1503, 1695, 1696, 1697, 1698, 1699, 1700, 1720, 49606, 49607, 49608, and 49609. A few of these are registered and will not change. For example, 1503 is what NetMeeting uses for the T.120 service (a standard that provides support for real-time, multipoint data communication). And 1720 is for the H.323 (the standard for Internet telephony) call setup. Both use TCP. But the others are neither standard nor set. To get NetMeeting up, basically you need to open up all ports between 1024 and 65535. That’s a lot of open doors and windows!

Did NetMeeting have to be written this way? Couldn’t it have been more securable? To quote Dr. Brian Reid, a director at Bell Labs Silicon Valley, “Programmer convenience is the antithesis of security.”

The Good (or at least Better)
Real Media — RealAudio and RealVideo — was created with firewalls in mind. If you fire up RealPlayer and look at View/Preferences you’ll see controls for defining proxies (if you sit behind a Firebox, for example) as well as for specifying what transports to use. I picked “Use TCP to Connect to Server;” I specified UDP port 7070 as a static UDP port to use for receiving data, and that’s the only “window” I had to open for RealMedia.

This is the way an application should be written — allowing the service to work in conjunction with a security policy and firewall.

What I Wish For
We should ask product vendors and application developers to develop services for today’s Internet — that is to say, to develop services knowing that clients and servers will be separated by firewalls. We should remind them that every usability decision they make may have a negative impact on our security, and may result in an application we cannot use (or, more probably, we’ll have to use, making our network insecure). I want applications that use specific ports, or tell us as part of the protocol what extra ports to use. I want applications that may sacrifice performance for security, but never security for usability. I want application developers to talk to security people and have a security architecture for any network-based application, and I want it there before they loose their wonderful, marvelous, cannot-live-without application on users whose network I am supposed to secure. It’s a new millennium. Maybe if we all keep asking for these things, we’ll get them.

Epilogue: From Theory to Practice
With the subject of this month and last month’s columns in mind, I decided to follow my own advice and batten down my WatchGuard SOHO. I don’t allow any inbound connections (connections initiated on the outside), but I wanted to see what outbound connections we required. “We” is my business and my family, using the same connection to the Internet. What were we actually using?

I ran tcpdump, sorted through the output, and got these results:

Allowed Incoming Services–none installed

Block TCP requests to port 139 SMB Networking
Block UDP requests to port 137 SMB Networking
Block TCP requests to port 137 SMB Networking
Block UDP requests to port 138 SMB Networking
Block TCP port range from port 1 to port 12
Block TCP port range from port 14 to port 21
Block TCP port range from port 26 to port 52
Block TCP port range from port 54 to port 79
Block TCP port range from port 81 to port 109
Block TCP port range from port 111 to port 118
Block TCP port range from port 120 to port 442
Block TCP port range from port 444 to port 553
Block TCP port range from port 555 to port 7069
Block TCP port range from port 7071 to port 65535
Block UDP port range from port 1 to port 52
Block UDP port range from port 54 to port 122
Block UDP port range from port 124 to port 7069
Block UDP port range from port 7071 to port 65535

Now I have a firewall configured as tightly as possible while still allowing the services we use from the inside. Even Steve Gibson’s recently publicized LeakTest told me my site was secure. So, if you’ve been agreeing with the theory behind my suggestions but wondering what they look like when worked out in real life, this is the best example I can provide. Go slam those doors and shutter those windows; you’ll be glad you did — especially the next time you hear of someone else being taken to the cleaners. ##