Core file monitoring tracks access to critical files on your servers in real time. It detects read, modify, delete, and rename operations, generates alerts on suspicious activity, and helps you determine whether files have been stolen or tampered with.
Prerequisites
Before you begin, make sure that:
Your Security Center edition is Enterprise Edition or Ultimate Edition. To upgrade, see Purchase Security Center and Upgrade and downgrade Security Center
The Security Center agent is online on the target server. The
icon indicates the agent is onlineThe server's operating system and kernel version are supported by the AliWebGuard file. For details, see Supported operating systems and kernel versions of the AliWebGuard file
How it works
Security Center evaluates each file access request against your monitoring rules. A rule is triggered only when a request matches all three of the following conditions in that rule:
Process path
File path
File operation
When Security Center evaluates a request, it checks allow rules first. If the request matches an allow rule, it is permitted without generating an alert. If no allow rule matches, Security Center checks alert rules. If an alert rule matches, Security Center generates an alert and records the event.
Step 1: Create a rule
Rule design
For each core file you want to protect, configure two rules together:
An alert rule — set the process path to
*(all processes) to catch any access that is not explicitly allowed.One or more allow rules — set the process path to each trusted process that legitimately accesses the file.
This combination ensures all access is monitored while suppressing alerts for expected behavior.
Always configure an alert rule covering all processes (*) before creating allow rules. Without it, processes outside the specified paths bypass monitoring entirely.
Do not use a wildcard in an allow rule's process path. A wildcard allow rule lets any process bypass monitoring, which attackers can exploit.
Example: To monitor /etc/sysctl.conf and allow only systemd to access it, create two rules:
| Rule | Handling method | Process path | File path | File operation |
|---|---|---|---|---|
| Rule 1 | Alert | * | /etc/sysctl.conf | All |
| Rule 2 | Allow | /usr/lib/systemd/systemd | /etc/sysctl.conf | All |
To monitor the same file across multiple servers, use a single alert rule with the file path and * as the process path, then create per-server allow rules for each trusted process path.
For additional configuration examples, see Best practices for configuring the core file monitoring feature.
Create a rule
Log on to the Security Center console. In the top navigation bar, select the region of the asset you want to manage. Supported regions: China and Outside China.Log on to the Security Center console.
In the left-side navigation pane, choose Protection Configuration > Host Protection > Core File Monitoring.
If you are using Security Center Advanced or a lower edition, click Buy Now to purchase Security Center Enterprise or Ultimate.
On the Core File Monitoring page, click the Monitoring Rule tab, then click Create Whitelist Rule.
In the Create Whitelist Rule panel, configure the parameters and click OK.
Parameter Description Rule name Enter a name for the rule. Handling method Select what Security Center does when the rule is triggered. Alert: generates an alert and records an event. Allow: permits the request without generating an alert or recording an event. Alert level Required only when Handling method is set to Alert. Select the severity for generated alerts. OS type Select the operating system type of the server to monitor. Status Enable or disable the rule after creation. Up to 100 rules can be enabled at a time. Process path Enter the path of the process to monitor. To monitor a single process, enter the exact path (for example, /usr/bin/bash). To monitor all processes in a directory, use a wildcard (for example,/etc/*). Each path must be 1–128 characters. Enter one path per line, up to 20 paths.Note/etc/matches only the path/etc/itself, not processes under that directory. Use/etc/*to match all processes under/etc/.File path Enter the path of the file to monitor. To monitor a single file, enter the exact path (for example, /etc/passwd). To monitor all files in a directory, use a wildcard (for example,/etc/*). Each path must be 1–128 characters. Enter one path per line, up to 20 paths.Note/etc/matches only the specific path/etc/, not all files under that directory. Use/etc/*to match all files under/etc/.File operation Select the file operations to monitor. NoteChange permissions is not supported on Windows.
Rule scope Select the servers to apply this rule to.
After the rule is created, it takes effect within 5 minutes for a first-time enable on a server. If you modify a rule, it takes effect within 1 minute. Existing alerts and recorded events are not affected when a rule takes effect.
To modify, delete, enable, or disable a rule, use the Status column or Actions column on the Monitoring Rule tab.
Step 2: View and handle alerts
On the Core File Monitoring page, click the Alert Event tab to see all alerts generated by Security Center for file access.
Find the alert to review and click Details in the Actions column to see the file access details. Security Center collects command-line interface (CLI) information after shell parsing and displays it as a JSON array. The displayed command may differ from the original input.
Example 1: The command
mkdir "1 2"(equivalent tomkdir 1\ 2) is displayed as["mkdir", "1 2"]after shell parsing.Example 2: The command
rm -rf *expands*to all files and subdirectories in the current directory. Security Center displaysrm,-rf, and the full list of expanded paths.
Security Center cannot collect detailed CLI information for Python scripts or shell built-in commands. For example,
echo "new content" >> /etc/nginx/nginx.confis a shell built-in command; the alert details page displays["-bash"]as the collected CLI information.Based on the alert details, determine whether the access is abnormal.
After reviewing the alert, click Handle in the Actions column and select a handling method.
Whitelist: Security Center automatically creates an allow rule for the detected behavior. Configure the Whitelist rule name, Process path, File path, File operation, and Rule scope parameters, then click OK.
Ignore: The alert status changes to Ignored. If the same behavior is detected again, Security Center generates a new alert.
Handle manually: Select this option if you have already addressed the abnormal event.
If the access is abnormal and affects your business, manually block the related processes and quarantine the related files.
Core file monitoring supports DingTalk Chatbot notifications only. After configuration, you receive real-time alerts in your DingTalk group. For setup instructions, see Configure notification settings on the DingTalk Chatbot tab.
FAQ
What are the differences between web tamper proofing and core file monitoring?
Both features protect files on your servers, but they serve different purposes.
| Item | Web tamper proofing | Core file monitoring |
|---|---|---|
| Scenario | Protecting assets such as websites that are vulnerable to attacks and sensitive to file tampering | Monitoring access to core files to detect content theft; monitoring file changes (modify, delete, rename) to detect tampering |
| Protection scope | Most Linux and Windows servers | Most Linux and Windows servers |
| Billing | Value-added service (purchased separately) | Included in Enterprise Edition and Ultimate Edition |
| Capability | Identifies abnormal file changes; can block related processes or generate alerts | Monitors abnormal file access, including read, modify, and delete operations; generates alerts |
Which feature takes priority when both are enabled?
Web tamper proofing takes priority. When both features are enabled on a server, Security Center first matches requests against web tamper proofing rules. If no match is found, it then evaluates core file monitoring rules.
Web tamper proofing's process allowlist rules apply only while web tamper proofing is active. Core file monitoring's allow rules apply only while core file monitoring is active.