Anonymous mySQL user removed via update and broke several sites
Hi,
We just moved to new server (centos -> cloudlinux) both are/were whm/cpanel.
I have 4 big sites that all share access to a generic Geogrpahy database that converts ip addresses to locale, among other things.
I have always had an anonymous user with select privileges to this db set up so any site I program that needs access to it automatically can. This is not a public server we only host for our clients and we are the developers of all sites on the server.
The new server has only been up for two days, and I just found out at 3am that last night around 11:35pm central time an email came in from security advisor stating that: The system"s core libraries or services have been updated. Reboot the server to ensure the system benefits from these updates.
Now, I'm not 100% sure this is related, but at 11:34pm the 4 sites that all require access to this DB went down. I didn't know about it for hours. This means the clients don't know yet, maybe they wont but they might know and I'll hear about it in the morning.
The thing is, is that SA had previously been "warning" me about an anonymous mysql user and provided me a command to run to get rid of it. Obviously I ignored this because its a SELECT perms only on a "public info" database so it was not a concern. After logging in, SA no longer warns me about the anonymous use because the reason all the sites went down was because the access to the database via that permission had been removed.
Why would this new server just take it upon itself to just remove stuff without my input? My old versions of cPanel hosted servers never had an issue or went rouge and did things to sabotage my sites without me doing that manually. I know this had to be done automatically since the server logs show no one else but me has signed into the server over the past 24+ hours.
Anyone have any clue why this would do such a thing? and how to make it not take it upon itself to attempt to be my AI overlord thand act as if it knows better than me in the future?
-
Hey there! The short answer is that it didn't - Security Advisor can't execute any commands on its own. The only "core libraries" that would require a reboot are the kernel, or packages such as glibc. Very few updates require a reboot, so it would be good to know what packages were updated. The easiest way to check this is with the "yum history" command, as that will show a timestamped list of what packages have been installed on the machine. It's worth noting this shows in reverse chronological order, so you'll want to scroll up to find the most recent changes. I'm sorry I don't have more specifics I can provide, but this will likely take some digging to get to a root cause. 0 -
This is the command that was ran that appears to correlate with the time frame of the mysql user being deleted: yum --assumeyes --color=never --config /etc/yum.conf update --enablerepo=cloudlinux-PowerTools --enablerepo=epel Any thoughts? 0 -
That's just the generic "update" command, so you'll likely see that many times in the log output. I'd move on to the DNF log directly to see if there is helpful information there. If you're not finding anything, you can always submit a ticket to our team and have us take a look. 0 -
I'm sorry I'm not sure what the DNF log is, can you elaborate? 0 -
I googled it, found it in /var/log.. Here is what I found, not sure what to make of this: # cat dnf.log | grep mysql 2023-11-14T03:39:04+0000 DEBUG repo: using cache for: cl-mysql-meta 2023-11-14T03:39:04+0000 DEBUG cl-mysql-meta: using metadata from Thu 21 Sep 2023 12:29:11 PM UTC. 2023-11-14T04:57:28+0000 DEBUG cl-mysql-meta: has expired and will be refreshed. 2023-11-14T04:57:48+0000 DEBUG reviving: 'cl-mysql-meta' can be revived - repomd matches. 2023-11-14T04:57:48+0000 DEBUG cl-mysql-meta: using metadata from Thu 21 Sep 2023 12:29:11 PM UTC. 2023-11-14T05:31:05+0000 DEBUG repo: using cache for: cl-mysql-meta 2023-11-14T05:31:05+0000 DEBUG cl-mysql-meta: using metadata from Thu 21 Sep 2023 12:29:11 PM UTC. 2023-11-14T05:33:12+0000 DEBUG repo: downloading from remote: cl-mysql-meta 2023-11-14T05:33:13+0000 DEBUG cl-mysql-meta: using metadata from Thu Sep 21 12:29:11 2023. 2023-11-14T05:34:34+0000 DEBUG repo: using cache for: cl-mysql-meta 2023-11-14T05:34:34+0000 DEBUG cl-mysql-meta: using metadata from Thu 21 Sep 2023 12:29:11 PM UTC. 2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta.solv 2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta-filenames.solvx 2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta-36fa755ec5e5b761/repodata/3b38a7474aa81f20798f3eee14374e704e95645d8dec86d3de12c1d8412ef1c5-primary.xml.gz 2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta-36fa755ec5e5b761/repodata/6fe0ca12088ffa726cfeaefe9288d3f1b64894cd2ff6e801686572e001d5cb17-modules.yaml.gz 2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta-36fa755ec5e5b761/repodata/090a23dd014750801415ef2e6c12467eb1e9d61cdbb7642deb204fc20ebf7277-filelists.xml.gz 2023-11-14T05:34:39+0000 DDEBUG Removing file /var/cache/yum/cl-mysql-meta-36fa755ec5e5b761/repodata/repomd.xml 2023-11-14T05:35:10+0000 DEBUG repo: using cache for: cl-mysql-meta 2023-11-14T05:35:10+0000 DEBUG cl-mysql-meta: using metadata from Thu Sep 21 12:29:11 2023. 0 -
It does look like there could have been a MySQL update during that time. I'd still recommend a ticket so we can check this out. 0
Please sign in to leave a comment.
Comments
6 comments