FreePBX 16 fail2ban log

SIP doesn’t have logins. These are authentications, and they apply to individual requests. A successful authentication is more important to know about that a failed one, if it turns out to have come from an attacker.

You didn’t post your fail2ban conf file and you seem to have two ‘rotates’ configured but chosing just one, either renaming to date or just the standard by number and changing rotate from 7 to 3 should fix it.

You don’t say how you installed FreePBX but each recipe usually provided a generic rotation of logs it generates, you would have to complain to the relevant distributor.

This is my fail2ban.conf file. I changed loglevel from 3 to 1 a while ago but all these challenge messages never went away.

Fail2Ban main configuration file

Comments: use ‘#’ for comment lines and ‘;’ (following a space) for inline comments

Changes: in most of the cases you should not modify this

file, but provide customizations in fail2ban.local file, e.g.:

[Definition]

loglevel = 1

[Definition]

Option: loglevel

Notes.: Set the log level output.

1 = ERROR

2 = WARN

3 = INFO

4 = DEBUG

Values: [ NUM ] Default: 1

loglevel = 1

Even if I change logrotate from 7 to 3, some of the fail2ban individual files are like 3GB and more. It might still take up most of the disk space on the server. I need to reduce the amount of logging coming from fail2ban and there doesn’t seem to be a way to do that. No one has ever told me that so far.

Also, if my logrotate is set to 7 by defail, why are there so many fail2ban files left with long numbers at the end like fail2ban-20230407. Why can’t it keep the log to exactly 7 files, or 3 files if I set it to 3?

I’m seriously considering turning fail2ban off. There were multiple posts like mine @dicko and you seemed to answer to each one with a different solution and non of those helped recude fail2ban logging. My fail2ban is eating up all of my disk space and it is getting redicolous. Out of the box FreePBX16 installed from a distro on a digitalocean cloud server. Nothing out of ordinary, yet FreePBX is failing to fix this.

The configuration you provided is for fail2ban output logging, but the log sample you provided is the Asterisk security log, which is the input to fail2ban. That is controlled by /etc/asterisk/logger.conf (which I think is owned by FreePBX in FreePBX systems), and, as far as I know, it is all or nothing.

Your directory shows 7 of these files, which is consistent with the logrotate configuration you provided. I presume the files with dates in their names are the outputs from fail2ban, which is what your log level setting will control. I would say the logrotates were doing what was asked of them.

A typical messages is 388 bytes (I did my rough calculations based on 200. 200 extensions with 5 minute registrations, would come to about 22.5MB a day (I think I got the number of 5 minutes a day wrong, before as well as the message length). However the actual registration interval could be as little as half the maximum, so we are at about 45MB a day. We are still out by about two orders of magnitude, so I think you need to look at exactly what traffic you are getting. Something may be registering far too often. The security log files will tell you which extension tried to authenticate, but you will probably need to use sngrep to really understand what is going on.

Demangled version of your file follows:

# Fail2Ban main configuration file
#
# Comments: use '#' for comment lines and ';' (following a space) for inline comments
#
# Changes:  in most of the cases you should not modify this
#           file, but provide customizations in fail2ban.local file, e.g.:
#
# [Definition]
# loglevel = 1
#

[Definition]

# Option: loglevel
# Notes.: Set the log level output.
#         1 = ERROR
#         2 = WARN
#         3 = INFO
#         4 = DEBUG
# Values: [ NUM ]  Default: 1
#
loglevel = 1

As has been stated here in this thread already, the file /var/log/asterisk/fail2ban is generated by Asterisk, disabling fail2ban will have zero effect on this file. This file is verbose by design, pretty much any event that asterisk deems related to security is logged here. When enabled, fail2ban will watch this file for spurious activity and react accordingly.

I expect that the reason these files are so large is due to having your Asterisk services exposed to untrusted traffic. You should address this before you start worrying about logfile minutiae.

On the FreePBX distro, logrotate is configured by default to rotate daily and purge after 7 days. However, the log volume in your case is such that Asterisk is also rotating the files, that’s where the .0, .1 and .2 files are coming from. You’ll want to remove those manually and in Settings → Logfile Settings set Log Rotation to none to disable the Asterisk rotations so that logrotate will take care of it.

3 Likes

Thanks for your responses, I appreciate it.

No, my FreePBX is closed down and all these challenges come from the authorized extensions and all of them are showing successful authentication.

Still noone has answered why an out of the box PBX would have this issue and how to fix it.

The Adtrans that are registered to all these extensions are set to registration expire in 5 minutes. But even if they re-register every 5 minutes, why would there be so much unnecessary log that it takes up so much space.

A ‘brand new FreePBX right out of the box’ listens to connections to UDP/5060 . The remote address and local address can be spoofed but do a reality check on them anyway that they match where the accountID is expected to be , because of the above , many recommend not using that port or protocol, as they are invariably less noisy.

sngrep is an effective way to see incoming connections

Thanks! I’ll try sngrep and get back to you guys.

I just logged into that FeePBX instance and it was about to overfill with the fail2ban logs again. Without erasing anything manually, I just ran this command to rotate the logs, and it deleted all the GBs of those logs.

logrotate -vf /etc/logrotate.d/asterisk

Could that mean my logrotate is not rotating those logs and not deleting them?

How can I troubleshoot logrotate and what it does in the system and find out if logrotate is the issue.

Make sure you have the /etc/cron.daily/logrotate present or it 'won’t rotate :slight_smile:

I just did sngrep on 2 of our PBXs and it looks like some extensions have a lot more traffic than the others. Some extensions only register and receive 200 OK message and that’s it. But other extensions for some reason try to register a bunch of times, then receive Unauthorized message, then try again and receive 200 OK message, and it goes on and on. It looks like those extensions are cluttering the resources on the server.

What could that be? All of the passwords are correct and in the web gui all extensions are registered and working.

What chanel tech are you using? default chan_sip will ‘alwaysauthreject’ until the caller better identifies

We always use pjsip and a custom port number. This is only happening with Adtrans on as clients. When I sngrep the PBX that has only Audiocodes ATAs, the results look very clean.

To answer “What could that be?”, I would suggest misconfiguration of the adtrans device perhaps or perhaps that they just behave that way, (quite normal in my experience) :slight_smile:

Just checked again and on the Audiocodes PBX it happens once in a while, but just not as many unauthorized and then OK messages as with the Adtrans. Why do they get unauthorized first and then are allowed to register I don’t get it?

It is an age old prophylactic method to make sure the caller is actually who they say they are, (SIP over UDP is quite lax with security and checks)

I’m kind of confused here. When I sngrep on these congested PBXs, it looks like these authorizations are just constantly happening. Why are the constantly happening if our Adtrans are only configured to expire every 5 minutes? And again, is there any way to just let it authorize and wait until another successful attempt? I’m really confused with the sngrep output.

I just found the problem. For some reason when we configured the Adtrans to expire in 300 seconds, they would constantly expire every 5 seconds, not within desired 300 seconds. Maybe a config glitch in the Adtrans. Putting them back to default 3600 seconds fixed the issue.

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