I'm a programmer, and I have worked for a few clients whose networks block outgoing connections on port 22. Considering that programmers often need to use port 22 for ssh, this seems like a counterproductive procedure. At best, it forces the programmers to bill the company for 3G Internet. At worst, it means they can't do their jobs effectively.
Given the difficulties this creates, could an experienced sysadmin please explain the desired benefit to what seems like a lose-lose action?
I don't see that anyone has spelled out the specific risk with SSH port forwarding in detail.
If you are inside a firewall and have outbound SSH access to a machine on the public internet, you can SSH to that public system and in the process create a tunnel so that people on the public internet can ssh to a system inside your network, completely bypassing the firewall.
If fred is your desktop and barney is an important server at your company and wilma is public, running (on fred):
ssh -R*:9000:barney:22 wilma
and logging in will let an attacker ssh to port 9000 on wilma and talk to barney's SSH daemon.
Your firewall never sees it as an incoming connection because the data is being passed through a connection that was originally established in the outgoing direction.
It's annoying, but a completely legitimate network security policy.
If they're blocking a mishmash of ports, letting some stuff through and blocking some other stuff at random (I love Paul Tomblin's sad tale of the people who block SSH and allowed Telnet) then they either have a very strange edge case for how they go about securing their network perimeter, or their security polices are, from the outside at least, apparently poorly thought out. You can't make sense of situations like that so just charge them the going rate for people who are a pain and carry on with your day.
If they're blocking ALL ports unless there's a specific business case for allowing traffic through that port, at which point its carefully managed then they're doing it because they're competent at their jobs.
When you're trying to write a secure application do you make it easy for other processes to read and write information to it as they please or do you have a few carefully documented APIs that you expect people to call and which you sanitise carefully?
Risk management - if you feel that traffic to or from your network going onto the Internet is a risk, then you look to minimise the amount of ways traffic can reach the Internet, both in terms of number of routes and number of methods. You can then monitor and filter these chosen "blessed" gateways and ports to try and ensure that the traffic traveling over them is what you expect.
This is a "default deny" firewall policy and is usually regarded as a good idea, with a couple of caveats which I'll come to. What it means is that everything is blocked unless there is a specific reason to unblock it, and the benefits of the reason outweigh the risks.
Edit: I should clarify, I'm not just talking about the risks of one protocol being allowed and another blocked, I'm talking about the potential risks to the business of information being allowed to flow into or out of the network in an uncontrolled way.
Now for the caveats, and possibly a plan to free things up:
It can be annoying when you're blocked out of something, which is the position you find yourself in with some of your clients. All too often, the people in charge of the firewall think its their job to say "No", instead of "Here are the risks, now what are the benefits, lets see what we can do".
If you speak to whoever manages network security for your clients they may be amenable to setting up something for you. If you can identify a few specific systems at their end you need access to, and/or guarantee you'll only connect from a specific IP address they may be a lot happier to create a firewall exception for SSH connections for those specific conditions than they would be to just open up connections to the whole internet. Or they may have a VPN facility you can use to tunnel through the firewall.
A certain large company in Rochester NY that used to make a lot of film blocked outgoing ssh when I worked there, but allowed telnet! When I asked about it, they said that ssh was a security hole.
In other words, companies sometimes make stupid decisions, and then make up baloney excuses about security rather than admit their mistakes.
I can understand blocking inbound SSH communication if the company is disallowing external logins. But, this is the first time I hear of an outbound SSH block.
What is important to note is that such firewalling will probably limit only the casual SSH user. If someone really wants to SSH outside (which will typically be to a server/machine they have significant access to, outside the enterprise network) they can easily run the SSH server on a port other than 22 (say, port 80). The block will be bypassed easily.
There are also several public domain tools that will let you exit the enterprise over HTTP (port 80 or HTTPS port 443) and provide proxies to let you connect to port 22 outside.
Edit: Ok, wait a second, i have an idea why this could be a policy.
Sometimes, people use SSH tunnels to bypass basic outbound firewalls for protocols like IM and Bittorrent (for example). This //might// have triggered such a policy. However, I still feel that most of these tunnel tools would be able to work on ports other than 22.
The only way such outbound tunnels can be blocked is by detecting SSH communication on the fly and (dynamically) blocking these TCP connections.
It's probably a regulatory/compliance issue. Your employer wants to be able to read/archive all communication. This is very often a requirement in industries such as banking.
There are two primary reasons to block outbound port 22, in my opinion.
First, as people have mentioned, SSH port forwarding can be used as a proxy or bypass around other ports and services to avoid IT policy stating such traffic isn't allowed.
Second, a lot of malware/botnets will use port 22 because it is often seen as "secure" and therefore allowed. They can then launch processes out that port, and infected computers might also launch SSH brute force attacks.
More often than not it is more a case of blocking all outgoing connections unless needed, and until you tried no one had requested port 22 to be available for outgoing connections (just 80, 433, and so on). If this is the case then the solution may be as simple as contacting IS/IT and telling them why you need an exception adding so your station can make outgoing SSH connections to specific hosts or in general.
Sometimes it is the concern that people might use the facility to use SSH as a way to setup proxies (via port forwarding over the link) to circumvent other controls. This can be a very important factor in some regulated industries (i.e. banks) where all communication needs to be monitored/logged for legal reasons (discouraging insider trading, detecting/blocking transfer of corporate or personal data, and so forth) or companies where there is a great fear of internal leaks giving away, accidentally or otherwise, trade secrets. In these cases using your 3G link (or other techniques such as trying to tunnel SSH through HTTP) to circumvent the restrictions may be a breach of your contract and therefore a sacking offence (or, probably worse, a legal offence) so be careful to get your action agreed before you attempt it.
Another reason could be to reduce the outgoing footprint (to internal services accessible to hosts within the company firewalls and to the world in general) should something untoward manage to get itself installed on a company ran machine. If no SSH connections are possible on port 22 many simpler hacks that try use brute-force SSH logins as one of their propagation routes will be blocked. In this case you may again just be able to ask for an exception to be added so that your machine can make SSH connections, if these connections can be justified to the people in control of the firewall(s).
Your clients are probably in possession of non-trivial data that they would like to retain. Outbound SSH is a really bad thing to have open for an entire network. It's pretty trivial to bypass proxys, leak sensitive data, and be generally obnoxious.
IMO, anything passing through the network/internet perimeter should be understood and controllable. If a group of devs need access to servers at a hosting provider via ssh, that's fine -- but it also needs to be documented. In general at the places that I have worked, we establish dedicated site-to-site VPN connections to locations outside of our network, (essentially extending our internal network) and avoid client protocols like SSH over the internet.
Because SSH can be used as a VPN. It's encrypted so network admins have literally no idea what's leaving their network (dump of the customer database, etc.). I just covered this stuff in my monthly column "Secret Tunnels". The cost of some 3G internet is a heck of a lot less than having to worry about encrypted protocols channeling your data out of the network. Plus if you default block outgoing port 22 and traffic inspect you can easily find SSH on non-standard ports and thus find people violating security policy.
I know a couple of people who abuse the capabilities of SSH to install a SOCKS proxy thru SSH, thereby circumventing some site restrictions.
Or even some simple port forwarding (ssh -L ....), if the port is indeed blocked because of site restrictions I'd go to:
get them to a table and let them elaborate on the reason why this is blocked. Of course you need to have good reasons why you need access to an external SSH port for developing an internal product (internal being: Why do you need access to boxA.example.com when you work for a company snakeoil.invalid)
But I have yet to see a company blocking outgoing SSH :)
The obvious answers have all been stated. It's an encrypted protocol that can be used to circumvent policy through the creation of tunnels (this is a great way to get past the corporate web filters) as well as the threat posed by unauthorized communications channels (reverse proxy).
It's true, telnet should be destroyed in any modern network. But, I can see allowing telnet out of the network while banning ssh. Telnet is less capable than ssh and I can always monitor the stream, in real-time, through my sniffers. If I don't have any telnet devices in my core network, and some user wants to telnet out, what do I care. I can see it, and verify that it's not a threat.
Of course, all of this depends on the idea that the default policy is to block all egress and only allow specific protocols. Bonus points if you're proxying them before the hit the edge.
It's not a case of specifically blocking port 22 because admins have a thing against SSH, more a case of only opening the ports that they know they need open. If your admin hasn't been told that SSH is needed open, your admin will block it, by the same principle that applies to disabling unused services on a server.
Clearly, an outbound TCP/22 block is easy to circumvent unless the network administrators have taken serious, serious efforts to block SSH traffic in specific. What's more, the asset administrators need to be on the ball enough to run asset inventorying sufficient to catch 3G modems, and suspicious IP addresses on 2nd NICs. We have ClearWire service in our area, so we even have WiMax as an end-run option around our network security.
We're not an institution that's majorly concerned with information leakage. But if we were, we'd need to combine a draconian network security policy with a draconian asset policy, with auditing. To the best of my knowledge, I don't think an off-the-shelf security package exists that'll turn off the network jack of an asset that inventories with an external network connection of some kind. That may be comming.
In the absence of such a package, the asset-inventory process is one of the best ways to catch an end-run network connection like 3G or WiMax.
And finally, blind blocking of TCP/22 will only block the least wiley of end-users intent on violating the AUP for their work network.
I've seen 22 blocked when they discovered that folks were directing http traffic through 22. It was a show stopper for those of us who needed it but the org stood their ground.
Most larger organizations will be blocking everything and only allowing HTTP/HTTPS access via a proxy server.
I'd be very surprised to hear of any corporations allowing direct external connections from desktops or servers unless there was a specific need.
Nothing stops you from running your remote sshd on port 80. Both ssh and sshd have a -p option to set the port.
Of course, if your admins are smart they should watch for ssh traffic, not just port 22 traffic. So, it sounds like you have a policy problem, not a tech problem.
As others pointed out though, encrypted protocols can cause heartburn in the folks who have to worry about assorted compliance issues.
