Friday, June 2, 2017

How Secure Can We Make Our Oracle Databases?


How Secure Can We Make Our Oracle Databases?

As a database administrator, one of the most critical questions that constantly arises is: How secure are our databases, and can we make them any more secure? Ensuring the security of your Oracle databases is crucial, as they are often the backbone of an organization’s data infrastructure. Over the years, I’ve adopted several best practices to enhance database security. Below, I share some key tips and strategies that I follow to secure my databases:

  1. Grant Access on a Need-to-Know Basis

Always follow the principle of least privilege by granting access only to users who genuinely need it. This minimizes exposure and reduces the risk of unauthorized actions within the database.

    2. Remove Unnecessary Grants and Privileges

Regularly review and clean up unnecessary permissions from users and roles. Privileges that are no longer needed should be revoked to prevent misuse or accidental data exposure.

    3. Audit Failed Logins Regularly

Implement frequent audits of Failed Logins attempts to detect unauthorized access attempts. Monitoring failed logins helps identify suspicious activities and potential security threats. 

    4. Evaluate Requests for Elevated Privileges

When a user requests elevated privileges, always engage in a conversation to understand their requirements. Assess if the elevated access is genuinely necessary and grant it only if justified.

    5. Grant the Minimum Required Access

Ensure that users are granted no more access than what is absolutely necessary for their tasks. Avoid giving broad permissions, as this increases the risk of accidental or malicious actions.

    6. Manage Temporary Access Carefully

Sometimes, users need access temporarily for specific tasks. Make sure to track and revoke these temporary permissions immediately after the task is completed to maintain security.

    7. Define Clear Boundaries for Data Access

Clearly define which users can access specific data. Implement fine-grained access control to restrict access to sensitive data based on roles and responsibilities.

    8. Use User Profiles and Audit Features

Leverage Oracle’s User profiles & Audit capabilities to monitor and enforce security policies. Track all user activities to ensure accountability and detect any unauthorized actions. 

    9. Enforce Complex Password Policies

Implement strong password policies that require complexity and regular changes. Complex passwords significantly enhance security by making unauthorized access more difficult. Here is the Link on how to do it 

    10. Use Triggers to Track User Activity

Utilize database triggers to monitor user actions such as logins, DML operations, and changes to critical tables. This helps in tracking user behavior and detecting anomalies. Use Triggers to track user activity.

    11. Encrypt Passwords in Applications

Ensure that passwords used in applications are encrypted. Storing plain-text passwords poses a significant security threat, especially if application code is compromised.

    12. Secure the Oracle Listener with a Password

Protect your Oracle Listener with a password to prevent unauthorized access and control over database connections. This adds an additional layer of security to your database environment.

    13.  Restrict Access to Known Servers and Clients

Use Oracle’s VALID_NODE_CHECKING feature to restrict database access to specific, known servers or clients. This helps protect your database from unauthorized network access. Use this Valid_node_checking Link on how to restrict access to servers/clients.

Conclusion

Securing your Oracle databases is an ongoing process that requires continuous vigilance, regular audits, and updates to security protocols. By implementing these best practices, you can significantly enhance the security of your Oracle environments and protect your data from unauthorized access and potential threats. Remember, security is not a one-time setup but a continuous practice that evolves with emerging threats and changes in your database infrastructure.


Thursday, December 15, 2016

java.lang.SecurityException: The jurisdiction policy files are not signed by a trusted signer



I was trying to Install OID (Oracle Identity Manager) and I got this error :

Problem:




        at oracle.as.install.engine.modules.configuration.standard.StandardConfigActionManager.start(StandardConfigActionManager.java:186)
        at oracle.as.install.engine.modules.configuration.boot.ConfigurationExtension.kickstart(ConfigurationExtension.java:81)
        at oracle.as.install.engine.modules.configuration.ConfigurationModule.run(ConfigurationModule.java:86)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.SecurityException: Can not initialize cryptographic mechanism
        at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:88)
        ... 31 more
Caused by: java.lang.SecurityException: The jurisdiction policy files are not signed by a trusted signer!
        at javax.crypto.JarVerifier.verifyPolicySigned(JarVerifier.java:328)
        at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:317)
        at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:262)
        at javax.crypto.JceSecurity.access$000(JceSecurity.java:48)
        at javax.crypto.JceSecurity$1.run(JceSecurity.java:80)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:77)



Cause:

My current version of java was 1.8.* which is not fully supported.
In this case JDK 1.8.0.1 is installed on all nodes in the cluster and JCE local policy version 6 was used for AES 256 kerberos encryption. JCE must be in sync with the JDK version.
      
