We are looking to change the port the agents communicate to the VSA to 443.
I have done a forum search and found some interesting posts - has anyone actually done this change successfully? What hurdles did you encounter?
I haven't done it, but I don't think it is possible; at the very least, you have to change the web service listening port. I can't think of a reason to do it, but for academic's sake...
From a pure LAN point of view, the Kaseya front end, which is where the agent checks in, already has a service listening on 443, the web service for https. So first, you would have to have the web service listen on a different port for https. That would make it confusing for your users to log in, possibly intentionally so I suppose.
From a WAN point of view, you could use NAT rules to listen on a separate public IP on port 443 and NAT that in privately to 5721.
I am curious why you would want to use the default https port though. I can't think of a reason. Any tools meant to look at https traffic wouldn't work. You wouldn't get added security of SSL/TLS. You wouldn't reduce your attack surface since you still have to have https listening on some port.
Security by obscurity is not real security, but it does add another layer to overall defenses. For example, if you put a live MS SQL server on the internet, I predict it would take about -1 seconds for someone to begin attacking it. If you put the same SQL server on port 20000 it may take months before someone stumbles over it. While it's not any more secure, it is less obvious. Predictable port numbers are just bad in general, unless there is a reason to have them (e.g. running your DNS server on TCP:54 and UDP:55 is unlikely to be a successful deployment).. Why would you want to make it easy for a bad guy to find you're running Kaseya?
Also, a relatively unknown fact is that your check-in port is actually run by IIS. For example, if you open http://mykaseyaServer:5721 you will get the login page. This is a security issue in terms of you believe all HTTP access is controlled or blocked from external sources (through no TCP:443 forwarding, or content filtering on 443)
That's a great idea - I'm a little jealous that I didn't think of it! We've changed our check-in port to a high number, so it is unlikely to be found unless someone is actually targeting us, but moving it to 443 would actually stop one port being available externally, and "should" retain full functionality. We're not able to test this now, but would be really interested to see what happens when you try it - I think we will follow!
The reasoning behind this idea was firewall changes on the client side. Most client these days require firewall changes to allow the agents to phone home. This can add weeks to deployments depending on who looks after the firewalls for a particular client.
The other contributor is that we have a need to change our external IP that Kaseya sits behind. The prospect of going through client firewall reconfiguration to support this will be very expensive and time consuming. Port 443 is a no-brainer for this.
Oh, that I understand. I think an easy solution would be dedicating a second public IP to agent check-ins, listening on 443. Then NAT that into the private Kaseya IP on 5721.
Just for thoroughness, to finish that last thought...
You can set the check in port from the client point of view on the Agent -> Check-in Control.
That is different than the port the server listens on, which is in System -> Configure.
So finishing my thought, you can set the Check-in Control port to 443, use your firewall to NAT 443 public to 5721 private, and leave the server port on 5721 behind your firewall.
yep - that is the plan. We will do a fair bit of testing, would still love to hear from anyone who has actually done it.
Thought of something late last night - when the agent package is generated - where does it get the check-in addresses and port so it's able to connect after installation?