FreePBX server compromised

(Ted) #42

I got a bunch of these SIP requests in the log now.
Only some of them receive a 200 OK reply.

[2020-09-11 02:25:41] VERBOSE[2060] res_pjsip_logger.c: <— Transmitting SIP request (435 bytes) to UDP:phone-gateway-ip:2155 —>
OPTIONS sip:5420@phone-gateway-ip:2155 SIP/2.0
Via: SIP/2.0/UDP PBX-IP:57293;rport;branch=z9hG4bKPj4594f97c-73b7-4cc3-8630-71e9a3058ee5
From: sip:5420@PBX-IP;tag=320995c4-f341-42c5-90b0-cfd32cd4cd49
To: sip:5420@phone-gateway-ip
Contact: sip:5420@PBX-IP:57293
Call-ID: 33be492c-7395-41a5-9156-7a77479e7601
CSeq: 36235 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-
Content-Length: 0

(Ted) #43

And this is a working extension. The one that doesn’t go unreachable. It is under a different USG in a different location. It looks like this one has a proper port number (the one that we want to use as a custom SIP port, while the other one is some other port number.

[2020-09-11 02:25:46] VERBOSE[9601] res_pjsip_logger.c: <— Transmitting SIP request (438 bytes) to UDP:phone-gateway-ip:5728 —>
OPTIONS sip:2255@phone-gateway-ip:5728 SIP/2.0
Via: SIP/2.0/UDP PBX-IP:5728;rport;branch=z9hG4bKPj169b4d92-c186-4ecf-87fb-dbcdc90292de
From: sip:2255@PBX-IP;tag=3f76edb3-c9a3-4c10-83e4-4746dce44959
To: sip:2255@phone-gateway-ip
Contact: sip:2255@PBX-IP:5728
Call-ID: 48017649-f076-426d-9a5b-6df1bc699159
CSeq: 31598 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-
Content-Length: 0

(Ted) #44

Looking at pjsip show contacts is showing me that the phones that a behind different routers are showing reachable and are also all showing the correct custom sip port, while other phones behind that USG Pro router, are all on random sip ports. Does that mean that USG is still doing the SIP ALG or something? Why is it modifying the sip port.


OK, we’re getting somewhere. The REGISTER request (as received by the PBX) has ports numbers in the Via and Contact headers. But (by default), the extension settings should have RTP Symmetric, Rewrite Contact and Force rport all Yes, so the OPTIONS should be sent to the IP address and port from which the REGISTER was received, ignoring headers in the REGISTER request.

The OPTIONS request has Via and Contact headers. Both of these should have the port that pjsip has in Asterisk SIP settings for Port to Listen On (which is the port that the phone should be sending requests to).

(Ted) #46

What could this mean?

Also why do you think under two different routers, the pjsip show contacts is showing the proper ports while under that USG they are all modified and the contacts are unreachable. It seems like the SIP ALG is still functioning on that router when I actually turned it off already.

(Ted) #47

Setting the Yealink phones registration expiry to 60 seconds seems to fix the issue and the phones go unreachable and jump right back to reachable. But I feel like it’s just a work around.


It’s not even a good workaround, because if an incoming call arrives during the brief unreachable interval, it will go to voicemail. However, a short expiry is usually a good idea for other reasons. If a momentary network outage causes qualify to fail, the lack of traffic may cause the remote router to close the NAT association, resulting in future OPTIONS requests not being delivered, until the device registers again, up to an hour later.

pjsip show contacts shows the address and port where an incoming call would be sent. If you have more than one endpoint behind the same NAT, all sending REGISTER from their local port 5060, the router/firewall must translate the source port number for all but one, whether SIP ALG is enabled or not. Otherwise, two endpoints would appear to be on the same port and the router wouldn’t know where to send the replies. While most NAT routers only modify the source port when there would otherwise be a conflict, I believe that USG by default always selects a random source port.

If pjsip show contacts for each extension shows the public IP address and port number from which REGISTER was received, regardless of the content of any headers, that is correct behavior. Anything else is a problem at the PBX end.

If the OPTIONS request is sent to other than the address and port indicated by pjsip show contacts, that’s a problem at the PBX end.

And, if the Contact header in the OPTIONS request contains anything other than the public IP of the PBX and the port that pjsip is listening on, that’s a problem at the PBX end.

Note that when any setting regarding IP addresses or ports is changed, you must restart (not just reload) Asterisk. If you’re not sure, reboot the entire server.

(Ted) #49

Thanks for your input. 60 registry expiration seems to always keep the phones reachable.
Does that mean I had some UDP time out issue on the router? Since all the phones were registering fine and were reachable for a few seconds, but then the connection timed out and the phones became unreachable. Maybe I should bump up the UDP timeout in the USG? Everything seems to work properly until that connection times out for some phones. But with the phone’s reg exp being 60 seconds everything is good. Doesn’t seem to be a port number issue, does it?

(Jared Busch) #50

Courtesy of @lgaetz’s twitter feed.



Network is poorly configured? No problem! Send more OPTIONS and REGISTER requests! That’ll help.


Registration and qualify are two different things, though related.
For a moment, assume that we turn off qualify.
The phone is set to register by default with a one hour expiry. If registration is successful and there are no calls, there will no further communication for almost an hour and both phone and PBX will assume that the phone is online during that time. However, the NAT association will close after the UDP timeout in the USG; after that incoming calls will fail, until the phone registers again.

If you set the registration interval shorter than the UDP timeout, the phone will stay connected. IMO registering every two minutes with a three minute timeout is a good combination of settings.

Qualify (OPTIONS requests) serve two purposes – they help keep the NAT association alive and they notify the PBX about a connectivity request more quickly. If they don’t work properly because they are being sent to the wrong port, you should fix that.

(Lorne Gaetz) #53


(Ted) #54

Now there is one way audio. Omg we only switched from a default port number:/


Please confirm that you only changed Port to Listen On and restarted the server. If your cloud provider has a firewall you also have to allow the new port to pass. However, any schemes involving forwarding a port to a different port will not work with Asterisk.

(Ted) #56

We only changed the binding SIP port in the pjsip settings and restarted the pbx after multiple times.
We also have disabled the responsive firewall because it is acting up and blocking remote Zoiper extensions when a Zoiper phone switches between networks like from wifi to LTE and quickly reregisters. RF thinks it’s an intruder and blocks them. So we disable RF and only use fail2ban.
If RF is disabled, do we have to explicitly open RTP ports or something so that the audio works properly?
Hows does RF play with RTP in general?
Also when RF is disabled what other percussions need to be done for the proper firewall ports traffic.
And our cloud provider does not have any firewall and our PBX and all endpoints have always worked fine with a default 5060 port and never had problems.

Nevermind, i think the audio is good, with RF disabled and no rtp ports opened up in the pbx firewall.

(Ted) #57

This is what 8x8 recommends to do when using a USG

(Ted) #58

Just an update, setting the UDP timeout to 660 seconds in the USG has so far resolved our issue completely. Even if we don’t change the phone registration expiration.

(system) closed #59

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