Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
This group should mostly be dealing with how web applications enable networking security issues that are otherwise not there. Everything is being tunneled over port 80 now so what does that enable and how do we fix it? 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Web application firewalls
Posted by: rsnake
Date: September 01, 2006 08:00PM

I'm curious if anyone has had any interesting luck using web application firewalls. Thus far I haven't been super impressed by anything, but I'm curious to hear about more. Anyone have any unique (good or bad) experiences worth noting?

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Web application firewalls
Posted by: merliin
Date: September 18, 2006 04:24PM

Hi Rsnake!

I have successfully used mod_security to block certain attacks that should not be occuring in normal traffic, such as the %00 null value attacks on php.
I also have a few regexps to cut off automata bot attacks and SMTP injection which both have constants. I also filter out some basic basic XSS and SQL injection to deter the script kiddies.

I also protect the very limited amount of tools that are located inside the apache chroot and I filter output to prevent certain scripts from running even if they somehow managed to get on the server (via stolen ftp accounts or something else).
The I also have some basic output filter rules to prevent phishing sites from being operated the server.

I also use it to temporarily block recent exploits for web applications commonly used by the server's users until a patch becomes available or is widely implemented.

It is not fail safe, but it is another layer of security that makes it a little harder for a would be attacker. As long as you do not expect a be-all-end-all solution and use it in conjunction with all your other tools then it is useful. Lets face it, there aren't alot of options when it comes to protecting the "firwall bypass protocol" aka http(s).

MERLiiN
http://www.nastynerds.com



Edited 1 time(s). Last edit at 09/19/2006 03:21PM by merliin.

Options: ReplyQuote
Re: Web application firewalls
Posted by: rsnake
Date: September 18, 2006 05:52PM

I know Jeremiah Grossman is working on a system to define the "goodness" of auditing tools, I wonder if the same could be applied to web application firewalls. What I mean is, how much does including mod_security help. It may help some but how much exactly? For me and my personal needs it hinders me more than helps me, but I'm a unique case. It would be interesting to see exactly how many attacks these are actually stopping (that would be exploited if it weren't there).

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Web application firewalls
Posted by: merliin
Date: September 19, 2006 03:20PM

You know you can turn mod_security on/off through .htaccess if you have the matching AllowOverride?

In any event it really depends on the ruleset, I find that it is mostly useful for protecting against automated attacks and temporarily blocking new common exploits. You can make certain assumptions that could break the odd functionality, but most times having uname -a in the postdata or url is malicious. The same goes for %00.

Having said that it would be interresting to see a comparison between the various web application firewalls and perhaps web application firewalls against IPS solutions. I guess it comes down to who has the best ruleset in the end as there aren't alot of heuristics involved with web application firewalls.

Perhaps I should suggest it on the OWASP mailing list as I do not have the energy or patience to do this myself. (Anyone looking for a thesis paper idea?).

MERLiiN
http://www.nastynerds.com

Options: ReplyQuote
Re: Web application firewalls
Posted by: rsnake
Date: September 19, 2006 03:55PM

I've got too many ideas as it stands... Toooo many projects and too little time. I need two full time developers for months to get through all the projects I want to try out.

I wonder why these devices haven't gotten more integrated. It would seem like mod_security would have a leg up, although I still am not sure I like the implementation of it as it doesn't tie in well with firewall rules, databases etc...

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Web application firewalls
Posted by: kirke
Date: September 20, 2006 11:16AM

> You know you can turn mod_security on/off through .htaccess if you have the matching AllowOverride?

IIRC that's a known issue in mod_security < 2.0.
But if a security admin configures AllowOverride for such things, something else is basicly wrong ;-)

> .. comparison between the various web application firewalls ..
it's hard to do that. The WAF-TC tries to do something in that direction (rsnake, you should have seen this in the webappsec list:)
Also Arian Evans has left some comments there.
Conclusion: most people comparing products get more frustrated, as more they understands what attacks are possible.

