Client firewall blocks all ports but 80 and 443, need away to forward requets on port 443 to SSH or HTTPS

Question

Hi,

I am currently working at a client were they have locked down the network, except for ports 80 and 443. I need to connect to our server using SSH, but the same server also runs our website. We do not want to invest in a new server or place a second network card.

I have been searching the internet for away to setup our linux server (running CentOS 5), so that there is a daemon listening on port 443 that depending on the client protocol forwards the request to the correct internal port (SSH 22 or HTTPS moved to a differentport_.

There are a lot of people on internet looking for this kind solution, but no clear instructions how to do this.

Anyone have ideas/clear instructions how to do this?

Regards, nidkil

Answer 1

An easy solution to your problem might be to assign multiple IP addresses to your box and bind your SSH to port 443 on a separate IP; you can usually assign multiple IP addresses to a single adapter, no need to add a second network card. Otherwise I don't know of any out of the box solutions for what you want to do. You would probably have to create a custom daemon for that, which would be a little tricky but doable.

Answer 2

You could build a small web application listening on port 443 that enables a reverse SSH shell towards the IP of the incoming connection, using public key authentication. Say:

• You authenticate on the web application; the web application retrieves your IP
• The application starts a SSH tunnel from its IP to your IP (at port 22)
• The SSH server on your machine ends the tunnel and listens at localhost:8080
• Then, you start a SSH session with localhost:8080. The commands in the following interactive session are redirected to the remote host.

Answer 3

The firewall restrictions are in place for a reason. They may not be good ones, but they make sense to the person who implemented it or caused it to be implemented. I wouldn't attempt to violate the company policy on external connections.

If your need is legitimate, I would request that the port, or an alternate, be opened to the addresses you require. If that doesn't work then perhaps a VPN solution would be acceptable.

In the case where the network folks are just insanely protective, unwilling to respond to reason, or plain incompetent, I'd want to make sure I had sign-off from a manager who's willing to go to bat for me WHEN it becomes an issue before I implemented a work-around. Anything else could reasonably end up with your employment being terminated. After all, you are talking about violating a company security policy.

Answer 4

If you have apache on our centos box, you can use mod_proxy to redirect requests from one port to another. I use this to redirect requests to http://webmin.myserver.com to http://myserver.com:10000 (webmin running on an inaccessible port)

ServerName webmin.myserver.co.uk
SSLProxyEngine On

ProxyRequests Off
ProxyPass / https://myserver.co.uk:10000/
ProxyPassReverse / https://myserver.co.uk:10000/

Place the above in your virtual server directive, and you're good to go. This may not work with Putty, but if you install webmin it has a SSH module you can access via a browser.

Answer 5

sslh : http://www.rutschle.net/tech/sslh.shtml

I'm using 1.5; I haven't tried 1.6b yet, and 1.3 has a problem with leaving zombies around.

Run it on port 443; if no data is sent with 2 seconds (the default), it forwards to ssh. Otherwise, it forwards to your web server.

I'm running it on my website (http://mikeage.net) -- you can netcat in if you want to see both login banners.

In my case, it also has another purpose. We have an even more restrictive setup than you: all ports are blocked, but 80 and 443 can be reached via proxy. I can have SSH use a program like corkscrew (or putty natively) to proxy my SSH connection via the company proxy to my server:443, where after a brief delay, my SSH server responds with it's login banner. I can also serve webpages over the standard HTTPS (and do, in fact).