Oracle 10g EE Installation On Ubuntu 10

This is all 32 bit, no 64 bit software will be covered here.

To get Oracle 10g in 2013 requires a support account of course. Only 11g is available now. Basically I needed Oracle 10 because its still quite heavily used in global business circles. My security testing software may run into Oracle 10 (in fact, already has several times).

After some considerable problems with library linking related failures with Oracle 10g and Ubuntu 12 (12.04.2), I decided to just save time by backdating and using more compatible libraries. The install with Ubuntu 10.04.4 Lucid Lynx. The install with this older version (this is only for dev work, trust me i wouldn’t dream of using this in production) went like a dream.


Note that many install guides insist on installing Oracle’s Java or some other JVM. I found that this was not necessary.

Other Libraries

and then libstdc++5 will be required. I found it here eventually…

and then …

dpkg -i libstdc++5_3.3.6-17ubuntu1_i386.deb

This process installs the library in the right place (at least where the installer for Oracle looks).

Users and Groups

sudo group add oinstall
sudo group add dba
sudo group add nobody
sudo user add -m oracle -g oinstall -G dba
sudo passwd oracle

Kernel Parameters

In /etc/sysctl.conf …

kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000

Reload to take effect…

root@vm-ubuntu-11:~# /sbin/sysctl -p

kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000

Change Limits

vi /etc/security/limits.conf

Add the following …

* soft nproc 2047
* hard nproc 16384
* soft nofile 1024
* hard nofile 65536

Change The System In A Suse Kinda Way

(Ubuntu isn’t a supported distro for Oracle DB and some subtle changes are needed)

sudo ln -s /usr/bin/awk /bin/awk
sudo ln -s /usr/bin/rpm /bin/rpm
sudoln -s /lib/ /lib/
sudo ln -s /usr/bin/basename /bin/basename

Oracle Base Directory

I went with more typical Oracle style directories here for some reason, but you can choose what’s best for you, as long as the ownership is set correctly (watch this space)…

sudo mkdir -p /u01/oracle
sudo chown -R oracle:oinstall /u01
sudo chmod -R 770 /u01

Update default profile

vi /etc/profile

Add the following …

export ORACLE_BASE=/u01/oracle
export ORACLE_HOME=/u01/oracle/product/10.2.0/db_1
export ORACLE_SID=orcl10

Convince Oracle that Ubuntu is Redhat

sudo vi /etc/redhat-release

Add this …
“Red Hat Enterprise Linux AS release 3 (Taroon)”

Run The Installer

The zip file from Oracle – you will have unzipped it, it can be anywhere on the system, lets say /opt.
So after unzipping you will see a /opt/database directory.

chown -R oracle:install /opt/database

Then what’s needed? Start up an X environment (su to Oracle and startx), open a Terminal and…


Installer Options

Do not select the “create starter database” here and selection of Enterprise Edition worked for me, with the Installation Type option.

The installer will ask you run 2 scripts as root. Its is wise to follow this advisory.

The install proceeded fast. I only had one error related to the RDBMS compliation (“Error in invoking target ‘all_no_orcl ihsodbc’ of makefile ‘/u01/oracle/product/10.2.0/db_1/rdbms/lib/'”), but this was because I had not installed the libstdc++5

Create a Listener

So what you have now is a database engine but with no database to serve, and no Listener to process client connections to said database.

Again. within the Oracle owned X environment…


and default options will work here, just to get a database working. netca is in $ORACLE_HOME/bin and therefore in the shell $PATH. Easy.

Create A Database

First up you need to find the GID for the oinstall group you created earlier…

cat /etc/group | grep oinstall

In my case it was 1001.

As root (UID=0) hose this into the /proc hugetlb_shm_group thus…

echo "" > /proc/sys/vm/hugetlb_shm_group

Again, as oracle user, do this…


…and again, default options will work in most cases here.

The database name should match the ORACLE_SID environment variable you specified earlier.

Database Service Control

The install script created a oratab file under /etc.
It may look something similar to…

root@ubuntu:~# cat /etc/oratab

The last part of the stanza (the “Y”) implies “yes” please start this SID on system start. This is your choice of course.

dbstart is a shell script under $ORACLE_HOME/bin. One line needs to be changed here in most cases…this is a basic substitution of your $ORACLE_HOME in place of the “/ade/vikrkuma_new/oracle” in the line after the comment “Set this to bring up Oracle Net Listener”: “ORACLE_HOME_LISTNER=/ade/vikrkuma_new/oracle”

# Set this to bring up Oracle Net Listener


if [ ! $ORACLE_HOME_LISTNER ] ; then
echo "ORACLE_HOME_LISTNER is not SET, unable to auto-start Oracle Net Listener"

And that should be sufficient to just get a database up and running.

To shutdown the database, Oracle provides $ORACLE_HOME/bin/dbshut and this won’t require any editing.

“service” Control Under Linux

Personally I like to be able to control the Oracle database service with service binary as in:
service oracle start
service oracle stop

The script here to go under /etc/init.d was the same as my script for Oracle Database 11g…

root@ubuntu:~# cat /etc/init.d/oracle
# Run-level Startup script for the Oracle Instance and Listener
# Provides: Oracle
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Startup/Shutdown Oracle listener and instance



# if the executables do not exist -- display error

if [ ! -f $ORA_HOME/bin/dbstart -o ! -d $ORA_HOME ]
echo "Oracle startup: cannot start"
exit 1

# depending on parameter -- startup, shutdown, restart
# of the instance and listener or usage display

case "$1" in
# Oracle listener and instance startup
echo -n "Starting Oracle: "
su - $ORA_OWNR -c "$ORA_HOME/bin/dbstart $ORA_HOME"
su - $ORA_OWNR -c "$ORA_HOME/bin/lsnrctl start"

#Optional : for Enterprise Manager software only
su - $ORA_OWNR -c "$ORA_HOME/bin/emctl start dbconsole"

touch /var/lock/oracle
echo "OK"
# Oracle listener and instance shutdown
echo -n "Shutdown Oracle: "

#Optional : for Enterprise Manager software only
su - $ORA_OWNR -c "$ORA_HOME/bin/emctl stop dbconsole"

su - $ORA_OWNR -c "$ORA_HOME/bin/lsnrctl stop"
su - $ORA_OWNR -c "$ORA_HOME/bin/dbshut $ORA_HOME"
rm -f /var/lock/oracle
echo "OK"
$0 stop
$0 start
echo "Usage: $0 start|stop|restart|reload"
exit 1
exit 0

Most likely the only change required will be the ORA_HOME setting which obviously is your $ORACLE_HOME.

Quick Test

So after all this, how do we know our database is up and running?
Try a local test…as Oracle user…

sqlplus / as sysdba

This should drop you into the antiquated text based app and look something like…

oracle@ubuntu:~$ sqlplus / as sysdba

SQL*Plus: Release - Production on Fri Jun 21 07:57:43 2013

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

Connected to:
Oracle Database 10g Enterprise Edition Release - Production
With the Partitioning, OLAP and Data Mining options



This post is based to some extent the following two posts:

Some parts of these posts didn’t work for me (I had lots of linking errors), but nonetheless thanks go out to the authors of those blogs.

Scangate Re-visited: Vulnerability Scanners Uncovered

I have covered VA tools before but I feel that one year later, the same misconceptions prevail. The notion that VA tools really can be used to give a decent picture of vulnerability is still heavily embedded, and that notion in itself presents a serious vulnerability for businesses.

A more concise approach at a run down on the functionality of VA warez may be worth a try. At least lets give it one last shot. On second thoughts, no, don’t shoot anything.

Actually forget “positive” or “negative” views on VAs before reading this. I am just going to present the facts based on what I know myself and of course I’m open to logical, objective discussion. I may have missed something.

Why the focus on VA? Well, the tools are still so commonplace and heavily used and I don’t believe that’s in our best interests.

What I discovered many years ago (it was actually 2002 at first) was that discussions around these tools can evoke some quite emotional responses. “Emotional” you quiz? Yes. I mean when you think about it, whole empires have been built using these tools. The tools are so widespread in security and used as the basis of corporate VM programs. VM market revenues runs at around 1 billion USD annually. Songs and poems have been written about VAs – OK I can’t back that up, but careers have been built and whole enterprise level security software suites built using a nasty open source VA engine.

I presented on the subject of automation in VA all those years ago, and put forward a notion that running VA tools doesn’t carry much more value as compared to something like this: nmap -v -sS -sV <targets> . Any Security Analyst worth their weight in spam would see open ports and service banners, and quickly deduce vulnerability from this limited perspective. “Limited”, maybe, but is a typical VA tool in a better position to interrogate a target autotragically?

One pre-qualifier I need to throw out is that the type of scanners I will discuss here are Nessus-like scanners, the modus operandi of which is to use unauthenticated means to scan a target. Nessus itself isn’t the main focus but it’s the tool that’s most well known and widely used. The others do not present any major advantages over Nessus. In fact Nessus is really as good as it gets. There’s a highly limited potential with these tools and Nessus reaches that limit.

Over the course of my infosec career I have had the privilege to be in a position where I have been coerced into using VAs extensively, and spent many long hours investigating false positives. In many cases I set up a dummy Linux target and used a packet sniffer to deduce what the tool was doing. As a summary, the findings were approximately:

  • Out of the 1000s of tests, or “patterns”, configured in the tools, only a few have the potential to result in accurate/useful findings. Some examples of these are SNMP community string tests, and tests for plain text services (e.g. telnet, FTP).
  • The vast majority of the other tests merely grab a service “banner”. For example, the tool port scans, finds an open port 80 TCP, then runs a test to grab a service banner (e.g. Apache 2.2.22, mickey mouse plug-in, bla bla). I was sort of expecting the tool to do some more probing having found a specific service and version, but in most cases it does not.
  • The tool, having found what it thinks is a certain application layer service and version, then correlates its finding with its database of public disclosed vulnerabilities for the detected service.

Even for some of the plan text services, some of the tests which have the potential to reveal useful findings have been botched by the developers. For example, tests for anonymous FTP only work with a very specific flavour of FTP. Other FTP daemons return different messages for successful anonymous logins and the tool does not accommodate this.

Also what happens if a service is moved from its default port? I had some spectacular failures with running Nessus against a FTP service on port 1980 TCP (usually it is listening on port 21). Different timing options were tested. Nessus uses a nmap engine for port scanning, but nmap by itself is usually able to find non-default port services using default settings.

So in summary, what the VA tools do is mostly just report that you are running ridiculous unencrypted blast-from-the-past services or old, down-level services – maybe. Really I would hope security teams wouldn’t need to spend 25K USD on an enterprise solution to tell them this.

False positives is one thing, but false negatives is quite another. Popular magazines always report something like 50% success rate in finding vulnerabilities in staged tests. Why is it always 50%? Remember also that the product under testing is usually one from a vendor who pays for a full spread ad in that magazine.

Putting numbers to false negatives makes little sense with huge, complex software packages of millions of lines of source code. However, it occurred to me not so long ago whilst doing some white box testing on a client’s critical infrastructure: how many of the vulnerabilities under testing could possibly be discovered by use of a VA tool? In the case of Oracle Database the answer was less than 5%. And when we’re talking Oracle, we’re usually talking critical, as in crown jewels critical.

If nothing else, the main aspect I would hope the reader would take out of this discussion is about expectation. The expectation that is set by marketing people with VA tools is that the tools really can be used to accurately detect a wide range of vulnerability, and you can bet your business on the tools by using them to test critical infrastructure. Ladies and gentlemen: please don’t be deceived by this!

Can you safely replace manual testing with use of these tools? Yes, but only if the target has zero value to the business.