Home » Posts tagged 'kamailio'

Tag Archives: kamailio

The Most Versatile VoIP Provider: FREE PORTING

SIP Happens! Deploying a Publicly-Accessible Asterisk PBX – replaced

blank

We’ve previously documented the benefits of SIP URI calling. Because the calls are free from and to anywhere in the world, the use case is compelling. The drawbacks, particularly with Asterisk® servers, have primarily centered around the security implications of exposing SIP on a publicly-accessible server. Today we want to take a fresh look at a possible SIP implementation for Asterisk based upon the pioneering work of Dr. Lin Song back in the PBX in a Flash heyday. We’ve embellished Lin’s original IPtables creation with additional security mechanisms now available with Fail2Ban, Asterisk, FreePBX®, and Travelin’ Man 3 as well as a terrific tutorial from JavaPipe. All of Lin’s work and ours is open source GPL3 code which you are more than welcome to use or improve pursuant to the terms of the GPL3 license.

Consider this. If everyone in the world had an accessible SIP address instead of a phone number, every call to every person in the world via the Internet would be free. That pretty much sums up why SIP URIs are important. The syntax for SIP URIs depends upon your platform. With Asterisk they look like this: SIP/somebody@FQDN.yourdomain.com. On SIP phones, SIP URIs look like this: sip:somenameORnumber@FQDN.yourdomain.com. Others use somenameORnumber@FQDN.yourdomain.com. Assuming you have a reliable Internet connection, once you have “dialed” a SIP URI, the destination SIP device will ring just as if the called party had a POTS phone. Asterisk® processes SIP URIs in much the same way as calls originating from commercial trunk providers, but anonymous SIP calls are blocked.

Before we get too deep in the weeds, let us take a moment to stress that we don’t recommend this SIP design for mission-critical PBXs because there still are some security risks with denial of service attacks and other vulnerabilities. For these deployments, Incredible PBX® coupled with the Travelin’ Man 3 firewall which blocks SIP access except from whitelisted IP addresses and FQDNs has no equal. When properly deployed, the bad guys cannot even see your server much less attack it. A typical use case for today’s new SIP design would be a public Asterisk server that provides anonymous SIP access to the general public without any exposure to corporate jewels. For example, we’ve put up a demonstration server that provides news and weather reports. In the corporate world, an equivalent deployment might provide access to a product database with pricing and availability details. Our rule of thumb before deploying today’s platform would be to ask yourself what damage could be inflicted if your server were totally compromised. If the answer is zero, then proceed. Otherwise, stick with Incredible PBX and the Travelin’ Man 3 firewall. The ideal platform for deployment using the same rule of thumb as above is one of these $7 to $15/year OpenVZ cloud platforms.

Overview. There are a number of moving parts in today’s implementation. So let’s briefly go through the steps. Begin with a cloud-based installation of Incredible PBX. Next, we’ll upgrade the Fail2Ban setup to better secure a publicly-accessible Asterisk server. We’ll also customize the port for SSH access to reduce the attack rate on the SSH port. You’ll need a fully-qualified domain name (FQDN) for your server because we’ll be blocking all access to your server by IP address. If you want to allow SIP URI calls to your server, you’ll need this FQDN. If you want to also allow SIP registrations from this same FQDN, then a single FQDN will suffice; however, with OpenVZ platforms, we recommend using a different (and preferably more obscure) FQDN for SIP registrations since registered users have an actual extension on your PBX that is capable of making outbound calls which usually cost money. In this case, the obscure FQDN performs double-duty as the equivalent of a password to your PBX. For example, an FQDN such as hk76dl34z.yourdomain.com would rarely be guessed by an anonymous person while sip.yourdomain.com would be fairly obvious to attempted intruders. But that’s your call.

Using whatever FQDN you’ve chosen for SIP registrations, we’ll add an entry to /etc/asterisk/sip_custom.conf that looks like this: domain=hk76dl34z.yourdomain.com. That will block all SIP registration attempts except from that domain. It will not block SIP invitations! The next step will be to add a new [from-sip-external] context to extensions_override_freepbx.conf. Inside that context, we’ll specify the FQDN used for public SIP URI connections to your server, e.g. sip.yourdomain.com. This will block SIP invitations except SIP URIs containing that domain name. We’ll also define all of the extensions on your Asterisk server which can be reached with SIP URI invitations. These could be actual extensions, or ring groups, or IVRs, or Asterisk applications. The choice is yours. These SIP URI authorizations can be either numeric (701@sip.yourdomain.com) or alpha (weather@sip.yourdomain.com) or alphanumeric (channel7@sip.abc.com). Finally, we’ll put the new IPtables firewall rules in place and adjust your existing iptables-custom setup to support the new publicly-accessible PBX. For example, we’ll still use whitelist entries for web access to your server since anonymous users would cause nothing but mischief if TCP ports 80 and 443 were exposed. It’s worth noting that KVM platforms provide a more robust implementation of IPtables that can block more types of nefarious traffic. We’ve supplemented the original article with a KVM update below. With OpenVZ platforms, we have to rely upon Asterisk to achieve IP address blocking and some types of packet filtering. So why not choose a KVM platform? It’s simple. These platforms typically cost twice as much as equivalent OpenVZ offerings. With this type of deployment, KVM is worth it.

Installing Incredible PBX Base Platform

Today’s design requires an Incredible PBX platform on a cloud-based server. Start by following this tutorial to put the pieces in place. We recommend you also install the Whole Enchilada addition once the base install is finished. Make sure everything is functioning reliably before continuing.

Upgrading the Fail2Ban Platform

Because this will be a publicly-accessible server, we’re going to tighten up the Asterisk configuration in Fail2Ban and lengthen the bantime and findtime associated with Fail2Ban’s Asterisk log monitoring. We also recommend that you whitelist the IP addresses associated with your server and PCs from which you plan to access your server so that you don’t inadvertently block yourself.

Log into your server as root and issue the following commands. When the jail.conf file opens in the nano editor, scroll down to line 34 and add the IP addresses you’d like to whitelist to the existing ignoreip settings separating each IP address with a space. Then press Ctrl-X, Y, then Enter to save your changes. Verify that Fail2Ban restarts successfully.

cd /etc/fail2ban
wget http://incrediblepbx.com/fail2ban-public.tar.gz
tar zxvf fail2ban-public.tar.gz
rm -f fail2ban-public.tar.gz
nano -w jail.conf
service fail2ban restart

If you ever get locked out of your own server, you can use the Serial Console in your VPS Control Panel to log into your server. Then verify that your IP address has been blocked by issuing the command: iptables -nL. If your IP is shown as blocked, issue this command with your address to unblock it: fail2ban-client set asterisk unbanip 12.34.56.78

Obtaining an FQDN for Your Server

Because we’ll be blocking IP address SIP access to your server, you’ll need to obtain one or perhaps two FQDNs for your server. If you manage DNS for a domain that you own, this is easy. If not, you can obtain a free FQDN from ChangeIP here. Thanks, @mbellot.

For the FQDN that you’ll be using for SIP registrations on your server, configure Asterisk to use it by logging into your server as root and issuing the following command using your new FQDN, e.g. xyz.yourdomain.com. Thanks, @ou812.

echo "domain=xyz.yourdomain.com" >> /etc/asterisk/sip_custom.conf

SECURITY ALERT: Never use the SIP URI MOD on a server such as this one with a publicly-exposed SIP port as it is possible for some nefarious individual to spoof your FQDN in the headers of a SIP packet and easily gain outbound calling access using your server’s trunk credentials.

Customizing the [sip-external-custom] Context

All FreePBX-based servers include a sip-external-custom context as part of the default installation; however, we need a customized version to use for a publicly-accessible PBX. You can’t simply update the context in /etc/asterisk/extensions.conf because FreePBX will overwrite the changes the next time you reload your dialplan. Instead we have to copy the context into extensions_override_freepbx.conf and make the changes there. So let’s start by copying the new template there with the following commands:

cd /tmp
wget http://incrediblepbx.com/from-sip-external.txt
cd /etc/asterisk
cat /tmp/from-sip-external.txt >> extensions_override_freepbx.conf
rm -f /tmp/from-sip-external.txt
nano -w extensions_override_freepbx.conf

When the nano editor opens the override file, navigate to line #10 of the [from-sip-external] context and replace xyz.domain.com with the FQDN you want to use for SIP invites to your server. These are the connections that are used to actually connect to an extension on your server (NOT to register). As noted previously, this can be a different FQDN than the one used to actually register to an extension on your server. Next, scroll down below line #24, and you will see a series of lines that actually authorize anonymous SIP connections with your server. There are two numeric entries and also two alpha entries to access the News and Weather apps on your server. The 13th position in the dialplan is required for all authorized calls.

