Slashdot Mirror
SSH Connections Thru The Firewall?
iamsure asks: "At my workplace, we have stringent rules on our firewall that filter out particular protocols (telnet/ssh being the one that is difficult for me). I actually work on the Security team, and as such, support such rules, as it helps reduce the number of incidents. However, I would very much like to access my machines from the outside via ssh, without making exceptions on the firewalls. After having tried http-tunnel (whose dual websites have gone offline, same for their server), and after having tried redirection of ports (the firewalls block the protocol, NOT the port), I am rather stumped. How does the rest of the slashdot reading public get through their firewalls?
There does seem to be a decent project underway at SocksViaHTTP , however, I was wondering if there are any other projects?"
How ssh (port 22) is any different from anything else? If connection outside can be established, no matter through what, even if through HTTP proxy, it can be used for forwarding.
Certainly. However, ssh *is* a secure form of shell communication. Telnet isnt. The fact that it can be used for other things is really besides the point.
What users are doing connecting _outside_ from inside, changes nothing. Telnet may be insecure, but who said that users are accessing something that requires security in the first place? It's outside! I access slashdot without any possibility of hiding my password when I log in, and I have no way to verify any signatures, yet it's perfectly acceptable because my authentication here is not important for security. OTOH, what users doing by connecting _from outside_ is always important -- at very least the passwords they use must be protected. However even that may not be necessarily as important as sysadmin logging in -- user may use one-time password and never transfer anything sensitive unencrypted (but FTPing of encrypted files is ok). This, of course, requires users that ACTIVELY support security, so most of people in the company simply aren't qualified to make the distinction, what they can or can't do over one-time authenticated but unencrypted link, so restricting them to inbound ssh is reasonable.
The rest of your post is essentially a big "Why bother with security at all, just trust your users" speech.
Not at all. I only mean "don't protect your network against malicious users". And this is absolutely reasonable because users ALWAYS have more opportunities to cause harm to the company without talking to anything outside the network, compared to anything that they can do with it.
While thats nice, when you are in charge of protecting corporate data that is mission critical, and users that dont know what right-clicking is, you will have a different grasp of things.
If the users are not malicious but merely incompetent, harm from them will not be decreased in any way by messing up their connections to the outside world -- after all, Melissa distributes itself using plain mail, and there is no reason to believe that anything else harmful won't do exactly the same. Better results can be done by banning users from installing any software on their boxes without a technician involves, and, if the OS allows, enforcing it in the configuration. And even without that, banning Outlook goes a long way to stop whatever malicious stuff may arrive -- it certainly will allow to avoid more trouble than any imaginable restriction to outgoing connections.
The job requirements dont say get touchy-feely and trust our users, they say keep the bad guys ( including employees) out, or you are out of a job.
I don't care, what your "job requirements" are -- if "bad guys" are already among employees, you MUST GIVE UP trying to thwart them because you have already lost -- at that point at most you must be able to restore clean copies of everything from backups fast enough to prevent further damage. There is no defense, and all possible messing around with firewalls won't help a single bit if any -- ANY -- means of communications are open.
The good news is, this is what others are supposed to take care of, so you, a sysadmin, must not waste your time by trying to do the impossible, fighting ghosts and spreading a paranoia within the company, but spend it defending against real threats that no one but you is supposed to defend against.
Contrary to the popular belief, there indeed is no God.
In general SSH connection should not be allowed outside a private LAN. If a user can establish a connection from his PC on the private LAN to a host on the Internet, then that user can also tell the Internet host to listen on a port and redirect any connections to that port to any host inside the private LAN. This defeats the purpose of having a firewall. Similarily tunelling via covert mechanisms is certainly a violation of your security policy and even if it does not result a hostile compromise of your organization's LAN it could result in a great deal of wasted time and money of security has to investigate what your doing.
Bottom line, if you can't already find a way to tunnel out then perhaps its a good idea that your not allowed to tunnel out. Why not bring up the topic with your network architecture person/people/group and discuss why they've set the policies they've had. If you have a legitimate need to establish outbound SSH connections they might be willing to find a solution for you.
To go further, use ssh keys (rather than passwords) to grant access; this means those keys (and the password to unlock them) need to be stolen for an intruder to gain access (naturally, you'll be firewalling the client as well, right?!)
If more than one person needs access to SSH on a given host, you might be able to tie things down by running several SSH servers, each listening on it's own port and each running as a seperate, regular user (rather than root, which is the normal configuration). This way, compromising your SSH server will only give your priviledges. (Note: I haven't actually tried doing this, but I don't know of a reason it can't be done...:)
To go a bit further, install filtering rules on the ssh server to limit what outbound connections it can make. If it's a Linux box, perhaps look into using iptables, which can provide filtering according to UID/GID.
Finally, in order to provide some kind of audit trail for when it does all go wrong, use one-time authentication at your firewall to allow or disallow the SSH TCP connection appropriately.
Several options here; in (approixately) increasing level of difficulty and inconvenience. Stop when you feel your paranoia level has been exceeded. :)
Where I work, SSH is the only connection to our development LAN we can have from the outside. I routinely tunnel connections through SSH, for accessing my ZWiki, and for getting/sending mail. If you're going to work from home (they pay for our cable modems), it *has* to be over SSH. If you need something out in the field, SSH is the only way.
:-)*
I can, however, see where you are coming from. So I have a pair of suggestions:
1. Webmin. This is the only remote admin tool I like. Everything else just sucks and breaks when I manually edit files. You can easily set it up to use SSL, too. If your firewall allows that kind of traffic (likely), you can use that. It has the added bonus of limiting access to parts of the system so that certain users can run specified commands, while superusers can create and run those commands. If you need to up/download files, it does that, too. Don't even try to use the telnet however. Limit your access to the commands page.
2. Obviously, you are a superuser. You don't want regular users to remotely access your internal systems while you have to. That's fine. Simply let yourself do it, while blocking the regular users. There are two ways I can think of for doing this: a. Set up a box with an SSH port open that only you (and whoever else should have access) have an account on. Make that an intermediate box, which you ssh into, then ssh to the server you're trying to get to. b. If your firewall supports "trusted hosts" (likely, if it can filter by content) and your home system has a static address, allow ssh only from your address.
If you can't do either of these, then forget it and don't bother giving away the free overtime
Why not stick a box in the DMZ purely for this kind of requirement. Then allow users with legitimate business reasons for using SSH to have accounts on it.
Not all that different from an application level proxy really.
Funny, I've just been talking to a few people about how silly fascist net admins prohibitting anything but http just causes everything to speak http...) to do just that. The one catch is that most web proxies will only let you connect via https to port 443 on the remote machine, so you need to be able to run sshd on that port.
Web proxies, due to mutual authentication concerns, generally give you a *straight* TCP connection when you go to connect via https. Therefore all you have to do is get ssh to walk the proxy. As it turns out, this is pretty easy and I've written a tool (http://www.snurgle.org/~griffon/ssh-https-tunnel
The tool is written in perl. It probably wouldn't be a horrible idea to rewrite it in C, but this one works pretty well, is easy to tweak, and seems fast enough.