Hi, so let's sumarize: Secure your box first as good as you can, then hide your version using httpd.conf and then take care of all the other information that your apache spreads (headers, error-pages). But be asured that all the camouflage will almost certainly not hide you 100%, because there always more evidence (tcp-fingerprints (I've not yet seen an unix clone running IIS), php vs. asp pages (I know, there ist php for IIS, too, but....), etc.). Best regards, Ralf Ronneburger Boris Lorenz wrote:
Hi,
Ralf Ronneburger wrote:
Hi,
so it's security through obscurity again...
Lets assume there would be an exploit for apache. What would skript kiddies do, telnet apache first or just run the exploit against the all servers and see what happens? I'd guess for the second option (time-saving) and that's why I'd advice you to save your time compiling apache to hide the version and os, this information can almost always be gained in another way. Rather use that time to find out, how you can make your apache more secure (by en/disabiling modules, configuration etc.).
some pretty valid points there. Security through obscurity is never a good solution, and I agree with you that most script kiddies won't spend their time with version-/banner probes; if a system is inherently insecure, banner phogging would be futile in the first place.
However, like I already tried to point out in my reply to Yarrel, there are more types of aggressors against IT infrastructure, and some (most?) of them *do* conduct extensive banner probes, mostly supported by some nifty shell scripts. According to my experiences, these types of attackers don't want to loose time as well and primarily go for a worthy prey (i. e. against a system with a more obvious information leakage).
Lastly, I don't think that changing two lines in an Apache include before compiling the package is a very time-consuming task ;)
Just my 2 cent,
dito.
Ralf Ronneburger
Boris Lorenz
---