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: Firewall best practices (Lloyd, Mike)
2. Re: Firewall best practices (Fetch, Brandon)
3. Re: Firewall best practices (ArkanoiD)
4. Re: Firewall best practices (ArkanoiD)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Apr 2010 07:55:13 -0700 (PDT)
From: "Lloyd, Mike" <drmike@redseal.net>
Subject: Re: [fw-wiz] Firewall best practices
To: <firewall-wizards@listserv.icsalabs.com>
Message-ID: <049901cae6e2$cdcf1b20$696d5160$@net>
Content-Type: text/plain; charset="us-ascii"
Carson Gaspar wrote:
> Once upon a time I did some serious thinking about a signature based
> firewall, that cared only a little about port numbers, and a lot about
> packet content. It would necessarily involve an update cycle similar to
> anti-virus signature updates.
>
> I've seen some work on this, mostly from a traffic shaping / IPS / IDS
> slant, but I haven't seen anything serious from the firewall front. But
> then I haven't been doing firewalls for several years, so I may just be
> behind the times.
For a firewall thinking beyond the header, you may want to check out Palo
Alto - http://www.paloaltonetworks.com/
You never know, if you could record your serious thinking and send it back
in time a few years, you might be able to sue them retroactively :-)
For those of us still doing firewalls, it's an interesting evolution.
It's particularly useful to those of us who automate firewall analysis - a
whole new mountain of details to figure out, effectively a form of job
security for firewall wizards everywhere.
Mike
------------------------------
Message: 2
Date: Wed, 28 Apr 2010 09:11:42 -0500
From: "Fetch, Brandon" <bfetch@tpg.com>
Subject: Re: [fw-wiz] Firewall best practices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Cc: "mjr@ranum.com" <mjr@ranum.com>, Firewall Wizards Security Mailing
List <firewall-wizards@listserv.cybertrust.com>
Message-ID:
<A22AB7AA11C57342918639C100566F244E1FD3546C@TXMAIL.texpac.com>
Content-Type: text/plain; charset="us-ascii"
Sorry - read the paper. It boils down to included "already trusted CA's" on the browser and a complicit CA cooperating with a nefarious entity to issue another cert for a targeted domain.
The hardware device the paper refers to can have this cert installed and proceed to impersonate the targeted domain thus decrypting all traffic destined for that destination.
-----Original Message-----
From: firewall-wizards-bounces@listserv.icsalabs.com [mailto:firewall-wizards-bounces@listserv.icsalabs.com] On Behalf Of Cian Brennan
Sent: Wednesday, April 28, 2010 4:14 AM
To: Firewall Wizards Security Mailing List
Cc: mjr@ranum.com; Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] Firewall best practices
On Tue, Apr 27, 2010 at 11:12:40AM -0500, Fetch, Brandon wrote:
> Too late:
> http://files.cloudprivacy.net/ssl-mitm.pdf
>
> And these devices are already in deployment...now, imagine one of these with a wildcard certificate running at a coffee house, or at the aggregation point within a provider's CO POP...
>
Where it would generate cert errors for every user?
These only make sense where you can install the proxy's wildcard cert on all of
the client machines. Neither coffee houes, nor ISPs can do this.
> -----Original Message-----
> From: firewall-wizards-bounces@listserv.icsalabs.com [mailto:firewall-wizards-bounces@listserv.icsalabs.com] On Behalf Of John Morrison
> Sent: Tuesday, April 27, 2010 5:45 AM
> To: Firewall Wizards Security Mailing List
> Cc: mjr@ranum.com; Firewall Wizards Security Mailing List
> Subject: Re: [fw-wiz] Firewall best practices
>
> My understanding of https (and other PKI-based encryption) is that
> only the holder of the private key can decrypt the data encrypted with
> the other (public) key in the pair. My view is that the firewall can
> only decrypt and inspect https traffic if it is acting as the server
> to the external client. It can't intercept and decrypt https traffic
> destined for another device - the real server. If it did https would
> be worthless. Any hacker could buy such a firewall to sniff and
> decrypt all https traffic.
>
> On 23 April 2010 20:18, <david@lang.hm> wrote:
> > On Fri, 23 Apr 2010, Martin Barry wrote:
> >
> >> $quoted_author = "Marcus J. Ranum" ;
> >>>
> >>> That's why firewalls need to go back to doing what they
> >>> originally did, and parsing/analyzying the traffic that
> >>> flows through them, rather than "stateful packet
> >>> inspection" (which, as far as I can tell, means that
> >>> there's a state-table entry saying "I saw SYN!")
> >>
> >> Marcus, are you referring to DPI or proxies or both or something else
> >> entirely?
> >>
> >>
> >>> If the firewall doesn't understand the data it's passing,
> >>> it's not a firewall, it's a hub.
> >>
> >> If an application emulates HTTPS traffic and is proxy aware, how do you
> >> tell
> >> the difference?
> >
> > There are firewalls on the market that can decrypt HTTPS traffic (and I
> > believe be configured to block any traffic that they can't decrypt)
> >
> > David Lang
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards@listserv.icsalabs.com
> > https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> >
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
> This message is intended only for the person(s) to which it is addressed
> and may contain privileged, confidential and/or insider information..
> If you have received this communication in error, please notify us
> immediately by replying to the message and deleting it from your computer.
> Any disclosure, copying, distribution, or the taking of any action concerning
> the contents of this message and any attachment(s) by anyone other
> than the named recipient(s) is strictly prohibited.
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
--
--
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
This message is intended only for the person(s) to which it is addressed
and may contain privileged, confidential and/or insider information..
If you have received this communication in error, please notify us
immediately by replying to the message and deleting it from your computer.
Any disclosure, copying, distribution, or the taking of any action concerning
the contents of this message and any attachment(s) by anyone other
than the named recipient(s) is strictly prohibited.
------------------------------
Message: 3
Date: Wed, 28 Apr 2010 20:45:36 +0400
From: ArkanoiD <ark@eltex.net>
Subject: Re: [fw-wiz] Firewall best practices
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Cc: mjr@ranum.com
Message-ID: <20100428164536.GB5208@eltex.net>
Content-Type: text/plain; charset=koi8-r
There is one, and it is aggressively marketed as "next generation" firewall (again).
I was thinking about this idea as well, but found its practical value insufficient
to match the effort. Marketing hypes have little to do with practical value, though.
(another comment inline, scroll down ;-)
On Tue, Apr 27, 2010 at 04:41:04PM -0500, Carson Gaspar wrote:
> Once upon a time I did some serious thinking about a signature based
> firewall, that cared only a little about port numbers, and a lot about
> packet content. It would necessarily involve an update cycle similar to
> anti-virus signature updates.
>
> I've seen some work on this, mostly from a traffic shaping / IPS / IDS
> slant, but I haven't seen anything serious from the firewall front. But
> then I haven't been doing firewalls for several years, so I may just be
> behind the times.
>
> >You're completely right about the "if the application
> >emulates HTTPS traffic" problem. I don't have an answer
> >to that one other than "we warned everyone that that
> >was going to be a problem." At this point, it's less
> >of technical problem than a social one. It seems to me that
> >an organization cannot claim to be concerned about
> >security while allowing user-oriented encrypted outgoing
> >links to any target. That's just foolishness. The fact
> >that "everyone does it" doesn't make it any less foolish.
> >Back in the proxy days we advocated tying outgoing
> >connections to an authenticated user; that's another
> >important aspect of the problem that gets short shrift.
Well, we are already capable of inspecting web mail just like traditional
email messages (well, exactly. and it works both ways, so all limitations
apply)
> See my previous (or possibly next, post moderstion...) post re: SSL MITM
> proxies. Of course that just puts you back at the first problem, except
> you may detect rogue apps by their non-acceptance of your magic CA cert.
>
> --
> Carson
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@listserv.icsalabs.com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
> email protected and scanned by AdvascanTM - keeping email useful -
> www.advascan.com
>
------------------------------
Message: 4
Date: Wed, 28 Apr 2010 20:34:05 +0400
From: ArkanoiD <ark@eltex.net>
Subject: Re: [fw-wiz] Firewall best practices
To: mjr@ranum.com, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <20100428163405.GA5208@eltex.net>
Content-Type: text/plain; charset=koi8-r
fwtk's grand-child does exactly that: you inspect traffic from "low-security"
sites to treat it just like generic http and leave banking/online payment connections intact.
I am thinking on adding a feature to examine certificates to ensure its validity
without MITMing the SSL itself. Have you seen my paper? I think i posted a link here.
On Tue, Apr 27, 2010 at 03:31:47PM -0400, Marcus J. Ranum wrote:
>
> In Marcus-land the way we'd do it is have crypto that didn't
> suck, and firewall rules that permitted outgoing crypto only
> to (say, if online banking was an authorized activity during
> office hours) a set of supported sites. Yeah, yeah, I know,
> Marcus-land isn't a real place...
>
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 48, Issue 16
************************************************
No comments:
Post a Comment