In this article we’ll focus on how to secure a basic sipXcom installation and walk you through how to configure sipXcom firewall settings. Securing a system doesn’t just mean locking it down. What we’re really talking about here is protecting the system from traffic that can interrupt the system from operating the way it should.

First, run your servers behind a standard firewall to off-load the brunt of the traffic from the internet. You wouldn’t put your file servers directly on the Internet, why would you put your communications system on the internet?

Block only traffic that needs to be allowed inbound. If you don’t have remote users, that means everything except maybe traffic inbound from a SIP Trunk provider. Firewall products such as pfSense ( or various Cisco ASA firewalls do an excellent job of protecting your server. For most firewalls you’ll want to disable any sort of “SIP helper” or SIP ALG (application layer gateway).

Remote users can be anywhere on the internet. That doesn’t mean that you need to open up your server however to the entire Internet. For instance, do you have users traveling to China? If not, why not block all traffic from China? You can do this with Country blocking features in pfSense (pfBlocker – Here’s a good blog post  –

A Session Border Controller can be thought of as a SIP firewall. It knows how to inspect SIP traffic and send it along or block it or even rate limit it. We also use them to terminate SIP Trunks from providers so that SIP packets can be manipulated at ingress and egress to provider interoperability. These are incredibly useful tools when you’re trying to protect your communications assets from the Internet (or even from your own internal network).

Something like this design is the ultimate in best practice for securing a communications system deployment:

sipxom diagram1


In the above scenario, the communication servers are protected by SBC’s connecting to the ITSP, roaming users on the Internet and also from the internal phone network. SBC’s can rate limit and shield the servers from bad actors as well as misconfigured devices.

Best practices are great, everything shy of that is a compromise of one sort or another (cost/benefit/etc.), but the following is where many installations start…

In the following sections we’ll explore settings that are relevant to the ‘less than Best Practices’ diagram shown above.

External Firewall Settings for SIP Trunks

sipXbridge is the internal trunking service that handles the SIP Signaling for trunks (it knows how to do this from System -> NAT Settings, we recommend static setting here with the NAT’d address of the server for outside the firewall). Media Relay is the service that rewrites media traffic (it knows how to do this from System -> Internet Calling).

If you are running a clustered system, a Session Border Controller is required to handle this traffic. The NAT Traversal only works for single systems.

SIP Trunk to sipXbridge for IP secured SIP Trunks:

Port 5080 UDP (SIP Signaling for Trunk inbound)

Ports 30000-31000 UDP (Media Relay)

SIP Trunk to sipXbridge for Dialog based SIP Trunks (trunk must login):

Nothing required to be open. The act of logging in will open the proper ports in the firewall and the keepalive will keep those ports open. This is what firewalls do…

SIP Trunk to SBC:

No outside ports from the Internet are required to be open to Uniteme servers for this. All of the trunking traffic would be directed at the SBC’s outside address and routed to Uniteme on the SBC’s internal IP address (assuming that your SBC lives with one leg outside and one leg inside).

External Firewall Settings For Remote Users

SIP Phones

If you are running a clustered (multi-server) system, a Session Border Controller is required to handle this traffic. The NAT Traversal only works for single server systems.

Remote User SIP Phone and no SBC:

Port 5060 TCP and/or UDP (SIP Signaling)

Ports 30000-31000 UDP (Media Relay)

Remote User SIP Phone and SBC:

No outside ports from the Internet are required to be open to Uniteme servers for this.

Phone Provisioning

Phone provisioning can occur over HTTP, HTTPS or FTP. We recommend limiting this to HTTPS for remote users.

Remote Phone requiring Provisioning:

Port 443 TCP (https)

User Portal

We recommend only allowing https traffic to the server for remote access to the User Portal. If users are using User Portal with Instant Messaging, XMPP ports must be opened as well.

Remote User requiring User Portal:

Port 443 TCP (https)

Remote User requiring Instant Messaging through User Portal:

Port 7443 TCP (Setting from System -> IM Settings -> Advanced -> HTTP Binding Secure Port)

XMPP Instant Messaging

If users need XMPP for a third-party XMPP client you’ll need to consider opening the following ports.

Port 5222 (XMPP)

Port 7777 (File Transfer Proxy)

Port 5269 (Server to Server Federation – Only if required for your server to connect to other XMPP servers, if not needed, don’t open it)

sipXcom Internet Calling Settings

The sipXcom system has a small integrated SBC. The Media Relay service handles the rewriting of IP addressing in SIP and media packets to send outside IP address to the ‘outside world’.

The Media Relay service only operates in single server networks. If you have a clustered environment you’ll need to utilize a third party Session Border Controller.

Define the Internal IP Address Space

In System -> Internet Settings, narrow down the Internal IP ranges to all of your IP addresses that are considered internal to your network (i.e., addresses that do not NAT). These settings are used by the Media Relay service to know when to route packets out to the Internet.

Set The External IP address of the System

In System -> NAT Traversal set the server’s NAT Config to Static IP and assign the IP address that the Server is NAT’d to on your Firewall. This tells Media Relay what IP Address to convert internal IP Addresses to.

Set Firewall Settings

We won’t go over about Rules and Groups, they are discussed in the system settings section of the wiki.

Standard warning here… Beware! Here be dragons… System -> Firewall -> Settings -> Show Advanced

The White List should only contain addresses you want to absolutely be able to get to the system from. If your firewall settings use automation and block your PC from access, you are blocked for all ports. Also, if you whitelist an IP that IP can get to all ports on the server. So, populate this list sparingly, but deliberately. This is your back door if you don’t have console access.

The Deny packets matching field is very powerful. It can be used to block certain User Agents from trying to connect to the server. The firewall searches each packet user agent and blocks IP’s that send UA data that contain these UA’s.

VaxSIPUserAgent/3.1,VaxSIPUserAgent,sipcli/v1.8,CiscoSystemsSIP-IPPhone,Cisco/SPA504G-7.4.9c,one-X,pplsip,eyeBeam,friendly-scanner,eyeBeam release 3006o stamp,sipcli,UsaAirport

You can use this list as a good starting point for User Agents that we’ve found should be blocked:

Enable all of the ‘Log” checkboxes to get logging configured the way we need.

Set Max entries to 6000 (this will keep the log from consuming the server disk space if the server is being attacked).

Call Rate Limits

Call Rate Limits will limit a particular type of SIP traffic from specific IP addresses. We would recommend setting up Call Rate Limits for all IP address ranges. You may need to adjust them for your users and your network. You’ll also want to ignore your SBC’s and gateway devices in the System Security settings. SBC’s should be set up properly to limit the rate of SIP messages forwarded through to Uniteme.

Setup the call rate limit IP Range in System -> Firewall -> Call Rate Limit.


If you already have one, click on it, if not, click on Add Call Rate Limit.

On the subsequent page, you’ll enter a name for the range, a description and then the starting and the ending IP address of the range.

Next, you Add Limits for each SIP Method and the rate at which you’d like to trigger on. The action taken is configured in System -> Security.



On each SIP Method rate limit, you’ll want to configure a sensible rate for each IP address in that range. For example, set up to watch REGISTER at 15 per minute, INVITE at 10 per minute and SUBSCRIBE to 20 per minute, Options at 10 per minute and ACK at 20 per second. These settings are not good for a remote firewall with 20 phones behind it but would be sufficient for a home user with 2 or 3 hard/softphones. You’ll have to adjust these rates to suit your user base and then maybe create other zones for remote offices that don’t connect to the server through a VPN tunnel (if through a VPN, they would be considered an Internal Address and would not go through NAT Traversal settings).

With the above settings, the following rules will then be established in iptables:


target     prot opt source               destination

Internet   tcp — anywhere             anywhere    tcp dpt:sip source IP range state NEW,ESTABLISHED

Internet   tcp — anywhere             anywhere    tcp dpt:sip-tls source IP range state NEW,ESTABLISHED

Internet   udp — anywhere             anywhere   udp dpt:sip source IP range state NEW,ESTABLISHED

Internet   tcp — anywhere             anywhere     tcp dpt:onscreen source IP range state NEW,ESTABLISHED

Internet   tcp — anywhere             anywhere     tcp dpt:sdl-ets source IP range state NEW,ESTABLISHED


Chain Internet (5 references)

target     prot opt source               destination

DROP       all — anywhere             anywhere STRING match “REGISTER sip:” ALGO name bm TO 65 limit: above 17/min burst 4 mode srcip-srcport htable-max 10000

DROP       all — anywhere             anywhere  STRING match “INVITE sip:” ALGO name bm TO 65 limit: above 10/min burst 4 mode srcip-srcport htable-max 10000

DROP       all — anywhere             anywhere  STRING match “SUBSCRIBE sip:” ALGO name bm TO 65 limit: above 20/min burst 4 mode srcip-srcport htable-max 10000

DROP       all — anywhere             anywhere  STRING match “OPTIONS sip:” ALGO name bm TO 65 limit: above 10/min burst 4 mode srcip-srcport htable-max 10000

DROP       all — anywhere             anywhere  STRING match “ACK sip:” ALGO name bm TO 65 limit: above 20/sec burst 4 mode srcip-srcport htable-max 10000

LOGLIMIT   all — anywhere             anywhere

Single Phone Rate Limits

Some safe settings for rate limits for your phone ranges are:

REGISTER: 6 per minute (lines should only need to register once per hour)

INVITE: 20 per minute (there are typically 2 for each call, and then there are Invites when calls are put on hold, or calls are transferred).

SUBSCRIBE: 5 per minute (a phone should only subscribe to MWI and BLF’s and Shared Lines at a rate of once per hour).

OPTIONS: 5 per minute (options pings aren’t usually needed for phones but may be used to keep a NAT/firewall pinhole open)

ACK: 10 per second (ACK can fly around pretty quickly in a SIP call…. 10 per second should be pretty safe though)

Remote Offices Behind NAT

You’ll want to scale the above numbers by the number phones that might be behind that NAT device. If the remote office is coming through a VPN tunnel, however, all of the remote phones will be unique IP addresses so there’s no concern then.

Phones Being Blocked

It’s important to not disable the firewall settings just because your phones are starting to be blocked. More than likely they’re being blocked for a reason. Either the device is misconfigured in some way and spamming the server with traffic (which you’ve successfully handled by blocking the offender) or you’ve got to go back and maybe loosen up some of your rate limits.

You’ll find firewall related logs in /var/log/sipxpbx (look for sipxsecurity.log) and also in /var/log/sipxpbx/firewall

Check out the log files and sort out why the phones are being blocked. Your sipXcom users will thank you for it.

Next time…

In a following blog we cover the SIP Security settings that configure Fail2Ban.

More About the sipXcom Project:

From 2010 to 2015, sipXecs primary development contributions were provided by the development team at eZuce, Inc. The sipXcom open source communications project was established in January of 2015 from a fork in the sipXecs project by the development team at eZuce, Inc. With the creation of sipXcom, this team shifted its focus to contributing to the new project and no longer maintains sipXecs code nor participate in the SIPfoundry forums.

The experts who have helped to build sipXecs into the incredible product that it is will be found in the Google Groups ( and (