Hardening the NetCrunch Server
How to deploy NetCrunch so that the server itself is a small target — what the server should and should not do, which account it runs under, and why monitoring belongs on a probe rather than on the server.
NetCrunch Security Features covers what protects the data NetCrunch holds. This covers the deployment around it: how to run the server so that there is less to reach in the first place.
The reasoning behind all of it is the same. A monitoring server holds credentials for much of the estate and can reach machines nothing else can reach. Anything that runs on that machine inherits that position.
What follows is guidance, not enforcement. NetCrunch does not currently block any of it — nothing here stops you monitoring from the server probe or running a script sensor on it. These are the choices that make an installation defensible, and applying them is yours to do.
Give the Server One Job
Run NetCrunch and nothing else on the server. No other services, no other applications, no general-purpose use.
This is not about resources. A monitoring server is a machine that already has credentials for your infrastructure; every additional process on it is another way in to those credentials.
Monitor from a Probe, Not from the Server
We recommend you to install a Monitoring Probe on a separate machine and monitor your environment from there. See Distributed Monitoring.
The server probe should monitor NetCrunch itself and nothing else.
That separation is what makes the advice above workable. Monitoring reaches out to devices, parses what they return, and in some configurations runs code to do it. Doing that from a probe keeps the work — and anything that goes wrong with it — off the machine holding the credential database.
If you only have one machine, you cannot follow this, and pretending otherwise helps nobody. A single-server installation is a supported way to run NetCrunch — it is simply the configuration with the least separation.
What still applies: keep other software off the machine, do not run script sensors or program-executing actions from the server probe, and treat the server as you would a domain controller rather than a general-purpose box. Add a probe when there is a second machine to put it on.
service-account
The Service Account
NetCrunch cannot run as Local Service. This is not a hardening preference; the product does not work that way.
Two reasons, and each is enough on its own:
- A Local Service account has no network identity, so it cannot authenticate to other Windows machines. Windows monitoring and Active Directory monitoring both stop working.
- NetCrunch stores configuration under
HKEY_LOCAL_MACHINE, which that account cannot write.
If your reason for wanting Local Service is to limit what the monitoring process can reach, the supported way to achieve that is the probe: run the probe on a separate machine with the privileges monitoring actually needs, and leave the server out of it.
Reducing what the server account needs is an active line of work, so the picture here is expected to improve in a future version. Today, the probe is the way to get it.
The account NetCrunch runs under is also what determines access to the data folder. Where the service does not run as LocalSystem, that account is granted access to the data tree alongside SYSTEM and the local Administrators group. See NetCrunch Security Features.
startup-script
The Startup Script
NetCrunch runs a startup script during server startup, before monitoring begins — useful for preparing anything monitoring depends on, such as mapping network drives.
SettingsNetCrunch SystemServerStartup Script
The script cannot be chosen from the console. It is a single fixed file that you place on the server machine yourself:
StartupScript.cmd- In the NetCrunch installation directory — not the data directory. The name is exact and there is no search: one file, one answer to why a script did or did not run. If it is not there, startup simply carries on.
This is deliberate, and it is the security property worth understanding. Defining what runs at server startup now requires write access to the installation directory, which already means local administrator on that machine. It is not something a remote caller can set.
This changed in this version. Earlier releases let the script be selected remotely, which meant an administrative client could choose what the server executed. Now the only thing that travels over the wire is how long to wait.
Wait Time
The one setting is how long NetCrunch waits for the script before carrying on with startup — up to 300 seconds, 30 by default.
Set it to 0 to start the script and continue immediately without waiting. If the script is still running when the wait time expires, NetCrunch resumes startup and leaves it running.
Output goes to StartupScript.log — but not next to the script. The log is written to the Logs folder of the NetCrunch data directory, which on a default installation lives under C:\ProgramData\AdRem\NetCrunch\.
The script and its log live in two different places: the script in the installation directory, the log in the data directory. That split follows the same rule as everything else here — the install directory is the privileged one you have to be an administrator to write to, and NetCrunch does not write logs there.
code-execution
Code That Runs on the Server
Some monitoring runs code rather than just reading values — script sensors, and alerting actions that launch a program. On a server probe, that code runs on the NetCrunch server, with the server's privileges.
For a hardened installation:
- Do not run script sensors against the server probe
- Do not configure actions that execute programs on the server
Neither is a limitation of the feature — both are useful, and both belong on a probe on another machine, where the same script does the same job without running next to the credential database.