Securing IPHost Network Monitor installation

What are possible security risks using IPHost Network Monitor and how can I reduce them?

Q: Does IPHost Network 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: IPHost Network 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, IPHost will not endanger your overall security.

We recommend to follow the below security guidelines, to make your IPHost usage as safe as possible. Use navigation shortcuts below for quick access:

1. IPHost Network 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 IPHost version

We recommend keeping your IPHost 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 IPHost contain upgraded versions of its software components, as well as updated configurations. We do not recommend using out-of-date versions of IPHost due to possible security risks related to running older versions of bundled Web server and OpenSSL library.

To see which version and build of IPHost is currently running, start IPHost GUI client and click “Help > About IPHost Network Monitor”.

1.2. Run IPHost out of virtual machine

IPHost can be run on virtualized Windows environment, i.e. on virtual machine. We recommend this approach over installing IPHost on a system shared with other applications. Some advantages of running IPHost on a virtual machine:

• isolated environment: IPHost doesn’t have to share resources with other applications (note that on busy monitoring setups IPHost 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

IPHost provides Access password feature to prevent unauthorized access to monitoring setup (and encrypting access credentials stored in database). Run IPHost GUI client and click “Settings > Access Password” to assign it.

By default, access password is empty (unset). It is recommended to set it to non-trivial string, thus adding an extra layer of security in accessing monitoring data.

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).

(please note on the above screenshot how “keys” directory below IPHost program data directory is specified)

Take care of other precautions as well (specify access password, use file system access control to restrict access to credentials files).

1.5. Avoid using insecure protocols

IPHost 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, IPHost 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)

Note: if public access is required for Web interface, using HTTPS and valid SSL certificate is strongly recommended. You can use service like Let’s Encrypt to get a free well-recognized SSL certificate.

1.7. Firewall unused ports

By default, IPHost 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

The above are default values; you can see the actual values of the ports numbers by running IPHost GUI client and clicking “Settings > System”.

It is recommended to block access to unused ports/services mentioned above; that will reduce amount of traffic used by IPHost installation, and reduce risk of DOS (denial-of-service) attacks on IPHost installation.

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, IPHost 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 IPHost or its components); however, they donate to overall hardening the IPHost 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, IPHost Network 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

There are several pieces of software that can be safely used to generate strong passwords. That includes well-known pwgen password generator, available in most Linux distributions by default, and its Windows port.

There are several pieces of software that can be used to store passwords safely, such as KeepAssX. Other conditions equal, please take care when considering storing your passwords on any external storage.

2.4. Restrict access to system running monitoring software

Please note that physical access to a system can defeat most known security measures.

If monitors use SSH key authentication, SSH private key should be stored somewhere on filesystem accessible by IPHost Network Monitor. Care should be taken to prevent user accounts different from the one used to run IPHost monitoring service from accessing those keys (otherwise, the security of corresponding SSH account can get compromised). It is recommended to store such keys below IPHost program data folder, in a separate folder, and use Windows access control to only allow reading the key files by account used to run IPHost monitoring service (system user account, by default).

Same way, care should be taken to prevent users from reading monitoring database file directly (otherwise, user can copy the database and/or access its records).

Related topics