firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: XML firewalls (WAF) (Chris Hughes)
----------------------------------------------------------------------
Message: 1
Date: Mon, 18 May 2009 14:40:01 -0400
From: "Chris Hughes" <chughes@l8c.com>
Subject: Re: [fw-wiz] XML firewalls (WAF)
To: <firewall-wizards@listserv.icsalabs.com>
Message-ID: <1C487244C6734FF98DA177C3D121CC0B@Acer>
Content-Type: text/plain; charset="us-ascii"
> After a reply to a previous post I was clued in on XML vulnerabilities
> with web applications. Off I went to do more reading when I discovered
WAF.
>> From what I read, the type of protection afforded by a WAF will
>> address some
> portion of the XML vulnerabilities for both internal as well as
> externally facing web applications. Now I'm left wondering which web
> based applications actually use XML or other mechanisms (SOAP) that are at
risk.
> I have a big MS SharePoint implementation that I'm particularly
> concerned about.
>
>
>
> Is there a way short of calling the vendors to see if they present the
> risk that WAF's allegedly help protect against?
this is similar to asking what applications have vunerabbilities that
regular firewalls could protect against.
most of the time if the application people knew they would fix the flaws
the problem is that http is being used as a network layer, so just like you
would not want to allow TCP everywhere without restriction you really
shouldn't allow http everywhere without restriction.
for some reason many people have trouble understanding this concept, but
what it really boils down to is that when you implement tunneling, you turn
the layer that you are using for tunneling into your transport layer, and
every piece of protection that you would normally put above the transport
layer needs to be implemented again above the tunneling.
so even if you have a top-notch firewall that does application layer checks
of the HTTP traffic, as soon as you start tunneling your application over it
you need to treat it as no better than a packet filtering firewall
(controlling the source and destination)
different WAF devices do different things, and on top of the device
capabilities, how good they can possibly be depends on how well you can
define (or understand) the legitimate traffic that you want to have go
through it.
if you have documentation of exactly what all your legitimate requests look
like, you can gain a lot of protection by having the WAF enforce these
restrictions (in theory this will add zero security because the application
already did a perfect job of checking it's input. however in the real world
this can be a significant win)
however, if you can't identify what legitimate traffic looks like, you will
have serious problems getting much benifit from a WAF. it doesn't mean that
you can't get any benifit, there are WAFs that try to watch the traffic and
guess what's 'normal' to configure themselves, but don't fall for the trap
of assuming that such devices aren't going to require understanding the
application (and tweaking the configuration) to get much use out of them.
David Lang
------------------------------
Sounds like to implement a WAF, I'll need someone who really understands the
xml calls between web hosts. On top of that I can see where development of
new applications will need central involvement of this same person. I don't
possess the knowledge of xml required for this so I'll have to look to one
of the programmers. This will be a tough sell. On the face of it, adding a
layer of security sounds good, but in these lean, understaffed times, it
will be hard to fill this order..
We are development heavy in integrated web apps. Securing this environment
burned me once before. Implementing HIDS on Webserver worked well, however,
the developers did not, even though they were instructed to, consult me when
making changes. The result was that they encountered problems and tried for
days to figure them out instead of calling me. Management freaked and
ordered all of the HIDS withdrawn from servers. I can see where a WAF will
require discipline that failed before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20090518/ea37188f/attachment-0001.html>
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 37, Issue 14
************************************************
No comments:
Post a Comment