ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Securing the Linux operating system
This lesson contains the following topics:

"Installing and Patching"

"Minimizing the Installation"

"Disabling System Services"

"Verifying Integrity"

"Securing the Console and Front Panel"

"Configuring the File System"

"Managing Accounts"

"Monitoring System Activity"

"References and Related Resources"

"About the Authors"

"Ordering Sun Documents"

"Accessing Sun Documentation Online"
This lesson is the first part of a two-part series that provides recommendations for securing the Linux
operating system. This part provides recommendations for securing local access and file systems. Part II
provides recommendations for securing network access and services. The information in this lesson
applies to most Red Hat/RPN and Sun based Linux distributions, although most techniques and
recommendations should apply to other Linux distributions.
It is important to address security for local access and file systems. Often, administrators are solely
concerned with protecting a system from remote threats. We recommend that you have equal concern for
local, authorized users who can exercise a weak configuration, either inadvertently or maliciously, and
gain unauthorized privileges on a system. We highly recommend a layered approach to security where
protection is implemented for both local and remote threats, resulting in a more robust security
configuration.
Sun Linux is based on the Red Hat Linux distribution and is a flexible, general purpose operating system.
To secure a Sun Linux system against unauthorized access and modification requires changes to its default
configuration. Although these changes are in most cases relatively minor, we strongly recommend that
you make these changes to improve the security posture of a system. The changes and recommendations
in both lessons address the majority of methods that intruders use to gain unauthorized or privileged
access to Sun Linux systems. You should implement these changes immediately after system installation.
As with most security strategies, you must achieve a balance between system manageability and security.
Some recommendations in this lesson might not apply to your environment and might negatively impact
your ability to manage a system. You must know your system and security requirements before starting.
Implementing the changes recommended in this lesson requires planning, testing, and documentation.
Securing the Linux OS
Page 1 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Installing and Patching
All Linux operating systems need several updates and patches. These updates typically include security
improvements as well as enhancements related to reliability, performance, and manageability. When
building a Linux system, be sure to use the latest software updates and patches to take advantage of
these improvements.
Install the System Securely
To prevent attackers from modifying a system or creating backdoors, do not attach the system to a public
network until you have installed security patches and completed security modifications. Attackers do not
need much time to exploit an unpatched out-of-the-box system.
Most Linux software distributions automates nearly every facet of the installation process. This benefit
makes each installation repeatable and less prone to error. A side effect of this process is that you may
not be able to select packages or clusters for installation or removal. However, after the installation is
completed, you can manually add or remove packages.
Apply Patches
Immediately after installing a Linux system, update it with all of the available security patches to help
prevent the exploit of known attacks. You can download the software updates and security patches for
Linux even if you do not have a service contract.
To identify which version of Sun Linux your system has, enter the following command.
# cat /etc/sun-release
Security patches are available in two forms:

Product Updates – Download these from http://sunsolve.sun.com/patches/linux. These updates
are clusters of patches that address issues related to reliability, availability, security, and system
management. These updates are typically downloaded and installed as a complete group.

Individual Security Patches – Download these from
http://sunsolve.sun.com/patches/linux/security.html. These patches address security issues in a
product, tool, or function. You can download these patches in either the Red Hat package
management (RPM) or Source RPM (SRPM) format. SRPMs are RPM files that contain the source
code for a program instead of its compiled code (stored in the RPM). In addition, an MD5
signature is on the site for each patch, so that you can verify the integrity of downloaded files.
We recommend this step to ensure that patches applied are only those provided by Sun.
NOTE: Apply only patches that are developed and released by Sun Microsystems, Inc.
Although the distribution is based on the Red Hat Linux distribution, patches released
by Red Hat should never be applied. Doing so might render the system unsupportable
by Sun.
Securing the Linux OS
Page 2 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
To verify that a patch was applied, use the rpm command. For example, to verify that the xinetd-2.3.7-
4.7x.i386.rpm package, available from the security patch web site, is installed, use the following
command.
# rpm -q -a | grep xinetd
xinetd-2.3.7-4.7x
If the rpm command does not return a match with the correct version, then download the patch from
Sun, and install it on the system as soon as possible. If the command returns no value, then the related
software package is not installed on the system and, therefore, the patch is unnecessary.
In addition to the Sun Linux security web site, Sun offers a security bulletin mailing list. This list is for
administrators who want to receive security bulletins directly from the Sun Security Coordination Team.
For more information on joining this list, email the Sun Security Coordination Team or submit a security
alert to the following Web site:
http://sunsolve.sun.com/pub-cgi/show.pl?target=security/sec
Receiving and acting upon these notifications in a timely manner is essential to sustaining a strong
security posture.
At this time, Sun does not provide an automated mechanism to ensure that a system is currently using the
most recent patches, security or otherwise. This process must be done manually to ensure that all
available and applicable patches are installed.
NOTE: You can use the Sun Cobalt Control Station to monitor and manage large deployments
of Sun LX50 systems. For example, you can use it to apply software updates. Using this
product might help simplify the patch management process for these sites. For more
information, refer to http://www.sun.com/hardware/serverappliances/controlstation.
As with any changes made to a system's configuration, always review the impact of the resulting changes
to ensure that the security posture of a system is not diminished. Ensure that previously disabled services
remain disabled after patches are applied. In addition, if possible, apply patches to non-production
systems first to identify the impact of the changes before implementing them on production systems.
Minimizing the Installation
It is important to reduce the Sun Linux installation down to the minimum number of packages necessary
to support the applications being hosted. This reduction in services, libraries, and applications helps
increase security by reducing the number of subsystems that must be disabled, patched, and maintained.
Sun Linux uses RPM to install, upgrade, and delete packages. Each package maintains a description, file
list, change log, checksum, and dependency information. Use this information to maintain and validate
Securing the Linux OS
Page 3 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
system integrity when adding, upgrading, or removing packages. To a limited degree, you can use the
information to validate a package, before or after you install it on a system.
To remove an RPM package that is no longer needed, use the -e option with the rpm command, as in the
following example:
# rpm -e minicom-2.00.0-3
# rpm -e glibc-2.2.5-42
error: removing these packages would break dependencies:
glibc-common = 2.2.5-42 is needed by glibc-2.2.5-42
In the example, the first package minicom-2.00.0-3 is successfully removed. The second package glibc-
common-2.2.5-42 is not removed, due to an unresolved package dependency.
CAUTION: When manipulating packages, take care to ensure that the RPM dependency tree is
not inadvertently corrupted. We strongly recommend that you avoid using the options --force,
--replacepkgs, --replacefiles and --oldpackage. Improper use of these options can cause the
RPM dependency database to reflect an inaccurate state of a system.
Disabling System Services
System services are started by the init system. Disable services that are not necessary to system
operation. For example, some services might allow a system to be compromised, due to incorrect
configuration. System services under the Sun Linux OS are controlled using the chkconfig command, which
you can use to list services available, then disable or enable them.
NOTE: The chkconfig command does not start or stop system service; it only enables or
disables it from running at boot time. If you disable a system service with chkconfig and do
not reboot the system, then you must stop the system service using the script in the
/etc/rc.d/init.d directory.
To list existing services and their states, use the following command:
# /sbin/chkconfig –list
To disable a system service, use the following command:
# /sbin/chkconfig --level 0123456 <service> off
To enable a system service, use the following command:
# /sbin/chkconfig --level 0123456 <service> on
Securing the Linux OS
Page 4 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
The previous example enables service for each of the system's seven run levels. Use only the number or
numbers corresponding to the run levels at which the service should run. For example, to enable a service
only for run level 5, then modify the --level option to include only the number 5.
For security purposes, only enable required services. The fewer services that are enabled, the less likely
it is that attackers can discover ways to exploit systems.
The packages installed determine what services are enabled by default. Removing unnecessary packages
disables some extraneous services. Examine the remaining services to determine their relevance to the
system and the hosted applications.
NOTE: Be aware that installing patches and/or software packages might restore or add new
entries for init to start. We recommend that you regularly review the services started by init.
In particular, check for new services or changes in the status of existing services after patches
or new software are installed on a system.
Verifying Integrity
After you install or upgrade a system, we strongly recommend that you verify the integrity of the Sun
Linux image. You can perform this task using the commands described in the previous section, but to
provide a higher degree of assurance, compare the packages on the system against a trusted source such
as the Sun Linux CD-ROM distribution.
It is possible to verify whether the files installed by RPM were modified after the installation by
comparing them with the original .rpm file. The following command compares the installed files with the
original xinetd package.
# rpm --verify -p xinetd-2.3.7-4.7x.i386.rpm
You can use a simple shell script to validate and report on the integrity of all of the RPM packages
installed on a system. This result is achieved by comparing the installed packages with their counterparts
from the installation or update media.
The following shell script is an example of how to generate a usable report.
# !/bin/sh
INSTALLED_RPMS="'rpm --query --all' | sort -u"
for pkg in 'ls /mnt/cdrom/RedHat/RPMS/*.rpm | sort -u'; do
short_pkg="'basename ${pkg} | sed 's/_386_pm//g''"
if [ 'echo ${INSTALLED_RPMS} | grep -wc ${short_pkg}' != 0 ]; then
rpm --quiet --verify --package ${pkg}
Securing the Linux OS
Page 5 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
if [ $? = 0 ]; then
result="SUCCESS"
else
result="FAILED"
fi
printf "Package Check: %-35s RESULT: %s\n" \
${short_pkg} ${result}
fi
done
NOTE: This verification method is most effective on newly installed or upgraded systems. For
systems or packages that have been patched, this method only works if the packages
signatures are tested against a patched, trusted copy of the package.
The following example illustrates how to verify packages against the package information stored in a
system's local RPM database. This check is similar to the pkgchk(1M) command in the Solaris OE.
# rpm -verify filesystem-2.1.6-2
# rpm -verify apache-1.3.23-11
S.5....T c /etc/rc.d/init.d/httpd
In the example, the integrity of the first package, filesystem-2.1.6-2, was successfully verified. The
check failed for the second package, apache-1.3.23-11, when the /etc/rc.d/init.d/httpd was found to
have been modified.
To verify all packages on a system, use the -a option in place of the package name.
# rpm -verify –a
This capability is not a substitute for functionality such as Tripwire. This information is used only by the
RPM framework to ensure that packages are completely installed, upgraded, or removed, and that all
package dependencies are properly met.
After you validate the integrity of a system, use products such as Tripwire to establish a baseline
database for detecting file integrity violations. The Sun Linux distribution includes the Tripwire Open
Source, Linux Edition, product originally developed by Tripwire, Inc. This tool provides data integrity
assurance through the collection and management of file signatures and related data. If configured
properly, this tool identifies when file system objects are changed. We recommend you consider products
such as Tripwire as part of an organization's overall platform security strategy.
NOTE: For more information on the Tripwire Open Source, Linux Edition product, refer to the
Web site http://www.tripwire.org/.
Securing the Linux OS
Page 6 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Other methods can provide a higher degree of assurance, but those methods are outside the scope of this
lesson. At this time, Sun does not provide a Sun Linux equivalent to the Solaris Fingerprint Database
software.
Securing the Console and Front Panel
The next task is to consider restricting access to a system's console. This task is useful if the server is
located in a common area of a network operations center.
NOTE: These tasks do not prevent attackers with physical access from compromising systems.
These methods provide incremental security, but caution must always be exercised when
physical access to a system and related hardware is permitted.
This section contains the following topics:

