Distributed SIP brute force attacks protection for the community

FreePBX Security
,
21

Not using UDP even more effective, TLS with an obscure domain particularly so, but most recent successes have been initially against your exposed ‘well known’ HTTP ports, not your SIP transport, sharing the same domain for web access with your SIP or webrtc or provisioning over ‘secure’ transport particularly not a good idea.

A firewall without port scan and connection limiting and prevention, also not recommended, I have used

https://www.configserver.com/cp/csf.html

for years successfully, totally compatible with any other iptable set of rules.

22

Should give what’s configured in your FPBX f2b whitelist, yeah?

23

Totally agree.

@dicko
Also it’s obvious that using different port will just reduce noise, although if you are supporting already established infrastructure - it’s not a trivial task to change the service port for thousands of phones/softphones, etc…

In ideal scenario if I’m to design it from scratch - it’ll be firewall, sip-proxy/sbc behind it and all the FPBXes behind proxy.

Reverse DNS - giving some non-existing FQDN in your SIP setup and then:

  1. if proxy sees query to IP addr - ignore and mark remote IP as scanner
  2. if proxy sees query to non-existing FQDN - ignore and mark remote IP as scanner
  3. if this is existing FQDN for one of your sip customers - proxy passes it to the customers FPBX.
  4. Additional logic to your taste - when IPs marked as scanners will end up on your central firewall to block that traffic at all.
24

Thanks for sharing, looks interesting.

25

Dicko, you’re using CSF on FPBX?
We use it on hosting boxes… interesting if so.

26

I think that could be of value.

27

I am. I start and stop other chains (mostly f2B) with csfpre.sh and csfpost.sh and have fail2ban insert it’s chains after csf’s

28

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