Chapter 1. Operating System Security
In this chapter we will cover the following topics:
Using Tripwire for file integrity checking
Using immutable files to prevent modifications
Closing vulnerable network ports and services
Using network security kernel tunables to protect your system
Using TCP wrappers to allow and deny remote connections
Enforcing the use of strong passwords and restricting the use of previous passwords
Restricting direct login and su access
Securing SSH login
The number of security threats related to operating systems and databases are increasing every day, and this trend is expected to continue. Therefore, effective countermeasures to reduce or eliminate these threats must be found and applied. The database administrators and system administrators should strive to maintain a secure and stable environment for the systems they support. The need for securing and ensuring that the database servers are operational is crucial, especially in cases in which we are working with mission critical systems that require uninterrupted access to data stored in Oracle Databases.
In this chapter, we will focus on some operating system security measures to be taken to have a reliable, stable, and secure system. Obviously operating system security is a vast domain and to cover this subject in a few pages is not possible. However, we can briefly describe several key items that can provide a starting point to address some of the concerns we will highlight in our recipes.
Briefly, the possible operating security threats are:
Denial of service
Exploits and vulnerabilities
Backdoors, viruses, and worms
Operating system bugs
Recommendations and guidelines:
Develop a patching policy.
Perform security assessments regularly.
Try to use hard-to-guess passwords.
Disable direct root login and create a special login user. It would be also easier to perform auditing.
Limit the number of users.
Limit the number of users who can issue the su command to become the root or oracle owner user.
Limit the number of services started, use only the necessary ones.
Limit the number of open ports.
Refrain from using symbolic links whenever possible.
Do not give more permissions to users than is necessary.
Secure ssh.
Use firewalls.
In these series of recipes for the server environment, we will use the operating system Red Hat Enterprise Linux Server release 6.0 (Santiago) 64-bit version. For the client environment we will use the Fedora 11 update 11 64-bit version. The server hostname will be nodeorcl1 and the client hostname will be nodeorcl5. All machines used are virtual machines, created with Oracle Virtual Box 4.1.12.
As a preliminary task before we start, prepare the server environment in terms of kernel parameters, directories, users, groups, and software installation as instructed in Oracle® Database Installation Guide 11g Release 2 (11.2) for Linux (http://docs.oracle.com/cd/E11882_01/install.112/e24321/toc.htm). Download and install Oracle Enterprise Edition 11.2.0.3, create a database called HACKDB, configured with
Enterprise Manager and
Sample Schemas, and define a listener called LISTENER with a default port of 1521.
Due to the limited page constraints, we will omit the description of each command and their main differences on other Linux distributions or Unix variants. The most important thing to understand is the main concept behind every security measure.
Using Tripwire for file integrity checking
Appropriate file and filesystem permissions are essential in order to ensure the integrity of the files that physically
comprise the database and the Oracle software. We must make sure that we do not grant permissions to other users to write or read data belonging to physical database and configuration files, such as listener.ora or sqlnet.ora outside of the oracle owner user. When Automatic Storage Management
(ASM) is used as a storage medium, we also need to ensure that we have the appropriate permissions defined at the exposed raw disks level. Even if these files are not normally seen with OS commands, disks can be compromised by using the dd command. Another problem may be related to the script or program execution, as power users and attackers may have group-level permissions that would allow them to unexpectedly or intentionally endanger the integrity of the database files.
The alteration of files and directories considered critical in terms of content and permissions could be the first sign of attack or system penetration. In this category we can also add suspect files with SUID and GUID enabled (most rootkits have files with SUID and GUID permissions), world writeable, readable and executable files, and unowned files. One option is to use custom scripts for change detection. In my opinion this is error prone and requires serious development effort. A better option is to use specialized intrusion detection tools that have built-in integrity checking algorithms and real-time alerting capabilities (SNMP traps, e-mail, and sms).
Tripwire is an intrusion detection system
(IDS), which is able to take time-based snapshots and compare them in order to check different types of modifications performed on monitored files and directories.
In the following recipe we will use the open source variant of the Tripwire intrusion detection system and demonstrate some of its key capabilities.
All steps will be performed as root user on nodeorcl1.
As a prerequisite, download the latest version source code of the Tripwire extract and copy it to a directory that will be used for compiling and linking the source code.
Enter in the directory where you have extracted the Tripwire source code, configure and build Tripwire binaries and libraries as follows:
During make install phase
we will be asked to accept the license agreement and a series of passphrases for generating the site and local key:
After the installation is complete,
initialize Tripwire. At this step, the policy and configuration files will be encrypted and applied. Based on policies and configuration, an initial baseline check will be performed and a database containing the characteristics of monitored files will be built:
After Tripwire will finalize the initialization, we will be able to add our own policies. On Red Hat, by default, the initial policy file, twpol.txt, and configuration file, twcfg.txt, will be located in the /local/usr/etc/tripwire/ directory. For security reasons these files must be deleted. To generate a text-based policy file from the existent policy configuration execute the following command:
Open and edit the /local/usr/etc/tripwire/twpolicy.txt file. In the global section after HOSTNAME=/nodeorcl1 add the ORACLE_HOME variable as follows:
Add two new rules related to the Oracle software binaries and libraries (all files from $ORACLE_HOME/bin and $ORACLE_HOME/lib) and network configuration files (all files from $ORACLE_HOME/network/admin). The files from these directories are mostly static; all modifications performed here are usually performed by database administrators (patching, enabling, or disabling an option, such as OVA, OLS, and network settings). In this case the ReadOnly mask summary is appropriate. Add a rule for the directory that contains the Oracle Database files (/u02/HACKDB). These files change frequently, and the $Dynamic summary mask should be appropriate here. Add the following three sections at the end of the twpolicy.txt file:
Perform some modifications in listener.ora and sqlnet.ora. Also, we have decided to not use
external procedures and external job execution in the future. Therefore as a primary security measure we will move (normally in a production environment you should delete them) these files from $ORACLE_HOME/bin directory to /extprocjob directory:
Next, as root update the Tripwire database using the new updated policy file as follows:
Again, to simulate an intrusion, perform some modifications on listener.ora and sqlnet.ora, change permissions on /u02/HACKDB/users01.dbf to world readeable, and move extjob and extproc back to $ORACLE_HOME/bin. Create a file named ha_script in /home/oracle with the SUID and GUID bit set and a file with
world writeable permissions called ha_wwfile:
Next as root, perform an interactive type check to find out the modifications performed on monitored directories and files. The expected values are recorded in the Expected column. All modifications are recorded in the Observed column as follows:
Also you will find information, visible in the Observed column, about the two files added in /home/oracle:
Note
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.
The most appropriate moment to install and perform an initial check for creating a baseline is right after operating system installation. Starting with a clean baseline we will be able to monitor and catch any suspect change performed on files over time. The monitoring performed by Tripwire is based on a policy and compliance model. There are a multitude of parameters or property masks that can be applied on monitored files, based on permission change, checksum, object owner, modification timestamp, and more. A property mask tells Tripwire what change about a file is being monitored. A summary property mask is a collection of property masks. The description of property masks and summary masks can be found in the policy file header.
Other administrative options
Print Tripwire configuration file:
To create or recreate the local and site keys, execute the following:
To print information about a database entry related to a file or object:
To print a generated report:
To add an e-mail address within a rule for change alert:
Using immutable files to prevent modifications
It is a very powerful method to set files as not modifiable even by the root user. Usually configuration files, binaries, and libraries, which are static in nature, are good candidates to set as immutable.
All steps will be performed on nodeorcl1 as root.
Before you change the file attribute to immutable, be absolutely sure that these files are static and may not cause outages.
For example, to prevent any modification to the Oracle listener configuration file listener.ora, modify it as immutable by executing the following command:
Now the file cannot be modified even by the root user:
At this step, we will set a library as immutable. For example, to protect against disabling the
Oracle Database Vault option, turn $ORACLE_HOME/rdbms/lib/libknlopt.a immutable:
If we try to disable the Oracle Database Vault option, we will receive an Operation not permitted message:
To check if a file is immutable we can use the lattr command:
To disable the immutable flag from listener.ora, execute the following command:
The
lsattr command can be used to check if the immutable flag is on or off:
The immutable flag can be set with the chattr command using the +i switch. To disable the immutable flag use –i. The –V switch translates to verbose mode. More about the chattr command can be found in the man pages.
In this section we will see how we can use lcap to prevent the root user from changing the immutable attribute. The kernel capabilities modified with lcap will stay disabled until the system is rebooted.
The lcap utility can disable some specific kernel capabilities.
Download and install lcap:
Disable the possibility to disable or enable immutability for files:
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.
All steps will be performed on nodeorcl1 as root.
To find out the listening sockets, issue the following command:
For more concise information about listening ports we can use nmap:
To list the active services and their corresponding runlevels, issue the following command:
To stop and disable a service, for example iptables6, issue the following command:
List the current state for the ip6tables service (now it has the status off for every runlevel):
To list the xinetd controlled services issue the following command:
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.
For example, the content of cvs configuration file, CVS service is disabled. To disable a xinetd service modify the disable parameter to yes:
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.
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.
Using network security kernel tunables to protect your system
If you are not using an advanced firewall to protect your system, it is possible to protect it against TCP and UDP protocol-level attacks by setting a list of kernel parameters, or tunables. Most operating systems allow this type of setting for protection against flood attacks, spoof, and ICMP-type attacks.
In this recipe we will enable network protection using kernel tunables. All steps will be performed as root on nodeorcl1.
All tunables must be added to /etc/sysctl.conf to be persistent across system reboots.
To enable them immediately execute the following command:
All security kernel tunables require restarting the network service to take effect:
The following is the list and description of tunables:
Enable TCP SYN cookie protection: A SYN attack
or SYN flood
is a form of denial of service attack in which an attacker sends a succession of SYN requests. The main scope of this type of attack is to consume all the resources from a machine and to make it irresponsive to subsequent network traffic by filling up the SYN queue
. SYN cookies
allow a server to avoid dropping connections when the SYN queue fills up. One well known tool with SYN flood capabilities available on Linux is hping, but there are several other free tools that can generate this kind of attack. These days almost all major Linux distributions have this tunable set to 1. To enable TCP SYN cookie protection or SYN flood protection, add the following network tunable to /etc/sysctl.conf:
More details about TCP SYN cookie attacks can be found at the following link: http://etherealmind.com/tcp-syn-cookies-ddos-defence/
Disable IP source routing: Source routing is a technique whereby an attacker can specify a route through the network from source to destination. This will force the destination host to use the same route as the source packets. To disable IP source routing add the following tunable to /etc/sysctl.conf:
Disable ICMP redirect acceptance: ICMP protocol is used by routers to redirect a source host to an alternative better path to other networks. An intruder could potentially redirect the traffic by altering the host's routing table and changing the traffic route. To disable ICMP and redirect acceptance, add the following tunable to /etc/sysctl.conf:
Enable IP spoofing protection: IP spoofing is a technique where an intruder conceals his identity by sending out packets that claim to be from another host. The manipulation of packets is made by forging the IP header's address making them appear as though they are sent from a different address. To enable IP spoofing protection add the following tunable:
Ignore ping requests: If you want or need Linux to ignore ping requests, to enable ignoring of ICMP requests, add the following tunable:
To enable logging for spoofed packets, source routed packets, and redirect packets, add the following tunable to /etc/sysctl.conf:
Enable bad error message protection: Bad error messages are usually used in DoS type attacks and are indented to fill up the the filesystems on the disk with useless log messages. To enable bad message protection add the following tunable to /etc/sysctl.conf:
The protection is activated at kernel level and it is very effective. There are slight differences between Linux distributions but you should find the same parameters that address network protection at kernel level.
Usually these modifications should be tested first. Placing your server behind a properly configured firewall is typically the preferred way to enable these types of protections. However, a database administrator tasked with protecting sensitive data may want to consider kernel-level tunables as a technique that may provide an additional level of protection, or that adds a defensive layer in case of a firewall configuration issue.
Using TCP wrappers to allow and deny remote connections
By using TCP wrappers you can control the accepting or denying of incoming connections from
specified servers and networks. You may use this capability to protect your network in conjunction with a firewall. In the following recipe, we will allow connections opened through ssh only from the nodeorcl5 host and deny from all others by using TCP wrappers.
All steps will be performed on nodeorcl1 as root.
TCP wrappers at host level are
controlled by two files located in the /etc directory called hosts.allow and hosts.deny.
First we will start to deny all incoming connections from all hosts using all services by adding the following line into /etc/hosts.deny:
In this moment if we try to establish a connection from nodeorcl5 it will be denied:
To allow incoming connections
only with ssh include the following in /etc/hosts.allow:
All changes to hosts.deny and hosts.allow takes immediately in effect; hosts.allow has precedence over the hosts.deny file.
The format for rules is composed by a service or daemon, and host name or IP address. In our examples, we denied all services from all hosts and allowed only ssh connections from nodeorcl5.
You can set rules for an entire network as follows:
Enforcing the use of strong passwords and restricting the use of previous passwords
It is essential to establish an effective security policy for Oracle software owner users. In this recipe we will talk about managing complex password rules that can primarily prevent brute force attacks. Restriction of using previous passwords and too similar passwords is an additional security measure which can be implemented to prevent undesired access into the system.
Password rule checking and restriction of the use of previous passwords is performed by Pluggable Authentication Module,
or simply known as PAM, discussed in this recipe. In these days PAM is available and used on all major Linux and Unix distributions. The differences in implementation on these platforms are minimal.
All steps will be performed on the database server host nodeorcl1.
As the user root open /etc/pam.d/system-auth for editing. Modify the line that begins with password requisite pam_cracklib.so, with the following line:
Save and close the file. At this step you can try to set some weak passwords, such as dictionary-based or very short passwords to verify that the defined rules are enforced.
If the password enforcement rules are working, login as the oracle user and change the password to a strong password, such as of24UT()next(1)=2:
At this step we will set up the restriction for using previous passwords. First create /etc/security/opasswd file and set its permission to 600. This file will retain the used password history for comparisons:
Open the /etc/pam.d/system-auth file and modify the line added in step 4 by appending the difok parameter and remember parameter at the end of the line beginning with password sufficient pam_unix.so as follows:
Login as oracle and change the password. Try to set the password as the same password used before. The PAM module will detect that the password is unchanged as we can see from the following listing:
Next, type a password with only two characters, difference. We will get a message that will tell us that the password is too similar to the old one:
Note
It is highly recommended to perform security assessments regularly on your system. To check your real password's strength you should try to use a password cracker.
For a list and description of some of the best available password crackers consult http://nrupentheking.blogspot.com/2011/02/best-password-crackers-in-hackers.html.
Some recommendations for generating strong passwords:
-
Strong passwords should contain lowercase, uppercase, special characters (such as@,&,},?, and !), high ASCII code characters (such as
and ♫), or unicode characters (such as ﭏ, and ﭚ).
Divide your password in to more than 2 or 3 groups and use special characters, high ASCII codes, or Unicode characters as delimiters for groups (for example: u6Yi5@My1k!P;m8U where @,!, and ; are delimiters).
Use more than 8 characters; 15-20 is a good number to prevent brute-force attacks. A brute force cracker program will need exponentially more time to break a password directly proportional with the password length.
Do not use more that 40 percent numbers in your password.
Avoid dictionary words.
The Linux PAM module pam_cracklib.so checks the password against dictionary words and other constraints using minlen, lcredi, ucredi, dcredit, and ocredit parameters, which are defined as follows:
minlen: Minimum length of password. In our case must be 12.
lcredit: Minimum number of lower case letters. In our case must be 2.
ucredit: Minimum number of upper case letters. In our case must be 2.
dcredit: Minimum number of digits. In our case must be 1.
ocredit: Minimum number of other characters. In our case must be 1.
To restrict the use of a previous password, the system must save the used passwords to use them for comparison. The file used for storing previous passwords is called opasswd. In case it does not exist, it must be created in the /etc/security directory. The restrict enforcement is performed in stacking mode by combining the remember parameter of the pam_unix.so module with the
difok parameter of the pam_cracklib.so module. The remember parameter will configure the number of previous passwords that cannot be reused, and difok is used to specify the number of characters that must be different between the old and the new password.
PAM configuration files on Red Hat Linux and variants are located in /etc/pam.d directory. The service shares the same name as the application designed to authenticate; for example the PAM configuration file for the su command is contained in a file with the same name (/etc/pam.d/su).
Next, we will take a look at the PAM configuration file format. To understand this we will use the line corresponding to the password module modified in this recipe:
The first directive is the module type. A brief summary of module types and how PAM enforces the rules is as follows:
The second directive from the PAM configuration files is represented by control flags. These flags tell what to do with the result returned by a module. All PAM modules return a success or failure result when called.
The third directive is the pluggable module. The next parameters represent the arguments passed to the pluggable module.
You can bypass PAM rules for password enforcement as root; hence the passwords to comply with the enforcement rules must be changed by each user.
Performing a security assessment on current passwords with the John the Ripper password cracker tool
Download and build John the Ripper
from source code as follows:
Unshadow /etc/password and /etc/shadow into a separate file, /tmp/passwd.db:
Add the file as an argument and perform a simple password cracking session:
The weak passwords are found instantaneously:
Restricting direct login and su access
On critical systems it is usually considered a bad practice to allow direct remote logins to system users, such as root or other application owners, and shared users, such as oracle. As a method for better control and from the user audit point of view, it is recommended to create different login users that will be allowed to connect and perform switches (su) to users considered critical. No other users should be exposed to the external world to allow direct, remote, or local connections.
In this recipe, we will create a group log and a user named loguser1, and we will disable direct logins for all others.
All steps will be performed on nodeorcl1.
Create a designated group for users allowed to log in:
Create an user and assign it to logingrp group as follows:
To disable direct login for all users add the following line to /etc/pam.d/system-auth:
Uncomment and modify the following line from /etc/security/access.conf:
All logins excepting users from the logingrp group will be denied. If we try to connect from nodeorcl5 the connection will be closed:
The connection succeeds as loginuser1:
To disable the su capabilities for all users exempting loginuser1, open /etc/pam.d/su and uncomment the following line as instructed in the file:
At this moment all users that don't belong to the wheel group are not allowed to switch to an other user. Add loginuser1 to the wheel group as follows. In this way the only user that may execute su command will be loginuser1:
If you try to execute an su command with the oracle user, you will get incorrect password message, and the switch cannot be performed:
But as user loguser1 it succeeds:
The PAM module that performs the login check is pam_access.so, with the control flag set to required and the module type account. The control of su command is performed by the pam_wheel.so module.
At this moment all users who do not belong to the group logusers are not allowed to log in locally or remotely. The only exemption is root login using ssh. We will see how to deny remote root logins with ssh in the following recipe, Securing SSH login.
These days ssh login can be considered the de facto method for connecting to remote servers. It is reliable and secure but if it is configured improperly, it can be more of a liability than an asset. In this recipe will change a couple of parameters to secure ssh and we will set up passwordless connections using public keys.
All the steps from this recipe will be performed on nodeorcl1 as the root user. The remote logins will be performed from nodeorcl5.
All parameters that will be modified are located in the /etc/sshd_config configuration file.
Change the default port 22. Most port scanners will identify automatically port 22 with the ssh service. Therefore it will be a good idea to change the default ssh port:
Disable root logins:
ssh will check for proper permissions in the user's home. Use strict mode:
Suppress all host-based authentications. Usually these methods should be avoided as primary authentication:
This parameter is very effective against DoS type attacks. Limit the maximum number of unauthenticated connections and connection attempts:
Allow just users that belong to a defined group to log in:
To make the changes effective, restart the sshd service:
After restart, the sshd daemon will listen on port 13120:
Try to connect from nodeorcl5 to nodeorcl1 as root. Direct root log ins will be denied:
After any change of configuration parameters, a daemon restart is needed. You can perform the restart in different ways, such as restarting the service or by sending a HUP (kill -1) signal to the sshd daemon process.
Using key authentication instead of using passwords is probably one of the securest methods of authentication. This will suppress definitively any brute force attempt using passwords.
Setting up public key authentication
Open the /etc/ssh/sshd_config file and disable password authentication by modifying the following parameter:
Enable key authentication:
On the client machine nodeorcl5 as the user loginuser1, create a passphase protected public/private key:
Now deploy the key on nodeorcl1 as follows:
Log in to nodeorcl1; you must type the passphrase entered during key creation:
Restart the sshd service as follows:
Argentina
Australia
Austria
Belgium
Brazil
Bulgaria
Canada
Chile
Colombia
Cyprus
Czechia
Denmark
Ecuador
Egypt
Estonia
Finland
France
Germany
Great Britain
Greece
Hungary
India
Indonesia
Ireland
Italy
Japan
Latvia
Lithuania
Luxembourg
Malaysia
Malta
Mexico
Netherlands
New Zealand
Norway
Philippines
Poland
Portugal
Romania
Russia
Singapore
Slovakia
Slovenia
South Africa
South Korea
Spain
Sweden
Switzerland
Taiwan
Thailand
Turkey
Ukraine
United States
Filter
