Re: Firewall best practices

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.

_______________________________________________
firewall-wizards mailing list
[email protected]
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

begin:vcard
fn:David Piscitello
n:Piscitello;David
adr;dom:;;3 Myrtle Bank Lane;Hilton Head;SC;29926
email;internet:[email protected]
x-mozilla-html:FALSE
url:http://hhi.corecom.com/weblogindex.htm
version:2.1
end:vcard