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.
What is APIBan
In a nutshell, APIBAN helps prevent unwanted SIP traffic by identifying addresses of known bad actors before they attack your system. Bad actors are collected through globally deployed honeypots and curated by LOD/APIBAN.
The APIBan API allows you to integrate and interact with APIBAN data. The response is provided in standard JSON responses and uses HTTP Status Codes to help determine results.
We went ahead and did a check via APIBan’s API to see if the IP was already detected by the honeypots, using the below steps:
1- IP address check: https://apiban.org/api/[API-Key]/check/[IPv4-Address] .
2- We get a response from APIBan {"ipaddress":"blocked", "ID":"1636221410"}
Great! So the IP address that already consumed our time and resources have already been seen by APIban, we went ahead and repeated the same for other IPs and realized that they were also already identified by APIBan’s honeypots, this confirmed to us that the quality of APIban blocking of IPs is really good.
Automating SIP blocking
The next thought was to write a script that will automatically check banned IPs and add them to our IP-tables deny rules, however, we did not have to write any scripts since APIban has already an open-source APIBan client software written in Go Lang that you can easily install on the server.
Here is a step-by-step guide on how to install and configure the APIBan client.
Side Effects of API Ban
At TelecomsXChange we monitored if installing APIBan has any side effects on the servers, to date we have not found any evidence of the APIban client causing any issues or consuming any unusual resources.
We also checked if APIban has accidentally picked any real-customer IP addresses and blacklisted them by accident, and it did not also do that.
The data quality was very good and did not interfere with any legit IP addresses, I think this is because data is not accepted from none APIBan honeypots which may lead to poisoning the APIBan database.
The Community
The author and community members for APIBan are made of well-respected individuals from the RTC open source community.
When APIBan is installed on our servers, whenever one of the APIban honeypots detects a new attacker, 4 minutes later we have this IP blocked in our IP tables giving us peace of mind that whenever this IP tries to hit us it will be already blocked by all our servers.
APIBan not accepting bad IP submission from third parties may be seen as a negative thing, however, we support this decision and think it’s a major contributor to the high-quality data that APIBan is providing its users.
Conclusion
Monitoring and blocking unwanted SIP traffic by hand is not scalable and is prone to human errors. APIban is an open-source project led by well-respected community members that expose an API that shares bad IP addresses using SIP honey pots deployed on several servers and then shares them with the community via RESTful API so they can be automatically blocked across different nodes.
APIBan comes with an easy to install client software that can automatically fetch new banned IPs and add them to your IP Tables without any manual work.
The APIBan service does not add any third-party data, keeping its high-quality data only fed from its own SIP honey pots to ensure the highest quality possible for banned IP Addresses.
If you appreciate the work the APIBan community is doing, please join us to sponsor them on Github.