Network Applications: A Security
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 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
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
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)
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
Epilogue: From Theory to Practice
I ran tcpdump, sorted through the output, and got these results:
Allowed Incoming Services–none installed
Block TCP requests to port 139 SMB
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. ##