Security: Too easy for intruders to use your phones to make calls

FreePBX Development
21

SkykingOH: thank you for your suggestions. On “Bug ID 13951” I will say:

  • I looked in the “The Asterisk Handbook, Version 2, Last Edit Date: 3/30/03”, in the sip.conf (around page 56), it does NOT list accept/deny as allowed settings. (They are available for IAX)

  • I now looked in O’Reily’s Asterisk book (2nd Edition), and there around page 98, for sip.conf it does list “permit/deny”. (not “accept”)

  • My version of FreePBX (2.4.0) does NOT have these settings available in the Extension page. Is it in a later version?
    So, now with knowing the key words, I found that what I posted in digium as Bug ID 13951 more appropriately a valid suggestion for FreePBX developer forum, already asked for by other users:
    http://www.freepbx.org/trac/ticket/2827
    http://www.freepbx.org/trac/ticket/932

Can anyone tell me if the solution in http://www.freepbx.org/trac/ticket/932 is now part of the standard FreePBX iso/download?

22

Thanks for finding my syntax mistake. I knew the constructs where available in Asterisk.

Patch 932 has not been merged into the release, it’s not a bad request.

It does set a precedent of looking to the application for perimeter security. If you install the application in a secure environment none of this is an issue. These features are aimed at the ‘do it your selfer’

Even the SIP specification delegates the feature called "admission control’ to the functionality of a ‘Session Border Control’.

FreePBX and Asterisk developers have limited cycles. They should be spent on telephony features not extending the scope of the application.

23

SkykingOH, Thank you so much for your valuable pointer to the feature already available in Asterisk.
I believe it helps the entire community, especially newbies, to let everyone know some of the very real security risks (one of the primary reasons I started this thread); and also some of the things that should be done to address the security issues.

Now some might say that if anyone does not completely understand the security issues, then they have no business playing around with Asterisk, but I think the concept of Asterisk being able to be used by the maximum number of people is a great idea. I suspect that is perhaps the philosophy of the founders of FreeePBX, and I thank them.

The issue I seem to be running into is that since FreePBX wipes out existing settings in many Asterisk conf file every time the administrator makes changes via the FreePBX GUI, therefore having these “permit/deny” security settings absent from the SIP set-up page, it means that even if one completely knows the syntax, then one has to choose not to use FreePBX for configuring SIP if one wants to use “permit/deny”. FreePBX might even wipe out “permit/deny” settings manually entered even when FreePBX is being used to modify for other settings.

To your point “If you install the application in a secure environment none of this is an issue”, I think that to be in a “secure environment”, one would have to have no access between the Internet and the Asterisk box. The problem is when one wants to have some access but have it secure. The more access one wants, the less secure the environment is, right?

As I said earlier in this thread, I have now completely locked out SIP port 5060 at the DSL-router level, so I believe I do now have a “secure environment”, but others might want to have more access, such as allowing others to “dial in” via SIP, remote extensions, and the like.

And, since it seems someone has already done the work in Patch 932, it might actually be less “cycles” for the more advanced people to simply include the work already done, so others (like me) don’t run into this problem then ask about it.

In summary, thank you so much for taking the time to point me (and anyone else reading this thread) in the right direction. It makes the Asterisk experience better for all honest people.

24

Thanks for your comments.

If you take a look in the notes at the beginning of sip.conf you will see you can add any settings you need in sip_custom_post.conf on a per peer basis.

My definition of a secure environment is the Asterisk server existing in a ‘server’ DMZ with access lists for each allowed service. Ideally this device should provide session border controller functionality. The latest release of Juniper ScreenOS performs this function nicely.

The problem is most folks don’t want to run a PIX or a Juniper firewall in the SOHO environment. The only option that I know of is to run DD-WRT and use IP-tables for your access list.

If you are going to open SIP anonymous dialing you don’t have to open up SIP registration for the peers outside your localnet.

