Secure Installation and Configuration
This chapter outlines the planning process for a secure installation and describes several recommended deployment topologies for the system.
Recommended Deployment Topologies
This section outlines the planning process for a secure installation and describes several recommended deployment topologies for the system.
Session Border Controller
- Peering - In a peering
model the SBC is contacted by a SIP server to relay endpoint signaling
information. The SIP server may be a PBX, registrar, proxy, SBC, or other
device. The IP of the device is usually trusted and pre-provisioned in the SBC
as an endpoint (session agent) that will be relaying calls. Since the remote
endpoint is already known, Access Control Lists (ACL) and Call Admission
Controls (CAC) can be pre-provisioned for the appropriate level of protection
or service level assurance.
- Access - In an access
model the SBC is contacted by a SIP endpoint to relay endpoint signaling
information. The IP address of the endpoint is usually not known, so trust
should be established through behavior such as establishment of a successful
registration. Once the endpoint becomes trusted, dynamic Access Control Lists
(ACL) and Call Admission Controls (CAC) can be applied. Monitoring of
potentially abusive behaviors provides a mechanism to “demote” or blacklist
endpoints.
- Hybrid - A hybrid model combines both Peering and Access topologies into a single configuration. This is a fairly common model, where remote users use a registrar server in the core network, but their calls are forwarded to a service provider on one of the peer connections.
Unified Session Manager
The Unified Session Manager (USM) provides edge security for an IMS
network, and should be positioned at access borders to integrate "traditional"
SBC functionality with the core IMS session control functions. It provides a
user registrar, local subscriber tables and Call Session Control Function
components such as Proxy CSCF, Interrogating CSCF, Session CSCF, IMS Access
Gateway, Emergency CSCF and Breakout Gateway Control Function.
Core Session Manager
Session Router
The Core Session Manager, which should never be positioned at a
network edge, is used as a core session controller between multiple network
types. It supports SIP in IMS and non-IMS environments, application servers,
media servers, gateways, etc. It can be deployed in a distributed, virtualized
model on COTS server hardware. The CSM can be used for session routing,
interoperability assurance, CAC, and subscriber database integration through
HSS, ENUM, or local subscriber table databases.
The Session Router is a “pure” SIP session router that can be
positioned in either a core network or at network borders. When installed at a
border, the same SBC protections used in peering and access models can apply.
In the network core, the emphasis is on routing and interoperability.
Enterprise Communications Broker
The Enterprise Communications Broker (ECB) should only be deployed
within an enterprise core network, and not on the edge. Instead of perimeter
security, the ECB is oriented towards functions such as dial plan management,
centralized session, routing, CAC, load balancing, and interworking.
Realm Design Considerations
- A mix of user endpoints, gateways, or peer trunks on the untrusted network
- Varying capabilities or incompatibilities of user agents
- Impacts of blocking traffic to one group of users vs. another (i.e. trust low or medium)
- Service level agreements (SLA) that require Call Admission Controls (CAC)
- Separate endpoints into realms based on trust level (high, medium, low) and that the response to detected abuse is appropriate for them (no action, demotion or blocking)
- Create multiple realms for endpoints based on the type of device – a user endpoint, a gateway, or a peer - since they will have very different considerations for SIP Header Manipulation, trust, signaling thresholds, endpoints behind NAT, and CAC.
- Consider increasing the deny-period from 30 seconds to something longer depending on how much abuse it is believed will be received from a public network and what type of delay users may tolerate.
- Set restricted-latching to sdp so only media received from the IP and port negotiated in signaling will be allowed.
- Pay close attention to the media management settings required for the endpoints and traffic flows (see the mm- parameters on the realm). If one way-audio is experienced this is one place to start investigating.
Management Interfaces
The Oracle SBC has two types of interfaces, one for management and the other for signaling and media (otherwise known as services interfaces). Security configuration for each interface is treated separately.
Two management interfaces allow access to the SBC for configuration, monitoring and troubleshooting purposes; a serial (console) interface and an Ethernet interface for remote management (wancom0).
Serial (Console) Interface
As with any industry standard serial interface to a network element, minimal security functions are available. The physical security of the installation location should be assured since console access cannot be blacklisted. However, the Admin Security license (discussed later) does allow for the console port to be disabled.
To avoid unauthorized access to the console interface the console-timeout should be configured to automatically disconnect the console session after an appropriate period of time (i.e. 300 seconds). Timeouts are disabled by default.
If the console port detects a cable disconnect it will also log out any logged in user to prevent unauthorized use.
The console interface should only be connected to a terminal server if the terminal server is deployed in a secure non-public network.
Configuration is detailed in Section 3 “System Configuration” of the ACLI Configuration Guide.
Management Port Configuration
The Wancom0 management interface MUST be connected to and configured on a management network or subnet separate from the service interfaces. If it is not, the SBC is subject to ARP overlap issues, and loss of system access when the network is down or under DDoS attack. Oracle does not support SBC configurations with management and media and service interfaces on the same subnet.
Configuration is detailed in Section 2 “Getting Started” and Section 3 “System Configuration” of the ACLI Configuration Guide.
Passwords
The SBC provides two levels of user accounts through the Acme Packet Command Line Interface (ACLI): User and Superuser (the “user” and “admin” accounts). SBC no longer supports default passwords and requires these to be changed on first login.
Alternatively, the SBC supports the management of passwords via external RADIUS and TACACS+ servers for finer grain access control. The SBC supports communications with up to six RADIUS servers for this function. At least two entries should be configured to prevent service interruption.
The SBC encrypts sensitive configuration data in the configuration file using a Protected Configuration Password (PCP). This administratively configured password provides security and convenience when migrating configurations to different SBCs. All user passwords should be changed; however, it is especially important to change the PCP (“config” user password) so passwords and keys stored in the config file are secure. TLS, IPsec, and HDR features are protected by the PCP:
CAUTION: Once the PCP password is changed the sensitive information (certificates, IPSec shared secrets, etc) in your configuration file will be re-encrypted using the new PCP the new encryption “salt.”. As a result, previously backed up configuration files cannot be restored unless the password is restored to the value that configuration file was encrypted with.
Configuration is detailed in Section 2 “Getting Started” of the ACLI Configuration Guide, and Section 4 “System Management” of the Maintenance and Troubleshooting Guide in the subsection entitled “Setting a Protected Configuration Password: Matching Configurations.”
The SBC provides a backup user for HDR file synchronization that must be changed. The backup user password can be set using the command “secret backup”. The “secret” command is detailed in Section 3 of the ACLI Reference Guide.
The SBC provides one user for administration of legal intercept functions when a Lawful Intercept (“LI”) license is installed – li-admin. The first time lawful interception is configured you will be prompted to change the password. However if you have installed the license, but never configured lawful interception, the default password may be active and usable via SSH. Procedures to change the password are detailed in the LI Documentation Set.
Boot Flags
Boot parameters specify what information the system uses at boot time when it prepares to run applications. The boot parameters allow definition of an IP on the management interface, set the system prompt, and determine the software load that will be used. In addition, there is a boot flag setting that may modify the file location to be used, but may also enable additional features. Administrator access to the command line interface is required to modify the bootflags.
There is seldom a reason to change the boot flag from its default value (0x08). Changes to the boot flags are usually only needed for hardware testing or recovery, debugging, etc.
- 0x01 – Turns off the hardened interface protection on the media interfaces, allowing all ingress traffic
- 0x10 – Enables a second sshd server that provides access to the linux system console. This server process is different from the ssh server used to access the ACLI for configuration.
- 0x80008 – enable source routing on the management port
For further information on boot flags refer to “Configuration Elements A-M” of the ACLI Reference Guide.
System ACLs
The Wancom0 Ethernet management interface should always be deployed in a secure non-public network.
The SBC provides static System Access Control List functionality (ACL) to protect the Wancom0 interface from other devices that can access the management LAN remotely. Only the management station(s) authorized for SBC access such as the Oracle Communications Session Element Manager should be permitted with ACLs. All system ACLs are considered “allow” ACLs, and include a specific IP source address / netmask and the IP protocol allowed. As the first ACL is created an implicit deny rule is inserted as the final ACL.
The “system-access-list” configuration is detailed in Section 3 “System Configuration” of the ACLI Configuration Guide.
Telnet/SSH
Telnet has been removed and only SSH is supported starting 8.0 release.
To avoid unauthorized access to the SSH interface, a timeout should be configured to automatically disconnect the terminal session after an appropriate period of time (i.e. 300 seconds). Timeouts are disabled by default.
The SBC supports viewing, importing, and deleting public ssh keys used for authentication of SSHv2 sessions.
You can select the algorithms which the Oracle Communications Session Border Controller offers during SSH session negotiation.
- ssh-config, encr-algorithms, do not use any *-cbc cipher
- hash-algorithm = hmac-sha2-s56
- host-key = ssh-rsa
- keyex-algorithms = diffie-hellman-group-exchange-sha256
Configuration is detailed in “Getting Started” of the ACLI Configuration Guide, and “System Management” of the Maintenance and Troubleshooting Guide.
FTP/SFTP
Only SFTP is supported.
GUI Management
The SBC can be managed by the Oracle Communications Session Element Manager via ACP through the management interface over TCP ports 3000 and 3001.
By default these ports are enabled in system-config > remote-control. If the SBCs are not remotely controlled by a Session Element Manager then this feature should be disabled.
Oracle recommends protecting ACP communication is recommended to be protected by with TLS. Enable ACP over TLS by configuring acp-tls-profile in system-config.
CAUTION: Disabling the remote-control feature is incompatible with the SBC HA architecture. Hence this functionality is considered optional and should only be deployed where HA and EMS are not used. If the SBCs are deployed in HA configuration, then the remote-control parameter needs to be enabled for the acquire-config feature to function properly.
Configuration is detailed in “System Configuration” of the ACLI Configuration Guide.
Web Management
Depending on the release, a web based management interface may be accessible via the management network connected to wancom0. The web interface is disabled and not supported for Service Provider SBCs, but Enterprise SBCs include a full featured management and provisioning system.
By default the web interface is disabled. It can be accessed via the wancom0 IP address when enabled. Note that even if the web interface is disabled that the SBC will respond on port 80 by default. However, all new connection requests are immediately torn down with a TCP RST since there is no web server process running, and no kernel rule to forward the request to the web server.
Oracle recommends that only HTTPS be enabled on this interface so TLS will be used instead of the default HTTP. Care should be taken when defining the cipher list in the tls-profile so that administrative traffic cannot be compromised. The default cipher list is “ALL”, which includes some insecure ciphers for backwards compatibility. The cipher list should be set manually to remove insecure ciphers. The recommended cipher list in order of preference includes:
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_SHA256
- TLS_DHE_RSA_WITH_AES_128_SHA256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
state enabled
inactivity-timeout 5
http-state disabled
http-port 80
https-state enabled
https-port 443
tls-profile strong-ciphers-tls-profile
Configuration is detailed in Section 2 “Getting Started” of the ACLI Configuration Guide.
Resiliency
Several features enable availability, a key component of a secure deployment.
High Availability
It is strongly recommended that the SBC be deployed in a High Availability (HA) architecture with a Primary node and a Secondary node connected over both Wancom1 and Wancom2 interfaces for resiliency. It is also recommended that the two units in an HA pair be directly cabled together. While they can be separated and connected via an Ethernet switch or layer 2 VPN, this introduces latency and can significantly impact capacity. Since session replication is performed over a clear text connection, it may also expose call or configuration data sent in the replication process. In short, a geographically redundant pair of SBCs is not recommended. If geo-redundancy is an absolute requirement, a secure site-to-site VPN should be implemented for session replication, and thorough testing should be conducted to understand impacts to session capacity.
Guidelines are presented in “520-0011-03 BCP - High Availability Configuration”.
Configuration is detailed in Section 14 “High Availability Nodes” of the ACLI Configuration Guide.
Link Detection and Gateway Polling
If the gateway-heartbeat is enabled, the SBC periodically sends ARP requests for each configured network-interface gateway. If the configured number of retransmissions has been exceeded, the SBC will mark that gateway as unreachable and decrement its health score. If the health score decrements far enough, and the health score of the standby unit is higher, an HA failover will occur.
It is recommended that exactly one network-interface per physical interface have gateway-heartbeat enabled.
gw-heartbeat state enabled heartbeat 10 retry-count 3 retry-timeout 3 health-score 30
The feature is explained in detail in the “High Availability Nodes” chapter of the ACLI Configuration Guide.
