I’m putting up a new API at SentryPeer com that allows users to check a numbed before it gets dialled to alert if it’s a toll fraud reconnaissance attempt. Details are collected by running your own SentryPeer org nodes that publish data to the same API.
The elixir / phoenix app will be AGPL once ready. APIs are all done and up though.
Is this for inbound calls? If so, it might be better to add a CID Superfecta module for SentryPeer to do the API call there. Depending on the complexity of the API call, it may be possible to use one of the generic Regular Expression superfecta modules.
Thanks for that. This is for outbound calls. The idea, which I’m proving at the moment, is during the in-between stage of a handset/endpoint having a valid registration but it’s attempting to make test calls to see what the fraudster can do. We’ve all been there. An endpoint gets compromised somehow and you only know if your channel limits are reached or it starts calling Easter Island etc. We can catch them before that though and trigger alarms/alerts.
This is the gist from the SentryPeer project introduction (when running the standalone SentryPeer node with API enabled, not using the central sentrypeer com API):
SentryPeer® is a fraud detection tool. It lets bad actors try to make phone calls and saves the IP address they came from and number they tried to call. Those details can then be used to raise notifications at the service providers network/pbx and the next time a user/customer tries to call a collected number, you can act anyway you see fit.
Let’s say you are running your own VoIP PBX on site. What SentryPeer will allow you to do in this context, is dip into the list of phone numbers (using the RESTful API) when your users are making outbound calls. If you get a hit, you’ll get a heads-up that potentially a device within your network is trying to call known probing phone numbers that have either been:
Numbers collected by SentryPeer nodes you are running yourself
Numbers seen by other SentryPeer nodes which have been replicated to your node via the peer to peer network
This would allow you to generate a notification from your monitoring systems before you rack up any expensive calls or something worse happens.
What would lead to this scenario?
Potential voicemail fraud. This can happen if you allow calling an inbound number (your DID/DDI) to get to your voicemail system, then prompt for a PIN. This PIN is weak and the voicemail system allows you to press ‘*’ to call back the Caller ID that left a voicemail. The attacker has left a voicemail, and they then guess your PIN and call it back. The number called is a known number that SentryPeer has seen. You can alert on it.
A device has been hijacked and/or a softphone or similar is using the credentials they stole off the phone’s GUI and is registered to your system and make calls to a number seen by SentryPeer.
An innocent user is calling a phishing number or known expensive number etc. that SentryPeer has seen before.
The code behind sentrypeer.com will be open-source too, released under the AGPLv3, published Q1.
We’ll be hosting it and you can run the SentryPeer node from sentrypeer.org to submit data to sentrypeer.com that they can then consume via its APIs for free. Hence this is free as in beer and free software.
Those that don’t want to do that can pay to access the data we’ve collected ourselves and other things. But the core platform is open-source to help with the trust part of the service. You can run the core platform that powers sentrypeer.com yourself with a bit of work.
sentrypeer.com SaaS/open-source backend is powered by Elixir/Phoenix Webframework/Phoenix LiveView and PostgreSQL.
It’s all open-source, but those that can’t be bothered to run things themselves can pay. Just like: