Security, Performance and Troubleshooting

The Sipwise C5 runs a wide range of services. In order to secure the platform while allowing access to Sipwise C5 , Sipwise C5 configuration framework provides a set of predefined network zones. Services are aggregated into appropriate zones by default. Zones are assigned to network interfaces (and VLANs if applicable) in /etc/ngcp-config/network.yml.

To facilitate firewall functionality, Sipwise C5 uses the Kernel’s 'netfilter' facility and 'iptables-persistent' as an interface to 'netfilter'. 'Netfilter' is using 'tables' and within that 'chains' to store rules in this hierarchy: 'table' → 'chain' → 'rule'. Default firewall setups of Sipwise C5 do not use netfilter tables 'nat' and 'raw', but only default table 'filter'.

Each 'chain' deploys a 'default policy' handling packets which did not trigger and rule in a prticular 'chain'.

The default firewall setup provided by Sipwise C5:

The Sipwise C5 comes with a preconfigured set of firewall rules, which can be enabled and configured in /etc/ngcp-config/config.yml in section security->firewall. Refer to appendices-main:appendices-main.adoc#security_yml for available configuration options.

Firewall configuration is applied by running ngcpcfg apply. However, this will not activate new rules automatically to avoid inadvertent self-lockout. To finally activate new firewall rules run iptables-apply. This will prompt for another system logon to verify access remains available. If the prompt is not confirmed, firewall rules will automatically be reverted to the previous state re-enabling access to the command line.

The following set of rules is added by the system upon activation of the firewall subsystem. Individual system rules are configured in '/etc/ngcp-config/templates/etc/iptables/rules.v4.tt2' and '/etc/ngcp-config/templates/etc/iptables/rules.v6.tt2'

The Sipwise C5 configuration framework makes it possible to add custom rules to the firewall setup in '/etc/ngcp-config/config.yml'. The custom rules are added after the system rules. Hence, they apply for packets not matched by the systems rules only.

Example custom rule to whitelist all IPv4 traffic from network interface eth1.301 effectively making VLAN 301 a trusted network:

Example custom rule to accept incoming traffic from monitoring station 203.0.113.93 for an optionally installed check_mk agent:

To add hosts or networks to the SSH whitelist they can be either added to key 'sshd.permit_support_from' in '/etc/ngcp-config/config.yml' or a custom rule may be used:

An example for Sipwise C5 firewall configuration in '/etc/ngcp-config/config.yml' enabling both the firewall subsystem and the logging facility may look like:

The Sipwise C5’s super-user account comes with a preconfigured password. It is imperative that this password is changed by the operator immediately after Sipwise C5 is shipped and before it is connected to any potentially unsecure public or private network using a secure password in compliance with existing password policies of the operator. The "root" password must not be shared outside of the operator’s organization including Sipwise engineers. The "root" password must not be shared in any publicly accessible communications including e-mail or ticketing systems.

To change the root password log into the freshly deployed system as "root" using the preconfigured password and execute:

Then follow the prompts to change the password.

The Vagrant/VirtualBox/VMWare Sipwise C5 images come with more default credentials which should be changed immediately:

The Sipwise C5 Web-interface comes with a preconfigured "administrator" account deployed with a default password. This account can be considered Sipwise C5 application super-user and has far-reaching access to application specific settings via the Web-interface. It is imperative that the password for this account is changed by the operator immediately after Sipwise C5 is shipped and before it is connected to any potentially unsecure public or private network using a secure password in compliance with existing password policies of the operator. The "administrator" password must not be shared outside of the operator’s organization including Sipwise engineers. The "administrator" password must not be shared in any publicly accessible communications including e-mail or ticketing systems.

The password for the "administrator" account can be changed via the Web-interface.

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.

Generate new password for user ngcpsoap to access the provisioning interfaces, see the details in apis:apis.adoc#provisioning_interfaces_section.

As soon as you have packets arriving on your Sipwise C5 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. Sipwise C5 allows you to block such kind of attacks quite easily, by configuring the following section in your /etc/ngcp-config/config.yml :

As soon as Sipwise C5 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 kamailio-lb.log a line saying:

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

Excluding SIP endpoints from banning

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

The Sipwise C5 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.

This is a very common attack that can be checked via the /var/log/ngcp/kamailio-proxy.log file. There will be INVITE/REGISTER messages coming in with strange usernames. Attackers are 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, Sipwise C5 allows you to detect and block such attacks quite easily by configuring the following parameters in /etc/ngcp-config/config.yml file:

It may be required to increase the number of failed attempts by adjusting the ban time (e.g. some users can be banned accidentally because they are not writing the right password). If a user tries to authenticate an INVITE/REGISTER (or more in general, any request containing an Authorization or Proxy-Authorization SIP header) and if it fails more than 3 times, the user@domain (not the IP as for Denial of Service attack) will be blocked for 3600 seconds (see failed_auth_ban_time on /etc/ngcp-config/config.yml). In this case, you will see the following lines in /var/log/ngcp/kamailio-lb.log file:

Both the banned IPs and banned users will be shown in the Admin web interface by accessing the Settings→Security Bans menu. To retrieve the same information from Kamailio memory, use the following command:

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 using this mechanism is achieved through encoding the original content of selected SIP headers. Then Sipwise C5 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:

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

This mechanism achieves topology hiding by stripping the SIP routing headers that show topology details and storing those data in the associative data structure (hash) in the Redis DB so that it can look it up when a reply or in-dialog SIP message comes in. From the signaling perspective it simulates a SBC (Session Border Controller) on the LB.

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, /var/log/ngcp/sems-b2b.log or /var/log/ngcp/rtp.log. Example of kamailio-proxy.log line:

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

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:

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

see the manual to know all the options:

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

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