How would I block this DID?

I had a hack attempt yesterday, the result of having Allow Anonymous SIP calls set. Reading through the forums, most of the suggestions on blocking DID numbers is based on filtering the number prefix and I couldn’t find any suggestions re blocking on some other part of the number.

On these attempts, the caller is changing the prefix and I’m assuming that is to try and avoid any prefix blocking. The rightmost digits are always the same. Is it possible to setup an Inbound Route that will match based on a pattern of the rightmost digits?

I tried using _.72597639454 as a pattern on a route that went to the Hangup action, but that seemed to block everything.

2016-04-11 05:22:08 1460308928.1731 "1 "<1> 0119011972597639454 Dial 600 NO ANSWER 00:20
2016-04-11 05:22:08 1460308928.1731 "1 "<1> 0119011972597639454 Dial 600 NO ANSWER 00:20
2016-04-11 05:17:53 1460308638.1706 "1 "<1> 909011972597639454 VoiceMail 1000 ANSWERED 00:30
2016-04-11 05:17:38 1460308638.1706 "1 "<1> 909011972597639454 Dial 1000 NO ANSWER 00:15
2016-04-11 05:17:18 1460308638.1706 "1 "<1> 909011972597639454 Dial 600 NO ANSWER 00:20
2016-04-11 05:17:18 1460308638.1706 "1 "<1> 909011972597639454 Dial 600 NO ANSWER 00:20
2016-04-11 05:13:00 1460308345.1686 "1 "<1> 9011972597639454 VoiceMail 1000 ANSWERED 00:30
2016-04-11 05:12:45 1460308345.1686 "1 "<1> 9011972597639454 Dial 1000 NO ANSWER 00:15

As I recall, “underscore period” matches everything in a context. I think you want one or the other, but I just don’t do enough dial-plans to tell you which one to use. I’d start with underscore.

How is he getting in?

There is NO good reason to allow anonymous SIP connections. Ever. Under any circumstances. No - you’re wrong - not even then. There is never, ever a good reason. We don’t even need the “open port 5060” part - it makes it worse, but it’s already bad. Never. Not now, not ever. :slight_smile:

So first, I suggest you turn that off.

Next, if he’s calling in over the network, block his IP address at your master firewall. If you are using a host-based firewall, block him in that. If that doesn’t work, change your inbound SIP port from 5060 to something else.

The point of this attempt (I’m guessing) is to find a sequence that allows him to transfer a call from your Asterisk to long distance. There’s an active thread about this right now.

Thanks for the advice.
The hack was a result of a combo of errors … I had Allow Anonymous enabled (misunderstood it’s meaning) and also the firewall I thought I had running, wasn’t.

I’ve used Shorewall for firewall management on other Linux systems so did the same on my Freepbx box, but didn’t realise that Freepbx’s own firewall manager was overwriting my Shorewall setup. I’m using a sip trunk from my provider and have the sip access locked down to their ip address only, or so I thought. I’ve removed the Freepbx firewall and all is now good.

I’ll do some more reading up on dial plan syntax and see what I can work out.

You need to to a bit of reading on how Asterisk dial patters work:
https://wiki.asterisk.org/wiki/display/AST/Pattern+Matching

From the link you will learn that a (.) character goes at the end of a dial pattern, and explains why yours doesn’t work. Also from the link you will learn that matching 10 digits where the final 7 are fixed is no more difficult than:

_XXX97639454

I saw those patterns in the first hours I had my new box up (freepbxhosting)… Between 11pm and 7am when I took a break from configuring the log had quite a few instances of them. Turns out I had also missed a firewall setting. It’s been a long time thing of scripts looking for outside routes that work. Not related to the other thread which is a different (also long time) risk.