Hacking Attempts. 3

[dsm600rr]

Hello all. On our in-house IPO we have a SIP Trunk that requires a Public Facing IP Address under Network Topology.

Now we have this SIP Trunk deployed on many customers and I see no outside attack attempts.

We also have SIP Remote Phones and the IX Workplace App using TLS and a FQDN. Having this we are getting alot of Login attempts.

I am just curious how these attacks are being attempted. Did they find our FQDN pointing to the PBX? What are they using for attempted Extension Logins? They seem like brute force attacks as we get quite a bit of hits.

We have 5060 locked down to the SIP Trunk Provider.

I have tried messing around with Excessive SIP Traffic Blacklisting with no luck. Nothing I change seems to change the fact that the IP Address are only temporarily blocked the 600 seconds.

Just trying to secure our stuff more however its looking like an ASBC is the best route, however requiring IPOSS kind of kills it being affordable for most customers.

ACSS

 

[IPOLackey]

They won't be using the FQDN, they'll just be attempting the IP Address. If you grab a sysmon trace of it you can see a bit more info like the SIP UA being attempted.

 

[dsm600rr]

IPOLackey: What trace options should I use?

So do they just attack the public IP Address with a Soft Phone that attempts a bunch of extension / password combos?

Even if they had the correct credentials, wouldn't they need the TLS Certificates as well?

ACSS

 

[dsm600rr]

I am seeing:

- VaxSIPUserAgent/3.1
- pplsip
- Avaya one-X Deskphone
- Avaya J179 IP Phone
- Avaya IP Phone 1120E



ACSS

 

[janni78]

Since they are connecting to the IP Office, it's certificate is used the same way when you connect to a website.
If you have a SBC you can get Mutual TLS which would require the client to also have the correct certificate.

I don't see how IPOSS kills the SBCE and why would you buy a security appliance that you don't plan to keep it up to date?

"Trying is the first step to failure..." - Homer

 

[jamie77]

If you want the cleint to require the cert to stop this, then an SBC is the answer.

Most poeple set an SBC to stop on user agent, domain name and extn range. But if they get these right then its still down to strong passwords to stop them.

If you have 46xxsettings publically available, then the FQDN is noted n there, so not hard to find it. Turn on 'Avaya Clients Only' to stop this in the system tab.

The hackers know the systems they are connecting to, hence they are using ana Avaya phone to try get in. They now already know you have Avaya. Thats not hard to find out either.


Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[IPOLackey]

Right, so if you have remote workers using Workplace, then check an inv for a user and note the SIP UA. If you're using J1XX handsets internally you'll also need to check their UA. A proper Avaya SIP UA will have a software version after it like - User-Agent: Avaya Communicator/3.0 (3.12.0.65.6; Avaya CSDK; Microsoft Windows NT 6.2.9200.0)

Then under System|VOIP|Access Control List and set this UA in the Whitelist.

Then under the LAN|Voip set Allowed SIP User Agents to Whitelist Only.

This will stop it responding to anything which isn't on the white list. Should clear out the attempts.

 

[chriscon]

Just a general question
If customer has a private certificate isn't that secure?
Also noticed that if you change port 5060 to a random port helps a lot

 

[janni78]

The only difference between a private and a bought certificate is that clients won't trust it without the Root (or Intermediate) Certificate installed, anyone trying to hacking your system will just trust any certificate.

The FQDN isn't hard to find either, it's right there in your certificate.

Making UA string checks more specific will stop some until more people start using it and they adapt.

"Trying is the first step to failure..." - Homer

 

[G van Hamburg]

Avaya SBCE and LDAP mac Address lookup. I think that is the best move to make at this moment.

Freelance Certified Avaya Aura Engineer

 

[dsm600rr]

IPOLackey: Thank you. I can pull the UA from SSA on the extensions, correct?

I am not seeing:
System|VOIP|Access Control List

ACSS

 

[jamie77]

You will need to be on 11.0FP4 or after and on an Server Edition to get that feature.

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[dsm600rr]

jamie77: I am on R11.1 SP1 with an Application Server running my VM Pro. That mean I am out of luck?

ACSS

 

[Albus2]

jamie77,

Can you explain how to configure SBCE properly, so it does the better job than SE itself, please?
As you say, filtering on UA is one thing. FQDN may be guessed. The settings file must be available, as it won't work without.
Private or public certs are equal, just only private can hold all needed SAN entries. A good thing is to use non-standard ports.
Using preferred port instead of 80/443 is a must.
But how do you setup for mutual auth? And which device or clients do support that? How can you block a specific client later (stolen device)?
Many thanks!

 

[derfloh]

G v Hamburg gave another valuable hint in another thread those days. You can check the client's MAC address against a LDAP server.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[jamie77]

One thing to remember, is the SBC can help stop these attempts, but its job is to protect the network behind it.

For example, without an SBC you have to open up a range of UDP ports for RTP traffic. An SBC stops the need for these to be open to a device on the LAN. it opens them only as and when needed, and to the people who need them. An SBC would stop someone taking advantage of a UDP port flaw, if there ever was one.

It also adds rate limiting and settings can be tuned to the customer needs and network.

Needing the cert can be done with an SBC by setting this in the Server TLS profile. No cert, no passthrough. Without this, certs add encryption, not added security.

Since R11.1FP4, some of the SBC protection function for UA checks and DoS protection was added to the IPO SE systems. IPs and extn are now black listed for a time on bad auth, and UAs can be tied down.

I suspect it wasn't a coincidence that this release was around the time of containers. After all, Avaya made the choice not to front their own public systems behind a firewall and not an SBC!

If you want to know how to configure an SBC properly, get on the course for this and let the Avaya SBC gods show you and explain.

If they manage to convince you, please share the info here. I've been asking Avaya to fully justify the cost, and the disgusting virtual resource requirements, of an Avaya SBC for many years. And they can't really do it.

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[G van Hamburg]

If you need any help with the Avaya SBCE, just contact me directly. The part about the disgusting virtual resource requirements I do not understand. What is so digusting about it?

And to be clear: Any SBC will always be better than no SBC. But if you run Avaya Aura or IP Office I recommend the Avaya SBCE.

Freelance Certified Avaya Aura Engineer

 

[jamie77]

ASBCE R8.0: 4 CPU, 8GB RAM, 160GB Disk + 1 CPU, 1 GB RAM, 40GB Disk for WEBLM

Total 5 CPU, 9GB RAM, 200GB Disk.

Very expensive to host, quite often double the cost of the server edition itself!!

Audio Codes or Ribbon SBC: 1CPU, 2 GB RAM, 15GB Disk. Does a very similar job for a quarter of the hosting cost.

It was bad enough at R7, but removing the 2 CPU, 4GB RAM small spec server at R8.0 really hurt.

And why we can't use the WebLM on the SE I wil never know!

I agree having an SBC is 100% better.

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[G van Hamburg]

Ok, thank you for explaining. IP office 11.1 has WebLM 8.x so starting from now a standalone license server is not needed anymore. It took a while but it’s there now.
For your other point, any SBC is better than nothing and as always, Avaya thinks big. For only a few users, don’t consider Avaya. Use the Avaya SBCE when it fit’s your needs. I also advice (and configure) Oracle SBC’s when I think the Avaya SBCE is too small.



Freelance Certified Avaya Aura Engineer

 

[jamie77]

I'm not aware that IP Office can be used for ASBCE. IF you have a doc that say different I would love to see it.

The R11.1FP1 release does (fianlly!!) say IPO Web LM can be used for some apps, but SBC is not listed. Nice to see they added IPOCC!!! lol

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer