|
|
| Line 1: |
Line 1: |
| − | ==Background ==
| + | http://www.oracle.com/technology/pub/articles/project_lockdown/phase1.html#1.3 |
| − | Take a look at the other executables in the $ORACLE_HOME/bin directory; some may look familiar, such as sqlplus or lsnrctl (the utility to start Listener); others may not.
| |
| − | | |
| − | Some of these files—such as tnslsnr, the utility that the Listener process runs, or dbsnmp, which was used in Oracle Intelligent Agent—are not directly touched by the end user. To properly secure them, you must understand what they do and take appropriate action.
| |
| − | | |
| − | Recall that if the SUID bit is set for a file, then regardless of who runs the file it runs under the privileges of the owner, not the executor. You also learned that setting the SUID can be dangerous and should be discouraged.
| |
| − | | |
| − | There are several other files that have the SUID set to on. Let's find them.
| |
| − | | |
| − | $ cd $ORACLE_HOME
| |
| − | $ find . -type f \( -perm -2000 -o -perm -4000 \) -exec ls -l {} \;
| |
| − | | |
| − | In Oracle Database10g Release 1 and later, the above should return only the following executables:
| |
| − | | |
| − | -rwsr-s--x 1 orasoft dba 93300507 Jul 22 11:20 ./bin/oracleO
| |
| − | -r-sr-s--- 1 root dba 0 Jul 1 23:15 ./bin/oradism
| |
| − | -rwsr-s--x 1 orasoft dba 94492 Jul 22 11:22 ./bin/emtgtctl2
| |
| − | -rwsr-s--- 1 root dba 18944 Jul 22 11:22 ./bin/nmb
| |
| − | -rwsr-s--- 1 root dba 20110 Jul 22 11:22 ./bin/nmo
| |
| − | -r-sr-sr-x 1 nobody nobody 58302 Jul 22 11:23 ./bin/extjob
| |
| − | | |
| − | Let's see what these files are:
| |
| − | | |
| − | Program
| |
| − | Description
| |
| − |
| |
| − | ./bin/oracleO This file is a copy of the executable "oracle". When you recompile the oracle executable using the relink command, the old copy is saved as oracle0. This is a potential security hazard; most DBAs ignore it and it can be an avenue for hackers. Therefore you should take action to remove the permissions. The best option is to have no permissions for it: | |
| − | | |
| − | $ chmod 0000 oracleO
| |
| − | | |
| − | Now, if you see the permissions:
| |
| − | | |
| − | $ ls -l oracleO
| |
| − | ---------- 1 orasoft oinstall 248823320 Sep 15 13:27 oracleO
| |
| − |
| |
| − | ./bin/oradism Used for Dynamic Intimate Shared Memory. May be in use on your platform. May not be present in all cases. If present, leave as is.
| |
| − |
| |
| − | ./bin/emtgtctl2 Used for Enterprise Manager Agent. There is no need for it to be set with SUID. The justification is same as the "oracle" executable. Remove the permissions. | |
| − | | |
| − | $ chmod 0700 emtgtctl2
| |
| − |
| |
| − | ./bin/nmb Used for Oracle 10g Grid Control agent to collect statistics on the target server. Leave it as is.
| |
| − |
| |
| − | ./bin/nmo Used for Oracle 10g Grid Control agent to collect statistics on the target server. Leave it as is.
| |
| − |
| |
| − | ./bin/extjob This is the executable for the EXTJOB (External Jobs, which allow you to execute OS-based programs from within Enterprise Manager). This is something you should be careful about. Do you use external jobs a lot? If not, then you should not even have this executable. In such a case, you can leave it in the directory but change the permissions and the ownership. The owner can be the Oracle software owner (orasoft, in our case) and the permissions should be rwx------.
| |
| − | | |
| − | $ chown orasoft:oinstall extjob
| |
| − | $ chmod 0700 extjob
| |
| − | | |
| − | There may be another program present, extjobO, which was a previous compilation of the same program. Change the permissions of that too.
| |
| − | | |
| − | $ chown orasoft:oinstall extjobO
| |
| − | $ chmod 0000 extjobO
| |
| − |
| |
| − | | |
| − | In Oracle9i Database Release 2, you will find a different file, ./bin/dbsnmp, which is the Oracle Intelligent Agent executable file. The permissions are set as such:
| |
| − | | |
| − | -rwsr-s--- 1 root dba 2986836 Jan 26 2005 dbsnmp
| |
| − | The problem with this file is that it needs root privileges to work properly, hence the SUID bit must be set to on. However, as this file is owned by root, hackers typically exploit it to gain access as root. The best advice is to eliminate it, or make it owned by the Oracle software owner and setting the permissions to 700. You will lose some functionality, but it's worth it to eliminate the risk.
| |
| − | | |
| − | The other executable to consider is tnslsnr, which is the Oracle Net Listener. There are two executables:
| |
| − | | |
| − | tnslsnr - the actual listener executable
| |
| − | lsnrctl - the utility that is used to manage the listener, such as starting, stopping, etc.
| |
| − | | |
| − | If you look at the permissions:
| |
| − | | |
| − | $ ls -l *lsnr*
| |
| − | -rwxr-x--x 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl
| |
| − | -rwxr-xr-x 1 orasoft oinstall 214720 Oct 1 18:50 lsnrctl0
| |
| − | -rwxr-x--x 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr
| |
| − | -rwxr-xr-x 1 orasoft oinstall 1118816 Oct 1 18:50 tnslsnr0
| |
| − | | |
| − | The files have execute privileges for all. Like the executable oracleO, when a new file tnslsnr is created by relinking the Oracle software, the existing file tnslsnr is renamed to tnslsnr0. This is done because if the process needs to be rolled back, the old executable can be copied over the new one. Because it's the copy of the old exdcutable, the file tnslsnr0 may contain the same functionality as the original tnslsnr. The same goes for lsnrctl0.
| |
| − | | |
| − | ==Strategy==
| |
| − | Now that you understand the purpose of each executable, let's see how you can secure your database infrastructure. Most of the strategy has been discussed in the above section on background information. So, in essence, your strategic moves are:
| |
| − | | |
| − | Remove all permissions from the files that are not needed—e.g., lsnrctl0.
| |
| − | Restrict permissions for executables to Oracle software only.
| |
| − | Remove the SUID bit on if the Oracle software owner starts the processes.
| |
| − | So, you want to change the permissions of the Listener-related files as follows:
| |
| − | | |
| − | $ chmod 700 lsnrctl tnslsnr
| |
| − | $ chmod 000 lsnrctl0
| |
| − | | |
| − | Verify the result.
| |
| − | | |
| − | $ ls -l *lsnr*
| |
| − | -rwx------ 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl
| |
| − | ---------- 1 orasoft oinstall 214720 Oct 1 18:50 lsnrctl0
| |
| − | -rwx------ 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr
| |
| − | ---------- 1 orasoft oinstall 1118816 Oct 1 18:50 tnslsnr0
| |
| − | | |
| − | ==Implications==
| |
| − | There are a few implications in this case:
| |
| − | | |
| − | Changing the oracleO executable has no impact on the operation of the database. If you ever face an issue that points to a corrupt "oracle" executable, your best bet is to rename the "oracleO" file to "oracle". If you do so, make sure you reset to permissions to 700. The same goes for lsnrctl0 and tnslsnrctl0 files.
| |
| − | Changing the emtgtctl2 permissions will have no impact if you use the Oracle software owner userid as the Enterprise Manager operating system credentials. If you use a different userid (not orasoft, for example), the SUID must be reset to the old value and the permissions must be set as they were.
| |
| − | The executable dbnsmp is used by Oracle Enterprise Manager Intelligent Agent, but only up until Oracle9i Database Release 2. Again, if you use the Oracle software owner as the operating system credentials, there is no impact from changing the permissions. If you use a different userid, you must reset the permissions to the previous value.
| |
| − | Action Plan
| |
| − | Change permissions of oracleO, tnslsnr0, and lsnrctl0 to 0000.
| |
| − | Change permissions for tnslsnr and lsnrctl to 0700.
| |
| − | Do you use external jobs in Enterprise Manager? IF no THEN change the permissions of extjob to 0000
| |
| − | ELSE
| |
| − | Change the permissions of extjob to 0700 and change the owner and group to orasoft and oinstall (or whatever the user and group of the Oracle software owner are).
| |
| − | END IF
| |
| − | | |
| − | IF you are on Oracle9i Database THEN
| |
| − | Are you using Oracle Intelligent Agent?
| |
| − | IF no THEN
| |
| − | Change ownership of dbsnmp to orasoft
| |
| − | Change permissions to 0700
| |
| − | ELSE
| |
| − | No change needed
| |
| − | END IF
| |
