Integrating with FreePBX

The script looks like it is using individual iptables rules for each IP(and apparently without aggregation), so yes, at some point thousands of rules will have a negative impact from a performance and memory perspective. The better option would be to use ipset, then a single rule can efficiently handle hundreds of thousands addresses.

I use multiple blacklists and geoblocking, but mainly to cut down on what I log. My rulest is otherwise secure and I would be comfortable without any of the blacklists.

Blacklist and geo-blocked traffic is dropped early and logged to a separate “just in case I need it” file. It keeps the “real” log file clean and easier to parse. Makes it much easier to see if there is a real problem.

1 Like

What is a good use case for any of these blacklists? If you just need (for example) UDP SIP access from previously unknown IP addresses (mobile data, residential dynamic IP), whitelisting a ‘secret’ domain name is IMO greatly superior. It’s very simple, requires no maintenance and doesn’t depend on any third parties (other than your DNS provider). But most importantly, it blocks 100% of random attacks, so you can have fail2ban (or other IDS) alert you to even one banned IP, whether from a targeted attack or a misconfigured client.

A blacklist would make sense if you intentionally allow access from the public, for example with a ‘call me’ button on your website or by publishing a SIP URI. Although IMO both of these are bad ideas for reasons unrelated to security, they are popular so we should explore how to secure them. It’s a huge risk to expose a PBX directly to such traffic; a SIP proxy that forwards only the ‘public’ service to the PBX is a must. It’s the proxy that needs the blacklist to keep the swarm of bots from hammering it and DoS-ing the service. The PBX just needs to whitelist the proxy’s address.

Does this work regardless of the SIP client in use to randomly connect from wherever the users are?

AFAIK any SIP device or app less than 20 years old will accept a domain name for the server/proxy.

Ah, you mean to use SIP Domains?

What is the pjsip equivalent to the chan_sip domain = syntax?

hi, What´s diffenrent apiban vs geoip.

apiban cpu working?

No, I mean iptables is set up so SIP packets other than established/related are dropped if they don’t contain the domain name. A simplified example:

Combined with Apache configuration that rejects requests without the proper domain (admin GUI, UCP, provisioning, etc.) an attacker that doesn’t know the name will not even be able to discover that you have a PBX.

1 Like

Do you have another strategy for TLS connections or not use them?

I don’t have a good strategy for TLS but believe that a good one is possible and would very much like to discuss it.

HTTPS for admin GUI and UCP is no problem; all modern browsers support SNI.

HTTPS for provisioning is an issue for some older devices without SNI. I believe that using HTTP with encrypted content is an adequate workaround; nearly all devices made in the last 15 years support it.

SIP over TLS is the big issue. I’d like to find a survey of IP phones, ATAs, softphones and SIP apps detailing which TLS features are supported. Requiring a client cert signed by the org is best, as that also defends against targeted attacks. SNI would be next best, but I suspect that most devices that don’t support the client cert don’t support SNI either.

Any ideas in this area would be most welcome.


Day 4 - More of the same. There seems to be about 1 case a day where a single IP gets thru the blacklist and attempts to do something it shouldn’t. Actual brute force attempts are stopped by fail2ban, the anonymous calls just seem to stop on their own after a few min of getting nowhere.

IP rules set is now at 500

1 Like

Would have to comment that there are probably more than 500 ip’s in the world involved in trying to get to UDP/5060.

This blacklist seems to be adding about two /32 networks per hour, It might take a while to catch up.

This will also be an ongoing problem because this blacklist is incremental and supplemental , so duplicate blocks will further bog iptables down and there is no mechanism to sanitize the chain

2020/08/23 02:10:22 Blocking
2020/08/25 15:20:01 Blocking

(That address has also long been in VOIPBL, but only once :wink: )

OK, take two

If you listen on UDP/5060 there will be lots of hits and you can add blacklists and chains and all sorts of stuff to filter that crap out, be that a 500 record blacklist or a 100000 blacklist. (I will let you choose the likely effective one, you can of course use more than one but use ipset over iptables at your peril)

If you only listen on TLS/5061 with a domain name that returns your ip address with “dig x” any ‘hits’ will mean that you are the subject of a second level directed attack. (there is nothing to stop you using TLS/50619 if you want to)

As @sorvani suggested using a domain name WITHOUT any reverse DNS records kinda makes you really quite robust but the certs used might have to be self-generated.

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

I haven’t had time to look at it yet, but a new project was launched at Kamailio World which was this last week. It adds API functionality for managing apiban (or managing the apiban iptables chain). It would be great if some Samaritan would document installation and simple usage with FreePBX:

It occurs to me that iptables isn’t really designed for long blacklists. It will have O(n) behaviour on the size of the list. A little searching reveals that there has been a feature called ipset, that has been around for a long time and allows parallel searches of such lists using hash tables, although I also found a reference suggesting that iptables + ipset was being replaced with something called BPF.

Even without extensions, I suspect that creating a decode tree would be better, and the tree might turn out quite shallow in some parts of the address space that tend to be frequented by legitimate business users.

Yes, @dicko mentions it often in this context. along with the old pile of poo tha tis the current iptables native to SNG7

Couple of ways to look at iptables, ipsets and blacklists.

apiban currently has 1097 hosts, voiplbl has 212849 , neither make good fodder for iptables (too many rules) but ipsets could swallow either one or both.

covers their implemention for ipsets , the apiban clients also easily modded to write to an ipset instead of direct iptable rules. For the go client you might need

But the truth is that voipbl only worries about udp/5060 and apiban also mostly gets similar reports. So if you aren’t listening on udp/5060 then neither are particularly effective or even necessary. If however you are so listening on udp/5060 a ‘wise virgin ’ might ask you ’ why do you want your head cut off so soon ?’

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