"Access and Modify BIOS Configuration"

"Restrict Access to BIOS"

"Limit Front Panel, Keyboard, and Video Access"

"Restrict Alternate Boot Devices"

"Restrict Access to the LILO Boot Loader"

"Disable Control-Alt-Delete Reboot Key Sequence"

"Require Single-User Mode Password"

"Disable the Magic SysRq Key"

"Restrict Root Access to Devices"
Access and Modify BIOS Configuration
The Sun Linux operating system is provided on the Sun LX50 system. The Sun LX50 system uses the
American Megatrends, Inc. (AMI) Basic Input and Output System (BIOS). The BIOS provides security
features that prevent unauthorized or accidental access to a system. When security measures are
enabled, administrators and users can access the system only when they enter correct passwords. You can
implement the following security measures:

Enable an administrator password, which is used to access and configure BIOS security options

Enable a user password, which can be granted full or limited access to BIOS

Enable secure mode, which prevents keyboard input, front panel reset access, and power switch
access.

Enable a keyboard lockout timer, which after a time-out period, requires a password to
reactivate keyboard input.

Disable booting to alternative devices, such as diskettes and CD-ROMs
Securing the Linux OS
Page 7 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
A system's BIOS performs power-on self-tests (POST), provides an interface to the hardware components
on a system, and facilitates loading an operating system by locating and accessing a boot loader. In
addition, the BIOS provides basic security features.
To access the BIOS configuration, press the F2 key while the initial boot screen is displayed on a console.
To maneuver the BIOS menu system, follow the instructions located at the bottom of the screen.
NOTE: If a BIOS administrative password is defined for the system, this password must first be
correctly entered before access to the BIOS configuration is granted.
If you change any of the BIOS configuration parameters, you must reboot the system for the changes to
take effect.
Restrict Access to BIOS
You can set a user password, an administrator password, or both. The passwords are limited to seven
alpha numeric, case-sensitive characters. By default, the passwords are not defined, and unrestricted
access is granted to the BIOS for any user with physical access to a console.
Setting a user or an administrator password requires:

Entering the password to enter BIOS setup.

Entering the password to boot the server if "Password on Boot" is enabled.

Entering the password to exit "Secure Mode."
Setting both passwords requires:

Entering the password to enter BIOS setup.
o
If entering a user password, the user may not be able to change some of the BIOS
options, depending upon privilege level granted.
o
If entering an administrator password, the administrator is able to enter BIOS setup and
access all options.

Entering either password to exit "Secure Mode."
CAUTION: With physical access to a system, BIOS passwords can be reset by changing
a jumper on the motherboard.
To Set an Administrator Password
1.
Enter the BIOS menu by pressing the F2 key while the system's initial boot screen is
displayed.
2.
Select the Security menu tab to display the security configuration menu.
3.
Select the Set Administrative Password option.
Securing the Linux OS
Page 8 of 47
ITSY243-Intrusion Detection Systems
4.
Enter the new administrative password.
5.
Re-enter the new administrative password to confirm the new password.
6.
Select the Exit menu tab, then select the Exit and Save option.
Prof. Michael P. Harris
Once set, the Administrative Password parameter changes from Disabled to Enabled. Now the
Administrative Password must be entered to access the BIOS configuration.
To Set a User Password
1.
Enter the BIOS menu by pressing the F2 key while the system's initial boot screen is
displayed.
2.
Select the Security menu tab to display the security configuration menu.
3.
Select the Set User Password option.
4.
Enter the new user password.
5.
Re-enter the new user password to confirm the new password.
6.
Select the privilege level granted to the user:
o
No Access – Prevents a user from accessing the BIOS configuration. If a user is assigned
to this level, the user password is used only to unlock the system when it is operating in
"Secure Mode."
o
Limited – Allows a user to access the BIOS and to change a limited number of noncritical fields.
o
View Only – Allows a user to access the BIOS but in read-only mode. The user is not
permitted to change any of the BIOS parameters.
o
Full – Allows a user to access the BIOS and change all parameters, except for the
Administrator Password.
7.
Select the Exit menu tab, then select the Exit and Save option.
Limit Front Panel, Keyboard, and Video Access
After setting the administrator password, limit access to the front panel, keyboard, and video. The
following additional options appear on the BIOS Security menu:

Secure Mode Timer – This timer is the period of inactivity in minutes before "Secure Mode" is
activated and the system's keyboard and mouse are locked.

Secure Mode Hot Key – This keyboard sequence places the system in "Secure Mode." By default,
the sequence is Control-Alt-[L], which is performed by holding down the Control and Alt keys and
simultaneously pressing the L key.

Secure Mode Boot – This setting configures the BIOS to prevent the system from starting the boot
process until a user or administrator password is entered. A password is required to boot from
removable media such as a diskette or CD-ROM.

Video Blanking – This setting disables the use of a video monitor when a system is in "Secure
Mode." When video blanking is off, the system displays information on the monitor even in
"Secure Mode." If a monitor is disabled in addition to the keyboard and mouse when in "Secure
Mode," video blanking should be enabled.
Securing the Linux OS
Page 9 of 47
ITSY243-Intrusion Detection Systems

Prof. Michael P. Harris
Disable Power Button – This setting configures the BIOS to ignore the use of the front-panel
power button. When enabled, this setting prevents a running system from being powered off
using the front-panel power button.
To Set Access Options
1.
Enter the BIOS menu by pressing the F2 key while the initial boot screen is displayed.
2.
Select the Security menu tab to display the security configuration menu.
3.
Select the appropriate option, and enable or disable it.
4.
Select the Exit menu tab, then select the Exit and Save option.
Restrict Alternate Boot Devices
You can use the Sun Linux BIOS configuration to specify the order in which devices are polled when
locating an operating system. This boot device priority selects the order in which hard-drives, CD-ROM
drives, and disk drives are accessed during boot processes. It is recommended that the system be
configured to boot first from the local hard drive before other media. This approach can prevent a system
from being compromised through a boot diskette or CD-ROM inserted during the boot process.
To Set Boot Device Priority
1.
Enter the BIOS menu by pressing the F2 key while the initial boot screen is displayed.
2.
Select the Server tab to display the server configuration menu.
3.
Select the Boot Priority menu to change the default boot priority.
4.
Select the hard drive as the first boot device.
5.
Disable any boot devices that are not required.
6.
Select the Exit menu tab, then select the Exit and Save option.
Restrict Access to the LILO Boot Loader
Sun Linux uses the LILO boot loader to load the Linux kernel. LILO allows users to pass parameters to the
kernel, several of which can be used to gain unrestricted access to a system (such as single for single-user
mode). You can configure LILO to require a password before allowing access.
To Configure LILO to Require a Password for Access

Add the following lines (see bold lines) to the /etc/lilo.conf file.

image=/boot/vmlinuz-2.4.9-31enterprise

password=<password>

restricted

label=linux

initrd=/boot/initrd-2.4.9-31enterprise.img

append="console=ttyS1,9600 console=tty0"
Securing the Linux OS
Page 10 of 47
ITSY243-Intrusion Detection Systems

Prof. Michael P. Harris
read-only
root=/dev/sda3
In this example, the password and restriction options are added to the kernel 2.4.9-31enterprise. In
practice, there exist multiple kernel definitions or image entries in the /etc/lilo.conf, often as a result
of kernel upgrades. We recommend that you define these options for each of the kernels listed in your
/etc/lilo.conf file.
NOTE: The version number 2.4.9-31enterprise changes based on the version of the kernel
running on the system.
Using the restricted directive in LILO allows booting of the default kernel without password verification,
but requires a password if any additional arguments are added (such as single to boot into single-user
mode) or if a kernel image other than the default is selected.
Access to the /etc/lilo.conf file should be restricted to only the root user, because the password
contained in that file is in clear-text. Set this restriction by executing the following command.
# chmod go-rwx /etc/lilo.conf
After any modifications, you must run the command /sbin/lilo to propagate any changes to LILO. The
following command is usually sufficient.
# /sbin/lilo
Disable Control-Alt-Delete Reboot Key Sequence
By default, a Sun Linux system reboots when the key combination Control-Alt-Delete is entered.
To Disable the Control-Alt-Delete Key Sequence
1.
Comment out the following line in the /etc/inittab file:
2. # Trap CTRL-ALT-DELETE
# ca::ctrlaltdel:/sbin/shutdown -t3 -r now
3.
Reload the inittab by either rebooting the system or by entering /sbin/telinit q.
Require Single-User Mode Password
You can configure the system to prompt for a password when booted into single-user mode. Add the
following line to the /etc/inittab file.
~~:S:wait:/sbin/sulogin
Securing the Linux OS
Page 11 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
CAUTION: It is highly recommended that you add a password to the LILO configuration file
instead of setting a password for single-user mode. Users can circumvent single-user password
restrictions using the command linux init=/bin/bash instead of the linux single command at
the LILO boot prompt.
Disable the Magic SysRq Key
If enabled, the SysRq key can be used for activities such as rebooting systems, inspecting memory,
synchronizing disks, and killing processes. It is mainly useful to kernel developers, because it allows them
to diagnose and recover a system state after problems. However, be aware that it can be used to gain
unauthorized root access.
t To Disable the Magic SysReq Key
1.
Enter the following in the /etc/sysctl.conf file:
kernel.sysrq = 0
2.
Reboot the system to implement this configuration change.
Restrict Root Access to Devices
The Sun Linux operating system provides the ability to restrict from where a remote user can log into a
system as root user. This restriction is an important capability to help promote accountability on a
system. Typically, we recommend that administrators do not log into systems directly using a root
account; instead they should log into systems using their unique account and assume root privileges as
needed. Often this recommendation is combined with role-based access control capabilities such as sudo
to further restrict what may be done with elevated privileges. By following this recommendation, actions
can be better associated with specific individuals.
The login command is part of the authentication process to access a local Sun Linux account. Except for a
root user, any user can log in to any valid device on a system, serial or virtual. A root user is not
permitted to log in to any device unless the device is listed in the /etc/securetty file. If a root user
attempts to log in to a device not listed, then the attempt fails and a failure notice is logged to the syslog
facility.
If you need to configure the system to permit direct root login over the primary serial interface, then add
the following line to the /etc/securetty file.
/dev/ttyS0
NOTE: Be sure to review the contents of the /etc/securetty file, removing any entries that
are not required. Be careful not to remove root accounts, which would inadvertently lock root
users out of the system.
Securing the Linux OS
Page 12 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Configuring the File System
The default file permissions on some files might not be adequate in all situations; therefore, configure
the Sun Linux file system to provide additional protection. Also, several mount options are available to
increase security, when used effectively. Sun Linux systems need some adjustment to prevent attackers
from gaining superuser privileges.
This section contains the following topics:

"Review set-user-ID and set-group-ID Files"

"Review World-Writable File System Objects"

"Review Unowned File System Objects"
Review set-user-ID and set-group-ID Files
The set-user-ID and set-group-ID bits (often referred to as SUID and SGID bits) on an executable file
indicate to a system that the executable should operate with the privileges of the file's owner or group.
For example, the effective user ID of the running program becomes that of the executable's owner, in the
set-user-ID instance. Similarly, a set-group-ID file sets the running program's effective group ID to the
executable's group. If the command with the set-user-ID and/or set-group-ID bit set is written correctly
with security in mind, it can be a useful method for solving some tricky operational challenges. These
operational challenges can often be solved using forms of role-based access control, such as sudo. For
more information on sudo, see "Limit Root Access" on page 25."
Many set-user-ID and set-group-ID commands have had flaws. Attackers have used these flaws to
successfully exploit systems. When security problems are reported, Sun fixes them and provides a patch.
Attackers might use the set-user-ID or set-group-ID commands to create backdoors. One way they do this
is by copying a system shell to a hidden location and adding the set-user-ID bit. This technique allows
attackers to execute shells to gain elevated privileges (most often superuser).
To Find All set-user-ID and set-group-ID Files
1.
To find all the set-user-ID and set-group-ID files on a server, use the following command:
# find / -type f \( -perm -u+s -o -perm -g+s \) –ls
2.
Store the output to a file on another system.
3.
Compare the output against the current file system from time to time, especially after
applying patches, to find any unwanted additions.
Securing the Linux OS
Page 13 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Review World-Writable File System Objects
A world-writable object is one that has the world-write permission bit set. World-writable objects are
problematic because any user can modify the object. An attacker might use a world-writable file to
perform a disk space-based denial of service attack on a system, or an attacker might modify the object,
violating its integrity. We recommend that all world-writable objects be catalogued and tracked over a
system's lifecycle. Objects that do not require this setting should have their permissions reset to a
stronger value.
To Find World-Writable File System Objects

To find all of the world-writable files and directories on a system, use the following
command.
# find / \(-type f -o -type d \)-perm -0002 –ls
NOTE: All world-writable directories should be configured with the "sticky" bit to
prevent users from deleting files owned by other users. For more information on this
capability, refer to the chmod(1) manual page.
Review Unowned File System Objects
Typically, file system objects stored on a system can be directly attributed to a user and group that exists
either on the system or in a naming service (for example, LDAP) used by the system. It is possible for a
user or group to be removed from a system, leaving file system objects in an unowned state. That is, the
files and directories are now owned by a user or group that no longer exists on the system.
This situation can also occur when extracting archives (for example, tar) built on a different system.
These programs can be configured to preserve the original object's ownership and permissions of the
archived objects. These programs restore the settings without regard to whether the user or group
assigned to the object actually exists on the new system.
To Find Unowned File System Objects
1.
To find all file system objects that are not owned by a valid user on a system, use the
command:
# find / -nouser –ls
2.
To find all file system objects that are not owned by a valid group on a system, use the
following command:
# find / -nogroup –ls
Securing the Linux OS
Page 14 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
NOTE: In general, all file system objects on a system should be assigned to a valid
user and group. Be sure to assign a valid user or group to any files found using the
previous commands.
Managing Accounts
Managing user and system accounts is an important aspect of Linux security. Some system accounts might
need to be deleted or modified. The time-based command execution system tools cron and at might need
to be configured to restrict user access.
This section contains the following topics:

"Delete and Modify System Accounts"

"Restrict at, cron, and batch Command Access"

"Limit Root Access"

"Use the Pluggable Authentication Module (PAM)"
Delete and Modify System Accounts
A default Sun Linux installation contains several accounts that either need to be deleted or modified to
strengthen security. Some accounts are not necessary for normal system operation. These accounts
include games, gopher, and news and uucp.
To Delete Accounts

To delete accounts in /etc/passwd and /etc/shadow entries, use the userdel command,
similar to the following example:
# /usr/sbin/userdel games
This example removes the /etc/passwd and /etc/shadow entries for user games.
Except for the root account, modify any remaining system accounts for added security by locking
them, setting account expiration, or setting their login shells to a restricted value.
To Lock Accounts

To lock unused accounts that are not locked by default, use the passwd -1 option. For
example, if the uucp account is not used, then lock it using the following command.
# passwd -l <username>
The password of the account is changed to a string that can never be a valid encrypted password.
Securing the Linux OS
Page 15 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
To Expire an Account

To schedule a user account to expire, use the following command:
# /usr/sbin/usermod -e YYYY-MM-DD <username>
An expired account has similar characteristics to those of an account where the password is locked. The
account can still be accessed by root via superuser, daemons can be started, and files and directories can
be owned by the account. As with locked accounts, expired accounts cannot be used to login to a system
or to access any of the services where authentication is required, such as Telnet, FTP, or IMAP.
To disable interactive access to a user account, use the following command.
# usermod -s /bin/false <username>
An account with a disabled shell (one that is not listed in /etc/shells and does not permit access to the
system) only impacts applications that check for valid shells, such as Telnet, FTP, and Secure Shell. This
method does not impact other applications such as IMAP and POP that by default do not check this
setting.
A better alternative to using /bin/false as a disabled shell is to use a program that not only prevents
access to the system but also logs the attempted access. The following shell script could be used to
implement such functionality. This example is based on the file /sbin/noshell program available from the
Solaris™ Security Toolkit software. For more information on the Solaris Security Toolkit software, refer to
http://www.sun.com/security/jass.
#!/bin/sh
#
trap "" 1 2 3 4 5 6 7 8 9 10 12 15 19
PATH=/bin:/usr/bin
export PATH
HNAME="'uname -n'"
UNAME="'id | awk '{ print $1 }''"
logger -i -p auth.crit "Unauthorized access attempt on ${HNAME} by ${UNAME}"
wait
exit
To change default account parameters used during new account creation (via useradd), change the
following values in either the /etc/login.defs or the /etc/default/useradd file.
TABLE 1 describes the parameters in the /etc/login.defs file.
Securing the Linux OS
Page 16 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
TABLE 1 /etc/login.defs File Parameters
Parameter
Description
PASS_MIN_DAYS
Minimum days allowed between password
changes
PASS_MIN_LEN
Minimum acceptable password length
PASS_WARN_AGE Days warning given before a password
expires
PASS_MAX_DAYS Maximum days a password may be used
TABLE 2 describes the parameters in the /etc/default/useradd file.
TABLE 2 /etc/default/useradd File Parameters
Parameter
Description
GROUP
Default group
HOME
Default user home location
EXPIRE
Expiration date of an account in the format
YYYY-MM-DD
INACTIVE
Maximum days after an unchanged and
expired password that the account is locked
out and can only be accessed by root
SHELL
Default shell
Restrict at, cron, and batch Command Access
The at, cron, and batch commands execute processes (events) at a specified future time. Access control
files are stored in the /etc directory.

The cron.deny and cron.allow files manage access to the cron command.

The at.deny and at.allow files manage the access to the at and batch commands.
The allow files are checked first to determine if an account is explicitly allowed to use these facilities.
Attackers can use these commands to implement logic bombs (triggered by a system condition, logic that
causes damage to data processing systems) or other programmed attacks that begin in the future. Unless
administrators examine every at, batch, and cron event, tracking usage and abuse can be difficult.
Therefore, we recommend that you restrict access to the at, batch, and cron commands to prevent
attacks and abuse.
Securing the Linux OS
Page 17 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
By default, Sun Linux includes scheduled cron events for the root account. Do not include the root
account in the deny files, because any scheduled jobs will be prevented from running.
Add to the deny files any additional system or software-specific accounts that do not require cron, batch,
or at access.
You might want to restrict user access to these commands as well. List individual user accounts in the
deny files. To restrict all user account access, create an empty allow file, then add only the accounts that
need access.
Limit Root Access
The sudo program implements a form of role based access control (RBAC). It is a commonly used tool for
limiting access to privileged commands and accounts. Using sudo has the following benefits:

sudo is configured by default to ask for a user's password

Fewer users need to log in as privileged users and know the password

Access to privileged commands is determined by a policy; users are given access only to the
commands they need

