Opinions sought on webserver/mysql server layout

Alex Beamish talexb-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Fri Dec 16 15:19:19 UTC 2005


On 16 Dec 2005 00:14:23 -0500, Tim Writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org> wrote:
>
> 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.


To follow on that, you could hook the database server directly to the web
server through another NIC, with their own little 192.168.128.x network, for
example. No other computer is connected to the database server, just the web
server, and the database server only accepts connections from the web
server. In effect, the two servers look like one larger server.

Of course, doing backups may present problems, but that's a story for
another day .. and may not even be necessary.

Alex

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
>



--
----------
Linux, Firefox and GMail .. what a combination.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/legacy/attachments/20051216/7b996e56/attachment.html>


More information about the Legacy mailing list