Re: Best practice suggestions for SQL and mapped drive through firewalls

[Mikael Olsson <mikael.olsson () clavister se>]

Hi Stig,

"Ravdal, Stig" wrote:
> The web-server will be in the DMZ/service network and data and the 
> database are secured behind the firewall.  Both servers will be 
> Windows 2000 servers.

Hmmm.. I'm not sure if "secured" is the right word to use when you're
opening up basically the two "biggest" ports available on the
data/db system. One buffer overrun in the SQL parser/protocol, or
misconfigured rights to use the "execute a system command" (I forget
the name) system procedure, and your internal network is under
anyone's control.

It _does_ protect against RPC commands and things, so the situation
does become a bit better.

However, why only use ONE DMZ? Why not one for each machine?
Attempt to protect the database server from the web server
somewhat, and then protect the internal network from the
database server.

> The proposed solution is to map a drive through the firewall and from what I
> can understand it would suffice to open up TCP 139 on the firewall to do
> this (using NetBIOS over TCP/IP and ignoring UDP 137/138).  Yeah it's not
> the most secure and I would appreciate any and all comments as to why one
> might NOT want to do this.

TCP 139 will work if all you want is a drive mapping to a share.

However, a question: if also you open up a NetBIOS hole from the internal 
network to the database machine, how do you keep internal users from
(accidentally) executing binaries on the database server?

> Connection to the Database would be using ODBC over TCP port 1433.  I'm not
> sure if we can make the client ports static but I think so thus the firewall
> would be able to allow incoming connections from "web-server" port <static>
> to "database" port 1433 (or we might even suggest using a less well known
> port).  I'm not sure what the outbound session may look like but if the
> firewall is stateful (and maybe with inspection) that may be less of a
> concern.

This adds very little value, if it is at all doable. You end up with
horrible TCP end-to-end semantic problems when you re-use the 
originator port, f.i. when the database connection is disconnected, you
usually get a 4-minute delay (2xTCP MSL) when you can't reconnect,
because either end has a socket sitting around in "time_wait" state.

> I have also suggested that we look into other ways including Secure FTP or
> FTP through SSH, but this may or may not be that easy to accomplish
> depending on the customer IT security team and what they are both willing
> and comfortable doing.

SFTP is one thing. Stay clear of normal FTP.

However, this is kind of hard to give you advice on, when we do not
know the requirements of the data on the database server. Does it
need to be immediately accessible when updated? If so, any form
of "push" probably won't work very well.


Generally speaking, in these situations, you have more data on
the database server than what the web server actually needs 
access to. Often, a good solution is to push the needed data
from the internal database server to one that is accessible
by the web server. But when the web server needs to update
the same data that got replicated out, things generally tend
to get a bit more tricky. And, of course, you might end up
with an additional machine to run the intermediate database
server on, which gets added right to the total cost of the
security implementation, which must then be compared to the
expected savings (in case of a break-in) of the security
solution, etc etc, but I won't go too far down that particular
road today ;)


Regards,
Mikael Olsson

-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com

"Smile; today is the tomorrow you worried about yesterday!"
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards