All Products
Search

This Product

    Security Center:Best practices for core file monitoring

    Document Center

    Security Center:Best practices for core file monitoring

    Last Updated:Jun 02, 2026

    Security Center monitors critical server files in real time — tracking reads, writes, deletes, renames, and permission changes — and alerts you to potential theft or tampering. This topic covers monitoring rule configuration best practices and DingTalk chatbot alert setup.

    Host intrusion detection and core file monitoring

    Defense-in-depth is a cybersecurity best practice. Host intrusion detection identifies suspicious activity based on behavioral patterns. Core file monitoring complements it by detecting unauthorized changes to files and directories.

    Together, these features improve detection of complex threats. During a security incident, core file monitoring alerts help your security team trace attacker activities for incident response and forensic analysis.

    Core file monitoring also detects internal threats, such as malicious insider actions or operational errors.

    Rule configuration guidelines and examples

    The following guidelines cover common monitoring rule configurations. Rules may flag legitimate operations as false positives — the last table column lists examples of normal activities that might trigger alerts.

    To minimize false positives, use a gradual rollout:

    • Pilot testing: Deploy new rules on a small group of machines first.

    • Close monitoring: Monitor triggered events during the trial to verify rule accuracy.

    • Iterative refinement: Add whitelist rules for confirmed benign operations to reduce alert fatigue.

    • Full deployment: After rules stabilize with minimal false positives, deploy to more servers.

    Type

    Description

    Subtype

    Actions

    Example file paths

    Potential false positives

    Core system files

    These directories contain system commands and shared libraries. Monitoring them detects tampering such as planted malicious binaries or altered dependencies.

    System executable binary directories

    write, delete

    • /bin/*

    • /usr/bin/*

    • /sbin/*

    • /usr/sbin/*

    Package management installations and source compilations (make && make install) write to these directories. Configure whitelist rules for these operations.

    Shared library directories

    write, delete

    • /usr/lib/*

    • /usr/lib64/*

    Configuration files

    Attackers modify critical configuration files for purposes such as:

    • Add or modify user accounts to gain or escalate system access.

    • Modify DNS settings to perform DNS hijacking.

    • Alter logging configurations to evade or disrupt auditing.

    • Modify or disable security settings to achieve their objectives.

    • Tamper with the configuration files of operational applications to hijack the authentication process, bypass security measures, or escalate user privileges.

    • Modify web service configuration files to load malicious libraries or alter parsing rules to redirect traffic to malicious sites.

    User and permission files

    write

    • /etc/passwd

    • /etc/shadow

    • /etc/group

    • /etc/gshadow

    • /etc/sudoers

    • /etc/sudoers.d/*

    Standard commands (useradd, usermod, userdel, passwd) write to these files. Add whitelist rules based on your procedures, or use alert data for auditing.

    Critical system configuration files

    write, delete

    • /etc/resolv.conf

    • /etc/hosts

    Routine changes to network settings, name resolution, or kernel parameters modify these files.

    Configuration files for operational applications

    write

    • /etc/ssh/sshd_config

    • /etc/security/pam_env.conf

    • /*/.ssh/authorized_keys

    System maintenance, security hardening, and key rotation may modify these files. Configure whitelist rules accordingly.

    Security audit configuration files

    write, delete

    • /etc/audit/auditd.conf

    • /etc/audit/rules.d/*

    • /etc/selinux/config

    • /etc/rsyslog.conf

    • /etc/rsyslog.d/*

    Initial audit framework setup or policy adjustments for compliance modify these files.

    Web service configuration files

    write

    • /etc/httpd/conf/httpd.conf

    • /etc/httpd/conf.d/*

    • /etc/apache2/apache2.conf

    • /etc/apache2/sites-available/*

    • /etc/apache2/sites-enabled/*

    • /etc/nginx/nginx.conf

    • /etc/nginx/conf.d/*

    Initial setup, module changes, and web service updates modify these files.

    Database configuration files

    write

    • /etc/my.cnf

    • /etc/mysql/my.cnf

    • /etc/postgresql/*/main/postgresql.conf

    • /etc/postgresql/*/main/pg_hba.conf

    • /etc/mongod.conf

    • /etc/redis/redis.conf

    Database service installations and operational changes modify these files. Add whitelist rules as needed.

    Common persistence locations

    Attackers add scheduled tasks, malicious services, or startup scripts to maintain persistent access after reboots or during periodic execution.

    Cron-related files

    write

    • /etc/crontab

    • /etc/cron.d/*

    • /var/spool/cron

    • /etc/cron.hourly/*

    • /etc/cron.daily/*

    • /etc/cron.weekly/*

    • /etc/cron.monthly/*

    Normal crontab management modifies these files.

    Service-related files

    write

    • /etc/init.d/*

    • /etc/rc.d/rc.local

    • /etc/systemd/system/*

    • /lib/systemd/system/*

    Service-based application installations may modify system services.

    Shell configuration files

    write

    • /*/.bashrc

    • /*/.bash_profile

    • /etc/profile

    Operations staff modify these files to change environment settings or create command aliases.

    Web service code directories

    Monitoring web code directories detects webshell uploads and unauthorized changes such as page tampering or script injections. Attackers exploit vulnerabilities to upload webshells for remote server access.

    Web code directories

    write, permission change

    /var/www/html/<code dir>/*.php

    Service deployments, CMS plugin updates, and CI/CD tools (Jenkins, GitLab CI/CD, Ansible) write to these directories. Configure write process rules, exclude upload directories, or restrict file extensions.

    Files containing sensitive information

    Credential leakage is a major risk. After gaining host access, attackers search for credentials to perform lateral movement. Monitoring read operations on sensitive files helps detect these activities.

    Cloud service CLI authentication information

    read

    • /*/.aliyun/config.json

    • /*/.ossutilconfig

    Associated applications legitimately read these files — for example, Alibaba Cloud CLI reads ~/.aliyun/config.json and kubectl reads ~/.kube/config. Security scanners also access them. Account for these operations in your whitelist rules.

    Version control authentication information

    read

    /*/.git-credentials

    Database configuration

    read

    /*/config/database.yml

    Private keys for operations and orchestration systems

    read

    /*/.ssh/id_rsa, /*/.kube/config

    Configure DingTalk chatbot notifications

    Configure a DingTalk chatbot to receive real-time Security Center threat alerts in a DingTalk group.

    Note

    DingTalk chatbot notifications are supported only in the Enterprise and Ultimate editions of Security Center.

    Prerequisites

    Create a custom chatbot in the target DingTalk group and obtain its webhook URL. Configure a custom keyword in Security Settings that matches the notification language:

    • Chinese: 云安全中心

    • English: Security

    Procedure

    1. Log on to the Security Center console.

    2. In the left-side navigation pane, choose System Settings > Notification Settings. In the upper-left corner of the console, select the region where your assets are located: Chinese Mainland or Outside Chinese Mainland.

    3. On the Notification Settings page, click the DingTalk Chatbot tab, and then click Add Chatbot.

    4. In the Add DingTalk Chatbot panel, configure the parameters and click Add.

      Parameter

      Description

      Example

      Chatbot Name

      A custom name for the DingTalk chatbot.

      Core file alert notification

      Webhook URL

      The chatbot webhook URL, obtained from the DingTalk group.

      Important

      Keep the webhook URL confidential. A leaked URL poses security risks.

      https://oapi.dingtalk.com/robot/send?access_token=XXXX

      Asset Groups

      Select an asset group from the Security Center Assets page. The chatbot sends alerts for assets in the selected group.

      Alibaba Cloud

      Notify On

      Select alert types and risk levels for notifications. Available types: Vulnerability, Baseline Check, Alert, AccessKey Leak Detection, Cloud Honeypot, Application Protection, Anti-ransomware, Core File Monitoring, and Malicious File Detection.

      Core File Monitoring/Alert Level/Urgent

      Notification Interval

      Notification interval. Options: 1, 5, 10, or 30 minutes. No limit sends each alert in real time (maximum 20 per minute per webhook).

      30

      Language

      Notification language: Chinese or English.

      Chinese

      The chatbot is Enable by default. Security Center sends notifications per your configured policy.

    5. (Optional) Find the chatbot in the list and click Test in the Actions column to verify the connection.

    Related topics