C100 after-sales support FAQ
This topic covers common issues and solutions for the C100 series of Database Audit.
-
Agent-related issues
-
Database Audit instance configuration issues
-
What permissions can I grant to a RAM user for Database Audit?
-
How do I add servers from different regions, VPCs, or accounts to the Database Audit system?
-
How do I configure auditing for local traffic to the database IP address '127.0.0.1'?
-
How do I troubleshoot the issue where no data is audited by Database Audit?
-
How do I configure auditing for TLS/SSL-encrypted database traffic?
-
-
Log Service (SLS) storage issues
Agent installation directory (Cloud Assistant)
Linux: /data/dbAuditAgent.
Windows: C:\dbagent\dbagent2.*.
You can use one-click installation for an agent only on ECS instances with Cloud Assistant installed. The agent starts automatically after installation.
Agent log directory (Cloud Assistant)
Linux
-
Log files: The directory contains
logfiles named with the date.
Windows
-
Log directory:
C:\dbagent\dbagent2.*. -
Log files: The directory contains
logfiles named with the date.
Missing wpcap.dll file during installation
If you see the error "The program can't start because wpcap.dll is missing from your computer" when installing the agent on Windows, WinPcap is not installed.
To resolve this issue, install WinPcap:
-
Run the uninstallation script to uninstall the agent.
-
Reinstall the agent. For more information, see Manually install an agent. During the installation, select the option to install Npcap.
Agent installation in a containerized environment
Yes, you can.
Typically, you can install the agent on the host server where the Docker container runs to collect traffic from all containers. If your containers are deployed in a Kubernetes cluster, you must install an agent on the host server of each new node. You can use Cloud Assistant to quickly install agents. For more information, see Install an agent.
In special cases, if you need to install the agent inside a container, see Manually install an agent.
Uninstalling an agent
Uninstalling a Cloud Assistant agent
On the Agent Management page, go to the Agent Management tab, select the agent instance that you want to uninstall, and click Uninstall at the bottom of the list.
After the uninstallation is complete, delete the agent. In the agent list, find the uninstalled agent and choose Delete from the More drop-down list in the Actions column.
Uninstalling a manually installed agent
-
Linux server
-
Log on to the Linux server as the root user.
-
Go to the agent installation directory
/data/dbAuditAgent/dbagent2.*. You can run theps -ef |grep dbagentcommand to view the agent installation directory. -
Run the
./uninstall.shcommand to uninstall the agent service, and then delete the agent installation directory.ImportantMake sure to delete the agent installation directory only after the uninstallation is complete. Otherwise, errors may occur during subsequent installations.
-
-
Windows server
Go to the
C:\dbagent\dbagent2.*folder and rununins000.exeas an administrator to complete the uninstallation.
Agent processes
The agent includes two processes: dbAgent.exe and dbMonitor.exe.
-
dbAgent is responsible for traffic forwarding. You can run the
netstat -ano |findstr 13001command on Windows or thenetstat -ano |grep 13001command on Linux to check the connection status. -
dbMonitor controls the service. This includes receiving asset and other configuration information from Database Audit and managing the runtime of dbAgent. You can run the
netstat -ano |findstr 13002command on Windows or thenetstat -ano |grep 13002command on Linux to check the connection status.
Abnormal agent connection on on-premises servers
Symptom: The network between the on-premises IDC server and the Virtual Private Cloud (VPC) where Database Audit is located is connected. However, after the agent is installed on the on-premises IDC server, the connection status is abnormal, and traffic cannot be collected for auditing.
Cause: By default, the Database Audit address specified by the
serviceIpparameter in theagent.iniconfiguration file is a domain name. Due to a DNS resolution issue on the server, the domain name cannot be resolved to the IP address of the Database Audit service. This causes the connection to fail, which results in an abnormal connection status.
Analysis
Check the agent logs. The log paths are as follows:
Linux:
/data/dbAuditAgent/dbagent2.*/log/*.logWindows:
C:\dbagent\dbagent2.*\log\*.log
The following log entry indicates that the process started successfully but failed to obtain the region for the IP address that is resolved from the Database Audit domain name. As a result, the server and Database Audit cannot communicate properly.

Test the host connectivity.
Ping the IP address of the Database Audit service. The following output shows that the connection is normal.

Ping the domain name of the Database Audit service. The following output shows that the domain name cannot be resolved.

Solution
Modify the DNS resolution address of the server to an Alibaba Cloud internal DNS address, such as 100.100.2.136/32 or 100.100.2.138/32, to connect to Alibaba Cloud services through the VPC. For more information, see Introduction to internal DNS resolution.
If you cannot modify the server's DNS resolution settings, modify the
serviceIpparameter in theagent.iniconfiguration file:Log on to the server where the agent is located. Go to the agent installation directory, open the
agent.iniconfiguration file, and find theserviceIpparameter.Copy the domain name that is specified for the
serviceIpparameter, and then run theping <domain_name>command to obtain the IP address.Replace the value of the
serviceIpparameter in theagent.inifile with the IP address that you obtained in the previous step.After replacing the value, run the following commands in sequence to reinstall the agent:
./uninstall.sh ./install.sh
What permissions can I grant to RAM users for DataBase Audit?
DataBase Audit supports granting the following permissions to Resource Access Management (RAM) users:
AliyunYundunDbAuditFullAccess: Grants a RAM user permission to manage Alibaba Cloud Security DataBase Audit (DBAudit). This policy includes read and write permissions. For more information, see Manage RAM user permissions.
AliyunYundunDbAuditReadOnlyAccess: Grants a RAM user read-only permissions for Alibaba Cloud Security DataBase Audit (DBAudit). For more information, see Manage RAM user permissions.
A RAM user authorization applies to the entire DataBase Audit service. You cannot grant permissions to a RAM user for a specific database that is configured in DataBase Audit. This applies to both ApsaraDB RDS databases and self-managed databases on ECS instances. A RAM user with DataBase Audit permissions can use the service for all configured databases, regardless of whether they have separate permissions for those individual databases.
Choosing a Database Audit edition
Database Audit provides different editions based on the number of database instances that can be audited. One IP address and port combination is counted as one instance. When purchasing the service, select an edition based on the number of databases you plan to audit. For example, if you need to audit one MongoDB and one MySQL database, select the Professional Edition (3 instances).
You do not need to consider the database type when you choose an edition.
Configuring Database Audit after purchase
After purchasing a Database Audit instance, configure the service by following these steps:
If you want to configure audit rules and alert notifications, see Quick start for C100.
Adding servers across regions, VPCs, or accounts
You can add servers from different regions, VPCs, or accounts by ensuring network connectivity between the servers and the Database Audit system.
Example 1: You have more than 10 servers under one Alibaba Cloud account, distributed across three different regions: China (Qingdao), China (Beijing), and China (Zhangjiakou). You only need to establish network connectivity between each server and the Database Audit system. Then, you can use a single Database Audit instance to audit the databases on all these servers.
Example 2: You have 13 ECS instances under one Alibaba Cloud account. Nine of them use the classic network, and four use a Virtual Private Cloud (VPC). You only need to establish network connectivity between each server and the Database Audit system. Then, you can use a single Database Audit instance to audit the databases on all these servers.
If network connectivity cannot be established, a single Database Audit instance can only audit databases on the same server as the instance.
Example 3: You have five servers under Alibaba Cloud account A and five servers under Alibaba Cloud account B. You only need to establish network connectivity between each server and the Database Audit system. Then, you can use a single Database Audit instance to audit the databases on all these servers.
Configuring local traffic auditing on Windows
The default traffic forwarding tool that is installed by the agent on Windows is WinPcap. If your service traffic includes local traffic, you must replace WinPcap with the Npcap plug-in. To do so, follow these steps:
-
Log on to the server where the agent is located. In Control Panel, first uninstall the agent and then uninstall WinPcap.
-
On the Agent Installation tab of the Agent Management page, download the 64-bit Windows agent installation package and decompress it on the corresponding Windows server.
-
Go to the decompressed folder and run the
dbAgent-setup.exefile to install the agent. During the installation, select theNpcapplug-in.
Auditing local traffic to '127.0.0.1'
Scenarios: A client application and a database are deployed on the same server, or an operations engineer accesses the database directly on the server.
To configure the agent, follow these steps:
-
Make sure that you have configured the database as an asset in Asset Management in the Database Audit system.
-
Make sure that the agent is installed and running correctly on the database server. For instructions on how to install the agent on a Windows system, see Configuring local traffic auditing on Windows in this topic.
-
On the agent server, run the following command to check the current database connections. The IP address that corresponds to the database port is the currently connected database IP address.
-
Linux:
netstat -ano |grep <database_port_number> -
Windows:
netstat -ano |findstr <database_port_number>
-
-
If the database connection IP address on the server is
127.0.0.1, you need to configureloopback interface IP address replacement (IPv4)for the agent, as described inStep 5. -
Log on to the C100 Database Audit system and go to the page. Click the Configure button for the target agent to open the configuration page. In the loopback interface IP address replacement (IPv4) field, enter the database IP address that is configured for the asset in Database Audit.
How do I test the network connectivity for DataBase Audit?
Follow these steps:
-
Log on to your ECS server.
-
Run the
pingcommand to check the connectivity to the domain name of your Database Audit instance. -
Run the
telnetcommand to check the connectivity to ports 13001 and 13002 of the domain name of your Database Audit instance.
If all steps are successful, the network connection between the agent and the Database Audit service is normal.
Cannot open the Database Audit system
The Database Audit system requires HTTPS access. You must open port 443 in the security group of the ECS instance where Database Audit is deployed to allow access.
Troubleshooting unaudited data
After configuring Database Audit as described in Configuring Database Audit after purchase, you can verify the configuration by viewing audited statements in .
If no statements were audited in the last five minutes, the audit device has not parsed any statements from the database asset during that period. Follow these steps to troubleshoot the issue:
-
Log on to the Database Audit console and check the Database Audit instance.
-
For a newly enabled instance, confirm that you have installed the agent and configured the database asset.
-
If you have not installed an agent or configured a database asset, see Manage database assets and Install an agent.
-
If you have installed the agent and configured the database asset, proceed to the next step.
-
-
If this is a previously enabled Database Audit instance, proceed to the next step.
-
-
Go to the C100 page and check the Storage Information for this instance to determine whether the storage space is full.
-
If the storage space is full, upgrade the storage. For more information, see Configure a Database Audit instance. Alternatively, you can back up the existing audit records by using the OSS Backup feature in the console, and then clear the storage after the backup is complete.
Note-
The storage usage displayed in Log Service (SLS) may have a delay of one to two hours.
-
If another Log Service (SLS) instance under your account has overdue payments, data cannot be written to your Database Audit instance.
-
-
If the storage space is not full, proceed to the next step.
-
-
Log on to the Database Audit system. For more information, see Log on to the Database Audit system. On the page, check the agent status.
-
If the agent status is abnormal, check the network connectivity between the agent server and the Database Audit system. For more information, see Testing network connectivity in this topic.
-
If the agent status is normal, proceed to the next step.
-
-
On the agent server, check the current database connections.
Linux:
netstat -ano |grep <database_port_number>Windows:
netstat -ano |findstr <database_port_number>For a normal connection, the connection state should be
ESTABLISHED. The IP address that corresponds to the database port is the currently connected database IP address. Make sure that this IP address matches the asset IP address (or the domain name that corresponds to the IP address) that is configured in the Database Audit system.-
If there are no database connections on the agent server, make sure that the agent is installed on a server with database services. To install an agent using Cloud Assistant, see Install an agent.
-
If a database connection exists and the database IP address configured for the asset in the Database Audit system is correct, proceed to the next step.
-
-
Use packet capture to check whether the database traffic is encrypted.
-
Troubleshoot the issue by checking the agent logs.
The log directory for an agent installed using Cloud Assistant is /data/dbAuditAgent/log. The directory contains log files named with the date.
If the issue persists, join the DingTalk group (Group ID: 44518739) to contact product and technical experts for assistance.
Why does an unknown user appear in the audit results?
Possible causes:
When you first enable auditing, if there are active sessions that have not been disconnected, they are audited as an unknown user. After a while, user information appears in the audited SQL statements.
If you need the user information to appear immediately, disconnect the application from the database and then reconnect.
When you access a SQL Server database by using a client application such as SqlDbx, the Tabular Data Stream (TDS) protocol is used for data transmission. During authentication, the user credentials are sent over a strongly encrypted SSL connection. As a result, Database Audit cannot decrypt the user information.
To ensure that user information is audited, we recommend that you do not access the SQL Server database through such client applications.
Auditing TLS/SSL-encrypted traffic
If packet capture shows that the database traffic is encrypted using TLS/SSL, see Database types that support encrypted auditing to confirm whether your encrypted database is supported for auditing.
-
For database assets that support encrypted auditing, you can import the private key to enable auditing.
-
For database assets that do not support encrypted auditing, you must disable SSL encryption on the database, or configure your application to disable the SSL encryption parameter in the application configuration file on the application server.
-
sqlserver: jdbc:sqlserver://your_server_address:1433;databaseName=your_database;user=your_username;passwd=your_password;encrypt=false -
mysql: jdbc:mysql://hostname:port/databaseName?useSSL=false
-
Handling full storage space
Database Audit stores its audit records in Alibaba Cloud Log Service (SLS). The storage duration can be set from 30 to 185 days. Log Service automatically clears expired audit records based on the storage duration. When the storage space is full, new audit data cannot be written. You can use one of the following solutions:
Upgrade storage capacity
Log on to the Alibaba Cloud Security DBAudit console.
-
In the left-side navigation pane, click C100 Instances.
-
Locate the instance for which you want to upgrade the storage capacity and click Upgrade in the Storage Information section.
-
On the Upgrade/Downgrade page, select a storage capacity. You can expand the storage space from 1 TB to 200 TB.
-
Click Buy Now and complete the payment.
OSS data shipping
You can use Log Service (SLS) to automatically archive data from a Logstore to Object Storage Service (OSS), expanding the use of your logs. You can set a custom lifecycle for data in OSS to store logs for an extended period.
Prerequisites
-
You have activated Log Service (SLS), created a Project and a Logstore, and successfully collected log data. For more information, see Quick start for Log Service.
-
You have activated Object Storage Service (OSS) and created a bucket in the same region as the Log Service (SLS) Project. For more information, see Activate OSS.
Configuring OSS data shipping
Log on to the Alibaba Cloud Security DBAudit console.
-
In the left-side navigation pane, click C100 Instances.
-
Locate the instance for which you want to configure storage and click Configure in the Storage Information area.
-
In the Storage Management dialog box, click OSS Backup.
-
On the OSS Data Shipping page, configure the data shipping task for Log Service (SLS). For more information, see Create an OSS data shipping task (legacy).
-
The Log Service (SLS) Project and the OSS bucket must be in the same region. Cross-region data shipping is not supported.
-
Data that is shipped and then cleared is treated as backup data. You cannot view it directly in Database Audit. If you need to view the backup data, you can import the data from OSS into Log Service for analysis. For detailed instructions on how to import backup data, see Import data from OSS.
Viewing logs in Log Service (SLS)
The audit and session logs displayed in the Database Audit system are sourced from data stored in SLS.
In the Log Service console, you can view and download log data from the Project and Logstore created by Database Audit.
Audit log
-
Logstore name: dbaudit-audit-*, where * represents the ID of your Database Audit instance.
-
For a detailed description of the audit log fields, see Log fields.
Session log
-
Logstore name: dbaudit-session-*, where * represents the ID of your Database Audit instance.
-
For a detailed description of the session log fields, see Log fields.