Oracle 11g automatically delays the logon prompt after the third unsuccessful logon attempt gradually up to 10 seconds with every next try to logon with another password.

Additionally Oracle has introduced a number of new security parameters for the spfile, among others to protect against denial of service and brute force attacks.

Also see these important notes on Oracle listener auditing and monitor TNS protocol attacks.

Let's take a look at these parameters:

Sec_max_failed_login_attempts specifies the number of unsuccessful authentication attempts from a client to the server before the client process is dropped. This parameter targets against brute force attacks with automated password crackers which try to attempt to create a server process in the first place and then issue an unlimited number of authentication requests by trying different user accounts and passwords in order to gain access to the database. The default value for this parameter is 10.

Here is an example:

I have created a logon script which tries to logon as user lutz and uses different passwords one after the other. You can see that for the first 10 times Oracle continues to throttle the logon prompt and after the 10^th. attempt the account is automatically locked:

SQL> start logon
ERROR:
ORA-01017: invalid username/password; logon denied 

Warning: You are no longer connected to ORACLE.
Elapsed: 00:00:00.10
ERROR:
ORA-01017: invalid username/password; logon denied 

Elapsed: 00:00:00.19
ERROR:
ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:00.28
ERROR:
ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:01.39
ERROR:
ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:03.49
ERROR:
ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:06.58
ERROR:
ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:10.68
ERROR:
ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:15.79
ERROR:
ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:21.95
ERROR:
ORA-01017: invalid username/password; logon denied

Elapsed: 00:00:29.13
ERROR:
ORA-28000: the account is locked

Elapsed: 00:00:29.47
ERROR:
ORA-28000: the account is locked

Elapsed: 00:00:29.83
ERROR:
ORA-28000: the account is locked

The two parameters sec_protocol_error_further_action and  sec_protocol_error_trace_action are parameters which specify how the database should react in case of denial of service attacks (DoS).

For those attacks aggressive clients send packets through the Oracle Call Interface (OCI) which then cause very large dump files on disk which lead to disk flooding and denial of service.

Sec_protocol_error_further_action can be set to:

• CONTINUE  

• DELAY, n  

• DROP, n .

With DELAY, n you can specify in seconds how long the server waits before it accepts further requests. This can prevent malicious clients from permanently consuming resources and thus slowing the system down.

By setting the parameter to DROP, n you specify that the client connection will be dropped after the n^th bad packet has been received.

Sec_protocol_error_trace_action defaults to TRACE. This is helpful for debugging if a client sends bad packets as the result of a bug because it creates the trace file on disk which can then be further analyzed.

By setting this parameter to LOG you can prevent the creation of very large traces on disk. The server then only creates a short message in the server trace file. Here the danger of DoS is banned and the availability of the database server is protected. At the same time a certain minimum amount of necessary auditing information is available.

The setting ALERT causes a short message in the alert.logs additional to the trace file created with LOG. 

In order to reduce information about the database system a client receives as a banner when it logs on it is possible to set sec_return_server_release_banner to TRUE. Then the Oracle server should not send information about the installed modules and the used version. This would make it more difficult to hack the database server because the aggressor cannot know the possible vulnerabilities. The default setting is FALSE and you must restart the instance to make a change to this parameter effective.

With release 11.1.0.6, this parameter does not really appear to work yet. I cannot see any difference in the returned banner on my system with either setting.