Message-ID: <00a401c3a2ec$9f8793f0$c71121c2@exchange.sharpuk.co.uk>
From: DaveHowe at cmn.sharp-uk.co.uk (Dave Howe)
Subject: Gates: 'You don't need perfect code' for good security 

> The SQL server doesn't have to be accessible to the Internet.  It
> only has to be accessible to those machines authorized to do
> authentication lookups.
True enough.

> There's reasons why 'best practices' call for a physically
> separate management network....
Unfortunately, this isn't an example of one. It can be considered
logically isolated (in that you must compromise the internet-facing box
before you can begin to attack the database) but there have been examples
before of worms that used one vunerability (bind, I think, for the example
I can recall most clearly, so fairly cross-platform) to get to a point
where more intrusive scanning (for vulnerable wintel boxes, again IIRC)
could take place without the firewall raising the alarm.
A slightly better scenario is to recognise that all connections between
the internet and an internal (dmz or shielded lan) host, and indeed from a
DMZ host to either shielded lan or internet, have both a passive and an
active end (this is familar enough to all firewall admins, and indeed
anyone who has had to work out how to get ftp to work :)
Any system where the "valuable" machine is the passive end of a tcp/ip
link is at least theoretically (and in too many cases actually)
vulnerable. Unfortunately, making the active end the internal host often
means resorting to polling (internal host connects regularly and pulls
queries from a passive "external" host, then pushes results back) which is
both inherently inefficient (given the vast majority of polls result in
"no work to do") and high-latency (incoming queries are processed, not
when received, but when polled for; assuming a five second polling cycle
and a one second "processing" latency - to do with file locking and making
the query available to incoming polls - you have a worst case delay of six
seconds *on top of* the time taken to actually transfer the query and
process it.)
physically separate management networks are inherently hard to set up - in
the ideal case, they consist of a single (direct) connection between the
management station and each managed machine, so no managed machine can
possibly contact another using that network and the management station can
only talk to managed servers, not the lan or under any circumstances the
internet.  In practice, this becomes unworkable above a few dozen (the
limit of a cost-justified switch to handle that many vlans and combine
them to a single host, plus of course for the host to have that many
virtual interfaces, ignoring any possible attacks on the switch or the
management station) and usually the best you can hope for is an
out-of-band administration channel, and a (physical) switch for when you
aren't using it :)

Powered by blists - more mailing lists