HoneyHeaders

[<rcbarnett () hushmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, perhaps this title is a bit cheesy, but with all the HoneyTokens
talk, I thought I would stick with the naming convention ;)

During some recent research into Web Server Fingerprinting and Countermeasures
(Hi Jeremiah!), I came up with some ideas for both obfuscating the server's
response headers, as well as, to incorporate some honeypot-esque headers.

I won't dive too deep into the security issues related to the HTTP Response
Headers (that would be for the WebAppSec List), but I can summarize it
quickly by saying that BlackHats can pretty easily identify web server
software by inspecting the servers reponse headers.  This goes beyond
simply looking at the "Server:" token.

I was speaking with Jeremiah Grossman of WhiteHat Security about this
issue and I am developing some countermeasures by manupulating the headers
returned by Apache.  I decided that instead of extensive source code
editing of Apache to try and emulate other webservers, I would rather
insert bogus headers to "simulate" a more complex network topology (I.E.-
 Make it appear that there is a Proxy Server, or two, and that the web
servers behind are iPlanet, IIS, etc...) to cause some confusion.  For
example, I have added in additional Apache HTTP Response Headers returned
to the clients such as:

**************************
Via: 1.1 squid.proxy.companyx.com (Squid/2.4.STABLE6), 1.1 devweb.companyx.com
X_FORWARDED_FOR: 192.168.1.103
**************************

These tokens are completely bogus.  The Via token is normally inserted
by Proxy servers to show the path that web clients take to get to a web
server.  Check out the Oreilly website for more information on TRACE/VIA
headers - http://www.oreilly.com/openbook/webclient/ch03.html

In the example above, it appears to the BlackHat that there are two Proxy
servers (One Squid Proxy and One called devweb) in front of the web server.
 The X_FORWARDED_FOR token is set by the first proxy server to specify
the original IP address.  I normally see these types of HTTP tokens when
investigating attacks on web servers and I am trying to track down the
intruder.  My thinking with adding in the headers was this - What if
I implement these headers and the X_FORWARDED_FOR IP Address is actually
a honeypot???  In addition to hiding our web infrastructure, we now also
have a method of steering would be attackers away from our production
server and to our honeypot.  The only people who should connect to the
honeypot web server (besides worms and automatic probes checking random
IP ranges) would be someone who was viewing the HTTP Response Headers
of our Apache server.

This may also help with the whole "rating your attacker" methodology,
 when investigating your web honeypot.  If the attacker gained knowledge
of your honeypot due to the HTTP Response Headers, then they are more
advanced than the Script Kiddie (only looking at the Server: Banner)
web attackers.

Well, this idea is brand new, so feedback is welcome.

Thanks,
###########################################
Ryan C. Barnett
Senior Security Engineer
Founder Honeypots: Monitoring and Forensics
SANS: GCFA, GCIH, GCUX, GSEC
###########################################

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.2 (Java)
Note: This signature can be verified at https://www.hushtools.com/verify

wl4EARECAB4FAj6NqlMXHHJjYmFybmV0dEBodXNobWFpbC5jb20ACgkQ0C5r6NXO9mI7
WgCgsXt+6BEl9QUQRz76+9xercCPGboAnRWfvvTWU3DLwXeZ5SUJ+R4LP32d
=3mqU
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2 

Big $$$ to be made with the HushMail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427