Inbound STIR/SHAKEN Challenge

We are getting more spoofed CID calls recently, with the icing on the cake being a spam caller reaching us using a phone number CID that belongs to our company. I was thinking of leveraging whats been going on with attestation lately to make a spam challenge for calls coming into our FreePBX.

I think I want to create a dynamic route (if possible, I can do it in dialplan too) that if the inbound call has a attestation of C I want the call to be prompted to press a random digit before going forward in the PBX. I’ve not seen where the letter grade is being assigned to the call, I believe the SIP Headers, but I am not sure which one, and what command I can use to expose the specific header (or less ideally all of them).

Can anyone provide any insight here? Is anyone doing something similar to achieve the same results (looking at the attestation of an inbound call)? Thanks all!

It depends on the provider you use. Some will not even pass the attestation level at all.

Feel free to share a raw INVITE and we’ll try to help out…

1 Like

Thanks!

I am using Ringsquared for the provider, and they say they are sending it. I will turn on sip debug and capture the logs to share.

I did see this STIR/SHAKEN in Asterisk ⋆ Asterisk but if I turn this on, will if mess up my outbound calls on this trunk. I am looking just to review the inbound attestation with as little impact to the overall system as possible.

Currently I would not recommend it, we still have further development to do to update it to recent standards so it works properly. Certificate verification will likely fail as a result.

1 Like

Raw INVITE:

2022/12/06 03:34:11.009430 xxx.xxx.xxx.xxx:5060 -> xxx.xxx.xxx.xxx:5060
INVITE sip:##########@xxx.xxx.xxx.xxx:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK+2ca7f50743eb11b1f49019cd21e11bb31+sip+1+e7720cf8
From: <sip:##########@xxx.xxx.xxx.xxx:5060>;tag=xxx.xxx.xxx.xxx:+1+cec21057+985c9bf;isup-oli=00
To: <sip:##########@xxx.xxx.xxx.xxx>
CSeq: 1072470877 INVITE
Expires: 180
Content-Length: 187
Call-Info: <sip:xxx.xxx.xxx.xxx:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Supported: resource-priority,siprec, 100rel
Contact: <sip:[email protected]>;isup-oli=00
Content-Type: application/sdp
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event, calling-name, ua-profile
Call-ID: 0[email protected]xxx.xxx.xxx.xxx
Organization: MetaSwitch
Max-Forwards: 69
P-Asserted-Identity: <sip:##########@xxx.xxx.xxx.xxx:5060>
Accept: application/sdp, application/dtmf-relay

v=0
o=- 56111412261740 56111412261740 IN IP4 xxx.xxx.xxx.xxx
s=-
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio 47226 RTP/AVP 0 101
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=ptime:20

It doesn’t look like it has any Stir Shaken info.

Are you sure it’s an incoming call from your provider directly to FreePBX?

This looks weird to me.

It’s a Call-Info header while I can’t see where “method” is a valid standard parameter it could be something custom being done by the carrier via Metaswitch. It probably looks weird because of that and you generally don’t see providers sending a Call-Info header with a call.

True, in addition, the NOTIFY in the INVITE is quite confusing…

I’ll check with the vendor, but there’s nothing in there to suggest they are sending attestation to us, right? Where would it normally show on the INVITE message?

An INVITE from AnveoDirect (carrier is Bandwidth):

INVITE sip:[email protected]:XXXXX SIP/2.0
Via: SIP/2.0/UDP 169.48.232.158:5060;branch=z9hG4bK78dde4f90e2a588700d137f32f783623;rport
Max-Forwards: 70
From: <sip:[email protected]>;tag=c180c699fb12c6b19e92008935a36901
To: <sip:[email protected]>
Call-ID: [email protected]_1-b2b_1
CSeq: 200 INVITE
Contact: Anonymous <sip:[email protected]:5060>
Expires: 300
User-Agent: ACC
cisco-GUID: 226425235-2841493383-1057501354-25226658
h323-conf-id: 226425235-2841493383-1057501354-25226658
P-Asserted-Identity: <sip:+1415305XXXX;[email protected]:5060>
P-attestation-indicator: A
P-origination-id: 2FB71233-D177-4DAA-9B34-E343EA35473F
X-anveo-e164: 1775420XXXX
Content-Type: application/sdp
Content-Length: 281
1 Like

