| Oracle® Real User Experience Insight User Guide Release 4.5.1 for 64-bit Intel Linux Part Number E12486-02 |
|
|
| Oracle® Real User Experience Insight User Guide Release 4.5.1 for 64-bit Intel Linux Part Number E12486-02 |
|
|
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 capturing of specific networks, hosts, Virtual Local Area Networks (VLANs), or to reduce overall monitored traffic. Individual user security can also be maintained by blinding POST arguments, and managing your Web server's private keys to encrypt secure traffic. Finally, the enabling and disabling of cookie hashing and the Replay Viewer (described in Section 3.8, "Working With the Replay Viewer").
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 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. The Edit collector ports dialog 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.
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 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) represents the Collector running on the Reporter server system. The currently defined network filters are displayed. Click « Add new filter » to define a new filter, or click an existing filter to modify it. The dialog shown in Figure 8-3 appears:
Use the 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.
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 Configure VLAN filter icon on the taskbar. The Configure VLAN filter dialog shown in Figure 8-4 appears:
Use the Filter list 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. 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 Limit overall traffic icon on the taskbar. The Limit overall traffic dialog shown in Figure 8-5 appears:
Select the required portion (All traffic, 1/2, 1/3, 1/4, or 1/8) 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.
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.
The Collector can be configured to omit logging of sensitive information. This is called blinding, and it allows you to prevent passwords, credit card details, and other sensitive information from being recorded on disk. To implement a blinding, do the following:
Select Configuration, then Security, and then Blinding.
Use the View menu to select the required Collector system. The System (localhost) represents the Collector on the Reporter server system. The current defined blindings for the selected Collector are listed. Click « Add new blinding » to define a new blinding, or click an existing blinding to modify it. The dialog shown in Figure 8-6 appears:
Use the Variable field to specify the variable name that should blinded (overwritten with "X") within POST arguments.
When ready, click Save.
You are prompted to restart the Collector. This is necessary in order to make your changes effective.
Important:
It is strongly recommended that you regularly verify that all sensitive data is blinded correctly on a regular basis. Applications often change over time, and so do their use of POST variables. The Collector and Reporter raw log files can be found in the directories
/home/moniforce/websensor/data.Blinding Support
The ability to blind sensitive data is restricted to form-based POST data. Hence, the blinding of sensitive information within XML, URLs, and other non-form traffic is currently not supported.
By default, all cookie information within RUEI is hashed. This mechanism provides a unique identifier (a hash). However, while this provides a unique value for comparison purposes, it is not in a human-readable format. 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.
If you require real values within cookies to be logged, then you will need to disable the hashing facility. Do the following:
Select Configuration, then Security, and then Blinding. Use the View menu to select the required Collector. Click the Toggle Cookie hashing icon on the toolbar. The dialog shown in Figure 8-7 appears.
Use the check box to specify whether cookie hashing should be enabled or disabled. When ready, click Save.
Important
You should be aware that disabling the cookie hashing facility has the following implications:
Only the first 1 KB characters of the cookie value 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. Note that only the first 255 characters are visible within the Reporter interface. However, the full 1 KB characters are available through the enriched data export facility. For more information, see Section 9.16, "Exporting Enriched Data".
Any sensitive information placed in the cookie now becomes visible, not only in the Reporter interface, but also in any exported data that contains cookie information.
After changing this setting, comparison of historical data will not be possible because hashed and non-hashed values cannot be compared.
By default, the Replay Viewer (described in Section 3.8, "Working With the Replay Viewer") is disabled. To enable recording of server response content, do the following:
Select Configuration, then Security, then Blinding, and then click the Toggle Replay functionality icon on the toolbar. The dialog shown in Figure 8-8 appears.
Use the Replay functionality menu to enable or disable the recording of server response content. When ready, click Save.
Important
The Replay viewer shows "raw" collected data. That is, no defined blinding filters are applied. Therefore, any sensitive information contained within the content becomes visible in the Replay viewer.
When the Replay viewer is disabled, although no new data is collected, the previously collected data is still available. If you need to purge the previously collected data, log on as root to the Collector system holding the Replay database, and issue the following commands:
su - moniforce rm -rf /home/moniforce/appsensor/wg/REPLAY
You will need to repeat this process for each required Collector system.
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 the system. 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-9 appears:
Use the Key field to specify the file containing the key. If the key is encrypted, you must specify the passphase.
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.Optionally, you can also specify a key activation password to secure the private key and certificate on the system. The certificate will be encrypted on the disk. Note that you will be required to re-enter this password each time the Collector's system is restarted. When ready, click Install key.
To remove an installed SSL key, right click the required key, and select Remove. You are prompted to confirm the key's removal.
Each time the system on which a Collector is running is re-started, all keys are re-loaded. In the case of keys with activation passwords defined for them, their passwords must be re-entered. In order to re-activate all (non-expired) keys, do the following:
Click the Activate key(s) icon on the taskbar. If it is not already visible, select Configuration, then Security, and then SSL keys. The Activation keys dialog shown in Figure 8-10 appears:
Specify the required activation password. Note that the password you specify will be tried for all keys that have activation passwords defined for them. Hence, you will need to run the Activate keys dialog as many times as you have different activation passwords.
Important:
It is important that non-expired keys with passwords are re-activated after the Collector system is re-started. Otherwise, the related data can not be monitored.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 Monitor SSL key expiration dialog shown in Figure 8-11 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.6, "Using SNMP Notifications"
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).
|
 Copyright © 2008, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
