Scrap/DealingWithFirewalls

UserPreferences

http://tangentsoft.net/wskfaq/articles/firewalls.html

1. 개요
2. How Your Protocol Affects Firewalls
3. Clients Behind Masquerading Firewalls
4. Clients Behind SOCKS Firewalls
5. Firewalls, Politics and Paranoia
6. Servers Behind Firewalls
7. Conclusion

1 개요

Firewalls are everywhere. It seems like everyone's company LAN is connected to the Internet these days, and nearly all those companies have prudently put their LAN behind some kind of firewall. So, it's likely that some day someone will try to use your client or server across their firewall. Depending on a number of factors, this may work without trouble, or you may run into many problems trying to make this work. This article will discuss these problems and some of the solutions to them.

2 How Your Protocol Affects Firewalls

For the greatest chances of working through a firewall without trouble, you should use a simple single-connection TCP-based protocol: the client connects to the server, sends data and gets replies on that connection, and when finished closes the connection.

For an example of a protocol that causes problems with firewalls, consider FTP. FTP has two connections: a control connection and a data connection. The control connection is always present, but the data connection is brought up only when the server needs to send bulk data to the client, such as a directory listing or the contents of a file.

In traditional "active" mode, the FTP server connects back to the client to establish the data connection. The problem is, the client has to tell the server which port number it's listening on for the data connection. When the client is behind a firewall, the server believes it's connected to the firewall machine, so it tries to connect to the given port on the firewall, which isn't listening for the connection. The server gets rejected, and the client sits waiting forever for the server to connect to it.

There are two solutions to this problem. The first is for the client to use "passive" mode: the client connects to the server for the data connection, instead of the server connecting to the client. The other solution is for the firewall to know the FTP protocol, so it can recognize the FTP data connection port number within the protocol, rewrite it to a port the firewall can use, and then listen on that port. When the FTP server connects to the firewall, the firewall can then connect to the FTP client inside the firewall and begin relaying data.

Unless you're writing a client for a well-known protocol, you should try to write it so the firewall doesn't have to know your protocol in order to forward packets. For the longest time, Real Audio clients didn't work behind firewalls because of the way Real Networks designed the protocol. Today that isn't a problem, but it took Real years to achieve the success they needed to get firewall vendors to add support for their protocol.

3 Clients Behind Masquerading Firewalls

Let's assume that your client uses a simple single-connection TCP-based protocol. There are still potential problems ahead: the type of firewall can make a difference to your client.

From a client program's perspective, the simplest kind of firewall is the masquerading firewall. They appear to hosts inside the firewall like a simple gateway to the Internet.

A masquerading firewall is fairly tricky from a technical perspective. Packets destined for the Internet go to the masquerading firewall, which changes the internal IP address and source port number of outbound packets to the firewall machine's IP address and a generated port number. Then they pass the packet outside to the Internet and wait for the reply. When the reply comes back, the firewall recognizes the port number it generated, and uses that to translate the port and IP back to the "internal" values, then passes it on to the host inside the LAN.

If your protocol is simple, your program should work through a masquerading firewall without problems. The only likely problem you'll run into is if the firewall blocks outbound connections to all but a few select ports. In this case, you'll have to ask the firewall's administrator to open up your port. This is discussed in more detail below in the "Firewalls, Politics and Paranoia" section.

4 Clients Behind SOCKS Firewalls

If a firewall doesn't do masquerading, it will usually allow clients to get through it via the SOCKS protocol. SOCKS allows a client program on a protected internal network to ask the firewall to act as a relay between it and a host outside the firewall.