That looks pretty clear :slight_smile:

I will follow-up with the vendor to see how it can be passed. @Stewart1 once it is passed, how to I access the headers in the dialplan? P-attestation-indicator, for example.

PJSIP_HEADER(read,P-attestation-indicator)
or
SIP_HEADER(P-attestation-indicator)
according to channel type.

https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Function_PJSIP_HEADER

2 Likes

Blocking based on attestion score alone will not have the desired results you think it will. It isnt meant for blocking spam.

A good example of my previous statement would be Peerless (and its other entities) are known for housing spammers. Those spammers use Peerless DIDs on the Peerless network, that gets them an A attestion. While meemaw is still on a carrier using SS7 with her 50 yo old POTS line will get either nothing or a C. Which means at the end of the day blocking C and allowing A scores means you blocked meemaw but let the spammer through.

Very green in this area, can you elaborate on what this means?

They are a large carrier that is under the net of a parent company that owns 3-5 carriers. All of which have been known to house shady actors. A lot of robo calling can be traced back to their DIDs.

1 Like

I considered that same thing and was scolded for considering it. The person told me that was not the intent of STIR/SHAKEN and that it was not my place to pursue the idea. I still believe that it has the potential to be a useful tool in an anti-spam toolbox.

For testing and data collection purposes, I added a feature to my system that sends me an email message with the attestation information for every inbound call. FlowRoute is my provider.

What I can say is that STIR/SHAKEN is not widely enough deployed to rely on attestation for anything other then curiosity-level information. In the future that should change, but for now I would not try to use it even to prompt for a CAPTCHA.

I would be more then happy to share my notification code if anybody is interested but I have only tested it on my system.

I have been running a CAPTCHA type spam-block on my system since 2012 and it is amazingly effective. My only problem now is that CAPTCHA fails are sent to “Lenny” and the volume of my Lenny recordings that are dead air or pre-recorded messages is getting too high.

However, just a few days ago I started testing a “greylist” feature and intend to develop a module that will let users implement it on their systems. I believe that, for my needs, such a feature will be very useful.

2 Likes

Would be interested in seeing what you have implemented. We are trying to come up with an adapted system that is on all the time, with the ability to turn it on for all calls if there is a large attack.

I have this idea, though I have not pursued it or fully fleshed it out.

  • Check if “greylist everything” switch is turned on, if yes send call to challenge
  • Check if caller id is on greylist or private/blocked, if yes send call to challenge
  • Check if caller id has called x times in y seconds, if yes send call to challenge
  • Check if DID has been called x times y seconds, if yes send call to challenge
  • Otherwise let call pass normally

Would be interested in seeing what you have come up with

The CAPTCHA system that I currently run is deceptively simple.

I used a module called “Dynamic Routes” that allows you to route calls using results from a database. For my personal home line, if your CID is not on the whitelist, then you are sent to a IVR that simply asks you to press 7, at which point my phone rings. If you do not press anything, you are routed to Lenny. Bots, scammers and others that use predictive dialers never hear the request to press 7 so they are sent to Lenny.
My main business line is similar, but with a more appropriate outgoing message.

My intent for a greylisting system is as follows:

  • “Whitelist” and “pinklist” calls ring through directly
  • “Blacklist” calls (This feature is one I won’t implement) are dropped
  • “Greylist” calls are added to “Pinklist” and ring through
  • Unknown callers hear “Call could not be completed. Please hang up and try again” and are added to greylist. A human will just try again, whereas a bot will either skip it or even actually delete the number from it’s list.

Both the greylist and the pinklist will expire CID’s after a specified period of time.

I am currently testing this on a couple of my lines. Too early to know how effective it is.
My opinion is that this system will be very effective at blocking scammers. Less so at blocking salespeople, so for that you would probably send “pinklist” callers to the challenge.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.