> .. as there aren't alot of heuristics involved ..
hmm, some WAFs are really good here, just to mention AppShield (dead, sigh), I guess secureSPERE does it also not that bad.
Sometimes you don't need much heuristics, see how Airlock tries to do it.
Or they leave all the heuristics to the admins, as TrafficShield does.

> I wonder why these devices haven't gotten more integrated.
you mean WAFs? That's what I'm wondering too. But since the really good ones have been blown away, or taken over by companies more interrested in marketing gimmicks and share holder value, the remaining ones struggle against the lost reputation, IMHO.
Web application security is a process, not a product. Soome people know ...

Options: ReplyQuote
Re: Web application firewalls
Posted by: rsnake
Date: September 20, 2006 11:23AM

You liked AppShield, huh? I tried it once, and broke past it's most restrictive rule set in just a few minutes by following a path. I talked with one of the product managers for the product recently and he said that was a known issue they couldn't do much about at the time. As long as you made a path through the pages with multiple HTTP requests via CSRF it bypassed it's filter logic.

I dunno about that one. It did have some other interesting features, but I never felt like it really did a good job of "knowing" what a user was and what was and was not a valid request. That's why I think tighter integration makes more sense. mod_security + mod_auth_external + database + iptables + tcpdump seems closer to a real WAF than just a network shim and a plugin to Apache.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Web application firewalls
Posted by: kirke
Date: September 20, 2006 11:37AM

hmm, I didn't vote for one or the other, they all have their goods and bads.
According AppShield, it was really simple to configure (compared to most others in that time) and did most jobs as expected. As any software in universe, it had bugs.
If you disqualify any WAF which is buggy somehow, or misses a special feature, you never find one. You need some pragmatism in a world which lacks the perfect tools.

mod_security is a Apache plugin! iptables a network shim. So what's new if you combine them? or did I miss something in your post?
All solutions have their pros&cons, but I'd always prefer a standalone WAF as device/appliance.

Options: ReplyQuote
Re: Web application firewalls
Posted by: rsnake
Date: September 20, 2006 12:29PM

Really? You prefer stand alone devices? But that's lacking the integration with the actual application (knowing who a user is). I think that's not just flawed, it's missing most of what your application knows about the user state inherantly.

I wasn't dismissing AppShield because of a bug, I was saying it had a pretty major design flaw that rendered it useless if anyone went around it. It couldn't be fixed either the way it was designed. Ease of use isn't my primary interest (yes I am a consumer advocate, but in the security space, I think I'm willing to put up with a little more complexity for better security - since it is a security operations manager's job anyway). AppShield was okay, but I ended up opting for our own home build solution, that didn't have the holes.

Yes, mod_security and mod_auth_external are apache plugins, and yes, iptables is a network shim, and so is TCPDump basically. What you missed in my comment was the database tying them all together. Keeping them seperate or only looking at single connections and not knowing user states is ignoring most of what you know about your user. That's why I think stand alone appliances aren't super useful, except for detecting the dumb newbie attacks - which I'm not even sure constitutes the real threat to enterprises anyway.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Web application firewalls
Posted by: kirke
Date: September 20, 2006 01:08PM

> You prefer stand alone devices?
yes 'cause if you manage to break either, there is another step to get into the next device. It races the bar.

> .. lacking the integration ..
well, you can use Airlock for user integration, but is this really the job for a WAF? I doubt. Anyway, this prooves again that in a practical world you have to make different decisions on "what is best for my environment".

> .. put up with a little more complexity for better security ..
ok, then TrafficShield might be a commercial choice for you, or mod_security 2.x.

I don't get to your point where a WAF needs to know the user, though it's good to identify the user's sessions.

> .. constitutes the real threat to enterprises anyway ..
LOL, most of them have so muche holes that any WAF adds vulnerable protection.

