Blocking Brute Force Hacking attacks on your FreePBX machine

The only one making assumptions here is you dude… Like I said before, if you want to be a tribalist, go right ahead, I really couldn’t care less. I thought I was helping people by posting something of use to stop hackers and that was a bad mistake. I’m over it.

For example, they turn off most logging, to avoid wearing out the SD card, and because of limited SD card capacity.

Please explain this accusation. How am I being a tribalist? How are any of us being tribalist?

1 Like

Well, the only good thing to come out of this topic is that there’s a link to Lorne’s post on APIBAN.

2 Likes

The original script itself is fine, that was also something that came out of this topic. Again, the firewall solution isn’t what was questioned. It was the reasoning behind it, it was flawed but it doesn’t mean the final product was. It just isn’t something that every FreePBX system needs.

If this was posted in the RasPBX community, where it would actually have a real impact, then it might have a better reaction.

Were any of these brute force attacks against anything but UDP/5060 ?

“This occurs with EVERYONE that uses FreePBX”. First post… HUGE assumption. To back up the supposed “tribalists” : this is not true and never has been. If you aren’t willing to correct your own erroneous assumptions, please do the internet a favor and stop spreading misinformation.

I’ve used the image provided directly from asterisk/sangoma
http:// www. raspberry-asterisk .org /downloads/

Sounds like two totally different images.

Nothing wrong with coming here to share and I appreciate that you put in the time to code a unique solution! Fail2ban, APIBAN, edge firewalls and your script can all be good things in the right hands (and I also say don’t fear re-inventing the wheel if you think it doesn’t do the job), but spreading misinformation, then yelling about it even louder instead of correcting yourself is not a good thing.

2 Likes

@fxpro, rather than sharing code directly in the forum, I recommend that you share links to a repo on github.com or gist.github.com or any code sharing site really. You can then update the project and people who see the post later get the benefit of any improvements. As a new user you would have been prevented from posting links, but you should be able to now.

Thank you for including license terms, but as a practical matter made up license terms like yours are essentially the same as no license at all from my point of view. I recommend you choose established open source terms (GPL/apache/MIT/etc.) and use those.

@fxpro , you look for these regexes immediately

patterns = [
        r"failed for '(\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b)",
        r"UDP (\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b):"
    ]

setup fail2ban ( >=0.9) with a maxretry of 1 for the asterisk jail, (make sure you have pynotify installed) and the regexes covered are

failregex = ^Registration from '[^']*' failed for '<HOST>(:\d+)?' - (?:Wrong password|Username/auth name mismatch|No matching peer found|Not a local domain|Device does not match ACL|Peer is not supposed to register|ACL error \(permit/deny\)|Not a local domain)$
            ^Call from '[^']*' \(<HOST>:\d+\) to extension '[^']*' rejected because extension not found in context
            ^(?:Host )?<HOST> (?:failed (?:to authenticate\b|MD5 authentication\b)|tried to authenticate with nonexistent user\b)
            ^No registration for peer '[^']*' \(from <HOST>\)$
            ^hacking attempt detected '<HOST>'$
            ^SecurityEvent="(?:FailedACL|InvalidAccountID|ChallengeResponseFailed|InvalidPassword)"(?:(?:,(?!RemoteAddress=)\w+="[^"]*")*|.*?),RemoteAddress="IPV[46]/(UDP|TCP|WS)/<HOST>/\d+"(?:,(?!RemoteAddress=)\w+="[^"]*")*$
            ^"Rejecting unknown SIP connection from <HOST>"$
            ^Request (?:'[^']*' )?from '(?:[^']*|.*?)' failed for '<HOST>(?::\d+)?'\s\(callid: [^\)]*\) - (?:No matching endpoint found|Not match Endpoint(?: Contact)? ACL|(?:Failed|Error) to authenticate)\s*$

# FreePBX (todo: make optional in v.0.10):
#            ^(%(__prefix_line)s|\[\]\s*WARNING%(__pid_re)s:?(?:\[C-[\da-f]*\])? )[^:]+: Friendly Scanner from <HOST>$

So, respectfully, how does your code improve on fail2ban 's :wink:

Might also want to consider incorporating ipset with the VoIP Blacklist Contributing would be even better…

Possible a brain reset needed

Where are the Brute force attacks coming from? Do your own analysis but probably something like

99.9% UDP:5060
0.0999% UDP:5000-5099
0.0001% TCP:1025-64000
0.000001% TLS:5061

Yep ipsets for UDP:5060 is currently needed, there are at least 200000 known bad actors. but please also consider why everybody who has moved to TLS:5061 or even just NOT UDP;5060 will likely find these threads amusing !

(if you post back, then yes, I will first ask you if you have actually tried that one relatively simple thing and why it didn’t work for you :wink: )

You think 5061 is just as safe as say 5261 or something less widely used?

No, 5061 is as totally ‘unsafe’ for udp or even tcp transport as any other port, the safety is derived by the transport later for tls which requires the session connects to a url which is not an ip address,and which must have a recognizable valid cert behind it, I suggest the cert you use is not the same as any public facing domain you might have , but you can buy ohshitrandombloodydsgoddam.link for less than $10 a year from namecheap, set a dns record to your pbx and then ask the whirlpool guy to watch sngrep. (Make it easy and install Niel Chang’s acme.sh for firewall free maintenance over DNS-01 with one of most preferred names services)

You can do TLS on any other port if you feel that the bad guys are still dogging TLS:5061 :slight_smile:

But we digress, the fascination is @fxpro 's new wheel here.

1 Like

As far as I know, that is only true for legitimate clients. In particular, there is no reason why a dodgy client should bother the verify the certificate; all it needs is the public key, and it doesn’t need to check ownership to get that.

We don’t want illegitimate clients, but the ‘dodgy client’ does not have an option to not check against a domain it might or might not know and how could it derive the domain name ohshitrandombloodydsgoddam.link to get the public key if it started off as a drive-by IP address shot, but you can have TLS also check the client cert and that is truly secure two way authentication providing the cert has not been otherwise compromised, but I find implementing that in the real world which means installing on each endpoint a cert which will be changing every short while is harder than implementing and so be enforcing vpn’s. This thread is about Brute force Hacking and that just doesn’t happen on transports other than UDP:5060

As I said, if you haven’t actually tried it, probably best to do that before commenting.

Wish it were new. Just downloaded it and sorry if anyone thinks 100 lines of bot produced python is an improvement on Fail2ban. This IS one possible alternative if you don’t like the complexity of fail2ban (and don’t mind iptables hitting a few million entries in short order and crashing your server), but it’s certainly no replacement.

This script may solve one problem, but the huge issue with solutions like this (which is basically what I did before fail2ban came along) is modern bot networks are extremely dynamic, so going from blocking single IPs to netblocks when needed and removing offending IPs or networks once they stop hitting you is critical for public facing services.

Most private PBXs shouldn’t need this or fail2ban, but without an actual dynamic firewall, you might as well simply block everything but your trunk provider(s), then whitelist only (or VPN) remote endpoints as needed… which is something Freepbx (DISTRO!) can actually do reasonably well out of the box these days.

I’ve never put Freepbx on a PI before, but it should be interesting to see how long it takes before he needs a rewrite to purge bad IPs when a) the PI runs out of memory or b) the IPs begin to overlap with providers or remote users.

