Detections
Analytics

O121-C2-017600 - The DBMS must terminate user sessions upon user logoff or any other organization or policy-defined session termination events, such as idle time limit exceeded

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

This requirement focuses on communications protection at the application session, versus network packet, level.

Session IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs, which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attackers are unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that particular user session.

Database sessions must be terminated when no longer in use in order to prevent session hijacking.

Solution

Configure DBMS settings to terminate sessions upon user logoff. Configure DBMS settings to terminate sessions upon the occurrence of any organization or policy-defined session termination event.

- - - - -

To configure specific session termination processes, we need to define the organization or policy-defined session termination event. Below are some examples.

Oracle has several ways to disconnect idle sessions, both from within SQL*Plus via resources profiles (connect_time, idle_time) and with the SQL*net expire time parameter.

Can use profiles to set the connect time and idle time with 'alter profile' statements:

alter profile senior_claim_analyst limit
connect_time 15
sessions_per_user 2
ldle_time 10;

Profiles comprise a named set of resource limits. By default, when users are created, they are given the default profile, which provides unlimited use of all resources.

The syntax to create a profile follows:

CREATE PROFILE LIMIT resource_parameters|password_parameters;
Resource_parameters:
[SESSIONS_PER_USER n|UNLIMITED|DEFAULT]
[CPU_PER_SESSION n|UNLIMITED|DEFAULT]
[CPU_PER_CALL n|UNLIMITED|DEFAULT]
[CONNECT_TIME n|UNLIMITED|DEFAULT]
[IDLE_TIME n|UNLIMITED|DEFAULT]

By setting resource limits, can prevent users from performing operations that will tie up the system and prevent other users from performing operations. Can use resource limits for security, to ensure that users log off the system, so as not to leave the session connected for long periods of time.

The system resource limits can be enforced at the session level, the call level, or both. The session level is calculated from the time the user logs on to the database until the user exits. The call level applies to each SQL command issued. Session-level limits are enforced for each connection. When a session-level limit is exceeded, only the last SQL command issued is rolled back; no further work can be performed until a commit, rollback, or exit is performed.

Using SQLNET.EXPIRE_TIME

The sqlnet.expire_time parameter is used to set a time interval, in minutes, to determine how often a probe should be sent verifying that client/server connections are active. If there is a need to ensure that connections are not left open indefinitely (or up to the time set by operating system-specific parameters), set a value that is greater than 0. This protects the system from connections left open due to an abnormal client termination.

When the probe detects a terminated connection or a connection no longer in use, it signals an error, causing the server process to exit. This setting is intended for use on the database server side of the connection, which usually handles multiple connections at any one time. Limitations on using this terminated (dead) connection detection feature are:

sqlnet.expire_time cannot be used on bequeathed connections.

The SQL*Net expire_time probe packet will generate additional network traffic that may downgrade the network's performance, depending on the number of connections.

Depending on the operating system that is in use, additional server processing may need to be performed to distinguish the connection probe from other events that occur. This overhead for detection of probe events can result in downgraded network performance.

Turning-on expire_time

To set up these advanced features, simply edit the sqlnet.ora file. If a beginner, follow this procedure:

Start the Oracle Network Manager GUI.

In the GUI navigator pane, expand the icons Local >> Profile.

From the list on the right-hand pane, select General.

Click on the Advanced tab.

Next, enter the values for the fields or options to set.

When finished, choose File >> Save Network Configuration to write the changes to the sqlnet.ora file. (Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file 'Non-default sqlnet.ora configurations.pdf' for how to find multiple and/or differently located sqlnet.ora files.)

The sqlnet.ora inbound_connect_timeout parameter

The sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set in seconds, for a client to connect with the database server and provide the required authentication information.

Also see sqlnet.inbound_connect_timeout tips.

To limit consumption of Oracle resources by unauthorized users and enable an audit trail, should set time-limit values for the sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter does not have default values.) Failure resulting from sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed out error.

See Also

https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_Oracle_Database_12c_V2R8_STIG.zip

Item Details

References: CAT|II, CCI|CCI-001185, Rule-ID|SV-220295r879637_rule, STIG-ID|O121-C2-017600, STIG-Legacy|SV-76255, STIG-Legacy|V-61765, Vuln-ID|V-220295

Plugin: OracleDB

Control ID: 0e03824e38f9398454fa53650e594801e4a2d48fd2dc9db4b6ab6c25de05f2b5