My preferred setup tends to be 3 tiered:
DMZ - Reverse Proxy (e.g. Microsoft TMG, Apache, F5), permits HTTP/S
connections only to:
App LAN - Application/Web servers, which can only make DB connections to:
DB LAN - Database server
With firewalls between all networks. I don't trust apps to have unrestricted
access to databases, whether they are in the DMZ or now.
Quite often there will also be a management LAN, with an authentication server
(i.e. AD) which needs connections into all the other networks.
Chris
From: [email protected]
[mailto:[email protected]] On Behalf Of Dan
McGinn-Combs
Sent: 18 May 2011 15:36
To: PaulDotCom Security Weekly Mailing List
Subject: Re: [Pauldotcom] MS-SQL in the DMZ
I think the issue is putting your DATA in the DMZ. Basically, from my
experience, you put stuff you can afford to lose because Internet resources hit
on DMZ hosts all the time. If your web server gets compromised, you can
format/reinstall it from scratch. No big deal. If your database server gets
compromised, you potentially lose your data. That could be a big deal.
On Wed, May 18, 2011 at 9:15 AM, Juan Cortes
<[email protected]<mailto:[email protected]>> wrote:
Thanks Michael.
So let me get this straight. there shouldnt be any comms from my sql server in
the dmz to my internal network.. correct? which i agree.
But comms to the sqlserver in the dmz from my internal network is ok? i am
pushing to change the default port just for some comfort.
thanks in advance
On Tue, May 17, 2011 at 3:34 PM, Michael Dickey
<[email protected]<mailto:[email protected]>> wrote:
One point of having a DMZ network is to isolate systems that accept untrusted
connections from those that do not. A front-end web server accepts untrusted
connections, but the SQL DB server does not; at least not directly. So if you
have some other way to isolate the communication between those boxes so that
one only talks to the other via something like a SQL port, then I guess feel
free.
Otherwise, the easiest best practice is to just say SQL DBs in the DMZ is a bad
idea. If your web server gets popped, maybe even marginally, it could open up
easy attacks into your SQL box.
Of course, this is a whole new discussion if:
- you're a small shop and/or might consider internal users as untrusted, but
can't afford so many separate networks
- you consider SQL owned if your front end web server is owned, which is a
certain non-layered way to look at it
On Tue, May 17, 2011 at 3:08 PM, Juan Cortes
<[email protected]<mailto:[email protected]>> wrote:
Hope all is well,
Can anyone point or recommend a some resources for best practices for SQL DBs
in the DMZ
thanks
--
Juan C.
_______________________________________________
Pauldotcom mailing list
[email protected]<mailto:[email protected]>
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com<http://pauldotcom.com/>
_______________________________________________
Pauldotcom mailing list
[email protected]<mailto:[email protected]>
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com
--
Juan C. Cortes
773-531-0637<tel:773-531-0637>
Chicago, Il 60632
_______________________________________________
Pauldotcom mailing list
[email protected]<mailto:[email protected]>
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com
--
Dan McGinn-Combs
[email protected]<mailto:[email protected]>
Google Voice: +1 404 492 7532
Peachtree City, Georgia USA
This e-mail has been scanned for all viruses by WebSense
MailControl.www.websense.com
Click here<https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==> to report
thisemail as spam.
"This email and any file attachments do not form a contract unless expressly
stated. They may contain privileged, confidential and/or copyright information.
If you are not the intended recipient or the service provider responsible for
delivering this please delete the material from any computer and return to the
sender at once; do not use, disclose or reproduce its contents. We do not
accept liability for any error or omission in the message arising from
corruption of, delay in or interference with, its transmission. We reserve the
right to monitor email communications through normal internal and external
networks. We believe but do not warrant that the email and the file attachments
are virus free."
Interservefm Ltd. Registered in England, Number : 2820560.
Registered Office: Capital Tower, 91 Waterloo Road, London SE1 8RT.
_______________________________________________
Pauldotcom mailing list
[email protected]
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com
