| Oracle® Real User Experience Insight User's Guide Release 6.5.0 for Linux x86-64 Part Number E17378-03 |
|
|
View PDF |
| Oracle® Real User Experience Insight User's Guide Release 6.5.0 for Linux x86-64 Part Number E17378-03 |
|
|
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 (HTTP or HTTPS) whose port settings you want to modify. 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.Oracle E-Business Suite-Specific Support
If the Oracle E-Business Suite (EBS) accelerator package has been installed, two additional protocol settings (HTTP/Forms servlet mode and Forms socket mode) are available within this facility. These are described in the Oracle Real User Experience Insight Accelerator for Oracle E-Business Suite Guide.
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.
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.
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.
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.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.
Note:
The check for expired SSL keys is scheduled to be run once a day at 6 am (Reporter system time).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, POST URL argument masking. A window similar to the one shown in Figure 8-9 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-10 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.Specifying the Default Action
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-11 appears.
Figure 8-11 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.
Automatically Listed Items
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.
Masking HTTP headers
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.17, "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.
National Language Support
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-12 appears.
Figure 8-12 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-13 appears.
Figure 8-13 Edit Collector SSL Certificate Masking Dialog
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-13.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|