Alcatel 8690
Security Guidelines
OSP 2.4.01
3CL-02350-BBXX-BGZZA
............................................... April 20, 2006
Table of Contents
Table of Contents .................................................................................................. 1
1. Overview of the different LAN and access modes ........................................ 31. Corporate (Management or intranet) LAN access to OSP R2.4.02 .................................... 42. User LAN access to OSP R2.4.02 ................................................................................... 53. OSP Private LAN ........................................................................................................... 54. Remote access for field support ...................................................................................... 65. Sigtran Signalling network ............................................................................................. 6
2. Securing the different access types ............................................................... 71. Secured Corporate (Management or intranet) LAN access ............................................... 7
1.1. Assessing the Risks ............................................................................................... 71.2. Intranet Security Policy .......................................................................................... 71.3. Authentication and access control implementation ................................................. 81.4. Passwords management ....................................................................................... 91.5. Encryption & Integrity checking ............................................................................ 101.6. Network segmentation & Protocol filtering ........................................................... 101.7. Operating System hardening and services limitation on the servers ....................... 10
2. Secured User LAN access ............................................................................................ 102.1. Authentication and access control ....................................................................... 112.2. Web server implementation ................................................................................ 112.3. Restrict the traffic between the public network and the Corporate intranet .............. 122.4. Network segmentation ........................................................................................ 12
2.4.1. Servers in the DMZ ............................................................................................ 132.4.1.1. Reverse Proxy Server .........................................................................................132.4.1.2. Secure Reverse Proxy Server ...............................................................................13
2.4.2. DMZ Topology .................................................................................................. 132.4.2.1. Screened subnet Firewall ...................................................................................142.4.2.2. Multi-homed Gateway .......................................................................................152.4.2.3. Conclusion .......................................................................................................15
2.5. Security policy .................................................................................................... 162.6. Operating System Hardening and Services Limitation ........................................... 172.7. Double LAN for HTTP flow .................................................................................. 17
3. Secured OSP Private LAN access .................................................................................. 174. Secured Remote access for field support ....................................................................... 185. Secured access for Sigtran signalling network ............................................................... 18
3. Communication with the OSP ...................................................................... 191. Communication with the SMF ...................................................................................... 19
1.1. Intranet communication with the SMF based on SOAP .......................................... 191.2. Secured Internet communication with the SMF via a ‘Reverse PROXY’ .................... 19
1.2.1. Advantages ....................................................................................................... 201.2.2. Drawbacks ........................................................................................................ 20
1.3. Why SOAP for PC to SMF communication? .......................................................... 201.3.1.R easons of the choice .......................................................................................... 201.3.2. gsoap ............................................................................................................... 21
1.4. Java Web Start ................................................................................................... 21
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 1/42
April 20, 2006 ......................................................................
1.4.1. Difference between Java applications and Java applets ...................................... 211.4.2. Presentation of Java Web Start .......................................................................... 211.4.3. Signing ............................................................................................................. 22
1.4.3.1. Description .......................................................................................................221.4.3.2. Signed applet ...................................................................................................22
1.5. Intranet communication for OSP 2.4 Management Application .............................231.6. Secure communication for OSP 2.4 Management Application ...............................241.7. Thin client and mass access communication ........................................................28
1.7.1. Definition of thin client ...................................................................................... 281.7.2. Description of thin client .................................................................................... 281.7.3. Mass Access service presentation ....................................................................... 281.7.4. Communication process .................................................................................... 29
2. Communication with the SLEE ......................................................................................302.1. Communication with the SLEE via DPE router .......................................................302.2. Communication with the SLEE via SOAP ..............................................................31
2.2.1. Web service architecture .................................................................................... 312.2.2. Communication process .................................................................................... 32
4. Recommended Firewall solution ................................................................. 331. Simplex configuration ..................................................................................................332. Duplex configuration ...................................................................................................34
5. Alcatel Product Security Incident Response ................................................ 36
List of figures ...................................................................................................... 37
Index of Topics .................................................................................................... 38
Document References ......................................................................................... 41
2/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
Overview of the different LAN and access modes April 20, 2006
1. Overview of the different LAN and access modes
The OSP R2.4.02 provides four LAN and access modes depending on the needs:
Corporate (Management or intranet) LAN : access for service and platform management.
User LAN : access for service management (via SOAP on HTTP or HTTPS).
OSP Private Internal LAN: No external access, only used for OSP process inter-communication.
Remote access via PSTN or vLan for field support.
The figure below illustrates one possibility showing the different LAN and access modes:
Figure 1.1 - Different LAN and access modes
In a typical OSP configuration, the following networks are defined:
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 3/42
April 20, 2006 Overview of the different LAN and access modes
1. Corporate (Management or intranet) LAN access to OSP R2.4.02
This LAN is protected from the Internet by a DMZ (with a firewall + Reverse Proxy on dedicatedhardware). It supports a very limited set of protocols: HTTP, SIP, … This section presents the external (i.e.: from the public Internet) access to the OSP R2.4.02 viaSOAP on HTTP(s).
• The SOAP server sends the SOAP requests.• A JAVA signed applet is downloaded to the client PC from the HTTP to SOAP gateway. • The SOAP requests are sent to the SOAP servers of the SMP.• SOAP answers are sent to the client.
Figure 1.2 - Access to OSP from Internet via a reverse proxy
For security reasons, this document recommends to use a reverse proxy and a DMZ between thepublic Internet where the PC is located and the operator's network.
This architecture will be explained in “Secured User LAN access” on page 10.
Internet
SOAP Server
SMF 2
Internal
Network
DMZ
SMF 1
Firewall Reverse Proxy
Firewall
Soap bus
4/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
Overview of the different LAN and access modes April 20, 2006
2. User LAN access to OSP R2.4.02
This LAN is protected from the Internet by a DMZ (with a firewall + Reverse Proxy on dedicatedhardware). It supports a very limited set of protocols: HTTP, SIP, … This section presents the external (i.e.: from the public Internet) access to the OSP R2.4.02 viaSOAP on HTTP(s).
• The SOAP server sends the SOAP requests.• A JAVA signed applet is downloaded to the client PC from the HTTP to SOAP gateway. • The SOAP requests are sent to the SOAP servers of the SMP.• SOAP answers are sent to the client.
Figure 1.3 - Access to OSP from Internet via a reverse proxy
For security reasons, this document recommends to use a reverse proxy and a DMZ between thepublic Internet where the PC is located and the operator's network.
This architecture will be explained in chapter 2.2.
3. OSP Private LAN
This LAN is dedicated and reserved to OSP machines (no ip forwarding is allowed from thisnetwork to any other network). It supports all internal (and proprietary) protocols required by theOSP to provide high performance (pseudo real time) and high availability features: DPE on TCP,
Internet
SOAP Server
SMF 2
Internal
Network
DMZ
SMF 1
Firewall Reverse Proxy
Firewall
Soap bus
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 5/42
April 20, 2006 Overview of the different LAN and access modes
Netwatcher on IPMP, Snaphot on Oracle SQL-net, Remote commands (RSH), Decnet (OSP 2.3-HPonly), …This LAN is totally private and doesn't permit any access to perform service management. Via theMCP, it's possible to perform platform management on this private LAN.
See “Remote access for field support” on page 6.
4. Remote access for field support
The Alcatel Field Support Team ("FBI") requires a remote access to the Multi Control Point ("MCP")and to all OSP servers, to be able to provide the support and maintenance services described inthe SLA.
Please refert to the OSP_FieldSupportSecurity_ed1 which explains all the different accessways which are validated and supported.
5. Sigtran Signalling network
This LAN is a dedicated/private/secured network (like SS7). It supports only Sigtran (M3UA)protocols on SCTP.
6/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
Securing the different access types April 20, 2006
2. Securing the different access types
The four kinds of access described in “Secured Corporate (Management or intranet) LAN access”on page 7 have to be distinguished and secured:
• Corporate (Management or intranet) LAN : access for service and platform management.• User LAN : access for service management (via SOAP on HTTP or HTTPS-Proxy).• OSP Private Internal LAN : No external access, only used for OSP process inter-communication.• Remote access via PSTN or vLan for field support.
1. Secured Corporate (Management or intranet) LAN access
1.1.Assessing the Risks
As there is no connection with an IP external network, this architecture is not vulnerable to externalnetwork attacks.But some statistics show that risks coming from the internal network itself are significant.These risks come from employees themselves and from the use of the services. These risks are forexample loss of data or data corruption (intentionally or not).To limit these risks, an OSP access security policy has to be defined and followed by the customer.
1.2.Intranet Security Policy
The Intranet security policy is then a matter of Authentication and Authorisation, in order to limitthe risks coming from the internal users themselves.We distinguish two kinds of users:
• Unix users• OSP operators.
Standard Unix users are created with OSP R2.4.02 (root, linus, oracle).OSP operators are defined in the database of the OSP Access service.Alcatel provides OSP R2.4.02 with security implementations and recommends some networkarchitecture for accesses, but a security policy has to be defined by the customer (operator of OSPR2.4.02) and is under his responsibility.The following aspects (not exhaustive) have to be taken into account when defining an Intranetaccess security policy:
• How do users interact with the OSP?• Who is allowed to use the resources?• Who is authorised to grant access and approve usage?• Who may have system administration privileges?• What are the users' rights and responsibilities?• What are the rights and responsibilities of the system administrator vs. those of the user?• What do you do with sensitive information?
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 7/42
April 20, 2006 Securing the different access types
1.3.Authentication and access control implementation
OSP R2.4.02 provides a password-based authentication mechanism. Before executing anycommand on the OSP platform and services, every operator has to authenticate himself byentering a dedicated login and password and he has to gain access to operator commands on theservice objects. The service objects and methods may vary according to the operator's profile(access control). The Access service provides this authentication and authorisation mechanism.The Access service is a SOAP server that:
• supports login, logout, modify password, login forced password • binds and unbinds service factories • validates the service factory for the session • manages the timeout of a service factory, as defined on the operator screen (in minutes).
Any session is divided in three steps:• login• work• logout.
8/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
Securing the different access types April 20, 2006
Figure 2.1 - Commands flow of the Access service from the operator login.
1.4.Passwords management
The security policy can implement the password management in order to limit the risks ofimpersonation.The rules that follow are recognised standards for password syntax and management.
• DON'T use your login name in any form (as is, reversed, capitalised, doubled, etc.).• DON'T use your first, middle, or last name in any form or use your spouse or child's name.• DON'T use other information easily obtained about you. This includes telephone numbers, social security numbers, birthday dates, etc.• DON'T use a password of all digits, or all with the same letter.• DON'T use a word contained in English or foreign language dictionaries, spelling lists, or other lists of words.• DON'T use a password shorter than six characters.• Use a password with mixed-case alphabetic.• Use a password with non-alphabetic characters (digits or punctuation).• Use a password that is easy to remember, so you don't have to write it down.
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 9/42
April 20, 2006 Securing the different access types
1.5.Encryption & Integrity checking
As no access is performed from external IP networks and the local network is considered as a safeplace, no specific transmission encryption and integrity checking is needed.
1.6.Network segmentation & Protocol filtering
The management PC accesses the SOAP bus of OSP R2.4.02. Furthermore, switches are used inplace of hubs to limit the ability of hosts to receive network traffic that is not specifically directed tothem.
1.7.Operating System hardening and services limitation on the servers
All OSP servers are hardened. Only necessaries packages are installed on the machines. Securitypatches concerning the software installed on the servers are taken into account in each newBaseline release. Only the services necessary to the OSP are running on the servers. Other specific settings areimplemented to improve the security. A host based firewall (SunScreen) can be implemented on each server connected to the corporateintranet.
This information is part of the following Alcatel internal documents which can be obtainedon request:
Baseline (for OS minimization and security patches)Factory Settings (system hardening is part of "security sheet")
2. Secured User LAN access
When a service or a set of services running on OSP R2.4.02 need to be accessed and managed byoperators or end-users over the Internet, web servers can be used to access OSP. The serversbecome public web servers.These web servers are gateways that perform the translation between the protocols used onInternet (HTTP and HTTPS in particular) and the interfaces of OSP R2.4.02 (SOAP).The solutions presented hereafter are implemented or recommended in order to secure the HTTPto SOAP.First, the document describes how authentication and access control are ensured for both accesstypes.In a second step, the document describes the solution implemented to ensure data transferencryption over the Internet.Then the need of access filtering using firewalls as well as the need to insert a Demilitarised Zoneis described.Finally, a global security policy is proposed.
10/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
Securing the different access types April 20, 2006
2.1.Authentication and access control
The same authentication and access control mechanisms than in the Intranet access are provided(See “Recommended Firewall solution” on page 33.).The picture below describes the exchanges.
Figure 2.2 - Overview of an Internet access to OSP R2.4.02 via SOAP on HTTP
2.2.Web server implementation
The following picture shows a possible configuration of an OSP WEB server with its DMZs betweenFirewall 1 and Firewall 2. In this picture, the DMZ plays a role of Reverse Proxy (HTTPS-HTTP),checks the Client Certificated and is a repository of Application Jar files, Java Server Pages.
Client Reverse Proxy
SOAP server SMP
HTTPS request (login+pwd) HTTP(S) request
(login+pwd)Soap connection phase
HTTPS response HTTP(S) response
HTTPS request(gcc command)
HTTPS response HTTP(S) response
HTTP(S) request(toc command)
Soap command phase
HTTPS request(gcc disconnect)
HTTPS response HTTP(S) responseSoap disconnect phase
HTTP(S) request(toc disconnect)
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 11/42
April 20, 2006 Securing the different access types
Figure 2.3 - Possible configuration of an OSP WEB server with its DMZs between Firewall 1 and Firewall 2.
2.3.Restrict the traffic between the public network and the Corporate intranet
To secure the network access, the web server(s) must be separated from the Internet by a Firewallsolution. It allows restricting the traffic between the external network and the Corporate intranet. Itthen prevents from many possible attacks, but it still allows anyone to access the authorisedservices on the web server.
2.4.Network segmentation
As the web server is a (set of) computer(s) intended for public access, there are potentially a lot ofpeople that can access or try to access this server from locations all over the world.Even if the access to the web server is protected by a firewall and if the server and its applicationsare correctly configured (according to the security requirements), there is always a risk that a newvulnerability appears and that someone tries to exploit it on your web server.If it occurs, we need to prevent the intruder from observing or capturing the internal OSP IP traffic,performing denial of service attacks in the internal network or obtaining information on servers ofthe internal OSP platform.To guard against these threats, the public web server(s) must be isolated from the OSP and thecorporate internal networks as well as from the public network (the Internet).
12/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
Securing the different access types April 20, 2006
A network has then to be added between the internal network with sensible data (OSP platform)and an external network (the Internet) in order to provide an additional layer of security. It forms aDemilitarised Zone (DMZ), which prevents the external network from directly referencing theinternal network.The DMZ is delimited by the firewalls that filter the access from the external network to the DMZand by a firewall that filter the access from the DMZ to the internal network.
2.4.1. Servers in the DMZ
The only servers allowed in the DMZ are gateways that perform HTTP/HTTPS to HTTP relay. Theseservers are called reverse proxy servers or secure reverse proxy servers. End-users have only accesswith http or preferably https flows to the server(s) in the DMZ that translate the commands onanother protocol(s) and on a different sub-network. It significantly limits network access.
2.4.1.1. Reverse Proxy Server
A Reverse Proxy Server (RPS) accepts requests from clients located on the Internet for the local webservers. Reverse Proxy Servers are generally used as part of the security infrastructure. They are typicallyplaced between the Firewall servers and the Web server farm. The RPS receives all of the HTTPrequests passing through the firewall and passes them to the Web Server farm, thus preventingdirect client access to the Web servers, and consequently hiding the identity of the Web servers.An RPS provides protection from attacks that are launched to take advantage of vulnerability suchas buffer overflow, malformed packets, etc. Thus, the reverse proxy can protect a normallyvulnerable Web server.In addition, an RPS could be load balanced using NLB service, clustering technology, or a load-balancing appliance.
2.4.1.2. Secure Reverse Proxy Server
A secure reverse proxy server is the name given to an RPS like described above when it is usingHTTPS / SSL to communicate with the clients located on the Internet. This adds another tier to thesecurity architecture.
2.4.2. DMZ Topology
Two topologies are possible:• Screened Subnet Firewall• Multi-Homed Gateway Firewall
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 13/42
April 20, 2006 Securing the different access types
2.4.2.1. Screened subnet Firewall
Figure 2.4 - Example of screened subnet firewalls
The screened Subnet firewalls provide the most secured topology: a DMZ is inserted between theinternal network and the untrusted network. The outer firewall only permits access from the outsidenetwork (Internet) and the bastion host(s) (Web servers). The inner firewall only permits accessfrom internal network (OSP platform LANs) to the bastion host(s).Since the outer router only advertises the DMZ to the untrusted network, a host on the Internetcannot reach the internal network. The inner firewall advertises the DMZ to the internal network, itis not possible to reach the external network from the internal one.In this case, an intruder has to penetrate 3 separate systems to reach the internal network.
Advantages
Safer because there are two physically separate layers
Drawbacks
ExpensiveMore difficult to manage
Internet
Firewall
Firewall
ReverseProxyServer
SMF SLEE
Screened Subnet
Private Network
UntrustedNetwork
14/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
Securing the different access types April 20, 2006
2.4.2.2. Multi-homed Gateway
Figure 2.5 - Multi-homed gateway
In case of Multi-homed gateway as described in the above picture, the same firewall having twoconnections with the DMZ replaces the firewall pair in the screened subnet firewall case.
Advantages
• Safer than Dual Home Gateway topology• Management
Drawbacks
The Central Gateway can become a bottleneck or single point of failure. Note that the Highavailability system answers this problem.
2.4.2.3. Conclusion
The multi-homed gateway is the recommended implementation of a DMZ, because it represents agood compromise between security, complexity (configuration and management) and cost.
Internet
Firewall
ReverseProxyServer
SMF SLEE
UntrustedNetwork
Secured Network
DMZ
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 15/42
April 20, 2006 Securing the different access types
2.5.Security policy
The security policy defines the services that must be explicitly allowed by the firewalls. All othernetwork services are then denied.The firewall must accept TCP connection on port 80 for HTTP and TCP connection on port 443 forSSL between the external network and the DMZ.Furthermore, filtering rules have to be established to block TCP connection originating from webserver to the external network. The reverse proxy server within the DMZ has only access via SOAP on HTTP located on the internalnetwork. The firewall must accept TCP connection on port 80 (or another port) for HTTP betweenthe DMZ and the internal network.The firewall technology must also be configured to block all the possible traffic between theinternal network and the external network and vice versa. The following table sums up theconfiguration of the multi-homed firewall.
Table 1: The configuration of the multi-homed firewall.
Sourceaddress
Destination address
Source port
Destination port
Service Protocol A/D
Any Reverse Proxy >1023 443 HTTPS TCP Allowed
Any Reverse Proxy >1023 80 HTTP TCP Allowed
Any Reverse Proxy >1023 8050 SOAP on HTTPS
TCP Allowed
Reverse Proxy
Any 80 >1023 HTTP TCP Allowed
Reverse Proxy
Any 443 >1023 HTTPS TCP Allowed
Reverse Proxy
Any 8050 >1023 SOAP on HTTPS
TCP Allowed
Reverse Proxy
HTTP/SOAP GW
* 8088 HTTP TCP Allowed
HTTP/SOAP GW
Reverse Proxy * 8088 HTTP TCP Allowed
Reverse Proxy
LDAP SERVER * 389 LDAP TCP Allowed
LDAP SERVER
Reverse Proxy * 389 LDAP TCP Allowed
Reverse Proxy
OSP SMF * 22 SSH TCP Allowed
OSP SMF Reverse Proxy * 22 SSH TCP Allowed
16/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
Securing the different access types April 20, 2006
2.6.Operating System Hardening and Services Limitation
All OSP servers are hardened. Only necessary packages are installed on the machines. Securitypatches concerning the software installed on the servers are taken into account in each newBaseline release. Only the services necessary to the OSP are running on the servers. Other specific settings areimplemented to improve the security. For the Web Servers, they are more services removed than for OPS servers (see Factory Settings)A host-based firewall (SunScreen) can be implemented on each server connected to the corporateintranet.
This information is part of the following Alcatel internal documents which can be obtainedon request:
Baseline (for OS minimization and security patches)Factory Settings (system hardening is part of "security sheet")
2.7.Double LAN for HTTP flow
In order to support Ethernet switch failure (LAN failure), the System should manage a double LANbetween the external network and the reverse proxies in the DMZ.Furthermore, a double LAN should be managed between the reverse proxies in the DMZ and theHTTP gateways of OSP R2.4.02.The "duplex configuration" based on CheckPoint product (See “Alcatel Product Security IncidentResponse” on page 36.) is compliant to this requirement
3. Secured OSP Private LAN access
No firewalls are deployed on this private LAN. In case this private LAN is interconnected via aWAN (Mated Pair configuration), it is up to the customers to protect the OSP private LAN from theirWAN.
Reverse Proxy
OSP SMF * 123 NTP TCP Allowed
OSP SMF Reverse Proxy * 123 NTP TCP Allowed
Else : DENIED
Table 1: The configuration of the multi-homed firewall.
Sourceaddress
Destination address
Source port
Destination port
Service Protocol A/D
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 17/42
April 20, 2006 Securing the different access types
4. Secured Remote access for field support
Please refer to the OSP_FieldSupportSecurity_ed1 that explains all the different securedaccess ways which are validated and supported.
5. Secured access for Sigtran signalling network
This security lets to the owner of the sigtran signalling network.
18/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
Communication with the OSP April 20, 2006
3. Communication with the OSP
This chapter describes the different communications with the OSP, including security issues.A communication can be established:
•between a PC and an SMF, or•between a PC and a SLEE.
The SMF servers handle management messages and run on an SMF. The communication with theSMF is always SOAP-driven (Simple Object Access Protocol). SOAP messages are created by theclient and enter the OSP by going through the SOAP FEP, which forwards the message to the rightSMF server. The communication with a SLEE can be established through the DPE Router. A SEP located on aSLEE SMF can also receive SOAP messages through the SOAP FEP. Mass access is managed by a dedicated service and also uses SOAP protocol.
1. Communication with the SMF
This section describes the two main ways to communicate with the SMF.• Intranet communication with SMF based on HTTP SOAP, using a Java Web Start application.• Secured Internet communication with SMF through a 'Reverse Proxy' using either a Java Web Start signed application or a project-based thin client.
1.1. Intranet communication with the SMF based on SOAP
A direct communication based on SOAP is established between the PC and the SMF. For securityreasons, it is mainly used for intranet purposes. By default, the SOAP technology uses HTTPtransport, which does not encrypt data and is thus not secured. For secure communications,HTTPS must be used.The SOAP messages are generated by the OSP management application, which uses the JavaWeb Start technology. This application is installed on operator PC when connecting for the firsttime to the OSP Web server.SOAP messages are received by a SOAP FEP, which forwards them to the right SMF Server.
1.2. Secured Internet communication with the SMF via a ‘Reverse PROXY’
In this secured mode, two different ways of communication can be distinguished.• using a JAVA application• using a thin client.
In order to provide data encryption during communication with SMF, the HTTPS communicationprotocol is used to communicate with a reverse proxy. The reverse proxy will translate the HTTPSmessage into a HTTP message and forward it to the SOAP FEP.
Security Guidelines 3CL-02350-BBXX-BGZZA 19/42
April 20, 2006 Communication with the OSP
1.2.1. Advantages
• secured communication, encrypted with standard SSL (Secured Socket Layer).• firewall possibilities: there is only one port needed because of http(s). Internet communication is possible. Another port must be opened to receive direct notifications from the SMF, such as session timeout or alarms monitoring.• HTTPS has a tradition to scale to high volume communication
1.2.2. Drawbacks
• the response time increases because of encryption• the performance is reduced because of encryption• resources consumption is higher on PC and HTTPS server.
1.3. Why SOAP for PC to SMF communication?
1.3.1. Reasons of the choice
The choice of using the SOAP protocol for remote procedure calls (RPC) in Release 2.4 is justifiedby the following points:
• CORBA uses several ports to communicate. In Rel 2.3, Corba was used for communication between SMF and management PC. Corba needs to keep several ports opened to work, which is a problem for secure communications, through a DMZ (demilitarized zone) for instance. SOAP uses HTTP transport, which only needs 1 port opened. The HTTP-to-Corba gateway that was needed to go through firewalls caused strong decrease in Rel 2.3 performance. This gateway is not needed in the Rel 2.4 architecture.• A standard to define interfaces: the SOAP clients and servers are generated by WSDL files. WSDL is becoming the standard for web services definition. The standard is defined and maintained by W3C Organisation, which also defines and maintains other widely used technologies such as HTTP or XML.• An open and interoperable architecture: through WSDL files, SOAP clients and servers can be created independently on both sides, whatever the technology (C++, Java, .NET, MS Office,..), and can communicate easily thanks to XML encoding.• Based on robust technologies: SOAP uses XML encoding on HTTP transport. These two technologies have a proven record of value and efficiency.• Web services growth: Web services become more and more present across the Internet. The use of SOAP in OSP creates a link between IT and telephony.• Support in JAVA: the Web Service Development Pack from Sun provides tools to easily generate and deploy SOAP clients and servers. The only input needed is the WSDL file.• Support in Microsoft .NET® and MS Office® products: recent Microsoft® products fully support SOAP messages by providing the WSDL file.
20/42 3CL-02350-BBXX-BGZZA Security Guidelines
Communication with the OSP April 20, 2006
1.3.2. gsoap
The SOAP stack used in SMF servers is gSoap. This stack proves to be reliable and provides goodinteroperability with other stacks. The design is simple and efficient. It integrates easily with theplatform since it is an open source product. Updates are frequent and include bug fixes andprotocol evolutions.It is directly integrated in the SMF server processes. The OSP toolchain automatically generates theserver and WSDL files.
1.4. Java Web Start
The communication between PC and SMF is made by exchanging SOAP messages. A brand newJava application is provided to easily generate the SOAP requests by simply filling fields in theapplication GUI (Graphical User Interface).This management application and its components are stored on the OSP web server. This includesseveral Jar files (Java classes containers), deployment scripts (JNLP files) and properties files.The operator can install the application automatically, by downloading the main deployment scriptlocated on the web server through a browser.After the application is installed, no browser is needed anymore: the PC to SMF communicationhappens through the management application.
1.4.1. Difference between Java applications and Java applets
A standard Java application is made of 'class' files, which may be zipped into JAR files. Anapplication runs by starting a Virtual Machine, providing the classes and specifying the class torun. This requires a copy of the application on the local drive or network. Such applications havethe right to do anything on your computer because the user is supposed to know the applicationand trust it.Applets are applications that are located on a web server and are downloaded before runninginside your browser. The application is not installed on the local drive; it is always up-to-date, sincethe user has to download it every time it has to be executed. But the download time can beimportant for complex applications. Moreover, you must use a browser to run the applet.Standards applets have restricted rights on the local computer since it can come from an untrustedsource.
1.4.2. Presentation of Java Web Start
Java Web Start is a technology developed by Sun Microsystems and available in the standard JavaRuntime Environment 1.4.2, and later. It gives the opportunity to mix both application and applettechnologies. A standard application is created, packaged in one or several JAR files and storedon a web server. The application and its content are described in deployment scripts in JNLP (JavaNetwork Launching Protocol) format. They contain the list of files, the parameters of theapplication and the context to execute it. Once a Java Runtime Environment 1.4.2 or later is installed, the user's PC is able to recognizeJNLP files downloaded from the Internet, through a MIME association. After the JNLP file isdownloaded, Java Web Start downloads all the JAR files needed by the application. If the JAR files
Security Guidelines 3CL-02350-BBXX-BGZZA 21/42
April 20, 2006 Communication with the OSP
have already been downloaded before, Java Web Start only downloads new files or files that havechanged since last execution. The application runs on the local PC when the cache is up to date.The Java Web Start technology allows having a large application that is easily deployed and isconstantly updated. More specifically, the OSP management application is described in a JNLP filelocated on the OSP web server. The first launch of the application may take a long time since itneeds to be fully downloaded and put into cache, but next executions will start faster than with anapplet, while staying fully in line with the software stored on the SMF.
1.4.3. Signing
1.4.3.1. Description
Applets or Java Web Start applications are downloaded from the Internet. As such, they come froman untrusted and potentially harmful environment. For this reason, downloaded software runs bydefault into a restricted environment where it is not possible to access local resources (drives,printers…).Signing is a technology developed to increase the confidence in downloaded code and to lift somelimitations of the runtime environment. In the case of the OSP management application, acertificate allows lifting all limitations, with the user's agreement: the application can then storeand load data on local drives, print documents, access the clipboard…
1.4.3.2. Signed applet
A signed applet or signed application is an applet or application with a digital signature thatserves two main purposes:
• it identifies the applet or application signer, who should be the person or organisation that developed this applet or application.• it prevents tampering by detecting if the applet or application has been modified by someone other than the signer.
The applet or application and a signature are separate pieces of information. An ordinary appletor application becomes signed when it is bundled together with a certificate. This implies thatwhether an applet or application is signed does not depend on the applet or application code.Using a signed application implies that the application code is granted access to the resources ofthe PC. This means that the application can have access to the file management, printmanagement and communication management. An ordinary application started with Java WebStart is only allowed to perform display activities.Before using a signed application, the user must grant the privileges the certificate asks for. This isdone when the application starts.
Signing application is only needed when the application is downloaded (Java Web Starttechnology). If the same application starts from the local drive or network, no certificate is neededto access computer resources.
22/42 3CL-02350-BBXX-BGZZA Security Guidelines
Communication with the OSP April 20, 2006
1.5. Intranet communication for OSP 2.4 Management Application
The OSP is managed by sending SOAP commands to the SMF. This is done by using the OSP 2.4management application. This application is deployed using the Java Web Start technologydescribed above.
Figure 3.1 - Client PC to SMP communication based on SOAP and using a signed application deployed by Java Web Start
Legend: The table below describes the communication process. The circled figures in the pictureabove correspond to the Stage numbers below.
Table 1: Legend of Figure 3.1 - Communication process .
Stage Description
1 The Java Web Start deployment script (JNLP files) is downloaded from the OSP Web server by
• the Java Web Start Application Manager (1a) or • a browser (1b).
2 A Java Web Start execution environment starts, with the JNLP files as parameters.
3 The Java Web Start execution environment checks the cache.
4 All jar files that are described in the JNLP files must be in cache. Missing files and files that are not up-to-date are downloaded from the Web server by the Java Web Start execution environment.
5 The Java Web Start execution environment executes the application.
PC
JVM 1.4.2 or later
Browser
Java WebStartApplication Manager
Cache
Java WebStartExecution Environment
OSP 2.4 ManagementApplication
Web Server
SMF
SOAP
FEP
SMF
SERVER
JNLP Files
Application JARFiles Repository
HTTP
HTTP
HTTP
HTTPSOAP
HTTPSOAP
TCP/IP XML
DPEXML
DPEXML
1a
1b
4
2
3
5
6
6
7
7
8
Intranet
Intranet
8
PC
JVM 1.4.2 or later
Browser
Java WebStartApplication Manager
Cache
Java WebStartExecution Environment
OSP 2.4 ManagementApplication
Web Server
SMF
SOAP
FEP
SMF
SERVER
JNLP Files
Application JARFiles Repository
HTTP
HTTP
HTTP
HTTPSOAP
HTTPSOAP
TCP/IP XML
DPEXML
DPEXML
1a
1b
4
2
3
5
6
6
7
7
8
Intranet
Intranet
8
Security Guidelines 3CL-02350-BBXX-BGZZA 23/42
April 20, 2006 Communication with the OSP
The web server and the SMF can be located on the same machine or on different machines.In this situation, port 80 is used for HTTP communications between PC and web server. Port 8088is used for SOAP communications between PC and SOAP FEP.In OSP 2.4, the SMF is able to send messages to a PC. The messages are addressed to a specificclient session on that PC. This means that a session must be opened for the PC to receivemessages from the SMF. Such messages are needed for alarm monitoring, session timeoutnotifications, and so on. To receive these messages, some ports are allocated on the management PC. One port is used foreach session running on the PC, starting from port 8088. This means that if you have a PCrunning 3 sessions, ports 8088, 8089 and 8090 will be allocated for monitoring messages.It is possible to run local management sessions. In that case, you don't need any connection to theSMF.However, the login used for the local session must have been used at least once on that PC before,so that the profile rights of the operator are stored on the local machine.At the end of a local session, the user has the choice to save the SOAP commands generated in afile for later execution, or to log to the SMF and execute them at once.It is also possible to install the application without web access, from a CD or a LAN, for example.This is useful when the connection is slow. In that case, it is not possible to make any upgrade fromthe Web server. A new CD must be provided for every upgrade.
1.6. Secure communication for OSP 2.4 Management Application
The OSP 2.4 management application is also able to generate SOAP commands over HTTPS. Thismeans that the SOAP messages are secured by SSL encryption over HTTP. The confidentiality of theinformation contained in the SOAP message is then guaranteed.
The Java classes generate a SOAP request that is sent through the FEP SOAP to an SMF Server.
The SMF Server sends the SOAP answer through the FEP SOAP to the client PC. The answer is handled by the Java classes.
The SMF sends a notification or a monitoring message to the PC (see below).
Table 1: Legend of Figure 3.1 - Communication process (Continued).
Stage Description
24/42 3CL-02350-BBXX-BGZZA Security Guidelines
Communication with the OSP April 20, 2006
Figure 3.2 - PC communication with SMF through a reverse proxy using HTTPS
A reverse proxy is used to mask the SMF and/or the Web server from the application user, but alsoto transform HTTPS into HTTP. The functions assumed by the reverse proxy are:
• Hide the OSP network from the untrusted environment.• HTTPS to HTTP gateway. The reverse proxy must transform the encrypted message (HTTPS) so that the SOAP FEP can manage it. The SOAP FEP is only able to handle HTTP messages. • Firewall. Protects the OSP network from external attacks. Some specific ports must be opened in the firewall (see next paragraph for more information).• Load balancing. The messages coming from the external world can be distributed to several SOAP FEPs. This is particularly useful for mass access.
Firewall and load balancing functions are not required functions. In the previous figure, thereverse proxy can assume all or only some of the functions. The Web server can be behind areverse proxy or not.Legend: The table below describes the communication process. The circled figures in the pictureabove correspond to the Stage numbers below.
Table 2: Legend of figure 3.2 - Communication process .
Stage Description
1 The Java Web Start deployment script (JNLP files) is downloaded from the OSP web server by
• the Java Web Start console (1a) or• a browser (1b).
2 A Java Web Start execution environment starts, with the JNLP files as parameters.
DMZWeb Server
JNLP Files
Application JARFiles Repository
HTTP
HTTPHTTP
HTTP
HTTP
TCP/IP XML
1b
PC
JVM 1.4.2 or later
Browser
Java WebStartApplication Manager
Cache
Java WebStartExecution Environment
OSP 2.4 ManagementApplication
2
3
5
SMF
SOAPFEP1
SMF
SERVER
DPE
DPE
7
8
10
SOAPFEP2
ReverseProxy
ReverseProxy
4
1a
1b
77
DPE78
HTTP
9
10
4
6
INTERNET
INTRANET
INTRANET
HTTP(S)
HTTP(S)
HTTP(S)
HTTP(S)
HTTP(S)
TCP/IP XML
1a
Firewall Firewall
DMZWeb Server
JNLP Files
Application JARFiles Repository
Web ServerJNLP Files
Application JARFiles Repository
HTTP
HTTPHTTP
HTTP
HTTP
TCP/IP XML
1b
PC
JVM 1.4.2 or later
Browser
Java WebStartApplication Manager
Cache
Java WebStartExecution Environment
OSP 2.4 ManagementApplication
2
3
5
SMF
SOAPFEP1
SMF
SERVER
DPE
DPE
7
8
10
SOAPFEP2
ReverseProxy
ReverseProxy
4
1a
1b
77
DPE78
HTTP
9
10
4
6
INTERNET
INTRANET
INTRANET
HTTP(S)
HTTP(S)
HTTP(S)
HTTP(S)
HTTP(S)
TCP/IP XML
1a
Firewall Firewall
Security Guidelines 3CL-02350-BBXX-BGZZA 25/42
April 20, 2006 Communication with the OSP
Stage 10 is optional. The firewall can be configured to block the messages coming from the SMF.It depends on the functionality needed in the untrusted area. If no monitoring or notification isneeded, these messages can be blocked.The reverse proxy must be configured to transform HTTPS messages (port 443) to HTTP messageson port 8088, because the SOAP FEP is only able to understand HTTP messages emitted on thatport. Firewalls must also be configured to let messages go through these ports. If the firewall is betweenthe reverse proxy and the PC, port 443 must be opened from PC to SMF. If the firewall is betweenthe reverse proxy and the SOAP FEP, port 8088 must be open from PC to SMF.For communication with the web server, port 80 must be opened for communication from PC toSMF. If HTTPS is also used on the web server, port 443 must be opened. If the client PC needs monitoring or SMF notifications (such as session timeout), port 8088 must beopened from SMF to PC also. If several client sessions must be opened for monitoring or SMFnotifications from the same PC, the same number of ports must be opened from SMF to PC,starting from 8088. Monitoring messages and SMF notifications are not encrypted.Example 1:You have 2 PCs running the management application. The first PC uses one client session withoutmonitoring. The second PC uses 3 client sessions without monitoring. The following ports must beopened in the firewall:
3 The Java Web Start execution environment checks the cache.
4 All jar files that are described in the JNLP files must be in cache. Missing files and files that are not up-to-date are downloaded from the web server by the Java Web Start execution environment.
5 The Java Web Start execution environment executes the application.
6 The JAVA classes generate a SOAP request that is sent through the Internet to a reverse proxy.
7 The reverse proxy transforms the HTTPS request into a HTTP request. The request is then sent to a SOAP FEP according to load balancing rules.
8 The SMF Server sends the SOAP answer through the SOAP FEP to the reverseproxy.
9 The reverse proxy encodes the HTTP SOAP message into a HTTPS SOAP messageand forwards it to the client PC. Answer is treated by the JAVA classes.
10 The SMF sends a notification or a monitoring message to the PC. This messagecan be blocked by the firewall function of the reverse proxy according to theopened ports (see below).
Table 2: Legend of figure 3.2 - Communication process (Continued).
Stage Description
26/42 3CL-02350-BBXX-BGZZA Security Guidelines
Communication with the OSP April 20, 2006
Example 2:You have 2 PCs running the management application. The first PC uses one client session withmonitoring. The second PC uses 3 client sessions, with 1 monitoring session. The following portsmust be opened in the firewall:
Example 3:You have 2 PCs running the management application. The first PC uses the one client session withmonitoring. The second PC uses 3 client sessions, with 3 monitoring session. The following portsmust be opened in the firewall:
If HTTPS is used, port 443 must also be opened in the previous tables.
Table 3: Example 1
Port Direction
80 PC to SMF.
8088 PC to SMF.
Table 4: Example 2
Port Direction
80 PC to SMF.
8088 Both directions.
Table 5: Example 3 .
Port Direction
80 PC to SMF.
8088 Both directions.
8089 SMF to PC.
8090 SMF to PC.
Security Guidelines 3CL-02350-BBXX-BGZZA 27/42
April 20, 2006 Communication with the OSP
1.7. Thin client and mass access communication
1.7.1. Definition of thin client
We call 'thin client' a client that requires little resource from the local computer. We are usuallytalking about HTML pages for thin client management. It is most of the time used for subscriberaccess, which therefore means mass access to the SMP with few commands per session.OSP 2.4 offers a new service dedicated to high management traffic, called Mass Access(pfmmassaccess).
1.7.2. Description of thin client
Thin client pages may be plain HTML pages located in a Web server and containing the SOAPrequests, but they are most often generated by some tools, such as HTTP servlets or JSP. Whateverthe technology used to get the HTML pages, they have to generate SOAP requests that the SOAPFEP can understand and route to the mass access server.
1.7.3. Mass Access service presentation
The Mass Access service maintains a small number of pfmaccess sessions to create a profile andmanagement context shared among a number of mass access users (we assume a large numberof users). The pfmaccess sessions created by the Mass Access service have the authorisation toaccess several SMF servers of the same service. When trying to send SOAP commands, a MassAccess user directly addresses the Mass Access service, which performs an authentication based ona LiteSCE script. The service then gives the user access to one of the pfmaccess sessions itmaintains.
28/42 3CL-02350-BBXX-BGZZA Security Guidelines
Communication with the OSP April 20, 2006
1.7.4. Communication process
Figure 3.3 - Mass access communication from a thin client page to the SMF through a revers proxy using HTTPS
Legend: The table below describes the communication process. The circled figures in the pictureabove correspond to the Stage numbers below.
Table 6: Legend of figure 3.3 - Communication process .
Stage Description
1 A user wants to post some data. An html page in the browser sends the data to the OSP web server. The request is encrypted in HTTPS.
2 The reverse proxy forwards the message in HTTP to the web server.
3 Optional step: the code is provided as a JavaServer Page (jsp) and requires to be compiled to a servlet (Tomcat).
4 A SOAP request is needed. Local jar files contain the stubs.
5 The SOAP request is sent to the SMF.
6 The SOAP FEP routes the message to the Mass Access Service.
7 The Mass Access service authenticates the user and forwards themessage to the right SMF server.
8 The response is sent to the SOAP FEP.
9 The response is forwarded to the servlet engine.
DMZWeb Server
Servlet Engine (TomCat)
Application JARFiles Repository
PC
Browser
SMF
SOAP FEP
SMF SERVER
ReverseProxy
HTTPS
MASS ACCESS SEP
JavaServerPages
2
11 10
1
4
3
SOAP DPE
SOAP DPE
SOAPDPE
SOAP HTTP
INTRANET
INTERNET
HTTP
HTTPSHTML
HTTP HTML
5 9
86
7
Firewall Firewall
DMZWeb Server
Servlet Engine (TomCat)
Application JARFiles Repository
PC
Browser
SMF
SOAP FEP
SMF SERVER
ReverseProxy
HTTPS
MASS ACCESS SEP
JavaServerPages
2
11 10
1
4
3
SOAP DPE
SOAP DPE
SOAPDPE
SOAP HTTP
INTRANET
INTERNET
HTTP
HTTPSHTML
HTTP HTML
5 9
86
7
DMZWeb Server
Servlet Engine (TomCat)
Application JARFiles Repository
PC
Browser
SMF
SOAP FEP
SMF SERVER
ReverseProxy
HTTPS
MASS ACCESS SEP
JavaServerPages
2
11 10
1
4
3
SOAP DPE
SOAP DPE
SOAPDPE
SOAP HTTP
INTRANET
INTERNET
HTTP
HTTPSHTML
HTTP HTML
5 9
86
7
Firewall Firewall
Security Guidelines 3CL-02350-BBXX-BGZZA 29/42
April 20, 2006 Communication with the OSP
2. Communication with the SLEE
For some applications, it may be interesting to access the service script in the SLEE directly via theDPE Router. It is also possible to access a SEP located in a SLEE via SOAP.
2.1. Communication with the SLEE via DPE router
In order to be able to directly access the service script in the SLEE, a secured Internetcommunication can be setup between a thin client PC and the SLEE via the DPE Router.
Figure 3.4 - Secured Internet thin client communication with the SLEE through an HTTP-to-DPE gateway
Legend: The table below describes the communication process. The circled figures in the pictureabove correspond to the Stage numbers below.
10 An HTML page based on the SOAP response is created by the servletand sent to the browser over HTTP.
11 The HTML page is encrypted in HTTPS.
Table 6: Legend of figure 3.3 - Communication process (Continued).
Stage Description
Internet
Secured (SSL)
Firewall
Demilitarised Zone
HTTP(S) request
HTTP(S) answer
HTMLPage
Servlet
HTTP(S)Server(Html Page)
DPE answer
toHTTP answer
HTTP requestto
DPErequest
11
2 23
455
SLEE
DPERouter
30/42 3CL-02350-BBXX-BGZZA Security Guidelines
Communication with the OSP April 20, 2006
In this mode, • the security is guaranteed due to SSL encryption• firewall possibility is available• no certification is needed• mass access is possible• servlet/html page has to be developed and is service specific.
2.2. Communication with the SLEE via SOAP
SOAP requests can be sent directly to a SEP located in a SLEE SMF. This possibility is used inparticular by web services.
2.2.1. Web service architecture
From an architectural point of view, a Web service in the OSP is simply a standard servicereceiving an object encoded in a SOAP message. The way of working is the same as with otherservices.A standard service, using DPE encoding for objects, can be easily transformed into a web serviceby simply inserting the SIB that decodes the object from a SOAP message. This way you can havea service triggered by DPE messages, SOAP messages or both.The SOAP message must first come to the SOAP FEP that will forward it to the right SEP. Themessage arrives in the SEP, is decoded and transformed into a standard object. The rest of theservice can handle the object indifferently, whether it comes from a SOAP or DPE message.
Table 7: Legend of figure 3.4 - Communication process .
Stage Description
1 HTML Page is downloaded from HTTP(S) server.
2 HTTP(S) requests are generated by the browser. HTTP(S) requests are sent through the Internet and a firewall to the DMZ (demilitarised zone) where they are decrypted.The 'HTTP-to- DPE gateway' is a servlet translating the HTTP requests into DPE requests.
3 DPE requests are sent to the SLEE via the DPE router.
4 DPE answers are sent to the 'HTTP-to-DPE gateway'. The servlet translates the DPE answers into HTTP anwers.HTTP answers are encrypted into HTTP(S).
5 HTTP(S) answers are sent through the firewall on the Internet to the client PC. The answer is managed by the browser.
Security Guidelines 3CL-02350-BBXX-BGZZA 31/42
April 20, 2006 Communication with the OSP
2.2.2. Communication process
Figure 3.5 - Secured Internet thin client communication with SLEE using SOAP with HTTPS through a reverse proxy
Legend: we do not develop the thin-client architecture that has already be discussed in the previouspages. We limit the description to the process of a client sending a SOAP message.
Table 8: Process of a client sending a SOAP message .
Stage Description
1 A thin client emits a SOAP request, encrypted in HTTPS.
2 The reverse proxy transforms the message into an HTTP message.
3 The SOAP FEP routes the message to the right SEP.
4 The Web Service SEP sends the response to the SOAP FEP.
5 The SOAP FEP forwards the message in HTTP.
6 The reverse proxy encodes the message in HTTPS.
7 Another SEP in the network sends an object to the Web Service SEP. The DPE object is treated the same way as the object encoded in a SOAP message.
8 The response is sent through DPE.
DMZ
PC
BrowserReverseProxy
SOAPHTTPS
6
1
SLEE
SOAP FEP
Standard SEP
Web Service(SOAP-enabled SEP)
8
SOAP DPE
SOAP DPE
INTERNET
SOAPHTTP
INTRANET
4
7
2
5
3
Authentication(LDAP)
Accounting
Authorisation
FirewallFirewall
SOAPHTTP
SOAPHTTPS
DMZ
PC
BrowserReverseProxy
SOAPHTTPS
6
1
SLEE
SOAP FEP
Standard SEP
Web Service(SOAP-enabled SEP)
8
SOAP DPE
SOAP DPE
INTERNET
SOAPHTTP
INTRANET
4
7
2
5
3
Authentication(LDAP)
Accounting
Authorisation
FirewallFirewall
SOAPHTTP
SOAPHTTPS
32/42 3CL-02350-BBXX-BGZZA Security Guidelines
Recommended Firewall solution April 20, 2006
4. Recommended Firewall solution
This chapter describes the firewall solution validated and supported by Alcatel.The firewall and secure reverse proxy are implemented on a simplex or duplex Intel 32 bitmachine (HP or Sun) running the CheckPoint VPN-1/FireWall-1 software. The duplex is a multientry point, where there is no single point of failure. Alcatel has validated the CheckPoint product(See “Alcatel Product Security Incident Response” on page 36.), for which a specific Baseline andFactory Settings are defined (available on request).The Checkpoint SecurePlatform operating system is a minimised and hardened version of RedhatLinux 7.2 (kernel 2.4.9-13).The firewall can be managed with a GUI client (SmartDashBoard) running on a Windows OS,used mainly to define the topology of the network and to install the secure policy.This secure policy is the base of the firewall: on these rules, the firewall is capable to access,analyse and utilise the communication information (all 7 layers), the communication-derived state(from previous communications), application-derived state and information manipulation. So the filtering is not decided on a simple isolated packet. This way the firewall ensures the highestlevel of security. Firewall log events generated by the syslog daemon are passed to the OSP syslogserver (PSMF). The firewall is configured as a reverse Proxy ("clientless VPN"). This enables establishing anencrypted session with an SSL-enabled Web browser, such as Microsoft Internet Explorer (5.0 SP2and above) or Netscape Navigator (4.8 and above).The Internet Explorer default certificate or other certificates (eg. The VPN-1/FireWall-1 InternalCertificate Authority or Verisign ) can be used to authenticate the user.When an OSP management PC connects with a web browser to the OSP, the data between thefirewall and the OSP Management will be encrypted using SSL (HTTPS), whereas the data in thesecure network will remain in clear text (HTTP). The firewall works like a reverse proxy, becausethere is no direct connection from a user to the dedicated server.
1. Simplex configuration
The simplex configuration is a very secure and easy to configure solution. It consists out of oneCheckpoint VPN-1/FireWall-1 and a smartcenter server module. The firewall is then managed viaa GUI interface somewhere in the entire network that will connect to the smartcenter server of thatfirewall.
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 33/42
April 20, 2006 Recommended Firewall solution
The picture below shows the simplex configuration:
Figure 4.1 - Firewall and Secure Reverse Proxy in simplex configuration
2. Duplex configuration
With the duplex we have a configuration of two firewalls. This is configured as a Multi Entry Point,meaning there is more than one-entry point to the OSP platform. That leads to a more complexway of configuring the network itself.However, nothing else is needed to define the secure policy. The big advantage is here that weavoid a single point of failure and have an even more reliable secure solution.
Internet
SOAP serverSMF 2DMZ SMF 1
SLEE 2SLEE 1
OSP Private Network
Corporate Intranet
FEP SOAP
HTTPS
HTTPS
HTTPSHTTP
OSP R2.4.02
PLMN or
PSTN
...
PC forremote
connections
Alcatel’s support center
Serial links towards each OSP server
Management PC&
Untrusted ApplicationsManagement PC
&Trusted Applications
Firewall and SecureReverse Proxy
34/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
Recommended Firewall solution April 20, 2006
The picture below shows the duplex configuration:
Figure 4.2 - Firewall and Secure Reverse Proxy in duplex configuration
Internet
SOAP serverSMF 2DMZ SMF 1
SLEE 2SLEE 1
OSP Private Network
Corporate Intranet
FEP SOAP
HTTPS
HTTPS
HTTPSHTTP
OSP R2.3.08
PLMN or
PSTN
...
PC forremote
connections
Alcatel’s support center
Serial links towards each OSP server
Management PC&
Untrusted ApplicationsManagement PC
&Trusted Applications
Firewall and SecureReverse Proxy
Firewall and SecureReverse Proxy
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 35/42
April 20, 2006 Alcatel Product Security Incident Response
36/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
5. Alcatel Product Security Incident Response
The Alcatel Product Security Incident Response Team (A-PSIRT) is the organization within Alcatel,under the leadership of the Product Security Officer (PSO), that enables Alcatel to respond in atimely and effective fashion to security vulnerabilities that (may) impact any Alcatel product. The overall process followed by the A-PSIRT for every Alcatel Product is described on the AlcatelIntranet Web Site of the Network Strategy Group.A dedicated team within Alcatel, called Security Incident Watch Team (SIWT) is permanentlymonitoring all security incidents, weakness reports, warnings, … reported by various channels(CERT, Alcatel Suppliers, Customers, …) and ensures the PSO is aware of all such issues.Alcatel statements on security risks (whether responses or advisories to customers) can be sent tocustomers via different channels. Regardless of the channel, the source material for the message isalways the same and is provided via the PSO web page.
April 20, 2006
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 37/42
List of figures
Figure 1.1 -Different LAN and access modes ............................................................... 3Figure 1.2 -Access to OSP from Internet via a reverse proxy ......................................... 4Figure 1.3 -Access to OSP from Internet via a reverse proxy ......................................... 5Figure 2.1 -Commands flow of the Access service from the operator login. ................... 9Figure 2.2 -Overview of an Internet access to OSP R2.4.02 via SOAP on HTTP ........... 11Figure 2.3 -Possible configuration of an OSP WEB server with its DMZs between Firewall 1 and Firewall 2. ........................................................................................................ 12Figure 2.4 -Example of screened subnet firewalls ...................................................... 14Figure 2.5 -Multi-homed gateway ............................................................................. 15Figure 3.1 -Client PC to SMP communication based on SOAP and using a signed applica-tion deployed by Java Web Start ............................................................................... 23Figure 3.2 -PC communication with SMF through a reverse proxy using HTTPS ........... 25Figure 3.3 -Mass access communication from a thin client page to the SMF through a revers proxy using HTTPS ................................................................................................... 29Figure 3.4 -Secured Internet thin client communication with the SLEE through an HTTP-to-DPE gateway ........................................................................................................... 30Figure 3.5 -Secured Internet thin client communication with SLEE using SOAP with HTTPS through a reverse proxy ........................................................................................... 32Figure 4.1 -Firewall and Secure Reverse Proxy in simplex configuration ...................... 34Figure 4.2 -Firewall and Secure Reverse Proxy in duplex configuration ........................ 35
April 20, 2006
Index of Topics
AAlcatel Product Security Incident Response 36Applet
Description 21CCommunication with the OSP 19Communication with the SLEE 30Communication with the SLEE via DPE router 30Communication with the SLEE via SOAP 31Communication with the SMF 19Corporate LAN access
Assessing the risks 7Authentication and access control implementation 8Description 4Encryption and integrity checking 10Intranet security policy 7Network segmentation and protocol filtering 10Passwords management 9
DDMZ
Topology 13FFirewall solution 33Ggsoap
Description 21IIntranet communication with the SMF based on SOAP 19JJava application
Description 21Java Web Start
Presentation 21LLAN and access modes
OSP2.4.02 ones 3Types 3
MMass Access service
Presentation 28Multi-homed gateway
Advantages 15Descritpion 15
38/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
April 20, 2006
Drawbacks 15OOSP private LAN
Description 5Secured 17
RRemote access for field support
Description 6Secured 18
Reverse ProxySecured Internet communication 19
Reverse Proxy server 13SScreened subnet firewall
Advantages 14Description 14Drawbacks 14
Secure reverse proxy server 13Secured Internet communication with the SMF 19Servers
DMZ 13Signed applet
Definition 22Use 22
Signed applicationDefinition 22
SigningDescription 22
Sigtran signalling networkDescription 6Secured 18
SOAPChoice reasons 20
TThin client
Definition 28UUser LAN access
Authentication and access control 11Description 5Double LAN for HTTP flow 17Network segmentation 12Operationg System hardening and services limitation 17Restrict the traffic 12Security policy 16Web server implementation 11
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 39/42
April 20, 2006
WWeb service
Architecture 31
40/42 3CL-02350-BBXX-BGZZA OSP 2.4 Security Guidelines
April 20, 2006
Document References
Document title
OSP 2.4.01S Security Guidelines
Reference number
3CL-02350-BBXX-BGZZA
Status
Draft
Current edition
Draft03
Date of current edition
04/08/05
History
History of changes
Edition Date Authors Editor Appraisor
Draft03 04/08/05 Thierry DemontyAlcatel
Sophie EvrardAlcatel
Lisiane GoffauxAlcatel
Draft02 15/07/05 Thierry DemontyAlcatel
Sophie EvrardAlcatel
Lisiane GoffauxAlcatel
Draft01 28/06/05 Thierry DemontyAlcatel
Sophie EvrardAlcatel
Lisiane GoffauxAlcatel
Edition Changes note DDTS ID
01 • Added:3. Communication with the OSP
This chapter was extracted from OSP 2.4 Architecture andFunctionality. The aim is having one single documentdealing with security.
NA
OSP 2.4 Security Guidelines 3CL-02350-BBXX-BGZZA 41/42
April 20, 2006
42
Disclaimer
All rights reserved. Passing on and copying of this document, use and communicationof its contents not permitted without written authorisation from Alcatel.A8690 OSP is a registered trademark of Alcatel.The other marks and product names cited are the service marks or registeredtrademarks of their respective owners.The information in this documentation is subject to change without notice. If you findany problems in the documentation, please report them to us in writing. Alcatel doesnot warrant that this documentation is error free.
Address
Alcatel lAvenue Comte de Smet de Nayer, 145000 Namur, Belgium
42
Draft Draft version NA
Edition Changes note DDTS ID
/42 3CL-02350-BBXX-BGZZA OSP2.4 Security Guidelines