Assistance request - Possible virus on PBX

General Help
1

Hi!

I need assistance figuring out what is happening on my PBX.

I recently changed my firewall/Router. We were using a RV042G and upgraded to a Fortigate 60.

At first, the upgrade seemed to cause issues: we had a lot of dropped calls and call quality issues. I ended up disabling SIP ALG in the fortigate and things were better… but not perfect.

I have noticed in the logs regular instances of this message:
[2017-08-11 14:57:03] VERBOSE[30044][C-000001a3] pbx.c: Executing [s@from-sip-external:6] Log(“SIP/67.68.XXX.XXX-00000488”, "WARNING,“Rejecting unknown SIP connection from 93.115.26.2"”) in new stack
[2017-08-11 14:57:03] WARNING[30044][C-000001a3] Ext. s: “Rejecting unknown SIP connection from 93.115.26.2”
[2017-08-11 14:57:03] VERBOSE[30044][C-000001a3] pbx.c: Executing [s@from-sip-external:7] Answer(“SIP/67.68.XXX.XXX-00000488”, “”) in new stack
[2017-08-11 14:57:03] VERBOSE[30044][C-000001a3] pbx.c: Executing [s@from-sip-external:8] Wait(“SIP/67.68.XXX.XXX-00000488”, “2”) in new stack
[2017-08-11 14:57:05] VERBOSE[30044][C-000001a3] pbx.c: Executing [s@from-sip-external:9] Playback(“SIP/67.68.XXX.XXX-00000488”, “ss-noservice”) in new stack
[2017-08-11 14:57:05] VERBOSE[30044][C-000001a3] file.c: <SIP/67.68.XXX.XXX-00000488> Playing ‘ss-noservice.ulaw’ (language ‘en’)
[2017-08-11 14:57:10] VERBOSE[29425][C-000001a2] res_musiconhold.c: Started music on hold, class ‘default’, on channel ‘SIP/507-00000486’
[2017-08-11 14:57:10] VERBOSE[30044][C-000001a3] pbx.c: Executing [s@from-sip-external:10] PlayTones(“SIP/67.68.XXX.XXX-00000488”, “congestion”) in new stack
[2017-08-11 14:57:10] VERBOSE[30044][C-000001a3] pbx.c: Executing [s@from-sip-external:11] Congestion(“SIP/67.68.XXX.XXX-00000488”, “5”) in new stack
[2017-08-11 14:57:15] VERBOSE[30044][C-000001a3] pbx.c: Spawn extension (from-sip-external, s, 11) exited non-zero on ‘SIP/67.68.XXX.XXX-00000488’
[2017-08-11 14:57:15] VERBOSE[30044][C-000001a3] pbx.c: Executing [h@from-sip-external:1] Hangup(“SIP/67.68.XXX.XXX-00000488”, “”) in new stack
[2017-08-11 14:57:15] VERBOSE[30044][C-000001a3] pbx.c: Spawn extension (from-sip-external, h, 1) exited non-zero on ‘SIP/67.68.101.XXX-00000488’
[2017-08-11 14:57:27] VERBOSE[29425][C-000001a2] res_musiconhold.c: Stopped music on hold on SIP/507-00000486
[2017-08-11 14:57:35] WARNING[2336] chan_sip.c: Retransmission timeout reached on transmission 626a73ce2ee623cababc6d8e2ddfd01d for seqno 1 (Critical Response) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response

XXX.XXX replaces the original IP for safety reasons.

The specialist that installed and configured the Fortigate claims that the traffic relating to the error message above is FROM our PBX, TO the outside world. The Fortigate is configured to allow UDP traffic on 5060 and 10000 - 20000 from our SIP provider’s IP address range ONLY; hence, we would assume that there would be no way for 93.115.26.2 to try and contact our PBX directly.

One other detail: PORT 5060 answers to telnet requests, even when my Internet Modem is fully disconnect. That is because my internet supplier offers phone lines with their modems, and appears to offer said landline on their PBX answering to telnet requests from the outside world. Fortigate specialist suggests changing the listening port to isolate our PBX from BELL’s system.

I would like to hear suggestions on how to resolve my issue. You may very well need more information from my part: please do not hesitate to ask! Make sure you are precise on your requests, as I’m not a VoIP expert. I cam navigate in Linux and am familiar with Freepbx, but that’s pretty much it.

Thanks!!

2

You need to disable anonymous and guest sip calls, telnet works over TCP so if you only offer UDP based SIP requests then it would be no problem. Your logs show attempts FROM Lihtuania so it is highly unlikely that your ‘specialist’ is correct. you need to fix your firewall(s) for port 23 (telnet) and absolutely deny such connections, (maybe use ipsets) . If your ISP accepts proxy telnet connections to your network then I suggest you look for another one

