SentryPeer module - testers wanted

[ghenry (Gavin Henry)]

@lgaetz

Gavin joined us on an Open Source Lounge back in April and provided a pretty good intro to the project. As I understood things then, SentryPeer’s goal is to alert the pbx admin AFTER an extension compromise has happened but BEFORE serious traffic pumping attempts begin. It does this by hosting exploitable honeypots which identify and catalog the outbound calling patterns of known traffic pumping compromises. With the knowledge that pumping exploits often initially make outbound calls to non-suspicious destinations before later making the serious toll calls. SentryPeer attempts to identify and notify the admin during the initial trial balloon phase of the exploit, potentially giving the admin time to investigate before the traffic pumping begins in earnest.

Exactly what @lgaetz said. I’ll put together some sequence diagrams using Mermaid and commit to our repo. Visualising this may help.

[ghenry (Gavin Henry)]

@BlazeStudios

So again, it can tell a domestic long distance call is traffic pumping without knowing the cost of the destination? Are there honeypots in the US?

Again, I had a customer that got compromised and was doing traffic pumping to both low cost and high cost US destinations. How would have SentryPeer stopped that? Oh and they didn’t do a crap ton of calls at once. They had calls under 20 minutes and never more than 3-5 at a time which was well within the allow channels for the account.

The SentryPeer module would take the destination a device is calling and send it to the API on sentrypeer.com and say, “Have you seen this before?”. The API would say yes (200 OK) or no (404 Not Found). What the API is checking doesn’t matter. It’s just looking for a match in the database. It’s us humans that are applying meaning and context to that data. I also did a ClueCon Weekly on SentryPeer if you have time.

We have a few in the US. I’m adding more. Don’t forget, you can always run one yourself and build up data in your own city/state that is relevant to you. The node can either just save it locally and you query the local API, or you can select the contributor plan and use our main API after enabling the WebHook with OAuth2.

As a contributor, you’ll only have access to the data you submit (so you don’t poison things), but you’ll get all the fancy alerting and be able to watch data come in (or switch on debug/verbose mode on your own node).

I’d be very happy to help you do this and write it all up for others too.

[ghenry (Gavin Henry)]

@BlazeStudios @lgaetz Hopefully these diagrams will help:

GitHub - SentryPeer/SentryPeer: Protect your SIP Servers from bad actors at... - Integrating with your own systems

Here’s the image if you don’t want to click through:

Let me know.

Thanks.

[BlazeStudios (Tom Ray)]

Unfortunately, I’m not sure this would work for me. As I stated previously, it is illegal for me to block domestic calls just because of possible cost or it could be a bad actor destination. So blocking a single call to a number SentryPeer thinks is bad is still a no-no for me. I can react to their activity if it starts to look suspicious, such as multiple CPS or other activity such as that but doing a dip on the number and then blocking it…can’t. The customer can decide what is blocked and what’s not but I can’t do it for them, not for domestic calls.

I mean, for individual PBX systems this might be a good solution but at the higher level of switching not sure how much value add this is (for me at least).

[ghenry (Gavin Henry)]

Ah, I must have missed the illegal bit. What is that covered under in the US? In that case, you can still process the alerts SentryPeerHQ would generate on a match and I could expand the FreePBX module to offer options for what to do on the PBX side for a match. That’s on my roadmap anyway and the point of this whole thread

Would ^^^ work?

Like being able to pick a destination/app to jump to in the dialplan. It’s all about early warning. The FreePBX module sends the originally dialled number, not the cleaned up one that gets sent to the carrier via the trunk/outbound route rules.

Thanks.

[BlazeStudios (Tom Ray)]

@ghenry

What is that covered under in the US?

Telecom regulations.

@ghenry

I could expand the FreePBX module to offer options for what to do on the PBX side for a match.

You could do that, it would be nice to give more control to the PBX admin. However, in my case, I am not running FreePBX to facilitate providing voice services to my customer base.

There is a difference between being a PBX admin and a voice provider/carrier. Completely different sets of rules such as a PBX admin is free to block any calls they want from leaving their private system before going to the PSTN. As their provider to the PSTN, I have to allow domestic calls in the US to go through since the service includes “long distance”. I am free to respond to abuse of my network such as suspicious call patterns but blocking individual calls isn’t acceptable based on “it could be fraud”.

As I said, for individual PBXes this should be fine for helping them detect attempts but for what I do, I would find something that allows me to check against known bad actor IP spaces (like APIBAN) over a potential high cost destination.

[ghenry (Gavin Henry)]

@BlazeStudios

@ghenry

What is that covered under in the US?

Telecom regulations.

@ghenry

I could expand the FreePBX module to offer options for what to do on the PBX side for a match.

You could do that, it would be nice to give more control to the PBX admin. However, in my case, I am not running FreePBX to facilitate providing voice services to my customer base.

OK. I think I’ll need to read up on this more. Is this just for your state or US wide? Do you run FreePBX at all then?

There is a difference between being a PBX admin and a voice provider/carrier. Completely different sets of rules such as a PBX admin is free to block any calls they want from leaving their private system before going to the PSTN. As their provider to the PSTN, I have to allow domestic calls in the US to go through since the service includes “long distance”. I am free to respond to abuse of my network such as suspicious call patterns but blocking individual calls isn’t acceptable based on “it could be fraud”.

Hmmm, very interesting. We don’t have these rules in the UK. As an ITSP, I can drop any call except to emergency services. Again, where can I read up on this?

As I said, for individual PBXes this should be fine for helping them detect attempts but for what I do, I would find something that allows me to check against known bad actor IP spaces (like APIBAN) over a potential high cost destination.

We also save the IP addresses of attackers just like APIBAN. They only focus on those. We were just talking yesterday about some type of collab on a public leaderboard.

Gavin.

[BlazeStudios (Tom Ray)]

@ghenry

OK. I think I’ll need to read up on this more. Is this just for your state or US wide? Do you run FreePBX at all then?

US wide, FCC regulations. You can find them on the FCC website, there’s quite a few. I run FreePBX at the customer site but very rarely, the majority of my customer base is UCaaS style services. Using FreePBX as the core of your voice provider services isn’t the right option.