Missing ip address in log - can’t ban with fail2ban (still problem in 2021)

This was originally reported about a decade ago here: Missing ip address in log - can't ban with fail2ban

The problem remains unfixed. On my brand new asterisk installation (brand new ubuntu 20 server, freshly installed asterisk 16.2.1, I am seeing my log files flooding with messages like this:

[Oct 2 22:28:56] WARNING[10592]: chan_sip.c:4178 retrans_pkt: Timeout on 1960475124-185555950-1418451360 on non-critical invite transaction.
[Oct 2 22:28:57] NOTICE[10592][C-0000018a]: chan_sip.c:26601 handle_request_invite: Failed to authenticate device sip:300@MY_SERVER_IP_IS_HERE;tag=1117068098

There is no way to configure fail2ban or other similar software to automatically ban the offenders that are triggering these messages, because asterisk still, to this day, does not include the IP address of the offender in these messages. It instead nonsensically includes the ASTERISK SERVER ip, which doesn’t help anyone.

These attempts are driving up the load average on my server and causing the disk to fill up rapidly as the messages are absolutely flooding my logs and scrolling at extremely high speeds.

Is there any way to fix this without having to go into the asterisk C source code files, manually adding the offender’s IP to the function that writes these log messages and then recompiling it as was suggested in the 10 year old thread I linked here?

Is there any easy fix for this?

This is a SERIOUS problem and has persisted for a decade now.

I have seen this brought up countless times before over the past decade. I’ve noticed people frequently respond saying stuff like “don’t open port 5060 to the internet” or “don’t use port 5060, use another port number”, etc. All of these are band-aid solutions that dance around the issue. Sometimes, people HAVE to use port 5060, and HAVE to keep it open to the internet because they have clients with dynamic IP addresses that are accessing the system over the internet.

We need a real solution to this problem besides “don’t open port 5060” or “only allow connections from certain IPs”. We need a way to actually see the IPs that are launching these massive brute force attacks on our systems.

Edit: AFter a bunch more head scraching, I discovered that if you enable “security” logging in /etc/asterisk/logger.conf, and edit fail2ban to look at /var/log/asterisk/security instead of messages, it seems to work. the failed authentications appear to be logged in /var/log/asterisk/security

This problem comes up enough that I think it should be default behavior. I can’t imagine how many folks have run into this problem and pulled their hair out trying to solve it. If Asterisk did this by default, a vanilla install of fail2ban with the default asterisk jail would work. Unfortunately, with the way asterisk is set up now, the user has to do a bunch of additional and not so obvious configuration to harden their system.

https://www.fail2ban.org/wiki/index.php/Asterisk

(I’d argue that fail2ban, itself, is often a band aid for proper whitelisting of service providers and VPNs for staff working from hone or in the field.)

(The above link was the second hit from googling “using fail2ban with asterisk”. I looked at it first because it was from fail2ban’s own web site.)

+1

F2B is for miscreants within whitelisted blocks.

Whitelisting is cheap and effective. “Security in layers”

It’s like ‘build the wall.’ If you have a solution that is cheap and effective against 90% of the problem, you can focus on the remaining 10% with the resources you have available.