- The True Issues
- Mitigating Organizational Risk
- Mitigating Agent-Forwarding Risk
- Mitigating Port-Forwarding Risk
- Final Ideas
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Mitigating Port-Forwarding Risk
Port forwarding is risky because many people don’t understand how it works. Many system administrators skip over the details in a mad rush to create an FTP replacement system. Additionally, many admins are used to client software being relatively harmless. They don’t understand how many features are available within most SSH clients. So those tunneling abilities remain a threat—a hidden, ignored threat.
How much open, unfettered access does your organization have to devices on the Internet?
SSH isn’t the only service that can do port forwarding. There are standalone port forwarders, such as netcat (nc), that can complete the hack. But do you expect something you see as a Telnet replacement to be its own VPN tool?
How do you mitigate the risk? After all, you can’t control the Internet servers, and most SSH clients have port forwarding capabilities. Even if your "official" client doesn’t, the malicious user can install another. And though you may have your firewall blocking port 22 outbound, that’s not good enough. SSH can run on any TCP port. So the home SSH server runs on the email port, the DNS port, or any port that people commonly open for outbound access. This seems an unsolvable riddle.
Let’s begin with the basics. People can’t comply with unwritten policy. You must create and communicate, strongly, a policy against creating tunnels/remote access into your organization. Emphasize that any tunneling/encryption technologies that go outside of your official remote access program and VPN toolsets are forbidden.
Do you even have a remote access and/or VPN strategy? Or do you allow just about anyone to use anything handy as a conduit to your precious business secrets? You must state the consequences for creating a private VPN into YourOrg.com—even if it seems unlikely that you can detect these tunnels.
Allowing people to run personal computers with administrative authority allows them to evade any security control or secure software alternative you provide. Once you have more control on the SSH client software being run, create a process to survey and alert based on client settings (or simply overwrite them with the correct settings). While you can’t control a remote server’s configuration, you can control the client-side settings running on your organization’s PCs. Look hard—you may find a PC client that works with Active Directory and group policies.
Now that people are warned and the PCs are set such that tunnels don’t happen by accident, it’s time to tighten default accesses. The idea is that any tunnel, if found, is plainly a malicious act that involves knowingly and consciously configuring to evade policy and to deceive the organization.
Create a review process for approving SSH access to key devices on the Internet. Sure, SSH can be run on multiple ports or even tunneled into something like HTTP. But you must set the precedent that by default outbound SSH is not allowed. Consider high-level inspection tools that can detect tunneled traffic. Some proxy servers will inspect HTTP traffic for compliance to HTTP packet standards. If the HTTP packet is bad, the packet is dropped. But what about HTTPS tunneling? Can that be inspected?
Inspect firewall and WAN router logs for long-term, persistent connections or for those that begin at odd times and go outside your network. If the destination is outside of your approval process, you may have a stealth tunnel in operation. Time to ask a few questions or do some monitoring of the scripts running on the PC. While PC implies "personal," they are company properties and therefore open to monitoring.
You might even break the tunnel to help monitor it. Simply state that all jobs that access external resources must initiate on a DMZ host that you control. This application proxying is a valuable way to control outbound access. Proxying allows you to monitor information flows and prevent port forwarding from burrowing into your intranet itself.