Re: securing DB access from the DMZ

[Ryan Russell <ryan () securityfocus com>]

On Wed, 20 Feb 2002 wasabi_pea () hushmail com wrote:

> The connection from the webserver to
> the switch makes me nervous.

Good.  That means you've got more clue than the previous guy. :)

> The former administrator wasn't concerned with the second NIC, and
> claimed that it was impossible for traffic to route from one NIC to the
> other.

Routing doesn't matter (though of course you can easily enable routing
on it.)  When someone compromises the IIS box, they just use it to attack
the DB.  No routing required.  It's probably even easier than that, simply
find a SQL injection hole in a server script, and take advantage of the
authentication and connection the web server has already to the DB server.

> I'm not sure I feel comfortable trusting that assumption to
> protect the database server from intrusion.

The current setup allows someone who has compromised the IIS server to
attack the underlying OS of the DB server.  That in combination with being
able to access the DB server port(s) gives the attacker twice as many
holes to choose from.  Fixing this design limits the attacker to just
hitting the DB port from the web server, if the firewall does its job.

> However, the former
> administrator like the solution so much he carried it out on all the
> servers in the DMZ, so that they could be administered without going
> into the server room.

So compromising any of the DMZ servers will let someone hit the DB server?
That design eliminates the usefulness of having 3 interfaces on the
firewall, and is equivalent to having a 2-interface firewall in front.
You don't have a DMZ, you've got all inside network.

> I'm considering alternative designs and solutions.  I think I'd like to
> cut the secondary connection to the switch and bring the database
> traffic back through the firewall to the inside network.

That's the usual minimum configuration.

> I'm also
> considering a second firewall to create a more secure zone for the
> database server and other important assets, like the Human Resources
> server.  That way I can further secure access to them from both external
> and internal users.

That would be ideal.

> Any other solutions or insights?  I'm particularly interested in hearing
> from others who have experience securing the Q-Up product and its
> database communications.

I can't speak to the Q-Up thing, but I used to do a fair amount of
DMZ-and-Database work.  If I will be permitted a minor plug, some of that
experience went into the book "Hack Proofing Your E-Commerce Site", but as
one of the authors I have a financial interest, so please look elsewhere
for whether the book is any good before you consider buying it.  Let me
give a quick version of some key points though:

You need to secure your IIS server, which includes all the usual stuff
like deleting sample scripts, disabling unneeded functionality, etc...
Micorosoft has put some tools out recently that go a long way towards
getting there.

You need to secure your BD server, which means making sure all the DB
users have minimum permissions, and that unnedded stored procedures are
removed.  Unfortunately, sometimes this isn't enough.  If the web server
absolutely has to be able to modify records, for example, then an attacker
will be able to as well.  Anything your web app can do, an attacker acting
as your web app can do, too.

Everyone harps on policy, but there is a reason.  You need to write a
policy that states all traffic to and from the DMZ machines must be
shunted through the firewall.  Get everyone to agree to it, and then you
have some basis for refusing to do it in the future after you clean up
this time.

                                        Ryan

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards