I visit customers on a regular basis. And when we sit together in front of the machine I sometimes spot tiny little things which may impose a security risk. This could be things such as
SEC_CASE_SENSITIVE_LOGON=FALSE or the use of
UTL_FILE_DIR or something else. To detect such sensitive spots you should download and use the Oracle Database Security Assessment Tool (DBSAT).
Download and use the Oracle Database Security Assessment Tool
First of all, you need to download the tool from MyOracle Support:
Afterwards you please may check the documentation:
Requirements and Database Releases
To execute the tool you will need the following database privileges and roles:
SELECT on SYS.REGISTRY$HISTORY
DV_SECANALYSTrole (in case Database Vault is active)
AUDIT_VIEWERrole (since Oracle 12c)
CAPTURE_ADMINrole (since Oracle 12c)
SYS.DBA_USERS_WITH_DEFPWD(since Oracle 11g)
AUDSYS.AUD$UNIFIED(since Oracle 12c)
The tool has two components:
- The DBSAT Collector executes SQL queries and runs operating system commands to collect data from the system to be assessed. It does this primarily by querying database dictionary views. The collected data is written to a file that is used by the DBSAT Reporter in the analysis phase.
- The DBSAT Reporter analyzes the collected data and reports its findings and recommendations in multiple formats: PDF, Excel, and Text. The Reporter can run on any machine: PC, laptop, or server. You are not limited to running it on the same server as the Collector.
You can run the DBSAT on database since Oracle Database 10.2.0.5 and on SPARC and Intel Solaris, Linux, Windows, HP-IA, AIX and zLinux.
Copy the zip file to a directory and unzip it, for example:
mkdir -p /home/oracle/dbsat unzip dbsat.zip –d /home/oracle/dbsat cd /home/oracle/dbsat
Execute the DBSAT Collector
Once you have ensured that the user you’ll use to execute DBSAT has all the above mentioned privileges and roles, you can execute it:
$ ./dbsat collect -n "/ as sysdba" dbsatrep
Another option would be for instance:
./dbsat collect scott /tmp/collect_result which interactively will ask you for scott’s password then.
Please see the entire command syntax for
Usage: dbsat collect [ -n ] dbsat report [ -a ] [ -n ] [ -x :section:] Options: -a Report about all user accounts, including locked, Oracle-supplied users -n No encryption for output -x Specify sections to exclude from report (may be repeated for multiple sections)
Execute the DBSAT Reporter
Generating a report is simple and straight forward – by default it will be password protected unless you will use the
./dbsat report dbsatrep
The result reports gives you summary information first:
And then you should watch out for yellow, orange and especially red marked entries such as:
And you’ll get also green messages when something is setup or used in the right way – and we know that this is crucial. Just speaking of old password versions:
Some remarks and findings
First of all, the report seem to run in
CDB$ROOT at first unless you direct it to specific PDBs. In my understanding it means you’ll have to execute DBSAT on a per-PDB basis. This makes sense of course. But I’d rather would have expected an option to run it in all containers in one pass and generate a consolidated report allowing to break down when necessary. This is the call to execute DBSAT in my PDB1:
./dbsat collect -n "sys/oracle@pdb1 as sysdba" dbsatpdb1
This works fine.
And finally, this struck me a bit:
Hm … DBSAT does not seem to be aware that BPs and RUs are a super-set of PSUs and RURs. My database is in better shape – I should get an extra star for applying RUs instead of RURs (or PSUs), and no RED ALERT should be shown.
Well, there’s always some room for improvement.
Finally, the Database Security Assessment Tool is very helpful and highly recommend. The warnings you get are mostly helpful and may signal some undetected risks and issues in your database. It will help you securing your database. And a few things need to be read with a grain of salt.
thanks for reviewing DBSAT. We are working to fix the patch finding rule.
I’ll let you know as the next release becomes available so you can give it a try.
Thanks Pedro 🙂
how to run the report in windows? i was able to collect but could not generate output.
can you please tell me which type of error (if any) you received? And how you tried to generate it?
nice article about DBSAT. I already tried it myself and it works fine – at least on 188.8.131.52 databases on Linux x86-64. Unfortunately, with all 184.108.40.206 databases I have issues with DBSAT and e.g. “SP2-0676: Bind variable length cannot exceed 1000 characters”. I hence already raised a question in the DB Sec community (https://community.oracle.com/message/14746286), waiting for anybody to have an idea on the source of the issue. But it was interesting to see that you encountered some (minor) findings with DBSAT.
Thanks and best regards,
Patrick – thanks – I will forward this to the DBSAT owners.
as I played around and found out myself, in the file “sat_collector.sql” there are some definitions that exceed some limit in (my) 220.127.116.11 databases:
var v_spool_file VARCHAR2(4000);
var err_buf VARCHAR2(4000);
Changing the 4000 value into 1000 leads to successful run 🙂
I already provided this feedback to MOS Doc ID 2138254.1 and will update the MOS community thread (link given above) accordingly.
If you have any other feedback, it would be nice to know.
Thanks and best regards,
Thanks Patrick – I will share this with Pedro from the team owning the DBSAT.
Thanks for your time and your effort!
Thanks for letting me know about this Mike. We will address the problem found.
We aim to give a seamless experience and have tested DBSAT on Oracle Databases 10.2.0.5 and higher (18c is already certified). I’m sorry you have run into this.
Since it’s the first time I’m seeing this issue, would you be kind to let us know if you have set NLS_LANG env variable?
We’d like to reproduce the problem and provide an appropriate fix.
DBSAT Product Manager
Oracle Database Security
please find my reply to your question on the Community entry that I created (https://community.oracle.com/message/14751061#14751061).