Rebuilding with stronger auth and encryption is a good idea, but you gotta find the root cause.
If your PBX or SIP ports are somehow exposed, you are facing the same problem, the only difference is that you are challenging the attacker with more advanced auth. Which is wrong.
Don’t expose your server again before you know what happened.
I’m not sure what firewall you use, but I’d go true every inbound and routing rule or run a port scan as mentioned earlier.
We use pfSense as our firewall. If I had to guess they got in via 5060 since that’s a very-well known port for SIP traffic and I used the defaults (bad I know now) to set this up.
You can keep using 5060 if you lock it down.
Some providers won’t give you a Trunk for something other than 5060
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
And sure enough there’s that damn scan again, happened as you said it would. Guess it’s time for that port scan.
EDIT: Did an nmap on the pfSense and the SIP ports aren’t open, so now I’m lost as to why the scan keeps happening.
@Offer
@jersonjunior hit the nail on the head exactly the code change.
The ‘small c’ will allow the dialplan to continue on when the agent hangs up (vs triggering a hangup of both agent and caller).
Then it will automatically call the script and the caller into your queue will hear it and be able to respond.
We are copying the QUEUE code into the override file. Here is the caveat to this that you will need to remember for this particular code change.
ANY Changes that you need to make to the queues via the GUI will have NO effect on the queue’s behavior. Since we are using the override file. What this means is if you need to make changes to the queue, you will need to perform the steps below for those changes to take effect in your production PBX as well as allow the automatic message to play. Without doing it, you will make changes, but asterisk will continue with the code that is in the override file, ignoring the changes.
Its the price of free.
INSTRUCTIONS
Open up extensions_addition.conf
Go [ext-queues] and copy everything from [ext-queues] all the way to ;–== end of [ext-queues] ==–;
[ext-queues]
include => ext-queues-custom
exten => 8860,1,Macro(user-callerid,)
exten => 8860,n,Answer
.............
bla bla bla
bla bla bla
..............
exten => 8860,n,Set(VQ_DEST=)
exten => 8860,n,Dial(Local/554@from-internal/n,)
exten => 8860,n(gotodest),GotoIf($["${QDEST}"=""]?app-
blackhole,hangup,1:${CUT(QDEST,^,1)},${CUT(QDEST,^,2)},${CUT(QDEST,^,3)})
exten => 8860*,1,Macro(agent-add,8860,)
exten => 8860**,1,Macro(agent-del,8860)
exten => h,1,Macro(hangupcall,)
;--== end of [ext-queues] ==--;
Copy this into “extensions_override_freepbx.conf”
Now you will need to modify two lines in the override file.
1> For the section that reflects your queue (in my example my queue is 8860) that will look basically like this (just remember yours will reflect the number that you have assigned to your queue)
exten => 8860,n(qcall),Queue(8860,${QOPTIONS},,${QAANNOUNCE},${QMAXWAIT},${QAGI},,${QGOSUB},${QRULE},${QPOSITION})
The change you will make is
exten => 8860,n(qcall),Queue(8860,${QOPTIONS}c,,${QAANNOUNCE},${QMAXWAIT},${QAGI},,${QGOSUB},${QRULE},${QPOSITION})
specfically you will add a “c” (lower case) right after QOPTIONS and before the first “,” comma mark
${QOPTIONS}c,${QAANNOUNCE}
Now, scroll down about 5 or so lines and you’ll see this:
exten => 8860,n,Set(VQ_DEST=)
exten => 8860,n(gotodest),GotoIf($["${QDEST}"=""]?app blackhole,hangup,1:${CUT(QDEST,^,1)},${CUT(QDEST,^,2)},${CUT(QDEST,^,3)})
Now between these lines insert the following line, except modify the XXXX value to be the number you dial to test your script with.
exten => 8860,n,Set(VQ_DEST=)
exten => 8860,n,Dial(Local/XXXX@from-internal/n,)
exten => 8860,n(gotodest),GotoIf($["${QDEST}"=""]?app blackhole,hangup,1:${CUT(QDEST,^,1)},${CUT(QDEST,^,2)},${CUT(QDEST,^,3)})
Now save your changes
from command line type in asterisk -rx 'core reload’
TEST!
To backout this code if there is a problem that is affecting a production system, it the extensions_override_freepbx.conf file, change the heading [ext-queues] to [ext-queues-bypass]
save that change
then in the cli type in
asterisk -rx 'core reload’
This will revert the pbx back to the original code.
You can then identify the changes, remove the -bypass
save/reload the script and test.
Those SIP endpoints register to Free-PBX. and Free-PBX will do outbound routes to gateway by extension.
If extension is 6XXX–> Trunk name: 6XXX -->Trunk: 6XXX in gateway --> port 1 (E1) --> PSTN1
If extension is 7XXX --> trunk name: 7XXX -->Trunk: 7XXX in gateway --> port 2 (E1) --> PSTN2
It seems digium gateway cannot identify the calls is called from which trunk, I monitored in freepbx log and saw that freePBX sent to gateway as 6XXX@freepbxIP or 7XXX@freepbxIP.
Please help.
Thanks
I don’t see that model on Digium’s website
What do you mean by scanner? Are you getting some kind of error o warning message?
No, it says “warning, friendly scanner from” and it’s an IP to VoicePulse’s public network for its SIP services. Now I’m trying to figure out why it keeps telling me the number I’m dialing isn’t in service even though I can dial out just fine…
You can (on most router/firewalls , pfsense included) write a rule(s) to remap as many ip/port rules from your wan to your lan, so if you choose to listen publicly to 38324 (for example) for sip connections from your asterisk (or any other sip server), and thusly provision your external extensions to use that port (don’t forget that you are the boss), you can remap your boring_wont_let_me_not_use_5060 vsp providers connections from them through your router using that remapping, the knuckle-draggers won’t get in unless the hammer you for 64000 connections, but then your port flood detection would kick in 
, but your stupid trunks and your well behaved external extensions will. Pretty well an teenager can use sipvicious or any of it’s variants to spoof sip connections to your external ip , generally on 5060, but the variants scan more often 5000-5999, don’t use them!! have a solid IDS but most of all realize that these guys are cleverer than you.
this is the model https://www.digium.com/products/voip-gateways/g400
Thanks
Appreciate the suggestion, but I need inbound calls to work again before I mess with any other firewall settings. This whole “number not in service” bit is on my last nerves. I’d like to go home sometime soon lol
That message is not a “bad” warning per-se. Is your inbound a catch-all? If your inbound doesn’t specify a DID, you will get that message, but that doesn’t mean your pbx is being targeted by an attacker.
That is not a PSTN gateway. That is a T1/E1 gateway.
Inbound, I don’t think, is a catch-all. Inbound specifies a DID. The last time I saw “warning, friendly scanner from” and Google’d it, nothing but SIPVicious came up, and the first time the person tried to make calls from multiple sources (one ending up in China). The second time (the reason why I’m here right now) they were making hour-long outbound calls through our system. And now every time an inbound call comes through, the scanner goes off.
@arielgrin, when did T1/E1’s stop being able to connect to the PublicServiceTelephoneNetwork?
Having 5060 open in anyway to the Innertubes, expose you to attack, UDP connections are intrinsically prone to being spoofed, just don’t accept 5060 from anyone, yet remap your trusted providers to yourchosen random port (not secure, but neither regularly attacked) .
Sorry, I meant it in the sense that is not an analog gateway. My bad for not specifying correctly.
Anyway, according to its manual, you should have an option called “Send Call Through” on menu “Call Routing rules” that should let you specify which port to use according to specified rules.
I don’t have my SIP port opened to the internet aside from my VoSP and I get the friendly scanner message on my catch-all inbound route but not on any other route that has a DID defined for it. That is why I asked.