Inbound routes issues

Going to need a call trace, share via pastebin:
https://wiki.freepbx.org/display/SUP/Providing+Great+Debug#ProvidingGreatDebug-AsteriskLogs-PartII

hello @ThetaCoder,

The quickest way to reduce the calls to your extensions (not the pbx), is to setup a call confirmation dialplan before the call would continue to its destination. You can use something simple like that:

[from-world-custom]
exten => s,1,NoOp(Incoming call from: ${CALLERID(num)})
same => n,Read(check_answer,silence/1&press-1,1,,1,5)
same => n,GotoIf($[ "${check_answer}" = "1" ]?continue:hangup)

same => n(continue),NoOp(Success, The call will flow to its destination)
same => n,Return()

same => n(hangup),Hangup
  1. Add this context to your extensions_custom.conf file and reload the dialplan (rasterisk -x'dialplan reload')
  2. Create a custom destination and add the destination: from-world-custom,s,1
  3. Select the Return switch to yes and add your destination (your extension, ivr, ring group etc.).
  4. Change the destination in your inbound route of your extension to check if it is working well for you.

If it will works well for your, change the default inbound route of your company.
If the spammer will guess the code (1 in my example), you will be able to change the code quickly in the dial plan (the config edit module).

Keep in mind that this dialplan will help you to allow only authorized call to continue to the pbx, but it will not reduce the load on the incoming calls, and you will have to keep monitoring your pbx to find more patterns of the spammer.

Let me know if you will need more help.

Thank you,

Daniel Friedman
Trixton LTD.

I had thought the calls had stopped, but they picked back up again. they are now starting to change their DID and CID slightly. I will hopefully get a trace done shortly and get it in pastebin.

Below is hopefully the trace of one of the more recent calls from the bad source

https://pastebin.freepbx.org/view/02459d2e

The DID has been changing every so often, but always seems to contain 441519470554 at the end.

look at line 4 and make sure you do not have anonymous or guest sip calls allowed

We get over 90% of our business via phone. I cannot turn off anon sip or it completely shuts down ALL incoming calls. I know this because we tried disabling those, and it shut down the whole thing.

You can fix your trunk setup to only accept calls from your providers designated servers. Then you can turn off anon/guest calls

our phones are on a dedicated network that connects directly to the EGS Gateway unit. No calls come in on our normal Public WAN address we use for internet.

Not sure why that helps resolving your problem, I don’t know what an “EGS Gateway” is my guess it is in fact the source of your trunk, but quite happy to be corrected

Our SIP provider is only that, just sip trunk to the EGS unit (think of it as an edge router/gateway) . All phone calls in or our pass through our SIP provider to that device to the phone network. We have no choice in where the calls come from, they only come from our SIP provider, we really have no way that I know of to set a designated server to listen to.

You are missing the point, here we are talking Asterisk, so I assume you have provisioned a trunk to whatever, having done that and if it is as localized as you say, defining the “host=ip.addr.ess” will accept calls from that IP and you can then turn off the anon/guest calls which is what you are seeing and being annoyed by, if you don’t do that then you will have to just put up with it or as otherwise suggested , send the calls to something that identifies as acceptable the caller.

in short all I need to know is how to setup call routing so that any DID that contains the spammer gets junked but EVERTYTHING else can come through. I have NO access to anything beyond the port where the phone network connects to the EGS. So even if I say only things coming from the EGS ports ip it wont stop all the calls from coming in as ALL CALLS come in via that port.

Setting up a ‘press 1 to continue’ is not an option, as we are a business, and asking every customer that calls to do that would kill the business. I am sorry for being short, but this has been going on for 2 weeks and my bosses are not accepting of ‘just deal with it’ as a response. My SIP provider has said they cannot block a DID, I would have to call the cops or the FCC, who aren’t going to do anything about it either.

So no consistency to CID/DID and no willingness to use an IVR. I would say there is no solution to this problem, unless you can do a whitelist like described here: Of Robocalls and Whitelists
That would force unrecognized callers to ‘press 1 to continue’ but after that they would be on the whitelist so it bypasses the challenge.

If you can’t/won’t constrain the anon/guest calls then as suggested have the caller validate, this can easily be a one time need, add them to your whitelist ( another story, and not a short one) and the next time they call they won’t be bothered.

I will take a look at that. Is there no way to setup a inbound routes so that the bad one gets trapped while letting the others through?

Hello @ThetaCoder,

After examining your logs, I can point out that the hacker tries to send calls directly through your trunks. The best way to reduce those tries is to set up a general inbound route that would terminate the call. You need to setup two general inbound routes with the following patterns: _X. and a blank one.

Please do not forget to setup your specific inbound routes as a range or as a specific DID. I for example, like to put them on hold, because it is letting me time to investigate the pattern of the attack and then block them for good on my system.

Here is a screenshot of my setup:


Thank you,

Daniel Friedman
Trixton LTD.

Hi Daniel:

This is not a hacker, these are inbound PSTN calls. OP wants to filter by CID.

I can’t think of a use single use for an inbound route with DID of _X. that would not be caught by the Any/Any route. What specific case does that route actually address?

Hi @lgaetz,

Yes, it is a hacker who tries to send calls through this pbx. The problem is that they do it directly through the carriers and not through an ip address. The filter that I suggested works for me many years for this type of attacks. The basic concept of this pattern is to block a DID that is not configured specifically on the inbound routes of the pbx. Look at the patterns again that is entering to the pbx. most of them are not legit DIDs, and should be terminated on the spot. This concept is good for alpha numeric attacks as well (_X. or s). This helps reducing significantly these types of attacks on PBXs.

Of course that this is just one step in fighting these hackers/spammers, because most of the attacks that I see are plain DDOS and every attack has its own pattern, but eventually, they all sum up to 10 -15 known attacking patterns.

The most annoying attack is the DDOS one with caller id spoofing, that is forcing you to start whitelist your customers, but if you are tightening your pbx from starters, most of the attacks just passing through your pbx and are getting terminated, since they are general attacks on PBXs from the internet.

Thank you,

Daniel Friedman
Trixton LTD.

I can’t believe they let that one go by so quickly.

First, there is always a Firewall - it’s built into the system. It’s called the Integrated Firewall and it is there.

Second, inbound and outbound calling are almost unrelated. The might appear to be and experienced PBX users are used to them being “the same”, but in Asterisk, they just don’t share a lot of anything.

The pedantic part of my brain won’t let this go. They all originate from the same “CID”. DID is how we describe the inbound direct dial number.

When a call is directed to your system, it is sent to one of your DIDs via a trunk. You mention that you need to use anonymous connections because of your provider, but that’s counter-intuitive. If you have a provider, you should have the servers for your provider identified in your trunk config. Anything that doesn’t come from your provider’s IP is anonymous and should be blocked. There are many long discussions on here about why anonymous is bad and how much money it can cost you.

This leads me to believe that you are setting up the trunk for a username/password pair when, in fact, you are using IP authentication. If that’s the case, then (once again) you need to allow the IP addresses of your ISP’s originating SIP connection(s) and block the rest.

Now, if you are trying to block PSTN calls, there’s a whole different set of possible choices there. Your request seems to be “magically know what calls are good and what calls are bad and block the bad ones.” That isn’t going to happen with this or any other telephone technology.

@lgaetz 's “Robocaller” scrtpy with it’s “one and done” authentication white list is excellent, especially if you throw a message on the front that says “because of nuisance and spam calls, please press ‘1’ to be added to our whitelist and your call will be directed to an agent.” Most customers will recognize that you are being responsible and will be more than happy to help you out.

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