On Mon, 3 Jan 2022, 03:22 Jim O'Brien, <jimdoesvoip at gmail.com> wrote:

Hi Gavin, Thanks for sharing. In many ways your project reminds me of Fred Posner?s APIBAN. I like your approach here with SentryPeer allowing an operator to run their own systems and choose to share with and receive IPs from others! These piecs are fantastic! Once the crush of coming back from holidays is over I cannot wait to give this a try.

Best,

Jim

Thanks Jim. APIBAN, for now, doesn't publish B numbers. I just added responsive mode (replying to probes so they then try proper INVITEs), but haven't committed it yet and the numbers API so you can check customer calling attempts. I'm also adding a SIP agent mode too for SIP redirects. The plan is you just run in agent mode with replication on (replication coming soon) as a mini SIP proxy etc. https://www.linkedin.com/posts/surevoip_sip-sip-fraudprevention-activity-688... I've also done an RPM and Dockerfile / Dockerhub container and my first ever proper debian package! That was a long time dream of mine as I thought debs were so hard compared to an RPM spec. https://github.com/SentryPeer/SentryPeer/releases/tag/v0.0.4 Just got Debian salsa git repo access this morning too so I can start to get it into Debian proper, hopefully. Gavin.

*nods* being UDP, it could be easy to spoof someone else to get them blocked. When I automated honeypot -> ACL, I shut myself out of Google's authoritative DNS servers, assuming because of spoofing. There could have been more than I didn't even realize. Gotta protect against that kind of stuff. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Fred Posner" <fred at palner.com> To: voiceops at voiceops.org Sent: Monday, January 3, 2022 9:14:13 AM Subject: Re: [VoiceOps] SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot Hi All, 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. 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. 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. 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. I like the idea of community submission, but the poisoning was determined to be too big of a risk for us. 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. With best regards, Fred Posner | palner.com Matrix: @fred:matrix.lod.com o: +1 (212) 937-7844 On 1/3/22 4:34 AM, Gavin Henry wrote:

On Mon, 3 Jan 2022, 03:22 Jim O'Brien, <jimdoesvoip at gmail.com <mailto:jimdoesvoip at gmail.com>> wrote:

Hi Gavin, Thanks for sharing. In many ways your project reminds me of Fred Posner?s APIBAN. I like your approach here with SentryPeer allowing an operator to run their own systems and choose to share with and receive IPs from others! These piecs are fantastic! Once the crush of coming back from holidays is over I cannot wait to give this a try.

Best,

Jim

Thanks Jim. APIBAN, for now, doesn't publish B numbers. I just added responsive mode (replying to probes so they then try proper INVITEs), but haven't committed it yet and the numbers API so you can check customer calling attempts.

I'm also adding a SIP agent mode too for SIP redirects. The plan is you just run in agent mode with replication on (replication coming soon) as a mini SIP proxy etc.

https://www.linkedin.com/posts/surevoip_sip-sip-fraudprevention-activity-688... <https://www.linkedin.com/posts/surevoip_sip-sip-fraudprevention-activity-688...>

I've also done an RPM and Dockerfile / Dockerhub container and my first ever proper debian package! That was a long time dream of mine as I thought debs were so hard compared to an RPM spec.

https://github.com/SentryPeer/SentryPeer/releases/tag/v0.0.4 <https://github.com/SentryPeer/SentryPeer/releases/tag/v0.0.4>

Just got Debian salsa git repo access this morning too so I can start to get it into Debian proper, hopefully.

Gavin.

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

It was just meant as a blanket statement. When automating blacklists, make sure you understand what is blocked and what is not. If you whitelist everything known good, then that's one way to skin the cat. I'm sure there are others. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Gavin Henry" <ghenry at suretec.co.uk> To: "Mike Hammett" <voiceops at ics-il.net> Cc: "Fred Posner" <fred at palner.com>, "VoiceOps" <voiceops at voiceops.org> Sent: Monday, January 3, 2022 11:12:36 AM Subject: Re: [VoiceOps] SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot On Mon, 3 Jan 2022 at 15:44, Mike Hammett <voiceops at ics-il.net> wrote:

*nods* being UDP, it could be easy to spoof someone else to get them blocked. When I automated honeypot -> ACL, I shut myself out of Google's authoritative DNS servers, assuming because of spoofing. There could have been more than I didn't even realize.

What's the gain of spoofing/poisoning if you are going to do "allow lists" for all your important IPs and only block on your important ports (SIP etc) with Fail2ban? I suppose, "just because I can".

Gotta protect against that kind of stuff.

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.