Search filters this STIG's checks locally. Separate terms must all match (use quotes for an exact phrase). A search you ran on the Search page carries over here.
Assessment Title
Rule Text
Oracle Database must protect against or limit the effects of organization-defined types of denial-of-service (DoS) attacks.
Description
Discussion Text
DOS attacks, more correctly characterized as "Denial-of-Service Events" as they most often the result of run-away processes and accidents, are the result of an excessive demand for a limiting resource.
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 but within the database itself, Oracle provides the following mechanisms:
1. Reduction of excessive concurrent connections from a single user (see STIG_ID O19C-00-000100).
2. Limiting the database connection rate (LISTENER.ORA).
3. Limiting the amount of CPU available to users with Profile kernel limits.
4. Limiting the amount of I/O available to users with Profile kernel limits.
5. Limiting the amount of storage space with tablespace quotas.
6. Limiting idle time with profile kernel limits.
Other best practices such as limiting the number of parallel handles available to users with Resource Manager Plans or using CMAN are also recommended as part of an overall plan for DoS prevention.
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 but within the database itself, Oracle provides the following mechanisms:
1. Reduction of excessive concurrent connections from a single user (see STIG_ID O19C-00-000100).
2. Limiting the database connection rate (LISTENER.ORA).
3. Limiting the amount of CPU available to users with Profile kernel limits.
4. Limiting the amount of I/O available to users with Profile kernel limits.
5. Limiting the amount of storage space with tablespace quotas.
6. Limiting idle time with profile kernel limits.
Other best practices such as limiting the number of parallel handles available to users with Resource Manager Plans or using CMAN are also recommended as part of an overall plan for DoS prevention.
New to STIG checklists? Read What is a STIG checklist? and CKL vs CKLB.