My experiance tells me, that the WAF first needs to integrate simply in the existing network topology, then being reasonable managable, in finally protect something.
Unfortunatelly this sequence of priorities is insecure, but managers like it: they want a product to protect their enterprise after it's gone live.
Security is a process, not a product! Some people (managers) won't get that in their minds. I guess we all struggle with such simple-minded ...

Options: ReplyQuote
Re: Web application firewalls
Posted by: rsnake
Date: September 20, 2006 01:35PM

I think we're going to have to agree to disagree on most of these point, but one thing probably needs further thinking. When you asked what I meant by knowing things about the user there are dozens of potential things you can mine here.

Firstly, let's say you know that a user always comes from one IP range, isn't it interesting to know they are suddenly coming from a different IP range within seconds of being in the first? How about seeing the same cookie from two different IP addresses at the same time? How about seeing a user connect to a page, but not the images on it from a session that is clearly not a slow modem/or smart phone? How about seeing no referring URL on a sensitive function when previously the same user had referring URLs? How about knowing that the user is logged out but they are attempting to access a function that has no links to it? How about knowing the user speaks english but is using a german browser? How about knowing that the user always logs in between 4-6PM but suddenly they are logged in at 3AM?

This list could go on and on and on... I don't know how you could ever know most of this from an appliance because you don't know what a "user" is let alone what state they are in. All you know is that a session is active.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Web application firewalls
Posted by: kirke
Date: September 20, 2006 02:45PM

Agreed, as usual.
Have answers to all/most of your questions, should I post?

Options: ReplyQuote
Re: Web application firewalls
Posted by: rsnake
Date: September 20, 2006 03:06PM

Sure, if you have the answers. If you can know those things from a network appliance I'd be interested in knowing how without knowing a lot about how cookie structures work, without some way to hook into the backend.

Options: ReplyQuote
Re: Web application firewalls
Posted by: kirke
Date: September 21, 2006 02:17AM

ok, first let me explain that there are reasons to check all that what you asked for, but keep in mind that for web application security you have to change the view and start looking on the application layer. Most of your items are interresting to know, for statistical information for example, but they often cannot be used to detect/identify/inhibit attacks. For details see below.


> let's say you know that a user always comes from one IP range, isn't it interesting to know they are suddenly coming from a different IP range within seconds of being in the first?
If you have a closed group of user, and probably can control their sytem (browser, proxy, whatever), then this can be a valuable info. But in real world, for most enterprise applications, you have to deal with users going through proxies like aol, which might change the IP for each request.
It can be used, but it is vage.
And finally you miss another point, most likely to be found for enterprise applications: there is a complex network topology in front. Consisting of (network) firewalls, reverse proxies, load balancers, caching proxies, web servers and application servers. And more worse: all these in any combination you can image. In such an environment, you have to ensure that each device passes the original client IP to the final destination, somwhow. I doubt that this works.

> How about seeing the same cookie from two different IP addresses at the same time?
See above.

> How about seeing a user connect to a page, but not the images on it from a session that is clearly not a slow modem/or smart phone?
hmm, sorry, don't know what you mean.

