I should have claritied things a bit.

Basically, we setup the following security regardless of the firewall used:

A - Depending on the site, we use some sort of encrypted user
authentication to allow connection in on the port.
B - The firewall will only allow connections from the specified server(s)
on that port.
C - All connections are encrypted between the server(s) and firewall at all
times.
D - The router in front of the web servers(s) blocks connections on port
1500 (both in and out).
E - I hacked together a script that changes tcp_wrappers to allow
connections from the firewall only between the required times.  (About 3
hours each night) and the ADSM server.
F - the dsmc operation is not scheduled, but run via the Operating Systems
schedule.  Yea, you lose ADSM scheduleing abilities
BUT I know that the only time their will be an internal connection is
during backup!.

This was work well for the past 6 months.

I'm still looking a a reasonable way to initiate the connection from
inside, that will require a little work though.

Anytime you allow connection to your internel network, there will be "ifs".
But we feel safe with the current ADSM requriements and measures that we
take.

Mat Kovach





Alan White <arw AT TIPPER.DEMON.CO DOT UK> on 01/22/99 10:38:45 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: Mathew Kovach/CTI/Caliber)
Subject:  Re: Backing up a server through a firewall




Mathew/Robert

Our security guys were pretty paranoid about this. Opening up port 1500 (or
any other) which allows access to the ADSM server for the baclient also
lets
the saclient in. We're into multiple 'ifs' now however if someone gets on
to
a box outside the firewall which is backing up to a server inside they can
start guessing at admin logon passwords on the server. If they are lucky
enough to guess a 'system' id then they can trash everything. They could
also schedule a one-time command as root (or NT administrator) on all other
registered clients, it gets messier.....

If they can't get an admin logon they could do lots of nasty things to the
box they are just with the baclient and -virtualn=hostname password
guessing, regardless of the id they got on as.

Unfortunately there are people like that ;-(

OK, we can set invalid logon attempts at 3 or something then lock the ids
but all we are doing is minimising the risk, not eliminating it.

Regards
Alan