17

I need to open the port for my MySQL server to the outside and from what I read, the default configuration is not secure nor encrypted.

For that, I have a few solutions in mind with their reason but I'd like to know, from a better security point of view, if I'm missing something.

First, the initial idea was to set up an SSH tunneling, but I'm afraid the connection could be lost from time to time (even if I setup with "autossh" system to automatically reconnect when the connection stops). My main concern is that I'm afraid to lose some requests (between the moment the ssh tunneling stops, and the time autossh takes up a new connection).

So I thought about opening MySQL for the outside. I'm aware this is not the best option without working on securing it, but if I add those steps, would it be better?

  1. Change the port for the outside. This won't stop someone to find the correct port, but it will at least stop the bots that target directly 3306
  2. Set up Mysql SSL. This will stop transmitting data in clear between the client and the server, and avoid MitM attacks.
  3. Allow only from certain IPs. This will ensure only the IPs I want will be able to connect. This would be managed by IPtables
  4. root will be only available from localhost. And all other users will have restricted access (to their database)

With this configuration in mind, do you think MySQL would still be vulnerable?

My only idea is if someone would access my web server, and knows the login/password, but I believe that once someone has the login/password, security becomes useless (because it has already been breached to obtain the credentials)

Antu
  • 129
  • 1
  • 7
Cyril N.
  • 2,649
  • 2
  • 18
  • 28

2 Answers2

12

The specific issues depend to some extent on the precise reasons you're opening the server in this way. However, I'm not sure what the difference between a direct MySQL connection dropping (which could happen anyway) and an SSL tunnelled connection dropping, in terms of levels of worry.

  1. Changing the port is essentially security by obscurity. It might reduce the number of attacks seen slightly, but I've never seen particularly high levels of traffic against any database ports when compared with what is commonly seen against, say, SSH ports. There is no harm in doing it, as long as it is not the only security precautions taken. Don't expect it to stop anyone targeting your server specifically though.
  2. SSL Connections for MySQL are sensible. Make sure your clients are aware of the specific certificate to expect, else it would be possible for a MitM attack to take place by interception and re-encryption (client->attacker is encrypted with attacker cert, attacker decrypts and sends to server using server cert, server responds to attacker, who re-encrypts the data to return to client)
  3. IP restrictions are good. You can apply defence in depth here - IPTables to allow for connections to the server, then specific users within MySQL to only be allowed from specific source IPs. Be aware of any users coming from dynamic or shared IP ranges - this mostly applies to users who require access from mobile devices in some countries, but can also result from corporate NATs.
  4. This is also good. Ensure that root still has a strong password, and does not rely on access from localhost as the only security precaution - in particular, allowing access to specific hosts indiscriminately, even if that is localhost, is a bad idea, since it weakens the security level to that of the lowest privilege user with access to that host.

However:

  • Are your clients storing access passwords in an unencrypted form? (e.g. are they using software to access the system which doesn't restrict access to the passwords if they click "remember my password"?) This might be addressed by policy (saying "don't click remember my password") or by technology (enforcing a specific client which doesn't have this function, or safely implements the function)
  • Is the stored data sensitive enough to warrant at-rest encryption?
  • Are you storing logs for the system, and monitoring these regularly?
  • Does the web server have access to any data it does not specifically require? (e.g. if it doesn't need to be able to read the MySQL users table, has it been prevented from doing so?)

Essentially, without knowing the specific details of your setup, any answer can only offer suggestions of what would normally be considered "secure enough". For a bank or for medical records, I would suggest that your setup is not secure enough, and that you should get in a specialist to help secure it fully. For a brochure website, with no transaction data, and no customer data, it's probably fine. For anything between them, it varies.

Matthew
  • 27,233
  • 7
  • 87
  • 101
  • In example #2, MitM attack: How is the attacker decrypting and re-encrypting with the server certificate? Are you assuming the attacker already got hold of the certificate files? How could that happen? If they don't have the files, we are safe from that happening, correct? – Jonathan May 21 '16 at 23:29
  • @JonathanLeaders The MitM mentioned is like a compromised proxy where the client isn't checking the public certificate of the server it connects to over HTTPS. The attacker sends a public cert that is unknown and the client blindly accepts it. If you're asking about re-encrypting with the server certificate then likely your clients already check for this. – ebyrob Jun 29 '17 at 13:27
  • @Matthew Much of this would apply to either MySQL's SSL -or- MySQL over SSH. But which is more secure? Is MySQL SSL worth using at all? Or is it always better to use a more industry proven encryption methodology? I'm not talking about just AES vs Blowfish etc but "full stack" security. A tiny block-chaining mistake, for example, could invalidate the entire setup. (connection dropping seems a minor performance concern only?) – ebyrob Jun 29 '17 at 13:32
4

One thing I can think of: Setting up SSL may not enforce all connections to be SSL. Be sure to verify that.

Aside from the above concern, I think it would only be vulnerable if there was a bug in Mysql itself. If you want to mitigate that, use a VPN (which is not unlike SSH tunneling, as it is an extra point of potential failure), and tell Mysql to only bind to the VPN's vitrual network interface (e.g. tun0).

P.Péter
  • 256
  • 1
  • 8