Knowledgeable users can leave your attempts to block outbound ports in tatters and let outsiders access computers on your non-routable internal network. As we will shortly see, relying on routers and firewalls alone to filter traffic and keep your network secure could lead to disaster.
One way you may be tempted to beef up security on your network is by blocking certain ports to outbound traffic – to prevent users running unauthorized IRC clients, for example. But all it takes is one bright spark on some far away floor with a strong urge to use IRC and your whole organization could soon be bypassing your attempt at a security control.
Here’s one way how. Let’s imagine you’ve blocked all ports to outbound traffic, except port 80 and 443, for Web traffic. Most of your users will find that their IRC clients won’t work, because they can’t send traffic to the relevant port on the IRC server they want to connect to. It doesn’t have to be IRC – users will be unable to connect to any services which require a port other than port 80. But there’s bound to be one user who figures out a relatively simple solution: port redirecting.
All he has to do is set up a port redirector – there are plenty to choose from: Fpipe, AVTPF, or rinetd to name but three – on his home Linux or Windows computer, and configure the redirector so that any incoming traffic on port 80 is redirected to whatever server and port he wants – such as his favorite IRC server on port 6667.
Now when he wants to use his IRC client at work, he simply points it to his home machine’s IP address (using port forwarding on his router to take care of NAT, if necessary) which will then redirect his IRC client to the real IRC server. Worse, he may tell his colleagues in the same department and elsewhere in the organization that if they want to use IRC from work, they should connect to his home machine on port 80. Suddenly everyone in your organization could be connecting to a server on port 6667, even though this shouldn’t be possible because your firewall is blocking everything but ports 80 and 443.
Clearly there are steps you can take once you figure out this is happening, but the point is that it can (and probably will) happen. Blocking outbound ports doesn’t stop people from finding ways to use them
What about letting outsiders in through your firewall? Surely if a user’s computer has a non-routable IP address, this makes it inaccessible to outsiders (unless traffic on certain ports is specifically routed to that machine using a firewall/router rule.) It turns out that this is not the case, though it does require some port trickery to create a reverse tunnel.
Let’s imagine our smart employee wants to log on to his work computer while he’s at home, without the assistance of the IT department. At home, he sets up an SSH server, configured to listen on port 80, the port that is allowed to send outbound traffic on your corporate firewall.
On his work computer, he uses an SSH client, and configures it to connect to the SSH server using port 80. He configures the SSH connection so traffic sent to the local port 3389 (that’s the standard RDP port) on the work machine is forwarded through the SSH tunnel, to port 3389 on the home machine.
The clever bit happens when our user returns home. Using Rdesktop or some similar Windows Terminal Services client, he connects to localhost (127.0.0.1) on port 3389. When he does this he will automatically be connected back, through the SSH tunnel, to port 3389 on the work machine, and get full control of the work machine using the remote desktop interface. He’s passed through the firewall, reaching a machine with a non-routable IP address, without setting up any port forwarding or redirecting rules on the corporate firewall/router.
Of course, an employee could do this quite easily using a service such as GoToMyPC, which performs NAT traversal in a similar way that Skype does – by having clients log on to a mediating server which brokers connections. What’s interesting about our example, and what should get alarm bells ringing, is that a firewall and non-routable IP address don’t really offer any protection at all from a determined outsider. Instead of using remote desktop, an attacker could use this reverse tunnel to FTP or telnet through the firewall on to the corporate network.
An obvious next step to take would be to implement some form of packet inspection appliance on the network to detect certain traffic types, but don’t forget that these can be overcome by programs like ProxyTunnel which can wrap SSH traffic in an apparent https packet. As with all security problems, there’s no such thing as a perfect solution – only a matter of raising the bar to make breaches harder for attackers. If you rely on your router and firewall for security you’re providing a very low barrier indeed.