exten => 947,13,Dial(local/947@from-internal)
exten => 951,13,Dial(local/951@from-internal)
exten => news,13,Dial(local/951@from-internal)
exten => weather,13,Dial(local/947@from-internal)

You can leave these in place, remove them, or add new entries depending upon which extensions you want to make publicly accessible on your server. Here are some syntax examples for other types of server access that may be of interest.

; Call VoIP Users Conference
exten => 882,13,Dial(SIP/vuc@vuc.me)
exten => vuc,13,Dial(SIP/vuc@vuc.me)
; Call Default CONF app
exten => 2663,13,Dial(local/${EXTEN}@from-internal)
exten => conf,13,Dial(local/2663@from-internal)
; Call Bob at Local Extension 701
exten => 701,13,Dial(local/${EXTEN}@from-internal)
exten => bob,13,Dial(local/701@from-internal)
; Call Default Inbound Route thru Time Condition
exten => home,13,Goto(timeconditions,1,1)
; Call Inbound Trunk 8005551212
exten => 8005551212,13,Goto(from-trunk,${DID},1)
; Call Lenny
exten => 53669,13,Dial(local/${EXTEN}@from-internal)
exten => lenny,13,Dial(SIP/2233435945@sip2sip.info)
; Call any toll-free number (AT&T Directory Assistance in example)
exten => information,13,Dial(SIP/18005551212@switch.starcompartners.com)

Once you’ve added your FQDN and authorized SIP URI extensions, save the file: Ctrl-X, Y, then Enter.

One final piece is required to enabled anonymous SIP URI connections to your server:

echo "allowguest=yes" >> /etc/asterisk/sip_general_custom.conf

Now restart Asterisk: amportal restart

UPDATE for DialPlan Junkies: We received a few inquiries following publication inquiring about the dialplan design. We’ve taken advantage of a terrific feature of Asterisk which lets calls fall through to the next line of a dialplan if there is no match on a Goto(${EXTEN},13) command. For example, if a caller dials ward@sip.domain.com and there is a line 12 in the dialplan directing the call to ward,13 which exists, call processing will continue there. However, if the extension does not exist, the call will not be terminated. Instead, if there exists a more generic line 13 in the dialplan, e.g. exten => _X.,13,Goto(s,1), call processing will continue there. We use this trick to then redirect the call to an ‘s’ extension sequence to announce that the called extension could not be reached. It’s the reason all of the whitelisted extensions have to have the same line 13 designation so that call processing can continue with the generic line 13 when a specific extension match fails.

Configuring IPtables for Public SIP Access

You may recall that, with Incredible PBX, we bring up the basic IPtables firewall using the /etc/sysconfig/iptables rules. Then we add a number of whitelist entries using /usr/local/sbin/iptables-custom. We’re going to do much the same thing with today’s setup except the rule sets are a bit different. Let’s start by putting the default iptables-custom file in place:

cd /usr/local/sbin
wget http://incrediblepbx.com/iptables-custom-public.tar.gz
tar zxvf iptables-custom-public.tar.gz
rm -f iptables-custom-public.tar.gz
nano -w iptables-custom

When the nano editor opens, scroll to the bottom of the file. You’ll note that we’ve started a little list of notorious bad guys to get you started. Fail2Ban will actually do a pretty good job of managing these, but for the serious recidivists, blocking them permanently is probably a good idea. In addition to the bad guys, you’ll want to whitelist your own IP addresses and domains so that you don’t get blocked from FreePBX web access to your server. The syntax looks like the following two examples:

/usr/sbin/iptables -I INPUT -s pbxinaflash.dynamo.org -j ACCEPT
/usr/sbin/iptables -I INPUT -s 8.8.8.8                -j ACCEPT

Whenever you make changes to your IPtables configuration, remember to restart IPtables using the following command ONLY: iptables-restart

Now let’s put the final IPtables piece in place with the default IPtables config file:

cd /etc/sysconfig
wget http://incrediblepbx.com/iptables-public.tar.gz
tar zxvf iptables-public.tar.gz
rm -f iptables-public.tar.gz
nano -w iptables

When the nano editor opens the file, scroll down to line 51 which controls the TCP port for SSH access to your server. We strongly recommend you change this from 22 to something in the 1000-2000 range. HINT: Your birth year is easy to remember. In the next step, we’ll make the change in your SSH configuration as well.

Next, scroll down to lines 143 and 144. Replace YOUR_HOSTNAME.no-ip.com on both lines with the FQDN of your server that will be used to accept SIP invitations (connections) on your server. These entries have no effect on SIP registrations which we covered above!

