Help with rouge international calls


I’m looking for assistance with a FreePBX Distro that is running Asterisk 10.12.1

The server is sitting on a private 10.0.0.x network behind a Cisco router. There are NO inbound ports directed at this system.

The sip secret for the extension [was] this:
ab625ff6a1c5ffed442ace6147e18bf6 – so I certainly wouldn’t call that weak.

However, despite this, an external IP has been able to authenticate as one of our extensions, and make international calls. I assume it could only do this through IP or MAC spoofing? Given that we’re not allowing any inbound requests, but perhaps the outbound NAT connection created to our VSP is being hooked into?

Regardless, when you read up on advise on the Internet most of the people with the issues have servers that are in the Internet, publicly accessible - however this isn’t the case here.

Also, I have used the module admin to see if there are any updates available, for which the only updates are for the Backup/Restore module.

Finally, the last thing I have tried is to lock down the IP that the extensions can authenticate from.

What else should I be looking for? I would have thought that no inbound ports, strong secrets and an up-to-date system would have been enough?

I hope that the PERMIT/DENY that I have added to the extension will give me that last bit of security, however any further input would be most appreciated :slight_smile:

If you have no traffic from the Internet directed to your FreePBX server through your Cisco router than the attack must be coming from another vector.

Agree, you can’t spook an IP address in the manner you describe and MAC addresses are layer 2 constructs and don’t exist beyond the connected network.

Judging solely by those comments you may have misunderstanding of network fundamentals and have inadvertently exposed the device to the Internet.

What kind of Cisco router is it?

Post a redacted config file from the router.


I should have noted that the PBX box has a sip trunk. So while we haven’t created any port forwards, the outbound connection to the sip trunk would be creating an entry in the NAT table, that I dare say is somehow being hooked in to.


Nope, that’s impossible. You didn’t tell me what kind of Cisco router it is.

Thanks for taking the time to respond :slight_smile:

A Cisco RV042 using a Billion modem in bridge mode. However as discussed, uPNP is off, and there is nothing in the forwarding table.

Using an external port scan confirms that we’re not listening: isn’t responding on port 5060 (sip). isn’t responding on port 5061 (sip-tls).

However, we get plenty of this:
[2013-09-11 11:35:01] NOTICE[8268] chan_sip.c: Sending fake auth rejection for device 111sip:[email protected];tag=8597538a

… Where the IP listed is the WAN IP of our internet connection.

And here’s the original line of the dodgy system logging in:
[2013-09-09 07:13:47] VERBOSE[29941] chan_sip.c: – Registered SIP ‘401’ at

SO what I can’t work out, is that if there are no ports forwarded externally through to the FreePBX box, how have we received devices authenticating as extensions, and other devices attempting to auth too?

I did a search on “asterisk sending fake auth rejection for device” and there were many hits on this message. I do not have time to research them all so I can’t be sure you problem is related.

But without a doubt there is a Palestinian registering extension 401 on your box using SIP udp/5060, did you port scan udp?

any other strange IP’s in

grep “Registered SIP” /var/log/asterisk/full*



Yes buddy I did this too however most people have 5060 open to the web, so people trying to get in are the norm…

Only that IP, and nothing since I set the DENY= for that extension.

I did a TCP scan online, I have downloaded “SuperScan4” and did a UDP and TCP scan of 5060:

Scanning 1 machines with 1 remaining.
TCP service scan (SYN) pass 1 of 1 (1 hosts x 1 ports)…
UDP service scan pass 1 of 1 (1 hosts x 1 ports)…
Performing hostname resolution…
Performing banner grabs…
TCP banner grabbing (0 ports)
UDP banner grabbing (0 ports)
Reporting scan results…
-------- Scan done --------

Discovery scan finished: 09/11/13 13:56:58

The ports aren’t open! So effed if I know how they can get in!

Well, the only way that calls can be made is SIP or the AMI (tcp/5038), you can capture the sip dialog with sip set debug ip (ip) or with tcpdump for a deeper look.