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. Period. By people, software, whatever else, so to avoid starting cat and mouse game, it's better not to mess with someone's ability to establish connection outside.
If you don't trust your employees to not undermine security, why would you trust them their job at all? They can do more rarm by plain sabotage of whatever they are doing than by any stupid port forwarding. Of course, there are all kinds of viruses/worms/etc. that will be more than happy to exploit any enabled protocol (and will succeed given that at least something works), but this returns to the basics -- system won't be secure if people who use it can run things of dubious origin. If your users run outlook and click on every attachment, be prepared that connection from their box is as untrustworthy as a connection from outside, it's that simple.
Contrary to the popular belief, there indeed is no God.
Revealing passwords of outside resources allows subversion of those outside resources by others, which can allow attacks back into your facilities. Finding an outside telnet, ftp, or web mail password allows tinkering with files which may be transferred into your corporate facilities.
Who said that they even use passwords? Maybe they use one-time passwords?
An employee might trust the attachments on saved email from a trusted source, not realizing that someone has altered them.
There is much more to the security of other users' accounts than encryption. In fact, it's extremely unlikely that potential intruder is sitting at mae-west examining the packets from your network, in the hope that he will intercept some of your users' unencrypted password to some external account, so he will plant some file there, so user will transfer it to his box at work, run it, and that will compromise your network. Intruders don't think that way. At best, if they will bother to plant some modified files on the user's account outside, they will find a security flaw that will allow them to access user's insecure account outside, and then it will make absolutely no difference, how user will access it -- over ssh or ftp. In any case, port filtering at work will not prevent user from using telnet from home, and it's more likely that his connection will be intercepted there because of poor configuration of bridges and switches at his ISP, thus making the whole effort a moot point.
At most, banning all outside connections but ssh will make a lot of users who have outside accounts without ssh support ssh to some box outside, then run telnet to non-ssh-supporting account. Security gained: 0, waste of time: 15 seconds per connection (to type a password), 100ms per packet (latency between outside accounts).
It doesn't matter if the weak link is outside or inside your corporate LAN.
You can't eliminate any insecure stuff outside, except the most unlikely way for intruder to make his, very indirect, attack. And there are thousands of ways to send a file to someone, pretending that it comes from his own account. You can't control that, and you shouldn't for a second imagine that you can -- even if you can decrease the probability of such attack by 0.1%. Instead you have to create a reasonable policy in the place where it matters -- never transfer anything executable from outside, period. If users can't avoid opening attachments in outlook -- ban outlook, make mail server strip all non-text attachments, do something else useful, but it's important that policy should be directed against real dangers instead of creating imaginary protection for accounts, you can't control.
Contrary to the popular belief, there indeed is no God.
If you establish a point to point tunnel using SSH, I don't see how it is trivial to then configure the inside point to route all the traffic across the tunnel throughout the network.
Even if that is done, then only the one host on the outside can access the internal network. To do otherwise would require configuring it as some kind of gateway...
So an end-user sets up NAT on an internal machine, opens an SSH connection to a machine on the internet and sets up a Socks5 server. I don't see how that is trivial...
Great idea. However, the one about letting the user enter a username/password/IP combination is a little stupid. I mean, that kind of defeats the whole purpose.
You also want to make sure the username/password is sent over HTTPS.
--Be human.
The firewalls block by PROTOCOL, not port.
Thus, portforwarding on the external server doesnt help anything. I can even run ssh on the https port (443) which I can connect to, and it will not help. Its the protocol that needs to be tunneled, not the port.
GPL'd web-based tradewars themed space game
This is really two very different issues, but good ones. (Although not related to the question at hand directly).
>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.
The rest of your post is essentially a big "Why bother with security at all, just trust your users" speech.
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.
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 happen to enjoy my work alot. I agree with the policies, I am looking for a way to follow them, while still tunneling out.
If you have knowledge of a solution to the PROBLEM, not an argument about the issues LEADING to the problem, I would love to hear them.
Thanks anyways..
GPL'd web-based tradewars themed space game
Well you might as well go all out and just use a VPN. It'd probably be better than a custom made and unproven cgi web unlocking thingie anyways.
But keep in mind just because you use SSH or a VPN does not mean that you are perfectly secure. Your machine may have a trojan key grabber installed, and could steal your passwords or keys.
Wow! You're pretty damned stupid.
Your security policy allows covert tunnels, but doesn't allow explicit tunnels? Did you think of that yourself, or did it require the doublethink of an entire comittee to ratify?
You don't want to open a port, because then you'd have to monitor the port, but you do want to open a tunnel, because then you mistakenly believe you'd never have to monitor the tunnel? Is this the "ostrich head in the sand" model of security that seems so popular nowdays?
I did read the full question, and I mistankely assumed that the slashdot editors had somehow mangled it into some sort of hilarious bufoonery by accident. It's sad to see that instead, they were fed the dranged rantings of an idiot, and then published it.
Slashdot is jumping the shark. I'm just driving the boat.
However, the one about letting the user enter a username/password/IP combination is a little stupid. I mean, that kind of defeats the whole purpose.
That's true. Why not just put in the name and IP number? Obviously, the server is going to have the public keys for the remote machines, and is only going to successfully negotiate a connection with a remote machine that has the right private key, so the password seems like a pointless extra step.
But, passwords are the sort of thing that would make people feel good, so it's probably not too bad to have it. Like you say, though, there's a really great danger that somebody would use the same password for this application as they would for an application that required a password, so they should be sent over HTTPS just to avoid someone leaking a password that's used for some other system.
Slashdot is jumping the shark. I'm just driving the boat.
Is it really so bad to open one, teensie, weensie little port on your server for ssh?
Have port 54522 portforward to 10.0.0.etc:22.
(Or did I miss the point?)
Daniel
Back in the days of terminal servers, companies where afraid of hackers using their modems. To make sure only authorized connections are allowed, they used to have callback systems. A person would dial the modem, enter a username and password. The modem would hangup and dial the assigned number for the validated user and the connection would begin. The fact that the callback number could only be changed from inside the office made sure that only authorized connections could be made.
I would think a similar system would work in your case. Most firewalls are concerned with traffic going in, not traffic coming out. Create a server in the office with an HTTP server on it. Add a java servlet/perl/cgi module to the server to ask for a user name and password. If the correct username/password is given, an ssh tunnel is open from the inside server to the remote machine on file for that user. if you don't need that much security, or have dynamic IPs at home, then pass a username/password/IP combination and have it open the tunnel to the given IP.
Another option is to look into VPNs, which you could create on your firewall, once connected, you would be considered "inside" the office, and could do anything you want. Cisco VPNs, while a little tricky to install, are secure, and well supported on their firewalls and routers. Be sure to have your VPN data encrypted.
--
He had come like a thief in the night,
Si hoc legere scis nimium eruditionis habes
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.