Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Fraudulent REGISTER on SBCE Remoteworker flow 1

Status
Not open for further replies.

AvayaUC2021

Technical User
Jan 27, 2021
13
FR
Hi team,

I have an Avaya SBCE (release 8.0.1) installed with an Avaya IPO (reelase 11.0.4).

I have a remote worker service running on SBCE.

Since yesterday, I received many fraudulent REGISTER and I don't know how to block that correctly.

I have already activaed DDoS options but that doesn't block the attacks.

SNAG-0006_27-01-2021_17.43.32_kimmzc.png


Thank you for help

Regards
 
The best thing I am aware of you can do about this is create really specific user agents / subscriber flows. Unfortunately that registration is pretty targeted and actually contains an Avaya user agent. If you are only using one type of phone with one version of firmware/software, you can create a user agent that's specific down to the version. The next best thing to do is make sure your login codes are complex, so that if they make it to the IPO, they can't guess the login code easily.
 
I use many type of phone:

- IX Workplace on iOS
- IX Workplace on Android
- IX Workplace on Windows
- J100 phones

I will change login codes to make it complex if no other solution on SBCE for that..

 
Yep, the hackers discovered the Avaya User Agent.

Make sure you use long/difficult passwords for the users.
Define the user agent with if possible the version you are using.
Use, if possible, a dedidcated extension range so you can create a URI group and only allow those extensions and the proper domain to register.
Create a URI group with all other extension ranges to block those via the security rules.
Define your domain in the subscriber flow and if possible define the source subnet.

But as we speak I am testing this:

New in R8.1 is MAC-based LDAP authentication
MAC-based LDAP authentication feature uses LDAP to authenticate the MAC address of the endpoints in the SIP REGISTER messages. Avaya SBCE supports LDAP version 3.
With this feature, Avaya SBCE:
Queries LDAP server to authenticate endpoints on receiving SIP REGISTER messages from the endpoints.
Creates a search filter and sends the query to the LDAP server.
Validates the MAC address received in the LDAP query response in the SIP REGISTER message and authenticates the endpoint.
The communication of Avaya SBCE and LDAP server supports:
IPv4 and IPv6 addresses.
The management interface.
The ability to communicate with the primary and alternate LDAP servers. If the primary LDAP server is non-functional, the communication continues with the alternate server.
Caching of LDAP queries and responses.




Freelance Certified Avaya Aura Engineer

 
Sounds interesting, Gerard. So you can have a LDAP server that stores all allowed MAC addresses and SBC checks with every registration of the MAC address can be found in LDAP?

Another option would be to implement client certificates for the remote endpoints. But I have no clue how to do that.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN
 
That’s how I read it and I hope it works like that. I am able to connect to LDAP with no issues but adding the custom macAddress field to the LDAP server is kind of a struggle.
I will keep you posted!

Freelance Certified Avaya Aura Engineer

 
Hi Derfloh, I got it working. So my sbce still checks if the user agent is correct, if the register comes from an allowed domain, if the phone number is allowed and after that if the MAC address can be found in my ldap server. Of course still use a long user password but this way, in my opinion we should be safe enough.

Freelance Certified Avaya Aura Engineer

 
The MAC address does not change. The question is if the registration when on WiFi is with the WiFi MAC or Ethernet MAC.
 
When I am on the wifi I am not routed to the sbce. My internal dns points me to the IP office directly. But I’ll do some more research on this.

Freelance Certified Avaya Aura Engineer

 
If you're behind a NAT network it would be the firewalls MAC that is shown, so for example if you use WiFi at home it would be your router MAC and not the MAC of the device.

"Trying is the first step to failure..." - Homer
 
No I don’t think so. The MAC is got from the sbc trace does not match any I have looked up in my network. Still working on it.

Freelance Certified Avaya Aura Engineer

 
Another way to secure Avaya systems, maybe that Avaya find a way to crypt the 46xxsettinps.txt & other settings files readable from Internet.
These files contains importants informations about phone system: SIP protocols/ports etc...
 
To secure the settings/firmware files you need to use TLS mutual authentication.

"Trying is the first step to failure..." - Homer
 
You can do that on IP Office already. On system you can allow Avaya HTTP clients only. When trying to retreive the settingsfile you see: HTTP Server Allows Avaya Clients Only

Freelance Certified Avaya Aura Engineer

 
Not much secure, I'm receiving attacks right now from Avaya Deskphone...
 
I agree, but I believe they use this User Agent after reading the 46xxsettings file. And the combination of using a correct user agent, and the register comes from an allowed domain, the phone number is allowed and after that the MAC address can be found in and ldap server (+ of course still use a long user password) should be safe enough.

Freelance Certified Avaya Aura Engineer

 
I'm deploying the SBCE 8.1.2 this afternoon and I will test LDAP function for MAC address and URI groups to allow/deny subnets and domains.
I'll keep you in touch about the result.
Thank you all for your ideas.
Thank you Tek-Tips for this community !
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top