[WEB SECURITY] Securing apache installation with PHP

Ryan Barnett rcbarnett at gmail.com
Mon May 23 10:33:58 EDT 2005


Uh-oh, here we go again...  Look I haven't heard anyone say that you
should ONLY alter Server banners and NOT harden your configurations
(patching, etc...).  Why is it that anytime someone mentions an
obscurity technique, people always assume that that is the only
security measure that you are implementing?

I woud disagree with your assessment of the security gain being almore
zero.  Web-based worms such as Scalper and Slammer did in fact inspect
the returned Server token banner.  Here is an example of running some
SSL exploit code against a vulnerable Apache server with an obfuscated
banner -

# ./apache-ssl-bug -t 0 192.168.145.100
Apache & OpenSSL 0.9.6 Exploit
Made by andy^ after the bugtraq.c worm
Trying to exploit 192.168.145.100
The web server is not Apache
FAILED  

I am a strong proponent of "Security With Obscurity."  Applying
security and obfuscation settings are not mutually exclusive, however
they should be applied in a linear fashion meaning apply ALL security
settings first and then move onto obfuscation.  If you switch the
ordering, you are in trouble...  I think that this is the problem. 
Most people will jump to the obfuscation techniques because they are a
bit "sexier" that other tasks.

-- 
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GCUX, GSEC


On 5/23/05, Bernhard Nießl <bernhard.niessl at gmx.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> On 19 May 2005 at 8:34, Peter Motykowski wrote:
> 
> > No need to hand out more info than needed!
> 
> Right, but that's not a matter of security, but only a matter of
> bandwidth.
> 
> So you cool guys have obfuscated the output of good ol' Apache to
> something similar to "<AnyVendor> <AnyProduct>". Fine. If you didn't
> replace the security holes of the Webserver, either IIS or Apache or
> anything else, the gain of security is very close to zero. What
> should a 37331 script kid restrain from starting any kind of attack,
> be it IIS-specific or Apache-specific? The attacker does simply not
> care of the server token presented!
> 
> Result:
> you only increased the server load, and the attacker wins the war,
> because you fought the wrong battle ...
> 
> Security by obscurity does not work. PERIOD.
> 
> 
> 
> Regards
> Bernhard Niessl
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (MingW32)
> 
> iQEVAwUBQpHZIaJiaNdddTN1AQGqdwf/T7dbMJkypfBzkSlV14EVWzoqvdlTFXOW
> q2Bst4xIeqbxxgqr08nD1t+jIu0GJdPr4RKQPsvZ74MBXCSk3FvaOv/qGpyJBP09
> FKvtaPzNkYdM589KeTbC5Zne242SF8q3bnLShWZQHXk+BNIGqwNljxutdCpZPT3D
> VXqx+zFJwIRDvrPpVPtWPCVQ7/bJ7jdHMR5j0ODdxekBDPi4UHwI5W6s0GvLRpSD
> mSs4h4nVIB9uYHR4VpOCa+QM33f/518vb1p9cnSsNAOsF0LaY6keaPi5j+Szf+17
> lojKrBDbzRgMuyJY5lM8qZYJ9CBO1ccGLtx+IG0gkfHpRmOSUmsugw==
> =FdXI
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> The Web Security Mailing List
> http://www.webappsec.org/lists/websecurity/
> 
> The Web Security Mailing List Archives
> http://www.webappsec.org/lists/websecurity/archive/
> 
>

---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/



More information about the websecurity mailing list