-1

(Moved from Stack Overflow as other users said it was a security question)

I have a mysql database sitting on a remote server. Nothing else, ie no web site using it, no server side scripts etc, nothing except remote access from an application that I wrote myself in Depli. That application runs on about a dozen machines around the country.

I have set up the allowed IP addresses using the remote mysql tool in cpanel. The problem is some users have dynamic IP addresses so they frequently complain they can no longer get in. Wildcards seem ineffective as even the first octet changes sometimes. The only solution is to use %.%.%.% (some sources say it should be %%%.%%%.%%%.%%%) but eitherway I am aware this reduces security.

The question is what would I (or anyone else) need to hack into the database if the wildcards allowed their IP address?

In my mind a hacker would need to know A) There is a database there in the first place B) The name of the database C) The name of the single user I have set up D) the password for that user

Can any expert programmers out there tell me if allowing access from any IP address would compromise security unduly?

| improve this question | |
2

The first answer told many things. But as long as your connection to the mysql database is possible, you can be hacked. [My off-topic advice: keep searching for info about exploits and vulnerabilties for mysql actively].

Can any expert programmers out there tell me if allowing access from any IP address would compromise security unduly?

Actually, I don't like that access from "any IP". This opens many ways to attackers.

That application runs on about a dozen machines around the country.

I fully recommend that you limit the access at least to the country IP addresses.

Search for IP address ranges for a certain country and add IP's of the ISP's from your country.

An attacker could find your database if you're running it on the default port. Change it!

And don't forget to successfully set up correct rights for the DB users.

| improve this answer | |
  • And to fully answer your question, you didn't tell what your application does. select/insert/... ? what rights are set on this user? – balex May 18 '15 at 11:51
  • "I don't like that access from "any IP". That's exactly my point!I don't either but don't have any hard facts why its not a good idea, given the other factors. @pbwned The db holds membership data and newsletter preferences for a UK mountaineering association. My application is used by the committee members and handles things like adding new members editing member data, doing email shots with a newsletter attached, reports such as members in a given radius of a town and communicating member data to the British Mountaineering Council. The sql involved is mainly inserts, updates and selects. – user3209752 May 18 '15 at 13:18
  • 1
    Do you really not see why having the door open, with only a username and password protecting the system, could be considered a bad thing? – Phil Sumner May 18 '15 at 13:42
  • So the attacker can easily gain access by sniffing the data of your customers. – balex May 18 '15 at 16:21
  • @user3209752 if that is what your doing, implement an API (like REST) over an SSL webserver with Token based acces schema and let the web app do the SQL connection. this way you can pritect your DB and its easier to safeguard a REST/JSON interface than a binary one (limit allowed length and characters for example). Remeber to use a proper authentication mechanism! (Do not roll your own) – LvB May 19 '15 at 22:18
3

An attacker would need one of the following:

  • No known user / password
    • A vulnerability for the mysql version you use.
    • the IP of your mysql server (if it runs on a default port chances are its already known to the criminal world)
  • Sniffed User name / password / ip
    • Nothing, he has all he needs.

The difference between the 2 scenario's is that 1 is a directed attack the other a dragnet attack.

The defence against those attacks could be :

  • use SSH or another VPN technique to tunnel your mysql connection through a 'safe' tunnel. (not exposing any part of your system aside from beginning and end point).
  • Use SSL connection on your mysql port. (this makes eavesdropping all but impossible)
  • if all your doing is adding data to the DB make a drop off point (app) that has access to the DB. these are often easier to secure using oauth2 or alike.
  • use Client side certificates with SSL. this makes it very hard for anyone but someone with the proper certificates to access your DB.
| improve this answer | |
  • MySQL native authentication, unless it's an old server or new server with passwords that used the old algorithm, is relatively sniff-resistant, since it uses a challenge/response mechanism and would only be subject to a replay attack if the 20 byte challenge were issued again by the server, but otherwise, everything is cleartext, including the username (which gives a would-be attacker an excellent starting point), without SSL. – Michael - sqlbot May 19 '15 at 2:42
  • Without versions we can not assume its the new mechanism I'm afraid. – LvB May 19 '15 at 8:53
  • Oh, agreed. The old auth mechanism was also not cleartext, but was significantly cryptographically broken. +1 – Michael - sqlbot May 19 '15 at 9:40
  • +1 for SSH tunneling and not exposing the port to the outside "world". – Jeroen Aug 28 '19 at 5:37
0

See MySQL BACKRONYM attack (more info here). Basically older versions of MySQL (before the latest MySQL preview release 5.7.3) were vulnerable to a man-in-the-middle SSL-stripping attack where a network attacker could capture your authentication data and login to your database.

So all the network attacker (some rogue party at an ISP) just needs to run a script, looking for attempted MySQL handshakes, apply this attack, capture database credentials and then they connect. An IP address white list probably doesn't help significantly, as again for the MitM/network attack they are in a position to impersonate your whitelisted IP address to this server.

My understanding is current default configurations are still vulnerable though can be configured to be secure. Granted, if your database is not accepting remote authentication (e.g., doesn't accept network authentication, or must be on the secure local intranet, or through VPN) then you are fine for the BACKRONYM attack.

| improve this answer | |
  • I read the CVE and what I understood is that the attacker tricks the MySQL Client into thinking the MySQL Server is saying "hey, I don't support SLL, send me the information in plain text". So if what I understood is right, I would only need to update MySQL on my client/slave server (since the error/bug is that the client is dumb enough to trust the reply and forgets about any configuration to enforce SSL). Am I right? – Jhuliano Moreno May 26 '15 at 14:39
  • 1
    Yes. The MITM tricks the client into believing the server doesn't support SSL. You fix this by upgrading the clients to 5.7.3 or greater, or don't talk to your database over untrusted networks (e.g., use it only as a local application, or a small private network, or over a secure VPN). – dr jimbob May 27 '15 at 16:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.