Re: Best practice suggestions for SQL and mapped drive through firewa l

[ark () eltex ru]

-----BEGIN PGP SIGNED MESSAGE-----

nuqneH,

"Ravdal, Stig" <stig.ravdal () digitalpaper com> said :

> Hi, I hope that some of you will offer your opinions and experiences on this
> question.
>
> My company is offering an e-commerce solution that uses an MS web server and
> MS 2000 SQL database.  In order to keep the data safe it has been decided
> that the data and database needs to reside inside a firewall:  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.
>
> The big question is how do we best implement this solution so that it works
> yet is acceptably safe.
> We do not know what the firewall the customer may use so if at all possible
> a "universal" and "best practice" solution is what we are looking for.
>
> 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.

Just do not (general rule that applies to netbios shares). 
Why do you want to do that?
 
> 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.

MS SQL runs TDS on 1433. it is, basically, a generic packet exchange over
tcp. see www.freetds.org if you want to know what happens inside.

It is (quite) firewall-friendly, though sometimes it expects weird things to
be like aligning ip and tds packet boundaries. It does not affect functionality
but that may affect performance.

There are several proxies for tds.
 
> 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.

You may run tds over ssl, ssh, ipsec and whatever else you want that does tcp
tunneling. 

                                     _     _  _  _  _      _  _
 {::} {::} {::}  CU in Hell          _| o |_ | | _|| |   / _||_|   |_ |_ |_
 (##) (##) (##)        /Arkan#iD    |_  o  _||_| _||_| /   _|  | o |_||_||_|
 [||] [||] [||]            Do i believe in Bible? Hell,man,i've seen one!

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQCVAwUBPH+bGKH/mIJW9LeBAQHZHgQAiH0tHYJImw/JktvlpBjvPGJLu9htPUBt
889FL3ZeJsWh/hwiLFj9E1SsssSFOlEQostcUPu2cVDELj4GLy6+3TPHNmETnL51
ZbMrBhHxkBm6WVKeHPX8nOI4SHTLqEYVuQ+nsfW614As2kI03Ghs+zauwy9APqlH
yirJ1wte3aU=
=OxnR
-----END PGP SIGNATURE-----
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards