Webserver port tunneling security - security options

Question

I'm developing system that allows access to client devices behind firewall, using port tunneling via SSH. Every client has dedicated linux based server, with port 80 being tunneled to public server. That way client's can have dynamic IP address and firewall enabled, no port forwarding on router is needed.

Every client has it's own port, eg.

• Client A -> port 8888
• Client B -> port 8889
• Client C -> port 8890

They can connect from anywhere to their own webserver simply by calling http://mypublicserver.com:[their_assigned_port_no]

I can see some security issues, tho.

1. Attacker can simply scan http://mypublicserver.com ports (65k of them) and get number of clients currently connected
2. Having that, perform any attack on their login screen, DOS their machine, try accessing PhpMyAdmin, brute-force etc.

There is also a limitation, as I cannot assign more than ~60k clients... It isn't a problem at the moment as I don't expect to hit more than 10k of them. Still, having to guess port number is not hard at all. It is also prone to mistype, somebody might be trying to login with his own credentials into somebody else machine because he typed 8989 instead of 8898.

As a defence, I thought of additional string value (hash or something) sent with login page request. If it is missing or incorrect - return 404. That way you can't get to login page if you don't know the string value, but it makes it almost impossible to get without having this site bookmarked, because short string would be easier to remember, but also easier to crack.

Another way (and this is currently my favourite one) is to login via web interface of http://mypublicserver.com. You login with other set of credentials which redirects you to http://mypublicserver.com with authentication key (stored inside mypublicserver's database) sent as POST data. After succesfull login key is invalidated, generated new and sent to mypublicserver from the client's webserver.

But this also means a need to remember 2 sets of login-password, probably leading to confusion ("Why do I need to login twice?!")

I have already:

• changed default location of phpmyadmin
• introduced account lock with more than 10 failed login attempts

What do you think of that? Did I miss something important? How can I secure that system?

Answer 1

I'm afraid that you have already failed at the first hurdle since you are using HTTP everywhere. This means that you are pushing unencrypted login traffic over the Internet which is subject to interception and misuse. You must have HTTPS at least from the client to the edge server.

You also haven't taken into account denial of service attacks though you haven't said whether you think that important. If all of the services are on guessable ports, an attacker can simply start streaming traffic to those.

Using multiple ports also makes it hard for clients to connect when behind a firewall. I'd recommend using a reverse proxy at the edge of your server network. That can both be the HTTPS terminator, load balancer (if needed) and can be made to redirect URL's to the appropriate back-end services.

On the front-end, clients should use a folder to identify their origin:

https://myserver.com/servicea
https://myserver.com/serviceb
etc.

The reverse proxy can redirect those to the correct back-end ports.

You don't need anything clever with ids/passwords though if you wanted to tighten things up further, you could use the reverse proxy or a firewall at the server end to restrict connections by source IP address.

Answer 2

This should be a comment - but its a bit long.

I'm struggling to decode your description of the problem. I think you're trying to say that you have a large number of web servers behind a firewall which you want to permit restricted access to via a gateway device exposed on the internet.

I'm guessing that the origin webservers don't have unique public IP addresses, and hence they are ssh clients to the gateway device.

Sorry, but I think this is a bad design and if you want to solve these problems you need to backup a bit. Even if scalability is not an issue, you've already run into limitations with how you route information to the back end, and its probably rather fragile.

I would configure the gateway device as a transparent forward HTTP proxy requiring authentication connecting to a VPN. The other end of VPN would be within the protected network at a secondary proxy capable of content based routing. In this model, you can provide a single SSL certificate at the gateway for all the access (you never mentioned SSL - this is pretty essential to be considered "secure"). You have the option of implementing the gateway authentication using various methods (via a cookie or NTLM or username and password) which could safely be cached by the clients.

Answer 3

You could deploy a VPN server connected to the webservers' LAN, and configure the webservers to only allow connection from the VPN:

Client -> VPN -> Proxy -> Webserver

Your clients only have one login and password, and nobody can connect to the webservers outside of VPN. And you can deploy HTTPS

You don't have to make a overcomplicated setup for this.