Linux Hardening

• Introduction
• Principles of hardening
• Protective partitioning of the system
• Installing/running only necessary software
• Remove common redundant packages
• Disabling services in Linux environment
• The xinetd.conf File
• Using chroot
• Using chattr/lsattr
• PAM - Pluggable Authentication Modules

• Deleting Unnecessary User Accounts and Restricting Shell Access

• Running Services in Chrooted Filesystems

• Minimizing Use of SUID root executables

• Linux last and lastb commands

• Procedure for integrating Bastille Hardening Script

Introduction

Generally Linux hardening is by-and-large similar to a more developed area of Solaris hardening and corporation experience with hardening Solaris is transferable to Linux.  It is a difficult and unrewarding job.

There are some Linux hardening packages of low or very low quality, for example the (abandonware) Bastille package discussed later. For Suse at one time there was harden_suse script.  More recent Linux package that is under development is Lynis. It's better than alternatives but still in default mode recommendation are either trivial of harmful. Tuning can increase the value of recommendations considerably, so this package has promise.

Checking of the level of hardening (system audit) can be performed by the same package as hardening.

Having said that, the principles of Linux hardening like any other Unix hardening in general can be summed up by the Principle of Least Privilege. This was originally used by the National Institute of Standards and Technology (NIST) to describe the desired behavior of the "Role-Based Access Controls" it developed for mainframe systems: "a user [should] be given no more privilege than necessary to perform a job" (http://hissa.nist.gov/rbac/paper/node5.html).

For example it is difficult to harden systems with GUI desktops like Gnome of KDE. So it server is interned to be more secure, it is prudent to configure X subsystem for a manual start, so that in production mode X usually does not run. Same is true for most daemons. If it is not required in production mode it should be configured for a manual start.  For example if FTP is required it would be available only for a time windows that automatic scripts use it to transfer files and IP can be restricted via TCP wrappers. 

But the key problem with hardening is to know where to stop not how to make the system more secure. And the key principle is "not too much zeal". Unfortunately corporate security departments often discard this vital principle and use hardening for justification of their existence ;-).

Principles of Hardening

Linux has historically tended to be "insecure by default": most distributions' default installations are designed to present the user with many preconfigured and active applications, which usually represent high security risk. As they apply to system hardening, the real work stems from these corollaries:

• Use Solaris instead of Linux if you need highly secure system. Linux is way too popular and was too complex to be secured reliably. It is Windows XP of Unix world. This variant of security via obscurity not only works, if works amazingly well and is more cost effective then securing Linux system and maintaining it in this state with patches.

• Segment the system into "waterprof blocks" using partitioning. Mount filesystems with minimum possible number of features. Use nosuid, noexec, noacl  and other mounting attributes whenever possible.

• Install only necessary software; delete or disable everything else. Understand and use the security features supported by your operating system and applications, especially when they add redundancy.

• Delete or disable unnecessary user accounts.

• Don't needlessly grant shell access: /bin/noshell should be the default shell for nobody, and any other account used by services. Only human users should have a real shell.

• Allow each service (networked application) to be publicly accessible only by design, never by default.

• Run most publicly accessible services like ftp in a chrooted filesystem (i.e., a subset of /).

• Don't leave any executable file needlessly set to run with superuser privileges, i.e., with its SUID bit set (unless owned by a sufficiently nonprivileged user).

• If your system has multiple administrators, use wheel group and sudo to delegate root's authority.

• Configure remote log server and logs checking.

• Run Linux with firewall enables and only the necessary ports opened. 

• Check a tuned for your system auditing script and mail reports on periodic basis.

All of these requirement are essentially ways of implementing and enforcing the Principle of Least Privilege. We'll spend most of the rest of part of the whitepaper discussing each in some depth with specific techniques and examples. We'll end this part by discussing Bastille Linux which is a recommended hardening script for Red Hat distribution.

Protective partitioning of the system

See Protective partitioning

Installing/Running Only Necessary Software

This is the most complex and the most important hardening steps in Linux as by default both Red Hat and Suse install huge number of "extra" applications and daemons. See Disabling useless daemons in RHEL/Centos/Oracle linux servers fot some hints.

Common sense, for example, dictates that a production server doesn't need a C compiler to be installed. Remember, since our guiding principle is "that which is not expressly permitted must be denied," it follows that "that which is not necessary should be considered needlessly risky."

To analyze if a given package is necessary for the intended server purpose or not currently is a manual process. The simplest way to get an initial guess is via a man lookup. All manpages begin with a synopsis of the described command's function. If there's no manpage for the command/package (or you don't know the name of any command associated with the package), try apropos <string> for a list of related manpages. If that fails, your package manager should, at the very least, be able to tell you what other packages, if any, depend on it. Even if this doesn't tell you what the package does, it may tell you whether it's necessary.

For example, if reviewing the packages I see libglade installed but am not sure I need it I should do the following:

$ man libglade
No manual entry for libglade
   
$ apropos libglade
libglade: nothing appropriate
   
$ rpm -q --whatrequires libglade
memprof-0.3.0-8
rep-gtk-gnome-0.13-3

That means that libglade is part of GNOME desktop. If the server in question doesn't need the X Window System at all, let alone a fancy desktop like GNOME, libglade can be uninstalled (along with the rest of GNOME).

In SuSE yast can help with the deinstallation of packages: navigate to Package Management Change/Create Configuration, flag libglade for deletion, and press F5 to see a list of any dependencies that will be affected if you delete libglade.

Remove Common Redundant Packages

For both RedHat and Suse it is recommended not to install the X Window System on DMZ servers. On internet servers it can be installed by should be be loaded by default (system should boot to the command line prompt.

Server applications almost never require X. If a server is to run "headless" (without a monitor and thus administered remotely), then it certainly doesn't need a full X installation with GNOME, KDE, etc. It might benefit from a minimal X11 system. Unlike windows most system administration tools in Linux have their command line equivalents.

During Linux installation, deselecting X Window packages, especially the base packages, will return errors concerning "failed dependencies." You may be surprised at just how many applications make up a typical X installation. In all likelihood, you can safely deselect all of these applications, in addition to X itself.

When in doubt, identify and install the package as described previously (and as much X as it needs Ч skip the fancy window managers) only if you're positive you need it. If things don't work properly as a result of omitting a questionable package, you can always install the omitted packages later.

The second large category of applications inappropriate for production systems is the software-development environment. Trusted internal systems, not exposed public systems, should be used for developing and building applications. One of the first things any accomplished system cracker does upon compromising a system is to build a "rootkit," a set of standard Unix utilities such as ls, ps, netstat, and top, which appear to behave just like the system's native utilities. Rootkit utilities, however, are designed not to show directories, files, and connections related to the attacker's activities, making it much easier for said activities to go unnoticed. A working development environment on the target system makes it much easier for the attacker to build a rootkit that's optimized for your system. Of course, the attacker can still upload his own compiler or precompiled binaries of his rootkit tools. But Tripwire or some other system-integrity-checker will alert you to changes in important system files.

tcpdump, nmap and similar security tools should be made accessible only to root and selected users (system administrators in a wheel group) as they have tremendous potential for misuse.

As for network services the list of necessary services is determined by the server role and as such is better determined by the hardening script used than by a paper policy.

While any unneeded service should be either deleted or disabled, the following deserve particular attention:

rpc services

Sun's Remote Procedure Control protocol (which is included nowadays on virtually all flavors of Unix) lets you centralize user accounts across multiple systems, mount remote volumes, and execute remote commands. But RPC isn't a very secure protocol, and you shouldn't be running these types of services on a DMZ hosts anyhow.

Disable (rename) the nfsd and nfsclientd scripts in all subdirectories of /etc/rc.d in which they appear.

r-services

rsh, rlogin, and rcp allow remote shell sessions and file transfers using some combination of username/password and source-IP-address authentication. But authentication data is passed in the clear and IP addresses can be spoofed, so these applications are not suitable for DMZ use. If you need their functionality, use Secure Shell (SSH), which was specifically designed as a replacement for the r-services.
 

linuxconfd

While there aren't any known exploitable bugs in the current version of linuxconf (a system administration tool that can be accessed remotely), CERT reports that this service is commonly scanned for and may be used by attackers to identify systems with other vulnerabilities (CERT Current Scanning Activity page http://www.cert.org/current/scanning.html).

sendmail

Sendmail, which is enabled by default on most versions of Unix, should not run continuously as a daemon

Telnet

Due to higher level of vulnerability of Linux systems telnet should be restricted via firewall to necessary segment. If possible ssh should he used instead.

Disabling Services in Linux Environment

Red Hat have chkconfig utility to manage startup services:

# chkconfig --help
chkconfig version 1.3.6 - Copyright (C) 1997-2000 Red Hat, Inc.
This may be freely redistributed under the terms of the GNU Public License.
   
usage:   chkconfig --list [name]
         chkconfig --add <name>
         chkconfig --del <name>
         chkconfig [--level <levels>] <name> <on|off|reset>)

To list all the startup services on my Red Hat system, I simply enter chkconfig --list.

# chkconfig --list 
anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
httpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
syslog          0:off   1:off   2:on    3:on    4:on    5:on    6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off
sendmail        0:off   1:off   2:on    3:off   4:off   5:on    6:off
(etc.) 

It will display the table on which run level which service is active. For example To disable Sendmail in run level 5, the following commands can be used:

# chkconfig --level 5 sendmail off
# chkconfig --list sendmail
sendmail       0:off   1:off   2:off   3:off   4:off   5:off   6:off

(The second command, chkconfig --list sendmail, is optional but useful in showing the results of the first.)

On SuSE systems, edit the startup script itself (the one in /etc/init.d), and then run the command insserv (no flags or arguments necessary) to change automatically the symbolic links that determine the runlevels in which it's started. Each SuSE startup script begins with a header, comprised of comment lines, which dictate how init should treat it

# /etc/init.d/lpd
#
### BEGIN INIT INFO
# Provides: lpd
# Required-Start: network route syslog named
# Required-Stop: network route syslog
# Default-Start: 2 3 5
# Default-Stop:cdd

# Description:  print spooling service
### END INIT INFO

For our purposes, the relevant settings are Default-Start, which lists the runlevels in which the script should be started, and Default-Stop, which lists the runlevels in which the script should be stopped. Actually, since any script started in runlevel 2, 3, or 5 is automatically stopped when that runlevel is exited, Default-Stop is often left empty.

Any time you change a startup script's INIT INFO header on a SuSE system, you must then run the command insserv  or chkconfig to tell SuSE to change the start/stop links accordingly (in /etc/init.d's "rc" subdirectories). insserv is run without arguments or flags. For more information about the SuSE's particular version of the System V init-script system, see SuSE's init.d(7) manpage.

