[VoiceOps] SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Gavin Henry]

> 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.