• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.


    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

Spoofing a Spectrum Protect server


TSM noob with 10 years expirience
ADSM.ORG Moderator

Possible to spoof a tsm server?

In an enviromnet with tsm server TSMA on ip, and a client runs happily here. Then a bad dude sets up a new tsm server with the same servername but on ip He has access to the client, and creates an identical node with the same password on the new server. Lastly he creates a entry in the local host file and redirect DNS for TSMA to the new IP, and restarts the scheduler.

Is there a mechanisme that will detect this on the client side? OR will it send data as usual?

Does anyone know what happens during a tsm login session. I know you need node_name and password, but in the stored registry key, does it also verify the actual server?

I know that SSL can be used to prevent this, but is there a build in check too?

-= Trident =-


ADSM.ORG Moderator

I like your scenario but will that happen? Most likely not.

Building a TSM server inside one's network is not a trivial task - it requires group effort:

- DNS changes
- IP address allocation
- cabling
- etc

Putting a spoofing TSM server on a network is not easy, and most likely next to impossible.

Now for the question: what local mechanism can you use? Password access prompt maybe the way to go plus hard coding the TSM IP address instead of using the DNS name.

What you should really be afraid of is Ransomware: the virus/worm is passed on from the node to the TSM server.


TSM noob with 10 years expirience
ADSM.ORG Moderator
Security audit can reveal the most amazing theories :)

I know all parts must be lined up (access/nodename/password/....)
And as long as you can modify the local /etc/hosts file, then server can be located 'anywhere'.

I was hoping the server guid or a smiliar values was part of the nodename/password cookie. If all three does not match, then notify user.


ADSM.ORG Moderator
I have actually tested this - the nodes connected and ran backups to the new TSM server even if the new TSM Server is on 7.1.7 while the old one was on The DNS entry of the new server=DNS entry of the old server after the switch. Of course, a full backup of all systems ran. Also, all nodes were registered first on the new TSM server and all backup schedules setup.

The settings to note on the client side:

- passwordaccess=generate
- tcpserveraddress=<dns_name_of_TSM_server>

Even if the TSM Server is set to "closed registration", it would not matter.


TSM noob with 10 years expirience
ADSM.ORG Moderator

A small follow up. A pmr has been opened about this. 31891,001,806

-= Trident =-


TSM noob with 10 years expirience
ADSM.ORG Moderator

In the enviroment where this was evaluated, it can not happen, unless you control all aspects of network, hosts, firewalls, usermanagement etc... But, the role of a security auditer does not take the entire picture into concideration. They look into one part at the time, and ask questions. And, that was the question that I got. Is it possible to connect to another tsm server without the client knowing about it?

An the answer to this is yes. The client does not verify the server with anything else than nodename and password.

In this case we can work happily with this missing feature of verification. But, I can see the requirement for a better client-server authentication and verification. How many people uses a random password for each client registration? How many do change the node password every day/week/month? Do clients have full access to internet, or is all traffic firewalled both directions?

Security becomes more and more detailed, and Spectrum Protect needs to have focus on this too.

-= Trident =-


TSM noob with 10 years expirience
ADSM.ORG Moderator
When I think about it,I am not sure that SSL will help out. In this case, we assume that a evil person has access. An import of the 'spoofed' tsm server public key is not that hard. Not sure how the login part with SSL works. Is it per node_name, or per node. My guess is that even with a valid node_name and password (and the imported public key from a spoofed server), the node will be able to connect to the wrong server.

Wrt the pmr, logs has been sendt to IBM, so I am awaitng their respons.

-= Trident =-


ADSM.ORG Senior Member
You ned the private key from the tsm server, this key must be copied to the "bad" tsm server.
So keep your tsm server secure, and a password on the keystore. If you also add the dnsname and ip adresses of the server to the private key it is even harder to move it to rouge tsm server and get it to work.

During a "normal" login the client will login to the server by using its password and id, the server will repsond with its "tsm server name", the client wil verify if this matches the stored value before proceeding.


TSM noob with 10 years expirience
ADSM.ORG Moderator

I have just tested. Got two tsm servers A & B. Both with SSL enabled on port 1510.

Imported SSL public key from both servers to the client. Logon with dsmc to server A with node and password

Exported reg key for:
Windows Registry Editor Version 5.00


And imported it for server B with these settings.


As you can see, the password hex key is the same.

Once this is in, I can connect to B without any verification other than node_name password combo. Even with SSL enabled. SSL is only for trafic, and is not used for authentication purposes. It will need a valid public key, which you have since you have configured it.

And i agree that this is a very special case. And the probability for this to happen is close to zero.

-= Trident =-

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 17 19.5%
  • Keep using TSM for Spectrum Protect.

    Votes: 53 60.9%
  • Let's be formal and just say Spectrum Protect

    Votes: 10 11.5%
  • Other (please comement)

    Votes: 7 8.0%

Forum statistics

Latest member