Fortify aws aurora_proxy_2019_pleu

Marco Tusa
Percona
Fortify your MySQL data security in AWS
using ProxySQL and Firewalling

• Open source enthusiast
• Principal Consultant
• Working in DB world over 25 years
• Open source developer and community contributor
About Me

Hello, Attendees!
Why use ProxySQL with Aurora or AWS solutions
What can be done to make your AWS/Aurora safer and more stable

What is ProxySQL (in 1 slide)
• ProxySQL has an advanced multi-core architecture.
• It's built from the ground up to support hundreds of thousands of
concurrent connections, multiplexed to potentially hundreds of backend
servers.
• Query filtering by design
• Query caching
• Embedded configuration distribution (cluster)
• Design to scale (the largest ProxySQL deployment spans several hundred
proxies).
• … and more

What is AWS Aurora (in 1 slide)
• Amazon Aurora is a MySQL and PostgreSQL compatible relational
database built for the cloud
• Features a distributed, fault-tolerant, self-healing storage system that auto-
scales up to 64TB per database instance
• Delivers high performance and availability with up to 15 low-latency read
replicas, point-in-time recovery, continuous backup to Amazon S3, and
replication across three Availability Zones
• fully managed by Amazon Relational Database Service (RDS)
• … and more

Use ProxySQL version 2 (The problem)
ProxySQL deal with backend servers using:
• Replication Hostgroup
• Async replication
• Scheduler
• PXC, NDB etc
AWS Aurora do not use READ_ONLY but INNODB_READ_ONLY
https://dev.mysql.com/doc/refman/5.7/en/innodb-read-only-instance.html

Use ProxySQL version 2 (Solution)
October 2017, this issue was opened (https://github.com/sysown/proxysql/
issues/1195 )
MYHGM_MYSQL_REPLICATION_HOSTGROUPS "CREATE TABLE mysql_replication_hostgroups
(writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY ,
reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND
reader_hostgroup>=0) , check_type VARCHAR CHECK (LOWER(check_type) IN
('read_only','innodb_read_only','super_read_only')) NOT NULL DEFAULT 'read_only' ,
comment VARCHAR NOT NULL DEFAULT '' , UNIQUE (reader_hostgroup))”
mysql> select * from mysql_replication_hostgroups;
+------------------+------------------+------------------+------------+
| writer_hostgroup | reader_hostgroup | check_type | comment |
+------------------+------------------+------------------+------------+
| 70 | 71 | innodb_read_only | aws-aurora |
+------------------+------------------+------------------+------------+
1 row in set (0.00 sec)

Use ProxySQL version 2 (How to implement)
First rollout your Aurora setup
• Identify the Endpoint for EACH instance
• aws rds describe-db-instances
• Web interface
INSERT INTO mysql_servers (hostname,hostgroup_id,port,weight,max_connections)
VALUES ('proxysqltestdb.eu-central-1',70,3306,1000,2000);
VALUES ('proxysqltestdb.eu-central-1',71,3306,1000,2000);
VALUES ('proxysqltestdb2.eu-central-1',71,3306,1000,2000);
VALUES ('proxysqltestdb-eu-central-1b.eu-central.1',71,3306,1,2000);
INSERT INTO mysql_replication_hostgroups(writer_hostgroup,reader_hostgroup,comment,check_type)
VALUES (70,71,'aws-aurora’, 'innodb_read_only’);
LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;

But WHY I should use it?
GOOD QUESTION

Why
Better a graph
Higher is
better

Why
Only connection
latency
When using Java
connector
Single pointer
Values in
nanoseconds

Why
Latency while running
the tests
Left Aurora
Right ProxySQL

Why it happens
ProxySQL can redirect the queries as you like and to the instance you want.
How do we read this graph? From left to right:
• read_only test with an Aurora cluster endpoint
• read_only test with ProxySQL
• write_only with an Aurora cluster endpoint
• write_only with ProxySQL
• read and write with an Aurora cluster endpoint
• read and write with ProxySQL

