[Duckington]

Hi,

I was told earlier that:

Quote

your sql port 3306 is open and giving your mysql version details while has a nice auth bypass to its in implimentation:
$ for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done

I've done a bit of googling about it and it seems my MySQL version may be afflicted by this:

http://www.h-online....te-1614990.html


Now I would assume that to stop people being able to do this, I would need to block the port from anyone outside the server being able to access it?

But I've only ever done a tiny bit with firewall configuration and to be honest it really confused me..

Could anyone point me in the direction of some instructions/examples/documentation on how I can do this? (It's a 64 bit CentOS 6.0 server if that makes any difference).

Also, is there a way that when that's been done, I can still get access myself through WorkBench? Because I have a connection set up at the moment so I can quickly get access to the database without having to login to anything else, but presumably that won't work after the port thing is changed..?

Thank you.

[no2pencil]

I believe that centos uses iptables by default. So block port 3306 using iptables, or whatever firewall you chose to run (personally I prefer ipfw), & you are all set.

However, keep in mind that the server, if behind any networking equipment, will not be offering port 3306 to the public, & therefor any requests to port 3306 will die at the modem.

[Duckington]

Wouldn't that mean my php scripts couldn't connect to MySQL then?

[no2pencil]

You should be able to setup iptables to block inbound traffic. If you are using internal scripts for server to server communication, then yes, they would be blocked.

This is a situation where you can't eat your cake & have it too. You can't turn it off & still have it on. Either the port serves or it does not.

As I said in my initial reply, any outside request to port 3306 will die at the modem if the port isn't forwarded. Or you could setup an in-between firewall to drop inbound 3306 requests, & then allow your internal server to server traffic to continue to function.

[Duckington]

Sorry I'm still quite confused, server administration is not exactly a strong point of mine.

The php scripts that access the MySQL database are on the same server as the database, so would they still be able to work in that case?

If not, it seems like an odd choice to have to make... mysql open to easy hacking or no mysql at all.

[no2pencil]

Duckington, on 10 September 2012 - 05:11 AM, said:

server administration is not exactly a strong point of mine.
...
it seems like an odd choice to have to make... mysql open to easy hacking or no mysql at all.

These two statements reflect one another. If the port isn't open, it's closed. If the port is closed, then there is no access, period. Local or public. This is because a socket is connected over the port, & the software binds the port listening for requests. Why I brought up the difference between outbound requests, & internal requests is to try through your firewall to differentiate external requests vs internal.

You really have two options, imo. Learn server administration, or pay for hosting. The world won't grant you a learning curve, so security really is 'live' from day one.

But again, as I stated in both of my previous requests, if your server is not attached directly to the modem, & you have no forwarding rule for 3306, then any outside requests will die right at the modem.

[DaneAU]

I believe in /etc/mysql/my.conf you will find bind-address in the config. By default i believe it is limited to connections from localhost, which is probably enough.

If you are wanting to be careful, then you could actively block connections via your mysql port (default=3306)

iptables -I INPUT 4 -i eth0 -p tcp --dport mysql -s 127.0.0.1 -j ACCEPT
iptables -I INPUT 4 -i eth0 -p udp --dport mysql -s 127.0.0.1 -j ACCEPT

If for instance you are wishing to accept connections over a public network, you may consider using SSH to provide some protection against password sniffing.