As I indicated fail2ban is a great solution also. Strong SIP secrets are a must.

I had the pleasure of spending a week with Philippe and having dinner with Mark Spencer at the last OTTS seminar (which I highly recommend). The conversation focused on business deployments. It’s fun to run Asterisk at home and gets you way up the ladder in geek factor, however at the end of the day it’s business deployments that support the ecosystem. Most IT departments have well developed security policies, established perimeter security and intrusion detection systems in place.

25

MAC addresses and IP addresses can be spoofed. I personally depend heavily on DENY and PERMIT statements in SIP.CONF to fend off brute force registration attempts. Even if they spoofed an address and managed to fake a registration; they still cannot make/receive calls on my dime.

The only thing missing is PERMIT/DENY statements for my SIP trunk provider.

26

Every one of my installations uses deny/permit statements to limit endpoint registration to the local subnet. What frustrates me if the lack of registration control for the trunks. I should be able to limit trunk traffic to specific IPs. For example… If someone tries to spoof my provider via DNS poisoning and I know my provider’s proxy addresses are 206.100.10.0/28 then I should be able to configure Asterisk to discard spoofed traffic in the same way Asterisk discards endpoint registration attempts that violate the permit/deny rules in sip.conf.

Just my two cents. I’m not a developer so until I figure out how to code in C… I don’t really have much to complain about. :slight_smile:

27

MAC Addresses are layer 2 constructs and are not routed. MAC’s can only be spoofed with a physical connection to the collision domain of the interface on the Asterisk Server.

IP source address spoofing is as close to impossible as I can think of on the Internet.

Once again strong secrets and a high quality perimeter firewall (The Juniper SSG’s have rich feature sets and pfSense is a popular and well liked Open source security gateway).

28

you should not be editing the sip.conf file. But instead editing or adding to one of the custom files instead. Please see http://freepbx.org/configuration_files for more information. Short of it is sip.conf can and does get modified and changed from time to time so editing it wil loose those changes on you.

29

Looking for answers.

An Exchange Server installed by Joe and Mo’s son was compromised and somehow the SIP secrets and extensions on the LAN were discovered.

Calls started at 06:30:59 on Saturday and went on until I remotely checked the logs on Sunday afternoon. The registered peers were at 82.77.174.163, an IP in Romania and the calls were going to New Orleans.

First I blocked the IP address using webmin and the Linux Firewall. Then disabled nat on the extensions. The peers were no longer registered and I have 200 pages of call logs along with a bunch of irate calls coming from Louisiana as the robocalls had caller ID and went on until after midnight.

In a case like this your SIP secret doesn’t matter as it was discovered through a compromised M$ box on the Network. It is a big argument for getting SOHO customers to use Google Docs instead of an unmanaged Windows server. Having nat set on LAN extensions seems to have allowed this though. The remote extensions have not been used in about a month so they were not detected nor were two other office extensions as no one is using them although they are registered.

When they put in that server they removed the Microtik firewall as they could not get their server to work behind it.

This installation is about a year and a half old. Have there been any developments which make remote extensions more secure? Or is there a procedure in place that I have overlooked? Anything beyond the SIP secret?

It will be interesting when I get the bill from Broadvox. FreePBX shows about 6000 minutes but that includes all the time from dial to no answer.

Thanks for all the hard work.

30

My sympathies, trn7n8.

My suggestions are:

It is not just the SIP passwords that need to be secure, but anything that would give a person access.

  • The asterisk-box passwords, such as the Maintenance password.
    (otherwise an intruder can simply add extensions ans passwords)
  • The router (otherwise an intruder can change port routings)
    etc.

Also, you could change the port being used from 5060 to some obscure number. This would slow down a potential hacker, but do not count on stopping them.
(My router receives a hacker attempt about every 10-20 seconds, so you can do the math on how long it would take to scan all 65535 ports.)

I hope that helps