Sign in or 
Share this
Securing Your PeopleSoft Application - Chapter 3
This chapter discusses various network components used for secure systems. Instead of covering all possible configurations and devices, this chapter addresses systems that apply to PeopleSoft architecture and that have been tested in the field. The discussion is also limited to security configuration only; scalability and high availability configurations are discussed in the Clustering and High Availability of PeopleSoft 8.4 red paper located on Customer Connection. The various security components to consider in your system are:
Routers – Most routers also have certain firewall capability, such as packet filtering, port blocking, and so on. These features should be enabled for added security whenever possible. Customers using co-location will generally not have access to the router because this is part of the co-location provider’s equipment. In these cases, all security features must be implemented within the system using additional equipment including firewalls, load balancer network address translation (NAT), reverse proxy server, and so on.
Firewalls – The firewall is one of the most common network devices used to secure a network environment. A firewall can be a logical or a physical device. The logical version of a firewall can be combination of routers, load balancers, and switches working together to create a secure network. A physical firewall device can be special software running on commodity hardware or it can be a dedicated hardware device. In the following sections, we use a three-pronged firewall. In this configuration, the firewall has three interfaces: one for internet, one for intranet, and one for the DMZ services. This configuration has a single point of protection (security failure) limitation for the intranet site. If this is not acceptable, the three-pronged firewall should be preceded with another pair of redundant firewalls. It is possible to run load balancers to distribute load among identical firewall units (FWLBS) for greater scalability, but the configuration is not simple. Implementing the three-pronged firewall with redundancy will require six extra load balancers and six extra switches/VLANS to implement.
Load Balancers – Load balancers are a highly recommended device for achieving high scalability and fault tolerance at a reasonable cost. Most units can be configured to replace a firewall and provide hardware SSL acceleration. This provides some amount of security and scalability at a reasonable cost. On most load balancers, each physical unit can be configured into multiple logical units. These logical units may have separate network interfaces and can be placed in various network topologies. Security administrators will most often not allow a single physical device to be configured for more than one security zone.
Reverse Proxy Servers – Reverse Proxy Servers (RPS) are most often used as part of a security infrastructure. Most sites deploy them to prevent internet IP packets from reaching production web servers directly. This is a security device for inbound HTTP(S) PIA traffic. An RPS provides protection from attacks that are launched to take advantage of vulnerability such as buffer overflow, malformed packets, and so on. It also adds another tier to the security architecture. Other sites may use them as a single signon portal server; one that allows RPS-authenticated users to access multiple internal systems with varying authentication schemes without individual authentication to those systems. Multiple RPS is required for redundancy and in some cases for scalability. When multiple RPS is deployed a load balancer must be used in front of the RPS. For PeopleSoft applications, a site domain name mapping will map to the load balancer for the RPS. For instance, an example site portal.corp.com should be mapped to a VIP 123.123.123.100 by external DNS systems and this VIP should be mapped to the RPS load balancer.
Forward Proxy Servers – Forward Proxy Servers or Proxy Servers in short are mostly used as part of a client security and caching infrastructure. Most sites deploy them to prevent users from connecting to the Internet directly. This is security device for outbound HTTP(S) PIA traffic. The user’s browser connect to a proxy server that is either configured in the browser or transparently routed to via a router. The proxy does the actual communication with the webserver on behalf of the user. The proxy also has the capability to cache content to improve performance and to log all browsing history for audit purposes. In the case where a site deploys either a PeopleSoft Integration System or an Enterprise Portal System which communicate to servers outside the production environment a (forward) proxy server should be used. The production firewall should be configured to allow only the proxy server to connect outside the firewall. The proxy is therefore the only means of communicating to the outside world from within the production environment. All HTTP(S) requests originating from PeopleSoft servers should be routed via the proxy server.
Servers – Servers have a number of security setting and vulnerability issues associated with them. At a minimum, all vendor-provided OS security patches should be applied to the servers. Additionally, all unused services should be disabled on the servers. This is explained in detail later in this red paper. Web servers and application servers should also use dual network interfaces so that they can reside in separate subnets. This provides additional level security layers. The merits of having a different subnet for each layer can create complicated router policies that are required for administering servers in different subnets. Additionally, certain security failures on the web server might expose sensitive data even if the security of the application server and the database server has not been compromised.
DNS Servers – A PeopleSoft production system should avoid using DNS name resolution whenever possible. Instead, it should use statically configured server addresses. It may be necessary, however, for PeopleSoft Portal or Application Messaging to be able to access remote servers. In this case an /etc/hosts entry is not practical and some DNS lookup may be necessary. Under no circumstances should the local DNS servers be allowed to receive DNS updates from remote servers. The local DNS server should also be prevented from sending DNS queries to remote server for local addresses. The local DNS server should only query the remote server for addresses that are outside the local domain of the site.
Disaster Recovery Plans – All installations regardless of size must create a disaster recovery plan. The disaster recovery plan must include unavailability due to security failures, standard power failures, physical disasters, and other outages. For highly secure installations, this should include creation of a second data center that is also part of a separate physical security zone. This means separate network security policies, access codes/badges, and security administrators.
Virtual IPs (VIPs) – VIPs are not physical devices. These are IP addresses where users point their browsers to access a services. These IP addresses could point to a real web server in the simplest case. In most of the systems described in this document, they will point to a logical service implemented using firewalls, load balancers, proxy servers, and real servers. A VIP is also the IP address that the site’s DNS name maps to. For instance, an example site portal.corp.com is mapped to a VIP 123.123.123.100 by external DNS systems.
Private Non-routable Address (RFC 1918) – Private non-routable address are IP addresses in the the range 10.0.0.0 – 10.255.255.255, 172.16.0.0 – 172.31.255.255 and 192.168.0.0 – 192.168.0.0. These IP addresses work within a network and all addresses within the network are addressable internal hosts and routers. These addresses are not addressable from the internet and internet routers will not be able to route packtes to these IP addresses. Having a private IP address provides some security by isolating the internal servers from the outside world but does not preclude the need for a firewall.
Public Address - Almost all IP addresses that are not within the range mentioned in RFC 1918 are publicly addressable. These are IP addresses that can be addressed and routed over the internet. Public addresses are required to expose services to internet user.
Network Address Translation (NAT) – NAT enables a local-area network (LAN) to use Private Non-routable IP addresses for internal traffic and public addresses for external traffic. A NAT device located where the LAN meets the internet makes all necessary IP address translations to packets moving from one address space to another. NAT provides some level of security by providing stateful inspection and by isolating the internal servers from the outside world. PIA uses HTTP(S) only and has no problems with NAT. Some network software like IPSec, Kerberos and so on require end to end packet level integrety and will not work with NAT. In some of these cases, for example, for IPSec there is no need to perform NAT for security alone. Also, the use of NAT does not preclude the need for a firewall.
Routers – Most routers also have certain firewall capability, such as packet filtering, port blocking, and so on. These features should be enabled for added security whenever possible. Customers using co-location will generally not have access to the router because this is part of the co-location provider’s equipment. In these cases, all security features must be implemented within the system using additional equipment including firewalls, load balancer network address translation (NAT), reverse proxy server, and so on.
Firewalls – The firewall is one of the most common network devices used to secure a network environment. A firewall can be a logical or a physical device. The logical version of a firewall can be combination of routers, load balancers, and switches working together to create a secure network. A physical firewall device can be special software running on commodity hardware or it can be a dedicated hardware device. In the following sections, we use a three-pronged firewall. In this configuration, the firewall has three interfaces: one for internet, one for intranet, and one for the DMZ services. This configuration has a single point of protection (security failure) limitation for the intranet site. If this is not acceptable, the three-pronged firewall should be preceded with another pair of redundant firewalls. It is possible to run load balancers to distribute load among identical firewall units (FWLBS) for greater scalability, but the configuration is not simple. Implementing the three-pronged firewall with redundancy will require six extra load balancers and six extra switches/VLANS to implement.
Load Balancers – Load balancers are a highly recommended device for achieving high scalability and fault tolerance at a reasonable cost. Most units can be configured to replace a firewall and provide hardware SSL acceleration. This provides some amount of security and scalability at a reasonable cost. On most load balancers, each physical unit can be configured into multiple logical units. These logical units may have separate network interfaces and can be placed in various network topologies. Security administrators will most often not allow a single physical device to be configured for more than one security zone.
Reverse Proxy Servers – Reverse Proxy Servers (RPS) are most often used as part of a security infrastructure. Most sites deploy them to prevent internet IP packets from reaching production web servers directly. This is a security device for inbound HTTP(S) PIA traffic. An RPS provides protection from attacks that are launched to take advantage of vulnerability such as buffer overflow, malformed packets, and so on. It also adds another tier to the security architecture. Other sites may use them as a single signon portal server; one that allows RPS-authenticated users to access multiple internal systems with varying authentication schemes without individual authentication to those systems. Multiple RPS is required for redundancy and in some cases for scalability. When multiple RPS is deployed a load balancer must be used in front of the RPS. For PeopleSoft applications, a site domain name mapping will map to the load balancer for the RPS. For instance, an example site portal.corp.com should be mapped to a VIP 123.123.123.100 by external DNS systems and this VIP should be mapped to the RPS load balancer.
Forward Proxy Servers – Forward Proxy Servers or Proxy Servers in short are mostly used as part of a client security and caching infrastructure. Most sites deploy them to prevent users from connecting to the Internet directly. This is security device for outbound HTTP(S) PIA traffic. The user’s browser connect to a proxy server that is either configured in the browser or transparently routed to via a router. The proxy does the actual communication with the webserver on behalf of the user. The proxy also has the capability to cache content to improve performance and to log all browsing history for audit purposes. In the case where a site deploys either a PeopleSoft Integration System or an Enterprise Portal System which communicate to servers outside the production environment a (forward) proxy server should be used. The production firewall should be configured to allow only the proxy server to connect outside the firewall. The proxy is therefore the only means of communicating to the outside world from within the production environment. All HTTP(S) requests originating from PeopleSoft servers should be routed via the proxy server.
Servers – Servers have a number of security setting and vulnerability issues associated with them. At a minimum, all vendor-provided OS security patches should be applied to the servers. Additionally, all unused services should be disabled on the servers. This is explained in detail later in this red paper. Web servers and application servers should also use dual network interfaces so that they can reside in separate subnets. This provides additional level security layers. The merits of having a different subnet for each layer can create complicated router policies that are required for administering servers in different subnets. Additionally, certain security failures on the web server might expose sensitive data even if the security of the application server and the database server has not been compromised.
DNS Servers – A PeopleSoft production system should avoid using DNS name resolution whenever possible. Instead, it should use statically configured server addresses. It may be necessary, however, for PeopleSoft Portal or Application Messaging to be able to access remote servers. In this case an /etc/hosts entry is not practical and some DNS lookup may be necessary. Under no circumstances should the local DNS servers be allowed to receive DNS updates from remote servers. The local DNS server should also be prevented from sending DNS queries to remote server for local addresses. The local DNS server should only query the remote server for addresses that are outside the local domain of the site.
Disaster Recovery Plans – All installations regardless of size must create a disaster recovery plan. The disaster recovery plan must include unavailability due to security failures, standard power failures, physical disasters, and other outages. For highly secure installations, this should include creation of a second data center that is also part of a separate physical security zone. This means separate network security policies, access codes/badges, and security administrators.
Virtual IPs (VIPs) – VIPs are not physical devices. These are IP addresses where users point their browsers to access a services. These IP addresses could point to a real web server in the simplest case. In most of the systems described in this document, they will point to a logical service implemented using firewalls, load balancers, proxy servers, and real servers. A VIP is also the IP address that the site’s DNS name maps to. For instance, an example site portal.corp.com is mapped to a VIP 123.123.123.100 by external DNS systems.
Private Non-routable Address (RFC 1918) – Private non-routable address are IP addresses in the the range 10.0.0.0 – 10.255.255.255, 172.16.0.0 – 172.31.255.255 and 192.168.0.0 – 192.168.0.0. These IP addresses work within a network and all addresses within the network are addressable internal hosts and routers. These addresses are not addressable from the internet and internet routers will not be able to route packtes to these IP addresses. Having a private IP address provides some security by isolating the internal servers from the outside world but does not preclude the need for a firewall.
Public Address - Almost all IP addresses that are not within the range mentioned in RFC 1918 are publicly addressable. These are IP addresses that can be addressed and routed over the internet. Public addresses are required to expose services to internet user.
Network Address Translation (NAT) – NAT enables a local-area network (LAN) to use Private Non-routable IP addresses for internal traffic and public addresses for external traffic. A NAT device located where the LAN meets the internet makes all necessary IP address translations to packets moving from one address space to another. NAT provides some level of security by providing stateful inspection and by isolating the internal servers from the outside world. PIA uses HTTP(S) only and has no problems with NAT. Some network software like IPSec, Kerberos and so on require end to end packet level integrety and will not work with NAT. In some of these cases, for example, for IPSec there is no need to perform NAT for security alone. Also, the use of NAT does not preclude the need for a firewall.
gregkelly |
Latest page update: made by gregkelly
, Feb 17 2009, 1:57 PM EST
(about this update
About This Update
Edited by gregkelly
view changes - complete history) |
|
Keyword tags:
None
More Info: links to this page
|
There are no threads for this page.
Be the first to start a new thread.