3

Using telnet to connect to the UDP port on your phone system should be disabled by disabling the TCP version of your SIP service.

Your Fortigate is not set up correctly - it sounds like your “specialist” is either untrained in simple Internet protocols, or does not have a clue what he’s doing (arguably, the same thing).

Clearly not. The connection attempt may be getting spoofed so as to look like it’s coming from your ITSP, but the traffic is definitely originating outside your network. Note that some of the traffic from this excerpt is coming from your PBX, but it’s mostly the stuff where the phone in Lithuania is told to p*ss off.

This tells all of us that the Fortinet is passing traffic from the outside world to your port 5060. Your “specialist” needs to lock this port down to only allow UDP traffic from the ITSP’s IP addresses, and block all TCP traffic to this port.

This line tells us that your system is correctly not allowing the connecting traffic to access your system. It is playing “all circuits are busy” and hanging up.

These lines are other problems that your “specialist” has probably caused because of his ignorance. For example, the 32000 msec is about 30 seconds of a call before the call gets randomly dropped. There are “qualify” (IIRC) settings that you need to implement so the router will not forget your outbound path to the ITSP and turn off your phones after 30 seconds. This is a failure in the RTP settings (port 10000-20000) in your configuration, so you’re likely to get one-way audio if your “rocket scientist” continues to “help” you.

Finally, @dicko is correct. You need to make absolutely certain that the system does not allow anonymous or unauthenticated connections. The Fortigate should be helping you more than it is, but you need to make sure you have battened down the hatches as much as possible.

4

I am always amused by the use of 5000-5099 (as these are the ones that 99.9% of the blackhat scripts probe) for ANY sip connection, be it UDP, TCP, TLS or whatever.
I always set my bindport(s) to something random > 20000, if you can’t configure your VSP to use an alternate SIP port, than at your firewall have traffic from such recalcitrant IP’s PAT’ted to you preferred bindport for her IP connections. then you can then drop any other 5000 - 5099 connections, at the firewall, of course all your external extension would have to use your.internet.presense.tld:(randomregitrationportyouchose)

If you do that then SERIOUSLY most of the knuckledraggers will never go past step one of their script.

3 Likes
5

The problem with changing the bindport is that you then lose almost all of the benefits that Iptables provides to SIP connections automatically by virtue of the related and established firewall rules. Those rules will detect outbound SIP related packets and open the related RTP ports for reply packets automatically, but only from the known source.

If you change your SIP port, you usually have to open the SIP or RTP ports to all traffic, from wherever. IMHO, the trade-off is not worth it. By using the default bindport, you never have to forward any ports unless you want remote access and are for some reason unable to configure a VPN.

6

Clearly, your router is allowing the connection from 93.115.26.2 through. This could be happening for a number of reasons, but the most likely answer is that your router is allowing all UDP traffic on Port 5060 through. Most likely answer is that your router is configured incorrectly.

If you use the default bindport of 5060, you generally shouldn’t have to open any ports whatsoever.

FYI- You should enable Allow Anonymous Inbound SIP, and then set an inbound catchall route that simply dumps the call (Terminate Call:Hangup). By allowing Asterisk to play the disconnect recording, you’re confirming to the potential hacker that your system exists and is an Asterisk system.

7

Allright; everyone here seems to confirm that the issue is “fortigate” related.

One of the thing that I find interesting is that the rule relating to the port 5060 allows connection from the IP range of my SIP provider only.

I’m going to assume that basically, even that rule is not set up properly.

Keep in mind that as per the firewall expert, the requests would originate FROM my PBX, as per the logs.

I’ll let you know what the outcome is. Thank you everyone that provided an input.

8

To be clear:

If a connection is initiated at your PBX (or otherwise inside your network) and it opens a dialogue with the attacker, the firewall will honor that request. The settings would have to be pretty exact for that to work. If something in your network is opening the port, then he could be correct. Having said that, though, that’s a pretty far-fetched scenario. It would require some very specific knowledge of your network and PBX setup.

The typical vector for these types of attacks is through an open port 5060. That’s why we recommended changing your “incoming call” port to something outside the norm. Note that the 5060 port doesn’t have to change in the PBX - open a port on the Fortigate and redirect it to the PBX 5060 port.

If you don’t have external phones connecting to the server (all of your extensions are behind the Fortigate) there’s no reason to allow incoming (or even outgoing) connections that reference your PBX port 5060, especially if you change the port.

Note that there are other attack that can be initiated that would open a dialog this way, but the FreePBX system is usually very good about blocking those attacks.