14. Platform Security, Performance and Troubleshooting

14.1. Sipwise SSH access to sip:provider CE
14.2. Firewalling
14.3. Password management
14.4. SSL certificates.
14.5. Securing your sip:provider CE against SIP attacks
14.5.1. Denial of Service
14.5.2. Bruteforcing SIP credentials
14.6. Topology Hiding
14.6.1. Introduction to Topology Hiding on NGCP
14.6.2. Configuration of Topology Hiding
14.6.3. Considerations for Topology Hiding
14.7. System Requirements and Performance
14.8. Troubleshooting
14.8.1. Collecting call information from logs
14.8.2. Collecting SIP traces

Once the sip:provider CE is in production, security and maintenance becomes really important. In this chapter, we’ll go through a set of best practices for any production system.

14.1. Sipwise SSH access to sip:provider CE

The sip:provider CE provides SSH access to the system for Sipwise operational team for debugging and final tuning. Operational team uses user sipwise which can be logged in through SSH key only (password access is disabled) from dedicated access server jump.sipwise.com only.

To completely remove Sipwise access to your system, please execute as user root:

root@myserver:~# ngcp-support-access --disable && apt-get install ngcp-support-noaccess
[Note]

you have to execute the command above on each node of your sip:provider CE system!

[Warning]

please ensure that the script complete successfully:

  * Support access successfully disabled.

If you need to restore Sipwise access to the system, please execute as user root:

root@myserver:~# apt-get install ngcp-support-access && ngcp-support-access --enable
[Warning]

please ensure that the script complete successfully:

  * Support access successfully enabled.

14.2. Firewalling

The sip:provider CE runs a wide range of services. Some of them need to interact with the user, while some others need to interact with the administrator or with nobody at all. Assuming that we trust the sip:provider CE server for outgoing connections, we’ll focus only on incoming traffic to define the services that need to be open for interaction.

Table 14. Subscribers

ServiceDefault portConfig option

Customer self care interface

443 TCP

www_admin→http_csc→port

SIP

5060 UDP, TCP

kamailio→lb→port

SIP over TLS

5061 TCP

kamailio→lb→tls→port + kamailio→lb→tls→enable

RTP

30000-40000 UDP

rtpproxy→minport + rtpproxy→maxport

XCAP

1080 TCP

kamailio→proxy→presence→enable + nginx→xcap_port

XMPP

5222 and 5269 TCP

None, standard XMPP ports for clients (5222) and federation (5269)


Table 15. Administrators

ServiceDefault portConfig option

SSH/SFTP

22 TCP

NA

Administrator interface

1443 TCP

www_admin→http_admin→port

Provisioning interfaces

2443 TCP

ossbss→apache→port


[Caution]

To function correctly, the rtpengine requires an additional iptables rule installed. This rule (with a target of RTPENGINE) is automatically installed and removed when the rtpengine starts and stops, so normally you don’t need to worry about it. However, any 3rd party firewall solution can potentially flush out all existing iptables rules before installing its own, which would leave the system without the required RTPENGINE rule and this would lead to decreased performance. It is imperative that any 3rd party firewall solution either leaves this rule untouched, or installs it back into place after flushing all rules out. The complete parameters to install this rule (which needs to go into the INPUT chain of the filter table) are: -p udp -j RTPENGINE --id 0

14.3. Password management

The sip:provider CE comes with some default passwords the user should change during the deployment of the system. They have been explained in the previous chapters of this handbook.

  • The login for the system account cdrexport is disabled by default. Although this is a jailed account, it has access to sensitive information, namely the Call Detail Records of all calls. SSH keys should be used to login this user, or alternatively a really strong password should be used when setting the password via passwd cdrexport.
  • The root user in MySQL has no default password. A password should be set using the mysqladmin password command.
  • The administrative web interface has a default user administrator with password administrator. It should be changed within this interface.
  • Generate new password for user ngcpsoap to access the provisioning interfaces, see the details in Section 9, “Provisioning REST API Interface”.

The Vagrant/VirtualBox/VMWare sip:provider CE images come with more default credentials which should be changed immediately:

  • The default password of the system account root is sipwise. A password must be changed immediately using command passwd root.
  • SSH authorized_keys for users root and sipwise should be wiped out using command rm ~root/.ssh/sipwise_vagrant_key ~sipwise/.ssh/sipwise_vagrant_key for VirtualBox/VMWare images (skip the step if you use Vagrant).
[Important]

Many NGCP services use MySQL backend. Users and passwords for these services are created during the installation. These passwords are unique for each installation, and the connections are restricted to localhost. You should not change these users and passwords.

14.4. SSL certificates.

The sip:provider CE provides default, self-signed SSL certificates for SSL connections. These certificates are common for every installation. Before going to production state, the system administrator should provide SSL certificates for the web services. These certificates can either be shared by all web interfaces (provisioning, administrator interface and customer self care interface), or separate ones for each them can be used.

  • Generate the certificates. The customer self care interface certificate should be signed by a certification authority to avoid browser warnings.
  • Upload the certificates to the system
  • Set the path to the new certificates in /etc/ngcp-config/config.yml:

    • ossbssapacheautoprovsslcertfile and ossbssapacheautoprovsslcertkeyfile for the provisioning interface.
    • ossbssapacherestapisslcertfile and ossbssapacherestapisslcertkeyfile for the REST interface.
    • www_adminhttp_adminsslcertfile and www_adminhttp_adminsslcertkeyfile for the admin interface.
    • www_adminhttp_cscsslcertfile and www_adminhttp_cscsslcertkeyfile for the customer self care interface.
  • Apply the configuration changes with ngcpcfg apply 'added web ssl certs'.

The sip:provider CE also provides the self-signed SSL certificates for SIP over TLS services. The system administrator should replace them with certificates signed by a trusted certificate authority if he is going to enable it for the production usage (kamailiolbtlsenable (disabled by default)).

  • Generate the certificates.
  • Upload the certificates to the system
  • Set the path to the new certificates in /etc/ngcp-config/config.yml:

    • kamailiolbtlssslcertfile and kamailiolbtlssslcertkeyfile .
  • Apply the configuration changes with ngcpcfg apply 'added kamailio certs'.

14.5. Securing your sip:provider CE against SIP attacks

The sip:provider CE allows you to protect your VoIP system against SIP attacks, in particular Denial of Service and brute-force attacks. Let’s go through each of those attacks and let’s see how to configure your system in order to face such situations and react against them.

14.5.1. Denial of Service

As soon as you have packets arriving on your sip:provider CE server, it will require a bit of time of your CPU. Denial of Service attacks are aimed to break down your system by sending floods of SIP messages in a very short period of time and keep your system busy to handle such huge amount of requests. sip:provider CE allows you to block such kind of attacks quite easily, by configuring the following section in your /etc/ngcp-config/config.yml :

security:
  dos_ban_enable: 'yes'
  dos_ban_time: 3600
  dos_reqs_density_per_unit: 50
  dos_sampling_time_unit: 2
  dos_whitelisted_ips: []
  dos_whitelisted_subnets: []

Basically, as soon as sip:provider CE receives more than 50 messages from the same IP in a time window of 2 seconds, that IP will be blocked for 3600 sec, and you will see in the the kamailio-lb.log a line saying:

Nov 9 00:11:53 sp1 lb[41958]: WARNING: <script>: IP '1.2.3.4' is blocked and banned - R=<null> ID=304153-3624477113-19168@tedadg.testlab.local

The banned IP will be stored in kamailio memory, you can check the list via web interface or via the following command:

# ngcp-kamctl lb fifo sht_dump ipban

Excluding SIP endpoints from banning

There may be some SIP endpoints that send a huge traffic towards NGCP from a specific IP address. A typical example is a SIP Peering Server.

[Caution]

sip:provider CE supports handling such situations by excluding all defined SIP Peering Servers from DoS protection mechanism.

The NGCP platform administrator may also add whitelisted IP addresses manually in /etc/ngcp-config/config.yml at kamailio.lb.security.dos_whitelisted_ips and kamailio.lb.security.dos_whitelisted_subnets parameters.

14.5.2. Bruteforcing SIP credentials

This is a very common attack you can easily detect checking your /var/log/ngcp/kamailio-proxy.log. You will see INVITE/REGISTER messages coming in with strange usernames. Attackers is trying to spoof/guess subscriber’s credentials, which allow them to call out. The very first protection against these attacks is: ALWAYS USE STRONG PASSWORD. Nevertheless sip:provider CE allow you to detect and block such attacks quite easily, by configuring the following /etc/ngcp-config/config.yml section:

  failed_auth_attempts: 3
  failed_auth_ban_enable: 'yes'
  failed_auth_ban_time: 3600

