File Integrity Monitoring administration

FIM stores a SHA fingerprint for important executable and configuration files at an administrator-approved point in time. Later scans classify differences as Added, Modified, or Deleted. It detects and preserves evidence; it does not change NTFS permissions and does not assume that every change is an attack.

In the layered model, FIM is the persistence tripwire. A web shell, replacement DLL, modified handler, startup/configuration change, or deleted defensive file cannot match the approved baseline unless an administrator deliberately accepts it. Realtime scanning decides whether the artifact is malicious; FIM independently proves that a protected file appeared or changed. Those two findings together provide stronger containment evidence than either a signature or a hash alone.

Reviewing a false positive before baseline approval

FIM reports change, not intent, and the scanner deliberately gives weight to behaviors commonly used by attackers. Therefore, an approved custom module or administration component can sometimes produce a Review or false-positive finding. This is acceptable when it is investigated and documented; it is not a reason to weaken detection for the whole site.

Use Create Baseline or Refresh Baseline only after validating the exact path and hash against the approved package/source, confirming the deployment window and publisher, explaining the triggered rule/AST/AI evidence, and checking for related intrusion signals. The baseline should accept only the verified state. A later content/hash change must reopen the finding and be scanned again. Files of unknown origin, executable artifacts under upload folders, or findings associated with unexpected accounts, WAF activity, persistence, or outbound connections must remain under investigation and must not be baselined.

Default scope

Protected types include ASPX, ASCX, ASHX, ASMX, ASAX, SVC, server templates, CONFIG, PHP/ASP/JSP, managed DLL, and EXE artifacts. Important locations include bin, web.config, server-side root files, module code, and executable files newly appearing under Portals.

High-churn locations such as App_Data, caches, logs, temporary folders, build output, node_modules, source-control data, DNN Defender storage, quarantine, and coverage output are excluded. Within Portals, ordinary media, documents, CSS, .js, and .map files are not added to the integrity baseline.

Does FIM back up the whole DNN site?

No. For each protected file in the baseline, FIM stores a hash and can keep one compressed recovery copy when the file is no larger than the configured 10 MiB default. Recovery copies are stored under App_Data\DNNDEFENDER\FIM_Backups; baseline metadata is stored in App_Data\DNNDEFENDER\fim-db.json.

FIM does not back up the DNN database, all of App_Data, media libraries, normal JavaScript/CSS, or every site file. It is not a replacement for a full website and database backup.

Storage estimate

Approximate storage is the total compressed size of protected baseline files at or below the recovery limit, plus metadata and any retained orphan recovery copies. The theoretical maximum is protected file count × 10 MiB, but the practical size is normally much lower because files are compressed and larger files are hash-only. Monitor the backup directory after large upgrades and also maintain an operating-system disk-space alert.

Does FIM restore automatically?

No. Immediate automatic rollback could overwrite a valid DNN or module deployment and break the site. An administrator can restore an eligible Modified or Deleted file from its baseline copy. Added files have no baseline copy and must be investigated, isolated, or removed through the incident workflow. Files above the recovery-size limit must be restored from the release package or an external backup.

Approved module/DNN deployment

1. Start FIM Maintenance Mode and record the change ticket or reason.
2. Install the verified DNN/module/skin package.
3. Test login, affected pages, Event Log, and critical functionality; run a malware scan.
4. Review the file differences. Do not hide unrelated suspicious findings in the new baseline.
5. Check the approval statement and choose Refresh Baseline & Resume.

If you end maintenance without refreshing, the next scan reports the differences against the old baseline. Maintenance expires automatically and temporarily suspends restore and scheduled integrity enforcement so it cannot interfere with a valid deployment.

Daily health check

Confirm Integrity monitoring healthy, Protected Files > 0, the expected Last Baseline, a successful recent scan/scheduler run, and zero unexplained Open Violations. Zero violations alone does not establish that the site is secure.