Access to privileged commands can be logged
Common uses for sudo are allowing system operators to make backups and create user accounts without
giving operators full root access.
To create a new account, an operator enters:
# sudo useradd newuser
It is very important to ensure that mail to root is checked or forwarded. Unauthorized use of sudo
generates an email to the root user and creates an entry in the system log /var/log/messages file.
May 4 18:25:14 scl1 sudo(pam_unix)[28769]: authentication failure; logname=attackerid
uid=0 euid=0 tty=pts/2 ruser= rhost= user=attackerid
To review valid uses of sudo, refer to /var/log/secure. In the following example, the sudo command was
used by the user joe to access the /bin/bash command as root.
May 4 18:25:28 scl1 sudo: sudoerid: TTY=pts/2 ; PWD=/home/sudoerid/joe ;
USER=root ; COMMAND=/bin/bash
The sudo command consults the /etc/sudoers configuration file to determine if a command is allowed.
This configuration file contains access control lists (ACLs) as in the following example.
<user> <hostname> = '(' <account> ')' <command> [',' <command>]
Securing the Linux OS
Page 18 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
A rule of this form allows user logged in to hostname to run command as user account. By including the
hostname in the rule, it is possible to share a single /etc/sudoers file between multiple machines. For
more information about the format of these ACLs, refer to the sudoers manual page.
Use the visudo command to edit the /etc/sudoers file. This command checks the syntax of edited
contents before overwriting /etc/sudoers. If the /etc/sudoers syntax is incorrect, sudo does not work.
To keep the description concise, you can define aliases for sets of users, hostnames, and commands. You
can use the alias ALL in any field. In the following example, we allow a group of operators to make
backups and restore them.
# provide access to dump and restore for backup operators
User_Alias OPERATORS = tom, dick, harriet
Cmnd_Alias BACKUPCMD = /sbin/dump, /sbin/restore
OPERATORS
ALL = (root) BACKUPCMD
Be aware that with a little creativity, any user who can make backups and restore them can gain root
access, so this example is not a completely secure setup. In general, we advise that you create scripts or
programs that wrap commands executed with privilege to limit the options available to its users. In
addition, these scripts can sanitize the execution environment by checking or resetting variables such as a
user's path to help ensure sane settings. This way, the use of privileged commands can be better
controlled.
You can configure sudo to allow only certain parameters to be passed to privileged commands. Verify that
operators cannot pass any arguments to privileged commands that have unintended consequences. The
following rule allows operators to change passwords for all users except for root.
# User alias specification
User_Alias OPERATORS = tom, dick, harriet
# Cmnd alias specification
Cmnd_Alias PASSWDCMD = /usr/bin/passwd, !/usr/bin/passwd root
# Defaults specification
OPERATORS
ALL = (root) PASSWDCMD
The previous example prevents execution of the sudo passwd root command. However, it does allow
execution of the sudo passwd --stdin root command. In this case, you can fix the problem by changing
the definition of PASSWDCMD slightly, as in the next example.
The following example allows two classes of users (web masters and operators) to manage a system. Web
masters can stop and start a web server. Operators can change forgotten user passwords (except for root
passwords), start system backups, and perform web master duties.
Securing the Linux OS
Page 19 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
# User alias specification
User_Alias OPERATORS = tom, dick, harriet
User_Alias WEBMASTERS = josephine, OPERATORS
# Cmnd alias specification
Cmnd_Alias PASSWDCMD = /usr/bin/passwd [!-]*, !/usr/bin/passwd root
Cmnd_Alias BACKUPCMD = /usr/sbin/backup_script
Cmnd_Alias HTTPDCTL = /etc/rc.d/init.d/httpd
# Defaults specification
Defaults
authenticate, timestamp_timeout = 60
# User privilege specification
root ALL=(ALL) NOPASSWD: ALL
OPERATORS
ALL = (root) PASSWDCMD
OPERATORS
ALL = (root) BACKUPCMD
WEBMASTERS ALL = (root) HTTPDCTL
Use the Pluggable Authentication Module (PAM)
The Pluggable Authentication Module (PAM) architecture allows administrators to control and replace the
methods used for authentication. In concept, while this is similar to the PAM functionality that is
available in the Solaris OE, note that there are differences.
For more information on the Solaris OE implementation of PAM, refer to the Sun BluePrints OnLine twopart lesson titled "Extending Authentication in the Solaris 9 OE Using Pluggable Authentication Modules
(PAM)."

Part I: http://www.sun.com/blueprints/0902/816-7669-10.pdf

Part II: http://www.sun.com/blueprints/1002/816-7670-10.pdf
Although PAM makes authentication operations more robust, it requires that system authentication
information be maintained in more places than just /etc/passwd and /etc/shadow. PAM can be expanded
to support Kerberos, LDAP, OPIE, S/Key, RSA SecureID, RADIUS, TACACS+, and others. Understanding how
the PAM system functions is essential for maintaining the security of a system.
All primary applications such as login, su, ssh, and sudo are PAM aware. Each application that uses PAM
does so through a common API that references the general configuration file /etc/pam.conf or the
application-specific file in the directory /etc/pam.d/, if it exists.
Securing the Linux OS
Page 20 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
NOTE: If the directory /etc/pam.d/ exists, the file /etc/pam.conf is ignored. The directory
/etc/pam.d/ is part of the standard Sun Linux installation.
CAUTION
Before editing PAM configuration files, make a backup of the files. Errors made in
configuration files can prevent PAM or the service you modified from operating correctly, and
might prevent privileged users from logging in. Also, you could inadvertently disable
authentication and expose the system. Do not change the default ownership or file
permissions of the /etc/pam.d/ directory or its contents.
Within the PAM configuration file, define methods for authentication. Enter one line per method using the
following format.
[service] [type] [control] <module-path> <module-arguments>
TABLE 3 lists the values for entering authentication methods.
TABLE 3 PAM Configuration Values
Field/Value
Description
service
This field exists only if the /etc/pam.conf file is used and is the name of the
service defined, such as login or su. If the file is in /etc/pam.d/ and is specific
to the application, then it is not used.
type
This field is the management group and can be one of the following:




control
account - Verify that the account is valid. For example: has the
account expired?
authentication - Verify the user's identity by using a password, smart
card, or biometric device.
password - Maintain the authentication method. For example: if the
password has expired, prompt for a new one.
session - Provide methods that are performed before the session is
started and after the session is ended, such as setting up and reclaiming
resources the user requires.
This field specifies what to do when a module fails its task:



Securing the Linux OS
requisite - Immediate termination of the authentication process; do not
call additional modules.
required - If this module fails, then allow other modules to be called,
but ultimately fail the authentication attempt. Each required module
must succeed for the authentication to succeed.
sufficient - Success of the module is enough to succeed in
Page 21 of 47
ITSY243-Intrusion Detection Systems


Prof. Michael P. Harris
authentication.
optional - Success or failure of this module is important if it is the only
module in the stack associated with this service and type.
More complex control syntax can be used; refer to the pam(8) manual
page.
module-path
This path is the full file name of the authentication module called with the
default location /lib/security/. A special module used by many configuration
files is pam_stack. This module lets you call a service from inside the stack.
This feature allows multiple services to include a system-wide configuration, so
that it only needs to be maintained in one place. The most common use for this
feature is the configuration file /etc/pam.d/system-auth.
modulearguments
Valid arguments are space-separated lists of tokens that modify behavior of the
module called. They are module specific.
For additional information on PAM, refer to the Linux PAM site at
http://www.kernel.org/pub/linux/libs/pam/, the pam(8) manual pages, and the PAM documentation in
/usr/share/doc/pam.
After editing the configuration file, test the changes and make any necessary adjustments.
NOTE: If you lock yourself out of a system, reboot into single-user mode, then restore the
configuration file from the backup.
Disabling Null Passwords
A null password allows users to log onto a system without having to first supply a valid password string.
When users have null passwords, they can press the Enter key when prompted for a password and gain
access to systems without a password. Obviously, this poses a significant security risk to the system and to
the accountability of actions performed by users.
To Disable Null Passwords

Make a backup of the /etc/pam.d/system-auth file, then modify the original by removing
nullok from the line, resulting in the following:
auth sufficient /lib/security/pam_unix.so likeauth
Checking Passwords Against a Dictionary
Sun Linux can be configured to verify that passwords cannot be guessed easily. On Sun Linux, this check is
performed by the module /lib/security/pam_cracklib.so. It checks to ensure that passwords are a
minimum length and verifies that a password does not occur in a dictionary.
Securing the Linux OS
Page 22 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
The dictionary used by this module is located in /usr/lib and is in cracklib format. By default, each of
the dictionary files is prefixed with the file name cracklib_dict. For more information on cracklib
including how to add new words to the dictionary, refer to http://www.crypticide.org/users/alecm/.
This module has a number of parameters, the most useful of which are as follows.
TABLE 4 pam_cracklib Parameters
Parameter Description
minlen
Specifies the minimum password length allowed
for an account
difok
Specifies the minimum number of characters that
have to differ from the previous password
To Check Passwords

Add the following parameters to an entry in /etc/pam.d/system-auth, resulting in the
following single line:
password required /lib/security/pam_cracklib.so retry=3 type= minlen=8 difok=3
Preventing Reuse of Old Passwords
The PAM module pam_unix.so can be configured to maintain a list of old passwords for every user, to
prohibit the reuse of old passwords. The list /etc/security/opasswd is not maintained as plain text, but
should be protected the same as shadow password files. This capability is often referred to as password
history.
To Retain a List of Passwords

To remember the last 15 passwords, add the following line in /etc/pam.d/system-auth file:
password sufficient /lib/security/pam_unix.so use_authtok md5 shadow
remember=15
Preventing Password Guessing
The module pam_tally keeps track of unsuccessful login attempts, and disables user accounts (not user
IDs) when a preset limit is reached. This capability is often referred to as account lockout.
Securing the Linux OS
Page 23 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
To Prevent Password Guessing

Add two entries in the /etc/pam.d/system-auth file:

auth
required /lib/security/pam_tally.so onerr=fail no_magic_root
account required /lib/security/pam_tally.so deny=5 no_magic_root reset
Because the order of the lines in /etc/pam.d/system-auth is important, we list the complete file
contents.
auth
required /lib/security/pam_env.so
auth
required /lib/security/pam_tally.so onerr=fail
no_magic_root
auth
sufficient /lib/security/pam_unix.so likeauth
auth
required /lib/security/pam_deny.so
account required /lib/security/pam_unix.so
account required /lib/security/pam_tally.so deny=5
no_magic_root reset
password required /lib/security/pam_cracklib.so retry=3
type= minlen=8 difok=3
password sufficient /lib/security/pam_unix.so use_authtok
md5 shadow remember=15
password required /lib/security/pam_deny.so
session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so
Monitoring System Activity
Examine all of the log files regularly for errors, warnings, and signs of an attack. This task can be
automated by using log analysis tools or a simple grep command.
Sun Linux includes an automatic log analysis and reporting tool named logwatch. This tool sends nightly
email reports to a root user. The email address can be changed by editing the
/etc/log.d/conf/logwatch.conf file. Logwatch is of limited use from a security perspective, because it
does not constantly monitor for unusual activity.
The syslog daemon receives log messages from several sources and directs them to the appropriate
location based on the configured facility and priority. The programmer interface syslog() and system
command logger are available for creating log messages. The facility or application type and the priority
Securing the Linux OS
Page 24 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
are configured in the /etc/syslog.conf file to forward log messages to specified locations. The location
can be a log file, network host, selected users, or all users.
By default, Sun Linux defines several log files in the /etc/syslog.conf file:

The /var/log/messages log file contains a majority of the system messages.