The xinetd.conf File

The /etc/xinetd.conf file (previously the inetd.conf file) controls many Linux services, including File Transfer Protocol (FTP) and Telnet.  Some daemon like pure-ftpd are designed (badly designed in case of pure-ftpd as configuration changes need to be passed as parameters) to run via xinetd as they do not contain compiled TCP wrappers.

The xinetd (like inetd before it) is a super server listening for incoming network activity for a range of services. It determines the actual nature of the service being requested and launches the appropriate server. The primary reason for the design is to avoid having to start and run a large number of low-volume servers which have relatively quick start.

Additionally, xinetd’s ability to launch services on demand means that only the needed number of servers is run. The etc/xinted.conf file directs requests for xinetd services to the /etc/xinetd.d directory. Each xinetd service has a configuration file in the xinetd.d directory. If a service is commented out in its specified configuration file, the service is unavailable.

The /etc/xinetd.d directory makes it simple to disable services that a particular server is not using.

Using chroot

chroot is one of the most powerful possibilities to restrict a daemon or a user or another service. Just imagine a jail around your target, which the target cannot escape from (normally, but there are still a lot of conditions that allow one to escape out of such a jail). If you do not trust a user, you can create a change root environment for him. This can use quite a bit of disk space as you need to copy all needed executables, as well as libraries, into the jail. Even if the user does something malicious, the scope of the damage is limited to the jail.

A good example for this case is, if you do not authenticate against /etc/passwd but use LDAP or MySQL instead. So your ftp-daemon only needs a binary and perhaps a few libraries. A chrooted environment would be an excellent security improvement; if a new exploit is known for this ftp-daemon, then attackers can only exploit the UID of the ftp-daemon-user and nothing else.

Of course, many other daemons could benefit from this sort of arrangement as well.

However, be forewarned that a chroot jail can be broken if the user running in it is the superuser. So, you need to make the service run as a non-privileged user. By limiting its environment you are limiting the world readable/executable files the service can access, thus, you limit the possibilities of a privilege escalation by use of local system security vulnerabilities. Even in this situation you cannot be completely sure that there is no way for a clever attacker to somehow break out of the jail. Using only server programs which have a reputation for being secure is a good additional safety measure. Even minuscule holes like open file handles can be used by a skilled attacker for breaking into the system. After all, chroot was not designed as a security tool but as a testing tool.

As an additional note, the Debian default BIND (the Internet name service) is not shipped chrooted per default; in fact, no daemons come chrooted.

There is also some software (not currently in Debian but which might be packaged in the future) that can help setup chroot environments. makejail for example, can create and update a chroot jail with short configuration files. It also attempts to guess and install into the jail all files required by the daemon. More information at http://www.floc.net/makejail/. Jailer is a similar tool which can be retrieved from http://www.balabit.hu/downloads/jailer/.

Also useful to create chroots (or jails) is deb.pl, a script that analyses dependencies of a set of files.

Using chattr/lsattr

These two commands are very useful, but they only work for the ext2/ext3 filesystem. With 'lsattr' you can list the attributes of a file and with 'chattr' you can change them. Note that attributes are not the same thing as permissions. There are many attributes, but only the most important for increasing security are mentioned here. There are two flags which can only be set by the superuser.

• First there is the 'a' flag. If set on a file, this file can only be opened for appending. This attribute is useful for some of the files in /var/log/, though you should consider they get moved sometimes due to the log rotation scripts.
• The second flag is the 'i' flag, short for immutable. If set on a file, it can neither be modified nor deleted or renamed and no link be created to it. If you do not want users to look into your config files you could set this flag and remove readability. Furthermore it can give you a little bit more security against intruders, because the cracker might be confused by not being able to remove a file. Nevertheless, you should never assume that the cracker is blind. After all, he got into your system.

You can, also, remove the chattr and lsattr programs from the system so that an intruder with root access cannot change (or list) this attributes. Since they are part of the e2fsprogs and it's Required priority you cannot simply remove it. However, you can safely delete these two applications (and probably some others) from the filesystem. Copy them before to a removable media (floppy disk?) along with they md5sums.

An intruder in the system would have to download his own copies of the binaries in the system (probably even compile them in it) which might give you a littler more time to detect and recover from the compromise before the whole system is overrun.

PAM - Pluggable Authentication Modules

Both the Red Hat Linux and Suse Linux distributions ship with a unified authentication scheme called "PAM". PAM allows you to change your authentication methods and requirements on the fly, and encapsulate all local authentication methods without recompiling any of your binaries. Configuration of PAM is beyond the scope of this document, but be sure to take a look at the PAM web site for more information. http://www.kernel.org/pub/linux/libs/pam/index.html.

Just a few of the things you can do with PAM:

• Use encryption other than DES for your passwords (Making them harder to brute-force decode)
• Set resource limits on all your users so they can't perform denial-of-service attacks (number of processes, amount of memory, etc)
• Allow specific users to login only at specific times from specific places

You can also prevent many attacks on unsecure services, like r-services, if you need to use them instead of ssh. For example, use PAM to disable the system-wide usage of .rhosts files in user's home directories by adding these lines to /etc/pam.d/rlogin:

		#
		# Disable rsh/rlogin/rexec for users
		#
		login auth required pam_rhosts_auth.so no_rhosts

Deleting Unnecessary User Accounts and Restricting Shell Access

This part of the server hardening process is well understood due to our Solaris experience and should not represent major problems. Still it's annoying to see a long list of entries in /etc/passwd for application-specific user accounts, regardless of whether those applications are even installed in each Linux distribution. For example, Red Hat created 33 such entries during installation, Suse 48 entries. While few of these are privileged accounts, many can be used for interactive login (i.e., they specify a real shell rather than /bin/noshell).

If you aren't sure what a given account is used for but see that account has an actual shell specified, one way to determine whether an account is active is to see whether it owns any files, and if so, when they were last modified. This is easily achieved using the find command.

Some accounts that are necessary, for example:

• root

• bin

• daemon

• rpcuser

• rpc

Several default system accounts are unnecessary in the enterprise environment and should be removed as the part of hardening:

• uucp

• news

• games

• shutdown

• halt

• gopher

uucp package needs to be deinstalled before removing uucp account if it was installed on the system. Generally only "human accounts" should have shells.

Running Services in Chrooted Filesystems

One of our most important threat models is that of the hijacked daemon: if a malicious user manages to take over and effectively "become" a process on our system, he will assume the privileges on our system that that process has. That means that it's equally important to mitigate the risk of potential daemon vulnerabilities, i.e., vulnerabilities that might be unknown to anyone but the "bad guys." There are two primary means of doing so: running the process with as low a set of privileges as possible (see the next section) and running the process in a chroot jail.

Normally, a process can see and interact with as much of a system's filesystem as the user account under which the process runs. Since most of the typical Linux host's filesystem is world-readable, that amounts to a lot of real estate. The chroot system call functionally transposes a process into a subset of the filesystem, effectively redefining the / directory for that process to a small subdirectory under the real root.

chroot is not an absolute control: a chroot jail can be subverted via techniques such as using a hard link that points outside of the chroot jail or by using mknod to access the hard disk directly. However, since none of these techniques is very easy to execute without root privileges, chroot is a useful tool for hindering an attacker who has not yet achieved root privileges.

Minimizing Use of SUID Root Executables

Normally, when you execute a command or application, it runs with your user and group privileges. Sometimes, however, a command's permissions include a set user-ID (SUID) bit or a set group-ID (SGID) bit, indicated by an "s" where normally there would be an "x"

-rwsr-xr-x    1 root     root        22560 Jan 19  2001 crontab

This causes that command to run not with the privilege level of the user who executed it, but of the user or group who owns that command. If the owner's user or group ID is 0 (root), then the command will run with superuser privileges no matter who actually executes it. That means that each and every SUID executable represents a security risk.

The SUID and SGID bits are most often used for commands and daemons that normal users might need to execute, but that also need access to parts of the filesystem not normally accessible to those users. For some utilities like su and passwd, this is inevitable: you can't change your password unless the command passwd can alter /etc/shadow, but obviously, these files can't be directly writable by ordinary users.

Some applications that run SUID or SGID have only limited need of root privileges, while others needn't really be run by unprivileged users. For example, mount is commonly run SUID=root, but on a server-class system there's no good reason for anybody but root to be mounting and unmounting volumes, so mount can therefore have its SUID bit unset.

The simplest way to identify files with their SUID and SGID bits set is with the find command. To find all root-owned regular files with SUID and SGID set, we use the following two commands:

find / -perm +4000 -user root -type f -print
find / -perm +2000 -group root -type f -print

If you determine that a file thus identified doesn't need to run SUID/SGID, the command to unset SUID is:

chmod u-s  /path/filename 

and this command to unset GUID:

chmod g-s  /path/filename 

Bastille hardening script has an entire module devoted to unsetting SUID and SGID bits. However, Bastille deals only with some SUID files common to many systems; it doesn't actually identify all SUID/GUID files specific to the server and the scripts needs to be adapted for each server role.

Procedure for integrating Bastille Hardening Script

Bastille is a very weak, badly engineered and architectured Perl script, so beware. It was discontinued in 2006 so right now this is abandonware. Note below is just for historical importance.

The following checklist can be used by system administrators for proper Bastille integration into the the system installation and hardening process.

This is a list of items to help the administrator set up a secure Linux system. This is a suggested list and provides some explanation why each item is important. It can also be used for HP-UX system with some minor modifications.

	Identify All Hardware
	Check for Bios and chipset updates
	IP Address and Host Name
	Partition the hard drive and install operating system
	Use rpm to remove packages which will not be used
	Turn off unused network services
	Install Additional Packages
	Install patches
	Make a strong root password
	Remove all unused system accounts
	Install an Access Warning Banner
	Configure and run Bastille-Linux
	Configure xnetd
	Check if SSH is availble
	Configure Tripwire
	Check for running Network Services
	Have the system scanned for security vulnerabilities

Identify all hardware

• Video
• Drive SCSI or IDE
• Network card
• Chipset
• Bios

Check for Bios, chipset and drivers updates

Check the vendor site of the hardware manufacturer(s) for updates

IP Address and Host Name

Contact the DNS administror to register the host name and obtain an IP address.

The host name should describe what the server is doing but should not contain the type of operating system nor should it tell the user it's primary application. For example, linuxfinance or oraclegsfc are not good names. Orion and sunspot are good names.

If you are re-using an IP address, confirm that the IP address, Subnet Mask, Default Gateway, and DNS settings are correct for the machine.

Partition hard drive(s) and install Operating System

Use rpm to manually remove packages which will not be used

Review the list of all installed program packages:

• rpm -qa

If you want details on an installed package type:

• rpm -qi &ltpackage-name>

Remove all program packages (one at a time) that you will not be using:

• rpm -e <package-name>

Turn off unused network services

Disable all of the following network services

• rshd
• rlogind
• rwhod
• telnetd - replace with ssh
• ftpd - replace with scp (if ftp is required then if should be configured to run chroot)
• sendmail

Some of the above services can be disabled by removing the associated rpm package. Others can be disabled by running the 'chkconfig' command and selecting all levels off (example: 'chkconfig --level 123456 sendmail off'). Still others can be disabled by removing entries from the /etc/inetd.conf file or the modifying the appropriate file in the /etc/xinetd directory (later versions of chkconfig will modify the xinetd entries for you).

Install Additional Packages

Install the following rpm packages if they were not installed initially

• openssh
• lsof
• bastille-linux
• tripwire

Install patches

Sometimes, package dependencies change from one version to the next. This is common with RedHat. Therefore it is very likely that the rpm -Fvh might fail the first time around. If it does, then manually resolve those dependencies by 'rpm -Uvh <needed packages>' and then attempt the rpm -Fhv again. Continue to resolve any dependencies. When all dependencies have been resolved, rpm -Fvh will proceed to update all remaining packages without complaint. If you have difficulty determining which package will resolve needed dependency, point your web browser to www.rpmfind.net and it will help. Experience has shown that all dependencies can be resolved with the packages contained in the update directory on the CD-ROM but it is not always obvious which package to load.

Make a strong root password

Root Password: This is the most critical password. Of all of the passwords this is the one that has to be strong. Strong being minimum 8 characters of which at least two of the characters should be numbers or special characters.

Remove all redundant system accounts

Disable the ones that were mentioned above.

Install an Access Warning Banner

