Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Is it a security risk to leave MySQL port open to internet?
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.

Is it a security risk to leave MySQL port open to internet?

littleguylittleguy Member
edited April 2012 in General

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

  • InfinityInfinity Member, Host Rep
    edited April 2012

    It's more of a security risk to run phpMyAdmin in my opinion.

  • AmfyAmfy Member
    edited April 2012

    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".

  • AmfyAmfy Member

    @Infinity said: It's more of a security risk to run phpMyAdmin in my opinion.

    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.

  • @Amfy said: Please give us a "netstat -tulpen".

    [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/sshd

    @Infinity said: It's more of a security risk to run phpMyAdmin in my opinion.

    I run it behind HTTP auth.

  • @speckl said: It is best to setup MySQL to accept local users only.

    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.

  • AmfyAmfy Member
    edited April 2012

    @littleguy said: 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

  • @littleguy said: My my.cnf file is only a couple of lines long and doesn't contain any port/binding setting.

    Add:
    skip-networking

  • @Amfy said: bind = 127.0.0.1

    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.

    Thanked by 1Amfy
  • AmfyAmfy Member

    @Damian said: Add:

    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...

  • AmfyAmfy Member
    edited April 2012

    @littleguy said: 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.

    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)

    You are a gentleman and a scholar!

    Thanks! You're welcome :)

  • DamianDamian Member
    edited April 2012

    @Amfy said: 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...

    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.

  • raindog308raindog308 Administrator, Veteran

    @Amfy said: echo 'bind = 127.0.0.1' >> /etc/mysql/my.cnf (at Debian / Ubuntu)

    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.

    Thanked by 1Amfy
  • AmfyAmfy Member

    @raindog308 said: 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!

  • raindog308raindog308 Administrator, Veteran

    @littleguy said: 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.

    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.

  • @Infinity said: It's more of a security risk to run phpMyAdmin in my opinion.

    But phpMyAdmin is only limited to MySQL's own security.

  • KairusKairus Member
    edited April 2012

    @Daniel said: But phpMyAdmin is only limited to MySQL's own security.

    And vulnerabilities in your web server, php, and the script itself.

  • @Kairus said: 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

  • @yomero said: 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

  • prometeusprometeus Member, Host Rep

    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

  • @Amfy said: 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?

    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.

  • MrAndroidMrAndroid Member
    edited April 2012

    @dmmcintyre3 said: 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.

    Thanked by 1Amfy
  • @Daniel said: But phpMyAdmin does not store ANY MySQL information.

    Just because phpmyadmin doesn't store mysql user/passwds doesn't mean your other web apps don't.

  • @Daniel said: Why would you store your mySQL details in phpMyAdmin? That just doesn't make sense :P

    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

  • @raindog308 said: but iptables provides another layer

    Layers of security are always good for sensitive stuff... e.g., network layer, daemon layer, user app layer.

Sign In or Register to comment.