SSH Connections Thru The Firewall? 35
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?"
Change the rules (Score:1)
various tunneling options (Score:1)
I'm assuming that you've already discussed this with the local überBOFH and decided that ssh is not acceptable, but a tunnel is. My personal opinion of your situation is that a tunnel is only acceptable if the remote endpoint is behind a firewall with a ruleset as least as restrictive as the home network's firewall and is subject to usage rules (who has access, what is each user allowed to do, etc) at least as restrictive as those of the home network. Remember that establishing a tunnel between two nets is equivalent to connecting the two networks behind their firewalls - if someone has access to one network, he won't be bothered by the firewall on the other.
That said...
At a client site I'm currently tunneling past a NAT router (because I want to run a protocol that the router can't masquerade) by having a machine behind the router establish a connection to a machine outside. I'm using a program called Tunnel Vision (http://www.worldvisions.ca/tunnelv/ [worldvisions.ca], or package tunnelv on Debian), but since your firewall probably won't allow it past you should use a protocol that your firewall does allow in ways that it dosen't expect.
If your firewall allows https through, you should be able to run anything you please through port 443 as long as it's SSL-wrapped (so the firewall dosen't think anything's amiss). You could use the stunnel package (http://www.stunnel.org/ [stunnel.org], or package stunnel on Debian) for this - set a server running on port 443 of a machine outside the firewall, and start the client running inside. This will establish a stream between the two endpoints, and you can run anything you please over it - I'd choose to run pppd.
If your firewall dosen't allow https but does allow http, you can use httptunnel (http://www.nocrew.org/software/httptunnel.html [nocrew.org], or package httptunnel on Debian). I haven't used httptunnel, so I don't know if you need to run pppd inside it. If it dosen't do strong authentication and encryption, you'll need something inside it for that, too.
These solutions require that an IP be reserved inside the firewall for the machine on the outside end. The machine inside should proxy-ARP for the machine outside.
You could also tunnel traffic over DNS queries - see http://nstx.dereference.de/nstx/ [dereference.de] for a program that will do that - but it's doubtful that you'll need to do that.
Re:They shouldn't let SSH out. (Score:1)
This is why a SSH application level proxy is needed. In that case you could configure the proxy to disallow some of the more objectionable aspects of ssh, e.g., port forwarding. How to do this without ssh thinking a man-in-the-middle-attck is ocurring is left as an exercise for the reader.
Yes, but with SSH it's trivial. (Score:1)
It isn't true that you can establish a tunnel on any port with any protocol. Under most circumstances it is possible but proxying firewalls can make it difficult or impossible. But let's just assume that you can always find at least one protocol/port that you can tunnel with, SSH is still a problem because it makes creating both outbound tunnels and inbound tunnels trivial. Other methods, even if they are "easy", are not trivial. Most security policies would make circumventing the security of the firewall a violation. So tunnelling without SSH is out if your trying to obey the policy. SSH is usually considered "grey": its good for the policy because it encrypts your shell sessions, but bad because it makes bypassing the firewall trivial (for TCP connections anyway, slightly more effort is required to tunnel UDP with SSH).
Security policies don't exist because employees aren't trusted, they exist so to provide guidelines for employee behavior that allows everyone to have a higher level of confidence that all information technology will function as desired (or at least as expected). IT is complicated and mostly broken IMHO. If you want it to work they way you think it should work then everyone needs to follow some guidelines; that's what the security policy is for.
For the uninitiated, I'm calling an outbound tunnel, a situation where you instruct your client to listen on port XXXX any packets that arrive on that port are delivered to the server who then delivers those packets to host a.b.c.d on another YYYY. I'm calling an inbound tunnel, a situation where you instruct the server to listen on port XXXX and any packets recieved there are delivered to the client who in turn delivers them to host a.b.c.d on port YYYY.
A outbound tunnel can be used to allow hosts on the private network to bypass the firewall and talk to hosts on the Internet. An inbound tunnel can be used to allow hosts on the Internet to bypass the firewall and talk to hosts on the private LAN.
Re:They shouldn't let SSH out. (Score:1)
Re:Change the rules (Score:1)
Re:Change the rules (Score:1)
Re:They shouldn't let SSH out. (Score:1)
In relation to your specific question, the way I would solve it would be to put a separate standalone box inside the firewall, and change the firewall to allow connections from that inside IP address to the outside on the ssh protocol. Then I would allow only myself or others I trusted to login to that machine, i.e., it would have a subset of the normal accounts on it. (I am sure that there is a better way to do this, without needing a separate machine, but I don't know it.) Then you would use this by connecting to the priviledged box and then connecting to the outside.
But what I really want to criticize is the instinct to incorporate presumptions about all the other employees ignorance ignorance into your security plan. If you want to allow some people (who are presummably smart enough to know the dangers) to use ssh through the firewall and not the general population, then you should have that explicit policy, not one that depends on an obscure hole never being discovered because most people are weenies. Then you can enforce that explicit policy of who has ssh priviledges through some normal mechanism, like what I outlined above or something more sophisticated.
I think a lot of big security disasters start like this -- someone sort of hacks their way around their own system, but presummes that the rest of the world will never figure out how to do it so their hack doesn't need to be incorporated into an explicit security model or plan, and then gets burned.
Re:proxy (Score:1)
Privledged Port (Score:1)
Re:Simple - tunnel via https (Score:1)
Thank you very much for this wonderful tool. Just about every way to get ssh through our firewall is supported on every platform but AIX. I'm not much of a programmer, so I'm on my own. This got me through and seems to work perfectly!
I wish just I had mod points.
Try executing commands via email (Score:1)
Tunelling and the art of Motorcycle Maintenance. (Score:1)
While I know that telnet isn't secure; a rinky-dink server at home generally lets me get my job done in tunnelling.
From a hacker's point of view; you can use the Firewall-Hacking tutorial on linuxdoc (I believe it ends up pointing to This site [nocrew.org])
The real point is that the moment you open up a port; you no longer have security. True security is having your machine turned off, not connected to a network, and in a steal cage...
GNU httptunnel (Score:1)
Sockscap + ssh client (Score:1)
Under linux the only option I have found (that is straight forward) is using the borderware client from NEC - you can use it to sockify your ssh2.
Anthony http://nexus.dacomtech.com/abarker.html
How to tunnel through a firewall using SSH (Score:1)
One of my coworkers wrote up the following. He explains it very clearly, so I'll just post it verbatim. Enjoy!
Quoted message follows.
I got an interesting reply from Richard Silverman, who appears to do
work on SSH.
I figured that you guys might find this interesting, especially if you
are trying to set up a tunnel from home.
We thought we had it down, but NO! There is a better way!
Here's what we are trying to overcome, basically. AAA (home machine)
can see FFF (the firewall machine) but not BBB (the CVS server, or another
machine in the internal network).
AAA <--> FFF <--> BBB
We can tunnel into BBB from AAA using SSH using two tunnels, and that is
what I have been doing. Like this:
AAA ==1== FFF ==2== BBB
And we set it up something like this:
STEP 1: AAA% ssh -L 2401:localhost:5000 FFF
STEP 2: FFF% ssh -L 5000:localhost:2401 BBB
What this does is the following:
STEP 1) AAA === FFF <>
Note the loop (<>): FFF forwards all connections from AAA:2401 to
itself:5000. The SSH tunnel is actually the login itself, and any
traffic hitting port 2401 on AAA will pass straight through the tunnel,
coming out on FFF, which then forwards that traffic to itself, port
5000. Hence the 2401:localhost:5000 (the hostname is relevant to the
end of the tunnel, not the beginning of the tunnel).
STEP 2) FFF === BBB <>
Again, note the loop: The tunnel is now setup from FFF to BBB (the SSH
login) and BBB forwards all appropriate connections to itself:2401. So,
for all intents and purposes, if we access CVS as though it was on AAA,
it will really get it as though we were sitting at BBB.
This scenario presents a problem. The tunnel on FFF is wide open to
anyone to use, provided that they are actually ON FFF. There are
probably ways around this, but what, for example, if someone tries to
forward the same port once they have logged in to FFF? Further, what if
FFF is cracked and the tunnel is open? Problems for everyone.
Anyway, there is a way to do it that makes the tunnel secure from one
end to the other, with no loose ends hanging about and no possibility of
port conflicts in the middle:
# Log in to FFF (creating a tunnel from AAA to FFF)
# Forward all connections from AAA:7000 to BBB:22
# (a tunnelled SSL connection)
AAA% ssh -L 7000:BBB:22 FFF
# Now login to BBB by ssh'ing to localhost port 7000, and
# forward the port (to itself -- BBB could also be localhost):
AAA% ssh -L 2401:BBB:2401 -p 7000 localhost
This way the tunnel looks like this:
AAA---FFF BBB
AAA=======BBB
AAA---FFF BBB
Does that make sense? We now have a secure tunnel from AAA to FFF (the
--- marks), with connections on AAA:7000 being sent through the
tunnel, then forwarded to BBB:22, which is waiting to receive SSH
connections.
Then, we simply login to localhost port 7000 (from AAA!), which has the
effect of logging in to BBB (the === marks) over a standard SSH
connection. While we're at it, we forward the localhost port 2401 to be
BBB:2401. Now we have a TRULY secure tunnel from end-to-end that nobody
else can use! So, CVS connections destined for localhost on AAA will
actually get forwarded in a secure fashion all the way to BBB. I think
that's pretty darn cool.
Additionally, we are not compromising the server anymore than it was
before, because NO EXTRA PORTS have been opened on FFF. FFF just takes
the tail end of your SSH tunnel and forwards all of the appropriate
traffic to the SSH port on BBB. No extra ports open on FFF, and we
haven't really opened anything up on BBB, either. Everything is
connecting either to port 22 ( from the outside ) or to port 2401, from
the machine BBB itself! This means that we could actually disallow
connection to any port except SSH from outside of the machine, and still
gain access to all of its services.
Since the previous double-tunnel (outlined at
the beginning of this message) has this problem with port hijacking in
the middle, we should not use it anymore. Connections using secure
tunnels should be done in exactly the way that I have outlined. This
avoids potential security hazards and keeps us from treading on one
another's toes.
FecesOverHTTP (Score:1)
---------------
Re:They shouldn't let SSH out. (Score:2)
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.
Re:They shouldn't let SSH out. (Score:2)
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.
Re:Yes, but with SSH it's trivial. (Score:2)
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...
Re:The old fashioned way (Score:2)
You also want to make sure the username/password is sent over HTTPS.
Re:port 54522 - port 22 (Score:2)
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.
Re:They shouldn't let SSH out. (Score:2)
>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..
Re:The old fashioned way (Score:2)
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.
Re:They shouldn't let SSH out. (Score:2)
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.
Re:The old fashioned way (Score:2)
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.
port 54522 - port 22 (Score:2)
Have port 54522 portforward to 10.0.0.etc:22.
(Or did I miss the point?)
The old fashioned way (Score:2)
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,
Re:They shouldn't let SSH out. (Score:3)
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.
They shouldn't let SSH out. (Score:3)
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.
SSH can be acceptable... (Score:3)
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. :)
Re:They shouldn't let SSH out. (Score:3)
No. Its not. I helped write it.
>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.
No, thats why I want to use a tunnel. It will be less obtrusive. If i were to open a port, anyone could use it, and we would have to monitor it continuously.
With a tunnel, the likelihood of someone else in the company doing the same thing is VERY low.
>. 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.
My group wrote the policy! I provided the risk lists that ended up with the rulesets we have, and I stand by them. However, I need a legitimate way through.
Try reading the full question before flaming. There *is* a legitimate need, and *we* cannot/will not open the ports. The solution is a tunnel, which is what I asked about here.
A couple of suggestions (Score:4)
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
proxy (Score:4)
Not all that different from an application level proxy really.
Simple - tunnel via https (Score:5)
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 [snurgle.org] (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.