Background

The Cisco BroadWorks Device Management System (DMS) delivers configuration files for SIP devices on Cisco BroadWorks platforms. Each time a device boots, it downloads its configuration file. The configuration file includes the essential details necessary to REGISTER via SIP and access the services.

The same essential details can be used by criminal bad actors to use SIP to attack a service provider. By identifying the Session Border Controller (SBC), SIP username and password, the attacker can REGISTER with the service and commit illegal actions to defraud the service provider of revenue.

• Direct Toll Fraud occurs when attackers place calls without intending to pay for them. In some cases, these calls have been connected to calling cards, so that unwitting users intending to place calls to expensive-to-call destinations are actually routing their calls through a system fraudulently.
• Traffic Pumping occurs when bad actors generate calls to a platform. They then receive income through the platform that receives those calls.

Bad actors have long scanner Session Border Controllers (SBCs) for vulnerable SIP accounts. But more recently, attackers are also scanning for unprotected SIP phone configuration files.

Best Prevention: Mutual TLS Authentication

The best approach to protecting SIP Device Management Files is Mutual TLS authentication. With this technology, the Device Management Server receives a request for a file, and checks to see if that request came from a device with a proper TLS Certificate. In the best cases, the TLS Certificate was added by the Manufacturer of the SIP Device, and cannot be directly mimicked by an attacker.

For example, a Poly device would provide a certificate signed by Poly, Inc., and an Algo device would provide a certificate signed by Algo. This allows the Device Management Server to ensure that the configuration files with all their sensitive data are provided only to the proper device types. And it ensure that attackers will not be able to retrieve the configuration files, because the certificates (and their corresponding private keys) are protected by these manufacturers from attack.

However, many service providers do not have Mutual TLS Authentication. To set it up, you can use BroadWorks R22 built-in TLS Mutual Authentication capability in some cases. But in many other scenarios you need the flexibility of a programmable device like the F5 Labs Local Traffic Manager (LTM).

But what if you don't have Mutual TLS and you're getting attacked? 

Detecting Scanning

You can observe scanning on BroadWorks by looking for 404 messages in the tomcat logs. For example, on this BroadWorks XSP (R22), we scan for /dms requests that fail and see many requests coming from one attacker IP address, 94.26.117.83. The 404 response code in these log entries show that the requests are failing.

bwadmin@xsp1$ zgrep '/dms.*404' /var/broadworks/logs/tomcat/access_log.*.gz| head
94.26.117.83 - - [14/Aug/2020:19:20:14 -0400] "GET /dms/Cisco504/000e084c8fdb.xml HTTP/1.1" 404 - - 0.046 46 "-" "Cisco/SPA504G-7.5.5" "-"
94.26.117.83 - - [14/Aug/2020:19:20:14 -0400] "GET /dms/cisco504/000e084c8fdb.xml HTTP/1.1" 404 - - 0.031 31 "-" "Cisco/SPA504G-7.5.5" "-"
94.26.117.83 - - [14/Aug/2020:19:20:15 -0400] "GET /dms/Cisco504/000e084c8fdb.xml HTTP/1.1" 404 - - 0.006 6 "-" "Cisco/SPA504G-7.5.5" "-"
94.26.117.83 - - [14/Aug/2020:19:20:15 -0400] "GET /dms/Cisco504/000e081717dd.xml HTTP/1.1" 404 - - 0.016 16 "-" "Cisco/SPA504G-7.5.5" "-"
94.26.117.83 - - [14/Aug/2020:19:20:15 -0400] "GET /dms/cisco504/000e081717dd.xml HTTP/1.1" 404 - - 0.005 5 "-" "Cisco/SPA504G-7.5.5" "-"
94.26.117.83 - - [14/Aug/2020:19:20:15 -0400] "GET /dms/Cisco504/000e0818471b.xml HTTP/1.1" 404 - - 0.010 10 "-" "Cisco/SPA504G-7.5.5" "-"
94.26.117.83 - - [14/Aug/2020:19:20:16 -0400] "GET /dms/cisco504/000e0818471b.xml HTTP/1.1" 404 - - 0.006 6 "-" "Cisco/SPA504G-7.5.5" "-"
94.26.117.83 - - [14/Aug/2020:19:20:16 -0400] "GET /dms/Cisco504/000e081717dd.xml HTTP/1.1" 404 - - 0.008 8 "-" "Cisco/SPA504G-7.5.5" "-"
94.26.117.83 - - [14/Aug/2020:19:20:16 -0400] "GET /dms/Cisco504/000e084c8fdb.xml HTTP/1.1" 404 - - 0.006 6 "-" "Cisco/SPA504G-7.5.5" "-"
94.26.117.83 - - [14/Aug/2020:19:20:16 -0400] "GET /dms/cisco504/000e084c8fdb.xml HTTP/1.1" 404 - - 0.007 7 "-" "Cisco/SPA504G-7.5.5" "-"

