The Enabling Technologies Blog


John Miller / / Categories: Audicodes, Security, Audiocodes, Session Border Controller, SBC, Firewall

Securing an AudioCodes Session Border Controller – Firewall Rules

AudioCodes has written a document with Security Guidelines for SIP Media Gateways and SBCs (Session Border Controllers). It was written for version 7.2 of the firmware. The major sections of the document include guidance on:

  • Separating Network Traffic
  • Implementing Layer 3/4 (Network) Firewall
  • Securing Management Access
  • Secure SIP using TLS (SIPS)
  • Implementing LDAP-based Conditional Call Routing
  • Defining SIP Message Blacklist/Whitelist
  • Monitoring and Log Events
  • SBC-Specific Security Guidelines
  • Gateway-Specific Security Guidelines

 

We recently worked with a client who wanted to implement as many of these recommendations as possible. We also had to follow the guidelines for network appliances that were established by their data security team. Some of the recommendations like “Separating Network Traffic” were impractical to implement in their environment and were waived. The most challenging was implementing the firewall. We had to define the rules for an interface connected to their local area and wide area networks and a second interface that was used for the SIP trunks. The LAN side rules were much more difficult to setup than were the rules for the SIP trunk interface.

Following are the results including some lessons learned about configuring the firewall on an AudioCodes Mediant Session Border Controller (SBC):

Parameters

The SBC is routing calls between:

  • Two (2) Lync 2013 Pools
    • Collocated Mediation Services on the Enterprise Edition servers
    • The pools were located in different locations
    • Configured in an Active-Passive failover configuration
    • Communication between the SBC and the Lync pools was over port 5067 using TLS
  • Two (2) Avaya Session Managers
    • These were in different locations (same as the Lync pools)
    • Configured in an Active-Passive failover configuration
    • Communication between the SBC and the Session Managers was over port 5060 using TCP. The client will likely change this to 5067 using TLS in the future
  • Three (3) Exchange 2013 Unified Messaging Servers
    • Two (2) were in the main location and the third was in the secondary location
    • All three (3) were in an active state associated with the primary Unified Messaging dial plan
    • The SBC was used to facilitate the delivery and retrieval of voice mails for the Avaya users. The Lync servers have a direct SIP connection to the Unified Messaging servers and do not need to leverage the SBC for Lync user voice mail
    • For various reasons we could not implement communication over TLS between the SBC and the Unified Messaging servers. We ended up using port 5060 over TCP
    • Ports 5062, 5065 and 5067 over TCP are also used with Unified Messaging Servers
  • Vendor SIP trunk
    • The vendor provided two (2) IP addresses for SIP signaling
    • The connection between the interface on the SBC and the client’s router was over a dedicated network
    • The client’s router was connected to their MPLS wide area network backbone
    • The vendor also had a connection to the client’s MPLS to provide facilities for the SIP trunks
    • Communication between the SBC and the vendor’s SIP signaling addresses was over port 5060 using UDP
  • Ten (10) AudioCodes MediaPacks of various port density at several locations across the wide area network
    • Communication between the SBC and the MediaPacks was over port 5060 using TCP
    • The client had wanted to use 5067 over TLS. On AudioCodes recommendation we did not use this due to concern over the MediaPacks having sufficient processing power to handle the demands of TLS communication
    • The MediaPacks were tied to the SBC using automatic registration and Far End User (FEU) licenses on the SBC

We had several requirements that we had to follow in configuring the SBC:

  • Install a highly available pair of AudioCodes Mediant 2600 Session Border Controllers
    • This required the addition of a “MAINTENANCE” network interface on the SBC. The SBC ended up with three (3) network interfaces:
      • LAN
      • SIPTrunks
      • MAINTENANCE
    • Interface the SBC to their existing AudioCodes One Voice Operations Center console
    • Use secure SIP (SIPS) wherever practical to communicate with the Lync Servers, Avaya environment, MediaPacks and SIP trunks
    • Use secure LDAP (LDAPS) to secure web and SSH authentication to the device
    • Only permit HTTPS, disable Telnetting to the SBC and enable Secure Shell (SSH)
    • The Lync and Unified Messaging servers use ephemeral ports in the range 49152-65535 for SIP signaling. This was important to be able to get the SBC and the servers to exchange SIP OPTIONS messages and for typical signaling
    • The Avaya servers and MediaPacks use 1024-65535 for their ephemeral ports
    • The Mediant 2600 supports up to 500 firewall rules. A Mediant 1000 supports up to 50 rules
    • You cannot insert new firewall rules like you can insert new IP-IP routing rules on the Mediant 2600. You can move rules up and down in the table

Planning

Like most firewall configuration, we decided the last rules in the list would block traffic to each of the interfaces. We would add rules above these blocking rules that would permit the absolute minimum set of ports needed to manage the SBC and allow it to route the traffic. We also felt it was important to logically group the rules and number them in a way that should make “inserting” additional rules as easy as possible. This was most important for the MediaPacks whose population would likely increase in the client’s environment. We defined the following logical rule groups and added them in this order:

  • SBC Management Access on the “LAN” network interface
    • Rules 0 and 1
    • Allow traffic from any device on the interface using these ports:
      • HTTPS
      • SSH
    • ICMP-Ping Rules on the “LAN” network interface
      • Rules 2 and 3
      • These rules are explicitly set to block ping traffic to the “LAN” and “SIPTrunks” interfaces
      • These were added to simplify enabling ping for troubleshooting as needed on the interfaces
    • Basic functions on the “LAN” network interface
      • Rules 4 through 8
      • DNS
        • Allow traffic from DNS servers in both locations
      • NTP
        • Allow traffic from the primary site’s NTP server
      • LDAPS
        • Allow communication with one (1) domain controller in each of the locations
      • SIP Trunks on the “SIPTrunks” network interface
        • Rules 15 and 16
        • 5060/UDP
        • We did not need to define rules for ephemeral ports on this interface. This will be discussed below
      • Lync Servers on the “LAN” network interface
        • Rules 20 through 31
        • Allow communication from each of the three (3) Lync Enterprise Edition pools in the two (2) locations
        • 5067/TLS
        • Ephemeral ports for signaling and media (49152-65535)
      • Avaya Session Managers on the “LAN” network interface
        • Rules 32 through 35
        • 5060/TCP
        • Ephemeral ports for signaling and media (1024-65535)
      • Unified Messaging Servers on the “LAN” network interface
        • Rules 36 through 50
        • 5060/TCP, 5062/TCP, 5065/TCP and 5067/TCP
        • Ephemeral ports for signaling and media (49152-65535)
      • Four (4) MediaPacks on the “LAN” network interface
        • Rules 51 through 58
        • 5060/TCP
        • Ephemeral ports for signaling and media (1024-65535)
      • One Voice Operations Center on the “LAN” network interface
        • Rules 80 through 85
        • UDP ports
          • 1161 - SNMP
          • 161 - SNMP
          • 123 - NTP
        • TCP ports
          • 80 - HTTP
          • 443 - HTTPS
          • 5000 – Quality of Experience
          • 5001 – Quality of Experience – Secured
        • High Availability Control on the “MAINTENANCE” Interface
          • Rules 90 to 97
          • Rules for the listed ports were configured for the “MAINTENANCE” interface IP address on both nodes of the highly available pair of Mediant 2600s
            • Any TCP port to 2442/TCP
            • Port 80/TCP to ports 0-65535/TCP
            • Port 670/TCP to port 680/TCP
          • Block All Rules
            • Rules 497 through 499
            • Block all other traffic to each of the three (3) Interfaces
              • LAN
              • SIPTrunks
              • MAINTENANCE

Adding Firewall Rules to an SBC

The instructions for adding firewall rules to a Mediant 2600 SBC can be found in the latest version of the  AudioCodes Mediant Software SBC User’s Manual. There are a few items to note about the SBC firewall:

  • Rules are applied at a very low level network layer on the SBC and override all other security related configuration
  • Firewall rules are inbound only. They affect traffic coming in to the SBC
  • You must “Save” the configuration after adding or changing firewall rules and you must reset the SBC to implement them
  • You must be signed on to the SBC as a user with “Security Administrator” or “Master” access level to configure the firewall
  • The SBC supports dynamic firewall pinholing for RTP/RTCP media traffic negotiated in the SDP of SIP calls. If the SBC and the remote device decide that the SBC will listen on port 55123 for RTP/RTCP traffic during a specific call, the SBC will open that port on the firewall for the duration of the call then close it
  • Firewall rules to allow RTP/RTCP traffic through specific ports are not required
  • You must add firewall rules if the device is communicating with a AudioCodes One Voice Operations Center server(s)
  • You must configure rules to permit traffic on the MAINTENANCE interface of a highly available pair of Mediant 2600s if you are including a blocking rule for that interface. These rules must be listed before the blocking rule
  • Firewall rules can be managed through both the web interface and client line interface through Telnet or SSH
  • You may also configure the rules directly in the “AccessList” section of the configuration file (INI)

From the web interface, navigate to the firewall table via “Setup menu->IP Network tab->Security Folder->Firewall”. Click “New” to add a rule. The form is split into three (3) sections:

  • Match
    • Index
      • Keep in mind that you cannot insert rules into this table when specifying an Index number for this rule
      • You can move rules up and down in the table or by directly editing the configuration file
    • Description
      • Enter a name or useful information about this rule
    • Traffic criteria that cause this rule to be applied
      • Source IP
        • IP address or DNS name of a specific host
        • The default is 0.0.0.0
      • Source Port
        • A single source port in the range 0 to 65535
        • You cannot enter a range of ports in this field
        • Port 0 allows any source port
      • Prefix Length
        • Subnet mask to be applied to the Source IP
        • The default value is 0 which allows all traffic regardless of the defined source IP. It will allow traffic from any IP address
        • This must be changed from 0. A value of 32 would be used to restrict the match to a single IP address. Other values can be used to permit a range of addresses
        • Even if you are using a DNS name, you must specify a value for this parameter
      • Start Port
        • Defines the first port in a range of ports on the SBC on which the incoming traffic is received
        • This range should cover the destination port in the incoming packet
        • If the “Protocol” (see below) is anything other than “TCP” or “UDP” the entire range, 0-65535, must be specified
      • End Port
        • Defines the last port in a range of ports on the SBC on which the incoming traffic is received
        • This range should cover the destination port in the incoming packet
      • Protocol
        • Specify a protocol type, i.e. UDP, TCP, ICMP, ESP, etc.
        • TLS is not a supported type in this field
        • If you specify “Any” then your port range must be defined as 0-65535
        • You can also use any of the IANA protocol numbers between 0 and 255
      • Use Specific Interface
        • Whether to apply this rule to a specific network interface
      • Interface Name
        • If you have chosen to limit this rule to a specific network interface, specify the name of the interface here
      • Action
        • Allow or Block (reject) traffic
        • Limit the maximum packet size
        • Define the expected traffic rate, i.e. the allowed bandwidth for the specified protocol
        • Allowing for momentary busts of data that exceed the expected traffic rate
      • Statistics
        • This is a read-only field that displays the number of packets that matched this rule. This counter gets reset when the SBC is restarted, or the rule is updated

Adding our Rules and Lessons Learned

We created sixty-seven (67) rules on this SBC. These rules included what we needed for:

  • Two (2) DNS Servers
  • One (1) NTP Server
  • Two (2) Active Directory Domain Controllers
  • Two (2) SIP signaling addresses on the SIP Trunks
  • Six (6) Lync 2013 Enterprise Edition Servers distributed across two (2) Lync 2013 pools
  • Two (2) Avaya Session Manager Nodes
  • Three (3) Exchange Unified Messaging Servers
  • Four (4) AudioCodes MediaPacks (The client will be adding at least six (6) more MediaPacks)

