Various organizations provide various security guidelines to aid us in hardening our databases. They are an EXCELLENT tool to this end and I cannot recommend enough reading and research in this regard. However, blindly implementing the guidelines is not a security panacea!!! It takes a knowledgeable DBA teaming with insightful IA personnel to determine if the guidelines make sense in your situation. I’ll illustrate this with an example:
How to Follow DoD/DISA Database Security Guidelines to Make Your Oracle Database Vulnerable to a Denial of Service (DoS) Attack
Necessary items:
- The latest Security Technical Implementation Guide (STIG) for Databases from the Defense Information Systems Agency (DISA) Field Security Operations Division
- Oracle Client (Free for learning!)
- A text editor (available with every Operating System): vi, Textedit, Notepad etc.
- Pete Finnigan’s list of common and default Oracle userids
Step 1. Apply the latest STIG Guidence to your database – Especially Item DG0073 in Section 3.3.10 – “The DBA will configure the DBMS to lock database accounts after 3 consecutive unsuccessful connection attempts within a specified period of time.”
Step 2. Mine Pete Finnigan’s list of common and default Oracle userids, and put them in a text file. Feel free to add any common database connection userids for popular applications.
Step 3. Use a command to iteratively feed the user ids from your file to sqlplus with a bogus password (MSWindows):
C:\>for /f "tokens=*" %I in (test.txt) do @sqlplus -L %I/NotThePassword@SID
Step 4. Repeat. After the 3rd incorrect password, the database account will be locked, and the application cannot connect until the account is unlocked by a privileged user.
Granted, if all the other items listed in the STIG are implemented, this will be extremely difficult (if not impossible) to accomplish from the outside, but it is easily accomplished by anyone who has access to the Oracle client (or JDBC, ODBC etc.) on any of the application servers – providing opportunity to an insider who doesn’t necessarily have database access.
This isn’t a specific Oracle issue, or an OS issue - the guidance is general enough to cover any DB/OS combination. The DISA/DoD STIG isn’t solely to blame either. The same guidance can be gained here, here, etc.
The larger issue, effectively securing your database, requires a bit of paradigm shift, a willingness to focus on the goal, (rather than the method) and a lot of teamwork and trust between DBAs and IA professionals.
The 3rd Alternative
When creating your roles, consider the automated, application users in your database and do not set a limit for unsuccessful login attempts on those accounts. To keep brute force and dictionary attacks at bay, you’ll need to ensure the application’s database account passwords are long and strong. Putting your database behind a stout firewall is also key - Isolating your database server from the internet altogether is really the best idea. Using the guidelines that are appropriate for your environment in 3.1.4.1 of the Database STIGs will further harden your installation.
After that, your best defense is malicious activity detection via auditing:
select USERNAME, count(USERNAME) from DBA_AUDIT_TRAIL where RETURNCODE=1017 and TIMESTAMP > CURRENT_DATE - interval '3' day group by USERNAME;
If you set up auditing, and use something like the SQL above to provide the raw instrumentation data for your database, you’ll be able to trend and perform velocity checks to sound the alarm when trouble may be in progress.
And that strengthens our security posture.
Brian Fedorko