RE: A few sql 2000 related questions

["Paul Melson" <psmelson () comcast net>]

Mike,

A1: Bindview is a decent tool, but it really depends what your goals for
monitoring are.  If you're trying to identify and/or prevent a compromise of
the server and its data, that is different than creating an audit trail for
accountability.

A2: It's probably not.  SQL Server can use SSL.  You can also use the MS
implementation of IPSec to encrypt traffic between two servers.  Either way,
I would double-check my configuration with tcpdump or something similar to
make sure the more secure transport method is being used.

Vyas Kondreddi has an excellent article on SQL Server security.  Anybody
interested in this topic, or even disinterested people tasked with
protecting MS-SQL databases should give it a read:
http://vyaskn.tripod.com/sql_server_security_best_practices.htm


Also, both of those proposed traffic/app flows have some major blind spots,
and I wouldn't pay the consultants who proposed them for the napkin they
wrote it on.  

First of all, and there is some debate on this, but I feel strongly that
network IDS/IPS has no place outside of a firewall.  I can go on for days
about reasons why this is, but the main reason is that it is a huge waste of
relatively expensive and limited personnel resources to make someone wade
through IDS reports on traffic that never enters the network.  That *is* why
the firewall is there, after all.  And yes, this will definitely impact the
overall security of the environment if you're trying to protect an
unfiltered baseline.

Second of all, has anyone accounted for how the IDS/IPS will analyze SSL
traffic?  I am only aware of two products that can do stream analysis of SSL
connections, and they require copies of all of the server certificates to do
so.  Still others do this by being the SSL endpoint and reverse proxy.  But
if the product in question doesn't do these things and/or isn't configured
to do them, you've wasted some $$ on an IDS/IPX box.

Third, I would need to hear the reasoning behind this, but I'm not sure why
you're using 'vpn' to pass traffic from one set of servers to another,
especially if traffic is (or at least can be) encrypted by the endpoints.
This isn't so much a 'flaw' that I see, but rather a red flag that the
proposals' author(s) may have been focused on using "security" technologies
without a lot of regard to how they actually impact the overall security of
the environment.

PaulM

-----Original Message-----
Subject: [fw-wiz] A few sql 2000 related questions

Folks,
I'm new to the list, so forgive me if the questions have been asked before.

1/ First, are there "best practices" relating to security MONITORING of sql
servers?  And tools to do so?  We have a copy of bindview for SQL.  I
haven't had a chance yet to look over it.

2/ We  currently are running a web server that has SQLServer 2000 on it.
Again,
I haven't had time for an exhautive review, but I don't think the SQL
connection is "protected" using ssl (which I have been led to believe is
best practice).
So for "back office" connections, is ssl best practice?  What about taking
SQL OFF that machine?  The cuurent protection goes as follows:

inet -> fw->(ssl) dmz (reverse proxy)->fw->web server running IIS/SQL-->back
office fw-->SQL "feeders"

The current solution is completely outsourced, but we are planing to change
that this year to just web hosting where we have more control.

One proposal I have is the following

inet-->IPS-->fw->dmz (ssl) web server->fw->(ssl)sql server->vpn(with
acls)->back office fw dmz->(ssl)back office feeder servers

comments?

other proposal is

inet-->IPS-->fw->(ssl) inverse proxy->fw->(ssl) web server ->(ssl)sql
server->vpn(with acls)->back office fw dmz->(ssl)back office feeder 
server->servers

comments?

Thanks for your feedback,
-ML

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