You may increase the number of failed attempt if you want (in same cases it’s better to be safed, some users can be banned accidentally because they are not writing the right password) and adjust the ban time. If a user try to authenticate an INVITE (or REGISTER) for example and it fails more then 3 times, the "user@domain" (not the IP as for Denial of Service attack) will be block for 3600 seconds. In this case you will see in your /var/log/ngcp/kamailio-lb.log the following lines:

Nov 9 13:31:56 sp1 lb[41952]: WARNING: <script>: Consecutive Authentication Failure for 'sipvicous@mydomain.com' UA='sipvicous-client' IP='1.2.3.4' - R=<null> ID=313793-3624525116-589163@testlab.local

Both the banned IPs and banned users are shown in the Admin web interface, you can check them by accessing the Security Bans section in the main menu. You can check the banned user as well by retrieving the same info directly from kamailio memory, using the following commands:

# ngcp-kamctl lb fifo sht_dump auth

14.6. Topology Hiding

14.6.1. Introduction to Topology Hiding on NGCP

The term "topology hiding" in SIP is used to describe the measures taken by typically an SBC (Session Border Controller) to hide detailed information of the internal network at the border of which it is located. Pieces of information such as IP addresses and port numbers used by SIP endpoints and intermediaries within the network are considered sensitive, as these can give some hints to potential attackers about the topology of the network.

In a typical SIP session the mandatory headers may carry that sensitive information, for example: Contact, Via, Record-Route, To, From, Call-ID. An SBC applying topology hiding will mangle the content of those headers.

Concealment of sensitive information is achieved through encoding the original content of selected SIP headers. Then NGCP will create a new SIP URI using a preselected IP address and the encoded content as URI parameter, finally re-assembling the SIP header.

Examples for encoded SIP headers:

Record-Route: <sip:127.0.0.8;line=sr-NvaAlWtecghucEhu6WtAcu...>
Contact: <sip:127.0.0.8;line=sr-NvaAli-1VeL.kRxLcbN86W...>

The load-balancer element of the Sipwise NGCP has an SBC role, from the SIP peers point of view. The LB offers topology hiding function that can be simply activated through a configuration change. By default the function is disabled.

14.6.2. Configuration of Topology Hiding

Activating topology hiding function is possible through the modification of the following configuration parameters in /etc/ngcp-config/config.yml file (shown below with default values of parameters):

kamailio:
  lb:
    security:
      topoh:
        enable: no
        mask_callid: no
        mask_ip: 127.0.0.8

Meaning of the configuration parameters:

  • enable: if set to yes, the topology hiding will be activated
  • mask_callid: if set to yes, the SIP Call-ID header will also be encoded
  • mask_ip: an IP address that will be used to create valid SIP URIs, after encoding the real/original header content.

    [Tip]

    Any valid, preferably private network address can be used. The suggestion is however to use an address that is not used by any other SIP endpoint or intermediary element in the network.

14.6.3. Considerations for Topology Hiding

Although hiding sensitive information about a SIP provider’s network is desired, there are some potential side effects caused by topology hiding.

The most common example is the consequence that SIP message size may grow when applying topology hiding. The fact that SIP messages become larger may even prevent NGCP from communicating successfully with another SIP entity (a peer SBC, for example). This can be expected under following circumstances:

  • SIP transport protocol is UDP
  • SIP messages have more Via and Record-Route headers
  • IP packets of SIP messages without the topology hiding feature already have a size close to the MTU

In such a case the IP packets carrying SIP messages with encoded headers will have a size exceeding the MTU, that will cause loss of data.

The recommended solution in such a case is to use TCP transport for SIP messages.

14.7. System Requirements and Performance

The sip:provider CE is a very flexible system, capable of serving from hundreds to several tens of thousands of subscribers in a single node. The system comes with a default configuration, capable of serving up to 50.000 subscribers in a normal environment. But there is no such thing as a normal environment. And the sip:provider CE has sometimes to be tunned for special environments, special hardware requirements or just growing traffic.

[Note]

If you have performance issues with regards to disk I/O please consider enabling the noatime mount option for the root filesystem. Sipwise recommends the usage of noatime, though remove it if you use software which conflicts with its presence.