We had quite a bit of trial and tribulation getting the rules to work properly. The rules for the “SIPTrunks” and “MAINTENANCE” interfaces were straightforward. We learnt a few things and got several surprises with the rules on the “LAN” interface:

  • You must specify a “Prefix Length” on every rule, even if you are specifying a DNS name instead of an IP address, otherwise it will act like a “wildcard” rule
  • We tried to use pool references for the Lync pools and a pool of Active Directory Domain Controllers. This did not work well at all! We ended up creating rules for each one of the Lync servers. We used the DNS name of each server in the rules. For the Active Directory Domain Controllers “pool” we used the DNS name of the most resilient Domain Controller in the first location
  • We later found that using the DNS name was also causing us a problem! Whenever we reset the SBC, we couldn’t get a successful SIP OPTIONS for any server that we used a DNS name for in the firewall rules. Initially we were able to work around the problem by setting our blocking rule on the “LAN” interface to “Allow” and saving the configuration followed by setting it to “Block” and saving again. We worked with AudioCodes to try to find a solution. We noticed that we had used an IP address for one of the MediaPack’s firewall rules. After a reset, the SBC could successfully OPTION that MediaPack. Based on that discovery, we replaced all of the DNS names with IP addresses!
  • For the Unified Messaging servers, we needed rules for ports 5060, 5062, 5065 and 5067 for each server. Since the “Source Port” field only supports a single port, we had to create four (4) rules for each Unified Messaging server!
  • For the SIP Trunks, we added two (2) rules, one for each of the two (2) signaling addresses provided by the vendor. We set these rules up referencing the IP address to allow traffic from any source port on the SIP Trunks into port 5060 with a “Protocol” of UDP on the SBC.
    • Description\Name: Allow 5060 UDP from the SIP Trunk
    • Source IP: Signaling IP Address for the SIP Trunk
    • Source Port: 0 (Any Port)
    • Prefix Length: 32
    • Start Port: 5060
    • End Port: 5060
    • Protocol: UDP
    • Specific Interface: SIPTrunks
  • The Proxy Set for the SIP Trunks are always in an “Online” state and we were able to make and receive calls over the SIP Trunks. We did not have to add any additional rules thus demonstrating the ability of the SBC to do the dynamic firewall pinholing for the RTP/RTCP media traffic

The Big SIP OPTIONS Ephemeral Port Lesson!

For the Lync and Unified Messaging Servers, we initially added a similar rule to the ones we added for the SIP Trunks. We allowed traffic in from each of the Lync servers from any source port to port 5067 over TCP (“TLS” is not supported in the “Protocol” field of the firewall rules) on the SBC.

  • Description\Name: Allow inbound Lync 5067 TLS – LAN Interface
  • Source IP: IP Address of a Lync Server
  • Source Port: 0 (Any Port)
  • Prefix Length: 32
  • Start Port: 5067
  • End Port: 5067
  • Protocol: TCP
  • Specific Interface: LAN

To our surprise, SIP OPTIONS did not work routing from the SBC to the Lync server. SIP OPTIONS coming from the Lync server to the SBC appeared to be working. We had the same problem with the Avaya Session Managers, Unified Messaging servers and MediaPacks. While we were working with AudioCodes support, one of the clients network engineers in a different context, mentioned something about ephemeral ports and the media traffic. Hearing this I recalled that the Lync servers would use ephemeral ports as their source port for signaling. We were able to determine that the SBC also used ephemeral ports as their source port.

We noticed in a trace that the SBC was sending OPTIONS to the Lync server but they weren’t being received back on the SBC. We could see the OPTIONS arriving on the Lync server. It appeared that the SBC wasn’t letting the response to its own SIP OPTIONS back in. We couldn’t put 2 and 2 together to understand why this was happening. I took an educated guess at a rule to try to solve the problem and came up with this based on my knowledge of the ephemeral port range on a Lync server which solved the problem:

  • Description\Name: Allow Outbound Lync 5967 TLS – LAN Interface
  • Source IP: IP Address of a Lync Server
  • Source Port: 5067
  • Prefix Length: 32
  • Start Port: 49152
  • End Port: 65535
  • Protocol: TCP
  • Specific Interface: LAN

We put in similar rules for the other servers and MediaPacks adjusting them for the required port and ephemeral ports supported by the device. This solution worked for all of the devices that we were doing SIP OPTIONS over TCP with. At the end of the day, we needed two (2) rules for each:

  • Six (6) Lync Servers
  • Two (2) Avaya Session Managers
  • Four (4) MediaPacks

