Asset ID: |
1-79-1945885.1 |
Update Date: | 2018-03-26 |
Keywords: | |
Solution Type
Predictive Self-Healing Sure
Solution
1945885.1
:
CVE-2014-3566 Instructions to Mitigate the SSL v3.0 Vulnerability (aka "Poodle Attack") in Performance Intelligence Center (PIC)
Related Items |
- Oracle Communications Performance Intelligence Center (PIC) Software
- Oracle Communications Performance Intelligence Center (PIC) Software
|
Related Categories |
- PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec PIC
|
In this Document
Applies to:
Oracle Communications Performance Intelligence Center (PIC) Software - Version 10.1.0 to 10.1.0 [Release 10.0]
Oracle Communications Performance Intelligence Center (PIC) Software - Version 9.0.4 to 9.0.4 [Release 9.0]
Information in this document applies to any platform.
Purpose
This document provides instructions to apply configuration changes required to resolve security vulnerability referenced by CVE-2014-3566.
Updating the JDK and enabling JSSE is not supported.
Details
Vulnerability in reference is about SSLv3 protocol being vulnerable to a man in the middle attack known as “poodle attack”.
More information about this vulnerability is available at http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html
Proposed resolution consists of disabling this protocol in the stack of SSL protocols negotiated during a client-server secure connection. TLS 1.0, TLS 1.1, TLS 1.2 are safe alternatives.
Use table below to determine, depending on server type, which procedure(s) are applicable:
Server type
|
Legacy name
|
3rd party tool
|
Procedure
|
Management server (apache server in case of 4 box cluster)
|
NSP onebox or NSP apache
|
Apache (httpd)
|
1
|
Management server (primary and secondary servers in case of 4 box cluster)
|
NSP onebox or NSP Primary, NSP secondary
|
Weblogic
|
2
|
Storage server and Management server
|
NSP onebox, NSP oracle and DWS
|
Oracle Enterprise Management Console
|
Refer to Oracle database 10g or 11g accordingly
|
PIC also uses other protocols that are either not secured or using SSLv3, however these client-server interactions shall be restricted by customer owned firewall setup to not be accessible from elsewhere than PIC backend VLAN. With this protection in place we do not need additional configuration steps for these interactions.
In summary, only ports 443 shall be accessible to end-users on frontend VLAN and Procedure 1 fixes the vulnerability. Ports 49696 (JXMAgent) shall be restricted to a system administrator because this tool does not support TLS.
Procedure 1 reconfigure Apache (httpd)
- Log in as root on the server console:
login: root
Password: <current root password>
- Edit mod_ssl configuration file
# vi /etc/httpd/conf.d/ssl.conf
Search the line containing the SSL protocol stack
/SSLProtocol
Edit the line with new rules
SSLProtocol -all +TLSv1
Save and quit
:x
- Restart httpd service:
# service httpd restart
Check the output if there is no unexpected message. For instance a typo on the parameter line would be mentioned. If this happens return to step 2.
Stopping httpd: [ OK ]
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using ::1 for ServerName
[ OK ]
If no unexpected output appears:
# exit
Procedure 2 reconfigure Weblogic
- Log in as root on the server console:
login: root
Password: <current root password>
- Edit setDomainEnv.sh configuration file
# vi /usr/TKLC/nsp/bea/user_projects/domains/tekelec/bin/setDomainEnv.sh
Search the line containing the SSL protocol parameter:
/Dweblogic.security.SSL.protocolVersion
Edit the line for the new value instead of SSL3:
-Dweblogic.security.SSL.protocolVersion=TLS1
- If you are running a 4-box configuration (secondary server only).
Repeat steps 1 and 2 for the secondary server and keep the connection open for verification during step 4.
- Stop nspservice service (nsp primary server or nsp single box only, not on secondary).
If you are running a 4-box configuration, return to primary server for this step.
This step will forcefully close user sessions on Management server; warn end users for this service disruption and choose appropriate time for servicing. This step has to be executed on nsp primary server only in case of 4 box setup and on nsp one box otherwise. This step does not need to be executed on nsp secondary server.
# service nspservice stop
This step will take a few minutes to complete. Check the output if it is similar to expected result.
Stopping NSP cluster
Stopping NodeManager
-
Verify instances are down (onebox or (primary and secondary))
Verify all the instances are down:
Following command should not show active processes when executed on the console.
# ps –eaf | grep nsp[12][ab]
If some active processes remains, contact Oracle support.
- Start nspservice service
This step will forcefully close user sessions on Management server; warn end users for this service disruption and choose appropriate time for servicing.
# service nspservice restart
This step will take a few minutes to complete. Check the output if it is similar to expected result, exit if yes, return to step 2 otherwise.
Stopping NSP cluster
Stopping NodeManager
Starting Node Manager:
.Starting NSP Administrator:
.......Starting NSP Cluster:
........................................................
When this is completed you can end the command line session:
# exit
Procedure 3 Stop Enterprise Management Console
Database Enterprise Management Console is only needed in case of troubleshooting on complex support cases. In production environments we recommend shutting this console down rather than reconfiguring SSL protocol.
- Log in as root on the server console:
login: root
Password: <current root password>
# su - oracle
- Stop the Enterprise Management Console:
# emctl stop dbconsole
- Quit:
# exit
References
<NOTE:1936300.1> - How to Change SSL Protocols (to Disable SSL 2.0/3.0) in Oracle Fusion Middleware Products
Attachments
This solution has no attachment