[oracle@linux06 jdk1.8.0_111]$ cd ..
[oracle@linux06 java]$ ls
default  jdk1.8.0_111  latest
[oracle@linux06 java]$ cd default/
[oracle@linux06 default]$ ls
bin        javafx-src.zip  man          THIRDPARTYLICENSEREADME-JAVAFX.txt
COPYRIGHT  jre             README.html  THIRDPARTYLICENSEREADME.txt
db         lib             release
include    LICENSE         src.zip


Solution:

Download :

For Java 6 use :
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html

For Java 7 use :
http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

For java 8 use :
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html        

********************    ********************    ********************
Update java with with new java unlimted jusrisdiction :
********************    ********************    ********************

After download and unzip :

[oracle@linux06 JCE]$ unzip jce_policy-8.zip
Archive:  jce_policy-8.zip
   creating: UnlimitedJCEPolicyJDK8/
  inflating: UnlimitedJCEPolicyJDK8/local_policy.jar
  inflating: UnlimitedJCEPolicyJDK8/README.txt
  inflating: UnlimitedJCEPolicyJDK8/US_export_policy.jar
[oracle@linux06 JCE]$ ls -ll
total 16
-rw-rw-r--. 1 oracle oracle 8409 Dec 14 10:39 jce_policy-8.zip
drwxrwxr-x. 2 oracle oracle 4096 Dec 20  2013 UnlimitedJCEPolicyJDK8
[oracle@linux06 JCE]$ pwd
/u01/app/SFTW/JCE
[oracle@linux06 JCE]$ ls
jce_policy-8.zip  UnlimitedJCEPolicyJDK8
[oracle@linux06 JCE]$ cd UnlimitedJCEPolicyJDK8/
[oracle@linux06 UnlimitedJCEPolicyJDK8]$ ls
local_policy.jar  README.txt  US_export_policy.jar

********************    ********************    ********************
as root user backup and replace files (US_export_policy & local_policy.jar)
********************    ********************    ********************

[oracle@linux06 security]$ su root
Password:
[root@linux06 security]# ls
blacklist          java.policy    local_policy.jar
blacklisted.certs  java.security  trusted.libraries
cacerts            javaws.policy  US_export_policy.jar
[root@linux06 security]# cd /usr/java/default/jre/lib/security
[root@linux06 security]# mv US_export_policy.jar US_export_policy.jar_bak
[root@linux06 security]# mv local_policy.jar local_policy.jar_bak
[root@linux06 security]# ls -ll
total 164
-rw-r--r--. 1 root root   4054 Sep 22 18:23 blacklist
-rw-r--r--. 1 root root   1273 Sep 22 18:23 blacklisted.certs
-rw-r--r--. 1 root root 112860 Sep 22 18:23 cacerts
-rw-r--r--. 1 root root   2466 Sep 22 18:23 java.policy
-rw-r--r--. 1 root root  27358 Sep 22 18:23 java.security
-rw-r--r--. 1 root root     98 Sep 22 18:23 javaws.policy
-rw-r--r--. 1 root root   3405 Sep 22 18:35 local_policy.jar_bak
-rw-r--r--. 1 root root      0 Sep 22 18:23 trusted.libraries
-rw-r--r--. 1 root root   2920 Sep 22 18:35 US_export_policy.jar_bak
[root@linux06 security]# pwd
/usr/java/default/jre/lib/security
[root@linux06 security]# cp /u01/app/SFTW/JCE/UnlimitedJCEPolicyJDK8/US_export_policy.jar /usr/java/default/jre/lib/security
[root@linux06 security]# cp /u01/app/SFTW/JCE/UnlimitedJCEPolicyJDK8/local_policy.jar /usr/java/default/jre/lib/security
[root@linux06 security]# ls -ll
total 172
-rw-r--r--. 1 root root   4054 Sep 22 18:23 blacklist
-rw-r--r--. 1 root root   1273 Sep 22 18:23 blacklisted.certs
-rw-r--r--. 1 root root 112860 Sep 22 18:23 cacerts
-rw-r--r--. 1 root root   2466 Sep 22 18:23 java.policy
-rw-r--r--. 1 root root  27358 Sep 22 18:23 java.security
-rw-r--r--. 1 root root     98 Sep 22 18:23 javaws.policy
-rw-r--r--. 1 root root   3035 Dec 14 10:47 local_policy.jar
-rw-r--r--. 1 root root   3405 Sep 22 18:35 local_policy.jar_bak
-rw-r--r--. 1 root root      0 Sep 22 18:23 trusted.libraries
-rw-r--r--. 1 root root   3023 Dec 14 10:46 US_export_policy.jar
-rw-r--r--. 1 root root   2920 Sep 22 18:35 US_export_policy.jar_bak

