Can't find which user/process is doing login attempts

wattie

Verified User
Joined
May 31, 2008
Messages
1,234
Location
Bulgaria
I am on MariaDB 10.4, but this is a long running issue from a very long time ago.

Every day in intervals between few minutes I see these entries in the BruteForce Monitor:

Code:
15676386600000	localhost		1	mysql1	2019-09-05 2:10:24 72774529 [Warning] Access denied for user ''@'localhost' (using password: NO)
15676386600001	localhost		1	mysql1	2019-09-05 2:10:24 72774530 [Warning] Access denied for user ''@'localhost' (using password: NO)
15676386600002	localhost		1	mysql1	2019-09-05 2:10:24 72774531 [Warning] Access denied for user ''@'localhost' (using password: NO)
15676386600003	localhost		1	mysql1	2019-09-05 2:10:24 72774532 [Warning] Access denied for user ''@'localhost' (using password: NO)
15676386600004	localhost		1	mysql1	2019-09-05 2:10:24 72774533 [Warning] Access denied for user ''@'localhost' (using password: NO)
15676386600005	localhost		1	mysql1	2019-09-05 2:10:24 72774534 [Warning] Access denied for user ''@'localhost' (using password: NO)
15676386600006	localhost		1	mysql1	2019-09-05 2:10:24 72774535 [Warning] Access denied for user ''@'localhost' (using password: NO)
15676386600007	localhost		1	mysql1	2019-09-05 2:10:24 72774536 [Warning] Access denied for user ''@'localhost' (using password: NO)

That's not a Brute Force obviously - it's not a password cracking attempt as they are not using any password. The problem is that it does not log the user who made the attempt - it's a localhost but all users are there of course

The MySQL error log from which the BruteForce Monitor is fetching the data is not helpful too:

Code:
2019-09-09  2:06:27 86934155 [Warning] Access denied for user ''@'localhost' (using password: NO)
2019-09-09  2:06:27 86934156 [Warning] Access denied for user ''@'localhost' (using password: NO)
2019-09-09  2:06:27 86934157 [Warning] Access denied for user ''@'localhost' (using password: NO)
2019-09-09  2:06:27 86934158 [Warning] Access denied for user ''@'localhost' (using password: NO)
2019-09-09  2:06:27 86934159 [Warning] Access denied for user ''@'localhost' (using password: NO)
2019-09-09  2:06:27 86934160 [Warning] Access denied for user ''@'localhost' (using password: NO)
2019-09-09  2:06:27 86934161 [Warning] Access denied for user ''@'localhost' (using password: NO)
2019-09-09  2:06:27 86934162 [Warning] Access denied for user ''@'localhost' (using password: NO)

(or one of the particulars from above):

Code:
root@srv2:/etc # grep "72774529" /usr/local/mysql/data/<SERVERHOSTNAME>.err
2019-09-05  2:10:24 72774529 [Warning] Access denied for user ''@'localhost' (using password: NO)

I tried looking at the PHP error logs with:

Code:
cd /var/log/httpd/domains
grep "Access denied" *

or even by date/time for specific entry:

Code:
grep "Mon Sep 09 02:06" *.error.log

but did not find anything suspicious there. At this point I tend to think that it's not a PHP script from user who is doing this but something else.

How do I find at least which process is doing this?
 
Last edited:
Cool! Same question over here. How can one find an abusing script? Or something else?

In my case exactly every 5 minutes:
Code:
2019-09-07 22:35:02 140514955360000 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
2019-09-07 22:40:02 140523749037824 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
2019-09-07 22:45:01 140515089577728 [Warning] Access denied for user 'root'@'localhost' (using password: NO)

Would also like to know how to investigate and find such cause.
 
In my case exactly every 5 minutes

Your case looks suspiciously close to my case with the OS difference (I am on FreeBSD). I don't think it's a script. I think it's some daemon which is not configured and it tries passwordless login.
 
I was also thinking of this, since I created a .my.cnf in /root and still the same log occured. Very curious finding this out.
 
I wattie case, maybe it could just be a user that uploaded all the files for a CMS, but did not bother to finish the installation and left it without filling in the database details in a php file? Then this could occur every time someone visit the site?
 
I don't think so. There are too many database hits and they are regularly appearing in few minutes intervals. It's like a cron schedule... but not exactly :)
 
You could check Roundcube logs (or whatever webmail you got), maybe they are automated brutefoces on webmail of some kind? Since I see a whole bunch of them on the same exact time and even second.
 
Nothing in the roundcube logs.

But here is something I fount - SquirrelMail configuration has an option "Database" in the menu:

Code:
# cd /var/www/html/squirrelmail/
# ./configure
SquirrelMail Configuration : Read: config.php
Config version 1.4.0; SquirrelMail version 1.4.23 [SVN]
---------------------------------------------------------
Main Menu --
1.  Organization Preferences
2.  Server Settings
3.  Folder Defaults
4.  General Options
5.  Themes
6.  Address Books
7.  Message of the Day (MOTD)
8.  Plugins
9.  Database
10. Languages

D.  Set pre-defined settings for specific IMAP servers

C   Turn color on
S   Save data
Q   Quit

and when I go to "Database', there are "DSN" entries (data source name?) which are empty:

Code:
SquirrelMail Configuration : Read: config.php
Config version 1.4.0; SquirrelMail version 1.4.23 [SVN]
---------------------------------------------------------
Database
1.  DSN for Address Book   :
2.  Table for Address Book : address

3.  DSN for Preferences    :
4.  Table for Preferences  : userprefs
5.  Field for username     : user
6.  Field for prefs key    : prefkey
7.  Field for prefs value  : prefval

8.  DSN for Global Address Book            :
9.  Table for Global Address Book          : global_abook
10. Allow writing into Global Address Book : false
11. Allow listing of Global Address Book   : false

R   Return to Main Menu
C   Turn color on
S   Save data
Q   Quit

I am not confident that this is used at all and it is the one causing issues. Just guessing at this point. I will read about it later today.
 
In my case the error introduced after migrating to PHP 7.2.
How did you fix it in your case Alex? It seems solved in my case after a conversion to MariaDB, I only see it now once on restarting mariadb.
 
Thank you Alex.
In that case it's probably not what I am/was experiencing. If it happens again I will use the find command. Didn't think of that before either.
 
Back
Top