In this section some parameters will be explained to allow the sip:provider CE administrator tune the system requirements for optimum performance.

Table 16. Requirement_options

OptionDefault valueRequirement impact

cleanuptools→binlog_days

15

Heavy impact on the harddisk storage needed for mysql logs. It can help to restore the database from backups or restore broken replication.

database→bufferpoolsize

64MB

For test systems or low RAM systems, lowering this setting is one of the most effective ways of releasing RAM. The administrator can check the innodb buffer hit rate on production systems; a hit rate over 99% is desired to avoid bottlenecks.

kamailio→lb→pkg_mem

16

This setting affects the amount of RAM the system will use. Each kamailio-lb worker will have this amount of RAM reserved. Lowering this setting up to 8 will help to release some memory depending on the number of kamailio-lb workers running. This can be a dangerous setting as the lb process could run out of memory. Use with caution.

kamailio→lb→shm_mem

1/16 * Total System RAM

The installer will set this value to 1/16 of the total system RAM. This setting does not change even if the system RAM does so it’s up to the administrator to tune it. It has been calculated that 1024 (1GB) is a good value for 50K subscriber environment. For a test environment, setting the value to 64 should be enough. "Out of memory" messages in the kamailio log can indicate that this value needs to be raised.

kamailio→lb→tcp_children

8

Number of TCP workers kamailio-lb will spawn per listening socket. The value should be fine for a mixed UDP-TCP 50K subscriber system. Lowering this setting can free some RAM as the number of kamailio processes would decrease. For a test system or a pure UDP subscriber system 2 is a good value. 1 or 2 TCP workers are always needed.

kamailio→lb→tls→enable

yes

Enable or not TLS signaling on the system. Setting this value to "no" will prevent kamailio to spawn TLS listening workers and free some RAM.

kamailio→lb→udp_children

8

See kamailio→lb→tcp_children explanation

kamailio→proxy→children

8

See kamailio→lb→tcp_children explanation. In this case the proxy only listens udp so these children should be enough to handle all the traffic. It could be set to 2 for test systems to lower the requirements.

kamailio→proxy→*_expires

Set the default and the max and min registration interval. The lower it is more REGISTER requests will be handled by the lb and the proxy. It can impact in the network traffic, RAM and CPU usage.

kamailio→proxy→natping_interval

30

Interval for the proxy to send a NAT keepalive OPTIONS message to the nated subscriber. If decreased, this setting will increase the number of OPTIONS requests the proxy needs to send and can impact in the network traffic and the number of natping processes the system needs to run. See kamailio→proxy→natping_processes explanation.

kamailio→proxy→natping_processes

7

Kamailio-proxy will spawn this number of processes to send keepalive OPTIONS to the nated subscribers. Each worker can handle about 250 messages/second (depends on the hardware). Depending the number of nated subscribers and the kamailio→proxy→natping_interval parameter the number of workers may need to be adjusted. The number can be calculated like nated_subscribers/natping_interval/pings_per_second_per_process. For the default options, assuming 50K nated subscribers in the system the parameter value would be 50.000/30/250 = (6,66) 7 workers. 7 is the maximum number of processes kamailio will accept. Raising this value will cause kamailio not to start.

kamailio→proxy→shm_mem

1/16 * Total System RAM

See kamailio→lb→shm_mem explanation.

rateomat→enable

yes

Set this to no if the system shouldn’t perform rating on the CDRs. This will save CPU usage.

rsyslog→external_log

0

If enabled, the system will send the log messages to an external server. Depending on the rsyslog→external_loglevel parameter this can increase dramatically the network traffic.

rsyslog→ngcp_logs_preserve_days

93

This setting will set the number of days ngcp logs under /var/log/ngcp will be kept in disk. Lowering this setting will free a high amount of disk space.


[Tip]

In case of using virtualized environment with limited amount of hardware resources, you can use the script ngcp-toggle-performance-config to adjust sip:provider CE configuration for high/low performance:

root@spce:~# /usr/sbin/ngcp-toggle-performance-config
/usr/sbin/ngcp-toggle-performance-config - tool to adjust sip:provider configuration for low/high performance

  --help                Display this usage information
  --high-performance    Adjust configuration for system with normal/high performance
  --low-performance     Adjust configuration for system with low performance (e.g. VMs)