The /var/log/maillog file contains mail system messages.

The /var/log/secure log file contains a majority of the security messages from sudo and ssh.
If you change the /etc/syslog.conf file, the syslog daemon must be restarted. Use the following
command.
# killall -HUP syslogd
In addition to logging syslog events locally on each client system, Sun recommends that syslog events be
sent to a centralized log server where logs can be more safely stored and analyzed. As an added benefit,
by logging events to a central location, logs may be more readily preserved in the event that the client
system is compromised.
Note that syslog monitoring is just a single process. Sun recommends that users protect their
environments through architectures that implement defense-in-depth through mutually reinforcing,
complementary security controls. The methodology for determining which controls are most appropriate
to your environment and where they should be positioned in your architecture is outside the scope of this
lesson.
Additional layered monitoring methods such as periodic-vulnerability assessments, file system integrity
monitoring, and host-based intrusion detection mechanisms can greatly improve your ability to detect
attempted or actual breaches of security whereas a single method might be more easily subverted.
References and Related Resources
Publications

"Extending Authentication in the Solaris 9 OE Using Pluggable Authentication Modules (PAM)."
Part I: http://www.sun.com/blueprints/0902/816-7669-10.pdf
Part II: http://www.sun.com/blueprints/1002/816-7670-10.pdf

Hatch, Brian, and Osborne, James Lee. Hacking Linux Exposed, Second Edition McGraw-Hill,
ISBN: 0072225645, November 2002.

Nemeth, Evi, Snyder, Garth, Seebass, Scott, and Hein, Trent R. UNIX System Administration
Handbook, 3rd Edition, Prentice Hall PTR, ISBN: 0130206016, August 2000.
Securing the Linux OS
Page 25 of 47
ITSY243-Intrusion Detection Systems

Prof. Michael P. Harris
Noordergraaf, Alex. "Solaris Operating Environment Network Settings for Security: Updated for
Solaris 9 Operating Environment," Sun BluePrints OnLine, June 2003,
http://www.sun.com/solutions/blueprints/0603/816-5240.html.

Noordergraaf, Alex and Watson, Keith. "Solaris Operating Environment Security: Updated for the
Solaris 9 Operating Environment," Sun BluePrints OnLine, December 2002,
http://www.sun.com/solutions/blueprints/1202/816-5242.pdf.

Reid, Jason. "Building OpenSSH - Tools and Tradeoffs," Sun BluePrints OnLine, January 2003,
http://www.sun.com/blueprints/0103/817-1307.pdf.

Reid, Jason. "Configuring the Secure Shell Software," Sun BluePrints OnLine, April 2003,
http://www.sun.com/blueprints/0403/817-2485.pdf.

Reid, Jason. "Integrating the Secure Shell Software," Sun BluePrints OnLine, May 2003,
http://www.sun.com/blueprints/0503/817-2821.pdf.

Red Hat Linux 9: Red Hat Linux Security Guide, Red Hat Inc., 2002.

Stevens, Richard W. TCP/IP Illustrated, Volume 1, 1st Edition, Addison-Wesley Publishing
Company, ISBN: 0201633469, January 1994.
Web Sites
NOTE: Sun is not responsible for the availability of third-party Web sites mentioned in this
document. Sun does not endorse and is not responsible or liable for any content, advertising,
products, or other material on or available from such sites or resources. Sun will not be
responsible or liable for any damage or loss caused or alleged to be caused by or in connection
with use of or reliance on any such content, goods, or services that are available on or
through any such sites or resources.

Center for Internet Security - Linux Benchmark http://www.cisecurity.org/

OpenSSH tool: http://www.openssh.com/

Sendmail Consortium: sendmail configuration information, http://www.sendmail.org/

SSH Communications Security, Secure Shell (SSH) tool: http://www.ssh.com/

Sun BluePrints: http://www.sun.com/blueprints

TCP Wrappers tool, Wietse Venema: ftp://ftp.porcupine.org/pub/security/index.html
Ordering Sun Documents
The SunDocsSM program provides more than 250 manuals from Sun Microsystems, Inc. If you live in the
United States, Canada, Europe, or Japan, you can purchase documentation sets or individual manuals
through this program.
Accessing Sun Documentation Online
The docs.sun.com web site enables you to access Sun technical documentation online. You can browse
the docs.sun.com archive or search for a specific book title or subject. The URL is http://docs.sun.com/
Securing the Linux OS
Page 26 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
To reference Sun BluePrints OnLine lessons, visit the Sun BluePrints OnLine Web site at:
http://www.sun.com/blueprints/online.html
Part II
This lesson is the second part of a two-part lesson that provides recommendations for securing the Linux
operating system. This part provides recommendations for network security. Part I provides
recommendations for securing local access and file systems. The information in this lesson applies only to
the Sun Linux distribution, although some techniques or recommendations might apply to other Linux
distributions.
Sun Linux is based on the Red Hat Linux Distribution and is a flexible, general purpose operating system.
To secure a Sun Linux system against unauthorized access and modification requires changes to its default
configuration. Although these changes are, in most cases, relatively minor, we strongly recommend that
you make these changes to improve the security posture of a system. The changes and recommendations
in this lesson address the majority of methods that intruders use to gain unauthorized or privileged access
to Sun Linux systems. You can implement many of the changes during or immediately after system
installation.
As with most security strategies, a balance must be achieved between system manageability and security.
Some recommendations in this lesson might not apply to your environment. Removing some services as
recommended in this lesson might negatively impact your ability to manage a system. You must know your
system and security requirements before starting. Implementing the changes recommended in this lesson
requires planning, testing, and documentation.
This lesson contains the following topics:

"Securing Network Services"

"Turning Kernel Network Parameters"

"References and Related Resources"

"About the Authors"

"Ordering Sun Documents"

"Accessing Sun Documentation Online"
Securing Network Services
Secure network services and configure network parameters for better security. The network services a
system provides are entry points that can be attacked and exploited to gain access. It is important to
understand the default configuration of Sun Linux, including its services and the methods used to disable
or protect them. Often, organizations need to use protocols or services that are not secure. Where
possible, we provide recommendations for improving the security of those services.
Securing the Linux OS
Page 27 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Network services enable distributed computers and their users to communicate, access remote systems
and information, transfer files, send electronic mail, print on network printers, and manage remote
systems. Multi-user operating systems such as Sun Linux typically provide many network services. These
services are either necessary for the operation and management of an application or are essential to the
service an application provides.
By default, Sun Linux only runs the portmap, rpc.statd, and sshd services. This default improves the
overall security posture of a system by limiting the number of unnecessary services that are started on a
system. In general, all network services that are not required to meet a business requirement should be
disabled.
Protect services that are offered by a system by using as many layers as feasible. The most secure systems
are not necessarily those with the most layers. The layers added must support the practice of defense-indepth by implementing complementary and mutually reinforcing security controls. The layers must adhere
to the principle of proportionality, whereby the costs of the controls are weighed against the value of the
assets being protected. In this lesson, we describe layers at the network level, such as filtering and
logging options, available in both xinetd and TCP Wrappers.
Network services can be attacked in many ways. These services might contain programming flaws, use
weak or no authentication, transfer sensitive data in unencrypted format, or allow connections from any
network host. These weaknesses allow attackers to access entry points and potentially exploit weaknesses
in the installation or configuration.
Some simple methods are available to reduce the risk of attacks against systems. In addition to disabling
unneeded services and applying all security patches, use security features (for example, encryption,
strong authentication, etc.) with network services whenever possible. You can deploy firewalls like
iptables on servers and desktops alike where IP forwarding is not required, but network service
protection is. Massive deployments and management of firewalls on many systems can be burdensome, so
plan appropriately.
Additionally, there are well-regarded open source and commercial tools that add protection. These tools
address security concerns by providing the following protection: access control, logging, strong
authentication, and privacy through encryption.
The open source toolkit OpenSSH is a suite of tools to replace UNIX® network commands such as telnet,
ftp, rlogin, rsh, and rcp. OpenSSH provides strong authentication and privacy through the use of publickey authentication and support of PAM. Also, OpenSSH provides the capability to securely tunnel X
Window network communications over an encrypted channel. When built with the TCP Wrappers library,
as is the case in Sun Linux, it provides additional access control. It is a very valuable tool because of the
unsafe commands it replaces. After deploying OpenSSH, disable the replaced network services in favor of
OpenSSH services.
The OpenSSH tool is very powerful and highly configurable. As a result, it is essential that the tool be
configured to be as secure as possible. For recommendations on OpenSSH configuration and tuning, refer
Securing the Linux OS
Page 28 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
to the Sun BluePrint Online lessons titled "Configuring the Secure Shell Software" and "Integrating the
Secure Shell Software."
To secure network services, perform the following tasks:

"Enable and Disable Network Services"

"Limit Access to Services Managed by xinetd"

"Enable TCP Wrappers"

"Enable Packet Filtering"

"Secure Telnet Connections"

"Secure Remote Access Connections"

"Secure FTP"

"Secure the Remote Procedure Call (RPC) Services"

"Disable or Secure automount Services"

"Secure the NFS Services"

"Secure the sendmail Services"

"Configure Name Service Caching"

"Secure Print Services"