Problems Due to Scanning

BroadWorks XSP servers providing DMS can be, in effect, "attacked" by bad actors scanning for SIP configuration files. High speed scanning on a BroadWorks DMS can cause the services of the XSP to be interrupted, and create unnecessary workload on the Network Server and the Application Server. You'll see alarms including:

• bwProtocolRegistrationFailure 
• bwMemoryOverAllocation

Blocking Scanners: F5 Labs Local Traffic Manager (LTM)

To block scanners, the ideal approach is to use a Network Device like the F5 Labs Local Traffic Manager (LTM) with a configuration that detects failed requests and then blocks those source IPs that make too many requests that fail. If you're adding an F5 Labs LTM to your network to improve Mutual TLS Authentication, then you can get immediate use from the device in this way.

Upsides:

• Keeps the blocking and security configuration in a single device built for security
• Simplifies the configurations on the XSPs
• Scales up efficiently even as more XSPs are added to th enetwork

Blocking Scanners: Open Source Solution with fail2ban

In the absence of a Network Device to support the XSP, the open source tool fail2ban can be used to monitor the XSP log files and ban attackers automatically. It uses the iptables rules in Linux to block traffic coming from attacker devices.

Upsides:

• Free, open source tool works on all Linux systems supported by BroadWorks
• Effectively blocks attackers to prevent scanning and system overload

Setup Guide: fail2ban for XSP on CentOS

Step 1 Become root, and install the epel-release repository and install the fail2ban package.

bwadmin@xsp1$ su
Password: **********
root@xsp1# yum install epel-release
root@xsp1# yum install fail2ban

Step 2 Create an initial configuration file.

root@xsp1# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Step 3 Setup a new filter to recognize scanning in the BroadWorks Tomcat logs.

root@xsp1#  cat > /etc/fail2ban/filter.d/broadworks-dms.conf << vEOF
[Definition]
failregex = ^ - .* "(GET|POST|HEAD).*/dms.*HTTP.*" 404 .*$
vEOF
root@xsp1# cat >> /etc/fail2ban/jail.local << vEOF
[broadworks-dms]
enabled = true
port = http,https
filter = broadworks-dms
logpath = /var/broadworks/logs/tomcat/access_log*.txt
bantime = 3600
findtime = 600 ## Every 10 minutes = 600 seconds...
maxretry = 5   ## Allow 5 failed attempts
vEOF

Step 4 Setup tool to recognize when BroadWorks rotates the tomcat logs.

root@xsp1# cat > /etc/fail2ban/filter.d/broadworks-dms_rescan.sh << vEOF
#!/bin/bash -
## fail2ban does not notice files when BroadWorks creates them, so it has to be told to rescan the files.
old_file_list=/var/tmp/`basename $0`.old_file_list.txt
t=`mktemp`
ls -1tr /var/broadworks/logs/tomcat/access_log*.txt > "$t"
if ! cmp --quiet "$t" "$old_file_list" ; then
cp "$t" "$old_file_list"
 service fail2ban reload
 systemctl start fail2ban
fi
vEOF

Step 5 Setup Linux to start fail2ban automatically.

root@xsp1# service fail2ban start # Works on CentOS or RHEL 6
root@xsp1# chkconfig fail2ban on # Works on CentOS or RHEL 6
root@xsp1# systemctl start fail2ban # Works on CentOS or RHEL 7
root@xsp1# systemctl enable fail2ban # Works on CentOS or RHEL 7

Step 6 Setup tool to recognize when BroadWorks rotates the tomcat logs. Then restart fail2ban.

root@xsp1# chmod 755 /etc/fail2ban/filter.d/broadworks-dms_rescan.sh

Step 7 Setup the rescanner to run every minute.

root@xsp1# cat > /etc/cron.d/fail2ban_broadworks-dms_rescan << vEOF
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
* * * * * root /etc/fail2ban/broadworks-dms_rescan.sh
vEOF