Problem
Users from other IPs on the (Windows XP) LAN suddenly cannot connect to my local MySQL server.
Background
I've set up MySQL on my local Windows computer so that other computers on the network have access to the root account. I've added each IP as a host for root. Up to some weeks ago, things worked flawlessly and I could connect to the server programatically and using various MySQL admin tools. Now, however, the MySQL server simply refuses connections from those IPs and I can't figure out why.
The network changes that I've done are: changing network card for two (of three) computers and fiddled around with MySQL settings. None of which should have caused this problem. I've tried adding a new user with all relevant hosts, but I get the same type of error:
MySQL Error number 1045 Access denied
for user 'root'#'shop' (using
passwords: YES)
The odd part is that the computer name, 'shop', is used instead of the IP. I don't know why.
Somehow, IPs seem to be resolved now and hostnames are used. Did you grant access to root#shop? Did you flush privileges?
First thing that pops into mind is Windows Firewall, which could have got re-enabled if you swapped NICs on the host computer.
My next suggestion would be to use a sniffer like Wireshark on the host computer and see what exactly happens packet-wise. You can use filters to make to reduce the output - they're very simple and easy to use. This tool has saved me countless hours of debugging.
-EDIT-
Another possible cause might be that your server somehow decided to resolve IPs to hostnames, in which case ip addresses may no longer work - one would need to add hostnames to the allowed list. Not sure if it works this way for MySQL though.
Could you have turned off TCP connections in MySQL?
Also, is the MySQL port open in your firewall?
If you changed your IP (DHCP?), make sure to correct it in my.cnf if you bound mysqld to your lan ip:
[mysqld]
...
bind-address=192.168.x.y
Related
I have really weird problem that I can't wrap my mind around. I'm using Debian Jessie for our servers. I've added testing repos and upgraded mysql version from 5.5 to 5.7.2 then setup private network between 2 servers:
Server A - 192.168.0.1 as database server
Server B - 192.168.0.2 as application server
I've created user and gave him all required privileges (i've tested multiple hosts and multiple variations of global and database privileges). Everything is working fine but randomly after couple days the user starts getting "Access denied" and can not log in to the database. Communication between servers works just fine, servers can ping each other and connection to mysql is not blocked as its sending Access Denied as response. I've flushed privileges many times and the user has no limits by default.
I've turned off firewall and checked system logs and I don't see anything even remotely related to my problem. I've tried all steps suggested by mysql docs where they suggest possible solutions to "Access Denied". I've tried with different app/database. I've tried many different users with both wildcard and classic hosts definitions, with different permissions and after couple days my application server is still getting "Access denied". If I log in locally on the database server and perform "Show grants" and "Show databases" everything seems fine - user has correct host and privileges yet can not log in remotely.
Application stack used for our apps is PHP with Symfony2/3. Is there anything I can do about it? Is there any software that could help me debug?
I have a hosted MySql server with many databases each with many views. I access the server remotely from my office using HeidiSql.
Once in a while the IP address of my office changes. When this happens, I have to add the new office IP address to the server using cPanel and the "Remote MySql" tool so that I can remotely connect again.
However, all of the views have definer: USER#OLD_IP_ADDRESS. If I need to change a view, I get Access Denied. Up to now, I have been deleting the view (yes, i can delete the view) and recreating it, which makes the view's definer USER#NEW_IP_ADDRESS, and then I can edit the view -- until the Ip address changes again.
So, my question is: What is the best practice is an environment like this. Is there a way to define the views once and, without causing a security risk, be able to edit the views after an IP Address change.
Thanks for any guidance.
You could loosen the host in the MySQL user account a bit, according to the IP range of your internet provider. That way, you don't need to change it every time you get a slightly different IP:
user#123.456.789.%
user#123.456.%
This of course loosens the security in this account, but if your password is be a good one, it should not be too risky.
A better way is to make the MySQL server only accessible via SSH. In that case, your MySQL server can be set up using the --skip-networking option, as you always connecting from localhost. Your user account can be user#localhost or user#127.0.0.1, which then would solve your above mentioned problem for all times.
HeidiSQL also supports SSH tunneled MySQL connections, see here for some tutorial.
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:
USER: root
PASS: 123456
Host: LOCALHOST (only)
How is it possible that anyone out there (local) can access it?
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
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.
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.
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:
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,
Get help from a security professional (depends if you want to spend $ or time and frustration to fix)
Apply security patches,
Remove services you don't need,
restrict the database access to only those programs that need it,
redo all your passwords,
check for installed root kits, and other viruses,
secure your server if at your own office and train staff in handling social engineering,
use a service that will monitor and filter the requests coming through and deny direct access (eg use cloudflare as a cheep starting point)
check for keyboard loggers (physical and software and other viruses) on all machines used to access the server),
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)
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:
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
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)
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
man in the middle attack on a connection that has legitimate access
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/
social engineering a way through getting people to give you access
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!)
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/
I last installed MySQL 7 years ago, and don't remember this being asked. If it was, I don't remember my response.
Anyway, I said no today, because why open a port if you don't have to, right?
But I've got a resin-web.xml that wants this filled in:
<url>jdbc:mysql://localhost:3306/''dbname''</url>
<user>''username''</user>
<password>''password''</password>
My first question is: if I open Port 3306 (I guess by creating an Allowed program entry in Windows 7 Firewall), is that risky?
Is there a way to not have to do that and still get to the MySQL on the shared machine?
Thanks for any help.
Nope, you'll have to open it, especially to connect remotely. Just try to lock it down such that it's only accessible from the local subnet, and make sure your Windows machine is behind a firewall or router of some sort to prevent the evil kiddies from the internet.
Be sure to lock down your mysql users too. Don't just allow root#% to access without a password, for instance.
You can also configure SSL connections in Mysql: http://dev.mysql.com/doc/refman/5.0/en/secure-connections.html
I have MySQL installed on a Windows 2003 server on our domain. I cannot connect to it from other machines on the domain. I open up the MySQL Administrator panel and try to change the server name from localhost to the machine name it does not recognize it. I have tried fully qualifying the name also. Any ideas what I need to change?
What sort of error, a total inability to connect? Windows Firewall is the first place I'd look, to make sure port 3306 is open.
have you double checked permissions on the databases using something like
grant all priviliges on 'database'.'*' to 'username'#'remote_machine_ip' identified by 'password';
Like Sukasa mentioned, also double check any firewalls you may have configured
You need to look in the my.cnf file and look for the bind-address setting and the skip-networking setting. You want the latter removed or commented out and the former to be the machine's IP address. Restart MySQL after you make changes.
A number of MySQL install packages defaulted to a local socket only install, which is helpful for security but considerably impairs network connectivity. :-)
I was trying to connect to the database using the default root userid. I created a new user and gave this user read permission to the needed tables.