Thursday, December 8, 2016

bash: /bin/install/.oui: No such file or directory


 Problem:

[oracle@linux5 database]$ . runInstaller
bash: /bin/install/.oui: No such file or directory
[oracle@linux5 database]$ uname -a
Linux linux5 3.8.13-16.2.1.el6uek.x86_64 #1 SMP Thu Nov 7 17:01:44 PST 2013 x86_64 x86_64 x86_64 GNU/Linux


Solution:



[oracle@linux5 database]$ ./runInstaller
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 120 MB.   Actual 20461 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 4031 MB    Passed
Checking monitor: must be configured to display at least 256 colors.    Actual 16777216    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2016-11-22_09-46-02AM. Please wait ...[oracle@linux5 database]$

Friday, December 2, 2016

uninstall java on linux

If you are not sure of what the dependent packages that might be blocking java then you can also use yum remove jdk*
This will also take care of dependent rpms.

[root@linux06 usr]# yum remove jdk1.8.0_111-1.8.0_111-fcs.i586

Loaded plugins: refresh-packagekit, security
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package jdk1.8.0_111.i586 2000:1.8.0_111-fcs will be erased
--> Processing Dependency: java for package: jna-3.2.4-2.el6.x86_64
--> Running transaction check
---> Package jna.x86_64 0:3.2.4-2.el6 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================
 Package           Arch        Version                 Repository                                                Size
======================================================================================================================
Removing:
 jdk1.8.0_111      i586        2000:1.8.0_111-fcs      @/jdk-8u111-linux-i586                                   259 M
Removing for dependencies:
 jna               x86_64      3.2.4-2.el6             @anaconda-OracleLinuxServer-201311252058.x86_64/6.5      298 k

Transaction Summary
======================================================================================================================
Remove        2 Package(s)

Installed size: 259 M
Is this ok [y/N]: Y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.
  Erasing    : jna-3.2.4-2.el6.x86_64                                                                             1/2
  Erasing    : 2000:jdk1.8.0_111-1.8.0_111-fcs.i586                                                               2/2
  Verifying  : 2000:jdk1.8.0_111-1.8.0_111-fcs.i586                                                               1/2
  Verifying  : jna-3.2.4-2.el6.x86_64                                                                             2/2

Removed:
  jdk1.8.0_111.i586 2000:1.8.0_111-fcs                                                                               

Dependency Removed:
  jna.x86_64 0:3.2.4-2.el6                                                                                           

Complete!

Monday, November 14, 2016

Is it safe to move/recreate alertlog while the database is up and running



 Is it safe to move/recreate alertlog while the database is up and running??


It is totally safe to "mv" or rename it while we are running. Since chopping part of it out would be lengthly process, there is a good chance we would write to it while you are editing it so I would not advise trying to "chop" part off -- just mv the whole thing and we'll start anew in another file.

If you want to keep the last N lines "online", after you mv the file, tail the last 100 lines to "alert_also.log" or something before you archive off the rest.



[oracle@Linux03 trace]$ ls -ll alert_*
-rw-r-----. 1 oracle oracle   
488012 Nov 14 10:23 alert_orcl.log

I will rename the existing alertlog file to something
 
[oracle@Linux03 trace]$ mv alert_orcl.log alert_orcl_Pre_14Nov2016.log

[oracle@Linux03 trace]$ ls -ll alert_*
-rw-r-----. 1 oracle oracle 488012 Nov 14 15:42 alert_orcl_Pre_14Nov2016.log
[oracle@Linux03 trace]$ ls -ll alert_*


Now let's create some activity that will need to update the alertlog.

[oracle@Linux03 bin]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Mon Nov 14 16:23:02 2016

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> alter system switch logfile;

System altered.

SQL> /

lets see if the new alertlog file has been created.

[oracle@Linux03 trace]$ ls -ll alert_*
-rw-r-----. 1 oracle oracle    249 Nov 14 16:23 alert_orcl.log
-rw-r-----. 1 oracle oracle 488012 Nov 14 15:42 alert_orcl_Pre_14Nov2016.log

Thursday, November 3, 2016

Directory permissions granted to a user in Oracle database

Querying directory permissions granted to a user


To query directory permissions granted to users in Oracle Database, you can use the DBA_TAB_PRIVS view. This view contains information about table and directory object privileges granted to users. Specifically, you want to retrieve information about directory privileges granted to users for a particular directory object.

Here’s a refined SQL query to achieve this, including sample output:

SQL Query:

sql:


