Opinions sought on webserver/mysql server layout

Tim Writer tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org
Fri Dec 16 05:14:23 UTC 2005


I also agree and can offer this rule of thumb. If there are little or no
consequences to having the data stolen or tampered with, leave the database
in the DMZ. By putting the database in your private network, you would be
reducing the security of your private network in order to protect worthless
data. On the other hand, if there are consequences to having the data stolen
or compromised, you would be well advised to take additional steps to protect
it. In other words, you must assume the servers in the DMZ will be broken
into.

As has been mentioned, one way to protect the data is to put the database on
your private LAN but that exposes it (your LAN) to some risk. An alternative
is to create a second DMZ for the database server. Your firewall then allows
database traffic from the web DMZ to the database DMZ and from your private
LAN to the database DMZ but not from the web DMZ to your private LAN and not
from the Internet to the database DMZ. A third alternative is to create
a simple, single purpose backend daemon to provide only the limited set of
functions required for your web application. If written carefully, this
single purpose server _might be_ more secure than a full blown database.


billt-lxSQFCZeNF4 at public.gmane.org writes:

> I agree with Scott. there is no right answer to this question.
> 
> The question you should ask is how important is the data in the database.
> 
> Consider two example: 1) the data in the database is configuration data for
> the webpages such as php pages. In this case a database should definitely be
> in the DMZ. There is no point in opening a possible security hole for this
> type of data.
> 
> 2) The data in the database is credit card numbers of customer. In this case
> this should be in the internal network. The extra security risk is more than
> compensated by an increase in the security offered by requiring the intruder
> to break into two different machines.
> 
> I hope this helps.
> 
> Bill On Thu, Dec 15, 2005 at 09:50:46PM -0500, Scott Elcomb wrote:
> > On 12/15/05, Neil Watson <tlug-neil-8agRmHhQ+n2CxnSzwYWP7Q at public.gmane.org> wrote:
> > > I've planned a new webserver to host two sites.  The server runs Apache,
> > >OpenCMS and Metadot.  This server sits on our DMZ.  I plan to host the
> > >database service on a separate server that sits on our internal network.
> > >It has been suggested that this is not a good idea.  What do you think and
> > >why?  Can you offer some real world examples of where database servers
> > >should be hosted?
> > In theory, all machines in the DMZ should be isolated from the machines on
> >your internal network.  (Machines in both the internal and external networks
> >should be able to call on "services" that reside in the DMZ though.)
> > 
> > Even opening a single port from the DMZ to an internal server poses at
> >least some risk if an attacker gains access.  Then again, putting the
> >database server in the DMZ poses it's own risk as well.
> > 
> > In practice I don't think it's always very clear cut.  There's a bunch of
> >factors involved in finding the solution - politics (particularly in
> >business), how secure the data in the database server needs to be, known
> >security issues with the database server packages, performance, etc.
> > 
> > Determine the factors critical to the application, weigh risks and
> >implementation cost against your security needs, and settle on a decision.
> >Network security is never perfect, but it is a worthwhile goal.
> > 
> > I don't have any real-world examples to give.  Sorry 'bout that.  ;-)
> > 
> > -- Scott Elcomb psema4.gotdns.com -- The Toronto Linux Users Group.
> >Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text
> >below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml
> --
> The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml
> 

-- 
tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
647.722.5301                                      toronto, ontario, canada
http://www.starnix.com              professional linux services & products
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list