| Siebel CRM Siebel Security Hardening Guide Siebel Innovation Pack 2015 E24815-01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Siebel Security Hardening Guide Siebel Innovation Pack 2015 E24815-01 |
|
Previous |
Next |
View PDF |
Where and how network computing resources reside, as well as how they work in connection with the Internet and other computers on the local network, can have a significant impact on network security. This topic describes the network components to consider in securing your Siebel Business Applications deployment. You must consider the physical layout of the network components and the network authentication measures required.
Figure 3-1 shows the basic components included in Oracle's Siebel Business Applications network.
Access to the devices that host Siebel Business Applications must be protected. If these devices are compromised, then the security of all applications on the computer is at risk. Utilities that provide computer-level security, for example, by enforcing computer passwords, can be used and are transparent to Siebel Business Applications.
Siebel Business Applications support the deployment of firewalls throughout the enterprise as well as reverse-proxy servers, Network Address Translation devices, and load balancers to secure the application from attack.
The architecture of Siebel Business Applications also takes advantage of high-availability technologies, such as Microsoft Cluster Services, which spread the workload across multiple computers allowing them to function as one. High-availability technologies address the need for failover and disaster-recovery management.
The following topics provide recommendations for deploying network components in securing your Siebel Business Applications infrastructure:
|
Note: Siebel Business Applications do not use Simple Network Management Protocol (SNMP) for managing network devices. You can disable Simple Network Management Protocol services on Siebel Servers, if required. |
A firewall separates a company's external Siebel Web Clients (those accessing applications over the Internet) from its internal network and controls network traffic between the two domains. A firewall defines a focal point to keep unauthorized users out of a protected network, prohibits vulnerable services from entering or leaving the network, and provides protection from various kinds of IP spoofing and routing attacks.
To secure a network, divide the network into zones of control by considering factors, such as the type of information contained in the zone and who needs access to that zone. Then place firewalls between the zones and implement access controls between the zones. As illustrated in Figure 3-2, "Recommended Firewall Deployment in a Siebel Business Applications Environment", an enterprise network for Siebel Business Applications typically comprises the following zones of control:
Internet zone. This zone is insecure and not trusted. External Siebel Web Clients reside in this zone.
Demilitarized zone. Publicly accessible servers are placed in this zone. Servers placed in this zone are called bastion hosts. Siebel Web servers and Web server load balancers reside in this zone. Clients outside the firewall access the Web server and the Siebel Server through a secure connection. This zone is where the external network first interacts with the Siebel environment.
Intranet zone. This zone consists of internal networks.
Components that reside inside this zone include Siebel Servers, the Siebel Gateway Name Server, a third-party HTTP load balancer (if deployed) for Siebel Servers, and the authentication server (Lightweight Directory Access Protocol or Active Directory Service Interfaces directory server). In a deployment of Siebel employee applications, internal Web clients can also reside in this zone.
Internal highly secure zone. Business critical information and services are placed in this zone. The Siebel database and Siebel File System reside in this zone. Restrict access to this zone to system administrators and database administrators.
Figure 3-2, "Recommended Firewall Deployment in a Siebel Business Applications Environment" shows the recommended placement of firewalls in a Siebel Business Applications environment, that is, between the Internet and demilitarized zones, and between the demilitarized and intranet zones. For optimum performance, do not install a firewall between the intranet zone and the internal highly secure zone.
Figure 3-2 Recommended Firewall Deployment in a Siebel Business Applications Environment
For additional information on the recommended placement of firewalls, see "Recommended Network Topologies". For information on assigning ports when setting up firewalls, see "Guidelines for Assigning Ports on Firewalls".
This topic provides guidelines for assigning ports when setting up firewalls in a Siebel Business Applications implementation.
Configure communication ports as follows:
Set up the external firewall to enable HTTP (default port 80) and HTTPS (default port 443) communications between external Siebel Web Clients in the Internet zone and the IP address of the Web server in the demilitarized zone according to the security parameters set on the Siebel Web Server Extension (SWSE).
Set up the choke firewall (the firewall between the demilitarized zone and the intranet) as follows:
For communications from the Web servers to the Siebel Server, use the SCBroker port (Siebel load balancing) or the virtual port of a third-party HTTP load balancer for Transmission Control Protocol (TCP) traffic. The default port used by SCBroker is 2321.
For communications from the Web servers to the Gateway Name Server, enable port 2320.
If you choose to place an internal firewall between the intranet zone and the internal highly secure zone, then set up the internal firewall as follows:
Enable port 636 for secure transmission of authentication information between the security adapter and the Siebel Servers. (The default is port 389.)
For communications between the Siebel Server and the Siebel database, enable the following default TCP ports:
1433 (Microsoft SQL)
1521 (Oracle)
50000 (DB2)
(Microsoft SQL only) Enable TCP port 139 and UDP ports 137 and 138 for communications between the Siebel Server and the Siebel File System.
For additional information on the default port allocations used by Siebel Business Applications, see Appendix B, "Default Port Allocations." For additional information on firewalls, see "Network Zones and Firewalls".
When deploying Siebel Business Applications across a firewall, verify that your firewall and proxy servers support the HTTP 1.1 protocol. This protocol enables functionality, such as inline data compression to improve performance for bandwidth-constrained environments, cookies, and other features.
If your firewall does not support HTTP 1.1, and you use HTTP 1.0 instead, then lower performance will result. The following requirements apply if you do not use HTTP 1.1:
Web server compression for SWSE must be disabled. In the eapps.cfg file, set the value of the DoCompression parameter to FALSE. (Use other settings where compression is known to be supported, or might be supported.) For more information, see Siebel System Administration Guide.
Make sure that the firewall can handle cookie-wrapping or other proxy-specific features that enable forwarding of a cookie. Or, reduce or remove the use of cookies in your Siebel Business Applications. For more information, see Siebel Security Guide.
Make sure that your proxy server does not pass to the SWSE any header content that uses HTTP 1.1 protocol. The proxy must remove any header content that is not compliant with HTTP 1.0.
Set up a screening router that selectively blocks or allows packets destined for internal resources. The screening router is typically a gateway to the external world, which is located at the perimeter, and is set up with the appropriate access list.
Network Address Translation rewrites the IP addresses of Internet connections as they cross the firewall boundary, thereby preventing direct access between the internal network and external networks, such as the Internet and partner networks.
Implement Network Address Translation on zone border security devices between the Web client and the Web server, and between the Web server and the Siebel Server.
You can balance loads on your Siebel Servers using native Siebel load balancing or a third-party HTTP load balancer. Using HTTP load balancing distributes incoming network traffic over several servers.
A third-party load balancer typically can provide additional security features, such as limiting TCP port exposure to a single port for multiple Siebel Servers. Single-port exposure allows you to consolidate network access for better port monitoring and security. It also provides simplified firewall configuration. You have to configure only one virtual port.
Additional security features provided by most third-party load balancers include:
Denial of service (DoS) attack prevention. In a DoS attack, a third-party HTTP load balancer helps handle the TCP connections. Incoming attacks can be caught at the load balancer before they reach the Siebel Server. A third-party HTTP load balancer typically has a built-in mechanism to stop DoS attacks at the point of entry.
Virtual Internet Protocol (VIP) addressing. A third-party HTTP load balancer uses VIP addressing. Unlike an IP address, a VIP address is not associated with a specific device in a network, so VIP addressing helps prevent hackers from accessing Siebel Servers directly. Web servers in the demilitarized zone communicate with the VIP only.
TCP handshake protection. The TCP handshake is replayed from the third-party HTTP load balancer to the Siebel Server rather than directly from the Web server in the demilitarized zone to the Siebel Server. This helps prevent attacks in which the TCP handshake is intercepted and redirected, for example, a SYN flood DoS attack.
When installing Siebel Business Applications, if you are using Siebel Server or third-party HTTP load balancers, then plan the use of TCP ports for firewall access:
If Siebel load balancing is used, then make sure the Web server can access the SCBroker port on each Siebel server.
If a third-party load balancer is used, then make sure the Web server can communicate with the VIP addresses and ports specified in the load balancer.
For information on the default port allocations used by Siebel Business Applications, see Appendix B, "Default Port Allocations."
Siebel Business Applications support the use of both forward and reverse-proxy servers within a deployment. Using proxy servers enhances security by preventing direct access to servers from the Internet.
Forward proxy servers are generally used to provide Web access to the Internet for client computers when direct routing is not possible, either because it is forbidden by policy or by the network implementation. Forward proxy servers are therefore part of the client security infrastructure. They are also sometimes used by Internet service providers for caching.
A reverse-proxy server acts as an intermediary to prevent direct connections from clients to Web servers. A reverse-proxy server shields internal IP addresses from users by rewriting the IP addresses of the Web servers so that the Web server IP addresses are not revealed to the user. Additionally, the reverse proxy server can cache data closer to end users, thereby improving performance. Reverse-proxy servers provide an additional layer of security by helping protect the Web server from direct external attacks, but do not directly help secure the Web application.
To handle traffic between the external Siebel Web clients and the Web server that contains the SWSE, install a reverse-proxy server in the demilitarized zone (see Figure 3-2, "Recommended Firewall Deployment in a Siebel Business Applications Environment"S). The Web server and SWSE can then be moved behind a firewall into a separate zone or into the intranet zone.
Customer applications, which use standard interactivity, commonly are deployed with reverse proxy servers. Employee applications, which use high interactivity, can also be deployed with reverse proxy servers. If you deploy applications that use high interactivity with a reverse proxy server or a Web server load balancer, then note the following considerations:
Siebel Business Applications do not support the translation of port numbers or protocol switching. An example of protocol switching is changing from HTTP to HTTPS.
|
Note: Protocol switching from HTTPS to HTTP is supported if you have enabled the TLS acceleration feature for communications between Siebel Web Clients and the Web server. For information on using TLS acceleration, see Siebel Security Guide. |
Siebel Business Applications support rewriting of the host name and of the IP addresses of the Web servers. For example, you can rewrite the following URL:
http://ServerInternal/callcenter_enu/start.swe
to:
http://ServerExternal/callcenter_enu/start.swe
However, you cannot rewrite it to:
http://ServerExternal/portal1/start.swe
The reverse proxy server and Web server must run on the same port.
If you deploy Transport Layer Security (TLS) between the client and the reverse proxy server, then you must also deploy it between the reverse proxy server and the Web server on which the Siebel Web Server Extension (SWSE) is installed. Similarly, if you deploy TLS between the reverse proxy server and the Web server, then you must deploy it between the client and the reverse proxy server.
|
Note: If the TLS acceleration feature is enabled, then you can deploy TLS between Siebel Web Clients and the reverse proxy server. However, you do not have to deploy TLS between the reverse proxy server and the Web server. You can use the HTTP protocol for communications between the reverse proxy server and the Web server. For information on enabling TSL acceleration, see Siebel Security Guide. |
Siebel Business Applications also support the use of Virtual Private Networks (VPNs). A VPN is a technique that allows computers outside the firewall to tunnel traffic through a firewall and to appear as if they are connected inside the firewall.
VPN technology allows employees working remotely to access many corporate intranet resources (for example, email servers, file shares, and so on) which are otherwise not sufficiently secure to be placed outside the firewall.
Internet Protocol Security (IPsec) is a mechanism for securing communications at the Internet Protocol (IP) layer. If IPsec is implemented, then IP packets (including the TCP information) are encrypted. You do not have to configure Siebel Business Applications to enable IPsec in your deployment.
IPsec encrypts TCP data; that is, data at layers 4 to 7 of the OSI model. If you want to implement load balancing, then be aware that Web server load balancers cannot balance loads for encrypted information from layers 4 to 7. Before implementing IPsec, therefore, check with the server load-balancing vendor for support details.
If you implement IPsec, then follow these recommendations:
Enable port 500 (User Datagram Protocol) and the IP protocols 50 and 51 on the perimeter firewall for IPsec communications.
It is recommended that you enable pass-through authentication on the VPN Gateway to support Network Address Translation on the client side. (The VPN Gateway can be the firewall with VPN functionality or a separate VPN server behind the firewall).
Denial of service (DoS) attacks can take different forms. However, the most common method involves one or more computers (often hijacked personal computers) bombarding a Web site or Web-accessible service with a large number of simultaneous requests. The affected servers are overwhelmed and the connections and processes are prevented from running. These types of attacks are almost always targeted against public-facing Web sites and applications.
The following steps can help prevent DoS attacks from affecting your employee-facing Siebel Business Applications:
Use different Web servers for public-facing applications and for employee-facing applications so that even if the public Web servers are overwhelmed, Web servers are still available to service employee applications. For additional information, see "Proxy Servers".
Run the employee-facing Application Object Managers and key components on different Siebel servers from those used to run public-facing Application Object Managers. This step helps to make sure that even if the Siebel Servers that process external applications are overwhelmed with requests, hardware resources are available to continue processing internal applications. For additional information, see "Load Balancers".
Other methods available when configuring firewalls to assist in preventing DoS attacks include designing them to reject rapid requests from the same IP address, or to blacklist specific IP addresses or domains. These methods are not foolproof and it might not be possible to use blacklisting on large public sites. For example, many DoS attacks use hijacked computers that are on large, well-known, Internet service providers. Blacklisting all of the users in these domains or IP ranges helps prevent the DoS attacks, but possibly prevents many valid users from using your Web site as well.
