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

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/