Hi All,
Hi Fred!
Re APIBAN...
APIBAN has two main ways that it's used... with a simple block of IP addresses through firewall or iptables being the most used aspect.
Blocked completely, or just for SIP? You gather just for SIP usage?
Briefly, through honeypots (global) IP addresses sending SIP or non-SIP (like dns, fuzz, or malformed SIP) are identified. We capture the commonly used SIP listener ports with UDP, TCP, and TLS.
That's the next step for SentryPeer, as I'm interested to see where the traffic comes into re UDP/TCP and TLS. I'm also interested in the patterns of probes vs attacks and number destinations and UAS targeted. What I've seen so far is it doesn't matter and it doesn't matter whether your SIP replies to probes are SIP compliant :-)
Most users utilize the apiban client to automatically block these IPs in iptables. There is also methods to check individual ip's by API as well as grabbing all active IPs, etc.
Blocking traffic just to their important SIP ports and having allow lists already I guess.
We looked into a community submission, but decided against it as it was too easily poisoned. The main goal here is quality of the data and making sure that we're not distributing any valid IP as something that should be blocked.
You could work round this by splitting up the feeds though based on tags for where the data came from. That's how I'm going to do it so a user can config / select and also list their own IPs/customers/ASNs etc. but I'm not going to replicate destination IP address and just leave them on the node that gathered them. How does one measure/gauge the quality of data gathered by others if the other party doesn't know what's important to them to gauge it? Lot's to think about :-)
I like the idea of community submission, but the poisoning was determined to be too big of a risk for us.
These are solved problems though in other domains? Or almost, spam, grading, rules based, ML etc.
I also like the idea of sharing some data of numbers being called, etc... but like that for analysis and approaching hardening in a non-realtime scenario.
The use case I have in mind is to build that list into a feed for say CGRateS or your SIP proxies or SIP agent (which I'm doing), so even before a customer or user starts to be used for fraudulent calls, they get an early warning of attempts, no matter if they are normalised numbers or not. Lastly, thanks for jumping in Fred. I need to watch more of your presentations as I think it's great we're all doing our bit and taking different approaches even though I'm way late to the party! Gavin.