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 xinetdxinetd-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-42error: 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} fidone

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-11S.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.9-31enterprise. In practice, there exist multiple kernel definitions or image entries in the /etc/lilo.conf, often as a result of kernel upgrades. We recommend that you define these options for each of the kernels listed in your /etc/lilo.conf file.

NOTE

The version number (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 single-user password restrictions using the command linux init=/bin/bash instead of the linux single command at the LILO boot prompt.

Disable the Magic SysRq Key

If enabled, the SysRq key can be used for activities such as rebooting systems, inspecting memory, synchronizing disks, and killing processes. It is mainly useful to kernel developers, because it allows them to diagnose and recover a system state after problems. However, be aware that it can be used to gain unauthorized root access.

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. World-writable objects are problematic because any user can modify the object. An attacker might use a world-writable file to perform a disk space-based denial of service attack on a system, or an attacker might modify the object, violating its integrity. 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 19PATH=/bin:/usr/binexport PATHHNAME="'uname -n'"UNAME="'id | awk '{ print $1 }''"logger -i -p auth.crit "Unauthorized access attempt on ${HNAME} by ${UNAME}"

waitexit

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=attackeriduid=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 operatorsUser_Alias OPERATORS = tom, dick, harrietCmnd_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 specificationUser_Alias OPERATORS = tom, dick, harriet

# Cmnd alias specificationCmnd_Alias PASSWDCMD = /usr/bin/passwd, !/usr/bin/passwd root# Defaults specificationOPERATORS 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 specificationUser_Alias OPERATORS = tom, dick, harrietUser_Alias WEBMASTERS = josephine, OPERATORS

# Cmnd alias specificationCmnd_Alias PASSWDCMD = /usr/bin/passwd [!-]*, !/usr/bin/passwd rootCmnd_Alias BACKUPCMD = /usr/sbin/backup_scriptCmnd_Alias HTTPDCTL = /etc/rc.d/init.d/httpd

# Defaults specification

Defaults authenticate, timestamp_timeout = 60

# User privilege specificationroot ALL=(ALL) NOPASSWD: ALL

OPERATORS ALL = (root) PASSWDCMDOPERATORS ALL = (root) BACKUPCMDWEBMASTERS 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.

typeThis field is the management group and can be one of the following:

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.

controlThis 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.

module-arguments

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.soauth required /lib/security/pam_tally.so onerr=fail  no_magic_rootauth sufficient /lib/security/pam_unix.so likeauthauth required /lib/security/pam_deny.so

account required /lib/security/pam_unix.soaccount 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=3password sufficient/lib/security/pam_unix.so use_authtok  md5 shadow remember=15password required /lib/security/pam_deny.so

session required /lib/security/pam_limits.sosession 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_fromSpecifies 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 = 192.168.1.0/24 bind = 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.allowALL: LOCAL 10.8.10.0/255.255.255.0 10.8.11.0/255.255.255.0portmap: 10.8.31.100sshd: 10.0.0.0/255.0.0.0 192.168.0.0/255.255.0.0# cat /etc/hosts.denyALL: 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 sufficient /lib/security/pam_rhosts_auth.so auth required /lib/security/pam_stack.so service=system-auth account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth

session required /lib/security/pam_stack.so service=system-auth

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 set-group-ID bits set on any files mounted on the devices, and to not interpret any character or block special devices stored on them as well. This change is made because the Sun Linux NFS implementation does not currently support NFSSEC. Consequently, the NFS services are not able to use strong authentication or encryption such as is provided by Kerberos.

cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdromfloppy -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 inexcess of their authority, are subject to having all of theiractivities on this system monitored and recorded by systempersonnel.

In the course of monitoring individuals improperly using thissystem or in the course of system maintenance, the activitiesof authorized users may also be monitored.

Anyone using this system expressly consents to such monitoringand is advised that if such monitoring reveals possibleevidence of criminal activity, system personnel may provide theevidence 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