Presented at MariaDB Roadshow Turin/Torino, Italy in February 2018

1. Securing Production
Deployments
Maria Luisa Raviol
Senior Sales Engineer- MariaDB

2. GDPR
A Matter of
Balance

3. GDPR
E’ l’armonizzazione di:
Processi
Conoscenza dei flussi
Azioni di prevenzione e procedure di reazione
Soluzioni tecnologiche
Crittografia
Pseudonomizzazione
Anonimizzazione
Accessibilità dei dati
Controllo a posteriori (auditing)
Conformità
Tenere il passo con le normative

4. GDPR
– Le Norme
• La sicurezza del dato
• La protezione e la prevenzione del rischio
• In pratica l’armonizzazione di processi e di tecnologia
Le aziende europee e/
o che trattano dati di
cittadini europei
dovranno garantire:

5. GDPR
– I processi
• La filiera del dato
• Occorre trovare una risposta a tutte le domande
• Un approccio dal generale al dettaglio è normalmente
preferibile
Chi
Cosa
Dove
Quando
Perché
+
Quanto
Come

6. GDPR
– La Tecnologia
Il regolamento dice che
• E’ necessario mettere in atto misure tecniche per
garantire un livello di sicurezza adeguato al rischio.
• In questo caso, le misure tecniche ed organizzative in
questione devono comprendere, tra le altre, se del
caso: la pseudonomizzazione e la cifratura di dati
personali
La tecnologia a
protezione dei dati

7. GDPR
– La Tecnologia
Cosa occorre prevenire:
• Accesso non autorizzato ai file dei database
• Accesso non autorizzato ai file accessori: log,
configurazioni, password…
• Compromissione dell’integrità dei dati
• Che applicazioni effettuino accessi “non sicuri” al
database
La tecnologia a
protezione dei dati

8. GDPR
– La Tecnologia
La protezione del database:
• Prevede misure di protezione dall’interno e
dall’esterno
• Controllo degli accessi esterni
– Firewall
• Controllo degli accessi interni
– Autenticazione
– Cifratura dei canali di comunicazione
• Cifratura del tablespace
• Cifratura dei file di log
• Cifratura dei backup
• Monitoraggio e controllo (Breach notification)
La tecnologia a
protezione dei dati

9. GDPR – MariaDB Enterprise Security
• Detect and prevent attacks
– Acces management
– Denial of service
– SQL Injections
• Protect data with encryption
– Native Mode Encryption protects data at rest
• TSL Encryption
– Protects data in motion
• Auditing for Security and Compliance
• MaxScale database firewall features
• MaxScale selective data masking

10. Security
threats
best
practices

11. “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

12. 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

13. 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

14. 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

15. 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

16. MariaDB
Security
Features

17. 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

18. 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

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

20. 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

21. 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

22. MariaDB Audit Plugin
• Logs server activity
– Who connected to the server
– Source of connection
– Queries executed
– Tables touched
• File based or syslog based logging
Auditing for Security and Compliance
Connection Disconnect
Connect
Failed Connect
Timestamp
Host User
SessionQuery DML + TCL
DDL
DCL
Object
Tables
Database

23. MariaDB
MaxScale
Security
Features

24. Security in MaxScale
Black & White List
Connection Rate Limitation
End to End SSL
Database Firewall Filter for SQL Injection protection
Selective Data Masking HIPPA/PCI Compliance
Maximum Rows Returned Limit DDoS Protection
Transport layer security between applications, proxy
& databases
DDoS Protection
LDAP/GSSAPI Authentication Support
Encrypted Binlog Server Files
SSL between binlog server and Master/Slave

25. 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

26. 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

27. 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.

28. What is a SQL Injection?
• 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

29. What is SQL Injection?

30. 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
Security - Filtering
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 SPECIFIED 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

31. MaxScale Security - SDM
SELECT Name, creditcardNum, balance
FROM customerTbl
WHERE id=1001
Name creditcardNum balance
---------------------------------------
John Smith xxxxxxxxxx 1201.07
Database Servers
Client
HIPPA/PCI Compliance:
Selective Data Masking
based on column name
DATABASE NAME,
TABLE NAME CLASSIFIER
MAY BE PROVIDED
• commerceDb.customerTbl.creditcardNum
• customerTbl.creditcardNum
• credicardNum

32. MaxScale Security – DDoS Protection
DDoS Protection
MAXIMUM ROWS FILTER
• Return zero rows to client if
number of rows in result set
exceeds configured max limit
• Return zero rows to client if
the size of result set exceeds
configured max size in KB Max Rows Limit = 500
NumRows Returned >
MaxRows Limit
QUERY FAILED: 1141
ERROR: No rows returned
51
QUERY
4 MaxRowsLimit FILTER
Clients
NumRows returned = 100032
Database Servers
QUERY

33. MaxScale Howto: DDoS Protection
• Persistent connections to backend.
– When server connections are logically closed, keep
them in pool for reuse.
• Client connection limitation.
– Specify the maximum number of connections for a
particular service.
• Limit rate of queries using the firewall.
Max Client Connections per
Service
Connection pool of
configurable size
Variable number of
connections
[SomeService]
...
max_connections=100
maxscale.cnf [SomeServer]
...
maxpersistpoolmax=30
maxscale.cnf
rule prevent_overload deny limit_queries 15 5 10 firewall.txt
Client Client Client Client
If more than 15 queries are received in 5 seconds, block all queries for 10 seconds.

34. MaxScale Security
Slaves
Master
Slaves
SSL
SSL
SSL
SSL
Secured Binlog Server
ENCRYPT BINLOG SERVER FILES
on MaxScale
SSL between binlog server
and Master/Slave
Secured user access
LDAP/GSSAPI for secured
single sign-on across OS
platforms(windows, linux),
applications and databases
Binlog Cache Binlog Cache

35. 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

36. Best Practices
Summary

37. 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

38. 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

39. 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

40. 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

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

42. Thank you