The sip:provider CE runs a wide range of services. In order to secure the platfrom while allowing access to the sip:provider CE the NGCP 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 sip:provider CE 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 sip:provider CE 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 sip:provider CE:

The sip:provider CE 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 Section 1.29, “security” 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 NGCP configuration framework allows 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:

rules4:
  - '-A INPUT -i eth1.301 -j ACCEPT'

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

rules4:
  - '-A INPUT -p tcp -s 203.0.113.93 --dport 6556 -j ACCEPT'

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:

rules4:
  - '-A INPUT -s 198.51.100.0/24 --dport 22 - j ACCEPT'
  - '-A INPUT -s 203.0.113.93 --dport 22 -j ACCEPT'

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

security:
  firewall:
    enable: 'yes'
    logging:
      enable: 'yes'
      file: '/var/log/firewall.log'
      tag: 'NGCPFW'
    policies:
      input: 'DROP'
      forward: 'DROP'
      output: 'ACCEPT'
    rules4:
      - '-A INPUT -i eth0 -j ACCEPT'

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.

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.

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

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-*:

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

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