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 (Dave Piscitello)
2. Re: Firewall best practices (Cian Brennan)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Apr 2010 09:13:56 -0400
From: Dave Piscitello <dave@corecom.com>
Subject: Re: [fw-wiz] Firewall best practices
To: mjr@ranum.com, Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <4BD83494.1060408@corecom.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Marcus,
The problem isn't exclusively that SSL is MITMable: it's (broadly) the
lack of or limited clue when assessing risk. While SSL may be in your
terms crappy security, you can use it effectively enough so that you
aren't the low hanging fruit, and today, there is so much low hanging
fruit, effective security is pretty much reduced to creating the
perception that someone else is an easier target.
For example, in many scenarios where SSL is terminated at the firewall,
the firewall is the trusted party identified by the server certificate.
So the risk of trusting "the firewall" varies according to deployment.
Thus, if "the firewall" were an adapter on the emerchant/efinance server
hardware or a blade in a chassis also hosting the emerchant/efinance
server, risk will be entirely different from "the firewall" being an
appliance several LAN hops away from the server, several countries away
in the same virtual/cloud infrastructure, or sitting on a shelf behind a
teller at a bank.
Some folks actually consider these factors. In many cases they raise
themselves above the low hanging fruit. But that's pretty much where
the majority of "security vision" stops or stumbles. I'll give two
examples of why this is "fail". I'm sure others can chime in other
equally demoralizing examples...
1) Folks mostly consider server side infrastructure security when they
do risk and much of the badness occurs in clients. Man in the browser
malware like Zeus is much more of a problem than SSL MITMs and it's a
much easier attack. Threats of this sort are trivialized in risk
assessments that naively mandate desktop software security and
automating patches.
2) Many of the purportedly smarter folks use consumer-oriented
registrars or ISPs for domain registration, DNS hosting, and use dirt
cheap certificates that aren't worth the electrons you'd need to
transmit them. These are almost *never* considered in risk assessments.
Sorry for the ramble. But here's a homework assignment. Do a "search" on
"bank", then check WHOIS on the domains of a random set of financial
institutions returned in the search and you'll find a surprising number
of banks who register domain names through dirt cheap registrars
(hehe... check your own domains). Look at the client lock status of
these registered domains and you'll see most are vulnerable; worse, ask
the IT folks at these companies and few can tell you what security
measures the registrars implement and even fewer know how to lock domain
names so they can't be deleted or transferred, or so that their DNS
configurations can't be altered.
Marcus J. Ranum wrote:
> Harrell, Matthew wrote:
>> This then allows the firewall to scan the data in the packets[...]
>
> I have always been kind of mind-boggled that The Internet makes
> abundant use of such crappy security that it's so trivially
> susceptible to MITM attacks. And it boggles me further that many
> technologists invest in technology for doing exactly this, given
> that the expected reaction (years ago!) should have been "time
> to fix SSL!" not "oh, cool! a 'secure' socket layer that is
> trivially MITMable! how convenient!" If there's anything that
> gives us a real indication of where security sits on the trade-off
> scale between "nothing at all" and "utter crap" it's the SSL
> situation. I guess that having crypto that sucks so badly that
> it's breakable is easier than having to actually ask the question,
> "if we are 'concerned about data leakage' why are we allowing
> outbound encrypted tunnels?"
>
> 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...
>
> mjr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dave.vcf
Type: text/x-vcard
Size: 220 bytes
Desc: not available
URL: <https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20100428/5b889a83/attachment-0001.bin>
------------------------------
Message: 2
Date: Wed, 28 Apr 2010 09:13:46 +0100
From: Cian Brennan <cian.brennan@redbrick.dcu.ie>
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: <20100428081346.GA20997@morpheus.redbrick.dcu.ie>
Content-Type: text/plain; charset=us-ascii
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
End of firewall-wizards Digest, Vol 48, Issue 15
************************************************
No comments:
Post a Comment