How do I get brute force logs to clear

mutualadvantage

New member
Joined
Jul 29, 2011
Messages
2
I'm sure I read that the brute force monitor logs should clear the IP addresses based on the settings in 'Administrator Settings' > 'Clear failed login attempts from log' but for some reason I have logs going back to July 1 - over 4000 pages takes sometime to load.

Is there a defined process I can follow to clear the logs or better still a fix for my problem that clears the logs as expected?

('Clear failed login attempts from log' is set at 5)

Many thanks.
 
I just manually deleted the files /usr/local/directadmin/data/admin/brute_*
 
I have logs going back to July 1 - over 4000 pages takes sometime to load.

Set it to on Admin settings page

Notify Admins after an IP has 500 login failures on any account
Notify Admins after a User has 500 login failures from any IP


that fill decrease number of alerts.
 
I was hoping that there was a way that DA could handle the clearing of the logs automatically or in a 'push button' way.

I have manually cleared the brute_log_entries.list file this time but should it really get to be over 3Gb in size or is this a problem for DA to look at?
 
Clear failed login attempts from log 7 days after entry was made

If it is not working as good as it supposed to work, then you might need to report a bug in an appropriate sub-forum.
 
I just manually deleted the files in /usr/local/directadmin/data/admin
- I see brute_log_entries.list. My servers thank you, one of them to the tune of 155 megs. and 7,505 pages in the log. Something needs to happen to auto-manage that file.
- I left brute.conf, brute_ip.data, and brute_user.data alone. I'm not sure if I should touch them or not.
- I also enabled "Parse service logs for brute force attacks"
 
Hello,

1) Please ensure you're using DA 1.40.3. Since this feature was introduced a few versions ago, many optimizations and improvements have been made.

Regarding the rotation of the brute_log_entries.list file, the newer optimized method reads each line, one at a time.
It then checks the date of each line, which is stored the first portion of the line (index) at the left.
If the date is within the range, it's to be kept, so is appended to a temp file (brute_log_entries.list.temp) as it goes.
The previous method would try and read in the entire brute_log_entries.list file, sort it, go through each entry from the very large memory-set, delete them (which triggers a resort) and then saves. Wasn't very efficient, hence the new method is about as sleek as it can get.

2) If all else fails (sometimes the file is just too big), you can use the old workaround, which is step 4:
http://help.directadmin.com/item.php?id=402

3) Although it shouldn't matter once everything is running, initial runs on the /var/log/* files can be slow if they're very large.
Changing /etc/logrotate.conf to have "daily" instead of "weekly" will keep the logs smaller and make the initial run faster.
After the initial run is done, DA notes it's last read position and filesize, and starts from there, to prevent the re-parsing of the entire file (reason not to delete brute.conf)

4) Lower numbers in the Admin settings (with regards to "Cleared failed attempts log") will keep the brute_log_entries.list file smaller and easier to view/manage.

John
 
A huge thanks for explaining that. It's a great feature with great capabilities. Perhaps the reason I had such a huge file is because I just updated DA yesterday from 1.39x. My list went back to August.
 
Last edited:
Back
Top