[Fail2Ban] SIP: banned 94.26.125.80 on localhost 36 emails per day

Hi guys,

I am currently getting 36 emails per day with messages like this:

Hi,

The IP 103.145.13.159 has just been banned by Fail2Ban after
14 attempts against SIP on localhost.

Regards,

Fail2Ban

How worried should I be?

Sometimes the number of attempts is over 300. This email was only 14.

To clarify, just today (11th September) I got 36 separate emails with 36 different IPs banned. Should I be worried? This only happened recently because we got a static IP from our ISP.

It depends on whether you have a legitimate need to be accessed, from, in this case Palestine and the Netherlands, by remote users, whether you have strong passwords on all your phones, and whether the from-pstn context can do anything (financially) harmful. If you don’t need to be accessed from high fraud risk countries (I’m not sure that the Netherlands i particularly high risk), you should have blocked their address ranges with static rules, or only opened address ranges for providers legitimately used by users of your system.

Using a very non-standard port number, can also reduce attacks, and reportedly TCP and TLS also don’t get attacked much.

1 Like

Palestinian attacks have been relentless for years but mostly just noise , the Dutch IP’d are a front for a relatively recent (couple of years) but very sophisticated ‘eastern european’ botnet often double blinded via Finnish domains and behind the last few penetrations of FreePBX, as long as you listen on UDP/5060 you will be vulnerable . (you will likely see them or there derivatives in your http logs also)

1 Like

Its not just palestine or netherlands, is like a huge range of countries across europe and probably US too. I havent looked up but all the IPs are different.

Will try set up on a different port. Thanks

I will change my UDP port to something other than 5060. Thanks

Change your bantime on fail2ban. 36 times per day - sounds like you probably have what most do of 10 minute ban time. Change it to a day, week, or month. Long as you know who is supposed to be connecting, this will push them out quick. Since they know they can re-attack you so soon afterwards, you’ll be on their list of attempts to be made. Even changing UDP port - they’ll probably find your port again, so changing the ban-time can shut them down for a length of time that makes the attempst not worthwhile on their end.

4 Likes

Thank you

Hi, what settings do you recommend here? This is what I currently have.


This is the times I have used. 3 failed attempts = banned for 100 days

Attacks from different IPs may just mean that attackers are using the tor network with random exit-points for their try-and-error attacks.
As mentioned above, you may reduce the accepted number of failures, and increase the find-time - for which failures will be detected, and also ban detected attackers for some more seconds or even set -1, which means “forever”. If so, you may have some times the need to un-ban yourself best by a second legitimated ssh-access from a third IP which is whitelisted, or un-ban legitimated phones coming in by a up-to-now unknown IP (e.g. mobile phones).

You can edit your incorrect posting to correct it.

thanks david, newly learned.

Please be very distrustful on attackers, which may use your outbound phone-number. Its not only because of your own pocket directly, but as well because of callers which will fake to be an employee of your organization. Currently a real caller from Beirut +961 1 orders funds transfers on banks pretending to be a corporate customer of this bank. Whats about, if he learned how to call the bank by the extension of your CFO? Or even, if any call to any bank looks like to come from one of your extensions instead of +961?

Until STIR/SHAKEN is working properly, globally, it’s easier for the fraudster to spoof the caller ID directly, without going anywhere near you or your provider.

This isn’t exactly true. These types of attacks have existed long before Tor was a thing.

attackers are almost exclusively attacking UDP/5060 the incredibly simple solution is to not accept those connections