Use IDS (Intrusion Detection System) to protect database security

Currently, application-level intrusion into applications and their background databases has become increasingly rampant, such as SQL injection, cross-site scripting attacks, and unauthorized user access. All these intrusions may bypass the front-end security system and initiate attacks against data sources.

To deal with such threats, the new level of security stands out, which is application security. This security technology applies the traditional network and operating system-level Intrusion Detection System (IDS) concepts to databases (applications ). Unlike conventional network or operating system solutions, application IDS provides active SQL protection and monitoring to protect thousands of pre-packaged or self-developed Web applications. For example, application IDS can monitor and protect key data so that database attacks, such as buffer overflow and Web application attacks, cannot cause real damage to the database, the application IDS can also review these events.

There is a big difference between application security and network and host security. Applications vary widely, but the attack targets are always the same, that is, database intrusion. Because the application uses SQL to communicate with the database, a good application IDS should be able to parse the SQL, provide an objective protection layer that can understand the traffic content and draw a line with the application.

Most application IDS have three components. The first is a network or host-based sensor. The network sensor is connected to a port on the vswitch. The configuration of this port determines that it can view all traffic in the database. In contrast, host sensors reside directly on applications. The sensor can collect SQL transactions and parse them, and then decide whether an alert should be issued for the traffic. If necessary, the warning will be passed to the next component, that is, the console server. This server stores event information and is the center of sensor maintenance activities such as policy configuration and upgrade. The third component in the application IDS is a Web browser, which allows administrators to modify IDS settings, monitor events in real time, and generate reports.

Taking SQL injection as an example, attackers attempt to bypass the SQL statements defined by the Web server to inject their own statements. Assume that the user name to be entered is Bob and the password is Hardtoguess.

When you see the entered content, the database will find the matching content in the WebUsers row, and then the application will verify the user. In order to intrude into the database, SQL injection attacks will fool the application and make it believe that you have submitted the correct certificate. For example, the password used for the attack is 'blah' or 'A' = 'A'. Therefore, the SQL statement created during the attack may be: SELECT * FROM WebUsers WHERE Username = 'bob' AND Password = 'blackh' OR 'A' = 'A '.

Logically, 'A' = 'A' is always TRUE, and the WHERE clause can also match all rows, attackers can also pass the authentication without a correct user name or password. The application server will accept the input information and allow attackers to pass. Next, the application server uses SQL commands to request data from the database.

If IDS is applied, the sensor collects SQL commands and decrypts them, and then checks which tables and columns in the database are accessed by these commands. Using this method, the sensor can determine whether the attack is normal or an attack. If the detected behavior is not permitted by the IDS policy, the sensor will determine the threat level of the attack and take appropriate measures, usually by sending a warning to the Administrator's console and/or by email.

This is just a simple example of application-layer attacks, and today many companies are facing such threats. By implementing application-level IDS, enterprises can effectively protect vulnerable data and reject the latest attacks and threats.