I figured it out. While /etc/mysql/my.cnf didn't have a password keypair stored, there was a password stored in /root/.my.cnf.
As soon as I commented out the password in /root/.my.cnf, I was not allowed to log in without a password (which is what I expected).
Is the TCP port SQL Server is listening on open globally?
If so, yes I'd be concerned. If there is a password that can be brute-forced or guessed, or an exploit that allows someone to bypass authentication, eventually your database could be compromised. You'll also be vulnerable to attacks that don't require access, such as someone filling up the drive that that has SQL Server error logs on it by creating many failed logins every second.
If the TCP port is open to the internet, the unwanted login attempts are normal. Based on my experience working at ISPs and hosting companies, a machine that's exposed to the internet will get probed on well-known ports all day (and port scanned periodically) if traffic isn't being dropped by a firewall.
On the other hand, if you have restrictive firewall rules that explicitly allow 124.117.233.94 through, it's likely that one of your customers or colleagues at that address has had a computer compromised.
You can currently read about controlling traffic to Azure Virtual Machines here. A good practice is to drop everything by default and explicitly allow only the traffic you want. Perhaps someone else will edit this to add further information.
Best Answer
Also you can use fail2ban for this goal as too easily way . In this case you just install it on you linux OS, then enable the section for
[mysqld-iptables]in the /etc/fail2ban/jail.local.This program check the mysql logs by its own given pattern and then blocks the IP addresses which they try to login more than 5 times, in iptables.