A simple script can tell you!
The security terminology for a pattern of actions or behaviors that MAY point to an active attack on your systems is Indicators of Attack. Let’s take an example from the voice and video world. Assume that your call centers on a typical Monday afternoon receive 30 calls per minute. If the call volume suddenly increases to 45 calls per minute, what does it imply? Are you under some TDoS attack or has some marketing campaign really taken off? One way to get an answer would be to see if the number of blank/short calls has spiked abnormally, which would be an indicator that your call centers are under attack.
A big challenge for enterprise security systems is often that news of the attack often arrives very late – too late to do anything about the incident. Often, security personnel are left with no choice except to pick up the pieces after the incident, learn from that episode, repair things, and put in new controls to prevent similar incidents from recurring. In short, the response is reactive.
Indicators of Attack are a way to get proactive – noticing specific behaviors that may indicate attacks lets you take smart actions that prevent things from falling apart. They allow you to, for example, block IP addresses or phone ranges that are suspicious, because they seem to be the origin of too many Register or Invite messages. Note that these are just indicators, not assertions – they may mean that you are under attack, or you have a configuration issue or that your systems are performing normally but business conditions are changing… regardless, there is something for you to look into, to investigate, and then decide.
The bright minds here at Assertion have been thinking long and hard about questions of security in the SIP world and we have built an extensive list of patterns and system behaviors that indicate or assert that your systems are under attack.
To help our customers, they have created a Python script – simple, easy, small, and open-source, that you can use to identify IOAs on your Avaya SBCs. The IOA script focuses on just 4 common IOAs – and it requires just one input – a zip file of your trace logs. It doesn’t even require an internet connection – there is nothing to download or upload. The script works in a simple fashion (details given below) and the output is 4 results:
- a list of the unusually high register rejects,
- unusually high invite rejects,
- unexpected user agents, and
- unexpected URIs.
The entire process, from download to output should take no more than an hour, and at the end of it all, you will know if you have something to think about.
The Rubber Meets the Road
Assumptions
We make the following assumptions:
- You are reasonably comfortable with the Linux command line
- Your Linux or Windows machine has Python installed
- You have access to the Avaya SBC trace logs.
Pre-requisites
To run the program, you need the following:
- Windows, Mac, or Linux (almost any version will do, but you need command-line access)
- Python 3.0 and above
Platforms supported:
- Avaya ESBC 8.x
- Avaya ESBC 10.x
Downloading the program
First, log into your Linux account (or your Windows machine) and download the program from: https://assertion.cloud/reports/check_ioa.zip
Download the input files
Avaya SBCs generate trace logs, which are to be used as input data for this program. You need access to these. Note that the SBC has these files, not the EMS, so you need access to the SBC device.
On the SBC, the /archive/log/tracesbc/tracesbc_sip folder contains the trace log files that are of interest to us. Download all the .gz files from this folder and save it in a folder called trace_logs_folder.
How to Run the Program
On the Linux (or Mac OS) terminal, run the following command: $ gunzip <path to check_ioa.zip>
On Windows – unzip the check_ioa.zip file.
This unzips the script files into a subfolder called check_ioa, which consists of the following files:
- check_ioa.py: This is the script – the program that processes and analyzes your trace files and tells you if you have any IOAs to worry about.
- config.py: This configuration file contains the parameters used by the check_ioa.py script.
The expected parameters and their default values are as follows:
- uri_list: An array of expected URI prefixes for validation. Replace the default values of 640, 650 with values that are relevant to your organization.
- ua_list: An array of expected user-agent strings. Replace the default value of “avaya 1x.” with the strings that your user-agents use.
- business_countries_list: An array of country codes to filter business-related calls. Replace the default values of “+1” (ISD for USA) and “+44” (ISD for UK) with the ISD codes of countries relevant to your organization.
On Linux (or Mac OS), run the following command: $ python <path to check_ioa.py>
On Windows: double-click the check_ioa.py file to run it.
The Python script asks for the “absolute path” to the folder that contains the “SIP trace logs”. When provided, it runs through all the logs and provides a set of 4 outputs, one for each of the IOAs mentioned earlier.
How to Read the Outputs
Number of Register Rejects:
This is the total number of registration rejects found in the input files, along with the top 5 extensions targeted.
If your servers are experiencing an unusually high number of failed Register attempts, it is possible that your systems are being probed or attacked by a malicious actor. A typical call center agent who fails to register successfully gives up after a few attempts and reaches out to the helpdesk, whereas an automated malicious actor may auto-retry until successful or blocked. Looking for patterns in the rejected Register attempts may firm up the indications – if an unusually high number is from a specific IP address (or range).
The output looks like this:
Number of Invite Rejects:
This lists the total number of Invite rejects and the top 5 callers rejected.
If an incoming Invite repeatedly gets rejected, it is possibly just a mistaken caller, or it may be a malicious probe. Consider that a caller repeatedly attempts to connect with extension 5002 of your system (300 attempts!), but your extension range does not have (and never had) that number – would that be good grounds to be suspicious of the caller?
The output looks like this:
Number of Unexpected User-Agents:
This is the total number of registration attempts from unexpected user-agents, along with the expected user-agents prefixes and top unexpected user-agents.
A typical call center deploys a limited set of softphone brands, types, and versions. For example, a call center may have Avaya and Genesys infrastructure on the server side and its agents will receive devices loaded with Avaya Communicator 3.x. Given that the average call center agent normally uses company supplied devices, it may be safe to assume that the client will be something like Avaya Communicator 3.6 on Android, iPhone, Windows or MacOS. So would it be fair to raise an eyebrow if a MicroSIP client attempts to connect to your network? Would it be fair to raise both eyebrows if it makes repeated attempts?
The output looks like this:
Number of Unexpected URI:
This lists the total number of registration attempts from unexpected URIs, along with the expected URI prefixes and top unexpected URI attempts.
This Indicator of Attack, like its predecessor, focuses on the usual behavior of organizations and then highlights the unusual. In most organizations, there is a standard set of extension ranges. So, if your organization has approved extension ranges starting from 640 and 650, but there are multiple attempts to register extensions starting from 450 or 500, should you sit up a little straighter? There might be an innocent explanation for this, but it might be worth your while to investigate…
The output looks like this:
What should you do if there are IOAs?
It’s good to be aware of unusual behavior in your systems, just so you have something concrete to investigate. And if this script does highlight some IOAs, connect with us at sales@assertion.cloud – we can dig deeper and let you know if it’s just a false alarm or you have something more serious to look at.