All Products
Search
Document Center

Security Center:Best practices for configuring the core file monitoring feature

Last Updated:Jul 19, 2024

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.

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

  • /bin/*

  • /usr/bin/*

  • /sbin/*

  • /usr/sbin/*

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

  • /usr/lib/*

  • /usr/lib64/*

Configuration files

Attackers may modify different key system configuration files to launch attacks. Examples:

  • Attackers can add or modify user account records to continuously gain access to a system or escalate their privileges on the system.

  • Attackers can modify Domain Name System (DNS) resolution settings to implement DNS hijacking.

  • Attackers can modify logging configurations to disrupt or evade auditing.

  • Attackers can modify or disable specific security settings to launch attacks.

  • Attackers can tamper with configuration files of O&M applications to hijack authentication processes and then bypass security measures or escalate privileges for specific users.

  • Attackers can modify configuration files of web servers to load malicious library files or modify DNS resolution settings to redirect traffic to malicious websites.

Files related to users and permissions

Write

  • /etc/passwd

  • /etc/shadow

  • /etc/group

  • /etc/gshadow

  • /etc/sudoers

  • /etc/sudoers.d/*

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

  • /etc/resolv.conf

  • /etc/hosts

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

  • /etc/ssh/sshd_config

  • /etc/security/pam_env.conf

  • /*/.ssh/authorized_keys

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

  • /etc/audit/auditd.conf

  • /etc/audit/rules.d/*

  • /etc/selinux/config

  • /etc/rsyslog.conf

  • /etc/rsyslog.d/*

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

  • /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 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

  • /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

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

  • /etc/crontab

  • /etc/cron.d/

  • /var/spool/cron

  • /etc/cron.hourly/*

  • /etc/cron.daily/*

  • /etc/cron.weekly/*

  • /etc/cron.monthly/*

Normal O&M operations may add, adjust, or delete existing crontab entries, which results in modifications to cron files.

Services

Write

  • /etc/init.d/*

  • /etc/rc.d/rc.local

  • /etc/systemd/system/*

  • /lib/systemd/system/*

When you install specific service applications, operations on system services, such as addition and modification operations, can occur.

Shell configurations

Write

  • /*/.bashrc

  • /*/.bash_profile

  • /etc/profile

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

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

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

  • /*/.aliyun/config.json

  • /*/.ossutilconfig

In most cases, files that contain sensitive information are read by the applications to which the files belong. For example, Alibaba Cloud CLI reads ~/.aliyun/config.json to load authentication information, and kubectl reads ~/.kube/config to retrieve the Kubernetes certificate information. Specific security software may scan this type of files to identify malicious files on a server. You must consider these normal read operations when you create whitelist rules.

Authentication information for version control

Read

/*/.git-credentials

Database configurations

Read

/*/config/database.yml

Private key information of O&M and orchestration systems

Read

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

References