Threat Level: green Handler on Duty: Manuel Humberto Santander Pelaez

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Web Application Firewalls (WAF) - Have you deployed WAF technology?

Published: 2009-01-12
Last Updated: 2009-01-13 15:16:06 UTC
by William Salusky (Version: 1)
2 comment(s)
  • What is WAF?

If your first response to the subject is "What is a Web Application Firewall?", Apologies but I respectfully defer you to the OWASP team who has a great definition posted at: [http://www.owasp.org/index.php/Web_Application_Firewall].  For those who would like extended reading material into the subject of WAF technologies, refer to: [http://www.webappsec.org/projects/wafec/].

  • PCI and WAF

Opinion: Growth in the Web Application Firewall space may be attributed somewhat to changes in the Payment Card Industry's (PCI) Data Security Standard [https://www.pcisecuritystandards.org] where integration of an "Application layer firewall" [legacy term] or "Web Application firewall" technology previously listed as 'best practice' had been modified mid-2008 to become a requirement.  WAF technology is now required tooling in the protection of public facing web applications especially where hosts are determined to be financially significant or financial data [credit card detail] is processed.

  • WAF geeks unite and take over?

I consider myself a geek in the art of WAF and place tremendous value on the visibility I gain into HTTP client traffic.  I depend on client traffic visibility for threat/abuse discovery purposes combined with the mitigation capability afforded by WAF for the gratuitous stomping out badness.  HTTP traffic visibility may seem trivial, until you contemplate the impossible if not an extreme PITA this becomes especially when HTTP services are SSL enabled.  The deployment of traditional IDS sniffer mode detection capabilities are no longer suitable for identifying HTTP borne threats within SSL enabled web applications [aside from a few SSL negotiation flaws ;)] without significant expense and the operational changes required to enable IDS sensors with SSL payload visibility. 

Speaking from personal experience, I am a huge fan of ModSecurity [http://www.modsecurity.org].  ModSecurity while open-source is specific to Apache, and covers the lions share of web apps that I have responsibility in protecting.  I do try to keep my eyes open for equivalent technologies that extend to other web server technology deployments where the underlying web server choice cannot be migrated for various reasons.  While I have experimented with ModSecurity in reverse proxy mode to protect IIS and other server product hosted web services and web apps, I have a mix of IIS services that depend on Microsoft's URLScan filter to provide a subset of equivalent ModSecurity functionality.  I have recently been turned onto to another open-source WAF named 'WebKnight' for Microsoft IIS server deployment.  Based on available documentation it provides functionality that goes beyond basic URLScan features.  However, my recent fifteen minute experiment in deploying WebKnight to a test environment was unsuccessful (I myself must RTFM), though I do plan on giving it proper evaluation time in the near future.

  • Share your experiences with WAF

I am most interested in hearing from readers on their experience with WAF technologies, whether they be open or commercial.  I'm keenly interested in constructive product opinions, alternate solutions for server technologies not mentioned, your lessons learned, pitfalls or any success stories you are willing to share.  If you happen to be doing something particularly exciting or know of other projects in the web application protection space that deserve attention, please share!  Pending reader response, results may be posted to a future diary.

  • WAF Links:

ModSecurity : [http://www.modsecurity.org]
IIS UrlScan   : [http://www.microsoft.com/downloads/details.aspx?FamilyId=EE41818F-3363-4E24-9940-321603531989&displaylang=en]
WebKnight   : [http://www.aqtronix.com/?PageID=99]

 

Apologies in advance to all who like clickable URLs in their articles.  It is my bit in avoiding the reinforcement of poor client user practices.

William Salusky
Handler on Duty - :)
 

2 comment(s)

Downadup / Conficker - MS08-067 exploit and Windows domain account lockout

Published: 2009-01-12
Last Updated: 2009-01-12 22:43:54 UTC
by William Salusky (Version: 1)
0 comment(s)

The storm center handlers mailbox has received a growing number of email inquiries regarding root cause for Windows domain account lockouts which we most likely attribute to the infection base of Downadup/Conficker malware variants.  Downadup/Conficker malware (actual naming is dependant upon your AV product) due to the integration of exploit code for the (MS08-067) RPC service vulnerability, if present on even a single host within any private network may quickly result in mass domain account lock outs where failed password attempt policies are in force.

FYI, Recent handler diaries related to Downadup/Conficker malware have been published by fellow handlers Lenny Zeltser: [http://isc.sans.org/diary.html?storyid=5653], and Patrick Nolan: [http://isc.sans.org/diary.html?storyid=5401].


On the note of proactive mitigations, F-Secure has published a blog today detailing a list of Downadup domains that have been determined will be leveraged *this week* by ongoing Downadup infections at: [http://www.f-secure.com/weblog/archives/00001578.html].  The F-Secure published host/domain blocklist is available directly via: [http://www.f-secure.com/weblog/archives/downadup_domain_blocklist_13_16.txt].  For additional technical background on Downadup malware, F-Secure malware detail is published at: [http://www.f-secure.com/v-descs/worm_w32_downadup_al.shtml].

The F-Secure published pre-emptive host block list was also referenced by [http://malwaredomains.com/?p=353].  This domain list makes an excellent candidate list for inclusion in blacklisting efforts by any organization who applies DNS based blocking/protective mechanisms in the attempt to prevent access to known malicious hosting/sites.

* The unique IP list (based on currently resolving hostnames from the F-Secure list) point to a mix of the following addresses and may change before this threat 'goes live'. 

ASN     |  IP Address      | AS Name
3561    | 64.70.19.33      | SAVVIS - Savvis
9120    | 212.97.133.21    | COHAESIONET Cohaesio A/S
10228   | 202.165.98.232   | YAHOO-CN Internet Content Provider
20860   | 62.233.121.61    | IOMART-AS Iomart Hosting Network Services
24940   | 78.46.64.140     | HETZNER-AS Hetzner Online AG RZ-Nuernberg
40142   | 24.240.195.100   | BGP1-AMP-TECHNOLOGY - Amp Technology, LLC

IP based blocking measures should be considered very carefully as blocking host IP targets may introduce collateral damage where access to legitimate sites can be blocked if mass virtual hosting services are leveraged as temporary pointers by the Downadup/Conficker host list.  The Yahoo business hosting VIP above is a prime example of where collateral damage by IP based blocking would be encountered.

William Salusky
Handler on Duty - ;)
 

0 comment(s)
Diary Archives