What is MariaDB Security?
When MySQL was acquired by Oracle in 2009, some of its developers wanted to continue developing a relational database management system (or RDBMS) in the free, open-source spirit they initially intended. MariaDB was born from that idea, becoming a sister platform to MySQL that remains highly compatible. Indeed, sister platform is an apt description as both MariaDB and MySQL are named after lead developer Michael Widenius’ daughters Maria and My respectively.
But as time marches on, MariaDB looks more distinct from MySQL as it develops its own unique features. These include support for more storage engines, faster caching and indexing, and improved replication, among others compared to its predecessor. While both share an SQL lineage, their growing differences require some nuance when developing good security policies for each platform.
If you’re contemplating implementing MariaDB with a strong security policy, this guide is an introduction to foundational security concepts that can scale with your database.
In this article, you will learn about:
Why Choose MariaDB?
MariaDB remains one of the most popular database servers in use around the world. Some of its most common uses involve inventory and transaction management as well as customer service and client relationship management.
In addition to the features listed above, one of MariaDB’s biggest draws is its free, open-source model – something that was advocated since its fork from MySQL and is intended to remain that way for the foreseeable future. MariaDB also supports PHP for web-related apps and development as well as Galera cluster technology.
Like other SQL databases, MariaDB is flexible and scalable, supporting small businesses and international corporations alike. It can also be a drop-in replacement for MySQL; that is, you can uninstall MySQL and install MariaDB to take its place while not changing anything in your clients or data.
Granted, MariaDB isn’t without its shortcomings. As MariaDB and MySQL continue to develop separately, they’ve gotten less compatible over time so drop-in replacement isn’t as seamless as it used to be. Moreover, if you’re not careful, MariaDB can become bloated and sluggish if you’re not paying attention to its caching or the size of its IDX log. Both of these, if left to grow too large or cumbersome, will bog down your database and slow it down.
These issues, however, can be mitigated by attentive administration, practicing data hygiene, and regular audits to ensure the database is functioning properly.
Common MariaDB Security Threats
While MariaDB shares similar security threats with other SQL-based applications, there are others that are unique to this platform as it continues to distinguish itself among the competition. Here are some of the most common security threats you may encounter and how to address them.
SQL Injection Attacks
Attacks that use SQL injection are when a bad actor types in (or injects) SQL language commands into user input. In turn, those injected commands will be executes, often changing the logic of applications (for example: allowing users to access other users’ data), or be exposed to data they shouldn’t have access to. In many ways this may include the entire database, and in some cases it may allow attackers to even take over the server itself.
One of the best ways to protect against SQL injection attacks is by implementing ways to prevent users from injecting code into user-supplied content (such as query strings, post data, http headers, etc). Two ways to do this is through parameterized queries and input validation in order to block bad input rather than run it through the database.
DDoS Attacks
Distributed denial of service (or DDoS) attacks are one of the most common, aggressive moves hackers can make to harm a database. As the name implies, a DDoS attack is when a database is overwhelmed by a rapid influx of queries from multiple accounts. If sustained long enough, this can slow down or even crash the database, rendering it useless until the attack subsides or the queries are halted.
As DDoS attacks against databases are usually indirect (i.e. the DDoS attack is performed on an appliciation that in turn queries the database), they are best dealt with in the application level. However, you can also minimize DDoS threats by disabling persistent connections and closing opened connections that result in errors.
Occasional Vulnerabilities such as MariaDB CONNECT Storage Engine Vulnerabilities
From time to time, vulnerabilities are found in software, and an example is the connect engine privilege escalation set of vulnerabilities, which consists of:
- Heap-Based Buffer Overflow Privilege Escalation
- Format String Privilege Escalation
- Use-After-Free Privilege Escalation
- Stack-Based Buffer Overflow Privilege Escalation
All of these vulnerabilities require authentication and, as their names suggest, are used to escalate user privileges. This is accomplished by exploiting flaws found in SQL querying processes but leveraging different factors within them. For instance, heap-based buffer overflow privilege escalation is when the attacker takes advantage of faulty validation of user-supplied data before it’s copied to a fixed-length heap-based buffer.
It is recommended to watch for software vulnerability announcements for MariaDB (as with other software you’re using).
Visit CVE Details for a full list of MariaDB security vulnerabilities as well as MariaDB’s official list of fixed vulnerabilities for more information.
Man-in-the-Middle Attacks
With so much data being transferred online, users often assume that these transfer are confidential between sender and recipient. While this is mostly the case with great encryption and security practices, there are still bad attackers who want to eavesdrop on these connections and steal data. These kinds of attacks are called man-in-the-middle (or machine-in-the-middle or MITM) attacks.
MITM attacks happen when an attacker hijacks communication between two parties. This can happen when an attacker is able to read clear-text data or decipher data sent between users, a user and database, or two or more applications.
ThIn the context of MariaDB, this vulnerability stems from an error that happens within the function which can improperly verify a server hostname.
The best way to defend against MITM attacks is to keep MariaDB updated (as there was a now-fixed vulnerability in SSL certificate validation, segregated from a network perspective (within a VPC or internal network), and require TLS encryption.
Data Corruption
Even with the best intentions, data can become corrupted. Data corruption happens for a number of reasons: when a user writes, edits, or transfers data incorrectly, when a process or query is interrupted, when a faulty line of code is injected, among many other scenarios. Even something as simple as a power outage or improper shutdown can cause data corruption.
In addition to checking over data hygiene regularly (that is, catching for any human errors in the database’s code or any of its queries, entries, or tables), be sure to have a backup and recovery policy so that the database can be reverted to an earlier version. It may be annoying to deal with recoveries, especially if your database is large and frequently updated, but it’s preferable to having to start from scratch after a catastrophic failure that corrupts the entire database.
MariaDB Security Configuration
Like other SQL-language databases, setting up MariaDB’s security configuration should take the following factors into account:
User Authentication and Authorization
Authentication (authn) and authorization (authz) refer to a user’s ability to connect to the database and what privileges they’re assigned respectively. Elements within the database such as objects, tables, rows, and columns can all have privileges, allowing you granular control over who has access to what.
These can be even more granular by using data masking (for more information read our MariaDB data masking guide) and row-level security strategies in addition to your preferred security and authn/authz plugins or applications.
For more information, also refer to our MySQL authentication guide.
Auditing
Keeping an audit trail is important for many reasons, such as security investigations and meeting compliance requirements.
MariaDB has its own audit plugin that can be used to log server activity records including user and host connections, executed queries, and any tables or variables that were accessed or changed.
Encryption
MariaDB, like other SQL databases, can use encryption to obscure data. This can be done by either encrypting the data directly or the container it’s held in. Some methods and tools MariaDB uses for encryption include:
- At-Rest Data Encryption
- In-Transit Data Encryption
- TSL/SSL Certificates
- Cipher Block Chaining (CBC)
MariaDB Security Best Practices
In addition to the solutions we’ve outlined alongside some of MariaDB’s common security threats, here are five MariaDB security best practices to consider.
1. Ensure User Accounts Have Strong Credentials
Some versions of MariaDB come with anonymous users which, by default, do not have passwords. While anonymous accounts generally have very low – if any – privileges, giving any accounts without passwords access to the database is a potential security risk.
Not only should you remove user accounts without passwords, but all passwords should include a string of at least 15 alphanumeric characters and symbols. Ideally, these strings should not include common words or phrases found in dictionaries as these are used by password scanners.
2. Keeping Credentials Safe
When using credentials, you should make sure that the credentials, especially strong credentials (administrative or with access to sensitive data) are kept in a safe way. For example, production credentials should be stored in vaults, and developers should not have credentials in places like public slack channels, e-mail communications, support tickets, etc.
3. Change Database Settings From Their Defaults
Default database settings are very useful for getting your fresh installation up and running fast. However, these same features used to make setup easy are preferred targets for hackers. You can avoid this by customizing your database settings including changing the default port, giving users the proper privileges, and removing anonymous accounts.
Once the defaults are changed, you should then test your database’s security to ensure no default settings remain that can be leveraged to gain access.
4. Grant the Least Amount of User Privileges Necessary
There’s no reason that the administrative assistant for the marketing department should have the same level of access that the database administrator has. To keep your database secure, give every user just enough privileges to do their jobs but nothing more. The principle of least privilege minimizes your database’s risks to bad actors getting control of an account that has more authorization than it should.
Be sure to adjust user privileges whenever they change positions or roles. While it’s good to assign privileges for each new user added to the database, it’s a better policy to check user privileges regularly – a task many organizations overlook.
In addition, when giving temporary privileges for a project, make sure that the privileges are revoked when they are no longer needed.
5. Perform Regular Data Security Assessments
It goes without saying that you should ensure the safety and security of your data regularly. Just as you want to back up your data in case of corruption or sudden outages, performing regular audits allows you to identify questionable or malicious behavior as well as malfunctions within the database itself.
Perform such assessments to also identify patches required to your MariaDB.
6. Keep An Accessible Audit Log
You should have a data access audit log, enabling you to know who was accessing what data, and when.
In addition to any organizational requirements, data security auditing is also mandated by law in certain jurisdictions; GPDR, CCPA/CPRA, and HIPPA are a few examples that require mandatory audits. Organizations found out of compliance with those laws are subject to expensive fines and an erosion of consumer faith if the public catches wind that your data isn’t as secure as it should be.
Implementing MariaDB Security with Satori
Satori helps organizations streamline access to sensitive data stored on MariaDB, as well as provision MariaDB production servers access. In addition, Satori continuously discovers and maps sensitive data on your MariaDB servers, and allows you to enable policies such as data masking in a fast and simple way.
