Security Warning - Watch Your Trunks!

[Linetux]

There's been a recent rise of attacks against port 5060 recently. A number of outlets are reporting varying degrees of issues, with the extreme of $120K bills coming in.

Some articles for reference:

http://isc.sans.edu/diary.html?storyid=9193

http://www.zdnet.com.au/thousands-lost-in-rising-voip-attacks-339306478.htm

http://www.zdnet.com.au/voip-hackers-strike-perth-business-339294515.htm

Watch those ports - use secure passwords - and unless you know what you're doing, don't accept anonymous SIP calls! I commend Ward for creating a PBX that doesn't have to have ports open to the outside world. Most definitely a step in the right direction for a lot of folks.

Stay safe out there!

 

[wardmundy]

Oldie But Goodie

Avoiding the $100,000 Phone Bill: A Primer on Asterisk Security

And, of course, with The Incredible PBX, all of these worries become a thing of the past... no ports exposed! We're working on adding sip2sip.info for SIP access (it's free!) which will be the best of both worlds.

 

[esjones]

To open ports, or not?

OK... so The Incredible PBX doesn't need ports opened on my router. Great!!

I had a dropped call incident today (multiple times... same number) with my Voip.ms trunk, so I opened a chat with their customer support.

First thing he asks is, "Do you have UDP port 5060, Range 10000 - 20000 opened and forwarded to your PBX?"

Which is it? Nearly everyone says you have to open these ports, and Nerd Uno says NO! I am inclined to put my trust in Ward, but would appreciate a bit more education on the topic.

Thanks.

- Earl

 

[jroper]

Hi

It very much depends on the carrier, and how they deliver DID to you. it also depends on your router.

Because 5060 handles the teardown and set up of the call, and the registration, theoretically, by the magic of NAT, the port should be open on the firewall to the carrier, so when an inbound call is set up, the SIP commands to negotiate the call should go straight to the asterisk PBX, as the NAT device knows that anything on 5060 has been requested.

However, the NAT port only stays open for a limited period of time, then closes. Hopefully, the period of registration is regular and of short enough time intervals to keep the NAT port open, however, this is by no means guaranteed, but works in most cases.

In SIP, there are two ports that are usually used for RTP, with Asterisk, they are in the range of 10,000 to 20,000 UDP, one port for the outbound, and one port for the inbound. There are a further two ports in this range used for RTCP (Realtime control Protocol) One in and one out.

So without NAT=yes, in Asterisk, you are using a total of 5 ports,

5060 for call negotiation
RTP and RTCP in and out

So RTP and RTCP traffic turning up on a port other than the one used for the outbound will be dropped as it has not been invited, hence one of the reasons for one way audio. There is another reason for one way audio, which is the misreporting of the clients IP address to the SIP server - which is why we use externip and localnet to tell the other end what our external IP address is, so the traffic is not sent to an internal IP, which cannot be found by your SIP provider.

Some modern firewalls can handle this state of affairs, and that is one of the purposes of ALG. (Application Layer Gateway) Generally with an ALG firewall, you do not do any port forwarding as this screws up the ALG in many cases - just leave ALG to do its job.

However, another way it can be dealt with is with the NAT=yes directive, which will ensure that the inbound and outbound RTCP and RTP ports will be the same for both audio in and out, thus ensuring that the appropriate NAT ports are open to the carrier.

So in many respects, Ward is correct, providing you have a router that is SIP aware, and the registration period is not too long in respect of the carrier.

However, not all carriers and routers are that friendly, so your technical support guy is also correct, in as much as he is trying to identify where the issues are. You don't have to open the SIP port to everywhere, only the IP addresses of the carrier concerned.

What I hope is that has given a brief overview of what is going on, so you can make your own judgement of what maybe going awry.

However, this is all about negotiation and set up of the call. A dropped call midway through a previously working call is unlikely to have anything to do with the above. In this case, I would have a second carrier, and see if the same problems persist over multiple carriers, in which case you should look to your own equipment.

If the problem is related to one carrier only, then I would be looking at carrier issues.

Joe

 

[wardmundy]

