4 ms·

> especially in an age when running bots hitting every public facing piece of equipment is so cheap? For me exactly that is a reason to disable versions. If I

by nisa 14y ago

> especially in an age when running bots hitting every public facing piece of equipment is so cheap? For me exactly that is a reason to disable versions. If I would be the attacker I would probably do a SELECT hostname FROM scanresults WHERE webserver == vulnerable-version Besides that, a header like: Server: Apache/2.2.16 (Debian) DAV/2 SVN/1.6.12 PHP/5.3.19 mod_ssl/2.2.16 OpenSSL/0.9.8o X-Powered-By: PHP/5.3.19 ...gives me a lot of clues for adjusting my exploit payload. In practice it may be an obscure attack vector - who knows. But more information is always helping the attacker. If there is a database somewhere (it is) - I don't want to have my specific versions in there. Who knows that kind of exploit is on the HN frontpage tomorrow. "Security by Obscurity" is a concept used by bad cryptographic ciphers. See Kerckhoff's Principle. I don't see how this applies to server information disclosure.

mhurron 14y ago
Exploits that would 'need' to know the version are scripted. They spew the attempt anyway. If it works it works, if it doesn't the script moves on. You don't really get anything by disabling the server from reporting it's version. On the other hand, it doesn't take any time to do it. But don't think you gained anything by disabling it.
- themstheones 14y ago
  I suppose even a hypothetical expensive exploit (requiring ten minutes per attempt for example) would not deter someone with a large botnet from trying it against every server. So while hiding version info might save from some attackers in some scenarios it doesn't provide real protection.
- nisa 14y ago
  I did not wanted to say that disabling version information is a security measure. It is not. Sorry if I was not clear on that. I just wanted to say it may give you some time. That's debatable. You and others disagree. I remember an exploit for ProFTPd that required different payloads for different builds (OS, Version, Architecture). Having a database with version data und using that database would maximize the attackers chance to own the machine. Before checking the whole internet, why not at first try all machines where the exploit would work more likely. After that try all other machines. Another issue I remember was PLESK¹. They added some versions ago a Header "Powered-By Plesklin". There were a few PLESK exploits in the wild where an attacker with a database of versions and headers for services could quickly attack them. That is a reason for me to disable versions. It is totally unrelated to other security measures. I just don't want to give the attacker any additional clue. The more time he needs to spend probing my server the more time I have to notice him. I'm not sure how easy it is to order a botnet to execute an exploit for the whole internet. Other comments suggest it is no problem anymore. If that is indeed the case, it's probably really not relevant to disable versions or not. However I think I outlined my reasoning. 1: I know, don't use it. This was not up to me.
- bigiain 14y ago
  I suspect there's some small measure of protection still - if there's a brand new exploit available (say, the current WordPress W3 Total Cache and WP Super Cache problems), I'd rather not have my sites rise to the top of the list of addresses for the botnets to start probing - because I'd left the version information publicly available (or made those sites trivially findable via a googledork). It won't protect me, but it might buy be a little extra time to respond...
zalew 14y ago
> If I would be the attacker I would probably do a SELECT hostname FROM scanresults WHERE webserver == vulnerable-version you would suck. 1. write exploit 2. send exploit 3. a) it worked - pwned b) didn't work - safe against this exploit btw have you heard of security patches? > I don't see how this applies to server information disclosure. http://en.wikipedia.org/wiki/Secure_by_design http://en.wikipedia.org/wiki/Secure_by_design

by nisa 14y ago

mhurron 14y ago

Exploits that would 'need' to know the version are scripted. They spew the attempt anyway. If it works it works, if it doesn't the script moves on. You don't really get anything by disabling the server from reporting it's version. On the other hand, it doesn't take any time to do it. But don't think you gained anything by disabling it.

themstheones 14y ago
I suppose even a hypothetical expensive exploit (requiring ten minutes per attempt for example) would not deter someone with a large botnet from trying it against every server. So while hiding version info might save from some attackers in some scenarios it doesn't provide real protection.
nisa 14y ago
I did not wanted to say that disabling version information is a security measure. It is not. Sorry if I was not clear on that. I just wanted to say it may give you some time. That's debatable. You and others disagree. I remember an exploit for ProFTPd that required different payloads for different builds (OS, Version, Architecture). Having a database with version data und using that database would maximize the attackers chance to own the machine. Before checking the whole internet, why not at first try all machines where the exploit would work more likely. After that try all other machines. Another issue I remember was PLESK¹. They added some versions ago a Header "Powered-By Plesklin". There were a few PLESK exploits in the wild where an attacker with a database of versions and headers for services could quickly attack them. That is a reason for me to disable versions. It is totally unrelated to other security measures. I just don't want to give the attacker any additional clue. The more time he needs to spend probing my server the more time I have to notice him. I'm not sure how easy it is to order a botnet to execute an exploit for the whole internet. Other comments suggest it is no problem anymore. If that is indeed the case, it's probably really not relevant to disable versions or not. However I think I outlined my reasoning. 1: I know, don't use it. This was not up to me.
bigiain 14y ago
I suspect there's some small measure of protection still - if there's a brand new exploit available (say, the current WordPress W3 Total Cache and WP Super Cache problems), I'd rather not have my sites rise to the top of the list of addresses for the botnets to start probing - because I'd left the version information publicly available (or made those sites trivially findable via a googledork). It won't protect me, but it might buy be a little extra time to respond...

zalew 14y ago

> If I would be the attacker I would probably do a SELECT hostname FROM scanresults WHERE webserver == vulnerable-version you would suck. 1. write exploit 2. send exploit 3. a) it worked - pwned b) didn't work - safe against this exploit btw have you heard of security patches? > I don't see how this applies to server information disclosure. http://en.wikipedia.org/wiki/Secure_by_design http://en.wikipedia.org/wiki/Secure_by_design