Security parameters in 11G and 12C

            There are 5 parameters that are all prefixed with ‘sec’ in an 11g and 12c database. Actually that is a lie because one is now deprecated in 12c. They are all, as you might guess related to security. This blog is about changes in the default values and some thoughts about whether or not the default value is appropriate or not.

• SEC_CASE_SENSITIVE_LOGON     TRUE in 11GR1 , 11GR2, DEPRECATED IN 12C
• SEC_MAX_FAILED_LOGIN_ATTEMPTS     default 11GR1,11GR2=10, 12c=3
• SEC_PROTOCOL_ERROR_FURTHER_ACTION     default is  CONTINUE in 11GR1, 11GR2, drop, 3 in 12c
• SEC_PROTOCOL_ERROR_TRACE_ACTION     default is TRACE 11GR1,11GR2, 12c
• SEC_RETURN_SERVER_RELEASE_BANNER     default is FALSE in 11GR1, 11GR2, TRUE in 12c

• SEC_CASE_SENSITIVE_LOGON

Let’s cover the deprecated one first. This came along in 11g (as all 5 did) and is now deprecated as 12c  is forcing case sensitive passwords. In parallel the orapwd function in 12c no longer has the ignorecase option either.
The one application that I know does not support case sensitive passwords is EBS R12.1.1 but there is a patch (12964564) if you wish to upgrade to 12c (or even continue to run at 11GR1) .

• SEC_MAX_FAILED_LOGIN_ATTEMPTS

Now defaults to 3 in 12c from the 11Gx default of 10,  which is not unreasonable. This allows a client to attempt a connection 3 times (multiple accounts) before dropping the connection.

• SEC_PROTOCOL_ERROR_TRACE_ACTION

This takes action if bad packets are identified as coming in from a client. The default is TRACE and again I would challenge that position. The other viable options are LOG which produces a minimal log file and  also an alert to the alert log or just ALERT or do nothing – NONE. The TRACE has the possibility of filling disk up which could have the same effect as a DoS attack which the parameter is trying to stop therefore I think I prefer the LOG option rather than just the ALERT option. However if you are alerting ensure that you have written a trap in whatever you use to parse your alert logs to spit out the message to your monitoring screens. A nice by-product of this alert is that you can now formally pass it onto the network team and you have sufficient evidence to do so.
 

• SEC_PROTOCOL_ERROR_FURTHER_ACTION

This is where it gets a bit tricky and we have another change in 12c. In 11g the default was CONTINUE, therefore if you had tracing set in the previous parameter you could end up with a lot of logging going on. I think the CONTINUE was the correct option in 11G as you do not want to stop valid connections into a production system because the packet might look bad – not without some degree of authorization at least.
From 12c the default has changed to DROP, 3. This means drop the connection after 3 bad packets have arrived from a client. Which sounds good as potentially a trace file will not become too big. However there is nothing stopping a client attempting many such connections, all with bad packets, which could potentially cause a DoS, not by using all your processes, but by filling your log area.
With this change of default I think it is even more important to know when connections are being dropped by the SEC_PROTOCOL_ERROR_TRACE_ACTION parameter and that is why I would suggest setting SEC_PROTOCOL_ERROR_FURTHER_ACTION to CONTINUE

• SEC_RETURN_SERVER_RELEASE_BANNER

This parameter specifies whether the server returns complete database software information to unauthenticated clients. The default is FALSE  in all versions despite the 12C  documentation stating that the default is now TRUE. Oracle have chosen that default  as the whole point of security is to not give away any more information than you have to and that cannot be argued with.