Am I being hacked?

Turn up the verbosity and see if that helps or do pjsip set logger on to look at the SIP packets.

I increased verbosity in the logging to 10 and now have this:

[2018-12-28 14:24:57] WARNING[9759][C-000000a8] func_channel.c: Unknown or unavailable item requested: ‘recvip’
[2018-12-28 14:24:57] VERBOSE[9759][C-000000a8] pbx.c: Executing [[email protected]:6] Log(“PJSIP/anonymous-000000a8”, "WARNING,"Rejecting unknown SIP connection from “”) in new stack
[2018-12-28 14:24:57] WARNING[9759][C-000000a8] Ext. s: "Rejecting unknown SIP connection from "
[2018-12-28 14:24:57] VERBOSE[9759][C-000000a8] pbx.c: Executing [[email protected]:7] Answer(“PJSIP/anonymous-000000a8”, “”) in new stack
[2018-12-28 14:24:57] VERBOSE[2614] res_rtp_asterisk.c: 0x336d150 – Strict RTP learning after remote address set to:
[2018-12-28 14:24:58] VERBOSE[9759][C-000000a8] pbx.c: Executing [[email protected]:8] Wait(“PJSIP/anonymous-000000a8”, “2”) in new stack
[2018-12-28 14:24:58] VERBOSE[9758][C-000000a7] pbx.c: Spawn extension (from-sip-external, s, 11) exited non-zero on ‘PJSIP/anonymous-000000a7’
[2018-12-28 14:24:58] VERBOSE[9758][C-000000a7] pbx.c: Executing [[email protected]:1] Hangup(“PJSIP/anonymous-000000a7”, “”) in new stack
[2018-12-28 14:24:58] VERBOSE[9758][C-000000a7] pbx.c: Spawn extension (from-sip-external, h, 1) exited non-zero on ‘PJSIP/anonymous-000000a7’
[2018-12-28 14:25:00] VERBOSE[9759][C-000000a8] pbx.c: Executing [[email protected]:9] Playback(“PJSIP/anonymous-000000a8”, “ss-noservice”) in new stack
[2018-12-28 14:25:00] VERBOSE[9759][C-000000a8] file.c: <PJSIP/anonymous-000000a8> Playing ‘ss-noservice.ulaw’ (language ‘en’)
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.380+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff408880d60”,LocalAddress=“IPV4/TCP/”,RemoteAddress=“IPV4/TCP/”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.380+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.383+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff414003010”,LocalAddress=“IPV4/TCP/”,RemoteAddress=“IPV4/TCP/”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.383+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.391+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff404024830”,LocalAddress=“IPV4/TCP/”,RemoteAddress=“IPV4/TCP/”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.391+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.392+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff40c014b60”,LocalAddress=“IPV4/TCP/”,RemoteAddress=“IPV4/TCP/”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.392+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.392+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff400003ad0”,LocalAddress=“IPV4/TCP/”,RemoteAddress=“IPV4/TCP/”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.392+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.406+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x2425430”,LocalAddress=“IPV4/TCP/”,RemoteAddress=“IPV4/TCP/”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.406+1100”
[2018-12-28 14:25:02] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:02.440+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff3f80031c0”,LocalAddress=“IPV4/TCP/”,RemoteAddress=“IPV4/TCP/”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:02.440+1100”
[2018-12-28 14:25:05] VERBOSE[9759][C-000000a8] pbx.c: Executing [[email protected]:10] PlayTones(“PJSIP/anonymous-000000a8”, “congestion”) in new stack
[2018-12-28 14:25:05] VERBOSE[9759][C-000000a8] pbx.c: Executing [[email protected]:11] Congestion(“PJSIP/anonymous-000000a8”, “5”) in new stack
[2018-12-28 14:25:07] SECURITY[2773] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“2018-12-28T14:25:07.003+1100”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7ff4100009a0”,LocalAddress=“IPV4/TCP/”,RemoteAddress=“IPV4/TCP/”,UsingPassword=“0”,SessionTV=“2018-12-28T14:25:07.003+1100”
[2018-12-28 14:25:09] VERBOSE[2614] pbx_variables.c: Setting global variable ‘SIPDOMAIN’ to ‘’
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [[email protected]:1] NoOp(“PJSIP/anonymous-000000a9”, “Received incoming SIP connection from unknown peer to 949204763000942”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [[email protected]:2] Set(“PJSIP/anonymous-000000a9”, “DID=949204763000942”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [[email protected]:3] Goto(“PJSIP/anonymous-000000a9”, “s,1”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx_builtins.c: Goto (from-sip-external,s,1)
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [[email protected]:1] GotoIf(“PJSIP/anonymous-000000a9”, “1?setlanguage:checkanon”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx_builtins.c: Goto (from-sip-external,s,2)
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [[email protected]:2] Set(“PJSIP/anonymous-000000a9”, “CHANNEL(language)=en”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [[email protected]:3] GotoIf(“PJSIP/anonymous-000000a9”, “1?noanonymous”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx_builtins.c: Goto (from-sip-external,s,5)
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [[email protected]:5] Set(“PJSIP/anonymous-000000a9”, “TIMEOUT(absolute)=15”) in new stack
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] func_timeout.c: Channel will hangup at 2018-12-28 14:25:24.382 AEDT.
[2018-12-28 14:25:09] WARNING[9893][C-000000a9] func_channel.c: Unknown or unavailable item requested: ‘recvip’
[2018-12-28 14:25:09] VERBOSE[9893][C-000000a9] pbx.c: Executing [[email protected]:6] Log(“PJSIP/anonymous-000000a9”, "WARNING,"Rejecting unknown SIP connection from “”) in new stack
[2018-12-28 14:25:09] WARNING[9893][C-000000a9] Ext. s: "Rejecting unknown SIP connection from "

I’m at a bit of a loss and not sure what to do to stop them.

One solution is to just NOT listen on udp/5060, with any channel driver, EVER.
Through personal experience, I would expand that to suggest that you don’t listen on any port between 5000 and 5999 for SIP INVITES , you are your own “king of the castle” with all your extensions, but many vsp’s only allow 5060 , no problem, you just add firewall port forwarding rules so your various vsp’s use of 5060 is remapped to the servers listening port, better yet use IP authentification. Even better , only allow traffic to named domains.

1 Like

Hi Dicko,

Thanks for your reply.

So if I use a port forward, say for example 12345 external to 5060 internal, this won’t have any effect on calls?

There is no requirement that SIP uses 5060. It can bind to any port (generally choose anything between 1025 and 63000 odd that is non conflicting). vsp’s that insist on using 5060 can be redirected to 12345 or whatever if you need to, but port and host can also be defined in the trunk definitions and registration strings if you use them. The theory is that if you only ‘pin hole’ udp/5060 to the minimum. Then most if not all ‘drive-bys’ will not see you. That usually means that your firewall will need a much less complex/possibly leaky set of rules

There is no best practice, regardless of port, that says you need to allow access to your SIP port from anywhere you don’t know about unless you allow people to connect to your PBX from random locations. You need to block access to your SIP port to EVERYONE and then allow extremely specific addresses access to that port.

One caveat: if you have people that connnect to your PBX from “random” locations (like the local McDonalds) or from phones that get new addresses every day. With these, using Dynamic DNS services, UCP, or VPN configurations are “better” practices, with VPN being the best.

There is no excuse to allow a SIP port to be visible to bad guys any more. There just isn’t. As a community, we have worked out at least four different ways to solve this problem for you - all you need to do is use the one that best suits your needs. To reiterate. there is no excuse for leaving your SIP ports open to the world. Pick a solution and set it up. Look at the FreePBX Wiki (under the Firewall entries for example) to get more information. If you still need more help, ask.

Strange because anonymous inbound calls via PJSIP are not allowed by default, anyway how about to increased security by using ACL (IP based allow/deny) and fail2ban?

Perhaps I can expand on my previous “possibly leaky” statement, any of Allow/deny/fail3ban/iptables are indeed “leaky”. That your system rejects them but doesn’t drop them unfortunately leaves a breadcrumb that the “investigator” now knows you provide SIP services, these guys are really not stupid, your IP addresses are collected and possibly sent to “second level” systems that are more aggressive . The concept that all and any ports CAN be compromised is indeed true, but in reality I have never seen SIP attacks outside 5000-5999. Quite reasonably, if you don’t respond on the major targets (5060 for asterisk et al but and increasingly 5080 for FreeSwitch and ironically a lot more on 5160 :slight_smile: ) then you cannot be but less exposed.

Absolutely, use firewalls as all sorts of ports are likely at least half-open 22,5038,8***,443, 3306 (aggressively nmap your box from outside if you don’t believe it, it is often used to provide a “fingerprint” of what you are likely running) but if you simply hide SIP and implement a rudimentary port-scanning policy your exposure is unsurprisingly a lot less ( and I mean a lot :wink: )

JM2CWAE and be mindful of probably not wanting to be an ostrich

I have never been a fan of using “non-standard” SIP ports as a primary method of “SIP security” but if it works it works. However, to think that probes happen in the 5XXX range is not entirely true as many regions around the world already block “external access” for SIP along the most common ranges. I’ve had customers in the past out of India, Iran, etc and those required me to have non-standard ports listening for SIP. Ports that in some cases where standards for other protocols. I’ve had to have 80, 443, etc all listening on SIP for these special cases because their regional firewalls let those through.

Honestly, in most business PBX deployments have a Deny All by default firewall and only letting what you need in is the best course of action. In some rare cases there are “remote” users and you might need to run some filtering/rate limiting to let them in but those are IBC’s for sure.

For someone like me that has end users connecting from all over US/Canada I took a little more pragmatic approach. I have customers that exist in one Regional Internal Registry, ARIN. I have no need to allow any access from the other four RIR’s so those are automatically blocked. Now all I have to do is deal with those within the ARIN ranges and that makes life a lot easier since they are more manageable and regulated. Case in point, my firewall caught someone in the same Data Center as me trying to hack my network. Whoever they were, no longer in my DC due to me filing complaints and logs.

Right now I got a system using these rules and in the last 75 days (since it was brought up) over 250K packets dropped from non-ARIN sources and over 100 ARIN ips dropped after they broke rules. In most cases they pretty much stop and move on once they start getting dropped constantly.

So really, security measures put into place should meet the requirements and need of your deployment. Since those are different for everybody some best practices are wise to follow but you’ll need to tweak it to meet your needs.

There is another function of Asterisk which also greatly improves security (but little used) if you use UDP/5060 (the target of 99.99% of the bad guys) .For chan_sip , just add
domain= ;If you have t38modems or the like

to either


or in the gui to extra sip settings in the GUI.

For chan_pjsip, I’m sure there is an equivalency in your AOR setup to reject any IP based URI’s

That would trigger something like a message

[2018-12-29 12:41:12] NOTICE[13726] chan_sip.c: Registration from ‘“301” sip:[email protected]’ failed for ‘’ - Not a local domain

that a well configured fail2ban asterisk regex will capture and ban at iptables but even so Neither SIP REGISTER nor INVITES nor OPTION would be accepted nor processed.

This particular attacker is in Iceland, so RIPE, I will note that most of the Chinese Universities (also not stupid) have moved their attack servers to ARIN cloud servers, they are still there though

Just have your phones register to your dns name and not the IP. There are possibly some problems with some VSP’s requiring them to use names not IP’s but none of mine have a problem here.

(Watching sngrep is very informative as to WTF is going on)


Kind of an edit to the the last line of my previous post about sngrep.

So as not confuse, sngrep is like tcpdump, it runs on raw packet capture so will nicely show traffic before it hits iptables, this means that it will reveal ALL SIP like traffic arriving (and departing) on your internet interface (by default) so if the ‘Msgs’ column is greater then 1, then the traffic reached your VOIP server, INVITES and REGISTER packets will reveal the ip source address, but hopefully if your firewall is well constructed it wont get through iptables, current fail2ban asterisk jails will catch the “not local” and eventually ban them, adding the should trip fail2ban , if your using older versions of fail2ban, such bans are “forgotten” on a restart so make sure fail2ban is current.

As a side note, many attackers are working in a cluster, so jailing the host is inefficient, they just use another IP address, I prefer to ban the entire underlying subnet , iptables can get very big , so look at using ipsets in your “deny” lists and look to a python script like available at

which derives the “route” from the ip address and add the result to you iptables drop list.

Be aware that that process is aggressive so the result of --addr --json 2>/dev/null |jq "[.entities[0],.objects[]][1],.network.cidr,",.null|tr '\n' '\t'|sed -e 's/null/\n/g'

would be

"Cox Communications Inc." "" "NETBLK-PH-CBS-68-14-208-0"

Possibly a badly configured extension that got caught, but works very well for Palestine and other bad actors , many cloud providers like OVH should be considered as bad actors as no matter how much you complain, the culprits are never kicked out.

(you can install jq from most repos)

Of course most of this isn’t be necessary if you don’t use 5060 :wink:

I have scripted it (for csf), but I am not allowed to post bash scripts here.


So, may I ask how many of those 250K+ well intercepted packets, ARIN or not, were directed to any port but udp/5060 and how many to anything but your servers IP address ?

Well all the servers I deal with are on public IPs so it’s 100% my servers IP that is being hit. As for how many are 5060 UDP, don’t know. Those places don’t need access to those servers for anything so I block them completely. There are other types of attacks to consider since these systems are generally full LAMP systems so why risk anything else being hit?

As for the ARIN based IPs, I’ve blocked over a hundred individual IPs in that time frame. Those are 100% on 5060 UDP because they get past the main firewall and I let my SIP firewalls/proxies deal with them. Since all my end users should be using FQDN’s one of my rules is to block any SIP request that has pure IPs in the From, To or RURI’s that alone has dropped most of those individual IPs which in turn reduces the amount of INVITE’s/REGISTER’s I get against the network.

Like I said, a lot of the real security measures that will need to be taken will be based on the individual needs of those implementing them. If every source IP is static, known and trusted then your firewall rules and measures are going to be different than those that have to let dynamic IPs in and thus open themselves up more to the world. Some may choose to use iptables alone and rate limiting others, like myself, employ proxies to help deal more granular levels of security.

Even my allowed IPs from end users or valid FQDNs still have User Agent validation, auth rates limits, call rate limits because a phone or PBX could be compromised at a location and sending requests from valid IPs, FQDN’s and the extra layers of checks are there as a safety net in case something like that was to happen.

But even with me, I have a few small providers I do this for and they each have their own business needs for their services/systems so while I re-use many of the core logic/structure it has to be tweaked for each network that it is being implemented on.

1 Like

Ah, so my posts were about not using 5060 which you are appaently not a fan of , you said

"As for how many are 5060 UDP, don’t know. "

Would that not be germane to this thread for you to glean that data , as would knowing whether the intrusions are directed to your IP or domain name?

as I suggested you can easily reject IP only traffic. Some say “the proof of the pudding is in the eating”, I invite you to taste it :slight_smile:

I think you are misunderstanding what I am saying. I have a network that is more than just Asterisk/FreePBX boxes. I have web servers, database servers, proxies, DNS, XMPP servers, SMTP Gateways, et al running on my network. As I have no end users or clients based in non-ARIN IP spaces, I don’t have any expectation or need for non-ARIN IPs to have any access to my network. So no, I cannot tell you how many non-ARIN IPs are hitting port 5060 over UDP because I’m flat out denying them to avoid any other issues or attacks to protect my network overall.

In regards to ARIN based IPs, I said I blocked over 100 IPs in the last couple months. Those IP’s where blocked by my system by hitting 5060 UDP and hitting me with IP based URIs. I have deeper checks if they get passed that but generally they do not because they aren’t trying to figure out the over 2 dozen FQDN’s I have in play (because the domains handle routing) they hit the IP. Since I’ve been running this network (few years now) I’ve had one instance where an attack and fraud attempts where made with valid FQDN’s on my network. That was due to the end user’s network being 100% compromised but my deeper checks alerted and stopped it.

I’ve been working at or with ITSP’s and LECs for 15+ years doing SIP for very large scale networks and users bases. In all those times we did not ever deploy the “use non-standard SIP ports” as a security measure. Did we see attempts over 5060 all the time, hell yes but proper firewall rules, SIP rules, etc do wonders to mitigate and manage those things.

I’ve dealt with this pudding and tasted it for a long time. So I’m well aware of what pudding recipes are bad and what can be good. As I keep saying, there are various ways to make the pudding and you have to give it the flavor layers that meet your tastes.

I am sorry I misunderstood , previously you said you didn’t know about 5060, now you do :slight_smile:

Many of us have systems that can chew gum and walk at the same time. Are you aware that fail2ban has
“sh*t-loads” of jails waiting to be enabled?

Some of us have larger networks that have VOIP users actually travel outside the US and some have being doing it for longer than +15 , seriously :wink: , they also expect all the other services we provide to still work even in China. Security means protecting as necessary, not block banning huge parts of the world.

If you are happy with your security, then good, do you mind if other people have other opinions?

What part of me saying that while you can follow standard/common practices but you have to make tweaks and adjustments to fit your network deployment screams “DO IT THIS WAY”? I related how my current network works. I also related how I had end users in India, Iran and other places in the world in the past that needed special consideration because not only couldn’t they use standard SIP ports, they had to use common ports for things like HTTP, etc for their SIP to work.

So yes, I’ve had to deal with customer from all over the world at some point and when that has been the case the network security took all that into consideration. Not every network and deployment has the same needs and requirements but they do generally have some cross over that makes using common practices common sense.

1 Like

This thread is surely about VOIP and securing it easily . I don’t think anybody cares about how clever you are (or me in truth). Lets just concentrate on the problem presented and the viable solutions available here. If you have any more useful input, please post it.

To start, it’s useful to know a little about the enemy. Attacks may be random, or targeting your system specifically.

Random attacks use automated tools to probe every IPv4 address. When something promising is found, a smarter robot and/or human skill is applied in an attempt to complete penetration. The motive is usually one of:

  1. Steal phone service, e.g. for resale in internet cafes or taxiphone shops.
  2. Make calls to premium numbers controlled by the attacker.
  3. For telemarketing spam or scam calls.
  4. To mask communications used in planning or executing an unrelated crime.

Targeted attackers generally have no interest in toll fraud. Examples include:

  1. A competitor tries to obtain your customer list, designs, business plans or other IP.
  2. A disgruntled current or former employee seeks to sabotage your business.
  3. Your wife searches for your communications with your mistress.

The security playing field is overwhelmingly tilted in favor of the attacker. Your defense must succeed every time, but he has to succeed only once. An attacker with sufficient expertise and/or funds will surely breach your system. If you need to defend against a targeted attack, get professional assistance. Nothing that we discuss here will be adequate. The remainder of this post is about random attacks.

It is infeasible, even with a large botnet, to probe every port in IPv4 space. So, using an obscure SIP port can certainly help; in my experience it will reduce unwanted traffic by at least 95%. But, be careful: if your PBX previously responded to an attacker on port 5060, changing the port (with the same IP) won’t help; he’ll scan every port on your machine. Likewise, if your IAX port (or heaven forbid, your web admin port) is open, he knows you have a PBX and will probe all ports for SIP.

Filtering by domain name is very powerful. My preference is to do this in iptables rather than Asterisk. An attacker sending REGISTER, INVITE or OPTIONS without the ‘secret’ domain name gets no response at all; after a few attempts he moves on to the next sucker. Also, it’s more flexible because you can whitelist addresses of trunking providers who will use your numeric IP address. Choose an obscure name and be sure that a reverse lookup yields something different. See for example

Once past the above defenses, the bad guys send two kinds of traffic: attempts to register an extension, and calls to numbers that might route externally. For the former, be sure that every extension has a password strong enough to resist offline cracking; there are several ways that he might have the hashed password. For the latter, be sure that anonymous and guest calls are disallowed and (in case he gets past that) the from-trunk and similar contexts have no path to an arbitrary external number. (You should also check for DISA, voicemail and attended transfer vulnerabilities, though an attacker would not need SIP access to exploit them.)

Fail2ban rarely prevents an actual breach – if the password is known, the bad guy gets in, if not (and it’s strong) a billion attempts won’t help him. However, it’s useful for alerting you to problems earlier in the chain, for reducing unwanted load on the system, and for removing log clutter that could prevent you from spotting other trouble.

In case all of the above fail, having some restrictions in the system is useful, e.g. blocking countries that you don’t normally call, or protecting those routes with a password.

Also, take advantage of the fraud controls offered by your trunking providers. To protect their own network, there are typically limits on number of concurrent calls, calls per second and maximum monthly spend. If higher than you need, ask them to reduce the limits for your account. If you auto-recharge, there may be an option to limit the frequency. You may also have the option to block calls exceeding a specified per-minute rate, or calls to specific regions or countries. And, if they have a ‘minimum balance for outgoing calls’, set that high enough so that if all hell breaks loose and your account is drained, your incoming calls will still work while you resolve the issue.

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