OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archives: RE: any experience with backup solutions

RE: any experience with backup solutions for servers in the dmz?

Subject: RE: any experience with backup solutions for servers in the dmz?
From: spiff (spiffbway.net)
Date: Thu Jan 13 2000 - 17:20:07 CST

Been busy of late, sorry to drop into this mid-thread.

In my experience, dmz machines need their own tape drives, one for every
host. It's just a place where one can't afford to skimp. While the cost
may become high in instances of massive www server-farms, I think the
benefits outweigh the cost. Consider that these machines are in your DMZ
and so on the drontline of any attack you may experience. Just as one
would make a backup of these machines in a known good state (and this is
one reason the host should have it's own tape drive/dvdrom/MO
disk/cd-writer), before putting them online in production, so too should
there be a minimized risk associated with each separate host. Even if they
are load-balanced mirrors, each should have it's own internal
backup. Consider the scenario where you have 10 hosts in a dmz all
connected to a backup server on their subnet. If one of those hosts is
compromised, the likelihood of the backup server and the other 9 hosts
being compromised increases significantly. The added admin overhead of
authentication and monitoring is considerably higher with a networked
backup server. It's a case of doing things completely differently than SOP
for internal network stuff. It is far simpler to have each host in a dmz
with it's own backup system.

spiff

On Tue, 11 Jan 2000, James R Grinter wrote:

> On Mon 10 Jan, 2000, "Ginsberg Rainer (QI/INF4) *" <Rainer.Ginsbergde.bosch.com> wrote:
> >ADSM uses a TCP connection. The port is configurable, default
> >is 1500. TCP connections will be established from both sides.
> >First, the server tells the client to do the backup, then the
> >client opens another connection and sends all its data.
>
> Here's my understanding of the current situation with ADSM (TSM).
>
> As things stand you can't limit where an Admin user can log in from,
> the admin client makes a connection to the same port 1500.
>
> Can someone get an admin client program/binary easily? Yes.
> Can someone connect from your system as an Admin? Yes, if they know/can
> deduce a user and password
> Can someone sit there guessing passwords for an Admin user? If you've
> not set an invalid signon limit.
> Can an admin user wreak havoc upon your backups? Yes, if they get one
> with sufficient privileges.
>
> You can stop an ADSM client (node) from being able to delete backup
> data, though. You've just got to hope that someone doesn't back up
> enough sets of data to blow a whole in your data retention policies
> (eg. Ten previous sets of files - make 10 backups of corrupted
> datafiles) before you notice and get back your off-sites: oh, you'd
> probably need to restore the database to match them too because it
> would have dropped all the previous backups. I don't think there's
> a way around that - talk with your site ADSM expert or try asking
> the ADSM-users list.
>
> (I expect there are similar issues with other backup products.)
>
> I can think of a few approaches to tackling the above issues. Maybe a
> second dedicated server which transfers its data, after the backup
> window, directly to another server? Or export filesystems inwards
> to a seperate partitioned network and backup from another node.
>
> James.
>

This archive was generated by hypermail 2b27 : Sat Jan 15 2000 - 21:39:25 CST