> How about seeing no referring URL on a sensitive function when previously the same user had referring URLs?
Good point: the application (or WAF) tracks if a user/session uses a referer.
I. g. it could be a good idea to build a hash over the common HTTP request headers, somehow, and then compare it to other requests. It will be a more sophisticated function to do that, 'cause some of the information is volotile.
You'll get better identifications, but not a unique one.
Also keep in mind that the referrer may change or even be missing due to the application's states. This is something very close to the applications's workflow and hence hard to detect by an independent device (that's why you prefer integrated WAFs, probably).
Not talking about the useless referrer at all ('cause stripped off somewhere for various obvious reasons).

> How about knowing that the user is logged out but they are attempting to access a function that has no links to it?
This is a typical privilege escalation/expansion problem to be handled in the application. I don't see how a WAF should know about the user's status in the application's session.
Things are slightly different if you have something like SSO systems. If you're looking for that functionality in a WAF, it's there, more or less perfect. AppShield had some, AirLock is very good (hence they call it application security gateway, not really WAF).

> How about knowing the user speaks english but is using a german browser?
I do that all the time, this way, or the other way around ;-)
Back to the basics: don't trust any user input. This includes the HTTP request header, which can be faked, mangled, or whtever (think of proxies again).

> How about knowing that the user always logs in between 4-6PM but suddenly they are logged in at 3AM?
Statistic, heuristic, nothing really unique to detect/inhibit attacks.
Should be done by the application or authentication system.

> I don't know how you could ever know most of this from an appliance because you don't know what a "user" is let alone what state they are in. All you know is that a session is active.
That's it. Why should a WAF know about the application logic? Let it do the things it is supposed to do: detect and filter attacks.
If you try to do it the way Imperva does by analysing what "seems to be common" and build rules on that, you let the attacker in the first few times 'til the system (won't say WAF here) detects the anomalie and denies the request.
I won't say that systems trying to detect anomalies based on statistics are that bad, but it takes time *and* some requests 'til they learned.
A better approach would be to integrate the WAF in the web or application server. But if you do that, the WAF knows about the application somehow, then you can do it in the application code yourself, there is not much difference anymore.

A WAF can detect most known attack pattern/vectors, no problem. They also can detect the applications work flow, somwhow, limited (AppShield did it very good).
IMHO it will be very hard to configure a WAF to inhibit logical attacks on session. Leave that to the application. But sessions are a complex story, should be another thread here ...

Options: ReplyQuote
Re: Web application firewalls
Posted by: M4-io
Date: September 30, 2006 06:33PM

I don't have the answer to all of your questions but you might be interested in this 'solution' that might stop a hacker/cracker in it's tracks.

Like many of us I'm using mod_security to deny a lot of known bad requests to my scripts. Most scripts are open source gimmicks like phpBB which is one big security hole but popular by my (hosting)clients. I can't deny them installing phpBB and I can't babysit them by checking the vulnerabilities in phpBB every 3 seconds. So I have to be alert and patch the stuff as soon as I see hack-attempts or get alerted by some of my intrusion detection scripts. It's too late at that moment and they might have exploited the leak already.

mod_security basically gives a 404 back to the user if he tries something illegal. So far I didn't get many false warnings so I'm thinking about a little wrapper that will add the ip of the offender to my iptables (Linux) firewall. In that case mod_security will act as a tripwire and any probe using agents like perl/www , wget in his request or the endless list of known 'bad' ips will be blacklisted immediately.

So far my mod_security rules list has 90+ entries, 231 useragents and 7000+ ip's that cannot access any of my scripts.

99% of the bad requests are being detected based on the useragents and normal rules ; only a few requests are blocked based on ip's and those are often grey searchengines which are basically pretty harmless.

Options: ReplyQuote
Re: Web application firewalls
Posted by: id
Date: September 30, 2006 07:02PM

more of an annoyance type blocking, feel free to add the fuckers to your firewall rules too http://fu.ckers.org/fuckers.txt

A script updates it daily, and sometimes I just add users to it that my scripts don't catch.

-id

Options: ReplyQuote
Re: Web application firewalls
Posted by: merliin
Date: October 09, 2006 07:33PM

M4-io Wrote:
-------------------------------------------------------
> So far my mod_security rules list has 90+ entries,
> 231 useragents and 7000+ ip's that cannot access
> any of my scripts.

You might want to consider blocking IPs through another method than mod_security due to the overheads caused. Iptables, firewall, router or even the allow/deny directives. As Ivan has stated himself:
>Some ModSecurity users like to run really large rule sets, where the number of >rules runs into thousands. (No, I don't think ModSecurity should be used with such >large rule sets but I'll talk about that some other time.)

Quite likely most of the IPs you block are allready blockable through RBLs such as xbl.spamhaus.org, then again using RBLs will always involve some astigmatism.

MERLiiN

MERLiiN
http://www.nastynerds.com

Options: ReplyQuote


Sorry, only registered users may post in this forum.