The core file monitoring feature monitors access to core files on servers in real time. The feature can monitor file operations such as read, write, delete, rename, and permission change, and generate alerts for suspicious operations. You can use the feature to prevent your core files from being stolen or tampered with. This topic provides examples on how to configure the core file monitoring feature and notification settings on the DingTalk Chatbot tab to receive alerts in real time.
Relationship between host intrusion detection and core file monitoring
Multi-layered and in-depth defense strategies are recommended for cybersecurity practices. In most cases, the host intrusion detection feature is used to detect suspicious intrusions based on intrusion characteristics. The feature focuses on known or unknown malicious behavior and system activities. The core file monitoring feature focuses on monitoring the integrity of files and directories in file systems and detecting unauthorized modifications.
The preceding features complement each other and provide comprehensive protection to improve the efficiency of detecting complex threats. Understanding attacker behavior is crucial in response to security events. If an attacker reads or modifies files within the protection scope of a monitoring rule that you create, the core file monitoring feature generates alerts to help operations personnel trace the detailed activities of the attacker and perform response and investigation in an efficient manner.
The core file monitoring feature can detect not only external threats but also internal threats, such as malicious behavior or misoperations performed by internal personnel.
Configuration rules and examples
This section describes the configuration rules and examples of the core file monitoring feature. The following table describes the common scenarios and how to configure monitoring rules. If normal O&M activities are identified as attacker behavior by the monitoring rules executed on different user systems, the rules can generate false positives. The last column of the following table provides examples of normal operations that may trigger alerts.
To minimize the impact of false positives on system O&M, we recommend that you gradually test monitoring rules before you deploy them on various user systems. The following list describes the steps:
Small-scale trial: During the initial phase, select a small number of servers to apply the monitoring rules.
Thorough monitoring: During the small-scale trial period, carefully monitor the hit details of each rule to verify rule accuracy and applicability.
Iteration and improvement: Review the protection effectiveness of the rules. If specific O&M activities trigger alerts and you confirm that the activities are not threats, configure whitelist rules for the activities. This way, critical O&M activities do not trigger alerts, and the number of alerts that must be managed is reduced.
Official deployment: After you test and optimize the monitoring rules several times and confirm that the hit rate of the rules is stable and false positives are eliminated, you can apply the monitoring rules to different servers.
File type | Description | File sub-type | Behavior | File path example | Operation that may trigger false positives |
Core system files | This type of directory includes the most system commands and shared link libraries. Monitoring rules created for these directories can help detect potential malicious tampering by attackers, including the insertion of malicious binaries or tampering of system dependencies. | Executable system binary directories | Write and delete |
| Activities such as installations or updates performed by using package management software can also write data to the directories. If you manually retrieve source code from a code repository and then compile the code to install software, you may accidentally write data to the directories. In most cases, the make && make install command is used. To prevent normal operations from triggering alerts, you must configure whitelist rules based on your business requirements. |
Shared library directories | Write and delete |
| |||
Configuration files | Attackers may modify different key system configuration files to launch attacks. Examples:
| Files related to users and permissions | Write |
| Normal operations such as operations performed by using the useradd, usermod, userdel, and passwd commands may write data to the files. You can create appropriate whitelist rules based on specific O&M rules, or use alert data as audit logs. |
Key system configuration files | Write and delete |
| The files are modified by performing O&M tasks that modify network settings, name resolution settings, and kernel parameters. | ||
Configuration files of O&M applications | Write |
| The files may be modified during system maintenance, configuration updates, security hardening, or periodic key rotation. We recommend that you create appropriate whitelist rules. | ||
Configuration files of security audit | Write and delete |
| The first time you configure the audit framework of a system or when you modify monitoring rules to meet compliance and security requirements, the files may be modified. | ||
Configuration files of web services | Write |
| Initial configuration of web services, post-installation settings, addition and removal of related modules, and updates to web services may result in modifications to the files. | ||
Configuration files of databases | Write |
| The files may be modified due to installation and O&M changes of database services. We recommend that you create appropriate whitelist rules based on your business requirements. | ||
Common persistence mechanisms | Attackers can add scheduled tasks, malicious services, or startup scripts to maintain persistent access during periodic execution or after system restarts. | Cron | Write |
| Normal O&M operations may add, adjust, or delete existing crontab entries, which results in modifications to cron files. |
Services | Write |
| When you install specific service applications, operations on system services, such as addition and modification operations, can occur. | ||
Shell configurations | Write |
| When O&M personnel change the default environment settings or create aliases for frequently used complex commands, related files may be modified. | ||
Code directories for web services | Rules that monitor the code directories of web services help ensure the security of web applications. In most cases, attackers exploit vulnerabilities or unauthorized access to upload malicious webshell files. The webshell files allow attackers to remotely access, control, and manage compromised servers. Monitoring the code directories of web services can effectively detect potential webshell uploads and unauthorized changes, such as web page tampering and malicious script injections. | Web code directories | Write and permission change |
| Routine business and maintenance operations, such as service updates, service deployments, and the installation and updates of plug-ins and themes for a specific content management system (CMS), may write web script files to the code directories. Specific automated deployment tools such as Jenkins, GitLab CI/CD, and Ansible may also write files during the continuous integration and deployment process. In these cases, you must configure specific write processes, or restrict directories that allow external file uploads and limit specific file suffixes to ensure security. |
Files containing sensitive content | Sensitive authentication information leakage is one of the primary risks in cybersecurity. After attackers gain access to a host, they search for sensitive information to perform lateral movements and expand their intrusion footprint. Monitoring read operations on files that contain sensitive content can effectively detect intrusions or malicious activities at the earliest opportunity. | Authentication information of cloud service CLIs | Read |
| In most cases, files that contain sensitive information are read by the applications to which the files belong. For example, Alibaba Cloud CLI reads |
Authentication information for version control | Read |
| |||
Database configurations | Read | / | |||
Private key information of O&M and orchestration systems | Read |
|
Configure notification settings on the DingTalk Chatbot tab
After you configure the notification method of DingTalk chatbots, you can receive notifications for threats that are identified by Security Center in the specified DingTalk group in real time.
Only the Enterprise and Ultimate editions of Security Center support the notification method of DingTalk chatbots.
Prerequisites
A DingTalk chatbot has been created in the DingTalk group that is used to receive notifications, and the webhook URL of the chatbot is obtained. When creating the DingTalk chatbot, you should configure the keywords based on the notification language in the Security Settings.
Chinese: 云安全中心
English: Security
Procedure
Log on to the Security Center console. In the top navigation bar, select the region of the asset that you want to manage. You can select China or Outside China.
In the left-side navigation pane, choose .
On the Notification Settings page, click the DingTalk Chatbot tab and click Add Chatbot.
In the Add DingTalk Chatbot panel, configure the parameters and click Add. The following table describes the parameters.
Parameter
Description
Example
Chatbot Name
The name of the chatbot. We recommend that you enter an informative name.
Core file alert notification
Webhook URL
The webhook URL of the chatbot. You can obtain the webhook URL in the corresponding DingTalk group.
ImportantKeep the webhook URL confidential. If the webhook URL is leaked, risks may arise.
https://oapi.dingtalk.com/robot/send?access_token=XXXX
Asset Groups
The asset group for which you want to send notifications. You can select an asset group that is created on the Assets page. After you select the asset group, the DingTalk chatbot sends notifications that are related to the assets in the asset group.
Alibaba Cloud
Notify On
The types and the severity levels of alerts for which you want to send notifications. The types are Vulnerability, Baseline Check, Alert, AccessKey Pair Leak Detection, Cloud Honeypot, Application Protection, Anti-ransomware, Core File Monitoring, and Malicious File Detection.
Core File Monitoring/Alert Level/Urgent
Notification Interval
The time interval at which the DingTalk chatbot sends notifications. Valid values: 1 Minute, 5 Minutes, 10 Minutes, 30 Minutes, and No Limit. If you select No Limit, a notification is sent each time an alert is generated.
If you select No Limit, up to 20 notifications can be sent to the webhook URL within 1 minute.
30
Language
The language of the notifications. Valid values: English and Chinese.
Chinese
By default, a new DingTalk chatbot is in the Enabled state. After you complete the preceding steps, Security Center sends notifications based on your configurations.
Optional. In the list of DingTalk chatbots, find the new DingTalk chatbot and click Test in the Actions column to check whether a notification is received in the DingTalk group.
References
Use the web tamper proofing feature to prevent website files or directories from being tampered with.