- Compare Editions
- Product Information
All settings, databases, network information, etc., stays on your servers. The product is not cloud-based.
By default, PA Server Monitor uses SSL/TLS secured HTTP communications between the Console, Satellites and the Central Monitoring Service. If encryption is turned off, remote connections (remote Consoles and Satellites) are not allowed.
The SSL/TLS connection can run on any port, and defaults to port 81.
SSL/TLS is implemented using the latest version of OpenSSL
This means notable exploits are quickly patched, including:
The embedded HTTPS server supports Forward Secrecy by supporting ephemeral Diffie-Hellman key exchange, depending on the encryption cipher that is negotiated between client and server.
There are two SSL/TLS security settings available which can be changed in Settings > HTTP Server Settings.
Here you can control which protocols the HTTPS server will use.
SSLv2 is not allowed, and SSLv3 is disabled by default.
Various ciphers settings are available, with the "Strongest ciphers" setting being the most robust at the time the product was released.
Cipher names and information can be found at https://www.openssl.org/docs/apps/ciphers.html
For an alternate cipher override value and discussion, see http://stackoverflow.com/questions/3775836/disable-weak-ciphers-in-ssl-connection.
By default, a self-signed SSL certificate is used, but you may replace that with your own certificate using the instructions at:
The generated self-signed SSL certificates are currently 2048 bit. The default signature algorithm is sha1RSA, signature algorithm of sha1, and the public key is RSA 2048 bits.
The self-signed certificates can be easily regenerated at any time.
The internal HTTPS server is very small and light. It supports a fixed number of connections, and each connection will only upload or download a fixed amount of data. These limits are registry configurable.
For many years, a number of customers regularly fuzz test and run vulnerability scanners on our software (and other software that they run on site). Any time an issue is found it is fixed within two business days. Most of the time it has involved adding an HTTP header, such as X-XSS-Protection: 1, X-Frame-Options:SAMEORIGIN, etc. It has now been a number of years since any problems have been found, and we always welcome feedback. We recently asked a white-hat tester to look at our software and nothing was found.
The monitoring service supports security alerts for anything that might change or affect monitoring. These are available at Settings > Security Alerts.
In addition, the monitoring service can be locked such that it cannot be stopped by the Windows Service Control Manager. This setting is at the bottom of the Settings dialog. If the service is terminated, the service is configured to automatically get restarted by the Windows Service Control Manager.
There are a variety of different credentials that might be put into the system depending on monitoring needs:
ALL of these credentials are encrypted using Microsoft's recommended method of storing credentials via the CryptProtectData function. This encrypts the credentials such that they can only be decrypted on the computer where they are stored using an encryption key that is managed by the operating system.
The encrypted credentials are stored in the registry at:
There are a few places in the product where the configuration can be exported to disk, with the option to export credentials. This export option can be completely disabled by setting:
Other protected settings are discussed here: Security Protected Settings.
Communication with individual servers is done using standard protocols (HTTP, Ping, SNMP, Windows RPC for things like Event Logs, Performance Counters, etc).
Communications via Windows RPC is done using standard Windows APIs, which means all communication and access is governed by the Windows security model.
Individual monitors need different permissions depending on what resource is being targeted. Please see Monitoring Permissions for more details.
By default, an embedded SQLite database is used to store data. This can be changed to store data in a MS SQL Server database. In that case, the database login needs access to create, update and delete tables and indices. It does not need access to, nor does it try to use any statements that would modify, create or delete individual databases, including the database it stores data in.
There are a few ways of logging in and interacting with the product:
All product logins tie a user to an account. Accounts can have their access filtered such that they can only access specific groups of devices, with potentially limited rights to those devices. The product uses a "never trust the client" posture, which means the backend service enforces all constraints.
“Can I just say that I think your support is pretty amazing! [And the product is not bad either!]”Iain M., IT Manager, United Kingdom