Avaya SBCE only allow certain public IP blocks / blacklist all others to relays

[rgunther]

Hey Guys - So on our Avaya SBCE i had to set up an application relay on port 411 for our remote J179 phones to pull firmware files from the avaya IP Office. While this works great, I am concerned about the security of leaving this open all the time. I have already had several hacking attempts and registration attempts on the sbce, in which I just keep adding the hacking IP blocks to the firewall blacklist. Is there a better way to do this? Is there a way to only let whitelisted IPs use the application relay? Better yet, can I block all traffic to the sbce unless it comes from an entry on my whitelist? I read the blacklist over-rides the whitelist; so if i have a blacklist entry to block all / then it would even block the entries included on the whitelist.

Appreciate any advice..

Thanks,

 

[rgunther]

.

 

[jamie77]

Not sure there is a way on the SBC to be hinest, but you could look to do this on the firewall NAT rules in front of the SBC?

Jamie Green

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

 

[G van Hamburg]

For downloading software and settings, use reverse proxy instead. You can specify the allowed url’s. On newer IPO’s you can also hide the settings file for non-avaya users.
Since you use 411, I suspect you didn’t user the no-user sbce settings. That will translate internal ip addresses to SBCE B1 addresses and use 443 insted of 411.

For better security, use user-agents and uri-groups on your subscriber flow. And don’t forget to use a strong phone password!

Freelance Certified Avaya Aura Engineer

 

[rgunther]

Thanks sir -

So we are currently using a reverse proxy for http 8411 and specifying the 46xxsettings file & certificate only. This is mainly so that we can use the workplace application and have it pull the settings file and necessary cert for the android application. We are using the Application relay for 411 & 443. Seems like we had to use 443 in order to get the Avaya Workplace Presence working. I believe 411 was for the J179 settings file to IPO?. On our IP Office we do have the "Use preferred phone ports option & "Avaya HTTP Clients Only" options enabled. For No User source numbers we have the following:

RW_SBC_REG= xxx.xxx.xxx.xxx (Public facing ASBC IP)
RW_SBC_PROV= 192.168.x.x (Private facing ASBC IP)
RW_SBC_TCP=5060
RW_SBC_UDP=5060

We do use URI-Groups on the subscriber flow; but not user-agents.​

 

[G van Hamburg]

Ok, So I’d change to TLS and use user-agents. Further more, all you tell me sound good! In 8.1.2 you can use ldap to allow registration based on mac address, that will make it again more secure.

Freelance Certified Avaya Aura Engineer

 

[rgunther]

Thanks so much. So I tried for days to get it working with TLS with no luck. Im not sure if it didnt like the 3rd party certificate we were issues or what, but none of our external devices (Workplace windows application / Workplace for Android app / or J179 phones) would correctly work with TLS. We actually have an SCN with 7 Avaya IP Offices in it / so our SBCE is configured with 7 external & 7 internal IPs. Then i set up 7 separate signaling & media interfaces, as well as 7 of the reverse proxy and application relays. We do have split-DNS setup so that the fqdn of the IPO does externally resolve the the public IP of the SBC, and internally to the IPO itself. Our 3rd party cert then did have all 7 of the FQDNs as well as the private IP's of the IPO systems. After trying to get TLS working for days, we gave up and just decided to use TCP 5060 since it has been working fine.

As far as User-Agents, I will def look into adding these. It looks like I will need a separate subscriber flow for each type of device we are using, since it only allows 1 type of device per user-agent field?

Thanks much for the input - truly appreciated!

 

[Albus2]

rgunther,

Why:
RW_SBC_TCP=5060
RW_SBC_UDP=5060

You shall just use:
RW_SBC_TLS=5061

Please do not use UDP or TCP from remote, just use TLS.

Also, 443 is not needed. You are using 'preferred ports' 8411 and 411 and those will replace 80 and 443.
On firewall, just 411, 8411, 5061 and the UDP port range need to be open.

Workplace and J100 will work.

 

[rgunther]

We are not using TLS, which is why I have 5060. And I had to open 443 in order for the avaya workplace presence to work. It would not work without 443 being open.

 

[Albus2]

Port 443 can be closed on the firewall. Most likely it is already in use for something else.


Workplace presence is transmitted in Websocket connection over port 411.
But this needs a secure connection, which is why you need to use TLS. Also, the identity certificate need to be created including the SIP domain.

· Example: URI:sip:sip.example.com (if sip.example.com is your SIP-Domain)
Any SIP domains in use as one SAN entry for each SIP domain, in URI format. This is typically the value configured in
Manager | LANx | VoIP | SIP Registrar | SIP Registrar FQDN. This entry is typically used by SIP endpoints when
accessing IP Office using DNS resolution.

 

[derfloh]

You will need TLS for the WebSocket connection anyways. So you can also use SIP over TLS.


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

 

[rgunther]

So it appears that out Avaya workplace presence does work without 443, but the presence on Avaya workplace for Android breaks as soon as i block 443. The minute i open up 443 again on our sbc, the presence on the Avaya workplace for Android Mobile starts working again. Also - we have not been using TLS at this point mainly because of the issues i am having generating certificates on the sbc. We currently have 7 avaya IPO systems in an SCN behind our SBC. On our SBC we then have 7 public & 7 private interface (one for each IPO). TLS is currently working internally, just not remotely because i could not get the certificates working on the sbc. When I generated the CSR on the SBC, I included the 7 DNS & 7 external & internal IP entries as SAN entries in the CSR. I did not include the SIP domain in uri format as when i tried to add URI:sip:xxxx.xxxx.xxxx.com to the SAN entry list, it came back with error "Subject Al Name is not properly formatted". As soon as a took the URI:sip entry out it would accept it. However it still not like our 3rd party certs and endpoints would not connect.

 

[G van Hamburg]

Avaya advices to use 1 cert per service. So on every public IP a seperate cert. You can do the same on the inside, at least I would do that. When, in IPO, the rgistrar and sip domain are equal (ipo.domain.com) you only need 1 DNS name. That’s how I did it.

Freelance Certified Avaya Aura Engineer

 

[Albus2]

We are still talking about Avaya IP Office Server Edition.

As an example, my system works with workplace (Win, Mac, iOS, Android and internal and from remote).
On the firewall, port 80 is closed, port 443 is a web server.
Port 411 and 8411 is open and forwarded to the IPO SE, also a custom TLS port (not 5061), plus the RTP port range. Nothing else.

Workplace is fine with all features. The same for remote J139/159/179.
Certificate is created on Server Edition. Subject Alternative Name is like: DNS:ipo.example.com, URI:sip:sip.example.com, IP:192.168.42.1, IP:203.0.113.30
SIP FQDN is ipo.example.com
SIP Domain is sip.example.com
LAN1 IP is 192.168.42.1
Public IP is 203.0.113.30