From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: RE: SQL Slammer doing the rounds again?

"Jim Harrison (ISA)" <jmharr@...rosoft.com> replied to "Harlan Carvey" 
<keydet89@...oo.com>:

[corrected for top-postingitis]

> > While I fully agree w/ Jim's advice, one thing I'm
> > still curious about...since we first saw Slammer...is
> > this - Is there a valid business reason to expose UDP
> > 1434 to the Internet?
> > 
> > I've asked this before and not received any responses.
> > 
> > If anyone has one, I'd love to hear it.  Please
> > refrain from the "maybes"...I'd like to hear valid
> > reasons why this port is exposed.
> 
> The simple answer is, "if the web app is properly designed, coded and
> tested, there should be no reason to 'open a port' (apologies to TS) to
> the SQL from the Internet.

Isn't "should" kind of a "maybe"??   8-)

> <tirade>
> 
> Unfortunately, there are many folks who have queried the ISA newsgroups
> and other ISA lists about how (not why) to allow inbound SQL connections
> because many web designers haven't quite caught up to the idea that the
> Internet isn't the friendly little sandbox that they seem to believe it
> is.
> 
> Consequently, they deploy distributed web apps that expect to have
> direct access to a SQL server across whatever network they're installed
> in.  This often leaves the network admins with one choice; open external
> access to the SQL server.
> 
> While it's true that you can IP-restrict that traffic, there's also IP
> spoofing to contend with.  Many ISP's don't even apply the basic ACLs
> that any first-year Cisco intern would have been taught, causing the
> plethora of "I'm seeing spoof attack reports from 127.0.0.1" complaints
> from many new ISA admins.  If the upstream devices were properly
> configured, their firewall (app, appliance, monkeys & buckets, etc.)
> would never see this traffic in the first place.
> 
> </tirade>

Understood, but I suspect that in Harlan's terms what you have just 
described is not "a valid business reason".

"My developer is a petulant, ignorant brat" is not a valid business 
reason for doing something that is, from a security standpoint both 
chronically stupid and thoroughly indefensible.

The real problem here though is that the "petulant, ignorant brats" 
hold too much power.  They are (often) seen as "the experts" by the non-
technical "I just want an e-commerce solution that works" business folk 
whose expertise is making widgets not computer security.

Or the web designers may be seen as "creative geniuses" whose flashy, 
whizz-bang "design" would be compromised by even the suggestion from a 
mere mortal that some mundane, real-world consideration such as system 
security should be taken into account in the design.

And there may well be other common "do not upset the designer/ 
implementer" reasons others have come across.

This raises an intersting point for me though Jim -- which of those is 
the reason the MS web site as a whole, and the security-oriented parts 
of it in particular, are _entirely unusable_ for those who choose to 
vastly improve the security of their default MS-suplied web browser by 
disabling scripting?

Or, put in security terms, why does MS require its users to lower 
"reasonable" security standards just to use its web site?

Isn't that just like the web designers you have just ranted against 
expecting/requiring worldwide access to SQL servers?

Actually it isn't, as this arrogance of Microsoft's affects hugely more 
(as in many orders of magnitude more) folk...

> ..I feel better now...

Good -- maybe you'll be up to kicking some MS web-designer butt down 
the hall...

(Oh, and don't throw the "use trusted sites" thing back at me -- your 
employer has chosen to colo with Akamai which has already infected one 
of your web pages with Nimda, so we should trust "MS on Akamai" why?  
BTW, the ironic thing about this is that MS's security pages are _much_ 
easier to use with your competitor browsers...)


Regards,

Nick FitzGerald

Powered by blists - more mailing lists