The banner needs to be installed for each of the appropriate network services which you are offering. Usually updating /etc/issue and /etc/issue.net is sufficient. Note - on Redhat systems the /etc/issue and /etc/issue.net files are overwritten at each boot. To avoid this, modify the file /etc/rc.local to leave your changes intact.

Configure Bastille-Linux

Bastille-Linux was installed in an earlier step. "The Bastille Hardening System attempts to 'harden' or 'tighten' the Linux operating system. It currently supports Red Hat and Mandrake systems."

Run the following command:

• /usr/sbin/InteractiveBastille

Use the following as a basic guide for the Bastille settings:

• Firewall Module:
  • Run Packet Filtering Script? NO (YES if this is multihomed system)
• File Permissions Module:
  • Restrict permissions on admins utils? YES
  • Disable SUID ping? NO
  • Disable SUID at? NO
  • Disable SUID printing? NO
  • Disable SUID traceroute? NO
• Account Security Module:
  • Disallow dangerous r-protocols? NO
  • Apply password aging? YES
  • Restrict cron? NO
  • Restrict root login to TTY1-6? YES
  • Does system boot from hard drive? YES
  • Disable CTRL-ALT-DEL reboot? NO
  • Password Protect single-user mode? YES
• SecureInetd Module:
  • Set default deny on TCP wrappers and xinetd? YES
  • Deactivate telnet? YES (use ssh)
  • Deactivate ftp? YES (use scp)
• Disable User Tools Module:
  • Disable compiler? YES
• Configure MiscPAM module:
  • Limit resource usage? NO
  • Restrict console access? NO
• Logging Module:
  • Add additional logging? YES
  • Configure remote logging host? NO
  • Enable process accounting? NO
• Miscellaneous Daemons Module:
  • Deativate routing daemon? YES
  • Leave sendmail in daemon mode? NO
  • Run sendmail via cron for outgoing messages? NO
  • Disable VRFY and EXPN sendmail commands? YES
• Printing Module:
  • Disable printing? NO
• TMPDIR Module:
  • Install TMPDIR/TMP scripts? YES
• End Screen Module:
  • Make changes? YES
  • Apply configuration to system? YES

Configure xnetd

xinetd has TCP wrappers capability built in. That should be done after Bastille setup since it makes some changes also.

First check the /etc/xinet.conf file. The /etc/xinetd.conf contains default values for the services it runs. It may also contain specific settings for the individual services or a reference (includedir) to a directory where the individual services are configured. In the 'defaults' section ensure the following are set:

no_access = 0.0.0.0	this denies all connections by default. This must be enabled on a per service basis. Bastille setup should have made this setting for you already.
log_type = SYSLOG authpriv	this causes the log messages to use the syslog facility. /etc/syslog.conf will tell you where the 'authpriv' messages are sent.
log_on_success = HOST PID log_on_failure = HOST	these indicate what info to log for each connection attempt.

Next ensure that only the services you need are turned on. 'chkconfig --list' will show you the status of the xinetd services. Turn on only the ones you need, all others should be off. For instance, to turn off telnet and turn on wu-ftpd do this:

chkconfig --list
chkconfig telnet off
chkconfig wu-ftpd on

For each service that you enable, make the following entry in the corresponding service file in the /etc/xinetd.d directory (or in the /etc/xinetd.conf if the services are defined there).

only_from = 10.0.0.0	this permits connections only from 10 network. all others are denied. If you need global access the use 0.0.0.0 - this permits connections from anywhere.
no_access = 144.29.0.0	this example denies connections from any machine in the 144.29.*.* network. by combining 'only_from' and 'no_access' values you can tweak who can and cannot access your services. Be sure to check the logfile for failed connections.

Check if SSH is availble

You should have installed the SSH rpm in an earlier step. This should have enabled the service for you. To confirm, type 'chkconfg --list' and look for the sshd entry - it should be on for at least the default run level (default run level is listed in /etc/inittab). The default settings for sshd are ususally pretty good - if you need to change any they are located in the /etc/ssh/sshd_config file.

Configure Tripwire

You should have installed the tripwire rpm from the update cdrom in an earlier step. To configure it for your system do the following:

• First modify the local policy to email reports when system file modifications are discovered. By default, email is not sent. To have email sent, edit the '/etc/tripwire/twpol.txt' file and modify each instance of "severity = " by adding a comma and a newline, then on the new line enter "emailto = "address" where "address" is recepient to receive the reports. Example:

  severity = $(SIG_HI)

  becomes

  severity = $(SIG_HI),

  emailto = your email address

  Unfortunately the tripwire documentation does not correctly tell you how to add multiple recepients so if you want them then the easiest way to do it is to modify the '/etc/mail/aliases' file and create a distribution list (be sure to type 'newaliases' if you do this).
  

• Next run the installation script:

  /etc/tripwire/twinstall.sh

  This will set up the encrypted config and policy files to prevent unauthorized access to the tripwire database.

• If you modify the twpol.txt file you will have to rebuild the security file. To do so type

  twadmin -m P /etc/tripwire/twpol.txt
  

• Next have tripwire build the database of system files. This takes several minutes:

  tripwire -m i -v
  

• Next use cron to schedule tripwire to scan the system weekly for modified files. Type 'crontab -e' and make the following entry (unless you changed it the default editor is vi):

  0 0 * * 7 tripwire -m c -M

  This will cause tripwire to run midnight each saturday to check the database and email a report to the users specified in the twpol.txt file. More info is available on tripwire by typing 'man tripwire'. You will very likely need to modify the twpol.txt file.

Check for running Network Services

Type the following two commands to check for running network services:

• netstat -a | grep -i listen
• lsof -i

Check the output YOU are responsible for this machine and the services it offers.

Have the system scanned for security vulnerabilities

The system should not be permanently attached to the LAN or put into production until it has passed a security scan

NEWS CONTENTS

• 20130417 : Lynis ( Lynis, Apr 17, 2013 )
• 20130417 : Linux system auditing by example by Emily Ratliff ( Linux system auditing by example, )
• 20130417 : GURU GUIDANCE / Hardening Linux Systems by Æleen Frisch ( )

Old News ;-)

[Apr 17, 2013] Lynis

Lynis is an auditing tool for Unix (specialists). It scans the system and available software, to detect security issues. Beside security related information it will also scan for general system information, installed packages and configuration mistakes.

This software aims in assisting automated auditing, software patch management, vulnerability and malware scanning of Unix based systems. It can be run without prior installation, so inclusion on read only storage is no problem (USB stick, cd/dvd).

Lynis assists auditors in performing Basel II, GLBA, HIPAA, PCI DSS and SOX (Sarbanes-Oxley) compliance audits.

Linux system auditing by example by Emily Ratliff

A case study in scripting for system audit compliance

30 Apr 2007

Think you have a secure Linux® system? Following best practices during installation and setup is a must, but if you haven't set up regular system auditing, you're missing half the picture. This article discusses some existing tools and offers a couple of sample scripts to automate the process in a real-world environment.

Many articles and books have been written on how to install a secure Linux system. But once the system has been installed to meet security requirements, only half the battle is won. The second half involves ensuring that the system continues to meet its security requirements throughout its lifetime (and that you can prove it). This means that periodic system auditing is required to make sure that nothing goes wrong.

System audit requirements

The security requirements that you verify during routine system auditing should be the same requirements and security principles that guide the system installation. The three-part developerWorks series "Securing Linux" gives you an introduction on how to install a reasonably secure Linux system. Regular system auditing will also help refine the security policy used for new machine installations as it helps close the feedback loop on what subsystems are actually in use.

The first tools for meeting these requirements are system auditing and host-based intrusion detection. This article focuses on system auditing. Host-based intrusion detection systems such as tripwire, AIDE, and Samhain detect when changes have been made to the file system and are therefore critical tools for ensuring that the system retains its known state. The Linux Gazette has an interesting article, "Constructive Paranoia," on using these tools (see Resources section below for a link).

