Now that you have set up your personal Asterisk® server (see Tutorial), it’s time to secure it. I can’t overstate the importance of this step. Without it, you could be leaving your server’s VoIP ports open for anyone on the Internet, which may cost you a lot of money.
Full article here:
Securing Your Asterisk VoIP Server with IPTables (Lin’s Tech Blog)
Just some notes on how to set up a Callcentric trunk in FreePBX and receive incoming calls without the need to create multiple trunks. This overcomes a limitation in Asterisk that is discussed in several other places (use a search engine if you really want to know).
Trunk settings:
When setting up the trunk use the following in the PEER details (change the highlighted parts):
type=peer secret=password qualify=yes insecure=port,invite host=callcentric.com fromuser=1777XXXXXXX fromdomain=callcentric.com disallowed_methods=UPDATE disallow=all directmedia=no defaultuser=1777XXXXXXX videosupport=no context=custom-from-callcentric allow=ulaw
And don’t forget to use a Register String (replace YYYYYYYYYY with your DID):
1777XXXXXXX:password@callcentric.com/YYYYYYYYYY
EDIT: Instead of using custom-from-callcentric as the context, in recent versions of FreePBX you can use from-pstn-toheader instead, and then skip the next step (the addition of the custom-from-callcentric context to extensions_custom.conf) entirely!
Add context to etc/asterisk/extensions_custom.conf:
In etc/asterisk/extensions_custom.conf add this context:
[custom-from-callcentric]
exten => _X!,1,Noop(Incoming Callcentric call)
exten => _X!,n,Set(CCDID=${CUT(CUT(SIP_HEADER(To),@,1),:,2)})
exten => _X!,n,Set(CDR(did)=${CCDID:1})
exten => _X!,n,Goto(from-pstn,${CCDID:1},1)
exten => h,1,Macro(hangupcall,)
Copy context to extensions_override_freepbx.conf and modify it:
Open etc/asterisk/extensions.conf in a text editor such as nano, and find the [from-sip-external] context. It will probably look like this, or something very close:
;-------------------------------------------------------------------------------
; from-sip-external
;
; This context is the default SIP context unless otherwise changed in the SIP
; Settings module or other sip configuration locations. This context is hit by
; either anonymous SIP calls or mis-configured SIP trunks when the incoming call
; can not be matched with a SIP section.
;
[from-sip-external]
exten => _.,1,NoOp(Received incoming SIP connection from unknown peer to ${EXTEN})
exten => _.,n,Set(DID=${IF($["${EXTEN:1:2}"=""]?s:${EXTEN})})
exten => _.,n,Goto(s,1)
exten => s,1,GotoIf($["${SIPLANG}"!=""]?setlanguage:checkanon)
exten => s,n(setlanguage),Set(CHANNEL(language)=${SIPLANG})
exten => s,n(checkanon),GotoIf($["${ALLOW_SIP_ANON}"!="yes"]?noanonymous)
exten => s,n,Goto(from-trunk,${DID},1)
exten => s,n(noanonymous),Set(TIMEOUT(absolute)=15)
exten => s,n,Log(WARNING,"Rejecting unknown SIP connection from ${CHANNEL(recvip)}")
exten => s,n,Answer
exten => s,n,Wait(2)
exten => s,n,Playback(ss-noservice)
exten => s,n,Playtones(congestion)
exten => s,n,Congestion(5)
exten => h,1,Hangup
exten => i,1,Hangup
exten => t,1,Hangup
;-------------------------------------------------------------------------------
Copy the entire context into etc/asterisk/extensions_override_freepbx.conf (without changing any other contexts that may already be there) and make the highlighted changes shown below. Don’t forget to replace the line number in the line that ends with “?checklang:noanonymous)” or things may break. EDIT: Replace custom-from-callcentric with from-pstn-toheader if you did not create the custom-from-callcentric context above:
;-------------------------------------------------------------------------------
; from-sip-external
;
; This context is the default SIP context unless otherwise changed in the SIP
; Settings module or other sip configuration locations. This context is hit by
; either anonymous SIP calls or mis-configured SIP trunks when the incoming call
; can not be matched with a SIP section.
;
[from-sip-external]
exten => _.,1,NoOp(Received incoming SIP connection from unknown peer to ${EXTEN})
exten => _.,n,Set(DID=${IF($["${EXTEN:1:2}"=""]?s:${EXTEN})})
exten => _.,n,Goto(s,1)
; Next 2 lines required to avoid adding 20 or so additional trunks just to receive CallCentric calls
exten => s,1,Set(FROM_DOMAIN=${CUT(CUT(SIP_HEADER(TO),@,2),>,1)})
exten => s,n,GotoIf($[${FROM_DOMAIN}=ss.callcentric.com]?custom-from-callcentric,${DID},1)
exten => s,n,GotoIf($["${SIPLANG}"!=""]?setlanguage:checkanon)
exten => s,n(setlanguage),Set(CHANNEL(language)=${SIPLANG})
exten => s,n(checkanon),GotoIf($["${ALLOW_SIP_ANON}"!="yes"]?noanonymous)
exten => s,n,Goto(from-trunk,${DID},1)
exten => s,n(noanonymous),Set(TIMEOUT(absolute)=15)
exten => s,n,Log(WARNING,"Rejecting unknown SIP connection from ${CHANNEL(recvip)}")
exten => s,n,Answer
exten => s,n,Wait(2)
exten => s,n,Playback(ss-noservice)
exten => s,n,Playtones(congestion)
exten => s,n,Congestion(5)
exten => h,1,Hangup
exten => i,1,Hangup
exten => t,1,Hangup
;-------------------------------------------------------------------------------
Note that every time you do a FreePBX upgrade you should open etc/asterisk/extensions.conf and make sure that the [from-sip-external] context has not been changed by the FreePBX upgrade. If it has, then you should make sure those changes get copied into the replacement context in etc/asterisk/extensions_override_freepbx.conf.
We’ve seen similar instructions that are more complicated than this (with regard to the added lines in the [from-sip-external] context) but we’ve been using this for a while and have found that it’s all you need – we’ve not seen any incoming Callcentric calls that have failed to be handled properly since we started using this.
Here is how to receive incoming faxes in the FreePBX Distro without spending $150 on their FaxPro module (which IMHO is severely overpriced, given that several other distros offer a comparable faxing solution for free, including Elastix and Incredible PBX, though I do not necessarily recommend either of those distributions for various reasons). It may be possible to do outbound faxing by installing Hylafax+ and AvantFax. (EDIT: If you read Russian, you could try following the instructions in this article – hint: Google Translate is your friend – but please do a full backup of your system first and be careful, because installing AvantFax in particular may overwrite a portion of your FreePBX GUI!).
If you only have the need to send an occasional outgoing fax, you can use FaxZero, which allows you to send up to three free faxes a day, with up to three pages in each fax. But, here is how you can easily receive incoming faxes in the FreePBX Distro.
First, create a new Virtual Extension:
Click Submit. When the next page appears, give the virtual extension a name and an extension number:
Now you must Submit the page and reload it, otherwise the fax settings will not appear. Now on that same page, fill in the fax settings. The Fax Email is the email address at which you wish to receive your faxes. I suggest using a PDF file as the output format:
Now Submit the page again.
EDIT FOR FREEPBX 14 AND NEWER VERSION USERS: The above is only partially correct for FreePBX 14. In that version, you must have the User Management module installed. Start out by creating a new Virtual Extension as shown above. Under the General tab, enter the User Extension and the Display Name, and make sure that in the User Manager Settings, Link to a Default User is set to Create New User. Under the Advanced tab, set Call Waiting to Disable. Click Submit. Go to User Management (under the Admin menu) and under Users find the newly created FAX user and click the edit button. Click the FAX tab and set Enabled to Yes, and Attachment Format to whatever you want (I suggest PDF). Then click the User Details tab and fill in the Email Address, and click Submit. Now continue on with the instructions below.
Next, create an Inbound Route using your FAX number as the DID Number. This can be any number coming into your system that is dedicated to FAX usage. In my experience, even a Google Voice number will work fine for this purpose most of the time. Do NOT set “Detect Faxes” to YES unless for some reason you want to use a single DID for both voice and FAX. If you can get a separate free DID just for receiving faxes, that’s far better than sharing a DID for both purposes. Instead, at the bottom of the page under “Set Destination”, select “Fax Recipient” from the dropdown and then the FAX extension you created:
Submit that page. Finally, you need to set an outgoing email address. Go to Settings and select Fax Configuration, then on the Fax Options page, fill in an Outgoing Email address (sender address) for faxes sent by your system. After doing that, go to the bottom of the page and click Submit, and only then should you go up and click the bright red Apply Config button. Don’t forget to Submit all your pages after making any changes or you’ll need to do them over!
Now you can have someone try sending you a test fax. They should send it to your DID and the call should be answered with FAX tones and after the fax is completed, it should automatically be sent to your specified email address (the one you chose when setting up the virtual extension) as a PDF attachment. If it doesn’t arrive in a reasonable time, check your spam or trash folders. Some email providers (Google, I am looking at you) seem to think that any incoming fax is a spam message. You may need to tell your email provider that such messages are “not spam”, or add the email address of your system as an “approved sender” or something like that. If you don’t find the fax in either your inbox, or your spam or trash mailboxes, it may be that your system is not properly configured to send email. That is another topic entirely and is beyond the scope of this article.
Note that the above has been tested on a recent version of the FreePBX Distro, but your experience may vary depending, on which version of the Distro you are using.
It is possible to build a small unexpensive box for making and receiving GSM calls and SMS. … When travelling outside the country, it is interesting to be reachable and be able to perform outgoing calls through VoIP without paying roaming fees. A Raspberry Pi can be transformed into a cheap VoIP box that routes VoIP/GSM calls in both sides (outgoing and incoming calls) as well as SMS.
Full article here:
Raspberry Pi B+ with Asterisk and chan_dongle on Arch Linux (AdeledA)
We do not normally provide security alerts but since we have several articles on this site dealing with tweaks to Asterisk and FreePBX, we thought we would just pass this along. If you are a FreePBX Distro user, go read this thread and this security notice now. You should particularly do this if you are noticing high CPU usage.
The problem is that there is an exploit in the FreePBX Distro caused by a piece of software that turns itself on when installed. Some users want it, but many have never heard of it and don’t use it, so it should be turned off by default. One side effect of this software is that it has given attackers a way to install and run bitcoin mining software on affected PBX’s, which can degrade performance and increase power consumption. It’s a simple fix to keep this from happening, so do it now!
One small problem with FreePBX/Asterisk installations is that if you deny anonymous inbound SIP calls (and you should be doing that to help keep your system secure), then any incoming calls on DIDs that don’t match one of your inbound routes will be quietly dropped, and will NOT appear in your CDR (call detail record). But maybe you’d like to see which DIDs calls are coming in on even if they are dropped, in case you have one or two DIDs that you don’t know about, particularly if you receive calls from multiple DIDs on the same trunks(s).
Normally, in your trunk configuration(s) you will have a line such as this:
context=from-trunk
All you need to do is change it so that it points to a custom context that you will place at the end of your existing /etc/asterisk/extensions_custom.conf file. So, you might change it to something like this:
context=custom-from-trunk
And then, at the end of /etc/asterisk/extensions_custom.conf …
[custom-from-trunk]
exten => _X!,1,TrySystem(echo “${EXTEN}” >> /var/log/dids)
exten => _X!,n,Goto(from-trunk,${EXTEN},1)
exten => h,1,Macro(hangupcall,)
This will write the DID of each incoming call to the file /var/log/dids. Note that if you have already changed the context statement in your trunks to point to a custom context for some other reason, you can just add the first line of the above context as a new line in that context (don’t forget to change the line number 1 to n if it’s not the first statement in the context).
Also note that before you apply the configuration changes, from a Linux command prompt you should do
touch /var/log/dids
to create the file and then either make it world-writeable, or change the ownership to asterisk. Otherwise Asterisk won’t have permission to write to the file and nothing will be saved.
Over time the log file might get a bit large and will have many duplicates. So whenever you want to look at it, just run the the following command (you could also put this in a cron job and run it once daily to keep the file from growing huge):
/bin/sort -u -o /var/log/dids /var/log/dids
This will sort the lines in numerical order and remove the duplicates.
Once you have done this, you can take a look at /var/log/dids now and then and see if any pop up that you didn’t know you had. Your provider might be deliberately or inadvertently “gifting” you with an extra DID, or you might be getting charged for a DID you aren’t using! Either way, it’s good to know what’s being sent to your system.
By the way, you can easily combine this with the hint given in How to show the source DID in FreePBX call detail reports – simply add the line
exten => _X!,n,Set(CDR(accountcode)=${EXTEN})
between the “TrySystem” line and the “Goto” line in the context shown above.
If you took the advice in the article, A possible way to thwart SIP hack attempts on your Asterisk (or other) PBX server, please be aware that an important note has been added:
IMPORTANT: Be sure to have a separate iptables rule (higher on the list than those above) that allows connections to port 5060 from devices on your local network. Otherwise, you may find that new extensions that you are adding for the first time will not register with your Asterisk server, or that after a system reboot, none of your local extensions will register!
Please take heed of that note, or you may be one power failure or reboot away from discovering that none of your local extensions are able to register with your PBX server.
Overview
Hangup handlers are subroutines attached to a channel that will execute when that channel hangs up. Unlike the traditional h extension, hangup handlers follow the channel. Thus hangup handlers are always run when a channel is hung up, regardless of where in the dialplan a channel is executing.
Multiple hangup handlers can be attached to a single channel. If multiple hangup handlers are attached to a channel, the hangup handlers will be executed in the order of most recently added first.
Full documentation page here:
Hangup Handlers (Asterisk Project)
Note: Hangup handlers were introduced in Asterisk 11, and therefore many long time Asterisk users may not be aware of this new feature. If you have always wanted your Asterisk server to perform some action at the time a call is hung up, a hangup handler might be the solution you have been looking for.
If you’ve had the problem of hackers trying to break into your Asterisk server, you probably know that you can use tools like Fail2ban to at least slow them down. But why let them know you even have an Asterisk server in the first place? Maybe you need to leave port 5060 open so that remote users (not on your local network) can connect to the server, but that doesn’t mean that you have to advertise to the bad guys that you might have something of interest. With that in mind, we direct your attention to this post in the DSLReports VoIP forum:
The Linux netfilter/iptables firewall is capable of stopping these attacks before they even start.
At a bare minimum, this stops 99% of the attacks when added to your iptables ruleset:
-A INPUT -p udp --dport 5060 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:your.pbx.dns.name" --algo bm -j ACCEPT
-A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:" --algo bm -j DROP
-A INPUT -p udp --dport 5060 -m string --string "OPTIONS sip:" --algo bm -j DROP
-A INPUT -p udp --dport 5060 -j ACCEPT
To understand how this works, read the original post by DSLReports user espaeth.
For another line of defense against such attacks, see the article Stop SOME SipVicious attacks from reaching your Asterisk, FreeSwitch, YATE, etc. PBX server.
Now that you have set up your personal Asterisk® server, it’s time to secure it. I can’t overstate the importance of this step. Without it, you could be leaving your server’s VoIP and SSH ports open for anyone on the Internet, which is a very bad idea and may cost you a lot of money.
Full article here:
Securing Your Asterisk VoIP Server with IPTables (Lin’s Tech Blog)
Recent Comments