Why it happens
The Cluster endpoint is an endpoint for an Aurora DB cluster that connects
to the current primary instance for that DB cluster. Each Aurora DB cluster
has a cluster endpoint and one primary instance.
That endpoint receives the read and write request and sends them to the
same instance. The main use for it is to perform failover if needed.
Each Aurora DB cluster has a reader endpoint. If there is more than one
Aurora Replica, the reader endpoint directs each connection request to one
of the Aurora Replicas. The reader endpoint only load balances
connections to available Aurora Replicas in an Aurora DB cluster. It
does not load balance specific queries.
If you want to load balance queries to distribute the read workload for a DB
cluster, you need to manage that in your application and use instance
endpoints to connect directly to Aurora Replicas to balance the load.

Aaah That’s why
• Native AWS Cluster endpoints and Reader endpoints are limited in what
they offer
• With ProxySQL you can very granularly choose how to use each
instance, without the need to have the application modify how it works
• Using ProxySQL will allow the use of additional elements like
• Query Cache
• Query rewrite
• Blocking/firewalling

Now What?
Secure all around
• Secure access to RDS (account, IASM, Roles)
• Secure network access (limit to local range/Port, VPN, etc)
• Secure MySQL user/password/location/access + grants
• Secure ProxySQL (user/password + encrypted )

No is not!
Enemies and dangers are around you
• Your own application
• Developers
• Your DBA/OPS
• Yourself

We can do more
• Queries with no filtering (Where)
• Over complicated queries
• Not indexed Queries
• Jobs that are not suppose to hit main production
• Reports on writer node/instance
Currently the only way to manage some of the above is to use SP
and limit all users to execute

Fields of action
Secure by limiting actions on the db
Use Proxy as Firewall

MySQL Query Rules Table
Filter by:
• username
• schemaname
• client_addr
• proxy_addr
• proxy_port
• digest
• match_digest
• match_pattern
Secure by limiting actions on the db

Destination_hostgroup
Pointing to different HG
Replace_pattern
Rewriting the Query
Or if firewalling blocking the query
Secure by limiting actions on the db: Targets

Secure limiting actions on the DB
Limit queries by (user/ip/ports)
insert into mysql_query_rules
(rule_id,client_addr,username,destination_hostgroup,activ
e,retries,match_digest,apply)
values(24,’192.168.1.50)','app_test',
101,1,3,'^SELECT.*$',1);
(rule_id,client_addr,username,destination_hostgroup,activ
e,retries,match_digest,apply)
values(38,'192.168.1.51','app_test',200,1,3,'.',1);
client_addr: 192.168.1.50
proxy_addr: NULL
proxy_port: NULL
client_addr: 192.168.1.51
proxy_addr: NULL
proxy_port: NULL

Block queries not filtered, without where (I am a dummy)
(rule_id,match_digest,error_msg,active,apply)
values(1,'^SELECTs((?!swhere).)*$','Bad Idea to performa SELECT
without a WHERE ... change the syntax and I will let you PASS',1,
1);
mysql> select count(*) from wmillAUTOINC;
ERROR 1148 (42000): Bad Idea to perform SELECT without a WHERE ...
change the syntax and I will let you PASS
mysql> select count(*) from wmillAUTOINC where millid=365;
| count(*) |
| 393 |

Block and transform query by type Select/update/inserts
use windmills; select count(*) a,tb1.b from wmillAUTOINC aa , (select count(*) b
from wmillMID)tb1 where millid=364
| a | b |
| 418 | 164577 | No where in subquery
match_pattern :
select count(*) a,tb1.b from wmillAUTOINC aa , (select count(*) b
from wmillMID )tb1 where millid=(d*)
replace_pattern:
select count(*) a,tb1.b from wmillAUTOINC aa , (select count(*) b from
wmillMID where millid=1)tb1 where millid=1
| a | b |
| 418 | 407 |
https://github.com/sysown/proxysql/issues/1556

Use ProxySQL as firewall
• block all
• block stupid checks (SELECT 1)
• let pass something by regexp
• let pass only specific queries
• Make it efficient

IPtables
[root@galera1h1n5 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- 10.0.0.0/24 anywhere tcp dpt:mysql
ACCEPT tcp -- 10.0.0.0/24 anywhere tcp dpt:tram
ACCEPT tcp -- 10.0.0.0/24 anywhere tcp dpt:bmc-reporting
ACCEPT tcp -- 10.0.0.0/24 anywhere tcp dpt:krb524
ACCEPT udp -- 10.0.0.0/24 anywhere udp dpt:tram
ACCEPT tcp -- 192.168.1.0/24 anywhere tcp dpt:42000
ACCEPT icmp -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:mysql
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain FORWARD (policy ACCEPT)
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)

