All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
MySQL Replication with SSL over Internet - how secure is it?
sirpumpkin
Member
Hey,
I decided to set up own nameservers for my domains. As I want my setup to be as redundant as possible, I will spread them out over several providers. I am using PowerDNS with MySQL Backend and plan to use the native master slave mode, which basically means that replication is done by the backend. So I am using MySQL replication. As I want to perform this replication between different providers I need some way to prevent man in the middle attacks, especially considering the risk of someone modifying the records while they are in transit.
Encryption is nice as well but I mainly need it just for the database user password as DNS records are public anyway.
I've now configured this as described in this tutorial although I made some changes (I am using Ubuntu 16.04 with MySQL 5.7):
https://llawlor.github.io/2016/03/14/mysql-ssl-replication.html
I'm wondering: Is this secure enough? Encrypted it may be but will this also prevent any MITM attacks? I've changed the "REQUIRE SSL" value to "REQUIRE X509" for a greater level of security. What I don't really understand is that I can (and MySQL 5.7 seems to default to this), establish database connections that are encrypted without providing any client certificates as all. As far as I understood it though, as soon as you provide the client certs, it will prevent MITM attacks as then it will check them.
I've also provided all certs when setting up the slave (in the CHANGE MASTER TO command) as opposed to the guide where only the ca file is provided.
What I don't have currently activated is the option '--ssl-verify-server-cert' as I'm connecting via the IP and not the Hostname:
https://dev.mysql.com/doc/refman/5.7/en/secure-connection-options.html#option_general_ssl-verify-server-cert
As far as I understand it, this option is only required for additional Security if I use a public CA for the certificate creation (not as I'm currently doing it like described in the guide)?
I'm looking forward to your feedback and suggestions!
Comments
How about adding rules blocking all IPs and only allow your vpses/servers' ip on each other firewall?
+1 properly firewalling the connection is a must too !
I guess you missed this
why not setup VPN tunnel? Something like TINC.
I remember trying to setup SSL this way on older versions of MySQL. Rather than learn the specific intricacies of MySQL certificate handling and risk exposing any flaws, or my misunderstandings, to the Interweb, decided it was much safer to use stunnel at both ends for the job.
It's another option, and seems a cleaner approach if you don't want the MySQL service listening publicly for any other reason.
These days I'd probably just use a point to point VPN.
As said before use TINC or a SSH tunnel.
Wouldn't SSL + basic login prevent man in the middle?
If the cert isn't verified, then any strong enough attacker could modify the route and pretend to be the server, catch your login details.
Unlikely to happen IMO, even more if you filter with a firewall to only make your DB port visible/accessible from your (other server's) IP.
Reading the official postgresql doc, they do recommend the SSL route. But they provide the ability to verify the cert.
So does MariaDB by the way: https://mariadb.org/state-ssl-mariadb/
I think it depends how sensitive is your data, but correctly implemented it should be enough for most uses cases, in my opinion.
If that's not enough for you, you can setup a VPN or an SSH tunel but if you do that in case a machine gets compromised, the attacker could more easily reach the other server...
I guess I'll just do SSH Tunneling with autossh. Seems reliable and secure, also it is really easy to set up.
A simpler alternative to setting up tinc, etc. is spiped:
http://www.tarsnap.com/spiped.html
We've setup similar, it's secure as your SSL is
But service with different providers, at different locations, hows your latency? Replication is greatly affected by this.
There's no need to use a public CA, and you might be better off using your own CA. OpenSSL comes with a rudimentary perl script for this (CA.pl), which is adequate if you're signing just a few certificates and don't need automatically manage their lifecycles etc. Otherwise there's other CA programs you can download. I used PyCA in the distant past but I don't think it's maintained any more.
You could also just use an ssh or ssl tunnel if it's simpler. Or don't put the db directly on the internet, but rather, have an https service that talks to it over localhost.
OpenVPN in peer to peer mode would be what I would choose, with corresponding firewall rules to lock down where the VPN connections come from in the first place; you wouldn't really need to bolt SSL onto MySQL at that point. SSH (so long as you're using PKI) is also not a bad choice and may be faster than a VPN.
For the sake of my own curiosity, is there some reason in particular you chose MySQL replication over AXFR/IXFR?
How secure do you want it to be?
If you want to be paranoid, do an IPSEC tunnel between the sites. Then make the connections over SSL, inside the IPSEC tunnel.
So I decided to just go with autossh and using a SSH tunnel, which works just fine.
Well there is the problem that zone transfers are by default unsigned. While you can solve this with TSIG, I didn't really get how to set this up with PowerDNS in case you are using a supermaster. I figured it would be easier to just use MySQL replication. Also, it was my first time setting up a MySQL master / slave config, so I wanted to learn something along the way. Encryption is an added bonus. Zone transfers are normally not encrypted. I don't care too much as dns is public anyways, but it is a nice thing to have.