All posts by Steven A

Solution

How to create Oracle ASM disks using disk or multipath devices in Red Hat Enterprise Linux?

Leave a comment
  • Please use the following steps to create Oracle ASM disks with either disks or dm-multipath:
    1. Identify Device(s): determine self-identifier for the disk or multipath device using an environmental (E:) variable from udevadm command output.
    2. Create Rule(s): Create a udev rule file /etc/udev/rules.d/96-storage-asm.rules and add a udev rule for each disk or multipath device.
    3. Apply Rule(s): Reload the udev service for the above changes to take effect and create the ASM disks.
  • It is highly recommended to also review the following Best Practices guide which covers udev rules in greater detail, as well as various other important settings recommend for running Oracle
  • Identify Device(s): determine self-identifier for the disk or multipath device using an environmental (E:) variable from udevadm command output. The identifier is required to be used for creating Oracle ASM devices.
    • A “self-identifier” is an identifier value provided directly by the disk or created multipath device that uniquely identifies the device independent of any device name assigned by the host. That is, while assigned sdX and mpathN names may change across boots, the identifier provided by the device will not change. Typically this identifier is based upon the disk’s World Wide IDentifer (WWID).
    • The command below will need to be repeated for each disk and/or multipath device that is to be used with Oracle ASM. Please note down the E: environmental value retrieved for each device. This value will be used in creating the ASM disk udev rule.
    • For disks, use ID_WWN (identifier, world wide name) — or if that is not available then ID_SERIAL, the disks serial number. Replace sdXbelow with the scsi disk name to be used as ASM disk
$ udevadm info --query=all --name=/dev/sdX |  egrep "WWN|SERIAL"
E: ID_SERIAL=ST6000NM0004-1FFFFF_ZZZZAAAA
E: ID_SERIAL_SHORT=Z4D0HDFG
E: ID_WWN=0x5000c50000000000                              <<== Use this id
E: ID_WWN_WITH_EXTENSION=0x5000c50000000000

For dm-multipath devices, use DM_UUID (dm device Universally Unique IDentifier). 
This identifier is nominally based up the underlying device's WWID or serial number. 
Replace mpathX below with the dm-multipath name to be used as ASM disk.

$ udevadm info --query=all --name=/dev/mapper/mpathX |  grep -i "DM_UUID"
E: DM_UUID=mpath-36001405a02467a627a24e62afa3d506c         <<== Use this id

$ udevadm info --query=all --name=/dev/sdX | grep -i "ID_WWN"
E: ID_WWN=0x6001405a02467a62
E: ID_WWN_VENDOR_EXTENSION=0x7a24e62afa3d506c
E: ID_WWN_WITH_EXTENSION=0x6001405a02467a627a24e62afa3d506c
# sg_inq -p 0x83 /dev/sdX
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 20
    designator_type: NAA,  code_set: Binary
    associated with the addressed logical unit
      NAA 6, IEEE Company_id: 0x1405
      Vendor Specific Identifier: 0xa02467a62
      Vendor Specific Identifier Extension: 0x7a24e62afa3d506c
      [0x6001405a02467a627a24e62afa3d506c]
  • NOTE: The DM_UUID above is derived from the underlying device’s WWN as shown. Within the above, sdX is one of the paths of the mpathX device. The ID_WWN_WITH_EXTENSION is the full NAA WWID of the disks under the multipath device.
  • NOTE: Using the environmental variables of udev is much more efficient than using Program= within udev rules. Therefore using the E:variables already available for a device is the recommended practice when creating udev rules.

 

Create Rule(s): Create a udev rule file /etc/udev/rules.d/96-storage-asm.rules and add a udev rule for each disk or multipath device.

  • For disks, add the following rule within the above file: 
    ACTION=="add|change", ENV{ID_WWN}=="{id-wwn-from-udevadm}", SYMLINK+="oracleasm/{asm-disk-name}", GROUP="dba", OWNER="oracle", MODE="0660"

for example, using the information from step 1 to create ASM disk named asm01:

