What are possible security risks using IPNetwork Monitor and how can I reduce them?
Q: Does IPNetwork Monitor extend the surface of vulnerability of my system? How can I prevent exposing the monitored hosts to additional security risks brought about by monitoring? A: IPNetwork Monitor contains several software components, requiring escalated privileges to run, and makes use of access credentials to perform its functions. If certain security precautions are taken, IPNetwork will not endanger your overall security. We recommend to follow the below security guidelines, to make your IPNetwork usage as safe as possible. Use navigation shortcuts below for quick access:- 1. IPNetwork Monitor related security improvements
- 1.1. Upgrade to latest IPNetwork version
- 1.2. Run IPNetwork out of virtual machine
- 1.3. Assign access password
- 1.4. Secure access to credentials
- 1.5. Avoid using insecure protocols
- 1.6. Restrict access to Web interface
- 1.7. Firewall unused ports
- 1.8. Avoid frequent polling
- 1.9. Use custom mail notification templates
- 1.10. Make use of spike filters to reduce false alerts
- 2. General security guidelines
1. IPNetwork Monitor related security improvements
The further pieces of advice are all important, you are advised to follow as many of them as possible. The general recommendations are all the same: avoid out-of-date standards and software components; allow minimal possible access to sensible data; use encryption and data obfuscation wherever possible.1.1. Upgrade to latest IPNetwork version
We recommend keeping your IPNetwork installation up-to-date. The latest updates are always available from Download page. You can also verify the checksum of installer file. Latest releases of IPNetwork contain upgraded versions of its software components, as well as updated configurations. We do not recommend using out-of-date versions of IPNetwork due to possible security risks related to running older versions of bundled Web server and OpenSSL library. To see which version and build of IPNetwork is currently running, start IPNetwork Monitor GUI client and click “Help > About IPNetwork Monitor”.1.2. Run IPNetwork out of virtual machine
IPNetwork can be run on virtualized Windows environment, i.e. on virtual machine. We recommend this approach over installing IPNetwork on a system shared with other applications. Some advantages of running IPNetwork on a virtual machine:- isolated environment: IPNetwork doesn’t have to share resources with other applications (note that on busy monitoring setups IPNetwork may require much resources, such as RAM, CPU, I/O operations and network bandwidth, to run smoothly)
- scalability: it is easier to control the amount of resources allocated to a virtual machine than to restrict a single application
- security: it’s simpler to restrict access to sensitive data such as access credentials by restricting access to entire virtual machine
1.3. Assign access password
IPNetwork provides Access password feature to prevent unauthorized access to monitoring setup (and encrypting access credentials stored in database). Run IPNetwork Monitor GUI client and click “Settings > Access Password” to assign it.
1.4. Secure access to credentials
When setting up access credentials, such as SSH keys, make sure to assign passphrase (do not use SSH keys with empty passphrase). This adds to security (if SSH private key is leaked, it will be still required to know its passphrase to make use of the key).
1.5. Avoid using insecure protocols
IPNetwork supports protocols (such as FTP, HTTP, SNMP v1 and v2c) that pass data as is, without encryption. Such data can be easily intercepted and/or tampered with. In case you pass any type of credentials, or other sensitive data, use encryption-based protocols to control remote devices. In short: use SFTP instead of FTP, and SNMP v3 instead of v1 or v2c; avoid insecure protocols, in general, wherever possible.1.6. Restrict access to Web interface
By default, IPNetwork Web interface is set up on default system’s network interface and adds no access restrictions. That makes possible, if Web interface is accessible, to control monitors (start or stop) and access monitoring reports. The following is recommended, in case the above behavior is undesirable:- select localhost (127.0.0.1) as default IP to run Web interface – that will prevent any outside party from accessing it
- set access password; users will have to enter it to access Web interface
- set up access to Web interface based on per-user basis (use Basic or Digest authentication feature of Web server used)
1.7. Firewall unused ports
By default, IPNetwork listens on several TCP/UDP ports:- TCP port 3056: monitoring service
- UDP port 162: SNMP trap listener
- TCP port 3055: database server
- TCP port 3459: agent server
1.8. Avoid frequent polling
User often set short polling intervals (30 seconds or less) for all monitors, to be alerted of possible problems as soon as possible. In practice, however, setting too short polling intervals can create extra load on the devices being monitored (especially in case of resource-consuming monitors, such as WMI-based, Web Transaction Monitor, SNMP and so on). Typical acceptable polling interval is 1 minute; in cases when performance value isn’t expected to change often, longer polling intervals could be reasonable. For example, one can use Ping monitor checking general resource availability every minute, and HTTP monitor, to check for certain content presence every 3-5 minutes. That will make checks more reliable and reduce unnecessary load on target device. The general rule is: make polling as infrequent as possible.1.9. Use custom mail notification templates
When using “Send mail” simple actions (notifications), try altering the default “Send mail” message template, to only contain information actually required. By using multiple simple actions, each with its own schedule and with its own message template, IPNetwork allows to direct different notifications to several groups of recipients. Since host names and details of monitoring events can contain sensible information about devices being monitored (location, capabilities, services present etc), that can negatively impact overall security of network being monitored. The general rule is: send as little information on the monitoring event as possible.1.10. Make use of spike filters to reduce false alerts
False alarms can often happen, if resource usage spikes can happen (e.g. if network speed shortly slows down due to a large amount of data being transferred). Under such conditions, monitors can switch to problem states, even if the resources being monitored do not actually exhibit any problem at all. To reduce probability of false alarms, spike filter can be used: it allows to ignore certain amount of consequent attempts to bring monitor to a problem state. Spike filters can be of use if network speed varies greatly, or if target devices can experience short-term spikes of load or resources usage. When spike filters are set to ignore reasonable amount (say, 2-3) of switches to problem state, they can prevent unnecessary checks and allow to better detect actual problems.2. General security guidelines
The recommendations below are general (unrelated to IPNetwork or its components); however, they donate to overall hardening the IPNetwork installation.2.1. Keep the system components updated
Nowadays security issues are detected constantly, in many OS components and software components in general. Keeping your OS and software pieces up-to-date is a must, otherwise you risk all kinds of security breaches – from unauthorized data access to getting hit by ransomware. Follow Microsoft guidelines on keeping your system secure: check for updates, subscribe to security advisories, avoid accessing/running potentially dangerous content (such as insecure links or documents attached to spam or otherwise dubious messages). That also includes installing anti-malware software; preventing a malware attack costs much less than handling its consequences.2.2. Avoid using privileged access wherever possible
By default, IPNetwork Monitor monitoring service is run under SYSTEM user account; certain monitors require escalated access (an example: WMI monitors, they usually require local administrator access). It is recommended to run monitors components, executing external software (such as “Script or Program” monitor) under as least privileged user account as possible. Default account (SYSTEM) is fine in most cases; however, privileged accounts should be used with much care, especially if they rely on processing user-provided data: programming mistakes and/or bugs could result in executing arbitrary code with escalated privileges.2.3. Avoid weak ciphers and credentials
This general rule should be applied wherever possible. If passwords are required,- do not use too short passwords (use passwords at least 12 characters long)
- do not use, as part of passwords, any personal information that can be easily guessed, brute forced or deduced out of public sources; that includes birthdays, addresses etc.
- never use same password for more than one service/purpose
- change passwords often enough; if you use computer-aided means to generate and safely store passwords, changing password at least once every 3-4 months is a good approach