Filter stupid ping
Select 1;
Million of times
(rule_id,match_digest,ok_msg,active,apply)
values(500,'SELECT 1','Ok',1, 1);

ProxySQL way (apply NOW)
SELECT
wmillAUTOINC.id,wmillAUTOINC.millid,wmillAUTOINC.location
FROM wmillAUTOINC WHERE wmillAUTOINC.millid=300 and
wmillAUTOINC.active=1’);
(rule_id,proxy_port,username,destination_hostgroup,schema
name,active,retries,apply,flagout,match_digest)
values(101,6033,'pxc_test',52,'windmills',1,3,1,null,
'SELECT wmillAUTOINC .id,wmillAUTOINC
.millid,wmillAUTOINC .location FROM wmillAUTOINC WHERE
wmillAUTOINC.millid=d* and wmillAUTOINC.active=.*');

ProxySQL way (apply Later)
Select MAX(millid) as millid ,MAX(active) as active FROM
wmillMID;
(rule_id,proxy_port,schemaname,username,destination_hostg
roup,active,retries,match_digest,apply,flagout)
values(999,6033,'windmills','pxc_test',50,1,3,' Select
MAX(millid) as millid ,MAX(active) as active FROM
wmillMID’,0,1000);
roup,active,retries,match_digest,apply,flagin)
values(1042,6033,'windmills','pxc_test',
52,1,3,'^SELECT.*$',1,1000);

Eehm … How much it cost?
With nothing enable 10 µ

Eehm … How much it cost?
Opps 30 µ is a bit too much

ProxySQL way (apply NOW digest)
SELECT
FROM wmillAUTOINC WHERE wmillAUTOINC.millid=300 and
wmillAUTOINC.active=1’);
(rule_id,proxy_port,username,destination_hostgroup,schema
name,active,retries,apply,flagout,digest)
values(101,6033,'pxc_test',52,'windmills',1,3,1,null, 
'0xDB3A841EF5443C35');

ProxySQL way (apply Later digest)
wmillMID;
roup,active,retries,digest,apply,flagout)
values(999,6033,'windmills','pxc_test',50,1,3,
'0x839B1DCE7A8B247A',1,1000);
roup,active,retries,match_digest,apply,flagin)
values(1042,6033,'windmills','pxc_test',
52,1,3,'^SELECT.*$',1,1000);

Eehm … How much it cost Now?
4µ is even less than before

Deal
Nothing enable : ~ 10 µ
Using match_digest : ~ 30 µ
Using digest : ~ 4 µ

Done! (or conclusions if you like)
• ProxySQL is now (v2.x and above) supporting ASW/Aurora
• ProxySQL is better than native connector
• Your security at SQL level sucks (look at the mirror before
complain with others)
• ProxySQL allow you implement SQL control and a way to
correct things (while you fix them for real)
• It has a cost (nothing is for nothing)
• At the moment we do not have it (digest solution)
automated (Can you develop it? Help the community !)

But must done right
Performance can be affected (by Tibor Korocz)
(https://www.percona.com/blog/2017/04/10/proxysql-rules-do-i-have-too-many/)

Fortify aws aurora_proxy_2019_pleu

We’re Hiring
47
Percona’s open source database
experts are true superheroes, improving
database performance for customers across
the globe.
Our staff live in nearly 30 different countries
around the world, and most work remotely
from home.
Discover what it means to have a Percona
career with the smartest people in the
database performance industries, solving the
most challenging problems our customers
come across.

Contact Me
To Contact Me:
Marco.tusa@percona.com
tusamarco@gmail.com
To Follow Me:
http://www.tusacentral.net/
http://www.percona.com/blog/
https://www.facebook.com/marco.tusa.94
@marcotusa
http://it.linkedin.com/in/marcotusa/
Consulting = No
mission refused!

Fortify aws aurora_proxy_2019_pleu

Recommended

More Related Content

What's hot (20)

Similar to Fortify aws aurora_proxy_2019_pleu (20)

More from Marco Tusa (19)

Recently uploaded (20)

Fortify aws aurora_proxy_2019_pleu