The security terminology for a pattern of actions or behaviors that may point to an active attack on your Avaya SBC is ‘Indicators of Attack’. Let me give 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 DDoS 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. The rest of this article talks about 4 common indicators of attack on your Avaya SBCs, and one simple way to look for them.
Indicator 1: Unusually High Register Rejects
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), for example.
Indicator 2: Unusually High Invite Rejects
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?
Indicator 3: 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?
Indicator 4: Unexpected URI
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…
Now, the problem you face: how do you look for these indicators? And this is where the bright minds at Assertion have stepped in to help! Read on to learn about the IOA script!
The IOA Script
So here at Assertion, the elves have been hard at work fixing and polishing our tools and tech, but as a side-project, 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 the 4 IOAs that we described earlier – 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 –
- download a gz file of trace logs to your laptop
- download the script.zip and unzip it
- read the readme.md
- edit config.py
- run check_ioa.py
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.
And what if there are IOAs?
It’s good to be aware of unusual behavior in your systems so that you have something concrete to investigate. And if this script does highlight some IOAs, connect with us – we can dig deeper and let you know if it’s just a false alarm or if you have something more serious to look at.
As we mentioned, it’s free, open-source, tiny, and fast. It neither downloads anything from the internet nor uploads anything there, so it’s safe and secure too! Give it a shot and let us know how useful it was.