Fail2Ban and ChallengeSent Event

Hi. I have Fail2Ban on a system and works great stopping attacks on SIP registrations and SSH brute force attempts but, I have recently noticed a bunch of SIP registration attempts where the other side doesn’t seem to offer a password when asked and so I just keep getting the following constant records in the “security” log…

[2019-05-21 12:03:55] SECURITY[100431] res_security_log.c: SecurityEvent=“ChallengeSent”,EventTV=“2019-05-21T12:03:55.417+0100”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:100@",SessionID=“0x804cf1820”,LocalAddress=“IPV4/UDP/MY_PUBLIC_IP_REMOVED/5060”,RemoteAddress=“IPV4/UDP/”,Challenge=“7e8ada93”

I get them from different sources, some don’t have a route back to them and so I can understand why they might not get the challenge event for them to respond with a password but some do and so, likely they just have badly configured scripts.

Anyway, I need to stop them. It seems they are not going to get anywhere on my system but, they do fill up the logs and i’d like to just drop their IP. I use FreeBSD and IPFW and use a table which bans the IPs when Fail2Ban spots something.

I understand these challenge events are normal and so I can’t just ban them when they are seen because this would also ban legitimate users. I am wondering if there is a threshold I could apply, ie, if there are 60 of these ChallengeSent from a particular IP within 30 minutes or something like that could I then ban the IP? Basically, what would be acceptable from a legitimate user and what wouldn’t be and I can maybe set up a rule based on that?

If fail2ban cant prorect you agaisnt this you will need to ban the IP manually, or write your own script who listen to AMI event ChallengeSent and if RemoteAddres is not a trusted IP, just block it automatically, using PHP or Python is an easy task

Likely it is like you say, a script would need to be created but possible a more direct method would be to pick up the user agent field from requests and capture any that use the likes of “sipcli/v1.8” and any other similar tools used and ban the IP. I captured some sip debug output and all these attacks came from a “sipcli/v1.8” user agent.

What I have done currently is use IPFW to restrict traffic to the SIP port to just the networks that should be, ie, internal networks and the SIP trunk provider, this has killed off the attacks dead straight away so, so far so good.

$cmd 60030 allow udp from to me 5060 in via $pif
$cmd 60031 allow udp from to me 5060 in via $pif
$cmd 60032 allow udp from to me 5060 in via $pif
$cmd 60033 allow udp from to me 5060 in via $pif
$cmd 60034 allow udp from to me 5060 in via $pif
$cmd 60035 allow udp from to me 5060 in via $pif

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