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_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

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
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) .


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.


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.


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.
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


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.

  • July 15, 2018 | 16 views
  • Comments