The Technical Bulletin outlines security precautions for General SIP Trunking to prevent unauthorized access and misuse of IP-PBX systems. It highlights various VoIP security threats, including Denial of Service attacks and Dial Through Fraud, and emphasizes the importance of implementing firewalls and monitoring tools like Wireshark to detect malicious activity. Recommendations for secure deployment and further reading on best practices are also provided to ensure the protection of IP-PBX systems in public network environments.
The Technical Bulletin outlines security precautions for General SIP Trunking to prevent unauthorized access and misuse of IP-PBX systems. It highlights various VoIP security threats, including Denial of Service attacks and Dial Through Fraud, and emphasizes the importance of implementing firewalls and monitoring tools like Wireshark to detect malicious activity. Recommendations for secure deployment and further reading on best practices are also provided to ensure the protection of IP-PBX systems in public network environments.
The Technical Bulletin outlines security precautions for General SIP Trunking to prevent unauthorized access and misuse of IP-PBX systems. It highlights various VoIP security threats, including Denial of Service attacks and Dial Through Fraud, and emphasizes the importance of implementing firewalls and monitoring tools like Wireshark to detect malicious activity. Recommendations for secure deployment and further reading on best practices are also provided to ensure the protection of IP-PBX systems in public network environments.
The Technical Bulletin outlines security precautions for General SIP Trunking to prevent unauthorized access and misuse of IP-PBX systems. It highlights various VoIP security threats, including Denial of Service attacks and Dial Through Fraud, and emphasizes the importance of implementing firewalls and monitoring tools like Wireshark to detect malicious activity. Recommendations for secure deployment and further reading on best practices are also provided to ensure the protection of IP-PBX systems in public network environments.
1 of 9 Introduction One of the most important aspects for the management of any IP-PBX has become the implementation and review of security on the system with regard to the prevention of unauthorised call access.
IP-PBX misuse can of course originate in-house, for example private calls initiated by an employee, or forwarding of a DDI to an extension and then on to an external destination. However, the rise in VoIP security threats reported recently, shows us that the worst misuse is likely to be generated remotely by ‘hackers’ looking to exploit any available remote access to the customers IP-PBX in order to generate unauthorised calls.
Globally indivduals and often well-organised groups are using online scanners to continuously scour IP address lists in order to exploit any weaknesses in VoIP environments.
Current VoIP security threats recognised against IP-PBXs include (but are not limited to):
Options and Register requests sent to gather information on the IP-PBX and features. Denial of Service (DoS) including SIP INVITE and REGISTER message flooding Spam over Internet Telephony (SPIT) Dial Through Fraud (DTF)
Generally unauthorised calls for DTF are to International or Premium Rate destinations, which are a higher than normal call charge. International calls can be made directly, via a preliminary call to a suitable operator or directory enquiries who is then asked to put them through. The operator will do this if they have no reason to suspect the call is fraudulent and there is often a surcharge for this to be done.
It is important to note that any customer thus affected is still liable for all such call charges and these can sometimes run into many thousands of pounds.
As hackers can be sending multiple requests, which have to be processed by the target IP-PBXs CPU. These attempts can often be considered - if frequent enough - to be a form of Denial of Service (DoS) attack, and have a significant impact on the performance of the system potentially causing it to become unresponsive to further SIP Trunk traffic.
NEC emphasise that this potential problem is certainly not specific to NEC IP-PBX equipment.
2 of 9 SIP Trunks - Network Edge Security When using SIP trunks with the SL2100, SL1x00, SV8100, SV9100, the connection method to an ITSP or remotely networked switch can be configured to not require any username/password authentication. This can leave the system under the right conditions (public Internet access) exposed to illegal connection attempts and potentially allow hackers the ability to dial through the system to external parties and also dial internally.
The following security precautions should be considered and implemented until you are sufficiently satisfied the PBX is secure enough that you feel comfortable to allow access for this specific functionality.
When allowing for SIP trunk access, ports should always be firewalled in order to only allow traffic from specifically configured IP addresses (commonly referred to as Inbound IP Traffic Filtering). Only statically assigned Public IP addresses from the ITSP or remote network that will be connecting to the switch should be allowed access.
If SIP trunks (or multiple profiles) are not used by the IP-PBX do not forward these associated ports from the firewall to the switch. Note, the number of profiles varies between IP-PBXes.
IP-PBX Application Default Port Assigned
SIP Trunk Signalling (Profile 1) 5060
SIP Trunk Signalling (Profile 2) 5062
SIP Trunk Signalling (Profile 3) 5090
SIP Trunk Signalling (Profile 4) 5092
SIP Trunk Signalling (Profile 5) 5094
SIP Trunk Signalling (Profile 6) 5096
RTP Media Ports (will vary depending on DSP
10020…10276 resource capacity on VoIP card)
3 of 9 Checking for malicious SIP activity Wireshark Tracing You can check for malicious SIP activity using Wireshark installed on a PC. This PC should have port mirroring enabled to it’s LAN network port so that it can also receive and see any IP traffic on the VoIP interface.
In any wireshark traces you may see many INVITE requests towards the IP-PBX. These will normally have international or national numbers in the To field (the called party) along with a commonly used trunk access code (9 or 0). The hackers are attempting to dial in to the IP-PBX and back out to an external destination number(s).
Example numbers seen include: 900441594800008, 800390245073685, 00441594800008, 000441594800008
INVITE Example 1
INVITE Example 2
The Contact field is where the call originated from, check whether this number corresponds with any numbering on your IP- PBX i.e. any extension number ranges or SIP Trunk IDs. Although do not rely on this solely as sometimes the number may match your actual system numbering.
The user agent field is the device attempting the call. This is normally the easiest method to detect if a call is malicious or authentic. You may see various values in here but common unauthorised ones can be: friendly-scanner (related to sipvicious), zxcvfdf11, sipcli/v1.8
4 of 9 Checking using the SMDR Output Alternatively if you do not have access to wireshark tracing you can configure the SMDR output on the IP-PBX and connect using a suitable Telnet client such as PuTTY.
Configuring the for SMDR Output
SL2100 screenshots used, methodology is similar for the other IP-PBXes.
Logon to the IP-PBX using PCPro and download the system configuration.
Go to programming level 3 and under Additional Devices > SMDR > Setup > SMDR Port Setting
Configure a TCP port to be used for the SMDR output e.g. 4001. Apply settings when done.
Go to Additional Devices > SMDR > Setup > SMDR Service Options
Set the output port type to LAN. Apply settings when done.
5 of 9 Go to Additional Devices > SMDR > Setup > SMDR Output Options
Configure the Output Options to be the same as in the below screen shot. Apply settings when done.
Go to Additional Devices > SMDR > Setup > SMDR Date Format
6 of 9 Set as European Format. Apply settings when done.
Go to Additional Devices > SMDR > Setup > SMDR Output for Extensions
Enable SMDR Printout, SMDR output of made intercom calls, SMDR output of answered intercom calls for all IP-PBX extensions. Apply settings when done.
Go to Additional Devices > SMDR > Setup > SMDR Output for Trunks
7 of 9 Enable SMDR Printout for all IP-PBX extensions. Apply settings when done.
Upload changes and disconnect.
Using putty to connect to the SMDR port
Once the above configuration items are in place you can then access the SMDR output port using it’s internal IP address or if remotely using it’s public IP address.
If accessing remotely, ensure your router/firewall is configured with a port forwading rule for the SMDR output port to the IP- PBX IP address. Additionally a firewall access rule may be required to allow access to the IP-PBX.
Once this is in place you should be able to connect to the SMDR port using a suitable Telnet/SSH client such as PuTTY (shown below)
Private IP Address Connection Public IP Address Connection
8 of 9 What are you looking for?
The SMDR buffer will hold up to 4000 records (for SL2100, number varies between IP-PBXes). When you connect to the SMDR Output port this information will be displayed.
If you see many calls coming into the IP-PBX with 00:00 duration and listed as NO ANSWER then it is likely these are malicious SIP calls being received by the IP-PBX.
Further Reading
Recommendations for secure deployment of an IP-PBX
The Internet Telephony Service Providers Association have on it’s website a Best Practice White Paper available titled ‘Recommendations for secure deployment of an IP-PBX’.
We would highly recommend anyone looking to deploy a secure IP-PBX system to read through this document thoroughly as it covers many general networking aspects of securely deploying a system in an environment which will be allowing access over public networks. Also it advises on how to monitor your system on a daily basis and what you should check you have in place before even deploying.
Enter the link below in the address bar of your browser to view the paper directly at the ITSPA website.
