Security for Unix Networks and Web Servers

Unix Networks

The following recommendations can be taken to secure UNIX networks.

Startup Scripts

Check the permissions and ownership of files. If they allow world access, browse scripts to see if any unusual process or script is started, especially if in user directories. Files and directories should be owned by root/root or root/sys with limited or no world write or execute permissions so that they cannot be modified or exploited by unauthorized users. User startup files should be owned by the individual user and have permissions of 640. In each user's directory, check for hidden files (e.g.,. login, .profile, etc...) that have extensions, such as .old/.backup or begin with "..", "...".

Services/Ports

Run a port scanner, such as nmap (available at http://www.insecure.org/nmap) to list open ports and services. Many UNIX services have well known security vulnerabilities associated with them, which allow root access. All unnecessary services (e.g., rexd, rquotad, talk, sadmind, kcmsd, rstatd, fs, exec, daytime, walld, fingerd, systat, rusersd, sprayd, uucpd,. chargen, time, echo, display, tftp, comsat and discard) should be disabled by placing a # at the beginning of the lines in the /etc/rc* files or in the /etc/inetd.conf file that caused the program to be executed. In addition, these ports should be blocked at the perimeter router or firewall.

System Trust

There are various ways for UNIX systems to allow access to a machine or an account without providing a password. Through the use of .rhosts ,.forward, .netrc, hosts.lpd, and hosts.equiv files, it is possible for a user on one system to access another system without providing a password. This practice should be reviewed for necessity. An intruder breaking into an authorized user's account can use those same trusts to reach multiple machines with little effort. Do not use plus signs (+) in these files as they allow wider access (to users and/or machines) than might be intended. Prohibit root from logging directly into a remote system through either the /etc/ttys, /etc/ttytab, or /dev/default/login files.

R Commands

Telnet and the "r commands" (rlogin, rcp, rsh and rexec) may transmit the username and password in the clear making it easy for an attacker with a sniffer to capture this information and act as a trusted user. If trust relationships are set up, "r" commands enable someone to access a remote system without supplying a password. If an attacker gains control of any machine in a trusted network, then he or she can gain access to all other machines that trust the hacked machine. If these services are not required, they should be disabled; otherwise, install openssh (available at http://www.openssh.com/). In addition, ssh, which includes sftp, is an alternative solution to FTP. The service encrypts all traffic including the password to reduce the threat of eavesdropping. Do not allow trust relationships.

Network Configurations

Check to see if network configuration files (such as hosts, defaultdomain, defaultrouter, netmasks, etc.) are owned by root/root and have permissions of 644. This is suggested to alleviate unauthorized modifications.

Patches

Ensure applicable system and security patches are current and have been installed. Note that patches may not be applied until a reboot occurs. Therefore, if a patch is listed in the output from "Patchdiag", "showrev", or whatever specific patch checker tool or UNIX command is used, but the machine has not been rebooted in awhile, there is a possibility that the machine may still be vulnerable.

User Accounts

Review all user accounts. Do they all have unique UIDs? This is important to enforce so that a person will not obtain the privileges associated with someone else's account or be able to read, delete, or modify another person's files. Check to make sure each shell field is set to a valid shell to alleviate malicious code from being executed and granting root access. The nobody4 account is for SunOS backward capability and should be deleted, if not needed. Make sure every line in the /etc/passwd file is in the proper format to alleviate accidental logins by an unauthorized person. Permissions for most home directories should be 740. Ftp and uucp users may be exceptions. Check automount directories for unauthorized. automount maps. All maps should be protected with permissions 755 and owned byroot/root.

System administrators should not directly log in as root, but rather as themselves and then switch user (su) to root. This is important for accountability. An administrative group (e.g. wheel) should be created in the /etc/group file and each administrative user should belong to that group. Once the administrative group has been created, the "su" program should have its ownership, group, and permissions changed (root/wheel, 750).

Permissions

Look for 'setuid' or 'setgid' files and programs. Drop the 'suid' and/or 'sgid' bits, if not needed. Look for world writable directories and files and drop the world permissions, if not needed. This will help prevent unauthorized access or the insertion of malicious code. Also check for files owned by root and are mode world read/write. These files may indicate a potential symbolic link attack if one of the parent directories are writable by the attacker. Check umask values. Suggest that user umasks be set to 022.

Cron/At Jobs

Check permissions on cron and at job .allow and .deny files. They should be 644, root/sys. .allow files permit users to use crontab and atjobs. .deny restricts these users from access. If .allow files do not exist, then the system checks the .deny files. If neither file exists, depending on system configurations, it either allows just root or everyone to write cron/at jobs. Check to make sure that all cron and at jobs have valid users associated with them. Crontab and atjob files should be owned by the specific user associated with them and have permissions of 600. Make sure that all cron or at jobs use absolute paths (full path names).

Core Dumps

Check for core files. Most reside in the "/" directory, but others may be located elsewhere. Core files may contain sensitive system data or user passwords. Remove core files from the system. Configure the system so that when core files are created, they are automatically redirected to /dev/null or have a ulimit=0.

Network Services

NIS

Ensure NIS maps do not contain system accounts. Establish a securenets file in the NIS environment as an effective way to secure access. Look for strange entries within the NIS ypserv.log file. This is suggested to prohibit unauthorized access.

NIS +

Check to see if NIS + is running in yp compatibility mode. If the "-YP" argument is there, the server is in NIS emulation mode and all exploits for NIS apply. Delete nobody permissions so that unauthorized persons don't have access to the NIS+ tables. Make sure world is given read-only permissions, except for the password table, which shouldn't allow any world access. When checking table permissions and access rights, they should match. Individual users should only have read access to the password table to prevent users from changing their UID value to 0, which would give them root access.

NFS

Ensure the NFS environment is not exporting sensitive file systems to the world (i.e., /etc,) regardless of permission settings. Ensure no critical file systems are shared to the world with read-write access. Ensure exported file systems are directed to specific hosts via the /etc/dfs/dfstab file or via netgroups. Ensure files are not exported to "localhost". Ensure files are shared with the "nosuid" designator, unless suid is required. Ensure the anonymous user has been established correctly. If the system has anon=0, then "root" users of remote machines will have the UID specified after the "=" equal sign. If the "root=" user has been established, then root users of the machines specified after the "=" equal sign will have a UID of zero on the remotely mounted file systems. Check all clients and servers to see which file systems are being mounted locally or remotely.

DNS

The Domain Name Service is the mechanism that Internet hosts use to determine the IP address that corresponds to a given hostname. Attackers often attempt zone transfers in order to gather information about a local network. One way to prevent zone transfers is to block tcp port 53. This can be done via firewall or or router access filters. Disable the BIND name daemon (named) on systems not authorized to be DNS servers. On the servers, upgrade to the latest version of BIND and run it as a non-privileged user. Run DNS in a chrooted environment. Hide the version string via the version option in named.conf.

Sendmail

Upgrade to the latest version of Sendmail. Do not run Sendmail in daemon mode (turn off the -bd option) on machines that are not mail servers or relays. Do not display the version number through sendmail banners. Ensure that the decode alias is not available. Decode should be removed or commented out of the /etc/aliases file so that it does not pipe to the 'uudecode' command and allow an attacker to overwrite system files. Check for .forward files as they can open up the system to attacks. If not needed, remove them or link to /dev/null. If needed, permissions should be 740 and owned by the user. If the system is not a server or does not have to listen for incoming mail, rename the sendmail startup script, binaries, and configuration files and change their permissions to 000.

Logs

System logging is crucial for troubleshooting and tracking unauthorized user accesses. Ideally, logs should be kept locally AND sent to a central loghost that does nothing but accept and store log messages. Your network security policy should help dictate which events need to be audited. Logcheck and swatch are tools that system administrators can use to examine log files for unusual activity, based on key phrases or specially set string patterns. They can also send emails to the system administrators, alerting them to possible unauthorized activity. Both are open source tools.

X-Window Environments

Remove the X Windowing environment on the server. By removing the Common Desktop Environment (CDE) and/or SUN's OPENWINDOW environment, the network server will not be susceptible to a variety of vulnerabilities.

Distributed Server Functions

It is commonly considered a good security practice to distribute the server functions of a network among separate systems. For instance, the DNS server should be separate from the mail server, which should be separate from the firewall, etc. A number of products, such as. Borderware's firewall product, include the software to run a web server, mail server, DNS server and other server functions all from the firewall. However, this presents a single point of failure for the network and therefore an avoidable vulnerability. Ideally, network servers should be set apart from the user segment in a secure DMZ or secure server network. Most firewalls allow this and if it does not, it can easily be accomplished by using routers behind the firewall.

Chroot Environments

chroot() is a UNIX command used to run a command or interactive shell with a special root directory. This command can also be used to create a "virtual" operating system and directory tree. It would be inside of the new "virtual" directory tree that DNS, Sendmail, Web, and other various servers could run. This would provide a potentially safe location for the applications. Building a chroot()ed environment can be very useful in protecting the rest of the system and keeping hackers out, however, it is easy to make a mistake while creating this chroot()ed environment. If it is improperly installed, it could create more ways for the hacker to infiltrate the machine.

Interesting Files

Check for files that have no permissions or have invalid owners or groups. Sometimes admins will have specific files which have no permissions assigned to them. These files can be kicked off by a script, cronjob, or app that temporarily changes the permissions during the execution of the program, then resets the program back to the original state.

Peripheral Devices

Consider removing or restricting access to local or network peripheral devices. Malicious code is easily introduced into secure networks via their peripheral devices. If an external device is not required for a specific client or server, have it removed. If the device cannot be removed, disable access to it via the hardware or software. Check to see if local and network printers are secure. Floppies should not be introduced to a client or server without the prior consent of the local Network Security Officer representative.

Buffer Overflows

Ensure that SOLARIS systems have a non-executable stack environment enabled. This will help prevent buffer overflows that originate from within the memory stack. For buffer overflows in RPC services, block the RPC port 111 at the router or firewall.

System Utilities and Commands

Restrict access or remove system utilities such as compilers, debuggers, etc. These utilities aid an adversary in informational reconnaissance. System commands like "strings" and "ln" should either have their permission bits restricted or have them removed form the system.

Current OS Packages

Ensure that the system packages are current. Solaris 7 and 8 can check the integrity and accuracy of system packages. Sometimes malicious code can be introduced to a system as a system package.

Rootkits

There are several scripts that can be implemented on a UNIX system that will search for

rootkits on clients and servers. Checking the integrity of system files against a master backup known not to be altered by malicious code is also a good practice.

Security Tools

To ensure and maintain the integrity of the network servers, it is important to constantly monitor them for signs of malicious activity. There are a number of tools that can aid an administrator in this task. Two of these tools that are commonly implemented are Tripwire and TCPD.

Tripwire

Tripwire monitors the permissions and checksums of important system files to easily detect files that have been replaced, corrupted, or tampered. For example, if an intruder gains access to the server and replaces the /bin/ls command with one that performs unwanted functions, tripwire will send an alert. Tripwire will send the system administrator a report each night. Tripwire calculates the checksums of executable files from a clean install. It then recalculates these checksums and compares them on a regular basis. Since some hackers are skilled enough to spoof the checksums on modified files, tripwire uses two different checksum methods. It is important to save the original checksums on a non-rewriteable CD on the system. This ensures data integrity.

TCPD

TCPD, also referred to as "TCP wrappers," allows one to log connections to TCP services such as telnet, rlogin and finger. In addition, it allows one to restrict which systems can connect to these services via two files, hosts.allow and hosts.deny. Both of these features can be very useful when tracking or controlling unwanted guests on a network. TCPD is easy to install and does not require modification to existing network programs. Just modify the /etc/inetd.conf file to execute TCPD instead of the actual program. TCPD will then do any necessary logging and security checks before running the real daemon. For example, if the /etc/inetd.conf originally contained this line: telnet stream tcp nowait root /etc/in.telnetd in.telnetd

Change it to this:
telnet stream tcp nowait root /usr/etc/tcpd in.telnetd.

Unix Web Servers

This section describes security configuration for UNIX web servers, using Apache as the example. It is assumed that Apache has been installed from the distribution and that none of the security parameters has been modified that come default in the original setup.

General Guidance

Ensure that the computer that runs the web server is dedicated. It should not have other uses, e.g., being a client workstation or print server. Always upgrade to the latest version of the web server available that is not the beta version. Do not perform development work on the operational web server. All data should be in final form and simply copied into place. Create a secondary mirror of the server for all development services and experimentation. Transfer data to the web server by tape, disk, or CD. Do not use FTP or telnet for data transfer. Remove all unnecessary services on the web server, including FTP, telnet, and X Windows. If that is not an option, make sure to run tcpwrappers on the open services. Use a port scanner to check for open ports on both the TCP and UDP protocols. If possible, use command line interfaces instead of X Windows. Using an X windowed interface opens up ports that cannot be effectively closed and still have the system remain functional. Since the server should be in production mode only, only a command line is required to update the site. Testing of the site should be done from a separate client.

Isolate the web server physically and virtually. If possible allow local access to the web server to the fewest number of people with a minimal number of users. Keep the web server close to the administrator, the web engineer, or the webmaster. Keep the web server on a LAN segment separate from the rest of the IT infrastructure. Do not mount or share services to and from the server.

Example: Apache

The latest version of Apache is available at
http://httpd.apache.org

Ensure the user running the Apache web server is set to nobody. In the httpd.conf file in the /usr/local/apache/conf directory, make sure that the effective user is nobody and that the group option is also set to nobody. Below are the lines to add to the file.

User nobody

Group nobody

Ensure that user nobody does not own or have write access to the htdocs or cgi-bin subdirectories or any other subdirectory under these. Below are the commands to set ownership of these directories to root and to restrict write access to only root.

chown -R root /usr/local/apache/htdocs.

chown -R root /usr/local/apache/cgi-bin

chmod 755 /usr/local/apache/htdocs

chmod 755 /usr/local/apache/cgi-bin

Do not store cgi-bin related data in a directory accessible to the web server. For example, create another directory called cgi-data in /usr/local/apache alongside cgi-bin and htdocs. Have the cgi scripts use that directory for data storage and manipulation.

Turn off AutoIndexing and Follow Symbolic Links. By default, Apache usually comes with automatic indexing of directories enabled. Look in the httpd.conf file (usually in the /usr/local/apache/conf directory) for the following line.

Within those set of options you will see an Options line that may look like the following.

Options Indexes FollowSymLinks Multiviews

This configuration means any requests for a directory that do not find an index file will build an index of what is in the directory. Also, any symbolic link in the document directory will also be followed even if it is outside of the web server's purview. For example, a symbolic link may be made to the root directory, giving at least read access to a great deal of the system as the owner of the web server process. For the most secure/functional Directory options, this segment of the httpd.conf file should look like the following.

Options Multiviews

AllowOverride None

Order allow,deny

Allow from all

Refer to the following URLs for further guidance:

http://httpd.apache.org/docs/misc/security_tips.html

http://www.linuxplanet.com/linuxplanet/tutorials/1527/1/

http://www.modperl.com/perl_conference/apache_security/

http://www.bignosebird.com/apache/a11.shtml.