ACTION=="add|change", ENV{ID_WWN}=="0x5000c50000000000", SYMLINK+="oracleasm/asm01", GROUP="dba", OWNER="oracle", MODE="0660" For dm-multipath devices, add the following rule within the above file:
    ACTION=="add|change", ENV{DM_UUID}=="{dm-uuid-from-udevadm}", SYMLINK+="oracleasm/{asm-disk-name}", GROUP="dba", OWNER="oracle", MODE="0660

for example, using the information from step 1 to create ASM disk named asm01:

ACTION=="add|change", ENV{DM_UUID}=="mpath-36001405a02467a627a24e62afa3d506c", SYMLINK+="oracleasm/asm01", GROUP="dba", OWNER="oracle", MODE="0660"
    • Similarly, a udev rule for each device would need to be added into the /etc/udev/rules.d/96-storage-asm.rulesfile.
    • Modify the Group, Owner, and MODE values as needed for matching your environment.

     

Apply Rule(s): As root, reload the udev service for the above changes to take effect and create the ASM disks. See "How to reload "udev rules" without restarting udev service? " for more complete steps.


# udevadm control --reload-rules
# udevadm trigger --type=devices --action=change
 
Home

Shebang Site

Leave a comment

The Shebang (#!)

 

The Shebang (#!)

#!/bin/bash

This is the first line of the script above. The hash exclamation mark ( #! ) character sequence is referred to as the Shebang. Following it is the path to the interpreter (or program) that should be used to run (or interpret) the rest of the lines in the text file. (For Bash scripts it will be the path to Bash, but there are many other types of scripts and they each have their own interpreter.)

Formatting is important here. The shebang must be on the very first line of the file (line 2 won’t do, even if the first line is blank). There must also be no spaces before the # or between the ! and the path to the interpreter.

Whilst you could use a relative path for the interpreter, most of the time you are going to want to use an absolute path. You will probably be running the script from a variety of locations so absolute is the safest (and often shorter than a relative path too in this particular case).

It is possible to leave out the line with the shebang and still run the script but it is unwise. If you are at a terminal and running the Bash shell and you execute a script without a shebang then Bash will assume it is a Bash script. So this will only work assuming the user running the script is running it in a Bash shell and there are a variety of reasons why this may not be the case, which is dangerous.

You can also run Bash, passing the script as an argument.

Solution, Uncategorized

RHEL mount hangs: nfs: server […] not responding, still trying

Leave a comment

Environment

  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 5
  • NFS Client (nfs-utils package)

    Issue

    • NFS shares hang with the following error(s) in /var/log/messages: 
      kernel: nfs: server <NFSservername> not responding, still trying
      kernel: nfs: server <servername> not responding, timed out

    • Resolution

    • The fix on our system was to lazy unmount, stop any processes that might be using the mount point, and remount.umount -l (mountpoint)
      service yum-updatesd stop
      mount (flags) (mountpoint)

      

      • 

    

    • 


	

	
	




	
	

				

			Solution, Uncategorized
		

			
conflict between 64 bit and 32 bit package architectures

		

			 			Leave a comment
						

	


		

		
yum update or yum install fails with package conflict between 64 bit and 32 bit package architectures ?


Environment


    

  • Red Hat Enterprise Linux 5
    • 

  • Red Hat Enterprise Linux 6
    • 

  • 64 bit architecture
    • 

  • 32 bit packages installed sharing some files with the 64 bit ones
    • 



Problems


    

  • Files are conflicting between 64 and 32 bit packages, how to fix it ?
    • 

  • yum update or yum install fails with package conflict between 64 bit and 32 bit package architectures.
    • 

  • 32 bit package showing conflict problem with 64 bit package.
    • 



Transaction Check Error:
file /usr/share/man/man1/ca.1ssl.gz from install of openssl-0.9.8e-27.el5_10.3.x86_64 conflicts with file from package openssl-0.9.8e-27.el5_10.1.i686
file /usr/share/man/man1/req.1ssl.gz from install of openssl-0.9.8e-27.el5_10.3.x86_64 conflicts with file from package openssl-0.9.8e-27.el5_10.1.i686
file /usr/share/man/man1/x509.1ssl.gz from install of openssl-0.9.8e-27.el5_10.3.x86_64 conflicts with file from package openssl-0.9.8e-27.el5_10.1.i686


Resolution


You can configure the yum client to update only a package of the exact architecture installed on the system.


Perform the following steps to remove duplicate packages(i.e. 32-bit and 64-bit packages installed on server which is causing the dependency issues).


    

  1. Install the yum-utils package:

    # yum install yum-utils
    

    2. 

  2. The package-cleanup --dupes lists all duplicate packages:

    # package-cleanup --dupes
    

    3. 

  3. The package-cleanup --cleandupes removes the duplicates (it asks for a confirmation to remove all duplicates unless the -y switch is given):

    # package-cleanup --cleandupes   
    

    4. 

  4. Edit /etc/yum.confset the following line:

    exactarch=1
    

    caveats to this: add multilib policy update in the configuration file
    5. 



multilib_policy=all


    

  1. Run yum command:

    # yum clean all
# yum update
    

    

    

    

    

    Root Cause
    

    When encountering library specific rpm dependencies, architecture of the packages must be considered. As the error here was from a 32bit rpm failing, logically it would follow the the package to resolve that dependency must also be 32bit. A 64bit library version can’t be utilized by a 32bit tool
    2. 


	

	
	




	
	

			
	

				

			Shell
		

			
The Shebang (#!)

		

			 			2 Comments
						

	


		

		
 


The Shebang (#!)


#!/bin/bash


This is the first line of the script above. The hash exclamation mark ( #! ) character sequence is referred to as the Shebang. Following it is the path to the interpreter (or program) that should be used to run (or interpret) the rest of the lines in the text file. (For Bash scripts it will be the path to Bash, but there are many other types of scripts and they each have their own interpreter.)


Formatting is important here. The shebang must be on the very first line of the file (line 2 won’t do, even if the first line is blank). There must also be no spaces before the # or between the ! and the path to the interpreter.


Whilst you could use a relative path for the interpreter, most of the time you are going to want to use an absolute path. You will probably be running the script from a variety of locations so absolute is the safest (and often shorter than a relative path too in this particular case).


It is possible to leave out the line with the shebang and still run the script but it is unwise. If you are at a terminal and running the Bash shell and you execute a script without a shebang then Bash will assume it is a Bash script. So this will only work assuming the user running the script is running it in a Bash shell and there are a variety of reasons why this may not be the case, which is dangerous.


You can also run Bash, passing the script as an argument.


 


 

	

	
	




	
	

			
	

				

			CLI
		

			
Linux CLI

		

			 			Leave a comment
						

	


		

		
The command line Interface


Chown clear date df eject env expand export fsck ftp help ifconfig ifdown killall ln logout mkisofs mknod pathchk printf quota quotactl ram readarray set shift symlink unshar uptime wait. Aspell bc cmp crontab dd dir dmesg expand expr find format fsck iconv if less lprintd mkisofs netstat nl popd ram rsync ssh tee test top true userdel who xdg-open. Chmod csplit dirs find grep head lprintq lsof mkdir passwd sed slocate ssh tar units until. Aspell builtin cat cfdisk comm cp cron ethtool fsck gawk getopts import local make man mkdir mtools netstat nslookup quotachec rename rev seq set sftp slocate sudo true vmstat xargs. Bg case diff3 expr fuser gawk iconv local lsof mv mmv nslookup printenv quotachec ram set shopt sync tar true ulimit vmstat who.


Awk bc bg case cksum dirname echo egrep groupdel logname lprm mkisofs mknod nohup scp sort sum v whereis while xdg-open. Bash cd chgrp comm dirname dirs echo fold gawk install lpc lprm more printf quotachec rcp read seq sftp sum touch top ulimit unexpand units vdir watch. Command csplit diff3 dircolors enable ifconfig jobs ping readarray sed strace sum wget. Bzip2 dc diff3 echo fdisk free fuser grep head logout lprintq lsof netstat nslookup ping rename renice remsync sdiff sed shopt shutdown sync unset wait whereis write. Fg fmt ftp groupdel groups id look lprint mkdir ping read split trap unset vmstat. Bc dmesg ethtool fmt fuser history id lprintd passwd readonly shutdown tsort unexpand units vmstat xargs yes.


Basename command declare diff3 du env eval exec expect expr iconv jobs lprint ls mkfifo mkisofs mv quota rcp return sftp slocate sync tee tracerout tr ulimit uudecode wait. Cal cut date export for hostname id jobs killall mount open pathchk quota quotachec return set slocate split sum tail time unset userdel uuencode. Cal dd diff3 dircolors eval exit ftp killall logout lpc man nice nohup sleep source ssh test unshar uptime while. Alias bg builtin chgrp csplit dc dmesg eval file fmt fsck function jobs join let local look nice popd reboot rmdir sftp sum suspend tee tracerout unexpand wc. Chmod for groupadd mkfifo mknod netstat shutdown umask uudecode while.


Awk cmp dig eject exit find fmt groupmod ifconfig install look lprintq lsof nslookup op paste printcap rmdir sftp sleep sum tracerout tsort until userdel wait. Awk bzip2 chmod cmp command dir ftp grep import less let ln lprint mtools mv quotachec ram sleep su symlink tail tracerout tr ulimit unexpand vmstat which whoami. Crontab ddrescue df dirname eval expect for hash history iconv id kill mtools nslookup paste pr read rename rev sleep ssh sync touch true type umask uudecode wait watch. Cal comm cp fdisk if lprintd open rev rsync unalias whoami xdg-open. Apt-get cmp enable expect fdformat history import ln lprintq mkdir mmv netstat ping readonly renice remsync slocate uname useradd usermod xdg-open.


Cd diff3 dmesg enable ethtool grep iconv id make ps reboot rsync tsort umask vdir xargs. Apropos eject env exit false lprm ls mkisofs netstat quotachec rcp read readarray select seq time umask unset useradd usermod while who. Cd chgrp crontab dir dircolors iconv pwd ram tail unalias until. Aptitude case chown ddrescue ifdown let local lsof pwd ssh true umask whereis. Alias aptitude bg ddrescue diff dirname false fdformat gawk jobs lprintd mv notify-se printcap quota ssh su tracerout v vi watch whoami. Apropos bc chkconfig clear exit expand free getopts groupmod install killall logname mkisofs open pr pushd readonly rsync select tail tee times tr while.

	

	
	




	
	

			
	

				

			Forum
		

			
Linux and UNIX Security Feature

		

			
				Gallery
			

			 
						Leave a comment
			
					

	


	

		










 






















Linux and UNIX Security Feature






Summary


An introduction to the security facilities of Open Source UNIX-like operating systems, focusing on Linux distributions.


User Accounts


Every UNIX-like system includes a root account, which is the only account that may directly carry out administrative functions. All of the other accounts on the system are unprivileged. This means these accounts have no rights beyond access to files marked with appropriate permissions, and the ability to launch network services.


Network Ports: Only the root account may launch network services that use port numbers lower than 1024. Any account may start network services that use higher port numbers.


Each user should have a single account on the system. Network services may also have their own separate accounts, in order to be able to access those files on the system that they require. Utilities enable authorized users to temporarily obtain root privileges when necessary, so that administrators may manage the system with their own user accounts.


Avoid Logging in as root: You do not need to log in with the root account in order to manage any aspect of your system. Use tools such as su or sudo when you need to carry out an administrative task that requires root privileges.


For convenience, accounts may be members of one or more groups. If a group is assigned access to a resource, then every member of the group automatically has that access.


User Private Groups: On many distributions, each account is automatically made the sole member of a group with the same name as the account. This enables you to easily limit access to particular files or directories, by associating them with a group that will only ever have one member.


The majority of UNIX-like systems use a Pluggable Authentication Modules (PAM) facility to manage access by users. For each login attempt or password change, the relevant service runs the configured PAM modules in sequence. Some modules support authentication sources, such as locally-stored files or LDAP directory services. Administrators may enable other modules that carry out setup tasks during the login process or check login requests against particular criteria, such as a list of time periods when access is permitted.


File Permissions


Every file and directory on a UNIX-style system is marked with three sets of file permissions that determine how it may be accessed, and by whom:


    

  • The permissions for the owner, the specific account that is responsible for the file
    • 

  • The permissions for the group that may use the file
    • 

  • The permissions that apply to all other accounts
    • 



Each set may have none or more of the following permissions on the item:


    

  • read
    • 

  • write
    • 

  • execute
    • 



A user may only run a program file if they belong to a set that has the execute permission. For directories, the execute permission indicates that users in the relevant set may see the files within it, although they may not actually read, write or execute any file unless the permissions of that file permit it. Executable files with the setUID property automatically run with the privileges of the file owner, rather than the account that activates them. Avoid setting the execute permission or setUID on any file or directory unless you specifically require it.


root Ignores File Permissions: The root account has full access to every file on the system, regardless of the permissions attached to that file.


The majority of files on a UNIX-like system are owned by the root account and have permissions that restrict or block access from all other accounts. Avoid modifying the permissions on system files and directories.


Historically, user home directories on UNIX-like systems were publicly readable, to facilitate sharing among academic colleagues. Unfortunately, some popular operating systems still make user home directories publicly readable by default.


Access Control Lists: Many, but not all, modern UNIX-like systems include support for a more flexible set of permissions known as Access Control Lists (ACLs). Unfortunately, some common applications are not fully compatible with ACL permissions.


Data Verification


To create a checksum for a file, or to test a file against a checksum, use the sha1sum utility. SHA1 supersedes the older MD5 method, and you should always use SHA1. For more information about sha1sum, refer to the manual:


man sha1sum



Open Source UNIX-like systems also supply the GNU Privacy Guard (GnuPG) system for encrypting and digitally signing files, such as emails. Many documents refer to GnuPG as gpg, which is the name of the main GnuPG command.


GnuPG Follows the OpenPGP Standard: The files that you sign or encrypt with GnuPG are compatible with other applications that follow the OpenPGP standard.


The Evolution email application automatically supports both signing and encrypting emails with GnuPG. Evolution is the default email application for several of the main Linux distributions, including Fedora, Novell Linux Desktop, Red Hat Enterprise Linux, and Ubuntu.


To use other GnuPG features in the GNOME desktop environment, install Seahorse through the standard software management tool for your distribution. For more information on Seahorse, refer to the project Web site:


http://www.gnome.org/projects/seahorse/


To integrate GnuPG with Mozilla Thunderbird, add the Enigmail extension to Thunderbird. Refer to the Enigmail Web page for installation instructions and other details:


http://enigmail.mozdev.org/


For more information on GnuPG itself, refer to the project Web site:


http://www.gnupg.org/


Encrypted Storage


Create one or more encrypted volumes for your sensitive files. Each volume is a single file which may enclose other files and directories of your choice. To access the contents of the volume, you must provide the correct decryption password to a utility, which then makes the volume available as if it were a directory or drive. The contents of an encrypted volume cannot be read when the volume is not mounted. You may store or copy encrypted volume files as you wish without affecting their security.


The cross-platform Truecrypt utility enables you to create and access your encrypted volumes with all popular operating systems:


http://www.truecrypt.org/


In extreme cases, you may decide to encrypt an entire disk partition that holds or caches data, so that none of the contents may be read by unauthorized persons. On Linux you may use either LUKS, CryptoFS, or EncFS to encrypt disks. Unfortunately, many UNIX-like systems do not yet integrate support for disk encryption facilities into their installation and management software, which makes configuration and maintenance more difficult. Disk encryption also reduces performance, and this may not be acceptable for systems that run demanding applications.


Secure Remote Access with OpenSSH


Every common UNIX-like system today includes a version of OpenSSH, an implementation of the SSH standard for secure remote access. An SSH service uses strong encryption by default, and provides the following facilities:


    

  • Remote command-line access
    • 

  • Remote command execution
    • 

  • Remote access to graphical software
    • 

  • File transfers
    • 



In addition, the forwarding features of SSH allow you to tunnel connections to other services through SSH. A tunneled service benefits from the same security and data compression features as the built-in facilities of SSH. This enables you to protect almost all communications between any UNIX-like systems, even when the traffic passes over open wireless networks or the public Internet.


SSH software not only encrypts the connection between systems but also uses a system of keys to provide mutual authentication between each party. Each SSH client utility automatically checks the identity of any remote system that it connects to, by verifying the key. Similarly, users may identify themselves to systems with a key, rather than typing potentially crackable passwords.


Use SSH by Default: SSH potentially offers the most secure method of remote access available today. The standard Open Source desktop environments now also support SSH as a standard method for working with remote files. Only enable access to your systems through other services if you need to do so in order to meet a specific requirement.


Most Linux distributions include the OpenSSH client by default. The OpenSSH service as usually offered as an option, although some distributions also provide it by default. macOS includes both the OpenSSH service and the client utilities. To access SSH services from Microsoft Windows systems, install PuTTY. You may download PuTTY from the main project Web site:


http://www.chiark.greenend.org.uk/%7Esgtatham/putty/


FileZilla, WinSCP, and other file transfer utilities for Microsoft Windows also support SSH.


The OpenBSD project maintains the OpenSSH software and Website:


http://www.openssh.com/


Software Management


The majority of Linux distributions incorporate software management facilities based on package files and sets of specially prepared Web sites, known as repositories or channels. Package management utilities construct or update working copies of software from these packages, and execute any other setup tasks that packages require. Repositories enable the management tools to automatically provide the correct version of each software product, by downloading the required packages directly from the relevant repository. Most systems also use checksums and digital signature tests to ensure that packages are authentic and correct.


In addition, package management tools can identify outdated versions of software by checking the software installed on a system against the packages in the repositories. This means that you can ensure that all of the supported software on your system does not suffer from a known security vulnerability, simply by running the update routine.


Most desktop systems now automatically alert you when new versions of the installed packages are released to the repositories, and provide options to update your system. Graphical interfaces to their software management tools also enable you to browse and select new software from the available packages.


Use packages from repositories whenever possible, in order to guarantee the provenance of the software on your system, and to ensure that it remains current. If you use software from elsewhere then you will need to verify, install, and update those products yourself. In these cases, download the software directly from the Web site of the manufacturer. Package management tools cannot inventory, check, or maintain any software that was compiled from source code, so you must be particularly careful when you use manually compiled products.


For historical reasons, the main Linux distributions use different package management products. Fedora, Red Hat Enterprise Linux, and related distributions use the RPM package format, and their software management facility is known as YUM. Debian, Ubuntu, and their derivatives use the APT management system and the DEB package format. These systems and package formats are largely equivalent.


Host Integrity Testing


To verify that a running system has not been compromised or tampered with, use an integrity testing facility. All host integrity testing software verifies a complete copy of a system by testing each file against a previously made checksum. Solaris and FreeBSD distributions both now include integrity testing utilities for this purpose. You may also use a cross-platform integrity monitoring system, such as Samhain or Osiris. Both Osiris and Samhain support centralized system auditing for multiple systems.


Since system configurations vary, administrators must configure the integrity tester to exclude the particular directories and files that are expected to change on a system, before creating an initial checksum database for that system. Integrity testing can then compare the checksums of each file against the database, and report on any disparity.


System Recovery


You may easily restore program files for all of the software that is included with your distribution with the software management tools. In order to fully recover a system from an accident, or deliberate compromise, you must also have access to copies of the data, configuration, and log files. These files require some form of separate backup mechanism.


All effective backup systems provide the ability to restore versions of your files from several earlier points in time. You may discover that the current system is damaged or compromised at any time, and need to revert to previous versions of key files, so keeping only one additional copy of a key file should not be considered an adequate backup.


Duplicates Are Not Archives: File synchronization software and RAID storage make duplicate copies of the current files, and may act as a safeguard against data loss from hardware failures. Unlike backup systems, these measures do not provide access to previous versions of files.


Distributions provide a wide range of backup tools and leave it to the administrator to configure a suitable backup arrangement for their systems.


Resource Allocation Controls


You may configure several mechanisms to limit the resources that an application or user account may consume. On systems with multiple users, enforce resource limits to ensure that no user may accidentally or deliberately cause facilities to fail by using all of the available resources. Since the correct resource allocations vary widely, administrators must configure appropriate limits for the system.


To set resource limits for particular services, edit the systemd configuration file for the service. If you need to limit individual processes, add a ulimit setting to the shell script that launches them. For more information about ulimit, refer to the manual for the bash shell:


info bash



The PAM login system includes a module to enforce certain resource limits for entire user sessions. The restrictions that this imposes may be circumvented, but they do provide some defense against accidental problems.


You must specifically enable storage quotas on each disk partition if you require them. Quotas prevent users from overloading the storage and backup facilities, but quota management is often an administrative matter rather than a direct security concern. Configuring storage quotas is beyond the scope of this document.


Monitoring and Audit Facilities


On Linux systems, the syslog and klogd services record activity as it is reported by different parts of the system. The Linux kernel reports to klogd, whilst the other services and facilities on the system send log messages to a syslog service. Distributions provide several tools for reading and analyzing the system log files.


Several facilities on any UNIX-like system may also email reports and notifications directly to the root account, via the SMTPservice. Edit the aliases file to redirect messages from root to another email address, and you will receive these emails at the specified address.


Automatic Log Summaries: Many distributions automatically send daily reports to the email address for root that summarize the activity logged by syslog and klogd.


To provide a central logging facility for your network, first select one of your systems as the log host. Configure the syslog services on your other systems to forward the information that they receive to the syslog service on the log host. You may then run analyzers on the log host to monitor events across the network.


For detailed real-time monitoring of the systems on your network, install SNMP agents that report to a management service such as Nagios or OpenNMS. SNMP is beyond the scope of this document.


Monitoring Network Appliances: Many network appliances, such as routers, support the syslog and SNMP standards. This enables you to monitor both UNIX systems and other network devices with the same log hosts and SNMP services.


Refer to the man page for basic information about syslogd:


man syslogd



Similarly, for more on klogd, refer to the man page:


man klogd



Both syslog and SNMP rely on software dispatching messages to a central service. If you configure process accounting on a system it maintains records of all the processes that are run on that system. Linux includes some support for process accounting, and distributions supply packages for GNU Accounting Utilities. Refer to the Web page for more information on the GNU Accounting Utilities:


http://www.gnu.org/software/acct/


Fedora and Red Hat Enterprise Linux systems also offer the LAuS (Linux Auditing System) framework. For more information on this, refer to the man pages for auditd:


man auditd



The System Firewall


The netfilter framework included in the Linux kernel restricts incoming and outgoing network connections according to a set of rules that have been defined by the administrator. Several Linux distributions configure firewall rules by default and offer utilities for managing simple firewall configurations. You may also manage the firewall rules on any Linux system with the standard iptables and ip6tables command-line utilities, or with third-party utilities such as Firestarter. If you decide to use iptables, remember that it only configures restrictions for IP version 4 connections and that you will need to use ip6tables to setup rules for IP version 6 as well.


Fedora, Red Hat, and SUSE automatically enable the firewall and supply their own graphical configuration utilities. You must manually configure and enable the firewall on Debian and Ubuntu systems. Current releases of Ubuntu include a command-line utility called ufw for firewall configuration.


Those Linux distributions that enable a firewall by default use a netfilter configuration that blocks connections from other systems. Any attempt by a remote system to access a service on a blocked port simply fails. This means that no other system may connect to an installed service unless you specifically choose to unblock the relevant port.


Use Only One Means Of Managing Your Firewall: Every firewall utility modifies the current firewall rules on the system. To ensure that your firewall operates correctly, select one method of managing the configuration, and avoid editing the firewall rules by other means.


Application Isolation


The most common UNIX-like operating systems provide several methods of limiting the ability of a program to affect either other running programs, or the host system itself.


    

  • Mandatory Access Control (MAC) supplements the normal UNIX security facilities of a system by enforcing absolute limits that cannot be circumvented by any program or account.
    • 

  • Virtualization enables you to assign a limited set of hardware resources to a virtual machine, which may be monitored and backed up by separate processes on the host system.
    • 

  • Linux Container facilities, such as Docker, run processes within a generated filesystem and separate them from the normal processes of the host system
    • 

  • The chroot utility runs programs within a specified working directory and prevents them from accessing any other directory on that system.
    • 



The administrator may setup guest operating systems in virtual environments for specific tasks, and restrict these guests far more than would be possible for a multi-purpose system. Each specialized system may include far less software, and this also simplifies every administrative task, including MAC configuration. Neither MAC nor virtualization prevent individual applications or services from being compromised, misconfigured or malfunctioning, but may prevent a problem from escalating.


At the simplest level, the SELinux framework can provide MAC facilities, to enforce a policy that defines the access permitted to programs or accounts on the system. SELinux was actually created by the NSA to meet the needs of government agencies handling classified data and enables administrators to develop extremely detailed and precise security configurations that encompass the entire operating system. Many developers and administrators consider SELinux too high a maintenance burden to implement fully.


Fedora and Red Hat Enterprise Linux systems automatically include a limited SELinux policy that restricts many standard network services, without affecting users or other programs. These distributions also provide some simple management tools for customizing the default policy and troubleshooting SELinux issues, but no tools to assist with developing new policies. Debian provides SELinux, but support is limited.


Ubuntu and SUSE do not enable SELinux by default. Instead, they provide the AppArmor facility. AppArmor configuration is much simpler than SELinux, but it offers more limited capabilities.


Several Open Source solutions exist to run complete operating systems within a virtual environment. By far the most popular are Xen and KVM. Xen enables you to configure a system to act as a host for multiple virtual environments, all of which are controlled by a single hypervisor. Current Linux distributions on machines that include CPUs with virtualization support may run the simpler and more flexible KVM. The current KVM offers significantly higher performance than the QEMU machine emulator that is it based upon. The original QEMU software operates too slowly for production applications, although it remains useful for testing and development work.


Modern Linux systems include support for containers and provide tools that enable you to easily use this facility. Docker relies on a background service that manages the containers on the host system, and this can support a large number of containers on a single host. The systemd-nspawn utility that is supplied with systemd runs individual containers without requiring an extra service.


Containers Do Not Isolate Processes: By default, any process within a container still has access to the facilities of the host system, such as networking, even though it does not have access to most of the filesystem. Any process that runs as root in a container can alter the host system.


The older chroot facility is universally available, but was originally designed for development tasks rather than security, and may be circumvented. Developers use this facility for building and testing software in a clean environment. Historically, administrators also used chroot to run potentially unsafe network services such as FTP servers within specially designed environments. Several tools exist to simplify constructing and maintaining chroot environments.


Applications May Escape chroot: Any application that is able to run arbitrary commands can execute code to gain access to the main system. To ensure the security of the chroot environment, avoid including shells, compilers, or script interpreters within the chroot directory. Any application that runs with root privileges may also escape the restrictions of chroot.


For more information about chroot, refer to the manual:


info chroot



A Note on Viruses and Malware


The security features of UNIX-like systems described above combine to form a strong defense against malware:


    

  • Software is often supplied in the form of packages, rather than programs
    • 

  • If you download a working program, it cannot run until you choose to mark the files as executable
    • 

  • By default, applications such as the OpenOffice.org suite and the Evolution email client do not run programs embedded in emails or documents
    • 

  • Web browsers require you to approve the installation of plug-ins
    • 

  • Software vulnerabilities can be rapidly closed by vendors supplying updated packages to the repositories
    • 



Although a virus could be written for use against current UNIX-like systems, no effective malware is known to exist. It is likely that any future malware would need the consent of a user on the system in order to install itself, significantly reducing the possibility that any such software would be able to spread across networks.