Restricting Call Destinations

Status
Not open for further replies.

simcard

Member
Jan 22, 2017
49
4
8
Hi Guys,

Just wondering what people are doing along the lines of restricting or barring certain call destinations; e.g. high-risk/high-cost/toll-fraud targeted destinations.

Some trunk providers allow you to turn off destinations selectively and some bar high-risk destinations altogether. While we like those options, we're considering what extra security steps we could take, as a second and third line of defense as we may well end up using a trunk from a provider that doesn't offer that.

Currently we use toll_allow to either allow or deny international calling, but looking for something a bit more granular (i.e. specific calling codes/countries).

So far we've considered taking the Outbound Route path and catching anything that matches the prefixes of the countries we want to block. The obvious downside to this is the upkeep over the long term if we add or remove calling codes; however it shouldn't be too onerous though; in the 20 years I've spent working in telco, I don't think the high-risk destinations have changed significantly over time.

Are there any other options out there that you've considered or are using?
 

simcard

Member
Jan 22, 2017
49
4
8
Doing some further investigation I stumbled across mod_blacklist looked, which on first glance looked promising, however it appears to be designed more for inbound calls (I can't see any outbound examples) and blocking individual numbers, not prefixes.
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
I have not seen anything like this except the way you have described. I don't think however, that it would be too difficult to create a module that did this. The thing is how would you want it, ie, per extension, per domain?
 

simcard

Member
Jan 22, 2017
49
4
8
Thinking out loud here:

Taking our current solution in to account; e.g. toll_allow approach with outbound routes seems to offer the greatest flexibility at this stage; we have all high-risk prefixes blocked using a global outbound route and can override that per extension using the toll_allow directive, based on other outbound routes we've created (full international access, limited international access etc). Seems to be working well based on our testing.

We were able to solve the 'global' and 'per extension' use cases with the above, however what this doesn't offer is much flexibility at the domain level.

The biggest pain I see is managing at a per extension level; say hypothetically you have 50 extensions and 5 of those require access to dial one country, while all other prefixes are blocked (and all other extensions in the domain are still restricted for all high-risk prefixes). Even with our current solution, that proves to be a headache to manage, but is better than leaving ourselves wide open.

The complexities I see are;
- Managing the list of prefixes blocked
- Allowing the prefix list to be blocked globally, but also have domain and per extension overrides if you want to open individual prefixes up
- Items taking it probably a step too far:
--- Would be nice to get some reporting on attempted calls to a prefix that has been blocked (CDRs would probably suffice from the testing we've done thus far; trying to work out how to implement custom hangup clauses to clearly distinguish blocked calls)
--- Blocking the IP of the incoming SIP requests if a threshold is hit (i.e. 'x' call attempts in 'y' minutes) - added layer of security (mind you I could see benefit in this being a module on its own, or implement rules in fail2ban?)
--- Time of day blocking for some prefixes (i.e. most toll-fraud happens when no one's around or late at night; happy to let users call during business hours to those high-risk destination, but outside of those times block the calls)

Just some thoughts at the moment. Will keep thinking about this and add as we go (some of which may be too far over the top for a custom module!).

cheers,

Andrew
 
Dec 1, 2016
92
8
8
45
inside-out.xyz
Status
Not open for further replies.