This article focuses specifically on the practical aspects of periodic system auditing based on real-world requirements from a system administrator of a subnet in a large academic network. The lessons learned by this administrator apply to everyone from business intranets to home users who want to prevent their home machine from becoming a zombie in the bot army. The administrator's system is required to undergo periodic, random system audits, during which routine audit activities (such as showing that the audit and system logs are regularly reviewed, and checking for user accounts that have lapsed), In addition, the administrator also has to address the following:

• Justification for suid/sgid executables that are on the system and why they are suid/sgid
• Proof that no file system with a world writable directory (/tmp and /var/tmp) has any suid/sgid files
• Open ports and the impact of firewalling off of those ports

What are all those suid files for?

Identifying the suid and sgid files on your system - and disabling the unnecessary ones - is one of the fundamental rules of installing a secure system. This task is so common that the man page for find lists the parameters for this in its examples. Listing 1 is a script that executes the typical find command and also helps answer the question of what the suid file does and what package it belongs to, in order to help the administrator to identify it, and decide if it should stay on the system or be removed. (You can download the code for Listings 1, 3, and 4 from the zip file in the Download section later in this article.)

Listing 1. Abbreviated sample output on suid/sgid files

[root@localhost hpc]# ./find_setuids.pl / 04755 root /usr/X11R6/bin/cardinfo cardinfo - PCMCIA card monitor and control utility for X pcmcia-cardinfo-3.2.7-107.3 04755 root /usr/bin/opiepasswd opiepasswd - Change or set a user's password for the OPIE authentication system. Opie-2.4-544.1 04755 root /usr/bin/opiesu opiesu - Replacement su(1) program that uses OPIE challenges opie-2.4-544.1 04755 root /usr/bin/sudo sudo - execute a command as another user sudo-1.6.7p5-117.4

Which file systems contain world writable directories?

As an administrator, you might be interested in world writable directories to meet the requirement that all user-writable file systems be mounted with the nosuid attribute. User-writable directories include users' home directories as well as any world writable directories. This requirement is in place to prevent users from creating suid executables that another user or administrator might inadvertently execute. However, if a legitimate suid executable is on the same file system as a world writable directory and is thus mounted nosuid, the suid bits are ignored and the executable will not operate correctly. You might consider implementing this restriction on your multi-user systems as well.

The script in Listing 1 also tests each regular file system for world writable directories and reports whether the file system contains a world writable directory at the end of the output. For each suid/sgid file, it also reports whether the file is on a filesystem that contains world writable directories.

Abbreviated example output on world writable directories:
/ Contains both suid/sgid files and world writable directories.

What network ports does the system use and for what purpose?

There are several ways to detect which ports are in use on your system. Nmap, netstat, and lsof are the most helpful tools.

• Nmap is an extremely flexible tool that can do active and passive scanning of remote (and local) systems.
• Netstat shows the network information about the local system. By default, it shows open connections.
• Lsof lists open files on the system. It can be used to get information about port usage because it also shows information about network sockets.

Kurt Seifried maintains a listing of 8,457 commonly used ports. (A link to his ports list is in the Resources below.) You can use this data to help explain what the port is being used for and what the impact would be of firewalling it off. He includes information about ports that are commonly used for trojans and root kits; for example, 31337 is commonly used by Back Orifice and 12345, 12346, and 20034 are used by netbus.

Listing 2 contains a script that uses lsof and netstat to show the system's current port usage in an easily readable format.

Listing 2. Sample output from port_scan.sh:

[root@localhost hpc]# ./port_scan.sh please wait... PORT SERVICE LINK 22 sshd http://www.seifried.org/security/ports/0/22.html 25 sendmail http://www.seifried.org/security/ports/0/25.html 123 ntpd http://www.seifried.org/security/ports/0/123.html 631 cupsd http://www.seifried.org/security/ports/0/631.html 46336 <-> 22 ssh **

In Listing 2, the low-number ports (<1024) indicate daemons running on the system that accept incoming communication unless firewalled off. The high-number port 46336 shows an outgoing ssh connection and the port (22) that it is connected to on the other end. This means that blocking outbound communication on ephemeral ports will break commonly used client programs such as ssh. See Kurt's ports list in Resources for more details on the effects of firewalling the higher-number ports.

These scripts and tools show port usage at a point in time. The audit subsystem can be used to find out which ports have been used (for the duration of the audit log files) even if they are not currently in use. Adding the following audit rule to /etc/audit.rules will log calls to bind.

-a entry,always -S socketcall -F a0=2

The parameter -a entry,always indicates that the rule should always be invoked at the beginning of the system call execution. The -S socketcall indicates that this audit rule is for the socketcall syscall. The socketcall syscall is multiplexed on the i386 architecture, so the -F a0=2 is required to limit the audit records generated to bind only.

Other architectures handle the bind system call differently, so these commands and scripts will have to be altered slightly to handle architectures other than i386. Audit events are recorded as multiple audit records that are correlated by a shared serial number. ausearch will correlate the related records using the serial number and present them as a group. The -i flag requests that numeric values, indicating, for example, that saddr (IP address) and uid (user name) be translated to human readable text when possible.

Listing 3. Abbreviated output from ausearch

                
# ausearch -i -sc socketcall
Abbreviated example output
----
type=SOCKETCALL msg=audit(11/20/2006 11:28:43.844:10) : nargs=3 a0=0
a1=b8004004 a2=10
type=SOCKADDR msg=audit(11/20/2006 11:28:43.844:10) : saddr=inet
host:127.0.0.1 serv:631
type=SYSCALL msg=audit(11/20/2006 11:28:43.844:10) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bfffaca0 a2=b8000664
a3=1 items=0 pid=3340 auid=unknown(4294967295) uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=cupsd
exe=/usr/sbin/cupsd
----
type=SOCKETCALL msg=audit(11/20/2006 16:40:46.169:16) : nargs=3 a0=6
a1=b8056720 a2=10
type=SOCKADDR msg=audit(11/20/2006 16:40:46.169:16) : saddr=inet
host:192.0.34.166 serv:123
type=SYSCALL msg=audit(11/20/2006 16:40:46.169:16) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bffff9a0 a2=b80004a8
a3=6 items=0 pid=3523 auid=unknown(4294967295) uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=ntpd
exe=/usr/sbin/ntpd

This output shows that each call to bind generated three audit records. The first record type is the SOCKETCALL record, which shows the number and value of the arguments passed to bind on entry. The second record type is the SOCKADDR record, which shows the host by IP address and the port used. The third record type is the SYSCALL record, which shows whether the call to bind was successful, the arguments upon exit, gives the process ID, file executed, and shows the effective and real user and group information of the process that made the call. For our purposes, we are interested mostly in the serv: part of the SOCKADDR record, which documents the port used and the exe= field of the SYSCALL record, which documents the program that made the call to bind.

Listing 4 contains a simple script using sed and awk to compress the output of ausearch down to only the non-duplicated (time omitted) executable and port number fields.

Listing 4. Sample output from auportprint.sh:

[root@localhost hpc]# ./auportprint.sh 22 /usr/sbin/sshd 123 /usr/sbin/ntpd 123 /usr/sbin/ntpdate 631 /usr/sbin/cupsd

This article introduced some tools and techniques that can help you maintain your system's adherence to its security policy. It also gave you some simple scripts to help parse system data into an easily readable format that can help you prove the security status of the system quickly and easily to anyone less familiar with the tools and system. I hope that you can use these simple tools and techniques to create your own scripts to periodically test the security stance of your systems.

Acknowledgments

Many thanks to Kylene Hall, Dustin Kirkland, Flavio Ivan da Silva, Rodrigo Rubira Branco, and Flavio C. Buccianti for their code, suggestions, and hard work on this article.

Download

