The document discusses various database security threats and best practices for securing MariaDB and MySQL deployments. It describes common attacks like SQL injection, denial of service attacks, and provides recommendations for defense including using database firewalls, limiting user privileges, encrypting sensitive data, and auditing. MariaDB MaxScale is highlighted as a way to implement features like connection pooling, query filtering, and data masking to enhance security.

1. Securing Production
Deployments

2. Security
threats
best
practices

3. “The majority of the HTTP attacks were made to PHPMyadmin, a popular
MySQL and MariaDB remote management system. Many web content
management systems, not to mention WordPress, rely on these these
databases. Vulnerable WordPress plugins were also frequently attacked.
Mind you, this was on a system that even in honeypot mode hadn't emitted
a single packet towards the outside world.”
ZDNet - Jan 23rd 2018

4. Threats
Viruses
Hacker attacks
Software spoofing
Defense
• Do not allow TCP connections to
MariaDB from the Internet at large.
• Configure MariaDB to listen on
a network interface that is only
accessible from the host where
your application runs.
• Design your physical network to
connect the app to MariaDB
• Use bind-address to bind to
a specific network interface
• Use your OS’s firewall
• Keep your OS patched
The Internet

5. Threats
Denial of Service
Attacks created by
overloading application
SQL query
injection attacks
Defense
• Do not run your application
on your MariaDB Server.
• Do not install unnecessary packages
on your MariaDB Server.
• An overloaded application can use so
much memory that MariaDB could
slow or even be killed by the OS. This is
an effective DDoS attack vector.
• A compromised application or service
can have many serious side effects
– Discovery of MariaDB credentials
– Direct access to data
– Privilege escalation
Applications

6. Threats
• Disgruntled employees
• Mistakes and human error
Defense
• Limit users who have:
– SSH access to your MariaDB server.
– Sudo privileges on your MariaDB server.
• Set the secure_file_priv option to ensure
that users with the FILE privilege cannot
write or read MariaDB data or important
system files.
• Do not run MariaDB process (mysqld) as
root
• Avoid wide hostname wildcards (“%”), use
specific host names / IP addresses
Excessive Trust

7. Threats
• Disgruntled employees
• Mistakes and human error
Defense
• Do not use the MariaDB “root”
user for application access.
• Grant only the privileges required
by your application.
• Minimize the privileges granted
to the MariaDB user accounts used
by your applications
– Don’t grant CREATE or
DROP privileges.
– Don’t grant the FILE privilege.
– Don’t grant the SUPER privilege.
– Don’t grant access to the
mysql database
Excessive Trust

8. MariaDB
MaxScale
Security
Features

9. MariaDB MaxScale Concept
DATABASE
SERVERS
MASTER
SLAVES
Binlog Cache
Insulates client applications
from the complexities
of backend database cluster
Simplify replication
from database
to other databases
CLIENT
PROTOCOL SUPPORT
AUTHENTICATION
PARSING
DATABASE MONITORING
LOAD BALANCING & ROUTING
QUERY TRANSFORMATION & LOGGING
Flexible, easy to
write plug-ins for
Generic Core
MULTI-THREADED
E-POLL BASED
STATELESS
SHARES THE THREAD POOL

10. MariaDB
Security
Features

11. Password Validation
Simple_password_check
plugin
Enforce a minimum
password
length and type/number of
characters to be used
External Authentication
Single Sign On is getting
mandatory in most Enterprises.
PAM-Authentication Plugin
allows using /etc/shadow and any
PAM based authentication like LDAP
Kerberos-Authentication as a
standardized network authentication
protocol is provided GSSAPI based on
UNIX and SSPI based on Windows
Applications

12. MariaDB PAM Authentication
GSS-API on Linux
• Red Hat
Directory Server
• OpenLDAP
SSPI on Windows
• Active DirectoryKDC Client MariaDB
2
3
4
1
Ticket
request
Service
ticket
Here is my
service ticket,
authenticate me
Client /
server
session

13. MariaDB Role Based Access Control
DBA
Developer
Sysadmin
Database
Tables
MariaDB 10
Role: DBA
Permissions:
• Update Schema
• View Statistics
• Create Database

14. Secured Connections
SSL Connections based on
the TLSv1.2 Protocol
Between MariaDB
Connectors and Server
Between MariaDB
Connectors and MaxScale
SSL can also be enabled
for the replication channel
External Authentication
Selective
Data-At-Rest
Encryption
Application control
of data encryption
Based on the AES
(Advanced Encryption
Standard) or DES
(Data Encryption
Standard) algorithm
Encryption for Data in Motion

15. Data-at-Rest
Encryption
• Everything:
– Tables or tablespaces
– Log files
• Independent of encryption
capabilities of applications
• Based on encryption keys,
key ids, key rotation and
key versioning
Key
Management
Services
• Encryption plugin API offers choice
– Plugin to implement
the data encryption
– Manage encryption Keys
• MariaDB Enterprise options
– Simple Key Management included
– Amazon AWS KMS Plugin included
– Eperi KMS for on premise key
management – optional
Encryption for Data Rest

16. Attack Protection with MariaDB MaxScale
Database Firewall Denial of Service Attack
Protection
• MariaDB MaxScale
Persistent Connections
• Connection pooling protects
against connection surges
• Cache the connections from
MaxScale to the database server
• Rate limitation
• Client multiplexing
• Protects against SQL injection
• Prevents unauthorized user
access and data damage
• White-list or Black-list Queries
– Queries that match a set of rules
– Queries matching rules
for specified users
– Queries that match certain
patterns, columns, statement types
• Multiple ordered rule

17. Server Overload Protection with MaxScale
• Server overload protection
– Persistent connection pool to backend
database
– Client connection limitation
– DB firewall - limit_queries

