RE: securing DB access from the DMZ

["Scott, Richard" <Richard.Scott () BestBuy com>]

See Inline:

Richard Scott
INFORMATION SECURITY
Fax: (001) -952-996-4830
Best Buy World Headquarters
7075 Flying Cloud Drive
Eden Prairie, MN 55344 USA

The views expressed in this email do not represent Best Buy
or any of its subsidiaries



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.

This is a huge issue with so called e-commerce.  I recommend, when possible,
to separate the application doing the data work with the web server.  
I have even seen sites where the application server is firewalled preventing
a compromised web server to be restricted to attacking an application server
before attempting to get access to the data.  I know that this model is
looked upon from some architects as over kill.  Some App servers do not
respond or perform well with a firewall in between them and the web server.

The fact that the web server has access to the SQL server directly must be
create some concern and adequate measures must be taken.  
I have seen far too often that the only AC on accessing the database was in
fact the connection string security parameters.


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.

Exactly where does an architect draw the line.  If you compromise the web
server, irrespective of firewall you could attack the certain sections of
the database server.  More often than not more protocols are allowed against
a DB server that isn't hardened.  What about replication and management
protocols.  So how much separation can one get before they get to over kill
and manage-less DMZ's?


> 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 prefer to have separate firewalls, one for the external perimeter and one
for the internal DMZ.  This saves administration of outer firewalls and
concentrates and cleanly setting up firewalls with more difficult rulesets.

> 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.
I agree.

> 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.


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.

Here here!  I agree.  I would also recommend looking at how you the
application itself connects to the database, more so I bet connection string
security credentials are either hard coded or stored in an insecure place.
Make sure that if the web server is compromised that it takes a lot of
effort to obtain RPC / ODBC / et al access to the database server.  Part of
the design of the application would be to ensure that data pulled from the
database, the mechanism used shouldn't be exploitable.  In that sense I mean
one should be able to use a generic connection string to obtain credit card
data.  Segregation of access to tables within the application is beneficial,
but you may not have the option at looking in to this that deeply.

Look for ACL on routers and how they can prevent certain access to resources
such as database servers.  

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.

;-)


Cheers
r.



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