I spend a bit of time in the field consulting. Over the last few years I’ve noticed a trend with new clients whereby I can usually (about 7 out of 10 times) identify “something” leaking out through the client’s perimeter that they were unaware of. I thought I would compile a list of the top 5 so folks could sanity check their own security.
Firewall Threat #5: Commercial VPN services
It amazes me how often employees will do an end run around perimeter security and setup their own VPN solution. I even see this on networks that already have an existing VPN solution in place. Could be the end user thinks the corporate solution is too restrictive. Could be they simply want to be able to extract info without going through the corporate content checking solution. Unfortunately there are a number of third party companies that are more than happy to sell VPN services that will circumvent the average firewall policy.
How does it work?
There are a number of VPN service vendors, but the most popular is GoToMyPC (now owned by Citrix), so I will talk about that service specifically. Implementation for the end user is pretty straightforward:
- Create an account and pay the $20/month fee
- Load agent software on their system at work
- Go home and launch their Web browser
The user can then logon to their work system and control their desktop remotely. They can even transfer file information by dragging files in or out of the session window.
Why are third party VPN services a problem?
Third party VPN services allow your end users to create an encrypted tunnel between their work system and systems on the Internet. If you have implemented some form of Data Leak Prevention (DLP) or content checking on the perimeter to control the flow of company private information, they will be defeated by a third party VPN. This means your end users could be transferring anything out of your network. Not only do you have no control of what info passes through the VPN tunnel, these services try very hard to look like normal traffic so you may not even know this is happening on your network.
Under the hood
Figure #1 shows how a third party VPN solution can work. Note that session establishment originates from the work system, not from a system on the Internet. So as far as the firewall is concerned this is an outbound session. Further, many of these services use TCP/443 to communicate and SSL to secure the session. So from the firewall this looks like normal HTTPS traffic. Most admins do not log outbound HTTPS, so there may not be any log entries to review.
How to prevent it
There are a number of possible solutions to curb this activity:
1) Review outbound firewall logs
Specifically, you want to look at outbound traffic taking place after hours. Filter out patching sites (Microsoft, Adobe, etc.), A/V signature updates, or any other expected pattern. Everything else should be scrutinized. Pay close attention to repeated connection attempts to the same host or subnet at a predictable interval (say every 20-60 seconds).
2) Desktop enforcement
Leverage application control or a similar technology to control which applications your users can install on their desktop. While this option may seem to be the most cumbersome, its also the only one that will work most consistently.
3) Block the IP addresses of known VPN services
While this option will work, it requires research to find out which IPs you should ban. Also, the list is going to change as new vendors come on the scene or IPs get moved around. For these reasons its my least favorite option.
Firewall Threat #4: Secure Shell (SSH)
It pains me to put SSH on this list, as over the years I’ve found it to be one of my most useful tools. Unfortunately SSH can be your worst nightmare when its in the hands of your end users.
How does it work?
Most people know you can use SSH as a secure replacement for Telnet. What is not as well known is that SSH can be used to tunnel TCP traffic. This can be implemented as either a forward tunnel, or a reverse tunnel.
SSH forward tunnels
When a user creates an SSH forward tunnel, the SSH client will open up which ever TCP port is specified by the user. Further, the user can instruct the remote SSH server where to send any traffic sent to this local port.
An example is shown in Figure #2. Let’s say that all outbound Web traffic is sent through a content checking system. The firewall checks outbound HTTP to ensure that only appropriate sites are accessed and that certain keywords are not permitted through. Let’s further assume that we have an internal user who wishes to access inappropriate sites.
Here’s what the end user would do. On their home system they would run a proxy server as well as an SSH server. From their office system they would run an SSH client in order to connect to their SSH server and request a forward tunnel. They would tell the SSH client to open a local port (say 8080) and tell the SSH server to forward all of this traffic to the local proxy server. Now all they need to do is tell their Web browser to use the proxy server located at Localhost, port 8080.
Voila! When they launch their Web browser it will connect to TCP/8080 on the local system. This traffic is then sent down the encrypted tunnel to the SSH server, and then on to the proxy. The proxy server will then connect to what ever site on the Internet the user specified. The firewall can not content check the passing data or control which sites get accessed, because the datastream is encrypted. Our perimeter security has been circumvented.
By the way, the user does not have to limit access to only their personal system. Its possible to tell the SSH client to service connections for other hosts on the wire as well. I remember an on-site I once performed where my porn signatures were triggering on the internal network but not at the perimeter. Turned out one of the engineers had done the above and opened up access to their buddies. So when another engineer connected to his system, the porn content was visible. When it left his system and went to the Internet, it was now encrypted and protected from detection.
SSH reverse tunnels
SSH reverse tunnels are similar to SSH forward tunnels, but are designed to handle data requests headed in the other direction. This is shown in Figure #3. Let’s say we have an internal server which is only accessible to internal employees. In other words, the firewall does not permit inbound connection requests from the Internet to be forwarded to the server. In fact there may not even be any one-to-one NAT or port forwarding in place for folks on the Internet to even try and access the server. Let’s further assume that we have an end user who wishes to expose this server to the Internet.
This time the user only needs the SSH server on their home system. From their office system, they launch an SSH session out to their server and request a reverse tunnel. With a reverse tunnel the user tells the SSH server to listen on some local TCP port (say TCP/80) and send any inbound connection requests to the SSH client. The user then tells the SSH client to forward these connection attempts to a specific port at a specific IP address (say TCP/80 on an internal HR Web sever).
Once this connection is complete, anyone connecting to TCP/80 on the users home system will be forwarded to TCP/80 on the internal HR Web sever. The firewall can not control the session because it looks like outbound traffic and all the data is encrypted. In fact you can’t even detect this activity on the HR Web server as all connection requests will be logged as originating from the user’s internal desktop system (the one running the SSH client).
How to prevent it
Take control of all outbound SSH activity. Block TCP/22 outbound and only permit it through when its verified the traffic meets corporate policy. SSH can be configured to listen on any TCP port, so we have to be able to spot non-standard port use as well. Leverage a NIDS or NIPS signature that checks the first three incoming TCP reply packets for an SSH server banner. This should be done on all TCP ports except 22. The banner will contain the string “SSH-1” or “SSH-2”. While its possible to hack the client and server software to change the banners, most end users do not have necessary skills to modify the software and still have it remain functional.
That’s enough for this post. In the next I’ll include the last three threats.
C
Related posts:
Another handy way out of places which restrict stuff even further with proxies is corkscrew. Just setup an outside server with ssh on port 443, setup corkscrew, and ssh to your heart content.
With the following in the .ssh/config you can do “ssh sslhost/destintion” to use the host listening on sslhost as a jumping point.
Host */*
ProxyCommand ssh $(dirname %h) nc -w1 $(basename %h) %p
Of course, this relies on the proxy server host being a bit dumb and not suspicous of really long running connections to a host!
Hey Niall,
I would probably bridge Corkscrew across items 4 (SSH) and 3 (outbound HTTP). I’ve used Corkscrew before and so long as you tweak the keep-alives it works pretty well. I would put this in the same category as SSH, it can be your best friend or worst nightmare depending on who’s using it.
Thanks!
C