/var/log/asterisk/fail2ban log file growing by ~10GB a day

Current PBX Version:15.0.16.53
Current System Version:12.7.6-2002-2.sng7

We recently deployed a new freepbx distro. We have done maybe 10-20 of these in the past 5 years without too many issues. On this deployment however, we decided to start using pjsip instead of chansip for devices and trunks. We noticed that after a couple weeks our disk had filled up. After tracking down the culprit, we found it to be fail2ban. More precisely, a fail2ban file inside of the asterisk log directory. I have been trying to research the issue myself by various forums, etc. As well as ensuring all modules are up to date. I can’t seem to put my finger on it so I came here. The root issue seems to be that the file is logging every qualify for every device, things that are purely informational. All the AccountID correspond to extensions that rightfully exist. We only have the server open to SIP communication with our trunk provider IPs (via cisco firewall access lists) and internal network. The log is filled with lines like the following:

[2020-06-05 14:46:06] SECURITY[11052] res_security_log.c: SecurityEvent=“ChallengeSent”,EventTV=“2020-06-05T14:46:06.887+0000”,Severity=“Informational”,Service=“PJSIP”,EventVersion=“1”,AccountID=“1033”,SessionID="f15d3fefb1f4199056c7fe9$

[2020-06-05 14:46:06] SECURITY[11052] res_security_log.c: SecurityEvent=“ChallengeSent”,EventTV=“2020-06-05T14:46:06.887+0000”,Severity=“Informational”,Service=“PJSIP”,EventVersion=“1”,AccountID=“1013”,SessionID="a65b70e45fb5164ec9f3906$

[2020-06-05 14:46:06] SECURITY[11052] res_security_log.c: SecurityEvent=“ChallengeSent”,EventTV=“2020-06-05T14:46:06.888+0000”,Severity=“Informational”,Service=“PJSIP”,EventVersion=“1”,AccountID=“1037”,SessionID="a04feb593b3cec873bf9e83$

[2020-06-05 14:46:06] SECURITY[11052] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2020-06-05T14:46:06.888+0000”,Severity=“Informational”,Service=“PJSIP”,EventVersion=“1”,AccountID=“1066”,SessionID="6ee5f8842162d8e64dee9d$

[2020-06-05 14:46:06] SECURITY[11052] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2020-06-05T14:46:06.900+0000”,Severity=“Informational”,Service=“PJSIP”,EventVersion=“1”,AccountID=“1020”,SessionID="8b4801e6b24731ede25f02$

[2020-06-05 14:46:06] SECURITY[11052] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2020-06-05T14:46:06.900+0000”,Severity=“Informational”,Service=“PJSIP”,EventVersion=“1”,AccountID=“1033”,SessionID="f15d3fefb1f4199056c7fe$

[2020-06-05 14:46:06] SECURITY[11052] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2020-06-05T14:46:06.901+0000”,Severity=“Informational”,Service=“PJSIP”,EventVersion=“1”,AccountID=“1013”,SessionID="a65b70e45fb5164ec9f390$

[2020-06-05 14:46:06] SECURITY[11052] res_security_log.c: SecurityEvent=“ChallengeSent”,EventTV=“2020-06-05T14:46:06.902+0000”,Severity=“Informational”,Service=“PJSIP”,EventVersion=“1”,AccountID=“1031”,SessionID="78efc785c03111b7eddfef5$

[2020-06-05 14:46:06] SECURITY[11052] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2020-06-05T14:46:06.904+0000”,Severity=“Informational”,Service=“PJSIP”,EventVersion=“1”,AccountID=“1037”,SessionID="a04feb593b3cec873bf9e8$

Any help would be greatly appreciated!! Thank you.

These are created by adding “Security” to any log file and that log file is tuned to have as little data as possible for Fail2ban to consume and find malfeasance , so its either smaller logs and no fail2ban or what you have right now without massaging the asterisk “l/etc/logrotate.d/asterisk” file base on file size rather than time, as once fail2ban has ‘consumed’ them, they are no longer very useful.

1 Like

So is that what you would recommend as the fix? Adjusting the log rotate for asterisk based on file size rather than time?

Something like

var/log/asterisk/security {
su root asterisk
   missingok
   rotate 4
   maxsize 250m
   create 0640 asterisk asterisk
   postrotate
     /usr/sbin/asterisk -rx 'logger reload' > /dev/null 2> /dev/null
   endscript
}
1 Like

ok I’ve modified the section with /etc/logrotate.d/asterisk to essentially match:

/var/log/asterisk/fail2ban {
su root asterisk
missingok
rotate 4
maxsize 250m
compress
notifempty
sharedscripts
create 0640 asterisk asterisk
su asterisk asterisk
postrotate
/usr/sbin/asterisk -rx ‘logger reload’ > /dev/null 2> /dev/null
endscript
}

Not seeing any impact on the actual log files yet. I will reboot the system this evening to hopefully give it a kick start. Thank you for your insight.

To test logrotate asynchronously

man logrotate

logrotate -vf /etc/logrotate.d/asterisk

five times

1 Like

Modifying the fail2ban/security section in /etc/logrotate.d/asterisk to essentially match:

/var/log/asterisk/fail2ban {
su root asterisk
missingok
rotate 4
maxsize 250M
compress
notifempty
sharedscripts
create 0640 asterisk asterisk
su asterisk asterisk
postrotate
/usr/sbin/asterisk -rx ‘logger reload’ > /dev/null 2> /dev/null
endscript
}

and then running logrotate -vf /etc/logrotate.d/asterisk
seemed to do the trick.

Thanks dicko!

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.