root@spce:~#

14.8. Troubleshooting

The sip:provider CE platform provides detailed logging and log files for each component included in the system via rsyslog. The main folder for log files is /var/log/ngcp/, it contains a list of self explanatory log files named by component name.

The sip:provider CE is a high performance system which requires compromise between traceability (maximum amount of debug information being written to hard drive) and productivity (minimum load on IO subsystem). This is the reason why different log levels are configured for the provided components by default.

Most log files are designed for debugging sip:provider CE by Sipwise operational team while main log files for daily routine usage are:

Log fileContentEstimated size

/var/log/ngcp/api.log

API logs providing type and content of API requests and responses as well as potential errors

medium

/var/log/ngcp/panel.log /var/log/ngcp/panel-debug.log

Admin Web UI logs when performing operational tasks on the ngcp-panel

medium

/var/log/ngcp/cdr.log

mediation and rating logs, e.g. how many CDRs have been generated and potential errors in case of CDR generation or rating fails for particular accounting data

medium

/var/log/ngcp/kamailio-proxy.log

Overview of SIP requests and replies between lb, proxy and sems processes. It’s the main log file for SIP overview

huge

/var/log/ngcp/kamailio-lb.log

Overview of SIP requests and replies along with network source and destination information flowing through the platform

huge

/var/log/ngcp/sems.log

Overview of SIP requests and replies between lb, proxy and sems processes

small

/var/log/ngcp/rtp.log

rtpengine related log, showing information about RTP communication

small

[Warning]

it is highly NOT recommended to change default log levels as it can cause system IO overloading which will affect call processing.

[Note]

the exact size of log files depend on system type, system load, system health status and system configuration, so cannot be estimated with high precision. Additionally operational network parameters like ASR and ALOC may impact the log files' size significantly.

14.8.1. Collecting call information from logs

The easiest way to fetch information about a single call among the log files is the search for the SIP CallID (a unique identifier for a SIP dialog). The call ID is used as call marker in almost all the voip related log file, such as /var/log/ngcp/kamailio-lb.log , /var/log/ngcp/kamailio-proxy.log , /var/log/ngcp/sems.log or /var/log/ngcp/rtp.log. Example of kamailio-proxy.log line:

Nov 19 00:35:56 sp1 proxy[7475]: NOTICE: <script>: New request on proxy - M=REGISTER R=sip:sipwise.local
F=sip:jdoe@sipwise.local T=sip:jdoe@sipwise.local IP=10.10.1.10:5060 (127.0.0.1:5060) ID=364e4676776621034977934e055d19ea@127.0.0.1 UA='SIP-UA 1.2.3.4'

The above line shows the SIP information you can find in a general line contained in /var/log/ngcp/kamailio-*:

  • M=REGISTER : The SIP Method
  • R=sip:sipwise.local : The SIP Request URI
  • F=sip:jdoe@sipwise.local : The SIP From header
  • T=sip:jdoe@sipwise.local : The SIP To header
  • IP=10.10.1.10:5060 (127.0.0.1:5060) : The source IP where the message is coming from. Between brackets it is shown the local internal IP where the message come from (in this case Load Balancer)
  • ID=364e4676776621034977934e055d19ea@127.0.0.1 : The SIP CallID.
  • UAIP=10.10.1.10 : The User Agent source IP
  • UA=SIP-UA 1.2.3.4 : The SIP User Agent header

In order to collect the full log related to a single call, it’s necessary to "grep" the /var/log/ngcp/kamailio-proxy.log using the ID= string, for example:

# grep "364e4676776621034977934e055d19ea@127.0.0.1" /var/log/ngcp/kamailio-proxy.log

14.8.2. Collecting SIP traces

The sip:provider CE platform provides several tools to collect SIP traces. It can be used the sip:provider CE ngrep-sip tool to collect SIP traces, for example to fetch traffic in text format from outbound and among load balancer, proxy and sems :

# ngrep-sip b

see the manual to know all the options:

# man ngrep-sip

The ngrep debian tool can be used in order to make a SIP trace and save it into a .pcap file :

# ngrep -s0 -Wbyline -d any -O /tmp/SIP_trace_file_name.pcap port 5062 or port 5060

The sngrep debian graphic tool as well can be used to visualize SIP trace and save them in a .pcap file :

# sngrep