Apache WordPress log scanning in BFM (disabled by default) (SKINS)(LANG)

Version 1.47


Brute Force Monitor can now scan the Apache domain logs for WordPress wp-login.php attacks. Internal default directadmin.conf setting: brute_force_scan_apache_logs=0 There are 2 ways of running it (option 2 is likely going to be recommended for most people) --------- 1) to enable scanning of logs manually specified, set: brute_force_scan_apache_logs=1 Next, for any domain you wish to have DA scan, add: /var/log/httpd/domains/domain.com.log= to the file: /usr/local/directadmin/data/admin/brute.conf With the brute_force_scan_apache_logs=1 set, the dataskq will be looking for logs that start with: /var/log/httpd/domains (whatever the directadmin.conf apachelogdir value is set to) No need to worry about adding the pos= and size= value to the brute.conf, as the internally default to 0. DA will crank them up as it goes. -------------- 2) Option 2 for running it: brute_force_scan_apache_logs=2 and DA itself will manage the logs in the brute.conf file for you (it adds all logs) DA loads a loglist from /var/log/httpd/domains/*.log (excluding error.log). Also loads the current /var/log/httpd/domains/*.log files currently saved in the brute.conf into the loglist. For each of the loglist files, if it's missing or size=0, remove from the brute.conf (likely deleted at some point) If size>0, parse it normally, and save to brute.conf. This keeps the brute.conf up to date. This is probably going to be the preferred method for most systems. However, if you know exactly which websites run WordPress, then use the 1st option, to help keep the parsing load down. If brute_force_scan_apache_logs=2 is used, then this variable comes into effect: brute_force_apache_log_list_update_interval=10 which is the number of minutes between the refresh of the apache log list. Missing logs are always removed from the list, but new logs won't start scanning for this amount of time. Time is in minutes, default is 10 minutes between refreshes. It will store "last_refresh" in the brute.conf each time it's updated. --------------- IMPORTANT: Note that apache does not know if a wp-login.php entry was a login failure or not.. All it knows is that a POST was made to the wp-login.php file. Because of this, the Brute Force Monitor considers each POST access to wp-login.php a failed login, even if the correct password was used. Keep this fact in mind when deciding on your IP block limit. If you login and out many times over and over, then DA will consider this an attack, even if the correct IP was used each time. So, make sure you don't add your domain log to the brute.conf until you're done with testing the login system. Possible To-Do: Create a separate login counter max value for these types of logins, as the "failed" count doesn't really apply, logically. ----- useful command to quickly see which domains are being attacked, sorted by number of attempts: cd /var/log/httpd/domains grep -c wp-login.php /var/log/httpd/domains/*.log | grep -v :0 | awk -F':' '{print $2,$1}' | sort -n And then if you want to monitor site sitse with the top 20 most number of attempts (be sure to look at the above output first, to decide), then, eg: cp /usr/local/directadmin/data/admin/brute.conf /usr/local/directadmin/data/admin/brute.conf.backup grep -c wp-login.php /var/log/httpd/domains/*.log | grep -v :0 | awk -F':' '{print $2,$1"="}' | sort -n | tail -n 20 | cut -d\ -f2 >> /usr/local/directadmin/data/admin/brute.conf =================== Bonus optimization found: While poking around in the code, I found a significant optimization to the code for "initial runs" where-by the internal list was previously being sorted after each log entry was found and added. Code has been changed to fill up the list until everything is done, and then only sort it once. For existing runs, it wouldn't change much (only scans changes since the last minute), but for initial runs where there could be hundreds of thousands of log entries found on the first go, sorting the whole list after each entry is added wasn't great (sorting after an entry is added to the container class is it's default behavior to prevent/overide duplicates entries, but doesn't apply in this case, as we know each log entry will be unique) =================== SKINS admin/admin_settings.html added triple radiobox for brute_force_scan_apache_logs=0|1|2 <tr> <td class=list> Scan for WordPress attacks </td> <td class=list> <input type=radio name=brute_force_scan_apache_logs value="2" |BF_SCAN_APACHE_LOGS_2|>All Logs&nbsp;&nbsp; <input type=radio name=brute_force_scan_apache_logs value="1" |BF_SCAN_APACHE_LOGS_1|>Manual&nbsp;&nbsp; <input type=radio name=brute_force_scan_apache_logs value="0" |BF_SCAN_APACHE_LOGS_0|>No &nbsp;&nbsp;<a target=_blank href="http://www.directadmin.com/features.php?id=1695">(?)</a> </td> </tr> =================== LANG lang/en/admin/admin_settings.html LANG_PARSE_FOR_BFA=Parse service logs for brute force attacks LANG_NOTIFY_AFTER_IP=Notify Admins after an IP has LANG_NOTIFY_ADMIN_USER=Notify Admins after a User has LANG_RESET_COUNT_AFTER=Reset count of IP/User failed attempts LANG_CLEAR_BF_FROM_LOG=Clear failed login attempts from log LANG_ALL_LOGS=All Logs LANG_MANUAL=Manual LANG_SCAN_APACHE_LOGS=Scan for WordPress attacks

Interested to try DirectAdmin? Get a 30-day Free Trial!