Description	Name	Size	Download method
Code for Listings 1, 3, and 4 in this article	hpc.zip	4KB	HTTP

Resources

Learn

• The article "Practical Linux Security" (developerWorks, Oct 2002) describes secure policies for sensible account management.

• The three-part developerWorks series "Securing Linux" outlines some security basics. Part 1 defines what it means to be secure, Part 2 lays the groundwork for a secure setup, and Part 3 explains strategies to harden your system to keep it safe from attack.

• The Linux Gazette article Constructive Paranoia at the End of 2003 describes lessons learned from the security incidents of November 2003.

• Kurt Seifried maintains lists of TCP-IP, UDP-IP, TCP, and UDP ports. He also wrote an excellent introduction to network security.

• Find more on NMap at Insecure.org.

• For additional information, see A Look at Systems-level Auditing under Linux by Timothy R. Chavez (in PDF format).

• In the developerWorks Linux zone, find more resources for Linux developers.

• Stay current with developerWorks technical events and Webcasts.

Get products and technologies

• Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.

• With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.

About the author

Emily Ratliff works in the IBM Linux Technology Center on Linux security. She has worked on multiple Common Criteria evaluations, Trusted Computing, Kerberos, and Enterprise Identity Mapping, among other projects. Emily's ultimate goal is to protect her unattended workstation from her toddler's random (and surprisingly successful) attacks.

GURU GUIDANCE / Hardening Linux Systems by Æleen Frisch

System security is always a trade-off between convenience and features on the one hand and protectiveness and removing unnecessary risks on the other. As the cliché goes, security is inversely proportional to convenience: the easier a system is to use, the less secure it's likely to be. In contrast to many discussions in this column, this month we turn our attention to the "secure if inconvenient" end of the spectrum.

As installed in "normal" mode from most current distributions, Linux tends to be a feature-rich yet very insecure operating system. For example, some distributions install an active Web server by default. While this is very convenient -- the system can start serving files almost immediately and Web-based administrative tools will work right away -- it also exposes the system to many sorts of security threats. If a very secure system is your goal, then there's still a lot of work to be done.

Hard Target

The process of modifying a system to make it highly secure is known as hardening. This month, we'll begin considering how to harden Linux for an environment with high security requirements (for example, a system functioning as a firewall). Every step we discuss may not be necessary for every system (or site), but knowing about all of them will enable you to apply the ones that are relevant to you. Furthermore, we'll perform the entire hardening process manually to gain the most insight.

Be aware that the order of activities in this discussion is not rigorous, and actual task ordering would need to considered carefully prior to making any changes to a system.

We will consider the hardening steps in groups of related activities: preliminary planning and preparation (what to do before you get started); securing the physical system (restricting physical access to the system and its components); installation (installing Linux and system software, including all security patches); securing services and daemons (configuring daemons to reduce security risks); securing local file systems (assigning appropriate permissions and removing insecure items); restricting root access (limiting root access to the system console and a small group of administrators); configuring user authentication, including remote access (specifying how users must authenticate themselves when they log in); setting up remote access (specifying user authentication from remote systems as well as other network-based access control); setting up ongoing system monitoring (these facilities allow you to detect any unauthorized changes to the system); and additional activities needed to complete the hardening process.

Before we begin, there are two important points to remember:

• Hardening activities must be performed before the system is placed on the network. Why? Because any system attached to a network prior to hardening has a chance, however small, of already being modified. You must begin the hardening process from a known, good system state. You must reinstall the operating system before you harden an existing system.
• Successful hardening is based on a least-privilege security model. The system should be open only as much as is needed to function properly. Similarly, users should be given the minimum amount of access that they need.

If you'd like a checklist for the process described in this column, see http://www.linuxmagazine.com/2002-09/harden_list.htm.

Preliminary Planning and Preparation

As with any major undertaking, it's only common sense to plan what will be done before modifying the system. You may also find it helpful to rehearse your particular hardening process before applying it to production systems. Doing so will enable you to test your actions and verify that they have the results that you intend. Rehearsing may also allow you to identify and address any unexpected side effects of the actions you are taking.

Here are some of the decisions to make before you begin to modify your system:

• Decide how you will partition the disks on the system, and where various file systems will be located. File systems provide natural security boundaries that you can take advantage of. On a secure system, isolate operating system files from all user files by placing them on separate file systems.
• Decide what software will run on the system. This will, of course, be determined in large part by the system function (e.g., a DNS server will need to run named). You will also need to be aware of the relevant software dependencies (e.g., an NFS server must run the portmap daemon).
• If appropriate, plan the system's user account and group structure. Create groups when you need to grant access to a system resource to multiple users.

