Configuring Database Audit Instance Rules

Scenario 1: Detecting Abnormal Access to Important Tables

Example: An e-commerce website has multiple microservices in the backend, including order management, user management, and offering search. These services are deployed on different nodes and have different IP addresses, as shown in Figure 1.

Figure 1 Service deployment

The green arrows indicate the access paths. If the order management service or product search service node is attacked, the attacker will access the user information tables from the intruded node. Such access is abnormal.

DBSS allows you to set the following rule to detect abnormal database access.

Figure 2 Adding abnormal database access

The rule shown in Figure 2 indicates that all requests sent from 192.168.1.1 or 192.168.3.3 to the user_info table are regarded highly risky.

After this rule is set, all abnormal access to the high-risk table will be audited, and risk alarms will be triggered.

Click Add Object, enter the target database and target table, and click OK.

Figure 3 Adding a target table

Scenario 2: Optimizing SQL Statements

Example: An application responds slowly when users perform some operations. It is found that latency occurs when the application accesses the database. However, the statements that cause the latency cannot be identified.

In this case, you can use the database slow SQL detection function of DBSS to locate the fault and optimize the performance.

Perform the following steps:

1. Log in to the DBSS console and choose the Risky Operation tab.
   Figure 4 Accessing the Risky Operations tab page
   

2. Locate Database_Slow_SQL_Detection and click Edit in the Operation column. In the Results dialog box that is displayed, set Operation Duration to Greater than 1000 ms.
   Figure 5 Setting the operation duration
   

3. Click OK.
4. After the configuration is complete, wait for a while and search for the slow SQL detection rule by its name. For example, enter SQL in the Rule Name search box on the Statements tab page.
   Figure 6 Slow SQL detection results
   
   NOTE:

   • You can analyze the search result and optimize the SQL statements.
   • You can gradually decrease the value of Operation Duration and perform multiple rounds of optimization.

Scenario 3: Adding a Whitelist to Reduce False Positive SQL Injection Alarms

DBSS provides the SQL injection detection function and built-in SQL injection detection rules. You can also add SQL injection detection rules.

Example: A normal statement generated by an internal program hits an SQL injection rule, as shown in Figure 7.

Figure 7 False positive SQL injection alarm

You can add this SQL statement to the whitelist, so that DBSS will no longer report alarms on it.

NOTE:

The priority of risky operation rules is higher than that of SQL injection rules.

As shown in Figure 7, the executed SQL statement is as follows:

SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'adventureworks' UNION SELECT COUNT(*) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'adventureworks' UNION SELECT COUNT(*) FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'adventureworks'

This statement uses the SELECT statement to access the TABLES table in the information_schema database.

Procedure

1. Access the Risky Operations tab page.
   Figure 8 Accessing the Risky Operations tab page
   

2. Click Add and enter rule information.
   Figure 9 Setting a rule
   

   As shown in Figure 9, the rule indicates that the SELECT statement executed in the TABLES table in the information_schema database is safe.

   Click Add Object, enter the target database and target table, and click OK.

   Figure 10 Adding an object to the SQL injection whitelist
   

3. Click OK.

   After the configuration is complete, the statement will no longer be regarded as risky or trigger an alarm.