SOCKS version 4 is the "basic" protocol. The main difference between masquerading and SOCKS v4 is that masquerading is transparent, whereas with SOCKS you have to modify your program to make SOCKS requests to get through the firewall. (SOCKS v4 also has a few features masquerading doesn't, like basic plaintext authentication, but this is a minor issue.)

SOCKS version 5 builds on that base and adds UDP support, end-to-end encryption, and secure logins. These latter two features make it much more secure than SOCKS v4 and masquerading, so it's becoming quite common. Few firewalls require encryption to get through, but quite a few are requiring SOCKS v5 logins, to curtail rogue programs getting through the firewall.

You can find out more about SOCKS via the following links:


• Permeo's SOCKS site - Permeo offers the SOCKS reference implementation, the SOCKSCap external SOCKSifier (both free for personal and educational use), a lot of good technical info, and some commercial products, including a commercial SDK for SOCKSifying your applications.
  
  Permeo's SOCKSCap allows almost any Winsock program to run over a SOCKS firewall with no changes to the application. (There are other vendors that offer SOCKSifiers, and a few non-Microsoft Winsock stacks are SOCKSified.) The problem with SOCKSCap is that your users must set up SOCKSCap by hand, and they must run your program through the SOCKSifier. It's more user-friendly to implement the SOCKS protocol within your program.
  
  SOCKS does let you get around some of the limitations imposed by a masquerading firewall. For one thing, you can do a "remote bind": ask the firewall to listen on a port for you, and pass connections in to your program. SOCKS v5's UDP support may also prove helpful to you. Just beware that even SOCKS firewalls can limit your design choices.
  
  
  

5 Firewalls, Politics and Paranoia

Technical people often look at a firewall as a technical solution to a technical problem. In actual fact, a firewall is a political construct. Like a country's border, it exists to protect an organization's turf from invaders. The permeability of a network firewall depends on the paranoia level of the people who control the firewall: there's a lot to be paranoid about in today's Internet.

Many firewalls are set up to block all outbound connections except to a very few ports. For example, the firewall might be set up to allow outbound connections on ports 80, 21 and 25 only (web, FTP and outbound email). If your application uses a port that the firewall blocks, you will have to persuade the network administrators to open up that port on their firewall. Network admins are often very territorial about their firewalls. Getting your way will require a certain amount of political finesse.

The administrators at such a site have decided that they'd rather open ports on a case-by-case basis than block ports as new security risks get discovered. You have to convince the admins to open up your port. I suggest that you prepare a written argument explaining what your program does, why it does it, and an analysis of potential risks. Don't fudge on the argument: be completely honest and open. Present the benefits of the application separately; you're not trying to convince the admins to use the program, just to show that the application is useful to users on their network. Try to get some of those users to speak with the network admins directly to help you press your case.

Why a written argument? Partly because it shows professionalism, partly because you might not be able to speak with the admins directly, and partly because it forces you to clarify and organize your thoughts. If you just call the admin up on the phone and make up your arguments as you speak with him, you may just come across as argumentative. Even if you do end up speaking with the administrator directly, having a written argument to refer to will help you to make your case.

Some people suggest a different tactic: change your program so that it sends its packets out on a port that's open on even the most restrictive firewalls. Because some firewalls examine the contents of packets to make sure they're legitimate, some people even suggest encapsulating your data in the protocol that usually runs on that port. For example, you could send your data out on port 80, and put your program data in the payload area of HTTP packets.

To extend the "politics" analogy, this is the "smuggling" tactic. Just like smuggling in the real world, it's likely to get you into trouble. You won't go to jail for it, but you might generate a lot of antagonism toward your program; network admins have been known to band together and ban programs that annoy them.

6 Servers Behind Firewalls

Let's say you've written a server program. It works fine, but then someone tries to use it behind a firewall, while the clients are on the other side of the firewall. This is very common when the server is running on someone's LAN, but they want to access your server from out on the wider Internet.

The easiest solution is simply to move the server outside the firewall, but most network administrators are extremely reluctant to do this. Common reasons are:


• Most of the users are inside the firewall: the users outside are the exception, not the rule.
  
• The firewall setup doesn't allow anything outside the firewall.
  
• The firewall is administered by some other party, like the company's ISP, and they won't allow you to put your server outside their firewall.
  
• If you can put the server behind the firewall, the firewall can control access to the server: it's an extra layer of protection between your server and the big bad Internet.
  
• It's axiomatic that you should not expose any more services to the outside world than you have to. Some network admins will stubbornly fall back on this despite any arguments you can muster, no matter how logical.
  
  
If you run into this, the solution is to get the firewall administrator to set up "network address translation". NAT is a term for several vaguely-related techniques, two of which you can use to make your server visible outside the firewall: port forwarding and address forwarding.

To understand NAT, consider the following LAN setup: the internal LAN hosts use the private IP address block 10.x.x.x. Let's say the host your server is running on has the internal IP address 10.1.2.3. Their ISP has assigned this company the public IP subnet 123.4.5.{1-15}. The firewall has at least two addresses: let's say 123.4.5.1 on the outside, and 10.1.1.1 on the inside.

Address forwarding is the simplest, but also the riskier of the two approaches. To set up address forwarding for our example LAN, the firewall could assign 123.4.5.2 to your server. Whenever requests come in on that address, it quietly translates the destination address to 10.1.2.3 and the source address to 10.1.1.1, and then it passes the packet inside the LAN for your server to handle. When your server replies, it believes it is replying to the firewall at 10.1.1.1. The firewall gets the reply packet and translates the source address to 123.4.5.2 and the destination address to that of the host that made the initial request. Then it sends the packet out onto the Internet which routes the reply back to the client.

The problem with address translation is that if your server host has any security holes, the firewall will let anyone outside break in through those holes. Once they're inside your server, they're also effectively inside the LAN, so the firewall's protection is totally gone.

The more secure NAT technology is port translation. Let's say your server uses port 1234. When you set up port translation on the firewall, it begins listening for packets on that port, which it forwards inside the firewall to your server. This is more secure because it only exposes that one port to the outside world.

Sometimes address and port translation are combined. Let's say the firewall only has one outside IP address available to it, and that you have several servers inside the LAN that use the same port. The firewall's NAT features may allow it to listen on ports 2000 through 2007 and translate packets coming in to each of those ports to different hosts inside the LAN, each with the same port, like your server's 1234.

Not all of these options are available on all firewalls, and the network adminstrator might not know how to use these features even if they are present. Or, they may simply be unwilling to let your server be visible from outside the firewall. Just like with the political issues with clients discussed above, resist the temptation to piggyback your protocol on top of an "approved" port and protocol, unless the firewall administrator gives you permission.

7 Conclusion

This review of firewall technologies, problems and solutions is limited to my own experience. If you've run into other types of firewalls or other problems getting through firewalls, please drop me a line with info about the problem and I'll try to add info on getting around the problem to this article.

• see also NatAndFirewall