Ghost Calls (sipvicious) Not Logged in CDR

We are getting occasional ghost calls from “sipvicious”. What surprizes me is there doesn’t appear to be a CDR entry for these events.

As best I can tell, these are port scans and I’m working to tighten up our firewall. But, I was hoping I could verify the fix by simply checking the event log for ghost call events. Otherwise, I just have to wait for someone to compain about being annoyed by random fake calls which isn’t a very reliable early warning system. :wink:

Is there a setting I need to configure in order to get the CDR report to show ghost calls? Or, is there a different place these would be logged? I’m able to ssh into the PBX VM if that’s what’s necessary.

Is your endpoint directly on the WAN? Not behind a firewall at all?

You will see “ghost calls” from many user-agents using UDP/5060 at your point of ingress, use sngrep and see if these calls are ‘whistles in the wind’ , i.e. you didn’t answer.

@dicko, thanks for the sngrep tip! I have not used that tool before. Looks awesome.

sngrep watches live traffic across the PBX server. Is there a log file on FreePBX/Asterisk that might have captured the sipvicious event so I can look back in time.

If there is none, and I need to leave sngrep running until the next sipvicious event happens… Does anyone know how I can get sngrep to jsut show ghost calls?

The function of the function keys is plain on the bottom status line, F7 allowing you to filter the current session , (F1 is a also worth pressing :wink: )

man sngrep

will reveal how to capture, replay and other useful things.

These are most likely not coming from the PBX but they are scanning your WAN for open ports and an INVITE sent to the phone will cause it to ring. You won’t find these calls in the PBX CDR because they don’t exist there.

There is another tool called pcapsipdump,

it is better for long term background monitoring as each call is saved in a seperate file located in directories identified by month/day/hour (with the from and too embedded in the filename) . If you call it with option " -m ^INVITE$" it will just keep INVITES (attemped calls) , and it will rotate the logged calls to your schedule so if you forget about it your disk wont explode. The files are regular pcap so you can read them back with sngrep or whatever.

You might better describe your layout as depending on where the phones and the PBX are in relation to the other the monitoring might need adjusting.

@dicko, thank you very much again. I used the F1 and figured out that INVITEs are what I need to filter for.

I am stumped though. Our FreePBX VPS is hosted by at and our phones are locked behind a UniFi Gateway Pro firewall that only allows established/related sessions in and drops invalid state packets.

In addition, there are no forwarded ports from the WAN to LAN and there is no DMZ.

So, everything incoming should be blocked and even if something gets through, there is no place to route it to.

The UniFi Gateway is Linux based, so if there is some firewall setting that would help figure out what’s going on I can grab it and post it.

When I nmap both public facing WAN ports on the gateway, there are no open TCP ports. And scanning from shows nothing open on 5060 UDP incoming.

What can I tighten up on my PBX server or my gateway/edge router? Any ideas?

One idea that is +99.99% effective against all these drive by’s is to use TLS (or less effective TCP) on a port outside 5000-5999 for your SIP signalling. If your VSP ONLY does UDP/5060, then write a firewall rule to rewrite that traffic to your internal UDP port and only allow the VSP’s IP(s) through. Add a lot more security by only accepting traffic sent to your domain name and reject anything sent to your IP address .

You should post a screen shot of a conversation captured by sngrep that concerns you

Also , importantly where are you running sngrep, the PBX itself or the UniFi (it’s basically Ubuntu, so ‘sudo apt install sngrep’ and its likely there also)


Where are you getting these calls? Do you see any activity in the asterisk log files?

If not, then change your phones local port to something other than standard SIP Ports.

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