Before I delve into the meat of today’s post I want to say that the goal of this series is to aid IT security and database admins in protecting relational databases from DoS attacks. During the course of this research I have heard several rumors of database DoS but not found anyone willing to go on record or even provide details anonymously. Which is too bad – this type of information helps the community and helps reduce the number of companies affected. Another interesting note: we have been getting questions from network IT and application management teams rather than DBAs. In hindsight this is not so surprising – network security is the first line of defense and cloud database service providers (e.g., ISPs) don’t have database security specialists. Now let’s take a look at database DoS countermeasures.

There is no single way to stop database DoS attacks. Every feature is a potential avenue for attack so no single response can defend against everything, short of taking the databases off the Internet entirely. The good news is that there are multiple countermeasures at your disposal, both detective and preventative, with most preventative security measures essentially free. All you need to do is put the time in to patch and configure your databases. But if your databases are high-profile targets you need to employ preventative and detective controls to provide reasonable assurances they won’t be brought down.

It is highly unlikely that you will ever be able totally stop database DoS, but the following mitigate the vast majority of attacks:

• Configuration: Reduce the of attack surface of a database by removing what you don’t need – you cannot exploit a feature that’s not there. This means removing unneeded user accounts, communications protocols, services, and database features. A feature may have no known issues today, but that doesn’t mean none are awaiting discovery. Relational databases are very mature platforms, packed full of features to accommodate various deployment models and uses for many different types of customers. If your company is normal you will never use half of them. But removal is not easy and takes some work on your part, to identify what you don’t need, and either alter database installation scripts or remove features after the fact. Several database platforms provide the capability to limit resources on a per-user basis (i.e., number of queries per minute – resource throttling for memory and processors), but in our experience these tools are ineffective. As with the judo example in our earlier attack section, attackers use resource throttling against you to starve out legitimate users. Some firms rely upon these options for graceful degradation, but your implementation needs to be very well thought out to prevent them from impinging on normal operation.
• Patching: Many DoS attacks exploit bugs in database code. Buffer overflows, mishandling malformed network protocols or requests, memory leaks, and poorly designed multitasking have all been exploited. These are not the types of issues you or your DBA can address without vendor support. A small portion of these attacks are preventable with database activity monitoring and firewalls, as we will discuss below, but the only way to completely fix these issues is to apply a vendor patch. And the vendor community, after a decade of public shaming by security researchers, has recently been fairly responsive in providing patches for serious security issues. The bad news is most enterprises patch databases every 14 months on average, choosing functional stability over security, despite quarterly security patch releases. If you want to ensure bugs and defects don’t provide an easy avenue for DoS, patch your databases.
• Database Activity Monitoring: One of the most popular database protection tools on the market, Database Activity Monitoring (DAM) alerts on database misuse. These platforms inspect incoming queries to see whether they violate policy. DAM has several methods for detecting bad queries, with examination of query metadata (user, time of day, table, schema, application) most common. Some DAM platforms offer behavioral monitoring by setting a user behavior baseline to define ‘normal’ and alerting when users deviate. Many vendors offer SQL injection detection by inspecting the contents of the WHERE clause for known attack signatures. Most DAM products are deployed in monitor-only mode, alerting when policy is violated. Some also offer an option block malicious queries, either through an agent or by signaling a reverse proxy on the network. Database monitoring is a popular choice as it combines a broad set of functions, including configuration analysis and other database security and compliance tools.
• Database Firewalls: We may think of SELECT as a simple statement, but some variations are not simple at all. Queries can get quite complex, enabling users to do all sorts of operations – including malicious actions which can confuse the database into performing undesired operations. Every SQL query (SELECT, INSERT, UPDATE, CREATE, etc.) has dozens of different options, allowing hundreds of variations. Combined with different variables in the FROM and WHERE clauses, they produce thousands of permutations; malicious queries can hide in this complexity. Database firewalls are used to block malicious queries by sitting between the application server and the database. They work by both understanding legitimate query structures and which query structures the application is allowed to use. Database firewalls all whitelist and blacklist queries for fine-grained filtering of incoming database requests – blocking non-compliant queries.This shrinks the vast set of possible queries to a small handful of allowed queries. Contrast this against the more generic approach of database monitoring, alerting on internal user misuse, and detection of SQL injection. DAM is excellent for known attack signatures and suspect behavior patterns, but database firewalls reduce the threat surface of possible attacks by only allowing known query structures to reach the database, leaving a greatly reduced set of possible complex queries or defect exploitations.
• Web Application Firewall: We include web application firewalls (WAF) in this list as they block known SQL injection attacks and offer some capabilities to detect database probing. For the most part, they do not address database denial of service attacks, other than blocking specific queries or access to network ports external users should not see.
• Application and Database Abstraction Layer Hardening: Many database DoS attacks, as well as all SQL injection attacks, go through web-facing applications. If you are building an application from scratch you have the option of designing in database protections from the beginning. This is highly unusual, and we are only aware of a handful of companies which have taken this approach, but it can be very effective against SQL injection and buffer overflow attacks. You build checks into the business logic to prevent misuse, and cast user-supplied data into properly constrained variables to ensure users don’t pass malicious garbage to your database. Much like Hibernate abstracts database interfaces for portability, Database Abstraction Layers abstract database usage for security. Only the DAL needs any detailed knowledge of the database, and it performs all queries. It translates generic application requests into database queries, if the request appears valid and all user data is correctly typed. As a secondary benefit, using a DAL helps with portability. These preventative measures are most useful when building an application, with time for database DoS threat modeling.

All these countermeasures are supplements to network and server DDoS protections, to address database misuse. Keep in mind that, compared to network flooding DDoS attacks, database DoS is unusual. But with a database exploit in hand, a database DoS attack fall less effort and scale than a network DDoS attack. As network defenses get better and we address problems in the lower layers of the protocol stack, attackers reach up the stack for other avenues to exploit.