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) (david@lang.hm)
2. Re: Cisco PIX - "Allow inbound IPsec sessions to bypass
interface access lists" (Eric Gearhart)
3. Re: Cisco PIX - "Allow inbound IPsec sessions to bypass
interface access lists" (Eric Gearhart)
----------------------------------------------------------------------
Message: 1
Date: Sun, 17 May 2009 02:18:34 -0700 (PDT)
From: david@lang.hm
Subject: Re: [fw-wiz] XML firewalls (WAF)
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <alpine.DEB.1.10.0905170159590.26653@asgard>
Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII
On Thu, 7 May 2009, Chris Hughes wrote:
> 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
------------------------------
Message: 2
Date: Sat, 16 May 2009 12:34:01 -0700
From: Eric Gearhart <eric@nixwizard.net>
Subject: Re: [fw-wiz] Cisco PIX - "Allow inbound IPsec sessions to
bypass interface access lists"
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<5792267e0905161234s23a4fe63qb0e622cf08bf960@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On the ASA, in ASDM there are connection profiles for each VPN tunnel
you setup. If you 'edit' the connection profile for the tunnel you're
trying to restrict, there's an "Advanced" dropdown. Under the advanced
dropdown, there's a 'Tunnel group."
Under that tunnel group, there's a "Default Group Policy"
------------------------------
Message: 3
Date: Sat, 16 May 2009 12:37:00 -0700
From: Eric Gearhart <eric@nixwizard.net>
Subject: Re: [fw-wiz] Cisco PIX - "Allow inbound IPsec sessions to
bypass interface access lists"
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<5792267e0905161237p76e4f334v4e064d54831ff3e7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Sorry I accidentally sent that last email prematurely... anyway under
"Default Group Policy" if you click manage there should be a
"DfltGrpPolicy." You can create your own custom Group Policy for this
tunnel, and specify a filter for this group policy. The filter you
select is just an extended access list, and your "source" is the
remote network from your VPN peer, "destination" is your local
networks on your local ASA.
Here's the obligatory Cisco link that explains all this:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9a87.shtml
--
Eric
http://nixwizard.net
------------------------------
_______________________________________________
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 13
************************************************
No comments:
Post a Comment