Security parameters in 11G and 12C
Posted by John Hallas on April 8, 2015
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|
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) .
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.
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.
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 authorisation 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
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.
So my joint recommendations for these parameters are :
- Ensure SEC_RETURN_SERVER_RELEASE_BANNER is set to the default of FALSE on all databases
- Set SEC_PROTOCOL_ERROR_TRACE_ACTION to LOG and ensure that traps are in place to capture the alerts
- Set SEC_PROTOCOL_ERROR_FURTHER_ACTION to CONTINUE, or at least ensure that if you are dropping connections then that has been communicated to interested parties who may not be able to get to the service they need to. A good half-way house would be to use (DELAY,3) to delay a packet by 3 seconds but it is important that all support parties are aware if this is enabled.
Finally, I will be posting a follow-up blog on Friday which covers some discrepancies in the 12c dictionary and seems to be a major issue but I need to do some more research first.
This entry was posted on April 8, 2015 at 9:26 am and is filed under 11g new features, 12c new features, Oracle. Tagged: 12c security parameters, SEC_CASE_SENSITIVE_LOGON, SEC_MAX_FAILED_LOGIN_ATTEMPTS, SEC_PROTOCOL_ERROR_FURTHER_ACTION, SEC_PROTOCOL_ERROR_TRACE_ACTION, SEC_RETURN_SERVER_RELEASE_BANNER. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.