Restricting MySQL connections from localhost to improve security

Question

I heard that anyone that knows my MySQL Username and Password can access it, Even if it\'s listening only to localhost.

Supposing my info is as following:

Answer 1

If you restrict access from remote hosts to your usernames and passwords then someone won't be able to access the database externally.

You could also configure your firewall to only allow traffic to 3306 (MySQL Default Port) from the localhost machine.

Update

To setup your user so they can only access through LOCALHOST use:

GRANT ALL PRIVILEGES ON *.* TO db_user @'localhost' IDENTIFIED BY 'db_passwd';
GRANT ALL PRIVILEGES ON *.* TO db_user @'127.0.0.1' IDENTIFIED BY 'db_passwd';

Also, bind your MySQL server to the local address. You can do this by editing the [mysqld] section of my.cnf:

[mysqld]
bind-address = 127.0.0.1

Answer 2

This is an older question that I stumbled across, but if Darkeden had phpMyAdmin or similar running, anyone can log in to that using valid MySQL credentials.

If it was compromised, then in addition to restricting connections, change all passwords.

Answer 3

you can block direct access to MySQL at the firewall or within MySQL itself, but the most likely way you'd be hacked is through an insecure web application - in that situation the attacker would most likely be able to read your database login and connect from the server.

So keep your applications secure - keep everything updated, don't allow file uploads, use suPHP if you have multiple accounts etc.

If you restrict your mysql application follow this steps:

1.You could just block port 3306. If the site is on the same server then it will still be able to access the database using localhost as the hostname.

2.Just add "bind-address = 127.0.0.1" to the "[mysqld]" section of their my.cnf file to restrict access to localhost only.

Most of people use this type of restriction.

Answer 4

I didn't see an answer that answered his (adjusted) question - he has locked it to localhost and the attacker is still getting in.

If you have truly restricted it to local host (check using netstat -an | egrep 3306 to check it is listening to 127.0.0.1 not 0.0.0.0), then the only way of accessing it is to originate a connection from that local host.

Initial steps to take:

1. probably rebuild a replacement system from scratch and hardening it before you make it publicly accessible (having a repeatable recipe eg using ansible will help as you may have to go through a few iterations to learn how he gets in) Check with reputable security scanners what you obvious holes are,
2. Get help from a security professional (depends if you want to spend $ or time and frustration to fix)
3. Apply security patches,
4. Remove services you don't need,
5. restrict the database access to only those programs that need it,
6. redo all your passwords,
7. check for installed root kits, and other viruses,
8. secure your server if at your own office and train staff in handling social engineering,
9. use a service that will monitor and filter the requests coming through and deny direct access (eg use cloudflare as a cheep starting point)
10. check for keyboard loggers (physical and software and other viruses) on all machines used to access the server),
11. check for physical means of logging your keystrokes in accessing your server (eg web cam style used in atm), the more exotic include sound (https://en.wikipedia.org/wiki/Acoustic_cryptanalysis), typing with a nearby wifi access point (eg https://www.schneier.com/blog/archives/2016/08/keystroke_recog.html)
12. Add an audit trail and monitor database activity to work out how he is getting through, but at least you need to do all the obvious securing first because otherwise he will just hop from one security hole to another

He could be also getting through using:

1. accessing via some program you are running (eg a web server) that is externally accessible and has a security hole that allows him to run arbitrary sql commands through its existing database connection - see https://www.w3schools.com/sql/sql_injection.asp

2. tricking some program he has access to from outside to proxy a connection for him to localhost:3306 (eg through a miss-configured network firewall on the machine)

3. tricking some program to run a local program (bash. mysql etc), and from there gaining access to the database - buffer overflows and other specially crafted data is a common issue to running arbitrary code

4. man in the middle attack on a connection that has legitimate access

5. bugs in a program that is automatically or manually processing data from outside, eg email, processing of postscript/pdf/any document with scripting processing - even viewing a text file can be dangerous - see https://www.proteansec.com/linux/blast-past-executing-code-terminal-emulators-via-escape-sequences/

6. social engineering a way through getting people to give you access

7. managing to get a hardware device attached to a computer that has access (how many people will pick up a "memory stick" lying in the work car park and check it out instead its a "programmable keyboard", and ALL computers trust keyboards!)

8. and then many more all the other sorts of methods I don't know, but those that are involved share ...

Just remember that you need to have practical security, I think xkcd says it just right: https://xkcd.com/538/