Blog Viewer

There is no way to stop hackers launching DB-DoS attacks, as every feature is a potential avenue for attack and its difficult to find a single DDoS technology or DDoS mitigation service that could guarantee to successfully defend against everything. So short of taking databases off the Internet, there is a degree of operational risk that needs to be managed.

Like database security, DDoS or DoS protection does not happen by itself; it requires an investment in time and mitigation processes and, in a growing number of cases, the use of advanced DDoS technology. The good news is that there are multiple countermeasures at your disposal, both detective and preventative, and many of the basic preventative measures are essentially free. All you need to do is put the time in to patch and configure your databases.

The following approaches will all help reduce the impact of any DB-DoS attacks:

Configuration

Reduce the attack surface of a database by removing what you don’t need—as you can’t 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

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 in order to identify what you don’t need and either alter database installation scripts or remove features after the fact.

Resource Limits

Several database platforms provide the capability to limit resources on a per-user basis (number of queries per minute, long running query timeouts, resource throttling for memory and processors, etc.). Configuring resource limits can help reduce the impact of attacks. Unfortunately, in our experience, these seldom stop DoS—though they can make it much more difficult. As with our previous judo comparison, attackers may use resource throttles to starve out legitimate users. Consider this a good option for graceful degradation and a good standard operating procedure, but remember that your implementation needs to be very well planned to prevent limits from impinging on normal operation.

Patching

Many DoS attacks exploit bugs in database code. Buffer overflows, mishandling of malformed network protocols or requests, memory leaks, and poorly designed multitasking have all been exploited. These are not the types of issues you or DBAs can address without vendor support. A small portion of these attacks are preventable with database activity monitoring and firewalls, but the only way to completely fix these issues is to apply vendor patches. 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 that enterprises patch databases every 14 months on average, often choosing functional stability over database security despite quarterly security patch releases. If you want to ensure bugs and defects don’t provide an easy avenue for DB-DoS, patch your databases promptly.

Database Activity Monitoring (DAM)

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, etc.) 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. That said, DAM is typically deployed to enforce business logic rather than to prevent DoS. Many monitors offer an option to block malicious queries, either through an agent or by signaling a reverse proxy on the network, but most DAM products are deployed in monitor-only mode, alerting when policy is violated. These platforms can be set up to help defend against DoS, but you need to configure them to block traffic and write policies to detect the attacks. 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 become quite complex, enabling users to do all sorts of operations—including malicious actions that can confuse the database into performing undesired operations. Each 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. And malicious queries can hide in this complexity.

Database firewalls are used to block malicious queries by sitting between the application server and database. They work by understanding legitimate query structures as well as which query structures the application is allowed to use. Database firewalls whitelist and blacklist queries for fine-grained filtering of incoming database requests. They also block non-compliant queries and, like DAM, some behavioral monitoring. This shrinks the vast set of possible queries to a small handful of allowed queries. Database firewalls are designed to restrict which queries can be run, almost eliminating buffer overflow type attacks. Contrast this against the more common passive approach of database monitoring, alerting on internal user misuse, and detection of SQL injection. DAM is excellent with known attack signatures and suspect behavior patterns, but database firewalls reduce the threat surface for possible attacks by only allowing known query structures to reach the database. This leaves a greatly reduced set of possible complex queries or defect exploitations.

Web Application Firewall (WAF)

Web application firewalls sit in front of the application to protect application functions from attack. They inspect requests for known malicious attack signatures, but they also provide basic rate-based DoS protection (against “flooding the pipes”) for the app. WAFs protect the database indirectly, by blocking known SQL injection attacks; they also offer some capabilities for detecting database probing. While they provide some protection for databases, WAFs fail to address many database denial of service attacks described in this paper.

Application and Database Abstraction Layer Hardening

Many DB-DoS attacks, as well as all SQL injection attacks, run 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 that have taken this approach—but it can be very effective against SQL injection and buffer overflow attacks. You build checks into business logic to prevent misuse and cast user-supplied data into properly constrained variables to ensure users don’t pass garbage to your database. Much like Hibernate abstracts database interfaces for portability, Database Abstraction Layers (DALs) abstract database usage for security. Only the DAL needs detailed knowledge of the internal database structure, and it performs all queries on behalf of the application much like stored procedures.

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.

While each of these countermeasures is very effective in its own way, it requires a concerted effort with both detective and preventative measures to provide reasonable assurance that databases are hardened against attack.

All these countermeasures are supplements to network and server DDoS protections to address database misuse. Database DoS is much less common than network flooding DDoS attacks. But with a database exploit in hand, a DB-DoS attack requires 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. Database downtime is no less intolerable than website downtime, and must be accounted for when designing the architecture to endure denial of service attacks.

I hope you have found this blog useful. If you have any thoughts or ideas for future blogs, please contact me.

Finally, a big thanks to Adrian Lane of Securosis^[i] without whom this DB-DoS triology would not have been possible.