| Oracle® Real User Experience Insight User's Guide Release 6.5.1 for Linux x86-64 Part Number E18053-01 |
|
|
View PDF |
| Oracle® Real User Experience Insight User's Guide Release 6.5.1 for Linux x86-64 Part Number E18053-01 |
|
|
View PDF |
This chapter describes how to configure and manage the security-related settings used by RUEI for traffic monitoring. This includes setting network filters to prevent the capturing of specific networks, hosts, Virtual Local Area Networks (VLANs), or to reduce overall monitored traffic. The security of sensitive data can also be maintained by specifying masking actions for HTTP protocol items (such as URL arguments, HTTP headers, and cookies). Finally, the managing of your Web server's private keys to encrypt secure traffic is also described.
The management of all security-related information is the responsibility of the Security Officer.
Important:
The Collector must be restarted after making any changes to security-related settings (other than HTTP protocol item maskings) for them to become effective.Within RUEI, you control the scope of traffic monitoring by specifying which TCP ports it should monitor. Obviously, no information is available for unmonitored ports. It is recommended that you carefully review your selections of monitored and unmonitored TCP ports (both HTTP and HTTPS).
The currently monitored ports can be viewed by selecting Configuration, then Security, and then Protocols. An example is shown in Figure 8-1.
To modify these settings, do the following:
Use the View menu to select the required Collector. The System (localhost) item represents the local server system.
Click the protocol whose port settings you want to modify. The following settings are available:
HTTP/Forms servlet mode: specifies the port(s) on which the Collector should listen for Forms servlet traffic. (This option is only for EBS suites).
Forms socket mode: specifies the port(s) on which the Collector should listen for Forms traffic in socket mode. (This option is only available for EBS suites).
HTTP: specifies the port(s) on which the Collector should listen for HTTP traffic. This setting should only be used for "pure" HTTP traffic.
HTTPS: specifies the port(s) on which the Collector should listen for HTTPS traffic.
A dialog similar to the one shown in Figure 8-2 appears.
To add a new port number, enter the required number in the Port number field, and click Add. To remove a port from the list, click the Remove icon to the right of the port. When ready, click Save.
Important:
The port numbers specified within each protocol must be mutually exclusive. That is, a port number should only appear in one protocol's list of assigned port numbers.You are prompted to restart the Collector. This is necessary in order to make your changes effective. Note you can also restart the selected Collector by clicking the Restart Collector icon shown in Figure 8-1.
Note:
Upon installation, the HTTPS port 443 is defined as the default monitored port.In addition to port numbers, you can use network filters to manage the scope of monitored traffic. They allow you to restrict monitoring to specific servers and subnets, and to restrict the level of packet capture.
To define or modify network filters, do the following:
Select Configuration, then Security, and then Network filters.
Use the View menu to select the required Collector. The System (localhost) item represents the Collector running on the Reporter server system. The currently defined network filters are displayed. An example is shown in Figure 8-3.
Click « Add new filter » to define a new filter, or click an existing filter to modify it. The dialog shown in Figure 8-4 appears.
Use the Server IP address and Netmask fields to specify the address to which the Collector should listen. It is strongly recommended that this is done in consultation with your network specialist. When ready, click Save.
You are prompted to restart the Collector. This is necessary in order to make your changes effective. Note that you can also restart the selected Collector by clicking the Restart Collector icon in the toolbar.
VLAN filters offer a means by which to limit monitored traffic to specific servers and subnets. To define VLAN filters, do the following:
Select Configuration, then Security, and then Network filters.
Use the View menu to select the required Collector. The System (localhost) represents the Collector running on the Reporter system.
Click the current setting for VLAN filter shown in Figure 8-3. The dialog shown in Figure 8-5 appears.
Use the Filter menu to specify whether VLAN filtering should be enabled. Note that enabling this filter means that only VLAN traffic will be monitored.
Optionally, use the VLAN ID field to specify a specific VLAN on which to filter.
When ready, click Save.
You are prompted to restart the Collector. This is necessary in order to make your changes effective.
In addition to the use of network and VLAN filters, it is also possible to specify how much of the overall traffic that remains after the application of other filters is actually monitored. By default, all remaining traffic is monitored.
To specify the level of overall traffic monitoring, do the following:
Select Configuration, then Security, and then Network filters.
Use the View menu to select the required Collector. The System (localhost) item represents the Collector running on the Reporter system.
Click the current setting for Traffic filter shown in Figure 8-3. The dialog shown in Figure 8-6 appears.
Use the Filtering scheme menu to specify whether filtering of network traffic should be based on physical or functional IP addresses. The use of this facility is described in detail in Section 8.2.3, "Filtering Based on Physical or Functional IP Addresses".
Use the Packet capture menu to select the required portion (All traffic, 1/2, 1/3, 1/4, 1/8, or 1/16) of the traffic that the Collector should monitor and, in cases of other than all traffic, the part of the data stream that should be monitored. For example, you could have an installation in which four Collectors are configured, and each Collector monitors a different quarter of the packet capture. When ready, click Save.
You are prompted to restart the Collector. This is necessary in order to make your changes effective. Note that you can also restart the selected Collector by clicking the Restart Collector icon shown in Figure 8-1.
The setting described above specifies how much of the total network traffic is measured. Therefore, if you specify that half of all traffic should be monitored, only the monitored half is reported. When using a setting of less than 100%, you should bear in mind that the reported information does not reflect all actual traffic, but the selected sample.
Traffic monitoring is based on IP addresses. This means that, regardless of what setting you use, complete user sessions are recorded. However, the number of those sessions depends on your selected setting.
As described above, all filtering of monitored traffic is based on IP addresses. However, it is important to understand that the client IP source (see Appendix O, "Monitoring NATed Traffic") specified for an application, suite, or service, represents the functional IP address used for reporting purposes only. By default, filtering of network traffic is based on the physical IP address. That is, the IP address fetched from the IP packet.
However, if a Collector is installed behind a NAT device, you may prefer that filtering is based on functional IP addresses. In that case, do the following:
Follow the procedure described in Section 8.2.2, "Limiting Overall Traffic" for each required Collector, and select the "Functional IP address" option from the IP address filter menu shown in Figure 8-6. When ready, click Save.
You are prompted to restart the Collector. This is necessary in order to make your changes effective. Note that you can also restart the selected Collector by clicking the Restart Collector icon in the toolbar.
If you intend to base network filter upon functional IP addresses, be aware of the following:
If the functional IP address is not available, then the IP address obtained from the IP packet is used instead.
The use of a configured client IP header for network filtering places a considerable processing overhead on the Collector, especially when SSL encryption is being used in the monitored traffic. This is because filtering upon physical addresses can be performed at the TCP level, while filtering upon functional IP addresses normally has to be performed at HTTP level.
RUEI can be configured to monitor encrypted data (such as HTTPS and SSL). In order to do this, a copy of the Web server's private SSL keys needs to be imported into RUEI. To import certificates to monitor encrypted content, do the following:
Select Configuration, then Security, and then SSL keys. Use the View menu to select the required Collector. A list of the currently installed keys and their status is displayed.
Use the View menu to select the required Collector. The System (localhost) represents the Collector instance on the Reporter server system. The currently defined SSL keys and certificates are displayed. Click « Add new key » to define a new key. Note that existing SSL key definitions cannot be modified. The dialog shown in Figure 8-7 appears.
Use the Key field to specify the file containing the key. If the key is encrypted, you must specify the passphase. When ready, click Install key.
The certificate will be encrypted on the disk.
Note:
The supplied file can be in PAM, DER, or PKCS12 format, and must include the key and matching certificate. The key must be an RSA key. Note that encryption protocols that use 40-bit keys (such as DES_40, RS2_4-0, and RC4_40) are not supported.Supported Encryption Protocols and Mechanisms
Within Message Authentication Codes (MACs), the MD5, SDA-1, and SDA-2 functions are supported. The SSL v3 and TLS v1.0 cryptographic protocols are supported. A complete list of the currently supported encryption algorithms is available within the SSL connections section of the Collector statistics window (see Section 9.2.1, "Working Within the Collector Statistics Window").
Be aware that both SSL and Oracle Forms traffic are particularly sensitive to disruptions in the TCP packet stream. This is because they require state information to be maintained for the duration of the connection, and any lost packets can cause that information to be lost, preventing RUEI from accurately monitoring and reporting the connection.
Therefore, you should ensure that each Collector is connected to a reliable network device, such as a TAP. In addition, it is strongly recommended that you regular review the information available through the Collector Statistics window (described in Section 9.2.1, "Working Within the Collector Statistics Window") to verify the integrity of the TCP packet stream. Particular attention should be paid to the reported TCP and SSL connection errors.
To remove an installed SSL key, right click the required key, and select Remove. You are prompted to confirm the key's removal.
Optionally, you can configure notifications about pending SSL key expirations. This allows you to plan the importation of new keys, and ensures that there are no gaps in the monitored data while new keys are obtained and activated. Do the following:
Click the Monitor key expiration icon on the taskbar. If it is not already visible, select Configuration, then Security, and then SSL keys. The dialog shown in Figure 8-8 appears.
Specify the number of days prior to expiration when notification should be generated. Use the controls on the other tabs to specify the e-mailing, SNMP, and text message notification details. These are similar to the dialogs explained in Section 5.5.1, "Alert Profiles".
When ready, click Save.
You are prompted to restart the Collector. This is necessary in order to make your changes effective. Note that you can also restart the selected Collector by clicking the Restart Collector icon shown in Figure 8-1.
Note:
The check for expired SSL keys is scheduled to be run once a day at 6 am (Reporter system time).If a Collector has been placed in front of a proxy server, and you intent to monitor SSL-encrypted traffic, then the proxy port to which the SSL traffic is sent must be configured as part of your RUEI installation. Do the following:
Select Configuration, then Security, and then Protocols. Use the View menu to select the required Collector. Note that the System (localhost) item represents the Collector instance running on the Reporter system.
Click HTTPS proxy. The dialog shown in Figure 8-9 appears.
Specify the proxy server port number(s) to which SSL traffic is sent. To add a new port number, enter the required number in the Port number field, and click Add. To remove a port from the list, click the Remove icon to the right of the port. When ready, click Save.
Be aware of the following:
If only non-SSL traffic is routed over a proxy port, the port number should not be specified via this setting. Otherwise, it can have a significant impact on Collector performance.
The port number of the server receiving the SSL traffic (behind the proxy) must be specified via the HTTPS setting (see Section 8.1, "Managing the Scope of Monitoring").
The RUEI installation can be configured to omit the logging of sensitive information. This is called masking, and it allows you to prevent passwords, credit card details, and other sensitive information from being recorded on disk. RUEI's security facilities allow you to control the logging of POST URL arguments, HTTP headers, cookies, and the contents of URLs.
To implement a masking, do the following:
Select Configuration, then Security, then Masking, and then select the appropriate option for the HTTP protocol item you want to configure. For example, URL prefix masking. A window similar to the one shown in Figure 8-10 appears.
The currently defined maskings for the selected HTTP protocol item are listed.
Click the « Add new masking » item to define a new masking, or click an existing one to modify it. A dialog similar to the one shown in Figure 8-11 appears.
Specify the name of the item whose logging you want to control. Depending on the selected protocol item, this will either be the name of a POST URL argument, or an item within a HTTP header, cookie, or URL prefix. Note the procedure for defining URL prefix maskings is described later in this section.
Select the masking action to be assigned to the defined item. The following options are available for protocol items other than URL prefixes:
Default: specifies that the defined default action for the selected HTTP protocol item should be performed for this item. The use of this facility is described in the following section.
Hashed: specifies that the item's contents should be replaced with a calculated hash value when logged. This mechanism provides a unique value for comparison purposes, but is not in human-readable form. For example, five different user IDs would receive five different hashes when logged, while multiple sessions by the same visitor would receive the same hash. This manufactured (hashed) value provides uniqueness, but not the real value itself.
Blinded: specifies that the item's original contents should be overwritten with an Xs when logged.
Plain: specifies that the item should be logged in its original state. That is, unprotected.
Truncated: specifies that only the first 1 KB characters of the HTTP protocol item are logged. Values longer than this have their reminder truncated and hashed, and appended to the first 1 KB of plain (unhashed) data. In this way, their uniqueness is preserved.
When ready, click Save. Any changes you specify take effect within 5 minutes.
Note:
All items are case insensitive.As mentioned earlier, the default setting specifies the action that should be taken for HTTP protocol items not explicitly specified in your security definitions. By defining items with the "Default" action, you can modify the security settings for a large number of data items (both listed and unlisted) with one user action.
To specify the default action, do the following:
Select the HTTP protocol item whose default action you want to specify. For example, HTTP header masking.
Click the current setting for the Default masking action menu. This is located at the top of the masking window. A dialog similar to the one shown in Figure 8-12 appears.
Figure 8-12 Edit Default Masking Setting Dialog
Select the required security setting to be applied to all data item's with the action "Default". When ready, click Save. Any changes you make to this setting take effect within 5 minutes.
In addition to the HTTP protocol item maskings you explicitly define, items are also automatically detected by RUEI during configuration. These are assigned the action "Default". You can modify their assigned actions either individually or collectively through changing the defined default action, but you cannot remove them.
In addition, be aware that after deleting an item (for example, a custom dimension item described in Section 3.9, "Working With Custom Dimensions"), if you have not modified its masking action, it is automatically removed from the displayed items list. However, if you have previously modified its defined action, you will need to explicitly remove it from the items list.
A number of pre-configured HTTP headers maskings are defined. These items are used by RUEI for the processing of monitored traffic. They have the action "Used in system" defined for them, which means their associated items are recorded in their original state. This action cannot be modified because they are required for the correct monitoring of network traffic.
Note that if session tracking is based on some standard technology (such as Apache or ColdFusion), the cookie is not reported in the "Used in" section. Instead, these cookies have the default masking action assigned to them, unless they have been defined manually, and have been configured differently from their default values. This does not represent a problem if the default masking action has not been set to blinded. If it has, all visitor sessions would be booked on one session.
In addition to URL POST arguments, cookies, and HTTP headers, it is also possible to protect certain URL contents by specifying a prefix. This facility is useful when you want to prevent the storage of URL structures that might contain sensitive information.
The options specify which parts, in terms of request and response headers and bodies, are preserved in the Replay Viewer facility and the Collector log files (from which information within the Data Browser groups and Session Diagnostics facility is derived). The following masking actions can be specified:
Complete logging: specifies that all parts should be preserved in both the Replay viewer and Collector log files (after all other defined maskings have been applied).
Note:
Selecting the "Complete logging" option as the default masking action is the equivalent of enabling replay functionality in previous versions of RUEI by selecting Configuration, then Security, then Blinding, then clicking the Toggle Replay functionality icon on the toolbar, and selecting the "Enabled" option.No Request body: specifies that all parts (after all other defined maskings have been applied) are preserved in Collector log files, but request bodies are not preserved in the Replay viewer.
Headers only: specifies that all parts (after all other defined maskings have been applied) are preserved in the Collector log files, but only request and response headers are preserved in the Replay viewer.
No replay: specifies that all parts (after any other defined maskings have been applied) are preserved in the Collector log files, but nothing is preserved in the Replay viewer.
No logging: specifies that nothing is preserved in either the Replay viewer or Collector log files.
The items recorded in the Replay Viewer facility and the Collector log files (from which information within Data Browser groups and Session Diagnostics is derived) for each of these masking actions is explained in Table 8-1.
Table 8-1 Items Logged With URL Prefix Masking Action
| Masking action | Request header | Request body | Response header | Response body | Recorded in Collector log file |
|---|---|---|---|---|---|
|
Complete logging |
X |
X |
X |
X |
X |
|
No request body |
X |
X |
X |
X |
|
|
Headers only |
X |
X |
X |
||
|
No replay |
X |
||||
|
No logging |
Note that if an item is used within the RUEI installation (for example, as part of an application or suite definition), this is indicated in the displayed list, and the item cannot be removed. In addition, be aware that while multiple (overlapping) item definitions are possible, the longest matching specification will be used as the assigned masking action.
Be aware that, in the case of overlapping matching URL prefixes (for example, /ru and /ruei), that have been assigned different masking actions, the longest match is taken. In addition, note that the prefix must be a true prefix. For example, if the matching URL is /app/ruei, neither /ru or /ruei will be matched.
In addition, it is important understand that the question mark character (?) should not be specified within URL prefixes. If it is, the question mark character, and everything after it, is ignored. For example, if you specify the URL /catalog/jn.php?item, it is truncated to /catalog/jn.php. URLs should be specified in human-readable format (not encoded).
Note:
URL prefixes are case sensitive.Masking Data Used by External Applications
As explained in Section 9.19, "Exporting Enriched Data", data collected by RUEI can be exported to enable its combination with other data warehouse data. Because any data items masked within RUEI are also masked when exported, it is recommended that you carefully review the requirements for data items used by external applications. The settings windows available within the masking facility provide an ideal audit tool to verify your security requirements.
Masking the Authorization Field
As explained in Section 6.2.10, "Defining User Identification", user identification is first based on the HTTP Authorization field. Be aware that, if this is sent over the network in plain format, this represents a security issue because the user name and password can potentially be decoded from it. This is a limitation of the basic authentication protocol.
If Authorization fields are sent over the network in plain format, you can use the masking options described in the previous section to control whether they are preserved in the Replay viewer. Alternatively, you can ensure that Authorization fields are hashed when included in network traffic. In this case, the user IDs are unavailable in the Session diagnostics facility.
See Appendix G, "Working With National Language Support" for a detailed discussion of the operation of data masking when working with international character sets.
Modifying Your Masking Definitions
Be aware that when changing a data item's security, any data already stored in log files is unaffected by the change. If necessary, you should consider purging the system (this is fully described in Section 9.13, "Resetting the System").
Important:
It is strongly recommended that you regularly verify that all sensitive data is masked correctly on a regular basis. Applications often change over time, and so do their use of POST variables, cookies, headers, and URL structures. The Collector and Reporter raw log files can be found in the directories
/var/opt/ruei/processor/data. The Session diagnostics export facility can also be used to audit the content of these files. This is described in Section 3.10.3, "Exporting Full Session Information".By default, all SSL client certificate properties (when available) are recorded as part of the log files generated by each Collector system. If this does not meet your organization's security policies, do the following:
Select Configuration, then General, then Advanced settings, and then SSL certificate masking. The panel shown in Figure 8-13 appears.
Figure 8-13 Collector SSL Client Certificate Masking Policy
Use the View menu to select the required Collector. The System (localhost) represents the Collector running on the Report system.
Click the current Collector SSL certificate masking action. The dialog shown in Figure 8-14 appears.
Figure 8-14 Edit Collector SSL Certificate Masking Dialog
The following options are available:
Log full certificate properties: specifies that the complete SSL certificate should be logged.
Log session ID only: specifies that only session ID information should be recorded.
No certificate properties logged: specifies that no proportion of the SSL certificate should be logged.
Select the required masking action. When ready, click Save.
You are prompted to restart the Collector. This is necessary in order to make the change effective. Note that you can also restart the selected Collector by clicking the Restart Collector icon shown in Figure 8-14.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|