Know-how for IT administrators and MSP partners
Trust Center
Practical guidance: how to configure and verify the solution safely, and what to do when something goes wrong. You'll also find what the solution doesn't do.
What protection rests on
Six principles behind every guide on this page.
Open nothing from outside
The agent doesn't listen on the network and connects to the console itself. Allowing outbound traffic is enough.
Keep the key in your hands
Backups are encrypted on the machine and the key never leaves it. Nobody else can decrypt them, so guard your copy of the key.
Assume a breach
An attacker may gain administrator access. At least one backup copy must stay out of their reach.
Prove backups by restoring
A finished job doesn't mean a working restore. Only a regular test gives you certainty.
Prepare your response early
There's no time to invent a procedure during an attack. Decide in advance who does what and what may be disconnected.
Grant only the access needed
Give everyone the lowest role that lets them do their job, and review access regularly.
Preparing the network
A standard deployment needs no port forwarding, public IP address or VPN. Just check outbound traffic.
| From | To | For |
|---|---|---|
| Protected machine | console.intellidefender.com, port 443 | Enrollment, control and update downloads |
| Protected machine | Your backup storage address | Transfer of already encrypted backups |
| Administrator's browser | console.intellidefender.com, port 443 | Working in the console |
| Internet | Protected machine | Nothing, no inbound port is needed |
- If the firewall allows only known addresses, add the console and the storage
- TLS inspection must not block WebSocket, or the agent won't connect
- Keep NAS and server management off the internet and use a VPN for access
- The agent reconnects by itself after an outage, no action needed
First deployment
The procedure for one machine. With several machines, try it on a less critical one first.
- 01
Create a code
Agents → Add agent. The code is single-use, belongs to one company and is valid for 24 hours by default.
- 02
Run the command
Run it with administrator rights. The core installs and the machine appears in the console within a minute.
- 03
Add modules
Approve Backup, and Guard if needed, on the agent's page. Nothing else installs without approval.
- 04
Store the key
Right after installing the Backup module, save the master key off the machine.
- 05
Verify a restore
After the first backup, restore a data sample to another location. Only then consider deployment finished.
Install commands
- Windows Server (PowerShell)
$t='enr_…'; irm https://console.intellidefender.com/install.ps1 | iex- Linux / Synology (SSH)
curl -fsSL https://console.intellidefender.com/install.sh | sudo sh -s -- enr_…
The console shows the exact command with your code. Supported systems are Windows Server, Linux with systemd (Ubuntu, Debian, RHEL) and Synology DSM 7. On Synology without SSH, use the package from the console: the agent needs root, so run a Task Scheduler task once and keep it enabled at startup.
Managing the master key
The key is the one thing nobody can rescue for you. Without it, backups are unreadable after a machine is lost, even for us.
- 01
Print the key
Run the command below on the machine with administrator rights.
- 02
Store it elsewhere
In a company password vault, or sealed in a physical safe. Never on the same machine.
- 03
Keep a record
Note the machine name and the fingerprint from the console, so you know years later which key belongs to which backup.
- 04
Try it
During a restore test on another machine, verify that the stored key really works.
Commands
- Print the key on the source machine
id-backup show-key- Add the key on the target machine
id-backup import-key -agent <agent-id> -key <hex>
Each machine has its own key. Anyone holding the key and access to the storage can read all of that machine's backups. Treat it as the most sensitive password in the company.
Designing backups
A good policy starts with how much data you can afford to lose and how quickly you must be running again.
- Set priorities
- Divide data into critical, important and other. Back up critical data more often and with a longer history.
- Back up databases as databases
- Don't copy their data files while they run. Set up a PostgreSQL, MySQL or MS SQL policy so the backup is consistent.
- Follow the 3-2-1-1-0 rule
- Three copies, two storage types, one off-site, one immutable and zero errors in restore tests.
- Schedule off-peak
- The first backup transfers everything, later ones only changes. On slow links, set a time window and bandwidth limit.
- Exclude what's useless
- Temporary files and caches add volume with no benefit. Still, when excluding, prefer to back up too much rather than too little.
- Fit retention to your needs
- Attacks and mistakes are often found late. Keep weekly and monthly versions as well as daily ones.
Immutable storage
With access credentials, an attacker deletes ordinary storage. Immutable storage prevents this for the lock period.
- 01
Create a new bucket
Enable Object Lock at creation. Providers often don't support enabling it later.
- 02
Choose a mode
Against an attacker with administrator access, choose Compliance. Governance can be bypassed with a permission.
- 03
Set the lock period
It must be longer than the time you need to detect an attack. Typically 14 to 30 days.
- 04
Adjust the lifecycle
Have old versions removed after the lock period + 1 day, or space is never freed.
- 05
Verify it
Try deleting a locked object directly at the provider and check that its version remains.
Watch the costs: during the lock you pay for deleted data too, and a Compliance lock can't be shortened. Start with a shorter period and extend it once you know your change volume. A local directory doesn't have this protection.
Restore testing
We recommend testing at least once a quarter and after every major change to the environment.
- Restore to another location or machine, never over production data
- Open the restored files and start the application, checking size isn't enough
- Restore the database and check recent records in it
- At least once a year, restore to another machine using the key from the vault
- Measure the restore time and compare it with what you promise management
- Record the date, scope, result and name. You'll use the record in audits
Configuring Guard
Guard recognizes mass file encryption. It works best when rolled out in stages.
- 01
Choose folders
Protect company shares and user data, not the whole disk or folders that applications constantly rewrite.
- 02
Start with defaults
Emergency snapshot and backup protection are on. Leave SMB isolation off for now.
- 03
Watch for a week
See whether batch jobs, encrypted archives or migrations cause false alarms.
- 04
Tune sensitivity
With false alarms, raise the file or finding count. For critical data, lower them instead.
- 05
Enable isolation
Only once you trust the alarms. Isolation disconnects all share users, not just the attacker.
Verify the result with a controlled test on a trial folder of copied data, not on production. On Windows, keep the firewall on for all profiles, or isolation won't apply everywhere.
During an attack
Print this and keep it handy. Your documentation may also be unavailable during an attack.
- 01
Confirm and isolate
Open the incident and review the affected files. If the attack is real, disconnect the source of encryption from the network.
- 02
Protect evidence and backups
Delete nothing and don't reinstall right away. Check that the agent has an active hold.
- 03
Find the source
Find which computer or account changed the files, block it and change passwords. Guard won't do this for you.
- 04
Pick a clean point
The incident shows the last backup before it started. Verify it by restoring elsewhere, as the attack may have begun earlier.
- 05
Restore and release
Clean the environment first, then restore data. Finally resolve the incident, which releases SMB and the hold.
- Don't pay a ransom without consulting specialists and a lawyer
- If NIS2 applies to you, watch the deadlines: early warning within 24 hours and notification within 72 hours
- The emergency snapshot is on the same volume, so check it's still available after the attack
- After the incident, add what the procedure was missing and repeat a restore test
Safe updates
Nothing updates by itself. You decide when and where a new version is deployed.
- 01
Read the changes
Find out which components the new version affects.
- 02
Try a pilot
First update one less critical machine.
- 03
Check its state
Make sure the agent is online and a backup completes.
- 04
Roll out
Then approve the rest of the company, ideally outside the backup window.
- 05
Check the result
With rolled_back status, the machine returned to the old version itself. Find out why and don't continue.
Practices for MSP partners
With many customers, order decides everything. These habits prevent most problems.
- Each customer separately
- Their own company in the console, their own storage and credentials. One customer's problem then doesn't spread to others.
- Agree who holds the key
- Decide in writing who keeps the keys: you, the customer or both. Also cover what happens to them when the contract ends.
- Roles as needed
- Give tenant_admin only to those who manage backups, as it can also start restores. tenant_viewer is enough for management and reviewers.
- When someone leaves
- Disable the account immediately and review the audit log. If they had access to keys or S3 credentials, change those too where possible.
- One standard
- Prepare a policy template and a deployment procedure. Record any customer deviations.
- Regular review
- Once a quarter, go through failed backups, incidents, restore test results and access with the customer.
What the console sees
The answer to a common security questionnaire item. The console controls agents, but backup contents never reach it.
The console stores
- Machine name, operating system, versions and last IP address
- Policies, including paths and database names
- A backup overview: paths, time and statistics
- Job status and logs
- Paths of files affected in an incident
- Accounts, the audit log and encrypted storage credentials
The console does not store
- The backup repository master key
- The contents of backed-up files and databases
- The contents of files inspected by Guard
- User passwords in readable form
Path and machine names can be sensitive, so keep that in mind when naming them. You set the backup location by choosing the store.
Known limitations
A risk assessment also needs to know what the solution doesn't do, and how to cover it.
- The console has no 2FA
- Sign-in uses e-mail and password. Use strong, unique passwords from a vault and review access regularly.
- The key isn't backed up for you
- Without a copy, backups can't be restored after a machine is lost. See the key management guide.
- Guard won't catch everything
- It can miss very small files and slow encryption below the set threshold. It doesn't replace endpoint protection or backups.
- Guard doesn't stop the attacker
- It doesn't block an IP address or a process. Isolation covers SMB shares, not NFS, and has to be enabled.
- Snapshots aren't universal
- On Linux they require Btrfs, and they sit on the same volume. They don't replace an off-machine backup.
- Verification doesn't replace a restore test
- Regular backup verification must be enabled in the policy and confirms data is readable. It doesn't check that a database loads or an application starts.
- Blocks aren't compressed
- When planning capacity, count on savings from deduplication, not compression.
- First installation
- The agent checks signatures for updates and modules. Run the install command only from your own console.
NIS2 evidence
What to prepare for Article 21(2) of the NIS2 Directive. Technical features help, but compliance also covers organizational measures and depends on your configuration.
| Requirement | What to prepare as evidence |
|---|---|
| Incident handling (b) | A printed attack procedure, incident records from the console, named responsible people |
| Continuity and backup (c) | Backup policies, immutable storage settings, restore test records |
| Suppliers and maintenance (d, e) | A supplier register, a history of approved updates |
| Cryptography (h) | Rules for key storage and a record of key holders |
| Access control (i) | A list of accounts and roles, regular access reviews, the audit log |
| Multi-factor authentication (j) | Not yet supported by the console; describe a compensating measure |
More about NIS2|For questions about certifications, audits and sub-processors, contact [email protected]
Troubleshooting
Answers to the questions administrators ask most.
Where do I find the agent logs?
In the data directory, in the logs subfolder. On Windows that's %ProgramData%\IntelliDefender, on Linux /var/lib/intellidefender and on Synology /volume1/@intellidefender.
The agent won't connect to the console. What should I check?
Check the outbound connection to console.intellidefender.com:443, DNS, and whether a proxy or TLS inspection is blocking WebSocket. Then look at core.log and the output of intellidefender status.
If the log reports that the agent was rejected, it has been disabled or deleted in the console.
What does the agent do when the console is unreachable?
Modules keep working locally with the last configuration, and Guard responds on the machine without the console. The console creates the incident and hold only once the connection is back.
How do I restore a backup on another machine?
Add the source agent's master key to the target machine with id-backup import-key, then start the restore from the console, choosing the target machine and folder.
After reinstalling, the agent reports a different key.
To read old backups, put the original key back from the vault. If a new key is intended, reset the fingerprint on the agent's page. The reset doesn't change the key or the data.
How do I uninstall the agent?
Run intellidefender uninstall with administrator rights. On Synology, first run sudo /volume1/@intellidefender-program/intellidefender uninstall, and only then remove the package. Check your master key is in the vault beforehand.
Shares are still blocked after an incident.
Resolve the incident in the console or use Release SMB on the agent's page. The firewall rules are removed once the command reaches the machine, so the agent must be online.
Guard reports false alarms.
Find out which job changes files in bulk. If it's normal activity, adjust the protected folders or raise the sensitivity thresholds in the policy. Avoid turning Guard off completely.
Preparing a security review?
Send us your questions or questionnaire. You can report security findings through the same contact.
Contact us