[ORACLE 11G]Failed Logon Delays特性

Hacking Prevention with Failed Logon Delays

A hacker may attempt a brute force hack to break into your Oracle Database. This is where they try constant logons to the database using some form. of a word list. To try to make brute force hacking more difficult, Oracle 11g includes a logon delay that takes effect after the third failed password entry attempt. After the third failed logon attempt, Oracle will incrementally delay subsequent logon or password prompts up to a maximum of 10 seconds. No delay will occur if the logon is successful.

Oracle 11g has added other features that improve security. You can configure actions related to bad packet reception, or the trace action that should occur should a bad packet be received, as well as the maximum number of failed logon attempts that a client can make before it's connection is dropped. Finally you can opt to enable or disable communication of the release banner to a client when it connects. These are all controlled by the following new parameters:

• sec_protocol_error_further_action - This parameter defines the action that should take place in the event that a bad packet is received from a remote system. This parameter can be set to the following options:
   
  • CONTINUE - Do not disconnect the client session. This is the default setting.
     
  • DROP - Drop the client connection after a specific number of bad packets. This parameter takes an integer argument that defines the number of bad packets that are acceptable.
     
  • DELAY - Delay accepting client requests after a bad packet is requested. This parameter takes an integer argument that defines the delay time in seconds.

  An example of setting this parameter is seen in this code sample. Note that the parameter sec_protocol_error_further_action is not a dynamic parameter, so you need to use the scope=spfile setting to properly set this parameter:

  
  

  ALTER SYSTEM SET sec_protocol_error_further_action='DROP' scope=spfile;

• sec_protocol_error_trace_action - This parameter defines the level of tracing that should occur when bad packets are received. This parameter can be set to the following values:

  • NONE - No logging occurs.
     
  • TRACE - A trace file is generated when bad packets are received. This is the default setting.
     
  • LOG - A small logging message is entered in the database alert log.
     
  • ALERT - An alert message is sent to the DBA via OEM.

  An example of setting this parameter is seen in the following code example. Note that the sec_protocol_error_trace_action parameter is dynamic:

  
  

  ALTER SYSTEM SET sec_protocol_error_trace_action='LOG';

• sec_max_failed_login_attempts - This parameter controls the number of authentication attempts that a given client connection can make on the server before the client process is dropped. The default value is 10. The sec_max_failed_login_attempts parameter is not dynamic and an example of it's use can be set as seen in this code sample:

  
  

  ALTER SYSTEM SET sec_max_failed_login_attempts=5 scope=spfile;

• sec_return_server_release_banner - This parameter indicates if the server banner will be returned to a client connection. Not returning the banner will make hacking a database more difficult since the user will not know which version of the database they are trying to hack. The default value is TRUE and sec_return_server_release_banner is a dynamic parameter. An example of the use of this parameter is seen in this example:

  
  

  ALTER SYSTEM SET sec_return_server_release_banner=FALSE;

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15747463/viewspace-755776/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15747463/viewspace-755776/