Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When running a public web server (e.g., with Apache), I've heard it's recommended to bind SSH to a second IP address, different from the one Apache is listening to.

But for me it seems like this is only a matter of obfuscation - once an attacker knows the second IP address, the situation would be the same as with a single IP address.

Am I right? Or are there any other benefits of using a second IP address except for obfuscation?

share|improve this question
2  
Unless you're talking about a honeypot I dont see the benefit – Purefan Feb 2 at 11:37
    
Look into port knocking. It is not as good as running ssh over an isolated network, but it is better than plain ssh when it comes to 0days – Navin Feb 3 at 16:11
up vote 40 down vote accepted

Unless that IP address belongs to a dedicated management network which implements additional security, it is a waste of resources.

Both IPs are, obviously, ending up on the same server. This means that, unless they come in through different networks (i.e. a management network that implements additional protection), there will be no difference locally between a connection to SSH going on one IP or the other: you can firewall these exactly in the same way (if you want) and it doesn't make any more or less obvious in the logs.

The only thing you're "hiding" is the relation between the SSH server and the web server and, unless you have very poor procedure for picking up account names, then it shouldn't matter.

If you're using a dedicated management network, however, it's a different matter: such a network could require all connections to go though a secure authentication phase and impose extra limitation on the conneting party (for instance, you can require them to be physically connected to the network, or go through a VPN requiring 2FA and making sure your client is "clean").

share|improve this answer
    
Hi @Stephane (+1) - could you explain why? For future onlookers, it would help if you could explain the idea behind the strategy, and then explain why that idea is flawed. – smeeb Feb 2 at 11:36
5  
Could you explain your comment "unless you have very poor procedure for picking up account names"? – gardenhead Feb 2 at 18:12
2  
If the account you use to connect to the SSH server is the name of the web site, putting both on the same IP address reveals that fact. It's not really a big issue since that shouldn't (in theory) weaken security – Stephane Feb 3 at 7:49

You are basically correct. It is obfuscation. Obfuscation is not without value, but you should not rely on it.

The first answer is correct, BTW, that it is good practice to host management services such as SSH on a separate network (i.e., not the internet).

share|improve this answer
    
An obscure port, port knocking and ssh on a separate IP all provide some obfuscation benefits. Obfuscation mainly has value in avoiding untargeted (automated scan) attacks. Moving ssh to another IP offers the least benefit in this regard since it will still be found on the default port by a range scan. Moving the port will be a bit more effective since fewer scans will cover a wide range of ports or these scans will hit fewer hosts per unit time. Port knocking will be most effective against untargeted attacks since scans would have to cover many ports and in a particular order to work. – Bell Feb 3 at 17:30
    
Well, there is one more benefit, which is that an attacker doesn't know that SSH service on IP x gives access to the server of, for example, web site y. When sshd and httpd are seen on the same IP, it's obviously the same machine. When the IP's differ, the attacker targeting site y won't know that the SSH daemon listening on IP x gives access to the same server. – Mark Koek Feb 4 at 11:51

It is a bit like moving SSH to a different port. You just hide something (poorly) and that shouldn't be something to rely the security of a system on. It might throw off the attackers that really don't know what they are doing (and they will not get into ssh anyway if it is setup properly) but is useless otherwise.

share|improve this answer

With fwknop deployed, anyone using nmap to look for SSHD can't even tell that it is listening - it makes no difference if they want to run a password cracker against SSHD or even if they have a 0-day exploit.

I have some notes here for using fwknop. I can also ssh into containers behind NAT with no port open externally.

share|improve this answer

I suppose a good question would be why do you even have SSH open to the WAN, anyway? ... As others have mentioned, administering via a private network is the Holy Grail.

The best approximation (and the reason I even bother to answer here) for a WAN connection is an IP wrapper or firewall ruleset that only allows SSH from a particular IP address. One such strategy is a dedicated SSH server that uses only key-based authentication (if necessary, from any IP address), and a WWW server that only accepts inbound SSH from said server's IP address. When an attacker has to guess, and then spoof, an IP address to get in, you have added a good layer of protection. That might be one application for your 2nd IP address ...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.