18. Network Overload Protection with MaxScale
• Network overload protection
– Max rows limit
– Max result size limit
– DB firewall - limit_queries
1
3
4
5
2

19. What is SQL Injection?
• A kind of web application attack, where user-supplied input comes from:
URL – www.app.com?id=1
Forms – email=a@app.com
Other elements – e.g., cookies, HTTP headers
and is manipulated so that a vulnerable application executes SQL commands injected by
attacker.
• Applications vulnerable to SQL injection:
– Incorrect type handling
– Incorrectly filtered escape characters
– Blind SQL injection
– Second order SQL injection
SELECT * from customer WHERE id = ?
User supplied value for id = 5, injected value is string ‘5 OR 1=1’
SELECT * from customer WHERE id = 5 OR 1=1
This will result in application getting access to entire customer
table instead of just the specific customer

20. What is SQL Injection?

21. How to Protect from SQL Injection
● Whitelist input parameters and queries
○ SELECT * from userinfo where userid = ?
○ If user id is a valid number between 1 and 100, look
for values [1,100]
○ If userid is an alphanumeric string, look for values
[a-zA-Z0-9]*$
○ Queries that match certain regular expressions
● Limitation
○ For free-form text fields, not easy to map to a subset
■ i.e., an input parameter for description of an item
○ As application and database evolves, whitelist needs
to be kept up to date
● Blacklist keywords and queries
○ DROP, DELETE, INSERT, GRANT
○ All Select queries with wildcard in FROM clause
○ All queries with “1=1” in WHERE clause
○ Queries that match certain regular expression
● Limitation
○ DBAs wanting to do valid operations may be
blocked from doing such operations
○ For certain search field, blacklisted keywords
such as DROP (drop clothe), GRANT (‘The boy
named Grant’) are actually valid input parameter
values

22. QUERY FAILED: 1141
ERROR: Required
WHERE/HAVING clause is missing
rule safe_select deny
no_where_clause
on_queries select
rule safe_cust_select deny
regex '.*from.*customers.*'
user %app-user@% match
all rules safe_cust_select
safe_select
Maxscale Database Firewall
DATABASE FIREWALL FILTER
SELECT * FROM CUSTOMERS;
MaxScale
Database Servers
1
2
3
Database Firewall Filter
Allow/Block queries that
MATCH A SET OF RULES
MATCH RULES FOR SPECIFIC USERS
MATCH ON
• date/time
• a WHERE clause
• query type
• column match
• a wildcard or regular expression or function name
Protect against SQL injection
Prevent unauthorized data access
Prevent data damage
Function name blocking - New in 2.2

23. [Connection Service1]
type=service
router=readconnroute
servers=server1
user=maxuser
passwd=maxpwd
filters=MyDBFirewall
[MyDBFirewall]
type=filter
module=dbfwfilter
rules=/home/user/myrules.txt
Query Blocking Example

24. MaxScale Whitelisting
• Allows only those queries that
• match a set of rules
• match rules for specific users
• match certain patterns
• multiple ordered rules
– Match on
• date/time
• a WHERE clause
• query type
• column match
• a wildcard or regular expression

25. Data Masking with MaxScale
SELECT Name, creditcardNum, balance
FROM customerTbl
WHERE id=1001
Name creditcardNum balance
---------------------------------------
John Smith xxxxxx9901 1201.07
Database Servers
Client
HIPPA/PCI/GDPR Requirement:
• Selective Data Masking by column
• Full or partial anonymization
– 4448889901 ⇒ xxxxxx9901
• Pseudo-anonymization
– Column values randomized,
however same value in multiple
rows randomizes to same
string
DATABASE NAME,
TABLE NAME CLASSIFIER
MAY BE PROVIDED
• commerceDb.customerTbl.creditcardNum
• customerTbl.creditcardNum
• credicardNum
Pseudo-anonymization - New in 2.2

26. Best Practices
Summary

27. Best Practices
USER MANAGEMENT
Use OS permissions to
restrict access
to MariaDB data
and backups
Use strong
passwords
Allow root access to
MariaDB only from local
clients—no
administrative access
over the network
Use a separate
MariaDB user account
for each of your
applications
Use the unix_socket
authentication plugin so
that only the OS root
user can connect as the
MariaDB root user
Allow access
from a minimal
set of IP addresses

28. Best Practices
ENCRYPTION
Encrypt some
data in the
application
Encrypt data
at rest
Non-key data
Credit card numbers, PII etc
Encrypt data in
transit using SSL
From clients to
MariaDB MaxScale
From clients to MariaDB
Between MariaDB
replicated servers
InnoDB tablespace encryption
InnoDB redo log encryption
Binary log encryption

29. Best Practices
Using MaxScale
Restrict the
operations
that clients
(applications)
are allowed
to perform
Identify
and flag
potentially
dangerous
queries
Customize
rules about
what’s
allowed and
what’s not
Use MariaDB
MaxScale as
a Database
Firewall
Implement
connection
pooling
capabilities
can protect
against DDoS
attacks

30. Best Practices
AUDITING
Ensure regulatory
compliance with
robust logging
Use MariaDB
Audit Plugin
Record
connections,
query executions,
and tables
accessed
Use logs for forensic
analysis after an incident
Logging either to a file or
to syslog

31. MariaDB Security Gets Stronger
All the Time
MariaDB User Community
Quickly
identifies new
threats
Creates
solutions
Reports
vulnerabilities
Contributes
features

32. Thank you

33. How MaxScale Protects from DDoS
• Server overload protection
– Client connection limitation
– Persistent connections
– DB firewall - limit_queries
• Network overload protection
– Max rows limit (2.1)
– Max result size limit (2.1)
– DB firewall - limit_queries