"Display Access Warnings"
Enable and Disable Network Services
Network services are generally started either at boot time by /sbin/init or on demand by the xinetd
daemon.
Sun Linux provides the general purpose command chkconfig to enable and disable services that are
started by init and xinetd. Using chkconfig is easier and less error prone than editing configuration files.
To enable or disable a service started by init, use the following command.
# chkconfig --level <runlevels> <service> [on | off]
To enable the Apache Web Server to run on levels 3, 4, and 5, use the following command.
# chkconfig --level 345 httpd on
This command configures the httpd service to start at boot time for run levels 3, 4, and 5 only. This
command only enables or prevents a service from starting; it does not actually start the service itself. To
start the service manually, use the following command.
# /etc/rc.d/init.d/httpd start
Securing the Linux OS
Page 29 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Services started from xinetd are managed in a similar way. The exception is that the run level should not
be specified, as it is irrelevant to services managed by xinetd. By default, the xinetd service is
automatically started at run levels 4 and 5.
To enable Telnet, use the following command.
# chkconfig telnet on
This command enables Telnet and reloads the xinetd daemon, which makes Telnet available immediately.
Limit Access to Services Managed by xinetd
Sun Linux uses the xinetd daemon to control availability to minor network services. All network services
are disabled by default. Services that are required to support a business requirement should be enabled
as appropriate.
Use the /sbin/chkconfig command to control xinetd services. The format and operations are the same
for init services. When listing services using chkconfig, the init services are listed first followed by the
services controlled by xinetd.
An ideally secured server often does not run xinetd, because the daemons started in the
/etc/xinetd.conf are frequently not needed.
The xinetd daemon provides a number of facilities that are useful for limiting and monitoring access to
the services it manages. Access can be limited by network address, time, and other parameters.
To Change a Managed Service
1.
Edit the /etc/xinetd.d/<service> file, where <service> is the name of the network service
to be customized.
2.
Use the chkconfig command to switch the service on.
This command sends a USR2 signal to the xinetd process to reread its configuration files. Note
that the signal differs from the signal used to reconfigure inetd.
Address-based access control is provided through two configuration parameters: only_from and no_access.
Both parameters specify an access list, which can contain IP addresses and ranges, host names, domain
names, and other parameters. Refer to the xinetd.conf(5) manual page for details.
Of the daemons started from the /etc/xinetd.d directory, the Telnet, FTP, and standard r* commands
are described in the following sections. In Sun Linux, these services are disabled by default.
For restricted access servers, all connections to services managed by xinetd should be logged. Logging is
enabled by default in Sun Linux.
Securing the Linux OS
Page 30 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Sun recommends that you review and consider the use of the xinetd options listed in TABLE 1. You can
use them to enforce additional policies such as limiting access times. Also, they allow for binding sockets
to individual network interfaces.
TABLE 1 xinetd Options
Option
Description
only_from
Specifies a list of host names, IP addresses, and/or IP address ranges that are
allowed access to this service. Packets originating from one of the permitted
addresses or address ranges are permitted, while all others are denied access to
this service. Note that, especially in the case of UDP services, a packet with a
spoofed source address is permitted to access the service.
The xinetd daemon filters UDP services as well as TCP services, unlike TCP
Wrappers, which only filter the first packet to a UDP server. However, xinetd
runs a separate process that acts as filter, which is a relatively inefficient
process and should be limited to low-traffic services.
no_access
Specifies a list of host names, IP addresses, and/or IP address ranges that are
not allowed access to a service. If a source address matches an entry on both
only_from and no_access lists, the most-specific entry takes precedence.
banner_fail
References a file containing contents sent over a TCP data connection that does
not meet the access criteria. The connection is closed immediately after the
data is sent.
bind
Listens only for connections on a specified interface address. We strongly
recommend that you use this capability to configure services to listen only on
those interfaces where the service is required. If a service is not required to
run on a specific network, do not make it available. For example, consider
binding management services to listen for connections only on management
networks.
The following example shows a possible configuration for the Telnet service.
# default: on
# description: The telnet server serves telnet sessions; it uses #
unencrypted username/password pairs for authentication.
service telnet
{
flags
= REUSE
socket_type = stream
wait
= no
user
= root
server
= /usr/sbin/in.telnetd
log_on_failure += USERID
disable
= no
Securing the Linux OS
Page 31 of 47
ITSY243-Intrusion Detection Systems
only_from
bind
Prof. Michael P. Harris
= 192.168.1.0/24
= 192.168.1.50
banner_fail = /etc/telnet_banner
}
In this example, the Telnet service is configured to bind to the system's IP address 192.168.1.50 and to
accept connection requests only from systems on the same network, 192.168.1.0/24. In addition, the
banner message defined in /etc/telnet_banner is displayed to any user attempting to connect to this
service from an IP address not on the 192.168.1.0/24 network.
Enable TCP Wrappers
The TCP Wrappers tool is an open source tool, developed by Wietse Venema, that provides a flexible
configuration mechanism for controlling incoming connections based on pattern matching for hostnames,
DNS domains, and network addresses. With Sun Linux, this functionality is integrated into the OS and
provides protection for most network services, even those started by xinetd. The tool provides a good
logging capability and detects DNS hostname discrepancies that can indicate an attack.
TCP Wrappers are enabled by default on Sun Linux. TCP Wrappers are configured into a number of
services, which include ssh, portmap, and every service managed by xinetd. A simple TCP Wrapper
configuration could have the following configuration in its /etc/hosts.allow and /etc/hosts.deny files.
# cat /etc/hosts.allow
ALL: LOCAL 10.8.10.0/255.255.255.0 10.8.11.0/255.255.255.0
portmap: 10.8.31.100
sshd: 10.0.0.0/255.0.0.0 192.168.0.0/255.255.0.0
# cat /etc/hosts.deny
ALL: ALL
This sample configuration restricts access to all services using TCP Wrappers to the local subnet and two
class C IP ranges (10.8.10.0 and 10.8.11.0). In addition, ssh and portmap allow other IP addresses to
connect. For more information about TCP Wrapper capabilities, refer to the tcpd(8) manual page.
Sun Linux uses xinetd as a replacement for the venerable inetd managed network services daemon. The
xinetd provides facilities that are similar to TCP Wrappers, and is generally much more flexible than
inetd. Unlike TCP Wrappers, xinetd can provide protection for UDP services by intercepting all packets
and matching them with access control lists before passing them on. Also, xinetd can perform rate
limiting and provides many logging options. On Sun Linux, xinetd has support built in for TCP Wrappers. It
is not necessary to use the tcpd binary.
Enable Packet Filtering
Linux kernels based on version 2.4 and newer, such as Sun Linux 5.0, come equipped with a built-in
packet filter called netfilter, that is also referred to by the name of the command that controls it:
Securing the Linux OS
Page 32 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
iptables. Netfilter supports all the features commonly found in modern IP packet filters, including
stateful inspection filtering.
A stateful inspection filter such as netfilter uses knowledge of packets that were previously seen as a
factor in its filtering decisions. It is no longer necessary to pass all TCP packets that have the ACK flag
set; DNS responses can be matched to requests. It is only necessary to add rules for the initial packet of a
session, then the stateful inspection mechanism takes care of the remaining traffic. Rule sets become
more concise, and there is less interference between rules for different protocols, which is a common
problem with static packet filters.
Netfilter also supports application level gateways (ALGs). These are rules that handle problem protocols
such as FTP that negotiate additional connections, which have to be passed by the filter. The ALGs
inspect the contents of packets to determine which additional connections to expect. Only a few
protocols are supported at this time, however.
Netfilter is an excellent tool for constructing host-based firewalls to protect against attacks from other
hosts, not just those outside a perimeter firewall. They provide an additional layer of defense to protect
against unneeded services being enabled by mistake, or when other security tools fail and are
circumvented. Always practice defense in depth where possible.
More information on the netfilter tool including source code, how-to documents, and tutorials are
available at: http://www.netfilter.org/.
An exhaustive list of netfilter and iptables related material is available at:
http://www.linuxguruz.com/iptables/.
Secure Telnet Connections
Telnet is a user-interactive service for accessing remote systems on a network. Unfortunately, this service
provides little in the way of security. By default, the only authentication information required is user
name and password. Neither of these items are encrypted while in transit, and are, therefore, vulnerable
to a variety of attacks including: man in the middle attack, session hijacking, and network sniffing. Tools
implementing the Secure Shell protocol can serve as an effective replacement and are strongly
recommended.
By default, the Telnet service is disabled in Sun Linux. If this service must be used, then consider using
strong authentication mechanisms such as Kerberos, One-time passwords, tokens, or other methods. In
addition, consider restricting access to the Telnet service using xinetd filtering, TCP Wrappers, or hostbased firewalls. That way, the risks associated with running a nonsecure service are reduced by limiting
who can access it.
Host-based firewalls and TCP Wrappers limit the hosts that may connect to a system. By restricting access
to services based on IP addresses, a system can limit its exposure to network attacks. Note that firewalls
do not prevent sniffing of Telnet connections.
Securing the Linux OS
Page 33 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
CAUTION: One-time passwords and filtering access do not protect the contents of a session
from being disclosed through network sniffing. In addition, be aware that these alternatives
typically do not protect a session against being hijacked by a malicious user. The malicious
user, in effect, can take over a session from an authorized user.
Secure Remote Access Connections
Access control and accountability are critical to the security of a system. Access control should involve
strong authentication for system access, while accountability information should provide tracking data
relative to system changes.
The standard r* commands (rsh, rlogin, and rcp) break both of these recommendations, because most
implementations of r* commands involve zones of trust. Within a zone of trust, all systems are trusted
and no additional authentication is required. Hence, an intruder need only gain access to one server to
gain access to all servers.
The default authentication mechanism of the r* commands uses the hostname or IP address of a system
and a user ID for authentication. No additional authentication is required. Considering the ease with
which an IP address and user ID can be stolen or misused, this default is clearly not a secure mechanism.
We recommend that you do not use the r* commands in this manner, and that you do not allow servers to
offer a service in this manner.
Where possible, the use of the r* commands should be replaced with a more secure alternative such as
Secure Shell. There might be times when this is not possible. In those cases, it is recommended that the
host-based authentication mechanism used by the rlogin command be disabled.
To Disable Host-Based Authentication

Comment out the pam_rhosts_auth.so entry in /etc/pam.d/rlogin file as follows:

#%PAM-1.0

# For root login to succeed here with pam_securetty, "rlogin" must be

# listed in /etc/securetty.

auth
required /lib/security/pam_nologin.so

auth
required /lib/security/pam_securetty.so

auth
required /lib/security/pam_env.so

#auth

auth

account required /lib/security/pam_stack.so service=system-auth