Sadly, that’s not really true anymore either. Bots are quickly getting more advanced and learning to test, then brute force on alternate ports. I don’t see this on any of my PBXs yet (most are private without remote users and don’t need a dynamic firewall), but my public web and mail servers have been seeing this for a while so it’s only a matter of time :(.

and your expreience of penetration on TLS:1025-65000 is so far ?

I suggested

99.9% UDP:5060
0.0999% UDP:5000-5099
0.0001% TCP:1025-64000
0.000001% TLS:5061

how does your analysis compare ?

as stated , try TLS before you deny it.

Your public IP address is obviously ‘well known’ to the bad guys, so would you share it here with the friendly guys, we could ‘suck it and see’ if you want :slight_smile:

these AI things are mostly regurgitations of ‘group think’ , ask it in any way if an rtp range of 10000 to 20000 is good, it will reply yes because everyone uses it but 3rd grade math students will understand that 10000 to 20000 is actually 10001 ports so is without doubt a wrong choice for rtp which needs exactly 2 per leg, do you still use 10000-20000?

ask it what transport is most secure for voip perhaps, but most of all be knowledgeable about Winston Smith . . .

After reading your comment I took a moment to consider whether or not I need to spend time to put it on GitHub as originally I only thought that I would post the code here just to help those, like me, that had trouble with hackers attacking their FreePBX and were not successful in stopping the hacking (after having my machine actually compromised and traffic running through it), even after activating fail2ban. My script ‘just worked’ and I never claimed anywhere that it was ‘better than’ fail2ban.

After this consideration, although I am reluctant due to the abhorrent display of tribalism and insanity, I thought what the heck, I need to get rid of some of the cobwebs and have a bit of a debate once in a while during my boring life :laughing:, whilst learning something new, both with security as well as with new tricks to block these hackers.

I’ll set up the GitHub shortly and then edit the original posts so that I can remove the code from here and keep it on GitHub like you mentioned so that I can easily post updates and it may help someone.

I shall also update the licensing terms as you suggested. I’m not a coder by trade and although I am taking a course in Python to increase my knowledge, I used GPT4 for parts of the code. I don’t have much time on my side as I’m busy with my own life, so I’ve never published any code outside of closed systems such as TradingView using Pinescript which doesn’t require any such terms.

Speaking as a member of this tribe, you brashly walked in two days ago and have not yet learnt to not piss on the wrong trees, trying to teach the grandmas here to suck eggs will not help your acceptance . . .