Another important preparatory task is to acquire and gather together all of the things that you'll need to install and configure the system. These include any software packages you typically install at your site, the media for the Linux distribution, and all of the security patches released since the media was created (in most cases your Linux vendor will offer such patches from their web site). However, it's also helpful to check an independent source of security vulnerabilities like CERT (http://www.cert.org/nav/index_red.html) for a list of recently discovered security problems.

Finally, it is important to take notes as you go, documenting the hardening process. Notes will be helpful for you in the future (you'll know exactly what you did) and for refining the process for other systems.

Documentation can also allow other system administrators to understand the system's configuration and apply the hardening process to other systems.

Secure the Physical System

When you're ready to proceed with the hardening process, the first thing to decide is where the system will physically live. In general, important and sensitive systems should not be placed in publicly accessible places because any one with physical access to the system will be able to compromise it.

For example, access to the system's CDROM (or even floppy) drive may allow someone to boot an operating system of his choosing and then freely examine the system's hard disks (more on this in a minute). In addition, an accessible system can be stolen, a risk that may be unacceptable when there is sensitive or valuable data on the system. Finally, systems that are accessible are also vulnerable to vandalism, and damaged servers can't fulfill their functions.

You may also need to consider these issues related to the system's physical security:

• Ideally, the system will be protected with a locked door. However, cheap locks are not much better than no locks when theft is a risk. In addition, locks are not sufficient when there are other ways of getting into the area (like windows). Don't forget to secure network devices and cabling. Accessible network cables are vulnerable to tapping and eavesdropping.
• Select a location where the risks of accidental damage to the system is minimal (e.g., no overhead sprinkler systems).
• Install an uninterruptible power supply for the system, if appropriate.

Once the system is set up, the next thing to do is to assign a BIOS password to it. This will prevent unauthorized people from changing the computer's BIOS settings. After the operating system is installed, you'll need to remember to modify the set up to disallow booting from the CD-ROM and floppy drives.

Install the Operating System

The next steps involve installing the Linux operating system and the rest of the required software. It's much easier to harden a system when you've installed the operating system yourself because you know exactly what it includes.

One recommended practice is to install a minimal operating system configuration, the minimum necessary to boot the system. Then, go on to install the additional packages you need from the installation media. This practice results in a final installation that has only the items that you really need. The logic behind this is that intruders can't exploit security holes in software that's not installed.

Next, you'll need to apply all of the security patches that you've gathered together. In addition, upgrade any packages where newer versions close security holes. Once you have configured, updated, and built all the required packages, backup the source code, and then remove it from the system.

Once the software is installed, the next step is to build a custom kernel for the system. Your custom kernel should disable any feature that's not needed (once again, intruders can't take advantage of features that aren't there). For example, for systems that are not operating as routers, you should remove IP forwarding capabilities.

Figure One shows some of the items you might want to consider disabling when you're not using the corresponding device types or features (listed as they are described in the make xconfig utility):

Figure One: Kernel features that you might want to disable

Code maturity level options

• Prompt for development and/or incomplete code/drivers = n

General setup

• process accounting = y (needed for system monitoring)
• support for a.out binaries = n

Binary emulations of other systems

• all items that you are not using to n

Block devices

• port IDE device support = n

Networking options

• IP: multicasting, IP: advanced router and Wan router to n.
• Set all unused protocols to n: IPX, Appletalk, Decnet, all experimental protocols

Network device support

• PLIP, PPP, and SLIP to n

IrDA (infrared) support

• the main item to n if you're not using the IR port.

File systems

• Set all unused file system types to n. Likely candidates include: ADFS, Amiga FFS, BFS, UMSDOC, EFS, JFFS, JFS, NTFS, OS/2, QNX2.

File systems -- Network file systems

• all unused types to n: Coda, NFS, SMB, NCP
• If you're using NFS, enable NFSv3 support, and enable server support only if the system will export file systems.

Kernel hacking

• debugging = n

Once you've configured the new kernel, build and install it and all associated modules. Boot the new kernel and make sure that it has all the functionality you need. Backup the default installed kernel and modules (save /boot and /lib/modules), and then remove them.

Similarly, backup the kernel source code directory (conventionally /usr/src/linux) and then remove it.

The final steps in this group involve configuring the system boot process:

• Configure the boot loader (LILO or Grub) for automatic booting, disallowing any boot time user intervention. The boot loader should also be configured to require a password. For LILO, this would mean removing the prompt keyword and using the password keyword within the lilo.conf configuration file (conventionally located in /etc). For Grub, you would use the hiddenmenu, default 0 and password keywords within the Grub configuration file (usually, /boot/grub/grub/conf).
• Require the root password to be entered when entering single user mode by adding the following line to /etc/inittab: sp:S:respawn:/sbin/sulogin
• You may also want to disable the ctrlaltdel inittab entry (just comment the line out with #)to prevent that key combination from ever triggering a reboot.

That's all for this month. Next month, we'll continue our look at system hardening by considering ways of securing the many daemons that are present on Linux systems.

---

Æleen Frisch is the author of Essential System Administration. She can be reached at [email protected].

Hardening, Part 2: Securing Services

This month we continue our look at the steps required to harden a Linux system by considering how Linux services can be secured. In fact, securing system services -- subsystems like printing and electronic mail, file and web serving, and remote access (telnet, ftp, rlogin, rsh, imap, and so on) -- represents a large part of the hardening task.

In general, the guiding principle of securing system services is install only those packages that the system actually needs. As we noted last month, potential intruders can't exploit software that isn't present on the system. When removing a package isn't possible or practical, then unneeded services should be disabled.

The following list represents the general tasks associated with securing system services:

• Disable or remove all unneeded services.
• Specify logging and access control for all services, allowing only the minimum access necessary.
• When appropriate, use chroot to run a service in a confined directory.
• If at all possible, create a special user to run server processes. For example, run named as user named.
• Use secure versions of daemons when they are available.
• Restrict access to facilities services like cron to system administrators.
• If a server lets you limit the number of daemon processes, specify a limit. Setting limits can help prevent some denial of service attacks.
• Finally, be sure to secure all services, whether they seem security-related or not (e.g., printing).

Locating and Disabling Linux Services

Before you disable unnecessary services -- or even decide which ones to keep -- you have to find them all. System daemons are started mostly during the boot process and are started from many different locations, including the following:

• From /etc/inittab: some daemons are started directly by init at boot time.
• By one of the boot scripts in /etc/init.d: these scripts are run at boot time when they are linked to the appropriate /etc/rcN.d subdirectory, where N indicates the run level.
• By the super network daemon, inetd or xinetd: some daemons are started on demand, when a client requests their services.
• Periodically, using the cron scheduler: daemons can be started via crontab entries.
• Manually: the system administrator can also start daemons and whole subsystems by entering commands by hand.

The method required to disable a service depends on how the service was started. Let's look at each of the possibilities individually.

Reviewing /etc/inittab

/etc/inittab file is the configuration file used by the init daemon. At boot time, init reads the entries in the file and starts a process according to each description. The same process occurs whenever the system changes run levels.

On Linux systems, it is somewhat unusual for system daemons to be started from this file, but they can be. For example, the following inittab entry runs the script /etc/start_acct, which starts the process accounting subsystem:

acct:35:once:/etc/start_acct 

The fields in the inittab entry are (in order) the entry's label, the run levels to which it applies, a mode keyword, and the command to execute, along with any arguments.

You should understand the purpose and effect of all of the inittab entries on your system. To disable a service started via inittab, simply delete the line or comment it out by placing a number sign (#) at the beginning of the line.

Boot Scripts

Most system services are started by a system boot script located in /etc/init.d. Generally, each script is limited to controlling (starting or stopping) a single service or subsystem.

To make one of these scripts run during the boot process, the script must be linked to one of the directories in /etc/rc.d named rcN.d, where N is the run level number. For example, /etc/rc.d/rc3.d contains the scripts that run when the system enters run level 3. The links in these run level-specific subdirectories have names of the form XMMname, where X is either K or S, MM is a two digit number, that determines the order in which scripts are run, and name is generally the name of the script in /etc/init.d to which this file is linked. K-files are used to stop services when entering a run level; S-files are used to start them (the scripts are passed the parameters stop and start, respectively).

Here is a small portion of the directory listing from the directory /etc/rc.d/rc5.d illustrating these links:

$ cd /etc/rc.d/rc5.d; ls -l ??[0-9]r*
lrwxrwxrwx  K46radvd -> ../init.d/radvd*
lrwxrwxrwx  K55routed -> ../init.d/routed*
lrwxrwxrwx  S20random -> ../init.d/random*
lrwxrwxrwx  S97rhnsd -> ../init.d/rhnsd*

This listing shows links to the files in /etc/init.d whose names start with "r." There are two K-files and two S-files.

If you want to disable a service that is started via a boot script, then you have two choices:

• You can remove all of the links to the corresponding file(s) in /etc/init.d. If you choose this method, then be sure to identify all of the files that are used for that service (some services like NFS use more than one script), and then remove the associated links in every rcN.d subdirectory.
• You can replace the existing script with a dummy version. This method has the advantage that you can easily reactivate the service later if necessary. For example, to disable the LDAP service, you could use the following commands:

# cd /etc/init.d
# ./ldap stop
# mv ldap ldap.save
# echo > ldap
#!/bin/bash
exit 0
^D
# chmod 755 ldap

First, we stop the LDAP servers if they are currently running. The remaining commands save the existing script under another name and replace it with a dummy script.

Configuring inetd and xinetd

There is another class of network services present on Linux systems: ones that are invoked on demand when a client requests their services. The daemons associated with these services are controlled by the inetd (or xinetd) "super" daemon.

inetd is responsible for starting daemons when their services are needed (inetd itself is started at boot time by a boot script in /etc/init.d). The list of daemons managed by inetd include many common user-level network services, including telnet, ftp, remote login and shells, mail retrieval, and the like.

Traditionally, inetd is configured via the file /etc/inetd.conf. Entries for most common services are typically included by default in the version of this file installed with the operating system. Some add-on services also add entries to the file (e.g., Samba). Occasionally, you may need to add entries manually for a new service that you install.

Disabling entries in /etc/inetd.conf is very easy: simply add a number sign (#) to the beginning of the line corresponding to the daemon you want to disable. Whenever you modify this file, you must send the HUP signal to the inetd process in order for it to take effect:

# kill -HUP `cat /var/run/inetd.pid`

Recent Red Hat Linux versions and many other distributions have switched from the standard inetd facility to a new one called xinetd. xinetd performs a similar function, but is configured differently. Each subordinate daemon has a separate configuration file in /etc/xinetd.d, and each file is named for the daemon it corresponds to. Here is a simple example file, /etc/xinetd.d/rlogin:

service rlogin
{
   socket_type       = stream
   protocol          = tcp
   wait              = no
   user              = root
   server            = /usr/sbin/in.rlogind
   server_args       = -l
   disable           = yes
}

The various attributes correspond to the fields in traditional /etc/inetd.conf entries. The final attribute, disable, controls whether the daemon is active or not. In this case, the rlogin service is disabled.

Obviously, disabling a subdaemon under xinetd's control is done by setting the disable attribute to yes in the appropriate configuration file.

Disabling or Removing Services

You should examine the systems that you administer carefully and be sure that you know what's running on them. Unfortunately, Linux distributions often install and enable a variety of unneeded services. Table One includes services that you might consider disabling or removing when they're not needed. Note that this list is not comprehensive and that there is no substitute for examining your own systems.

Table One: Services you may not need IN /ETC/INITTAB: Comment out or remove entries for getty processes for terminal lines which will not be used. DAEMONS STARTED BY BOOT SCRIPTS (WITH TYPICAL SCRIPT NAMES): NFS automounter (and NFS itself if it's not used): autofs, nfs, nfsserver, nfslock. Unused standard networking servers, for example: routed, gated, ratvd, snmpd, named, dhcpd, dhclient, dhrelay, nscd, smb. Unneeded mail transport services: sendmail, postfix. Unused optional local and network facilities: atd, ldap, kudzu, rhnsd, vncserver, ypbind, quota, quotad, apache, mysql, hylafax, netsaint (and dozens more). Unneeded printing facililites: lpr, lprng, cups. SUBDAEMONS OF INETD/XINETD: User remote access: rlogind, rshd, telnetd, ftpd, tftpd, rexecd, rexd, talkd, ntalkd, fingerd, and so on. TCP/IP connectivity testing services: echo, daytime, chargen, discard, time. Unused mail retrieval protocols: imap,pop2, pop3, etc.

Note that many recent Linux systems disable all inetd/xinetd subdaemons by default. At present, this is considered a "best practice".

Restricting Access to Services

Once you've removed or disabled unneeded services, the next step is securing the ones that will run.

ACCESS CONTROL FOR INETD AND XINETD

Let's look again at a sample entry from /etc/inetd.conf:

#service socket proto wait? user prog args
imap stream tcp nowait root /usr/sbin/tcpd/usr/sbin/imapd

On most Linux systems, inetd is set up to use Wietse Venema's TCP Wrappers package. When TCP Wrappers is in use, the tcpd program replaces the native program for each inetd service (the sixth field in each configuration file entry). The actual service daemon is given as tcpd's argument, and any arguments to the service daemon itself follow the image name.

TCP Wrappers provides two important additions to the standard inetd functionality: access control and logging. ItautomaticaTCP Wrappersy logs access failure to the syslog daemon facility.

Using TCP Wrappers, the files /etc/hosts.allow and /etc/hosts.deny control access to the various daemons under inetd's control, according to the following logic:

• If an entry in hosts.allow grants access, then the request is honored. The first applicable line in /etc/hosts.allow is used.
• When no line in hosts.allow applies, hosts.deny is checked next. If any entry within it denies access, then the request is denied. Again, the first applicable entry is used.
• In all other cases, the request is granted.

Here are some sample entries from hosts.allow:

rlogin : ophelia hamlet laertes yorick  
pop3 : .ahania.com EXCEPT mailhost.ahania.com 
ftpd : 192.168.4 192.168.10

The first entry grants access to the rlogin service to users on any of the listed hosts (hostnames may be separated by commas and or spaces). The second entry allows email retrieval via POP3 by users from any host in the domain ahania.com except mailhost. The third entry allows ftp access to all hosts on the subnets 192.168.4 and 192.168.10.

Here is a simple /etc/hosts.deny file:

ALL : ALL :

The sole entry in this file prevents all access that has not been explicitly permitted in hosts.allow. Using such an entry as the final line in this file is strongly recommended.

xinetd subdaemons are generally secured in a different way (although TCP Wrappers may also be used in combination with xinetd). Here is a sample entry for the imapd daemon which illustrates xinetd access control:

service imap
{
   user           = root
   server         = /usr/sbin/imapd
   only_from      = 192.168.10.0 localhost
   no_access      = dalton.ahania.com
   access_times   = 07:00-20:00
}

The only_from attribute specifies the hosts that are allowed to use this service; requests from any remote host not on the specified subnet will be refused. The no_access attribute performs the opposite function and denies access to the specified host(s). Finally, the access_times attribute specifies when the service is available to users who are allowed to use it.

xinetd also provides excellent logging facilities, which should be used. Logging is often specified in the facility's main configuration file, /etc/xinetd.conf, as in this example from Red Hat:

defaults
{
   log_type        = SYSLOG authpriv
   log_on_success  = HOST PID
   log_on_failure  = HOST
}

These entries specify that success and failure will be logged to the syslog authpriv facility. Successes will log the remote hostname and process ID, and failures will log the remote hostname. You can add additional logging items for a specific service by including an entry like this one within its individual configuration file:

log_on_success          += USERID

This entry adds the user ID to the log entry for successful connections.

USING CHROOT AND SANDBOXING

Isolating potentially dangerous services from the rest of the system is one way to minimize risks. The chroot command is used for this purpose.

chroot runs a command using a specified location within the file system as the command's root directory (rather than /). For example, the following command runs the named daemon, using the directory /jail as its root directory:

# chroot /jail named

The named process will treat /jail as its root directory. For example, when named looks for its main configuration file, usually /etc/named.conf, it will actually access the file /jail/etc/named.conf. (Note that recent versions of named have a -t option which can be used to specify an alternate root location directly, without needing chroot.)

In order for named to function correctly, you will need to set up a minimal file system under /jail that contains the files and directories that named will need: /etc/named.conf and the zone files, the named executable and any required libraries (you can link named statically when you build it to avoid the latter), the password and group files, and the device files null and random. The latter must be created with the mknod command:

# mknod /jail/dev/null c 1 3
# mknod /jail/dev/random c 1 8

Running a daemon or subsystem as a user specifically created for that purpose (rather than root) is sometimes called sandboxing, and it's best to use this security technique wherever you can. You can combine sandboxing and chroot for added security.

For example, you can create a special user and group to run the named daemon (the user and group are often also called named). Then, use the named command's -u option to start the server running as the specified user. Under this scheme, you will also need to change the ownership of the named directory tree to this user and group.

Many facilities have a built-in ability to specify a user other than root as the user context for the daemon process. You can manually configure ones that don't by creating a special user, changing the ownership of important commands and files to that user, and granting that user access to any required system resources. It may take some trial and error to sort out all the details, but most daemons can be secured in this way.

Other Service Configuration Issues

We'll close this column with a few miscellaneous service security issues.

Some packages provide ways of limiting access to the services as a whole (e.g., cron) or to administrative functions (e.g., LPRng). For example, the files cron.allow and cron.deny control access to the crontab command. The location of these files varies: for Red Hat, they're in /etc; for SuSE, they're in /var/spool/cron.

Both files contain a list of user names, one per line, which determine access to crontab. If cron.allow exists, then a username must be listed in it to run crontab. If cron.allow does not exist but cron.deny does exist, then any user not listed in cron.deny may use the crontab command. cron.deny may be empty to allow unlimited access. Finally, if neither file exists, then anyone can use crontab. Be aware that these files control only whether a user can use the crontab command, and not whether any existing crontab entries will be executed.

Some services provide both normal and secure daemons. When a secure service option is available, the service should be configured to use it.

Next month, we'll conlude our look at hardening Linux systems and examine techniques for securing local file systems, user authentication, remote system access, and ongoing system monitoring.

---

Æleen Frisch is the author of Essential System Administration. She can be reached at [email protected].

Recommended Links

BASTILLE-LINUX

Center for Internet Security - Standards

Benchmarks

Red Hat Linux	1.0.5	11/02/2006
SUSE Linux	1.0	03/17/2006
Slackware Linux	1.1	06/16/2006

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019