New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Is it a security risk to leave MySQL port open to internet?
Here's a snapshot from my users:
http://i.imgur.com/vtChA.png
(Crossed out are my custom users with access only to a certain database on localhost)
The question mark I have is the "Any" % user with a password (I have not set any.) Is this common in MySQL setups?
What are the associated security risks of not blocking the port?
Comments
It's more of a security risk to run phpMyAdmin in my opinion.
Wouldn't say that mysql is open to the world, when you see something like that in phpmyadmin.
These things above are only for the users, it's more important, what you my.cnf or netstat -tulpen says. In your my.cnf you can choose on with network mysql is bind to.
Please give us a "netstat -tulpen".
Why? It's only a php script. When I won't write any user detailed infos in the config from phpmyadmin, run it as an own user it shouldn't be that unsecure?
It is best to setup MySQL to accept local users only. Then if you need remote access, set those users up specifically and bind them to their correct ip's. Having MySQL remotely accessible for no reason is a security risk.
[root@s ~]# netstat -tulpen Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 27 9369 1436/mysqld tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 0 8274 1179/master tcp 0 0 0.0.0.0:4711 0.0.0.0:* LISTEN 0 7960 968/sshd tcp 0 0 :::80 :::* LISTEN 0 9421 1461/httpd tcp 0 0 :::4711 :::* LISTEN 0 7962 968/sshdI run it behind HTTP auth.
Is it possible to do this without iptables? My my.cnf file is only a couple of lines long and doesn't contain any port/binding setting.
echo 'bind = 127.0.0.1' >> /etc/my.cnf (at CentOS)
echo 'bind = 127.0.0.1' >> /etc/mysql/my.cnf (at Debian / Ubuntu)
than service mysqld restart // or
/etc/init.d/mysql restart
Add:
skip-networking
You are a gentleman and a scholar!
On a related note, are there any security or performance issues arising from not running iptables? I don't see a need for it as I only run SSH/Apache outwards.
skip-networking
Some months ago, when I had the same problem, that was also my first opinion. But it hasn't worked on CentOS, because then mysql disabled the whole network and the only way to access it was the mysql socket...
Right, I also would say it's okay not to run it (because you have nothing really to protect/drop :P). My servers arent't configured with any rules (except some IPs which I have dropped because of massive ssh bruteforce)
Thanks! You're welcome
Yes, that was my point. Sockets have been cultivated for the past 30 years, so barring a few magic methods, they do not have security issues.
I thought the preferred way in debian was to create your own .cnf files in /etc/mysql/conf.d and override or add anything in those.
Ah, good idea!
It's a point of philosophy more than anything in my opinion.
iptables is helpful if you want to control access to/from certain IPs. Only certain IPs can rsync to one of my VPSes. Yes, you can control that in the rsync config, but iptables provides another layer. More layers is good :-)
It's also helpful if you have users and you want to prevent them from starting their own services. i.e., joe user fires up some kind of daemon - he can't do that if you have a default-deny-style iptables ruleset in place.
It's also a helpful from a sysadmin POV because now it takes two steps to enable a service. I discovered not long ago that proftpd was running on one of my VPSes - I'd installed it and hadn't turned it on, but Debian's installer did. Didn't matter because I didn't have that port open.
Finally, iptables is useful to have around for on-the-fly rules additions. I had some idiot hammering my web server a while back - I suspect he was trying to attack someone else's and mistyped the address. Because I'd already setup a rules file, had a script to stop/start iptables, etc., it was easy to put a rule in to drop everything from his IP. Of course, I could have done it even if I'd never run iptables, but now I have it sitting there in my rules file (commented out now), ready to do a quick modification and run again if someone else in the future is a problem. More a convenience thing than anything else.
Just my two packets.
But phpMyAdmin is only limited to MySQL's own security.
And vulnerabilities in your web server, php, and the script itself.
But phpMyAdmin doesn't use its own login system it uses mySQL. So if you find a vulnerability in the script you can't do anything unless you have a vulnerability in MySQL.
@Daniel
Good point... Unless you use a weird xss/sql injection and use the permanent phpmyadmin storage... Other users can get affected
Why would you store your mySQL details in phpMyAdmin? That just doesn't make sense :P
Actually you can protect phpmyadmin with a first layer of authentication (or access control) using the webserver and then let phpmyadmin authenticate users using mysql authentication
If you have phpmyadmin (or other web based mysql admin software) installed, and someone finds it and a way to make your web app leak the mysql user/passwd, they have full access to the database. If you don't have phpmyadmin installed and mysql only listning on 127.0.0.1 or locked down to only the IPs you need to access it from, they can't do anything with that database username and password as long as it's not used elsewhere.
But phpMyAdmin does not store ANY MySQL information.
Running phpMyAdmin has the same security as running remoteSQL.
Just because phpmyadmin doesn't store mysql user/passwds doesn't mean your other web apps don't.
No, but the settings to phpmyadmin and every user.
A comples SQL injection could load the settings for each user and execute specifical queries to their databases
so bad
Layers of security are always good for sensitive stuff... e.g., network layer, daemon layer, user app layer.