04 December 2009

Firewalls

Posts relating to the category tag "firewalls" are listed below.

04 December 2009

WAF as a Marketing Tool?

I'd never thought about it, but on Wednesday at BeNeLux OWASP Day 2009, someone asked if a web application firewall could be used to provide "next generation" web analytics.

Photograph of directional signage to the lecture theatre at College De Valck, Leuven, Belgium where BeNeLux OWASP Day 2009 was being held

An interesting idea. Noa Bar-Yosef had been discussing how web application firewalls could be used to monitor valid business logic processing and attempt to deter or deny business attack bots. WAFs are a highly discussed topic and their merits are widely debated by information security professionals, but I don't think their use for gathering marketing data has ever been raised before (tell me if I'm wrong, please). The question was asked by a developer who was tired of adding third party JavaScript code in all his organisation's templates and links. This would also avoid the use of third party code and, with some more development and a good analysis system, be an alternative good selling point for a WAF. Who knows, the marketing departments may have a greater budget than the IT folk.

I enjoyed the whole event and found the lecture theatre a good location. I found Eoin Kerry's discussion of real world secure development, Sando Gauci's presentation of WafWoof and WafFun, and Prof. Dr. Ir. Bart Preneel's talk on the SHA-3 competition especially enlightening.

I'm looking forward to next year (and eating the Belgian chocolate from this year).

Posted on: 04 December 2009 at 19:48 hrs

Comments Comments (0) | Permalink | Send Send

29 September 2009

IP Address Restrictions and Exceptions

It's common for access to some web sites to be restricted to users from particular Internet Protocol (IP) addresses. This is usually in addition to some other identification and authentication method. But other IP addresses are often added to this "allow list" and these should not necessarily be trusted in the same way.

Photograph of a sign with an exclamation mark on a yellow triangle that reads 'Caution - Traffic management Trial - DO NOT MOVE' on a construction site boundary's wire barrier

In a typical scenario, a web site hosted on the internet that is used to administer another web application might be restricted to the company's own IP addresses. Then the developers say they need to check something on the live site, or another server needs to index the content, or someone wants to work from home for a while, or the site needs to be demonstrated at a client's location. All these additional IP addresses are added to the "allow list". These restrictions may be being applied at a network firewall, traffic management system, at the web server, in the application itself, in intrusion detection systems or in log analytical software, or in many of these. These are difficult to manage and in time there will be many IP addresses that no-one knows why they are allowed unless they are carefully documented, and subject to a fixed time limit when they are confirmed again by an appropriate person or removed. These extra addresses are quite often hard for someone else to guess.

However, there is another area where IP addresses are added to "allow lists", and this is for remote monitoring and testing services. These might be checking uptime, response times, content changes, HTML validation or security testing. The service providers publish the IP addresses of the source systems so that companies can specifically allow access to their web sites. Since the number of these services is relatively small, it's not too difficult to find which one might give access to areas of a web site or web application that the public (and malicious people) should not be able to get to. The particular danger here is that the IP addresses might be excluded from monitoring and logging, and therefore even a diligent web site manager might not realise for example the uptime monitoring service is making unusual, or excessive, requests.

Although it is not likely a malicious person is using this "trusted" address unless routing has been compromised as well, problems can go undetected, from what might seem to be a legitimate source. The IP address may have been typed incorrectly, or worse, the restrictions/exceptions may not have been implemented correctly allowing more addresses to have the privileged access than intended. Not logging a user's session is privileged access.

Allow traffic through, but be very specific what is allowed and monitor what's going on. Review all the exceptions periodically. Be especially careful about anything that bypasses authentication (such as allowing a search engine to crawl restricted-access content) on an otherwise public site.

Posted on: 29 September 2009 at 10:18 hrs

Comments Comments (0) | Permalink | Send Send

16 June 2009

FTP is not an Option

Many websites are updated using File Transfer Protocol (FTP). Don't do it.

A discussion thread How Do You Store FTP Login Information For Your Clients? highlighted what common practices are, but almost entirely missed the issues of transfer of login credentials over unencrypted channels, privileged access to the whole of the server, account sharing, password and user management.

... [I] also put the info in the client file folders (actual paper client folders) for future reference and sometimes in Outlook business Contact Manager...

It's no surprise that some of the most serious hacks are suspected of being undertaken using compromised FTP accounts.

FTP is not an option. Ask your hosting company or systems staff to disable FTP services and block all traffic to/from your web servers on TCP ports 20 and 21, at your network firewall.

Posted on: 16 June 2009 at 09:28 hrs

Comments Comments (0) | Permalink | Send Send

09 December 2008

Parameter Filtering

Last Thursday I attended the latest OWASP London meeting to hear two excellent speakers.

Justin and Adam from Gotham Digital Science presented demonstrations of a potential SQL injection worm and their Secure Parameter Filter (SPF) for IIS either side of a round-up from Dinis of the OWASP EU Summit 2008 outcomes.

SPF looks like a promising quick-patch tool for vulnerable web sites (written in any programming language) that are served by Microsoft Internet Information Server version 7 (IIS7) or could be served via an IIS7 proxy - if the site's written in ASP.NET, it's definitely worth serious consideration, even on IIS6. The main benefit is protection from tampering of parameter values, URL manipulation and replay attacks, combined with some blacklisting of cross-site attack code in user-supplied input. There are potentially some usability issues relating to restricting application entry points and having token time outs, but the tool of course needs to be configured to suit each site. Do take a look.

There are a pair of identical trial web sites available (from the page linked above) with and without the SPF tool installed - having seen the demo I'm looking forward to trying this on some test sites.

Posted on: 09 December 2008 at 09:49 hrs

Comments Comments (0) | Permalink | Send Send

Firewalls : Web Security, Usability and Design
http://www.clerkendweller.com/firewalls
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Page http://www.clerkendweller.com/firewalls
Requested by 38.107.191.116 on Friday, 12 March 2010 at 02:07 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2008-2010 clerkendweller.com