Each Unified Messaging servers required five (5) rules. We had to write one “outbound” rule for each of the four (4) ports used by the Unified Messaging servers, 5060, 5062, 5065 and 5067 plus an “inbound” rule for the port range 5060-5067 rule (we discussed creating separate inbound rules since the ports the Unified Messaging server uses are not contiguous. The client’s security team was agreeable with us using a single rule reflecting the 5060-5067 range):

  • Description\Name: Allow inbound UM 5060-5067 TCP – LAN Interface
  • Source IP: IP Address of a Unified Messaging Server
  • Source Port: 0 (Any Port)
  • Prefix Length: 32
  • Start Port: 5060
  • End Port: 5067
  • Protocol: TCP
  • Specific Interface: LAN
  • Description\Name: Allow Outbound UM 5060 TCP – LAN Interface
  • Source IP: IP Address of a Unified Messaging Server
  • Source Port: 5060
  • Prefix Length: 32
  • Start Port: 49152
  • End Port: 65535
  • Protocol: TCP
  • Specific Interface: LAN

 

  • Description\Name: Allow Outbound UM 5062 TCP – LAN Interface
  • Source IP: IP Address of a Unified Messaging Server
  • Source Port: 5062
  • Prefix Length: 32
  • Start Port: 49152
  • End Port: 65535
  • Protocol: TCP
  • Specific Interface: LAN

 

  • Description\Name: Allow Outbound UM 5065 TCP – LAN Interface
  • Source IP: IP Address of a Unified Messaging Server
  • Source Port: 5065
  • Prefix Length: 32
  • Start Port: 49152
  • End Port: 65535
  • Protocol: TCP
  • Specific Interface: LAN

 

  • Description\Name: Allow Outbound UM 5067 TCP – LAN Interface
  • Source IP: IP Address of a Unified Messaging Server
  • Source Port: 5067
  • Prefix Length: 32
  • Start Port: 49152
  • End Port: 65535
  • Protocol: TCP
  • Specific Interface: LAN

Conclusion

This was the first time that my colleagues or I at Enabling Technologies had ever added firewall rules to the LAN Interface of an AudioCodes SBC or Gateway. In the hundreds of these devices that we have implemented we have never put rules on the “LAN” interface and only put rules on the “SIPTrunks” interface a few times. There was a lot of discussion about whether these rules were even needed.

All parties agreed that the interface between the SBC and the vendors SIP Trunks signaling addresses was very secure, “close ended” and well protected. It was felt that it would be highly improbable that anywhere on the path between the SBC and the signaling addresses could be exploited. There was also some thought given to the premise that clients should have a certain level of trust with their communications vendors and their security and protection protocols. We all agreed that in most cases a closed routing path and reliable well-regarded vendor usually negates the need to add firewalling to the SIP trunk interface on an SBC. We had similar discussions about the LAN interface.

Clients develop a level of comfort and trust with the security and protections they place on the users and equipment on their LANS. The argument was posed that if you are confident about the safety and security of your LAN, adding firewall rules to the SBC would be redundant. Whenever you add firewall rules or enable other security measures on a device or server you are adding complexity to the configuration and management of the device. You are actually lowering the mean time between failure (MTBF) on the device. You are usually also adding additional load against the processing power of the device.

The client in this case was confident with the protections that they had on their LAN. They felt that knowing what they knew about their environment that the likelihood of a breach on the LAN or SIP Trunk interface of the SBC was unlikely. However, the client was not only wary of what they knew but were also wary of what they didn’t know. Given this stance and philosophy the client’s business rules stated that they should protect their environment as much as possible to mitigate against known unknown threats. Given this business rule the trade-off of adding the complexity and load on the SBC was overridden by the requirement to protect their equipment and data assets to the fullest extent. There were some compromises made, not using TLS on the MediaPacks as an example but for the most part, the SBC was secured on both interfaces as much as practicable.

In the coming weeks, there will be additional articles highlighting some of the other security features that were enabled on this SBC.

Subscribe to Email Updates

Refine by

To expand the list, please click on the double arrows.

 

Search by Category or Author:

ref:_00D80KtFf._5000y1WwWQD:ref