1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. Check out the 6 new Certified Incredible PBX Builds for Asterisk 11 and 13 featuring CentOS 6, Ubuntu 14, Raspberry Pi 2, and Asterisk-NOW.
    Dismiss Notice

HowTo Secure Your VoIP System while still allowing external access

Discussion in 'Add-On Install Instructions' started by sunshinenetworks, Nov 15, 2010.

  1. Dear forum readers,

    We have recently added a how-to article on our website which explains a new and easy way to secure your VoIP server while still allowing external access into your Asterisk server. We have been using it for quite a while for our customers and it works like a charm. It doesn't rely on other packages or daemons either, just iptables which is included in most Linux distributions. Any comments are appreciated, and if you like our articles, please thank us by pressing "like" in the article.

  2. wardmundy

    wardmundy Nerd Uno

    Excellent article! Can't wait to try your two tips. Assuming it all works, it should be extremely easy to at least build both techniques into Incredible PBX.

    Keep in mind that, if you implement Tip #1, you also will need to adjust the 5000:5082 entry in /etc/sysconfig/iptables and restart IPtables: service iptables restart
  3. jrglass

    jrglass Guru

    I trying to implment #2 and have a couple of questions.

    1 Are the /32; /32;/24 at the end of the ip addresses the number of allowed connectiontion, if not what are they?

    2 If I need to add more passwords later do I repete the whole process? How would I reset the firewall back to the default PBXIAF settings.


  4. jtjacobs

    jtjacobs New Member

    Great Article!

    Jeff -

    1. depending on which line you are talking abotu the /32; /32;/24 are the number of bits in your VOIP providers network or the network your Asterisk Server sits in. /32 = ( only 1 IP Address/host) where /24 = ( 254 IP Addresses/hosts)

    2. Yes - repeat the first lines were the passwords are added - this is covered in the original article about 2 paragraphs below the section of code.

    Hope this helps!
  5. I have removed the first step ( the port changing part ) since it's covered in another article and confused some forum readers. The article has been updated and now should be easier to read. Thanks for the kudos, it's appreciated.
  6. blanchae

    blanchae Guru

    These are called subnet prefixes and a "shortcut" for displaying the subnet mask. An IP address consists of 32 bits and so does the subnet mask. Each number is represented by 8 bits. For example, - it takes 8 bits to represent 192, another 8 bits for 168, one more for the 1 and finally another 8 bits for the 0. In total 8+8+8+8 = 32 bits

    The subnet mask for this network is We can describe the network as

    This is where your binary expertise comes in. 1111 1111 in binary is equal to 255 in decimal. To make it easier to read, the 8 bits are grouped in 4s (nibbles). So is equal to
    1111 1111.1111 1111.1111 1111.0000 0000 or if we count the number of 1s (there's 24), we can represent the network using the prefix as

    If you get into subnetting a network using variable length subnet masks (VLSM) then you use the prefix as it allows you to easier describe and create classless (VLSM) networks vs. classfull (Class A, B and C) networks .

    If you want to learn more about TCP/IP and how to create classless subnets using VLSM, you can visit my online book that I wrote called Introduction to Data Communications.
  7. Lost Trunk

    Lost Trunk Guru

    I think I get the general idea of what's being done here, but if I wanted to implement this, I can't change the display name on all my non-local SIP devices at the same time. I'm pretty sure they do all have a display name set, and I see it's possible to use multiple display names, but is there any easy way to show the existing display name that's currently being sent from each external device before you implement this? That way, you could temporarily add those names as allowed "knocks" until you can set them to something perhaps a bit more obscure, or you could just keep using the current name as the knock password, assuming I understand the principle behind this.

    My other question is a bit more obscure, but if you have been using Webmin to manage iptables (via the Linux Firewall module), then will adding rules from the command line as is needed to use this method mess that up? Reason I ask is because next to the "Apply Configuration" button in Webmin's module, it says, "Click this button to make the firewall configuration listed above active. Any firewall rules currently in effect will be flushed and replaced." There is also "Revert Configuration" button, which says "Click this button to reset the configuration listed above to the one that is currently active." So maybe if Webmin users do apply the changes from the command line they would still need to go into Webmin's Linux Firewall module and "Revert Configuration" if they don't want those changes to be lost? I'm asking because I'm not sure exactly how Webmin handles that, and hoping someone is more familiar with how that particular module works than I am.
  8. blanchae

    blanchae Guru

    With Webmin's Linux Firewall, I've completely changed the /etc/sysconfig/iptable file and when I opened up Webmin's Firewall, the changes were there. There's no separate file for Webmin's Firewall, it reads the iptables file. So as long as it is closed, you can modify iptables to your heart's content.
  9. Lost Trunk

    Lost Trunk Guru

    Hmmm… maybe I'm missing something, but earlier today I ran Ward's script that blocks a bunch of known offending IP addresses from that other thread, and when I went into Webmin it didn't show any of them. I suspect Webmin actually does have its own database separate from the iptables file, but if you click Revert Configuration it will bring import whatever rules are currently in use (I'm thinking that might not be the thing you want to do after running Ward's script, at least not without restarting iptables first so you don't import that entire list). But I could be wrong.

    Still hoping someone can tell me if there's a way to see the existing display names being sent by the endpoints.
  10. You could enter the following command in your SSH prompt:
    # grep "From: " /var/log/asterisk/full

    or, to display only unique values ( easier reading ) :

    # grep "From: " /var/log/asterisk/full|cut -f1 --delimiter=\; | sort -u

    That will show you all the display names being sent to your server.

    edit : As lost trunk said hereunder, you will need to turn on sip debugging on your Asterisk server first for a few hours / days. To turn sip debugging on :
    # asterisk -rx "sip set debug on"
  11. Lost Trunk

    Lost Trunk Guru

    Thanks, sunshinenetworks. I tried your method and at first it didn't return any results, so I opened up the CLI and started sip debugging ("sip debug") and let that run for a while (long enough for all the connected devices to re-register), then turned sip debugging back off ("sip no debug"), and then your command worked. One thing I did notice is that some user names are sent enclosed in quotation marks and some are not - it seems to be a device specific thing, but I assume that makes no difference. I was going to try your method but then started having problems with Firefox that ultimately resulted in me having to reboot my system, and after that one thing led to another, so, maybe later today or tonight.
  12. I like this idea and appreciate the How To article that you posted but, I have a correction as well as questioning your technique.

    First of all, you state that the Display Name field is used only internally within your Asterisk server. This is not entirely correct. The Display Name field is used within your Asterisk PBX system as a form of caller ID. Furthermore, depending on how your system is configured and what connection methods are in use, it is possible to send Display Name between disparate systems. It is part of the SIP URI. The contents of the Display Name field is also displayed on the screen of recipient extensions, as a caller ID, unless it is overridden by the server's extension configuration.

    You suggest the use of something like "SIP-Header-Request" in the Display Name field as a method of concealing the "password" from those that might be sniffing the network. But, I see this as being more suspicious than putting a real display name such as a phone number or a person's name in the Display Name field. Looking at a packet capture, I would find it far more suspicious to see SIP information in the Display Name where I would expect to see "Tom Jones" or "Front Desk". My users would also find it annoying to see "SIP-Header-Request" displayed on their phone every time they receive an internal call.

    I think that you could still use the technique as yet another layer on top of an already well secured system. But, I'd put Tom Jones in the Display Name field as the port knock "password".

    Is there something wrong with my thinking or is there something that I missed?
  13. Lost Trunk

    Lost Trunk Guru

    Astrosmurfer, there are a couple things wrong. First, the information in that field is overridden by the name you use when you configure the extension in FreePBX. So users should never see what you put in there under any circumstances, unless perhaps you fail to set the Outbound CID field in the extension's configuration.

    And second, I think the fake header is only there to confuse anyone who may be packet-sniffing, which more than likely is not going to happen anyway, but if they do and they aren't very familiar with how sip packets are constructed, the knock string will look like random gibberish to them, and get lost in a sea of other sip packets. But feel free to use what you like, it's your system.

    I have discovered a couple of other issues, though, when trying to set this up with a softphone (Zoiper). First, if you make the name (Caller ID Name, as Zoiper calls it) too long (I'm guessing longer than 15 characters), Zoiper won't send it or won't send all of it. Since in the USA the maximum Caller ID name length on the PSTN is 15 characters, you may encounter devices or clients that won't let you use a string longer than that.

    And second, in addition to SIP, Zoiper supports the use of IAX protocol, but the knock doesn't as written - it's SIP only. And yet IAX is actually a very good choice for a softphone to avoid firewall issues, and I've heard there's even a couple of commercial VoIP adapters that support IAX. But unlike SIP, I cannot find anyplace that IAX2 protocol sends the client's Caller ID name, so maybe this won't work for IAX?
  14. In my experience it is very common, if not most common, for the Outbound CID field to be blank in Asterisk extension configurations. It is, after all, an optional setting. So, saying that "users should never see" it is not an accurate or probable statement.

    With regard to your second statement; you are making my point. For someone aware enough to sniff a VoIP session and know that a string may or may not be valid, the string "SIP-Header-Request" will look very out of place in a CID field as compared to a name or number. My point being that while the stated intent is obfuscation, the result is actually that additional attention is drawn to the non-standard contents of a CID field.

    The 15 character limit that you describe would certainly make sense because of the PSTN CID limitations that you described.

    I don't have an answer for you regarding a usable field for IAX2 port knocking. However, since there are so few IAX hardphones, it is most likely that your IAX clients will be software running on a PC. In this case, standard port knocking is trivial. A series of telnet or ping commands, entered manually or replayed via script, can be used on the client to open the IAX2 port.
  15. Lost Trunk

    Lost Trunk Guru

    I have never, ever left the Outbound CID field blank when configuring an extension. If you do, then maybe this method isn't for you.

    On the second point, all I can say is I disagree with you. You believe what you want, it doesn't make it so. And in any case, I really don't think packet sniffing is the huge threat that anyone needs to be worried about. Everyone talks about it, but how often have you heard of a confirmed case of packet sniffing leading to an attack? And if someone can sniff the packets and extract the password you're kind of screwed anyway, and if someone had that kind of ability I'd think they'd probably try to hack into accounts on commercial VoIP providers. I'm not saying the danger is zero, but I disagree that using a confusing string that might cause a "script kiddie" to doubt what they're seeing is going to make you any more likely to be hacked. But hey, it's your system, do what you want - you apparently do anyway, if you're leaving the Outbound CID field blank. If this method isn't for you, then just leave it be. Or, put in the real user names and then put in lines to accept each of them, if that's what floats your boat. Either way, the thing this will stop is brute force attacks, in case fail2ban is misconfigured or you restart iptables for some reason and forget to also restart fail2ban.

    As for trying to get users to run an additional script - well, it's kind of why I was a bit skeptical of the Travelin' Man approach - it's not that it doesn't work, in fact I'm sure it works perfectly, but that there are some users (your boss or your parents, perhaps) that will barely be able to figure out how to run the softphone, and you throw ANY additional complexity at them and they just won't use it (and will then complain that your system isn't as easy to use as Skype!).
  16. chemcat9

    chemcat9 Guru

    Ward/Development Team,

    Have you tested this method yet? Will you be updating the Incredible in the short term with it?


  17. I sense condescension from you. Is that intended? Naturally, I don't feel that it is warranted.

    Regarding outbound CID on the extension, I think it's great that you are so thorough as to never leave it blank. But, I can tell you from a great deal of experience(I see lots of other people's setups) that many/most people leave it blank. (Perhaps we could get a show of hands in the thread?) It is an optional field so, we cannot use absolutes like "never" when it is indeed perfectly possible or likely for the field to be blank.

    With regard to the threat from sniffing, I would argue that it is a very real threat. While we can never be sure of what individuals may be doing as they skulk around in public spaces, we do have a fair bit of evidence to look at. Numerous past malware "products" have dropped sniffers on the infected host. The sniffers are usually targeted, looking for specific information and there's no reason to believe that our favorite Chinese SIP hackers won't get around to trying that approach if and when they get tired of brute forcing everyone's PBX.

    Recently, a Firefox plugin called Firesheep was released to the masses. It sniffs cookies from social networking sites and allows those running Firesheep to login to other people's accounts. This isn't some complex attack or obscure script kiddie app. It's a Firefox plugin that hipsters are actively using to "hack" each other's Facebook accounts. The sniffing threat is real and pervasive even if it hasn't targeted SIP accounts yet.

    Regarding the added complexity of a script to port knock, I agree here. It is added complexity and added opportunity for failure. Indeed, Travelin' Man is a non-starter for that very reason. The added steps of going to a website first and then starting your app are too cumbersome both to setup and to use on a regular basis.

    Regarding the complexity of additional user actions; from my own anecdotal experience, Mom and Grandma are not the targeted users of Asterisk homed softphones. It's usually corporate types who are accustomed to certain procedures for remote operations. These people are often trained to bring up a VPN tunnel before starting their apps. Which makes all of this conversation moot. I've always felt that VPNs are the right choice but, they are less viable for a hardphone. But, in the few cases where I might use port knocking with a softphone, I'd put my port knock script in a batch or bash file that then also calls the softphone app. It is then a single click of the desktop icon for the user to port knock and start the softphone.

    As for the greater complexity over Skype; no SIP based telephony solution will EVER be as easy to use as Skype. Even a single click ringdown scenario will still suffer at the hands of NAT and firewalling while Skype easily dances through these hoops. If the viable choices are SIP/Asterisk and Skype, Skype will always be the hands down winner in the ease of use arena.

    That brings up another elephant in the room but, I'll start a new thread for that one.
  18. I agree, the "Display Name" is not the ideal place to place such a knock, but in the Yealinks it's one of the few customizable places.

    If you can change the UserAgent that the phone sends, or any other value you can come up with, like user-defined SIP strings that's better.

    I have updated the HowTo to show how an SPA504G can be configured to use the UserAgent string ( which really isn't used anywhere in Asterisk ) instead of the Display Name for SunshineNetworks knocking.
  19. Lost Trunk

    Lost Trunk Guru

    Not intended, it's just that this whole discussion frustrates me greatly. I think that any security measures should be implemented on the system side, and should not degrade the users' experience in any way. I don't see Travelin' Man as a viable solution, and I'm not real happy about the whole whitelist thing in the other thread. I think this is a case of "the good is the enemy of the best." I'll probably get stoned for saying this, but sometimes I see a tendency to release software that is "just barely good enough" and then leave it in that state. Doesn't matter if it delays calls going through, or requires users to jump through hoops, if it works at all let's move on to other things and not spend an extra few minutes or few hours to do it right.

    To me, the SunshineNetworks Knock is an example of a great solution - it's easy to implement and once set up, users don't have to do or single thing or know how it works. I think there could be other great added layers of security, and it frustrates me that I'm not a coder so I can't write some of them myself (I'd definitely pursue my geographic restriction idea, for one thing - even if nobody else would use it, I would).

    The other thing I notice is that in this forum there is a level of paranoia about security that I don't see anywhere else (I don't hang out on security-related sites, obviously). I know there are systems out there that have far less security than you would find in the Incredible PBX and yet have never sustained a successful attack. I'm certainly not against any reasonable security measure (reasonable being easy to implement, and never cutting off users' service unexpectedly, and never requiring users to do anything other than pick up the phone to make a call). I happen to think VPN's are a great idea for many reasons - they encrypt conversations, they solve a multitude of firewall-related issues, and they are inherently far more secure than a SIP connection. I wish we could get Linksys/Cisco to release firmware updates for their products that would include an OpenVPN client (if they needed additional firmware memory, they could remove some of the codecs that hardly anyone uses). It seems to me like a huge fail on the part of VoIP adapter manufacturers that they seem to care so little about security, but that's another rant altogether.

    Still, sometimes I feel like Ward and a few others carry on like scolding nannies about security. I realize that VoIP system do get hacked, but as I said in another post, there's a difference between a reasonably cautious "belt and suspenders" approach to security, and an overly paranoid "suit of armor" approach, where you have the system locked down so tight that no one wants to use it.

    It occurs to me that Ward and the FreePBX developers and similar people in their shoes might have enough clout to talk to the people at Linksys/Cisco, Grandstream, and so on, and try to get them to include an OpenVPN client in their adapters. I think a couple of SIP phones (not adapters) already have that capability. I think right now, something like that would be the very best approach to this problem. It's too bad no one's ever managed to hack the PAP2 firmware (similar to what's been done with OpenWRT and Tomato for routers) and made some needed improvements, of which OpenVPN capability might be one.
  20. wardmundy

    wardmundy Nerd Uno

    We experiment with all sorts of security solutions and attempt to implement the best ones based upon many of the factors you have identified. There are basically three kinds of systems:
    1. Server and all of the phones are behind a hardware-based firewall
    2. Server is behind a hardware-based firewall but some or all of the phones are exposed to the Internet
    3. Server and the phones are exposed to the Internet
    We have a lot of new users on the forums. Hopefully, they will start with #1 and Incredible PBX. It is rock-solid secure because of a hardware-based firewall, random passwords, IPtables, and Fail2Ban.

    The #2 option primarily involves business users. VPNs make sense here, but they are enormously complex to set up and operate. Believe me. I deployed hundreds of them in the federal courts, but I had a huge budget and lots of staff. If that's your environment, by all means go for it.

    Finally, there are many new users that want to try the #3 hosted solution because it's easy and inexpensive. This posed enormous risks because Incredible PBX wasn't designed to operate in this environment. Yes, I'm paranoid about security. And there's nothing worse than someone deploying a system they think is secure when it really isn't.

    The BlackList approach was an effort to provide some insulation for these folks. And the WhiteList option restores absolute security when used in conjunction with Travelin' Man for remote phones. It may not be perfect, but it's unobtrusive and simple to deploy and use. When something better/simpler/safer comes along, we'll jump on it.

    In the meantime, lumping all these types of systems into one big pot and whining that we worry too much about security glosses over lots of very real security issues that have cost end-users and businesses millions of dollars. There's nothing wrong with going back to 1234 for all of your extension passwords if you have a big bank account and like to help other folks out with free calls. :crazy:

Share This Page