> 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 :) _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
