Multiple non-http services, 1 static IP

Question

I have an issue where we have several non-http(s) services which we would like to access from across the WAN. SSH is a primary protocol we'd be using, FTP as well.

Here's how things are laid out. We have a single public IP address. That address is on our ASA (5505 base license) which is natted to a server in our DMZ. This is a windows server 2012 machine which, right now is running IIS services to perform reverse-proxy to our HTTP and HTTPS services.

What is the best way to securely allow external access to services like SSH/FTP? Is there a (preferably free) Linux equivalent to ISA server/Threat Management Gateway 2010 (neither of which I have available as options)

I know I can use a NAT function from the ASA to forward ports directly to machines but that doesn't seem as secure. Ideally I'd like to be able to create DNS A records (like ftp.domain.com) which point to the static IP, get routed to the DMZ (as things currently do) and then have it identify the type of request and forward it to the right host? Can this be done with IPTables in linux perhaps?

Thanks for ANY help!

Answer 1

Identifying the type of request and forwarding it based on that cannot be done at the TCP level. By the time your gateway need to decide which host to NAT it to, the request has not been sent yet.

On the application layer, you have more possibilities. This will be protocol dependent and is only possible for some protocols. An HTTP proxy is one example doing this.

That approach is completely impossible to apply to SSH. This is the case due to SSH clients usually not sending any data until they hear something from the server. Which means even at the application layer, you haven't seen the information you need by the time you need to pick a backend. The fact that SSH communication is encrypted and authenticated only makes this even harder.

The options I know of to make this work are:

• Use different port numbers for the different SSH servers
• Use IPv6 so you have enough IP addresses for each host
• Encapsulate the SSH traffic in another protocol. This could be SSH inside SSH by using a bastion host.

As far as FTP goes, my recommendation is to not use that protocol. The two separate TCP connections used by FTP makes it more difficult to get working. And the lack of integrity check in the protocol means it isn't very secure. I recommend sftp (which is similar to ftp but runs over ssh), or HTTP in case you need anonymous access.

Answer 2

There are several tools that handle threat management at different levels (most of them reactive because, being an encrypted protocol, it is hard to see anything until it is written in the logs). SSH is, generally, a secure protocol on its own if configured correctly. I am usually advocating AGAINST letting SSH open to the Internet unless absolutely necessary. Even in that case, having something like a secure URL where you can login and temporarily whitelist your current IP is a good alternative. Nowadays there are sooo many bots scanning vulnerable SSH machines and you never know when a new vulnerability appears in any application.

As to FTP, IMNSHO, DO NOT USE IT!!! Rather use its SSH based alternative, SFTP. FTP is a protocol where even passwords normally get sent via clear text, together with all the data. It has been a long time now since I stopped ever even considering FTP as an alternative for pretty much anything at all.