Book Image

Oracle 11g Anti-hacker's Cookbook

By : Adrian Neagu
Book Image

Oracle 11g Anti-hacker's Cookbook

By: Adrian Neagu

Overview of this book

For almost all organizations, data security is a matter of prestige and credibility. The Oracle Database is one of the most rich in features and probably the most used Database in a variety of industries where security is essential. To ensure security of data both in transit and on the disk, Oracle has implemented the security technologies to achieve a reliable and solid system. In Oracle 11g Anti-Hacker's Cookbook, you will learn about the most important solutions that can be used for better database security."Oracle 11g Anti-hacker's Cookbook" covers all the important security measures and includes various tips and tricks to protect your Oracle Database."Oracle 11g Anti-hacker's Cookbook" uses real-world scenarios to show you how to secure the Oracle Database server from different perspectives and against different attack scenarios. Almost every chapter has a possible threads section, which describes the major dangers that can be confronted. The initial chapters cover how to defend the operating system, the network, the data and the users. The defense scenarios are linked and designed to prevent these attacks. The later chapters cover Oracle Vault, Oracle VPD, Oracle Labels, and Oracle Audit. Finally, in the Appendices, the book demonstrates how to perform a security assessment against the operating system and the database, and how to use a DAM tool for monitoring.
Table of Contents (16 chapters)
Oracle 11g Anti-hacker's Cookbook
Credits
Foreword
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Closing vulnerable network ports and services


In general, a standard operating system setup will install more services than necessary to run a typical Oracle environment. An additional service means a service that we do not really need to run on an Oracle database server. Keep in mind that if there are fewer services that listen, the more it reduces system vulnerabilities and also we will reduce the attacking surface. Most exploits are built upon the vulnerabilities of these services to penetrate the system. In addition, we may reduce the resource consumption that is induced by these additional services.

In this recipe, we will present some commands to find listening ports and active services, including those controlled by the inetd daemon, followed by an example on how to disable a service.

Getting ready

All steps will be performed on nodeorcl1 as root.

How to do it...

  1. To find out the listening sockets, issue the following command:

    [root@nodeorcl1 ~]# lsof -i -n
    COMMAND    PID  USER   FD   TYPE DEVICE SIZE NODE NAME
    portmap   1887   rpc    3u  IPv4   4472       UDP *:sunrpc 
    portmap   1887   rpc    4u  IPv4   4473       TCP *:sunrpc (LISTEN)
    rpc.statd 1922  root    3u  IPv4   4591       UDP *:pkix-3-ca-ra 
    ……………………………………………………………………………………………………………………
    sshd      2239  root    3u  IPv6   6274       TCP *:ssh (LISTEN)
    sendmail  2280  root    4u  IPv4   6426       TCP 127.0.0.1:smtp (LISTEN)
    [root@nodeorcl1 ~]# 
    
  2. For more concise information about listening ports we can use nmap:

    [root@nodeorcl1 ~]# nmap -sTU nodeorcl1
    
    Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2012-01-11 23:31 EET
    mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns_servers
    Interesting ports on nodeorcl1 (127.0.0.1):
    Not shown: 3158 closed ports
    PORT    STATE         SERVICE
    22/tcp  open          ssh
    25/tcp  open          smtp
    111/tcp open          rpcbind
    ……………………………………………………………………………
    826/udp open|filtered unknown
    829/udp open|filtered unknown
    [root@nodeorcl1 ~]#
    
  3. To list the active services and their corresponding runlevels, issue the following command:

    [root@nodeorcl1 ~]# chkconfig --list | grep on
    acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
    anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
    …………………………………………………………………………………………………
    xinetd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
    yum-updatesd    0:off   1:off   2:on    3:on    4:on    5:on    6:off
    [root@nodeorcl1 ~]#
    
  4. To stop and disable a service, for example iptables6, issue the following command:

    [root@nodeorcl1 ~]# chkconfig ip6tables stop
    [root@nodeorcl1 ~]# chkconfig ip6tables off
    
  5. List the current state for the ip6tables service (now it has the status off for every runlevel):

    [root@nodeorcl1 ~]# chkconfig --list | grep ip6tables
    ip6tables       0:off   1:off   2:off   3:off   4:off   5:off   6:off
    
  6. To list the xinetd controlled services issue the following command:

    [root@nodeorcl1 ~]# chkconfig --list | awk '/xinetd based services/,/""/'
    xinetd based services:
            chargen-dgram:  off
            chargen-stream: off
            cvs:            off
            ……………………………………………………………………………………………
    

    Related configuration files for every service controlled by xinetd are located at /etc/xinetd.d/. Configuration files have the same name as the service controlled.

  7. For example, the content of cvs configuration file, CVS service is disabled. To disable a xinetd service modify the disable parameter to yes:

    [root@nodeorcl1 xinetd.d]# more cvs
    # default: off
    # description: The CVS service can record the history of your source \
    #              files. CVS stores all the versions of a file in a single \
    #              file in a clever way that only stores the differences \
    #              between versions.
    service cvspserver
    {
            disable                 = yes
            port                    = 2401
            socket_type             = stream
            protocol                = tcp
            wait                    = no
            user                    = root
            passenv                 = PATH
            server                  = /usr/bin/cvs
            env                     = HOME=/var/cvs
            server_args             = -f --allow-root=/var/cvs pserver
    #       bind                    = 127.0.0.1
    }
    

How it works...

Almost every service can be configured to start or stop at a particular runlevel. It's good to remember that not every service listens on a port, so it is not representing necessarily the danger of being attacked from outside. Some services can introduce other avoidable problems, such as unnecessary resource consumption or functional bugs.

There's more...

To avoid time-consuming tasks, such as finding and closing unnecessary services, it is recommended to start with a minimal installation. This conservative approach can help to ensure that optional services are installed and turned on only when they have been determined to be absolutely necessary to enable required functionality.