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.
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.
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
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 domain.name” 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.
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.
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 ?’
)