sufficient /lib/security/pam_rhosts_auth.so
required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
Securing the Linux OS
Page 34 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Shown in bold text, this change forces rlogin to prompt for a password. The rsh protocol does
not allow for password authentication, and should therefore always be disabled. Note that the
pound sign (#) is added to the line.
Secure FTP
The ftp daemon has many of the same security issues as the telnet daemon. By default, all
authentication information transmitted over a network is in clear-text, in much the same fashion as the
Telnet protocol. This exposes the FTP protocol to many of the same attack scenarios as Telnet, including
man in the middle, session hijacking, and network sniffing. For these reasons, consider alternatives to
FTP when FTP transport functionality is required.
OpenSSH provides a secure alternative to FTP, providing most of the functionality of command-line based
FTP access.
The Washington University FTP (wu-ftp) service is provided in Sun Linux. This implementation of the FTP
service supports several security enhancements not commonly found in its predecessors. In particular, the
wu-ftp service supports:

Enhanced access control using the /etc/ftpaccess file. Use this file to restrict access to specific
users and restrict access based on group membership, source address or network, and user
classes.

Extended logging capabilities that permit you to log connection events, individual FTP
commands, individual file transfers, upload or download, and security rule violations as defined
by the FTP configuration.

Explicit definition of the control and data ports used by the FTP server. This capability is very
useful for controlling FTP access in firewall environments.

Containment using the chroot(1M) facility. This facility allows a service to be configured to run
in a contained area, such as a user's home directory, thereby limiting the file system objects a
user can access.
For more information on these capabilities and other configuration options provided by this service, refer
to ftpaccess(5).
Sun Linux includes a fully configured set of directories for anonymous access. A default /etc/ftpusers file
is included as well. In this file, specify all accounts not allowed to use the incoming FTP service. At a
minimum, include all system accounts (for example, games, news, uucp, and so forth) in addition to the
root account.
Frequently, intruders use FTP with these accounts to gain unauthorized access. Commonly, root access to
a server over Telnet or Secure Shell is disabled while root FTP access is not. This configuration provides a
backdoor for intruders who might modify a system's configuration by uploading modified configuration
files, thereby accessing a system remotely.
Securing the Linux OS
Page 35 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
The second security feature of the in.ftpd daemon is the ability of the daemon to log IP addresses of all
connections and commands issued to the ftp daemon through the syslog service. Logging is enabled with
the -l option. Commands issued to the ftp daemon are logged when the -d option is used. By logging FTP
connection requests and commands to a log server for parsing, you can track and resolve unauthorized
access attempts.
CAUTION: Using the -d option has the potential for logging passwords that are erroneously
entered at the login prompt. It is important that the log files be sufficiently protected to
prevent the disclosure of this sensitive information.
The wu-ftp daemon can change the banner message shown before login. Use this daemon to hide from
potential attackers the version of the FTP server used.
To Change Banner Messages for Incoming FTP Connections
1.
Review the /etc/ftpaccess file to determine if the following entry is present:
banner=/etc/ftpd/banner.msg
2.
If the entry is not present, add it.
3.
Replace the contents of the /etc/banner.msg file with a line similar to the following, as
appropriate for your environment:
Authorized Use Only
Secure the Remote Procedure Call (RPC) Services
The Remote Procedure Call (RPC) mechanism provides a way for network services to communicate and
make procedure calls on remote systems. When a new RPC service is started, it registers with portmap,
the central RPC service agent. The portmap maintains a table of RPC services (listed by program number)
and the network addresses on which they listen for clients to connect. A client first communicates with
the portmap service to determine the network address it must use to contact an RPC service. You can list
current RPC services by using the rpcinfo command, which communicates with the portmap service.
CAUTION: Typically, the RPC services available in most Linux distributions are not secure.
This situation is not true of other operating systems, such as the Solaris OE, that implement
protocols such as AUTH_DH and RPCSEC_GSS and have the ability to restrict RPC usage to a
local system using RPC that is implemented over TLI. For more information on AUTH_DH,
RPCSEC_GSS, and TLI, refer to the Solaris documentation available at http://docs.sun.com/.
Given that the Sun Linux operating system does not support these capabilities, unless RPCbased services are required to support a business function, such as accessing or sharing files
via NFS, then disable them.
Securing the Linux OS
Page 36 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
To Disable the RPC portmap Service


Use the following commands together:
# /sbin/chkconfig -level 0123456 portmap off
# /etc/rc.d/init.d/portmap stop
The first command prevents the RPC portmap service from starting at boot time and the second
command stops any currently running instances of the portmap service.
The second command illustrates how you can disable a service without the need for a reboot.
You could omit the second command, but then a system reboot would be required to completely
disable the service.
NOTE: This approach to disabling services applies to any services managed by the
chkconfig command. Use this command to either allow or prevent a service from
starting at boot time. It does not start or stop services on a running system.
CAUTION: Be aware that stopping the portmap service does not directly prevent RPC
services from running on a system. In particular, if an RPC service is configured to
listen on a fixed port, such as through xinetd, then it can still be accessed. Be sure
to review the contents of the /etc/xinetd.d directory for services with type
parameters that include RPC. For these services, disable or restrict access to them.
Disable or Secure automount Services
The automount service automates the process of mounting file systems and devices without requiring that
users have administrative privileges on a system. This process is accomplished using the kernel level
autofs service with the automountd system daemon. File systems mounted by this service are
automatically unmounted after a predefined period of inactivity.
In Sun Linux, the automount service is capable of mounting not only NFS shares but also removable media
such as CD-ROMs and diskettes. Typically, the automount service is used heavily in environments that use
naming services such as NIS or LDAP, because remote file system information used by this service can be
easily stored in these directories. It can be used on a standalone system as well, where there might be a
requirement for automatically mounting local removable media. As with any service, if the automount
service is not required to support business functions, it should be disabled or removed.
To Disable autofs

Use the following command:
# /sbin/chkconfig -levels 0123456 autofs off
Securing the Linux OS
Page 37 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
To Remove autofs
Use the following command:
# rpm -e autofs
If the automount service is required, then take steps to ensure that its configuration is as secure as
possible. First, ensure that the automount service is configured to obtain its information from the correct
naming service (for example, files, NIS, LDAP, etc.). Next, ensure that the file systems listed in the
automount configuration are mounted appropriately.
For example, the /etc/auto.misc file can be configured to mount various forms of removable media. If
this file is configured improperly, a user could mount a diskette, formatted as a Linux (ext2) file system,
that contains set-user-ID binaries. These binaries could then be run, giving the user added privileges and
possibly allowing the entire system to be breached. To prevent this situation, ensure that only valid
devices are listed and that mount options are added, where appropriate, to the automount service
configuration files such as /etc/auto.master and /etc/auto.misc.
In the next example, the keywords nosuid and nodev are added to the /etc/auto.misc file for the cd and
floppy resources. This action instructs the system to ignore set-user-ID or set-group-ID bits set on any files
mounted on the devices, and to not interpret any character or block special devices stored on them as
well. This change is made because the Sun Linux NFS implementation does not currently support NFSSEC.
Consequently, the NFS services are not able to use strong authentication or encryption such as is provided
by Kerberos.
cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
floppy -fstype=auto,nosuid,nodev :/dev/fd0
NOTE: These options are part of the standard configuration provided by Sun Linux. For other
mount options, refer to the mount(8) manual page.
CAUTION: Some mount options are specific to certainly file system types. Always be sure to
use the correct options for the file systems that you are using.
Secure the NFS Services
A Sun Linux system can be an NFS server, an NFS client, both, or neither. From a security perspective, the
best option is to neither provide NFS services nor accept them from any other systems as long as they are
not required.
If both NFS server and client services are not required, they can be uninstalled by removing the nfs-utils
package as follows:
Securing the Linux OS
Page 38 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
# rpm -e nfs-utils
If either the NFS client or server services are needed, then this package should not be disabled because
both the client and server software is contained in the same package.
By default, the NFS client service is enabled, whereas the server service is disabled.
To Disable the NFS Client Service


Use the following commands:
# chkconfig --level 0123456 nfslock off
# /etc/rc.d/init.d/nfslock stop
The first command prevents the NFS client service from starting at boot time. The second
command stops the NFS client service if it is already running on a system.
Frequently, business requirements require an NFS server. If this is the case, ensure that the NFS
server configuration is as secure as possible.
To Improve Security of the NFS Server Configuration
1.
Explicitly list hosts allowed access to NFS server directories.
2.
Do not open access to all systems.
3.
Export only the lowest directory necessary.
4.
Never share more data than is needed to meet the business requirement.
5.
Export read-only wherever possible. In addition, consider the use of other flags such as
secure and root_squash.
For more information on these options, refer to the exports(5) and mount(8) manual pages. The
NFS server and various mechanisms available to secure it encompass more material than can be
covered here.
Secure the sendmail Services
The sendmail daemon forwards and receives mail from other systems. You should use centralized mail
servers to receive mail instead of using local servers. However, allow local systems to generate outgoing
mail and forward it to other servers.
Ideally, a more secure Mail Transport Agent (MTA) should be used instead of the MTA bundled with Sun
Linux. The sendmail daemon bundled with Sun Linux has been subject to denial of service, buffer
overflow, and misconfiguration attacks. Alternative MTAs with smaller and more robust code are
available. These other MTAs are more security conscious and if configured properly, compromise the
security of the server less than sendmail.
Securing the Linux OS
Page 39 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
If sendmail must be used as the Mail Transfer Agent (MTA), then refer to recommendations made at
SendMail Consortium, in the Sendmail O'Reilly publications, and through the SunSolve OnLine SM service.
There are a wide variety of sendmail versions in use, and there are differences in the associated
sendmail.cf configuration files. Because of this, a sample sendmail.cf file is not included with this
lesson.
If sendmail is not required or only outgoing sendmail is required, we recommend that you remove,
disable, or enable only outgoing sendmail. The following sections provide instructions and
recommendations.
To Remove or Disable sendmail
If no sendmail functionality is required to support a business need, remove or disable it. Base your
decision on the need to provide outgoing mail from a system. If this capability is needed, then do not
remove the sendmail software.

To remove the sendmail software, use the following command:
# rpm -e sendmail sendmail-cf sendmail-doc


To disable the sendmail service, use the following commands:
# chkconfig --level 0123456 sendmail off
# /etc/rc.d/init.d/sendmail stop
The first command prevents the sendmail service from starting at boot time. The second
command stops the sendmail service if it is already running on a system.
To Allow Only Outgoing sendmail
The sendmail daemon is not needed for email delivery to other systems. All messages that can be are
immediately delivered. Messages that cannot be immediately delivered are queued for future delivery.
The sendmail daemon, if running, retries to deliver these messages again.

To enable only outgoing sendmail, use a cron job to start sendmail every hour to process
undelivered messages.
The following cron entry starts sendmail every hour to flush the mail queue:
0 * * * * /usr/lib/sendmail –q
Configure Name Service Caching
The name service cache daemon nscd provides caching for name service requests. It exists to provide a
performance boost to pending requests and to reduce name service network traffic. By default, the nscd
Securing the Linux OS
Page 40 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
package is installed, but the nscd daemon is disabled. This section applies only if you need to enable the
nscd daemon.
The nscd daemon maintains cache entries for databases such as passwd, group, and hosts. For security
reasons, it does not cache the shadow password file. All name service requests made through system
library calls are routed to nscd.
Because caching name service data makes spoofing attacks easier, we recommend that you modify the
configuration of nscd to cache as little data as possible. This task is accomplished by setting the positive
ttl to zero in the /etc/nscd.conf file for the name service requests deemed vulnerable to spoofing
attacks. In particular, modify the configuration so that passwd and group have positive and negative ttl
values of zero.
NOTE: There might be a performance impact on systems that use name services intensively.
Use the nscd -g option to view the current nscd configuration on a server. This option is a helpful
resource when tuning nscd.
Secure Print Services
When a Sun Linux system is installed, the line printing package is installed, but needs to be configured. By
default, the lpd daemon is not started.
To Secure Print Services
1.
To ensure that line printer services are not started, disable the package at startup by using
the following command.
# /sbin/chkconfig --level 0123456 lpd off
2.
If printing services are not required for the system, remove the package by using the
following command:
# rpm -e LPRng
Display Access Warnings
Displaying access warnings allows companies to pursue full legal recourse if a system is accessed or
compromised by unauthorized users. These warnings contain messages about inappropriate and
unauthorized use of a system. They generally warn users that their sessions and accounts might be
monitored for illegal or inappropriate use. Consult your legal counsel for requirements and verbiage.
Securing the Linux OS
Page 41 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
The contents of the /etc/issue file are displayed for local and serial access. The contents of
/etc/issue.network are displayed for incoming Telnet connections. Also, you can use the message of the
day /etc/motd file.
The following is an example warning.
This system is for the use of authorized users only.
Individuals using this computer system without authority, or in
excess of their authority, are subject to having all of their
activities on this system monitored and recorded by system
personnel.
In the course of monitoring individuals improperly using this
system or in the course of system maintenance, the activities
of authorized users may also be monitored.
Anyone using this system expressly consents to such monitoring
and is advised that if such monitoring reveals possible
evidence of criminal activity, system personnel may provide the
evidence of such monitoring to law enforcement officials.
If sendmail service must be configured to run on a system, then consider modifying the banner message
that is displayed to clients connecting to a service on TCP port 25. By default, the banner includes host
name and version information that might be used by attackers and automated vulnerability scanners.
Changing the banner text does not impact the ability of the service to function.
To Change the Banner Message
1.
Add the following line to the /etc/mail/sendmail.mc file and rebuild the configuration file:
define(´confSMTP_LOGIN_MSG', ´´Mail Server Ready'')dnl
2.
Place the line after the include directive in this file, and before any FEATURE lines.
If you modify the contents in /etc/sendmail.cf file, which is generated from the
/etc/mail/sendmail.mc file, all changes are lost at the next generation cycle.
3.
To generate the /etc/sendmail.cf from the /etc/mail/sendmail.mc file, do the following:
# m4 /etc/mail/sendmail.mc > /tmp/sendmail.cf
Securing the Linux OS
Page 42 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Turning Kernel Network Parameters
Configure kernel variables to improve network security. Some changes might cause a system to not
strictly comply with relevant RFCs and might require testing before being placed on production systems.
Configure kernel variables by performing the following tasks:

"Configure IP Forwarding"

"Disable Source Routing"

"Ignore Broadcast ICMP ECHO Packets"

"Log Invalid Addresses"

"Configure ICMP Redirect Messages"

"Use Source Route Verification"

"Disable Protocol Stacks"
Configure IP Forwarding
During startup, the /etc/sysctl.conf file is read by the sysctl command. This file contains settings for
kernel parameters.
You can disable or enable IP Forwarding by assigning net.ipv4.ip_forward to the kernel parameter.
Assigning a 0 disables and assigning a 1 enables forwarding. Be aware of the following:

Assigning a 0 resets all IPv4-related variables to conform with RFC 1122 (requirements for
Internet hosts–communication layers).

Assigning a 1 resets all variables to conform with RFC 1812 (requirements for IP version 4
routers).
NOTE: It is important to set this kernel parameter first, before changing any other
related parameters.
To Disable or Enable IP Forwarding

To disable IP forwarding, set the parameter in the /etc/sysctl.conf file as follows:
net.ipv4.ip_forward = 0

To enable IP Forwarding, set the parameter in the /etc/sysctl.conf file as follows.
net.ipv4.ip_forward = 1
Securing the Linux OS
Page 43 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Disable Source Routing
Source routing has been used in attacks, and legitimate uses of source routing are few. It is a good idea to
discard all packets that use source routing, unless you have a specific need for them.
To Disable Source Routing

Add the following lines to the /etc/sysctl.conf file:

net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_source_route = 0
The first line disables source routing on all current interfaces. The second line provides a default
for any new interfaces that might be configured later.
Ignore Broadcast ICMP ECHO Packets
Many operating systems respond to ICMP ECHO (ping) packets that are sent to the network broadcast
address. This behavior has been used to mount denial-of-service attacks by causing all hosts on a network
segment to send ICMP REPLY packets to a host under attack. Our advice is to disable this behavior.
To Disable Echo Broadcasts

Add the following line to the /etc/sysctl.conf file:
net.ipv4.icmp_echo_ignore_broadcasts = 1
Log Invalid Addresses
When a kernel receives packets with obviously invalid addresses, they are discarded.
To Log Invalid Addresses

Add the following two lines to the /etc/sysctl.conf file.

net.ipv4.conf.default.log_martians = 1
net.ipv4.conf.all.log_martians = 1
Configure ICMP Redirect Messages
ICMP redirect messages are used by network gateways to inform a host sending data to forward packets to
a different gateway. If a Sun Linux system is not configured to act as a gateway, that is the
net.ipv4.ip_forward parameter is set to 0, then the system should never need to send ICMP redirect
messages.
Securing the Linux OS
Page 44 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
To configure the system to never send ICMP redirect messages, add the following line to the
/etc/sysctl.conf file.
net.ipv4.send_redirects = 0
Similarly, if you only have one gateway on the network to which the host is attached, then it is safe to
ignore any incoming ICMP redirect messages. These messages could not be generated in such a case,
because there is only one path out of the network.
An attacker can forge redirect messages to install bogus routes. This action might initiate a denial of
service attack if a newly specified router is not a router at all. Similarly, this technique could be used to
force network packets to be routed through an attacker's machine, where the packets could be inspected,
captured, or modified. Although there are rules governing valid ICMP redirect messages, all of them can
be easily spoofed.
If possible, configure the system to ignore ICMP redirect messages by adding the following line to the
/etc/sysctl.conf file.
net.ipv4.accept_redirects = 0"
Use Source Route Verification
The Sun Linux source route verification mechanism verifies that a packet comes in on an expected
network interface. The routing table is consulted for each incoming packet. The interface the packet
comes in on must match the interface that would be used to reach the source of the packet. If these
interfaces do not match, the packet is discarded. This feature is enabled by default.
Source route verification adds overhead to packet processing and might not work in environments where
asymmetric routing occurs. Source route verification is controlled by the following parameters.

net.ipv4.conf.default.rp_filter

net.ipv4.conf.all.rp_filter
Our recommendation is to leave it enabled unless it causes performance or routing problems.
To Disable Source Route Verification

Add the following lines to the /etc/sysctl.conf file:

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
Securing the Linux OS
Page 45 of 47
ITSY243-Intrusion Detection Systems
Prof. Michael P. Harris
Protocol Stacks
The kernel supports on-demand loading of kernel modules. Many components of the kernel such as file
systems, protocol stacks, and device drivers are loaded the first time they are needed. The process of
loading a required kernel module is quite simple: the kernel creates a new user process and runs the
program /sbin/modprobe, which loads the required module.
This simple and effective mechanism has one drawback: protocol stacks other than TCP/IP might be
loaded inadvertently. When a network socket is created for protocol family N, the kernel executes the
following command.
# /sbin/modprobe -s net-pf-N
The protocol stack is loaded. We recommend that you disable all unnecessary protocol stacks.
To Disable All Unnecessary Protocol Stacks

Modify the following lines to the /etc/modules.conf file:

alias net-pf-4 off # IPX

alias net-pf-5 off # Appletalk

alias net-pf-10 off # IPv6
alias net-pf-12 off # Decnet
References and Related Resources
Publications

Hatch, Brian, and Osborne, James Lee. Hacking Linux Exposed, Second Edition McGraw-Hill,
ISBN: 0072225645, November 2002.

Nemeth, Evi, Snyder, Garth, Seebass, Scott, and Hein, Trent R. UNIX System Administration
Handbook, 3rd Edition, Prentice Hall PTR, ISBN: 0130206016, August 2000.

Noordergraaf, Alex. "Solaris Operating Environment Network Settings for Security: Updated for
Solaris 9 Operating Environment," Sun BluePrints OnLine, June 2003,
http://www.sun.com/solutions/blueprints/0603/816-5240.html.

Noordergraaf, Alex and Watson, Keith. "Solaris Operating Environment Security: Updated for the
Solaris 9 Operating Environment," Sun BluePrints OnLine, December 2002,
http://www.sun.com/solutions/blueprints/1202/816-5242.pdf.

Red Hat Linux 9: Red Hat Linux Security Guide, Red Hat Inc., 2002.

Reid, Jason. "Building OpenSSH - Tools and Tradeoffs," Sun BluePrints OnLine, January 2003,
http://www.sun.com/blueprints/0103/817-1307.pdf.

Reid, Jason. "Configuring the Secure Shell Software," Sun BluePrints OnLine, April 2003,
http://www.sun.com/blueprints/0403/817-2485.pdf.
Securing the Linux OS
Page 46 of 47
ITSY243-Intrusion Detection Systems

Prof. Michael P. Harris
Reid, Jason. "Integrating the Secure Shell Software," Sun BluePrints OnLine, May 2003,
http://www.sun.com/blueprints/0503/817-2821.pdf.

Stevens, Richard W. TCP/IP Illustrated, Volume 1, 1st Edition, Addison-Wesley Publishing
Company, ISBN: 0201633469, January 1994.
Web Sites
NOTE: Sun is not responsible for the availability of third-party Web sites mentioned in this
document. Sun does not endorse and is not responsible or liable for any content, advertising,
products, or other material on or available from such sites or resources. Sun will not be
responsible or liable for any damage or loss caused or alleged to be caused by or in connection
with use of or reliance on any such content, goods, or services that are available on or
through any such sites or resources.

Center for Internet Security - Linux Benchmark http://www.cisecurity.org/

OpenSSH tool: http://www.openssh.com/

Sendmail Consortium: sendmail configuration information, http://www.sendmail.org/

SSH Communications Security, Secure Shell (SSH) tool: http://www.ssh.com/

Sun BluePrints: http://www.sun.com/blueprints

TCP Wrappers tool, Wietse Venema: ftp://ftp.porcupine.org/pub/security/index.html
Securing the Linux OS
Page 47 of 47