Or, "How to shoot yourself in the foot in 60 seconds". Your MySQL server is now exposed to the internet; your only hope is that it contains no vulnerabilities. Also, allowing MySQL-root access from an outside machine is...unwise, to say the least. Moreover, you have now broken any scripts expecting the MySQL server to listen on 127.0.0.1, and you need to fix their config.
A much more secure way would be to make a SSH tunnel, and forward the SQL connection through it - for the MySQL server, the traffic still originates from localhost, you are not exposing the MySQL server for the whole world to crack, and SSH provides significantly better security options than MySQL could hope for. (This has the drawback that you need to set up the SSH tunnel before connecting with the MySQL client, but 1. most decent SQL tools can do this for you automagically and 2. if yours can't, it's a simple command-line invocation)
Everything has a risk, but not all risks are equal. You seem to be saying "no point in closing or even locking the door, just leave everything wide open and put up a sign saying 'please do not enter'; it's the same, as everything has a risk." Is the difference in risk clearer now?
As for the example, SSH (or most other remote access solutions) has much more secure modes of operations than MySQL (or any other database) - which shouldn't really be surprising. One of these products is a database (where security is just an afterthought), whereas the other is a tool for secure remote access (where security is the main goal; unless you're the type of user who's blindly clicking "yes yes yes agree yes agree sure yes yes," it's very hard to break SSH).
If you insist on deploying insecure systems, that's mostly your problem; please don't advise others to do likewise (as you're actively causing harm by this).
Yup, the topic was "let's just open the server directly onto the network, after all, nothing bad could ever happen on the Internet" (For next topic, I'd suggest "someone hacked my server, stole my data and made it a part of a botnet, halp!!1!").
5 comments
[ 2.9 ms ] story [ 18.0 ms ] threadA much more secure way would be to make a SSH tunnel, and forward the SQL connection through it - for the MySQL server, the traffic still originates from localhost, you are not exposing the MySQL server for the whole world to crack, and SSH provides significantly better security options than MySQL could hope for. (This has the drawback that you need to set up the SSH tunnel before connecting with the MySQL client, but 1. most decent SQL tools can do this for you automagically and 2. if yours can't, it's a simple command-line invocation)
The user 'root' was just an example.
As for the example, SSH (or most other remote access solutions) has much more secure modes of operations than MySQL (or any other database) - which shouldn't really be surprising. One of these products is a database (where security is just an afterthought), whereas the other is a tool for secure remote access (where security is the main goal; unless you're the type of user who's blindly clicking "yes yes yes agree yes agree sure yes yes," it's very hard to break SSH).
If you insist on deploying insecure systems, that's mostly your problem; please don't advise others to do likewise (as you're actively causing harm by this).
i will post a topic about ssh tunneling if that makes you happy. :)