The good news is you'll immediately know if your router requires these ports to be open because the calls will either work or won't. Here's a big hint though. If it doesn't work, a new router is a helluva lot cheaper than a $100,000 phone bill.

 

[blanchae]

One option is to add the qualify=yes to your trunk setting. Asterisk will send a SIP OPTIONS command regularly to check that the device is still online. This should keep the port open on your firewall.

If the SIP registration is initiated from Asterisk to the service provider than the firewall will open the ports automatically. It doesn't block outgoing connections.

If the SIP registration is initiated remotely to Asterisk, then the firewall will, by default, block incoming SIP calls. Then you would need to open ports 5060-5061 and 10000-20000 and direct them to your Asterisk server. Plus add NAT=yes in the extension setting (if from an extension) and configure sip-nat.conf for

externip=Your External IP
localnet=192.168.1.0/255.255.255.0 ; substitute your subnet info here
nat=yes

In addition to having your firewall direct SIP to your Asterisk server, I would also limit the remote source to your service provider IP address - only your service provider is allowed access through the firewall to your Asterisk server, all other IP addresses are rejected. This should be done through both your router firewall and iptables.

 

[dswartz]

I have UDP/5060 forwarded to my piaf box, but the firewall acl only permits traffic from the two freepbx SIP servers.

 

[vanDivX]

I am a bit confused with too many places where one can filter inbound IP traffic. This is the list in what I think is the hirearchy for traffic coming in from outside to PIAF either to register as remote extension or ITSP.

1) your hardware firewall
2) PIAF IP Tables
3) FPBX IAX & SIP Seurity section (Asterisk global rules: deny, permit)
4) FPBX per Extension (deny, permit)

I think this is the hierarchy.

Comments:

My hardware firewall is ClarkConnect (old edition, now it is called 'Clear Foundation - Clear OS') and I don't seem to have the ability to only permit inbound traffic from specified IPs to given ports, that is I can only open ports but can't associate them with IPs allowed to use them. But I might be mistaken about that or perhaps the new ClearOS firewall does have this ability and I should upgrade...

--> But I suppose I can get the same functionality by allowing only certain IPs in PIAF IP tables? Right?
Then it shouldn't matter that I have 5000-5082 & 10000-20000 ports open on my firewall forwarded to PIAF, right?

I have some doubts about point 3 - the global permisions. I mean the rules set there don't seem to do anything but I didn't do rigorous testing and can't claim to be some expert.

Also it has no description like if deny should come first in line and permits following. I use PC remote access software with IP access filtering where the logic is you permit what IPs you want to allow access from and then on bottom line you deny everything else, here it is in reverse, at least I assume the advice I got here on forum regarding this was correct (deny on first line, then permits following) - but this should be spelled out in the popup clue description (I suppose those fields are used for other tasks than just IP fitering and so they didn't state any rules incl. those for deny permit)

I did play with placing deny last, also deny on first and last line but it didn't seem to matter, I mean I wasn't getting any effect I could see that it does anything (but that might be because registrations stick for a while even if all traffic from those IPs is blocked, however I could remotely connect to another location and register extension from there while the IP of that location wasn't permitted, it got me confused also not sure if simply saving & reloading is enough for these changes to take effect, maybe iptables should be restarted but not knowing the command I also restarted whole PIAF few times during this testing to make sure)

On the other hand the per extension IP filtering does work but I miss having more than one entry field for IP 'permit' (one of my remote extension IP changes even in its first octet and so I can't use this per extension permit setting, it would have to have several fields or allow something like

90.0.0.0-96.0.0.0/255.0.0.0

which I don't know if that is allowed there. If it was I'd just filter right at the extension level and forget about global settings.

Actually I don't know if this global permissions are superseeded by IP tables by I suppose they are. But then I don't see the point using both as they seem to do the same job only you have to fill in more lines, I'd put my eggs just into IP tables, is that right?

-------------------------------

Bottom line in security is I suppose how much money you have deposited with ITSPs (assuming one has only those that won't extend you any credit) and most you can loose is what you got prepaid, right? Or can someone break into your PIAF and register trunk someplace where they give credit no questions asked and he runs up huge bill on this trunk... but still he'd have to register there under your credentials for you to get stuck with the bill afterwards, right?