Client-server Authentication


I'm relatively new to using uptime and I have a basic question regarding client-server authentication.

I install a client on a W2K3 client server box. No problem. I then go to the uptime server and add the client server in as a managed client. I noticed that at no point does it ask me to authenticate against the client server I'm adding. I am then able to monitor pretty much any service, restart them if they fail etc with Action Profiles all from the uptime server. The client application on the client server is running as a system level process.

So my question is – what is stopping a hacker from opening an unauthenticated connection to my servers and taking control of them through the uptime port/protocol? Is the security of my servers now dependent on a firewall rule I will need to roll out across the entire enterprise? If so, is there any intention to implement some sort of inbuilt security between uptime clients and their managing server?


  • Additionally, will the client operate correctly if I reconfigure it on the client server to use a less privileged account than “SYSTEM”? If I gave it a normal user account, what extra privileges would I need to grant the user? You can assume that I will be monitoring only, and not attempting to restart privileged services, etc.

  • Hi Neobyte,
    The up.time agent will allow anyone to retrieve stats back from it, but it will not allow anyone to make any changes on the system. It's purely a read-only setup.

    To be able to restart a Windows service you must first need to setup a password on the agent system. The password is stored in the registry on the remote system and the monitoring station will need to have that password entered before it's able to restart the service via the agent. You can set the password by using the Admin Console that's installed with the agent.

    The agent commands are easy enough to get by sniffing the packets since they're simple TCP strings, or you can also simply call support for info on the agents, but that alone will not give you access to make changes on systems with up.time agents installed. The same password security is used when using custom scripts except that the agent can only execute scripts/apps that it has been specifically setup to execute. That info is in the registry as well and you can set it up by using the Admin Console as well.

    Let me know if that answers your questions or if you have any others that I can help you with.

  • First off thanks Joel I appreciate you taking the time to answer my question.

    I've found the bit in the docs that talks about changing the Windows agent password – it states “if you want communication between the agent and the up.time Monitoring Station to be more secure, you should add a password to the agent”. That implies that once the password is set, you would need it to retrieve *any* information from the agent. Is this correct?

    Also, I believe I saw a “use SSL” option on the server side. If I configure SSL and configure my agents with a password, does this secure my agents from anonymous access, as well as snooping of the packets?

    Thanks in advance!

  • Hi Neobyte,
    Not a problem.

    Adding a password to the agent will not actually make it “more secure” at all; it simply enables you to use custom scripts or start/stop/restart Windows services. The performance data is still gathered the exact same way. You can verify this by performing a Poll Agent (My Infrastructure > system name > Poll Agent).
    Can you let me know exactly which article/doc stated that as it may need to be clarified.

    Yes, setting the agents with SSL encryption will secure your network from snooping apps and we have a KB article that describes how to do this:

    It simply involves installing a free SSL tool called “stunnel” and have that act as the proxy for the agent so that it responds in an SSL TCP connection.
    Just to clarify however; setting up the agent to respond with SSL still means that anyone that knows the read-only agent performance gathering commands can still execute them without requiring any sort of password; but they are still only read-only commands.

    Let me know if this help or if you have any other questions.