Post

2 followers Follow
0
Avatar

Securing your RPS

If a site were to replicate to a remote RPS across the web it would require ports 8014 and 8015 forwarded at the remote site for the replication to take place.

Obviously for security you only allow these ports access from the WAN IP of the source site.

But if the source site is compromised, say with a hack of the source server, how to we protect the remote RPS from being attacked through port 8015. I have tested this and the administration page is visible through the link. The credentials are likely to be different, but it still seems like a vulnerability.

 

Simon Gray

Official comment

Avatar

Thank you for your contribution, Simon. It is appreciated.

First of all, it is absolutely best practice to have completely separate administrator credentials between such systems. But the admin account of the destination shouldn't even be known outside of it ... here is why:

For the RPS to RPS replication using the task type "Replication to a remotely-managed RPS", we recommend that the credentials that are shared from the destination node to the source node (in order to get entered into the source UDP Console) would be a non-admin account. That way, even if the complete source site is compromised, it would not automatically mean the destination RPS is in danger. The non-admin account is not able to log into the UDP Console. It is only able to send replication traffic, but cannot modify or remove older recovery points.

It's correct that the UDP Console is visible via port 8015. That's a desired feature for some admins. Some do the UDP management from their smartphone or tablet via https. And you're correct, this access can be secured on the network level according to each individual's needs.

For additional security concerns - may I ask to keep them in individual tickets, please?

Thank you! Kai Steinbach

Kai Steinbach
Comment actions Permalink

Please sign in to leave a comment.

1 comment