Writing Firewall-Friendly Applications

Writing Firewall-Friendly Applications

People often complain that firewalls get in the way and won't let their applications work. News flash! Firewalls are supposed to get in the way! It's their job. If they were supposed to just pass everything along, they'd be called routers, although some routers do have firewall functionality. Firewalls are also normally administered by grumpy people who don't want to change anything. At least the firewalls most likely to protect you from attackers are administered by this sort of person. Firewall administrators aren't likely to open new ports to allow some application they don't understand, and this goes double if your application needs to allow several ports to be open in both directions. If you write your application correctly, you'll find that firewalls don't get in the way nearly so often. I predict that there will be many more firewalls in the future; most hosts will have some form of firewalling installed. In addition to an ordinary firewall at the perimeter, there could be firewalls at any point in the network. It will become even more important to design applications that work well with firewalls.

Here are some rules to follow:

  • Use one connection to do the job.

  • Don't make connections back to the client from the server.

  • Connection-based protocols are easier to secure.

  • Don't try to multiplex your application over another protocol.

  • Don't embed host IP addresses in application-layer data.

  • Configure your client and server to customize the port used.

Let's examine the reasons for each of these rules.

Use One Connection to Do the Job

If an application needs to create more than one connection, it is a sign of inefficient design. Sockets are designed for two-way communication on one connection, so it would be rare to truly require more than one connection. One possible reason might be that the application needs a control channel in addition to a data channel, but provisions for this exist in TCP. Additionally, you can easily work around this if you design your protocol well many protocols provide information in the header that specifies what type of data is contained in the packet. If you think you need more than one connection, consider your design a little bit longer. IP filters are most efficient the fewer rules are implemented. If an application requires only one connection, that's one set of rules and fewer ways to misconfigure the firewall.

Don't Require the Server to Connect Back to the Client

A good example of a firewall-unfriendly application is FTP. FTP has the server listening on TCP port 21, and the client will immediately tell the server to connect back on a high port (with a port number greater than 1024) from TCP port 20. If a firewall administrator is foolish enough to allow this, an attacker can set his source port to 20 and attack any server that listens on a high port. Notable examples of servers that an attacker might like to try to hack in this manner are Microsoft SQL Server at port 1433, Microsoft Terminal Server at port 3389, and X Window clients the client and server relationship is reversed from the usual on the X Window system on port 6000. If the firewall administrator sets the firewall just to deny external connections to these servers, inevitably some type of server will show up that wasn't anticipated and will cause security problems. Don't require your server to connect back to the client. This also complicates peer-to-peer communication. If the system my application is running on has a personal firewall, I'll have a hard time establishing communications in both directions. It's better if an application just listens on a single port and you invite others to connect.

Use Connection-Based Protocols

A connection-based protocol such as TCP is easier to secure than a connectionless protocol such as UDP. A good firewall or router can make rules based on whether the connection is established, and this property allows connections to be made from internal networks out to external hosts but never allows connections to originate from an external host to the internal network. A router rule that would let Domain Name System (DNS) clients function might look like this:

Allow internal UDP high port to external UDP port 53 Allow external UDP port 53 to internal UDP high port

This rule would also let an attacker set a source port of 53 and attack any other UDP service that is running on high ports on the internal network. A firewall administrator can properly deal with this problem in two ways. The first way would be to proxy the protocol across the firewall, and the second would be to use a stateful inspection firewall. As you might imagine from the name, a stateful inspection firewall maintains state. If it sees a request originate from the internal network, it expects a reply from a specific server on a specific port and will relay only the expected responses back to the internal network. There are sometimes good reasons to use connectionless protocols under some conditions, better performance can be achieved but if you have a choice, a connection-based protocol is easier to secure.

Don't Multiplex Your Application over Another Protocol

Multiplexing another application on top of an established protocol doesn't help security. Doing so makes your application difficult to regulate and can lead to security issues on both the client and the server as your application interacts in unexpected ways with the existing software. Usually, the rationale for multiplexing goes something like this: those nasty firewall administrators just don't want to let your application run freely, so you'll just run on top of some other application-layer protocol that is allowed. First of all, a good firewall administrator can still shut you down with content-level filters. You'll find that in general, a properly written application will be allowed through a firewall. If you follow the rules presented here, you shouldn't need to multiplex over an existing protocol. This is not to say that extending existing protocols is always a mistake. For example, if two Web servers are going to communicate with each other, it is entirely natural that they should do so over port 80 TCP.

Don't Embed Host IP Addresses in Application-Layer Data

Until IPv6 becomes widely implemented, network address translation (NAT) and proxies are going to continue to be common and will probably be seen more often as the shortage of IPv4 addresses becomes more severe. If you embed host IP addresses in your application layer, your protocol is almost certainly going to break when someone tries to use it from behind a NAT device or proxy. The message here is simple: don't embed host addresses in your protocol. Another good reason not to embed transport-layer information is that your application will break once your users move to IPv6.

Make Your Application Configurable

For various reasons, some customers will need to run your application on a port other than the one you thought should be the default. If you make your client and server both configurable, you give your customers the ability to flexibly deploy your software. It is possible that your port assignment will conflict with some other application. Some people practice security through obscurity which generally doesn't get them very far security and obscurity is a more robust practice and these people might think that running your service on an unusual port will help them be more secure.



Writing Secure Code
Writing Secure Code, Second Edition
ISBN: 0735617228
EAN: 2147483647
Year: 2001
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net