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 conﬁgure your databases.
The following approaches will all help reduce the impact of any DB-DoS attacks:
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 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.
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.). Conﬁguring 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.
Many DoS attacks exploit bugs in database code. Buffer overﬂows, 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 ﬁrewalls, but the only way to completely ﬁx 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 deﬁne “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 conﬁgure them to block trafﬁc and write policies to detect the attacks. Database monitoring is a popular choice as it combines a broad set of functions, including conﬁguration analysis and other database security and compliance tools.
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 ﬁrewalls 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 ﬁrewalls whitelist and blacklist queries for ﬁne-grained ﬁltering 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 ﬁrewalls are designed to restrict which queries can be run, almost eliminating buffer overﬂow 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 ﬁrewalls 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 ﬁrewalls 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 “ﬂooding 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 overﬂow 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 beneﬁt, 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 ﬂooding 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.
[i] Adrian Lane, Analyst and CTO. Adrian is a senior security strategist with 25 years of industry experience. He brings over a decade of C-level executive expertise to the Securosis team. He specializes in database architecture and data security. With extensive experience as a member of the vendor community (including positions at Ingres and Oracle), in addition to time as an IT customer in the CIO role, Adrian brings a business-oriented perspective to security implementations. He is a Computer Science graduate of the University of California at Berkeley with post-graduate work in operating systems at Stanford University.