On Mon 10 Jan, 2000, "Ginsberg Rainer (QI/INF4) *" <Rainer.Ginsberg_at_de.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.
Received on Jan 12 2000
Intro
