As far as I can tell the blacklist module has received virtually no love or attention practically since its inception. It could be a much better tool in the fight against spam callers if it were brought up to date.
The two main improvements I would suggest are blocking based on Caller ID name, and partial number matching. Caller ID name is easy to explain - rather than looking at the Caller ID number you look at the received Caller ID name and if it matches a particular string it gets blocked.
Partial number matching would let you say that if a caller ID number begins with the specified digits it would be blocked. Now you may wonder how useful this would be, but consider this.
If you go to https://www.telcodata.us/new-exchanges-report and pick a recent month to display, it will show you all the new thousands blocks of telephone numbers assigned in that month. While it is understandable that big providers like Verizon or Comcast might continually need new number block assignments as they add customers, itâs a bit more puzzling why some companies you have probably never heard of would need so many new numbers, until you realize exactly how those numbers are often used.
As least two of the less well known company names on those lists are companies that I recognize as being the originators of better than 90% of the spam calls that come into my PBX. Iâm not going to name them because they might take offense to being called out as spam enablers, and they probably have lawyers. But a few months back, I simply started blocking all calls that come from their exchanges in my home state and surrounding states, plus a couple other states that tend to be big originators of spam calls, and that has dramatically cut the number of spam calls that make it through the system. Unfortunately, it seems that many phone spammers and con artists donât like to hold onto the same numbers too long, because people start to recognize and block those numbers. And these spam-enabling telcos just keep giving them new numbers to annoy us from.
If there were a requirement that phone companies had to prove that they were actually adding new customers, and not just allowing existing customers to keep switching numbers to avoid detection and blocking prior to being assigned any more new thousands blocks, it would be much easier to curb the flow of spam calls. But in the meantime the best way I have found to block spam calls it to block all calls from thousands blocks assigned to those two companies. This means blocking based on the first seven digits of a ten digit number. Right now Iâm having to do it using a very expansive block of dialplan in extensions_override_freepbx.conf, which is obviously far from an ideal way to do it. But it also means that when new thousands blocks are added for those companies I need to go in and modify my custom dialplan, which is a real pain in the butt.
Which bring me back to my idea that if you could specify that a number in the blacklist only had to be a partial match for the first x digits of a number that is y digits long or longer - in this case x would equal 7 and y would equal 10, but it might be different in other countries - it would be easier to block calls originating from these spam-enabling telcos. If anyone else thinks this is a good idea, maybe the FreePBX developers might want to consider giving the blacklist module a bit of an upgrade.
Itâs always a good idea to improve this module indeed.
This module is open source, so anybody whants to change or improve the code can do that.
Add a range of number is doable of course.
Parsing CID as well. But I think this module should be reviews enterly because the black list is stored in asterisk db.
Is the way should be to use AGI and manage these CID number? Why not.
However, a spam today canât be a spam one year later. So, need to manage blacklist duration.
But, if Iâm a spammer, I can change my CID number when I want for each one of call.
It may have some false positive too.
But I agree with you. this module could be improved sure.
When ? I donât know
No sound about this kind of plan for this module.
It doesnât answer your question directly, but I gave up on blacklisting over a year ago and now white list. All unknown inbound CIDs get challenged for DTMF input and get whitelisted if they pass. All outbound numbers are also white listed. In 18 months, something like 1-3 calls managed to get through.
There is one huge drawback with whitelisting that I canât solve, and that is you must anticipate any desirable robocaller CIDs. Things like automated credit card fraud detection, utility outage notification, etc. I have decided the good outweighs the bad.
Designating a number as whitelisted is certainly a possibility. Instead of the âblacklistâ that we have now, you could have a list of numbers and number patterns, and for each item on the list it could be blacklisted or whitelisted. Whitelisted numbers would receive one kind of treatment, blacklisted numbers another, and any number not in the list at all a third type.
Or for that matter, just have a number/pattern list with user selectable destination options, maybe a numeric category. So on one page youâd enter a number and select the category it belongs in, say for example all blacklisted numbers would be in category 1. Then on a separate page you would select where call for category 1 go. Choices would be to terminate the call, send the call back to the normal call flow, or divert the call to (for example) a context where a specific set of digits must be entered for a call to return to the normal call flow. There are other possible destinations also, for example you could send it to something like a time condition. The difference would be that at this point in the call flow I believe you are operating on calls that have not yet had a destination selected via an inbound route, so unless you are going to terminate the call you would probably not want to select a specific destination, and even if you are going to qualify a call (by making the caller enter a code, for example) you still need to be able to return it to the inbound route logic so the correct destination can be selected. So at this point in the call flow if you used a time condition, your choices would be to terminate the call, or send it back to normal call processing, or possibly to send it back to normal processing but with a variable set that would cause it to immediately go to voicemail if voicemail is enabled for that destination.
I have no idea how difficult it would be to program something like that, though. Of course you could get around the problem of not having gone through the inbound route yet by having separate numbers/patterns lists for each of your inbound route destinations, which could even allow individual users to build their own numbers lists via the UCP, but that would be horrible for the system administrator to maintain, especially when the majority of blocked numbers will still need to be handled globally - you donât want a known scam number connecting to anyone on the system, but you would not want to have to add it to each and every individual numbers/patterns list in this scenario.
The idea of having an optional automatic expiration date is probably a good one also, but there may be some numbers where you might not want that number to expire for a very long time. Maybe let users set a default expiration period in number of days or years, but with the option to make that longer or shorter for particular numbers or patterns. To my way of thinking, five years would probably be about right for the default expiration, but some may want to set it to ten years or longer. But that is another piece of data youâd need to save for each number.
Not sure why anyone would not want to use the Asterisk DB for this purpose, it seems to be extremely fast on lookups even with tens of thousands of numbers in a particular database.
Iâm using contact management because it has strong Admin GUI and UCP support already. Bulk export and backup/restore is all taken care of by FreePBX. Iâm not concerned about scalability, tho the query is so trivial, I canât imagine scaling is an issue, particularly with fast AGI. I have no interest in obsessing about this or maintaining anything. The contact list grows organically with time and usage, and I am not bothered by spammers.
One idea we had was kind of a blended approach. We had a few tables we made on a web front end. The operation controls these front end tables.
Permanent pass list
Permanent flag list
Caller Flexible flag checker
Control to dynamically adjust the flag criteria (x matches in y seconds)
Entry for area code + prefix and another for 10-digit number
DID Flexible flag checker
Control to dynamically adjust the flag criteria (x matches in y seconds)
Custom Dial Plan
Number on pass list? If yes, send the call though unchallenged. otherwise
Number on flag list? If yes, send to IVR challenge. otherwise
Query the CDR on the fly for the last y seconds, counting the number of times the area code + prefix appear. Is the count higher than the defined x? If yes, send to IVR challenge. otherwise
Query the CDR on the fly for the last y seconds, counting the number of times the 10 digit phone number appears. Is the count higher than the defined x? If yes, send to IVR challenge. otherwise
Query the CDR on the fly for the last y seconds, counting the number of times the DID has been dialed. Is the count higher than the defined x? If yes, send to IVR challenge. otherwise
send the call though unchallenged.
The challenge IVR asks the caller to press a random two phone keys.
The give is, is that at the beginning of the attack some calls will slip in, BUT in exchange, you donât have to prompt customers unnecessarily all the time. As the attack ramps up, specific ranges of numbers and DIDs get the IVR prompt, while the majority are unaffected. As the attack dies down, the numbers fall off and you donât have to worry about permanently flagging a number that might be legitimate later.
If the caller is on the 'whitelist" continue as normal, otherwise answer the phone and start recording it but donât say anything for a few seconds while âwaiting for speechâ, a couple of possible scenarios. . .
A real person will say something like âhello?â or âanyone thereâ and then wait for you to answer, if you get silence after a short pattern of speech, then goto â2FAâ
Robocallers and reverse 911 type calls start speaking and donât stop so wait until they are done and send the recording to google STT for translation, these calls generally hangup, if they donât then go to â2FAâ . But either way, if the " STT" response is longer than n words , email/sms/push-notify the resulting STT to whatever, while possibly positively âweightingâ the STT with words like âemergencyâ âalertâ or âfraudâ and similarly negatively âweightingâ words like âcontributeâ âpolicalâ âloanâ âdrugâ âloanâ
My â2FAâ context, ask the caller a random question with an easily testable answer. like âwhat color is the sky?â or âwhat day of the week is it?â or âthe last four digits of the phone number you are calling fromâ perhaps qualified by a preample of âYYou are a new caller, as such, just one time answer this question, if you answer correctly, you will never hear this again . . .â .
Send the response to STT and regex the response against âacceptable answersâ. A âpassâ adds them to my astdb whitelist âfamilyâ with date, cidnumber and cidname for completeness.
The idea is that it is easy for a human to âpassâ but not possible with any DTMF response (I notice some robocallers are possibly STTâing YOUR recording like âplease press 5â and doing just that)
Before anybody asks, google will roundtrip a STT/TTS of a short challenge/response in < a couple of seconds, quite acceptable to me.