SELECT
grantee AS "GRANTEE", table_name AS "DIRECTORY_NAME", LISTAGG(privilege, ',') WITHIN GROUP (ORDER BY privilege) AS "GRANTS" FROM dba_tab_privs WHERE table_name = 'DPUMP' GROUP BY grantee, table_name;

Columns Explanation:

  • grantee: The user or role to whom the privilege is granted.
  • table_name: The name of the directory object. In Oracle, directories are also managed as table-like objects in the DBA_TAB_PRIVS view.
  • LISTAGG(privilege, ',') WITHIN GROUP (ORDER BY privilege): Aggregates the list of privileges granted to each user, separating them by commas.

Sample Output:



GRANTEE DIRECTORY_NAME GRANTS
-------------------- ------------------------------ -------------------- SCOTT DPUMP READ,WRITE TIGER DPUMP READ,WRITE TOM DPUMP READ,WRITE CAM DPUMP READ,WRITE SAM DPUMP READ,WRITE


Usage Notes:

  1. Adjust Table Name: Make sure to replace 'DPUMP' in the WHERE clause with the actual directory name you want to query.
  2. Privileges: The privilege column typically includes access types such as READ and WRITE.
  3. Oracle Versions: The DBA_TAB_PRIVS view is standard across Oracle versions, but always refer to your specific Oracle documentation for any version-specific details.

This query helps database administrators quickly review and manage directory access permissions granted to different users, ensuring appropriate access control and security.

Failed to auto-stop Oracle Net Listener using ORACLE_HOME/bin/tnslsnr



Usage : we can use dbshut script file in $ORACLE_HOME/bin to shutdown  database & listener.

 [oracle@Linux03 bin]$ ps -ef|grep pmon
oracle   20693     1  0 10:57 ?        00:00:00 ora_pmon_orcl
oracle   21133 19211  0 11:01 pts/0    00:00:00 grep pmon

[oracle@Linux03 bin]$ dbshut
Processing Database instance "orcl": log file /u01/app/oracle/product/12.1.0.2/db_1/shutdown.log

[oracle@Linux03 bin]$ ps -ef|grep pmon
oracle   21287 19211  0 11:09 pts/0    00:00:00 grep pmon
[oracle@Linux03 bin]$





Error : Failed to auto-stop Oracle Net Listener using ORACLE_HOME/bin/tnslsnr

[oracle@Linux03 bin]$ dbshut

Failed to auto-stop Oracle Net Listener using ORACLE_HOME/bin/tnslsnr


 Solution (same as above): edit dbshut script and change

From : ORACLE_HOME_LISTNER=$1
 To  :  ORACLE_HOME_LISTNER=$ORACLE_HOME 




Note : 
One pre-req for this script to run is set 'Y' in /etc/oratab. This basically tell the script to start all database instance running of this home. while 'N' tells not to start db using dbshut script.

[oracle@Linux03 Desktop]$ grep 'orcl' /etc/oratab
orcl:/u01/app/oracle/product/12.1.0.2/db_1:Y

dbstart: line 275: ORACLE_HOME_LISTNER: command not found


Usage : we can use dbstart script file in $ORACLE_HOME/bin to start database & listener.

[oracle@Linux03 bin]$ ps -ef|grep pmon
oracle   20588 19211  0 10:56 pts/0    00:00:00 grep pmon

[oracle@Linux03 bin]$ dbstart
Processing Database instance "orcl": log file /u01/app/oracle/product/12.1.0.2/db_1/startup.log

[oracle@Linux03 bin]$ ps -ef|grep pmon
oracle   20693     1  0 10:57 ?        00:00:00 ora_pmon_orcl
oracle   21035 19211  0 10:57 pts/0    00:00:00 grep pmon

[oracle@Linux03 bin]$ 



Common error with dbstart script :


Error : /u01/app/oracle/product/12.1.0.2/db_1/bin/dbstart: line 275: ORACLE_HOME_LISTNER: command not found

[oracle@Linux03 bin]$ dbstart

/u01/app/oracle/product/12.1.0.2/db_1/bin/dbstart: line 275: ORACLE_HOME_LISTNER: command not found


Solution : Edit dbstart script and change (~ line 275)

 From : ORACLE_HOME_LISTNER=$1
 To   : ORACLE_HOME_LISTNER=$ORACLE_HOME



Note : 
One pre-req for this script to run is set 'Y' in /etc/oratab. This basically tell the script to start all database instance running of this home. while 'N' tells not to start db using dbshut script.

[oracle@Linux03 Desktop]$ grep 'orcl' /etc/oratab
orcl:/u01/app/oracle/product/12.1.0.2/db_1:Y