Blocking SIP traffic manually is a reactive procedure, in the absence of smart tools, being pro-active is nearly impossible, it is common if you’re only reacting to a SIP attack then the damage of different types is already done.
The Challenge of blocking SIP traffic
It is no secret that attackers are pretty smart programmers, commonly attackers use sophisticated tools that scan virtually any network and perform the SIP attacks automatically.
in this context, the same attacker IP address is usually seen by several servers and networks, once these tools identify a vulnerability it’ll start attacking you immediately.
When manually blocking unwanted SIP traffic, our internal data shows that we are more likely to perform SIP blocking after an alert is triggered, for example, alarms start triggering on your resources for Disk space, CPU, Memory utilization while the legit traffic has not increased.
Another operational challenge is when a SIP provider has many nodes that they manually manage, blocking an IP address one node means you have to re-deploy the same rules across the board. Management by hand is a time-consuming process whereas software-defined Automation is fast
Case Study
Recently while working with a vendor and had the sngrep tool open, we noticed many hits coming from unknown IPs, all the attempts were rejected by TCXC‘s `Authentication, Authorizations ` module, however, those attempts still consumed Disk space, CPU, and memory as they kept coming.
We went ahead and blocked the unwanted IP address manually in IP tables and repeated the same across our servers, that’s when we thought it would be a good opportunity to verify and test if this attacker’s IP was already detected by APIBan’s SIP honeypots, an open-source project that we recently heard about at Tadhack 2021.
Continue reading…