Once you’ve made these changes, save the file BUT DO NOT RESTART IPTABLES JUST YET.

Securing the SSH Access Port

TCP port 22 is probably one of the most abused ports on the Internet because it controls access to SSH and the crown jewels by default. Assuming you changed this port in the IPtables firewall setup above, we now need to change it in your SSH config file as well. Edit /etc/ssh/sshd_config and scroll down to line 12. Change the entry to: Port 1999 assuming 1999 is the port you’ve chosen. Be sure to remove the comment symbol (#) at the beginning of the line if it exists. Then save the file. Now reboot your server, and you should be all set.

Dealing with the Bad Guys

You’ll be amazed how quickly and how many new friends you’ll make on the public Internet within the first few hours. You can watch the excitement from the Asterisk CLI by logging into your server as root and issuing the command: asterisk -rvvvvvvvvvv. Another helpful tool is to monitor your IPtables status which will show IP addresses that have been temporarily blocked by Fail2Ban: iptables -nL. This will catch most of the bad guys and block them. But some are smarter than others, and many know how to spoof IP addresses in SIP packets as you will quickly see. Unlike on KVM platforms, IPtables on most OpenVZ platforms cannot search packets for text strings which is a simple way to block many of these attackers. HINT: You get what you pay for. And, in some cases, attackers disguise their address or use yours. We’ve now found that ${SIPURI} holds the caller’s true identity so we’ve updated the code accordingly. Whether to permanently block these guys is completely up to you. A typical SIP INVITE before such a call is dropped only consumes about 100 bytes so it’s usually not a big deal. You also can manually block callers using the Fail2Ban client with the desired IP address: fail2ban-client set asterisk banip 12.34.56.78.

Additional Security on KVM Platforms

As we mentioned above, a KVM platform provides considerably more security for your public-facing server because you can block entire countries using the ipset extension to IPtables. You can read all about it here. After considerable discussion and suggestions on the PIAF Forum, we would offer the following code which blocks the countries we have identified as causing the majority of problems. First, modify your /etc/sysconfig/iptables configuration and insert the following code in the IPSPF section of the script around line 93. You can change the list of blocked countries to meet your own needs. Just be sure to make the same country-code changes in the blockem.sh script which we will cover in step 2. A list of available country codes can be found here. Save your changes, but do NOT restart IPtables just yet.

-A IPSPF -m set --match-set cn src -j DROP
-A IPSPF -m set --match-set ru src -j DROP
-A IPSPF -m set --match-set ps src -j DROP
-A IPSPF -m set --match-set kp src -j DROP
-A IPSPF -m set --match-set ua src -j DROP
-A IPSPF -m set --match-set md src -j DROP
-A IPSPF -m set --match-set nl src -j DROP
-A IPSPF -m set --match-set fr src -j DROP

Second, we want to add a new /etc/blockem.sh script and make it executable (chmod +x /etc/blockem.sh). Make sure the country list in line #5 matches the dropped countries list you added to IPtables in step #1 above.

#!/bin/bash
cd /etc
wget -qO - http://www.ipdeny.com/ipblocks/data/countries/all-zones.tar.gz| tar zxvf -
for i in \\
cn ru ps kp ua md nl fr
do
/usr/sbin/ipset create -exist $i hash:net
for j in $(cat $i.zone); do /usr/sbin/ipset add -exist $i $j; done
done
wait
sleep 5
service iptables restart
wait
service fail2ban restart
exit 0

Third, try things out by running the script: /etc/blockem.sh. Verify that IPtables is, in fact, blocking the listed countries: iptables -nL.

BUG: Some early releases had a missing line which caused the IPSPF section of code in the IPtables script not to be executed. You can test whether you’re missing the necessary line by issuing the following command:

 grep "INPUT -j IPSPF" /etc/sysconfig/iptables

If the result is a blank line, then issue the following command to fix the problem:

sed -i 's|-A INPUT -j ASIP|-A INPUT -j IPSPF\\n-A INPUT -j ASIP|' /etc/sysconfig/iptables

Finally, we recommend adding the script to /etc/rc.d/rc.local so that it gets run whenever you reboot your server.

In choosing a KVM platform, we’ve had good luck with the $5/month Digital Ocean platform where you still can get a $100 credit to kick the tires for 60 days, Vultr (similar pricing to D.O. without the 60-day credit). With either of these providers, you can add automatic backups for an extra dollar a month. In the bargain basement (may not be here tomorrow) category, we like (and use) both the SnowVPS KVM $15/year and AlphaRacks KVM $22/year offerings. Many other low-cost options are documented on the LowEndBox site. Just don’t invest more than you can afford to lose… and make a backup.1

Connecting a SIP Phone to Kamailio or LinPhone

If you followed along in our initial Kamailio adventure, then it’s easy to test some SIP URI calls to your new server. You can connect virtually any kind of SIP telephone or endpoint to Kamailio. Another easy way to try out SIP calling is to first set up a free LinPhone SIP Account.

You can find dozens of recommendations for hardware-based SIP phones both on Nerd Vittles and the PIAF Forum. For today we’ll get you started with one of our favorite (free) softphones, YateClient. It’s available for almost all desktop platforms. Download YateClient from here. Run YateClient once you’ve installed it and enter the credentials for your Kamailio or LinPhone account you’ve previously created. You’ll need the IP address of your Kamailio server or LinPhone’s FQDN (sip.linphone.org) plus your account’s password. Fill in the Yate Client template using the IP address or FQDN as well as your Username and whatever Password you assigned to the account when you created it. Click OK to save your entries.

Once the Yate softphone shows that it is registered, try a test call to one of the SIP URIs you authorized on your new Asterisk server: sip:947@sip.yourdomain.com.

If you don’t happen to have a Kamailio server or a LinPhone SIP account to play with but you have another Asterisk server, then the simple way to enable SIP URI extensions is by editing /etc/asterisk/extensions_custom.conf. In the [from-internal-custom] context, add an extension that can be used to contact any desired SIP URI. Then reload your dialplan: asterisk -rx "dialplan reload". Now dial that extension (2468 in the following example) from any phone connected to your Asterisk server. The entry would look something like this to call the SIP URI on your new server for the latest weather forecast:

exten => 2468,1,Dial(SIP/weather@sip.yourdomain.com)

Originally published: Monday, January 28, 2019  Updated: Wednesday, February 6, 2019


blank
Need help with Asterisk? Visit the VoIP-info Forum.


 

Special Thanks to Our Generous Sponsors


FULL DISCLOSURE: ClearlyIP, Skyetel, Vitelity, DigitalOcean, Vultr, VoIP.ms, 3CX, Sangoma, TelecomsXchange and VitalPBX have provided financial support to Nerd Vittles and our open source projects through advertising, referral revenue, and/or merchandise. As an Amazon Associate and Best Buy Affiliate, we also earn from qualifying purchases. We’ve chosen these providers not the other way around. Our decisions are based upon their corporate reputation and the quality of their offerings and pricing. Our recommendations regarding technology are reached without regard to financial compensation except in situations in which comparable products at comparable pricing are available from multiple sources. In this limited case, we support our sponsors because our sponsors support us.

blankBOGO Bonaza: Enjoy state-of-the-art VoIP service with a $10 credit and half-price SIP service on up to $500 of Skyetel trunking with free number porting when you fund your Skyetel account. No limits on number of simultaneous calls. Quadruple data center redundancy. $25 monthly minimum spend required. Tutorial and sign up details are here.

blankThe lynchpin of Incredible PBX 2020 and beyond is ClearlyIP components which bring management of FreePBX modules and SIP phone integration to a level never before available with any other Asterisk distribution. And now you can configure and reconfigure your new Incredible PBX phones from the convenience of the Incredible PBX GUI.

blankVitalPBX is perhaps the fastest-growing PBX offering based upon Asterisk with an installed presence in more than 100 countries worldwide. VitalPBX has generously provided a customized White Label version of Incredible PBX tailored for use with all Incredible PBX and VitalPBX custom applications. Follow this link for a free test drive!
 

blankSpecial Thanks to Vitelity. Vitelity is now Voyant Communications and has halted new registrations for the time being. Our special thanks to Vitelity for their unwavering financial support over many years and to the many Nerd Vittles readers who continue to enjoy the benefits of their service offerings. We will keep everyone posted on further developments.
 



blank

  1. Digital Ocean and Vultr provide modest referral credits to Nerd Vittles for those that use our referral code. It in no way colors our recommendations regarding these two providers, both of whom we use extensively. []

SIP Happens! And Kamailio Makes It Easy, Part I


blank

If ever there was a Swiss Army Knife for SIP, Kamailio (a.k.a. OpenSER) is the hands-down winner. The flexibility of this open source SIP server is legendary. Whether it’s secure communications, insulation from brute force attacks, load balancing, failover, WebRTC, or the return of shared line appearances on your office phone system, Kamailio can handle it while processing thousands of call setups per second on minimal hardware platforms.

Our plan for today is to walk you through setting up a Debian-based Kamailio server on an inexpensive cloud platform that is suitable for making thousands of free SIP phone calls worldwide. Down the road, we’ll walk you through using Kamailio as a frontend for one or more Asterisk® servers to insulate your communications workhorses without sacrificing network security. If, like us, you managed an office which migrated from key telephones to a platform like Asterisk, then you will most certainly appreciate the ability to once again let your managers and secretaries share phone lines without the aggravation of call parking and pickup. Other than removing a free office coffee machine, I can’t think of any single event that ever prompted a staff and management revolt quite like the one we experienced with the removal of key telephones. Little wonder that it’s part of all Cisco and Avaya phone systems as well as cloud offerings from Vonage, 8X8, Jive, and probably others.

Before we begin our adventure, let me caution everyone that this is an experimental platform with a tutorial prepared by a Kamailio novice. While we’ve done our homework, digging out information on Kamailio is a challenge because many of the experts depend upon Kamailio consulting for their livelihood. It’s quite similar to the early Asterisk years. We also don’t vouch for the longevity of any of these VPS providers. Reread our article for details.

SIP URI (Free) Calling Opportunities

We mentioned free SIP phones in our introduction of Kamailio. But let that sink in for a moment. As we have stressed for many years, SIP calls to anyone with a public SIP URI (somebody@somewhere.com) are entirely free to anyone worldwide. And you can talk as long as you like. All that’s required is an Internet connection, a SIP phone or softphone, and a SIP URI. As part of the Kamailio implementation, we’ll show you how easy it is to create SIP URIs for all your friends and business acquaintances securely… in seconds. First, let’s take a moment to consider what SIP URI (free) calling opportunities are available. There literally are millions of SIP URI resources that await. But, unless you want to be one of the "don’t call us, we’ll call you" folks, you also will need one or more SIP URIs for yourself. YOU DON’T NEED A KAMAILIO SERVER TO OBTAIN A SIP URI. Here are just a few of the possibilities. Using SIP Broker, you can call anyone on more than 2,000 VoIP networks around the globe. Using a softphone and a free or almost free registration with VoIP.ms, CallCentric, or LocalPhone, you not only get a SIP URI, but you also can request an iNUM number which also doubles as a SIP URI by coupling it with @81.201.82.50. 3CX and pbxes.org also offer SIP URIs to complement their free offerings. All of these companies will let you connect a softphone or SIP endpoint directly to their service without the need for an Asterisk PBX in the middle.1 You can even refer your favorite spam callers to Lenny via SIP URI: 2233435945@sip2sip.info.

Deploying a Cloud-Based Debian Server

We hope you took advantage of one of the special VPS offerings we highlighted to start the New Year. Some are still available with annual pricing that’s less than the cost of most lunches these days. We recommend a cloud platform because (1) it’s cheap, (2) it’s easy to set up a Debian platform, and (3) it provides a static IP4 address for your server. When you sign up or if you wish to reconfigure an existing VPS that you may have gathering dust, just choose the Debian 8/64 operating system and assign an FQDN to your server. Once you get your credentials, log into the server as root with the password that was provided. Immediately change your root password and issue the following commands to bring Debian up to date. We also strongly recommend changing the SSH port to deter would-be attackers. A TCP port in the 1000-2000 range works wonders. Simply edit /etc/ssh/sshd_config and change the Port 22 entry before rebooting. HINT: Birth years make the SSH port easy to remember.

passwd
apt-get update
apt-key update
apt-get dist-upgrade
apt-get -y install gcc flex bison libmysqlclient-dev make libssl-dev nano
apt-get -y install libcurl4-openssl-dev libxml2-dev libpcre3-dev ntp ntpdate
reboot

Once the reboot is complete, log back into your server’s new SSH port using this syntax where 1234 is the port number you chose.

ssh -p 1234 root@server-ip-address

Now we’re ready to install the necessary packages to support Kamailio:

apt -y install mysql-server
mysql_secure_installation
apt -y install kamailio kamailio-mysql-modules
apt -y install kamailio-dbg
apt -y install kamailio-extra-modules
apt -y install kamailio-outbound-modules
apt -y install kamailio-presence-modules
apt -y install kamailio-tls-modules
apt -y install kamailio-utils-modules
apt -y install kamailio-websocket-modules

Configuring Kamailio’s kamctlrc File

For today, we’ll be configuring Kamailio to allow user logins from SIP endpoints including SIP phones and softphones. Down the road, we’ll change things up to let Kamailio serve as the front-end to one or more Asterisk PBXs. But let’s learn to walk before we start running. We’ll be editing three configuration files and then adding a SIP account to support logging in from a SIP phone. Let’s begin with kamctlrc.

(1) Edit kamctlrc: nano -w /etc/kamailio/kamctlrc

(2) Start by uncommenting SIP_DOMAIN and insert the FQDN you associated with your VPS.

(3) Uncomment DBENGINE line and make certain it points to MYSQL.

(4) Uncomment the following line: DBRWUSER="kamailio".

(5) Uncomment the DBRWPW line and insert your own password between the quotes.

(6) Uncomment the following line: DBROUSER="kamailioro".

(7) Uncomment the DBROPW line and insert a different password between the quotes.

(8) Uncomment the DBACCESSHOST line and insert the IP address of your server.

(9) Drop down near the bottom of the file and uncomment the PID_FILE line.

(10) Save the file.

Configuring Kamailio’s kamailio.cfg Startup File

(1) Edit kamailio.cfg: nano -w /etc/kamailio/kamailio.cfg

(2) Make the top of the startup file look like the following:

#!KAMAILIO
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_USRLOCDB
#!define WITH_ANTIFLOOD
#!define WITH_PRESENCE
# change next line to comment to disable logging
#!define WITH_ACCDB
#
# Kamailio (OpenSER) SIP Server v4.2 - default configuration script

(3) Find the line: #!define DBURL "mysql://kamailio:kamailiorw@localhost/kamailio"

(4) Change the kamailiorw entry to the password you entered in step #5 above.

(5) Tighten up security a bit by searching for the line containing friendly-scanner.

(6) Immediately above that line, cut-and-paste this addition from Fred Posner at AstriCon:

### Posner additions
        if ($ua =~ "(friendly-scanner|sipvicious|sipcli)") {
                xlog("L_INFO","script kiddies from IP:$si:$sp - $ua \n");
$sht(ipban=>$si) = 1;
                sl_send_reply("200", "OK");
                exit;
        }
        if($au =~ "(\=)|(\-\-)|(')|(\#)|(\%27)|(\%24)" and $au != $null) {
                xlog("L_INFO","[R-REQINIT:$ci] sql injection from IP:$si:$sp - $au \n");
$sht(ipban=>$si) = 1;
                exit;
        }
###

(7) Save the file.

(8) Generate the MySQL database and tables to support Kamailio: kamdbctl create

(9) At every prompt, type Y to add the feature.

(10) Open MySQL as root using the actual MySQL password you assigned when adding the MySQL package:

mysql -u root -ppassw0rd kamailio

(11) At the MySQL prompt, cut-and-paste the following commands:

ALTER TABLE acc ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT '';
ALTER TABLE acc ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT '';
ALTER TABLE acc ADD COLUMN src_ip varchar(64) NOT NULL default '';
ALTER TABLE acc ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT '';
ALTER TABLE acc ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT '';
ALTER TABLE acc ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT '';
ALTER TABLE missed_calls ADD COLUMN src_user VARCHAR(64) NOT NULL DEFAULT '';
ALTER TABLE missed_calls ADD COLUMN src_domain VARCHAR(128) NOT NULL DEFAULT '';
ALTER TABLE missed_calls ADD COLUMN src_ip varchar(64) NOT NULL default '';
ALTER TABLE missed_calls ADD COLUMN dst_ouser VARCHAR(64) NOT NULL DEFAULT '';
ALTER TABLE missed_calls ADD COLUMN dst_user VARCHAR(64) NOT NULL DEFAULT '';
ALTER TABLE missed_calls ADD COLUMN dst_domain VARCHAR(128) NOT NULL DEFAULT '';
quit

Configuring Kamailio Defaults in /etc/default/kamailio

(1) Edit Kamailio defaults: nano -w /etc/default/kamailio

(2) Make the startup defaults look like the following:

#
# Kamailio startup options
#

# Set to yes to enable kamailio, once configured properly.
RUN_KAMAILIO=yes

# User to run as
USER=kamailio

# Group to run as
GROUP=kamailio

# Amount of shared and private memory to allocate
# for the running Kamailio server (in Mb)
SHM_MEMORY=128
PKG_MEMORY=4

# Config file
CFGFILE=/etc/kamailio/kamailio.cfg

(3) Save the file.

Managing Kamailio Startups & Shutdowns

With all the pieces in place, here’s how to start, restart, stop, and check status of Kamailio:

systemctl start kamailio
systemctl restart kamailio
systemctl stop kamailio
systemctl status kamailio

Adding Users/Accounts to Kamailio

Now we’re ready to add accounts to Kamailio. These can be numeric, alphanumeric, or purely alpha entries. They become the user’s respective SIP URIs when coupled with @FQDN where FQDN is the fully-qualified domain name assigned to your server:

kamctl add username userpw

As you probably have guessed, kamctl is the main management tool for Kamailio. Issuing the command by itself will list all of the possible options that are available.

Monitoring Kamailio Access

There are a number of ways to monitor access (both legitimate and otherwise) to your Kamailio server. Here are a few of our favorites:

systemctl status kamailio
cat /var/log/syslog | grep kamailio
mysql -u root -ppassw0rd kamailio -e "select * from acc"
mysql -u root -ppassw0rd kamailio -e "select * from missed_calls"

Connecting a SIP Phone to Kamailio

You can connect virtually any kind of SIP telephone or endpoint to Kamailio. You can find dozens of recommendations for hardware-based SIP phones both on Nerd Vittles and the PIAF Forum. For today we’ll get you started with one of our favorite (free) softphones, YateClient. It’s available for almost all desktop platforms.

Download YateClient from here. Run YateClient once you’ve installed it and enter the credentials for the account you created above. You’ll need the IP address of your server plus your account’s password. Fill in the Yate Client template using the IP address or FQDN of your Server as well as your Username and whatever Password you assigned to the account when you created it. Click OK to save your entries.

Once the Yate softphone shows that it has registered with Kamailio, try a test call to Lenny by dialing sip:2233435945@sip2sip.info.

Next week, we’ll tackle security. If you run systemctl status kamailio for a few days, you’ll understand why. We’ll also get your Kamailio server interconnected with Asterisk so that inbound calls to your new SIP URI pass through to Asterisk transparently. Enjoy!

Originally published: Monday, January 14, 2019


blank
Need help with Asterisk? Visit the VoIP-info Forum.


 

Special Thanks to Our Generous Sponsors


FULL DISCLOSURE: ClearlyIP, Skyetel, Vitelity, DigitalOcean, Vultr, VoIP.ms, 3CX, Sangoma, TelecomsXchange and VitalPBX have provided financial support to Nerd Vittles and our open source projects through advertising, referral revenue, and/or merchandise. As an Amazon Associate and Best Buy Affiliate, we also earn from qualifying purchases. We’ve chosen these providers not the other way around. Our decisions are based upon their corporate reputation and the quality of their offerings and pricing. Our recommendations regarding technology are reached without regard to financial compensation except in situations in which comparable products at comparable pricing are available from multiple sources. In this limited case, we support our sponsors because our sponsors support us.

blankBOGO Bonaza: Enjoy state-of-the-art VoIP service with a $10 credit and half-price SIP service on up to $500 of Skyetel trunking with free number porting when you fund your Skyetel account. No limits on number of simultaneous calls. Quadruple data center redundancy. $25 monthly minimum spend required. Tutorial and sign up details are here.

blankThe lynchpin of Incredible PBX 2020 and beyond is ClearlyIP components which bring management of FreePBX modules and SIP phone integration to a level never before available with any other Asterisk distribution. And now you can configure and reconfigure your new Incredible PBX phones from the convenience of the Incredible PBX GUI.

blankVitalPBX is perhaps the fastest-growing PBX offering based upon Asterisk with an installed presence in more than 100 countries worldwide. VitalPBX has generously provided a customized White Label version of Incredible PBX tailored for use with all Incredible PBX and VitalPBX custom applications. Follow this link for a free test drive!
 

blankSpecial Thanks to Vitelity. Vitelity is now Voyant Communications and has halted new registrations for the time being. Our special thanks to Vitelity for their unwavering financial support over many years and to the many Nerd Vittles readers who continue to enjoy the benefits of their service offerings. We will keep everyone posted on further developments.
 



blank

  1. Some of our links refer users to sites or service providers when we find their prices are competitive for the recommended products. Nerd Vittles receives a small referral fee from these providers to help cover the costs of our blog. We never recommend particular products solely to generate commissions. []