PBX constantly sends traffic to unknown IPs

Hi, we have an Asterisk (Trixbox) implementation that was workign perfectly, up until a few weeks when users started complaining that internet browsing is slow.

The PBX is connected with TWO NICs: one one SIP modem (which seems OK), the other on our hardware firewall (for management purposes). After hours of troubleshooting, we have discovered that the PBX was the culprit, as it is sending data constantly down the ADSL link. It maxes out the upload bandwidth of the ADSL connection, sending data with 5060 source port (SIP traffic?) to two UNKNOWN destinations, one in UK, one in China.

We have blocked this on the firewall, but we can see it still attempting to send traffic, every single second.

Any ideas as to WHAT this traffic is?

Post the Asterisk cli output with a verbose level at least 5. Could be useful too if you post the log files.

But note that Trixbox is a dead product, whose supplier has closed down even its peer support channels.

Note. I would strongly suspect you have an equal amount of inbound traffic.

Thanks to both for your replies. You are right, there IS a equal amount of inbound traffic. Why, when and to who I have no idea.

This TrixBox setup worked perfectly for several years, and then all of a suddent it went ballistic.

I’ll post excerpts of the log for further review - many thanks.

The traffic will be from criminals, trying to get free phone calls, to make money from premium rate numbers that they own. This is a standard hazard for VoIP systems, that has increased recently. Certain countries are particularly infested with this sort of criminal. On non-turnkey systems, people use tools like fail2ban to add temporary firewall rules to gap this traffic.

There are various good practice rules, although often ignored by GUI producers, that reduce the risk of an attacker actually making a chargeable call. There are papers on this is the standard Asterisk documentation.

E.g. don’t open 5060 except from your ITSP, unless you need to have people call in from random locations, without using a VPN. Use VPNs for phones that are used outside your firewall perimeter. If you must open, block networks associated with coutries where you phones will not roam. Don’t use extension numbers as SIP device resource names (for example use MAC addresses). Use strong passwords. Make sure that your ITSP context cannot make chargeable calls.

Thanks David. It does look like someone got into the system or is trying to. I am not sure HOW, as the PBX is behind an enterprise-grade firewall, with all access to PBX from the outside world blocked.

It is completely beyond me who and when gained access to the PBX. The fact remains that these calls are “placed” from the ADSL link, NOT the SIP link (another mystery). I am currently blocking of traffic from the PBX to the ADSL (obviously SIP calls are allowed), but the big question here is HOW do we stop the PBX from attempting to place these calls?

Do we declare it compromised, and set it up from scratch, or?


You haven’t presented any evidence that it is placing calls.

You will get matched incoming and outgoing UDP traffic if someone is simply searching for valid passwords. As the uplink bandwith is lower, that will saturate first. The attacker will be trying extensions, passwords, and destinations as fast as they can send them.

Blocking traffic except for SIP won’t make any difference as the uplink traffic is likely to be SIP 4xx responses. You need to block SIP traffic from the firewall to the PBX from all addresses except your ITSP’s.


Ok scream over, you say “two UNKNOWN destinations, one in UK, one in China.” how can they be unknow if you know were they are ??? if you have their IP address configure your firewall to drop ALL udp and tcp traffic from them. as since you have Trixbox there was a security issue them and they are rather insecure to say the least.

You asterisk logs will help you a lot also look at you cdr and see if they are getting calls out.

then get a script running to automate the firewall.

DAVID, allow me to clarify: TWO modems: one SIP, one BB (ADSL). The SIP modem is directly attached to the PBX. The BB has a UTM behind it. The PBX is also connected to the UTM, so the PBX can be managed from within the LAN.

They aren’t placing calls as such, as the traffic goes out from the broadband modem, not the SIP modem. We (or the ISP) don’t see any issues with calls getting piped out of the SIP modem (at which point the client’s bill would skyrocket).

What I don’t get, is HOW they are reaching out to the PBX, when the PBX has two interfaces, one is behind the UTM, the other is in a restricted SIP grid that only allows SIP traffic within the ISP.

IAN: just because we know where the IPs are located in, doesn’t mean we know WHO is at those IPs.

I will dig into the logs now and see what’s going on.

Thanks to both.

Ok, so going into Asterisk CLI with a lot of vvvvvvvverbosity, there is ZERO traffic at this point (the office is shut).

Going on to the firewall to see if the outbound traffic to these speficic IP persists over the ADSL link, returns some new attempts to new destination IPs (where 192.168.x.y is the obfuscated version of the actual LAN IP):

9 05/02/2013 14:30:04.672 Notice Network Access UDP packet dropped 192.168.x.y, 5060, X0, 5135, X1 UDP Port: 5135 1 (LAN->WAN)

14 05/02/2013 13:15:25.000 Notice Network Access UDP packet dropped 192.168.x.y, 5060, X0, 5074, X1 UDP Port: 5074 1 (LAN->WAN)

30 05/02/2013 09:02:16.000 Notice Network Access UDP packet dropped 192.168.x.y, 5060, X0, 5381, X1 UDP Port: 5381 1 (LAN->WAN)

34 05/02/2013 08:17:33.656 Notice Network Access UDP packet dropped 192.168.x.y, 5060, X0, 5123, X1 UDP Port: 5123 1 (LAN->WAN)

39 05/02/2013 07:01:37.224 Notice Network Access UDP packet dropped 192.168.x.y, 5060, X0, 5065, X1 UDP Port: 5065 1 (LAN->WAN)

So, if no calls are being attempted/can be traced by Asterisk, YET the above appears on the UTM as the PBX attempts to send traffic out, what do you think went down here? Box compromised?


[quote]just because we know where the IPs are located in, doesn’t mean we know WHO is at those IPs.[/quote] it doesnt matter, if you are not expecting to get traffic from them or send traffic to them , DROP all packets, dont REJECT them.

firstly you just show traffic from your box out, I would stop asterisk, (not shut the server down) and see if the traffic stops, if it doenst then something else has been installed on the server.
netstat -n will help show that. also look at the link in my sig it will tell you how to do a trace so you can get a clear idea of whats going on.

you have by teh sounds of it been hacked, calls arnt getting out but the service will be degraded.

Thanks Ian, interested to know HOW someone made it through to the box. Unless some internal user messed up, his/her PC compromised, and from then on God knows what…

I will look at the material you are proposing. I think the only way to be sure nothings going on is to set up a new PBX, preferably NOT Trixbox…

The fix is in the firewall !!! Another PBX brand could place you in the same position. When my Trixbox was first hacked, I used the Linux OS to blacklist those IPs. Now I have a Cisco router rule that checks a whitelist before allowing UPD 5060 registration through.
As far as Trixbox being dead, that is only the free CE (Community Edition) that is dead!
These are the IPs I collected in my blacklist:

Thanks to all for your replies. It is now clear that this PBX needs to be set up again from scratch. Most probably NOT with TrixBox. Based on everyone’s comments and my own findings, TrixBox is extremely unsafe and unsecure. Most probably we will be going with 3CX.

Any comments?

Why have you decided on 3cx ? why not look at a native asterisk with freepbx if you need a GUI or look at Asterisknow or Elastix?

If you are looking at 3cx then you might as well look at Mitel and Avaya. as they will be comparable in cost

Also, you haven’t convinced me that your problem is anything to do with the PBX software. It still seems to be that you are seeing the normal reaction of SIP software to a problem in your routers/firewalls.

Trixbox has more well known well understood security holes than swiss cheese. You should not be using Trixbox if you have it connected to the internet…full stop.