ITSY 2400 – Operating System Security
Prof. Michael P. Harris
(Ver20051107)
Securing the Linux Operating System (Part 1)
This Lab 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 “hands-on” Lab is the first part of a two-part series that provides recommendations for
specifically securing a Sun™ Linux 5.0 operating system. Most of the instructions,
techniques, and procedures apply to most distributions of Linux and Unix. This first Lab
provides recommendations for securing local access and file systems.
“Securing the Linux Operating System” Part 2 will provide recommendations for securing
network access and services. The information in this lab applies specifically to the Sun Linux
5.0 distribution, although some techniques or recommendations might 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. A layered
approach (DiD) is highly recommended to security where protection is implemented for both
local and remote threats, resulting in a more robust security configuration.
Sun Linux is based on Red Hat Linux so those of you who are familiar with Red Hat systems
will find most all the commands familiar. To secure a Linux system against unauthorized
access and modification requires changes to its default configuration. These changes are
in most cases relatively minor, so I strongly recommend that you make these changes to
improve the security of your system. The changes and recommendations in both labs address
the majority of methods that intruders use to gain unauthorized or privileged access to
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 lab 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 lab requires planning, testing, and documentation.
Installing and Patching
Since the initial release of Sun Linux, Sun has released 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.
It is strongly recommend that you apply all security patches to a system immediately after
installing it.
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 distribution 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 cannot 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 Sun and most other Linux systems 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. This step is recommended to
ensure that patches applied are only those provided by Sun or a known trusted
provider.
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, Most Linux distributions offer a security
bulletin mailing list. These lists are for administrators who want to receive security bulletins
directly from the Sun Security Coordination Team. 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. Your distribution may offer this service.
In this Lab, this process must be done manually to ensure that all available and applicable
patches are installed.
NOTE
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 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, Red Hat, and other Linux systems use 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 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. Some services might allow a system to be compromised, due to incorrect
configuration. System services under the 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
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. 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, verify the integrity of the 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}
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/.
Other methods can provide a higher degree of assurance, but those methods are outside the
scope of this lab.
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
For the next section we will assume your Linux 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
A system's BIOS perform 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 provide basic security
features.
To access the BIOS configuration, a user usually presses the DEL, F12 , or 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.
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.
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
non-critical 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 usually 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.

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 system's 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 BIOS configuration to specify the boot 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 system's 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
Many Linux systems use 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"

read-only
root=/dev/sda3
In this example, the password and restriction options are added to the kernel 2.4.931enterprise. 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 (example) 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, most Linux systems reboot when the key combination Control-Alt-Delete is
pressed.
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
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 singleuser 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.
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
Most Linux operating systems provide 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, Administrators should 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 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.
Configuring the File System
The default file permissions on some files might not be adequate in all situations; therefore,
configure the Linux file system to provide additional protection. Also, several mount options
are available to increase security, when used effectively. 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, Most Linux
systems offer fixes and provide patches.
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.
Review World-Writable File System Objects
A world-writable object is one that has the world-write permission bit set. Worldwritable 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. All world-writable
objects should 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
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 Sun 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. Some of these
accounts exist to support software subsystems that are not used or are for backwards
compatibility.
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.
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.
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, You restrict access to the at, batch, and
cron commands to prevent attacks and abuse.
By default, Most Linux systems 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>]
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, you should
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.
# 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.
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.
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 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:




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
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
Linux can be configured to verify that passwords cannot be guessed easily. On most Linux
systems, 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.
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.
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 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 lab.
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.

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/
To reference Sun BluePrints OnLine labs, visit the Sun BluePrints OnLine Web site at:
http://www.sun.com/blueprints/online.html
Part II
This lab is the second part of a two-part lab that provides recommendations for securing the
Sun™ Linux 5.0 operating system. This part provides recommendations for network security.
Part I provides recommendations for securing local access and file systems. The information in
this lab applies only to the Sun Linux 5.0 distribution, although some techniques or
recommendations might apply to other Linux distributions.
Sun Linux 5.0 is based on the Red Hat 7.2 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 lab 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 lab might not apply to your environment.
Removing some services as recommended in this lab 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 lab requires planning, testing, and
documentation.
This lab 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.
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-in-depth 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 lab, 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 public-key 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 to the Sun BluePrint Online labs 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
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.
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
only_from
bind
= 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: 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 host-based 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.
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

password 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
session required /lib/security/pam_stack.so service=system-auth
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.
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 RPC-based services are
required to support a business function, such as accessing or sharing files via NFS,
then disable them.
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
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 setgroup-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:
# 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.
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 OnLineSM 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 lab.
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 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.
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
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"
For more information about IP forwarding, source routing, broadcast ICMP ECHO packets, and
source route verification, refer to the detailed descriptions in the Sun BluePrint OnLine lab
titled "Solaris Operating Environment Network Settings for Security: Updated for Solaris 9
Operating Environment."
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
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.
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
Disable 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.

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