SQL4-00-000100 - The number of concurrent SQL Server sessions for each system account must be limited.

Warning! Audit Deprecated

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

Information

A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices on an organization's internal network from being directly affected by DoS attacks.

One way SQL Server can limit exposure to DoS attacks is to restrict the number of connections that can be opened by a single user. SQL Server supports this through the use of logon triggers. (Note, however, that this need not be the only, or even the principal, means for satisfying this requirement. Depending on the architecture and capabilities of the network and application, a network device or an application may be more suitable for providing this protection.)

When determining the appropriate values for this limit, take the characteristics of the various kinds of user into account, and bear in mind that some applications and some users may need to have multiple sessions open. For example, while a standard account using a simple application may never need more than, say, five connections, a database administrator using SQL Server Management Studio may need significantly more, because each tab in that application counts as a distinct session.

Architectural note: In SQL Server, a count of active sessions by user can be obtained from one of the dynamic management views. For example:
SELECT original_login_name, count(*)
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
GROUP BY original_login_name;
However, for this to return an accurate count in a logon trigger, the user would have to have the View Server State privilege. (Without this privilege, the trigger sees information only about the current session, so would always return a count of one.) View Server State would give that user access to a wide swath of information about the server. One way to avoid this exposure is to create a summary table, and a view of that table that restricts each user to seeing his/her own count, and establish a frequently-run background job to refresh the table (using the above query or similar). The logon trigger then queries the view to obtain a count that is accurate enough for this purpose in most circumstances.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

Establish the limit(s) appropriate to the type(s) of user account accessing the SQL Server instance, and record them in the system documentation.

Implement one or more logon triggers to enforce the limit(s), without exposing the dynamic management views to general users.

Item Details

Audit Name: DISA STIG SQL Server 2014 Instance DB Audit v2r3

Plugin: MS_SQLDB

Control ID: 92e1f1f0b6bcc3979da626e607ca43b511eb3a8e388dffca84ebc6f08d933927

Detections

Analytics

SQL4-00-000100 - The number of concurrent SQL Server sessions for each system account must be limited.

Warning! Audit Deprecated

Information

Solution

See Also

Item Details