Linux & Security

p

Hardening the operating system

Linux is capable of high-end security; however, the out-of-the-box configurations must be altered to meet the security needs of most businesses with an Internet presence. Here i shows you the steps for securing a Linux system—called
hardening the server—using both manual methods and open source security solutions. The hardening process focuses on the operating system, and is important
regardless of the services offered by the server. The steps will vary slightly
between services, such as e-mail and Hypertext Transfer Protocol (HTTP), but are essential for protecting any server that is connected to a network, especially the Internet. Hardening the operating system allows the server to operate efficiently and securely. I include the essential steps an administrator must follow to harden a Unix system; These steps include

• updating the system
  
• disabling unnecessary services
  
• locking down ports, logging, and
  
• maintenance.
  

Open source programs allow administrators to automate these processes using:

• Bastille
• sudo
  
• logging enhancers such as SWATCH, and possibly
  
• antivirus software
  

Before you implement these programs, you should first understand how to harden a system manually.

Updating the Operating System
An operating system may contain many security vulnerabilities and software bugs
when it is first released. Vendors, such as Red Hat, provide updates to the operating system to fix these vulnerabilities and bugs. In fact, many consulting firms recommend that companies do not purchase and implement new operating systems until the first update is available. In most cases, the first update will fix many
of the problems encountered with the first release of the operating system.


Red Hat Linux Errata and Update Service Packages
The first step in hardening a Linux server is to apply the most current errata and
Update Service Package to the operating system. The Update Service Package
provides the latest fixes and additions to the operating system. It is a collection of
fixes, corrections, and updates to the Red Hat products, such as bug fixes, security
advisories, package enhancements, and add-on software. Updates can be downloaded individually as errata, but it is a good idea to start with the latest Update Service Package, and then install errata as necessary.

However, you must pay to receive the Update Service Packages, and the errata are free.

Many errata and Update Service Packages are not required upgrades. You need to read the documentation to determine if you need to install it. The Update Service Packages include all of the errata in one package to keep your system up to date. After you pay for the service, you can order Update Service Packages on CD, or download them directly from the Red Hat Web site.


Handling Maintenance Issues
You should apply the latest service pack and updates before the server goes live, and constantly maintain the server after it is deployed to make sure the most current required patches are installed. The more time an operating system is available to the public, the more time malicious hackers have to exploit discovered vulnerabilities. Vendors offer patches to fix these vulnerabilities as quickly as possible; in some cases, the fixes are available at the vendor’s site the same day. Administrators must also regularly test their systems using security analyzer software. Security analyzer software scans systems to uncover security vulnerabili-
ties, and recommends fixes to close the security hole. This section discusses the maintenance required to ensure that your systems are safe from the daily threats of the Internet.


Red Hat Linux Errata: Fixes and Advisories
Once your Red Hat system is live, you must make sure that the most current
required Red Hat errata are installed. These errata include bug fixes, corrections,
and updates to Red Hat products. You should always check the Red Hat site for the latest errata news.The following list defines the different types of errata found at the Red Hat Updates and Errata site.

• Bug fixes Address coding errors discovered after the release of the product, and may be critical to program functionality.

  These Red Hat Package Manager tools (RPMs) can be downloaded for free.

  Bug fixes provide a fix to specific issues, such as a certain error message that may occur when completing an operating system task. Bug fixes should only be installed if your system experiences a specific problem. Another helpful resource is Bugzilla, the Red Hat bug-tracking system.
• Security advisories Provide updates that eliminate security vulnerabilties on the system. Red Hat recommends that all administrators download and install the security upgrades to avoid denial-of-service (DoS) and intrusion attacks that can result from these weaknesses. For example, a security update can be downloaded for a vulnerability that caused a memory overflow due to improper input verification in Netscape’s Joint Photographic Experts Group (JPEG) code.
• Package enhancements Provide updates to the functions and features of the operating system or specific applications. Package enhancements are usually not critical to the system’s integrity; they often fix functionality programs, such as an RPM that provides new features.
  

Here are the steps for accessing Linux bug fixes, security advisories, and package enhancements:

1. To download bug fixes, point your browser here. Under the “Errata: Fixes and Advisories” section, click the Red Hat Linux Bug Fixes link. The latest bug fixes are available for download on this page. Click each bug to learn more, and determine whether it affects your system. Some fixes do not include software downloads, such as RPMs; instead, they explain how to configure your system to fix the problem.
2. To download security advisories, point your browser here. Under the “Errata: Fixes and Advisories” section, click the Red Hat Linux Security Advisories link. It is imperative for Linux administrators to check this Web site on a regular basis, determine if the changes are necessary, and implement the vulnerability fix.
3. To download package enhancements, point your browser here. Under the “Errata: Fixes and Advisories” section, click the All Red Hat Linux Errata link, and then the Package Enhancements link. A Red Hat Linux Package Enhancements link may also exist on the main Errata page. The available package enhancements are listed. Check the list to see if any enhancements affect your operating system or applications. If an enhancement exists, and installing it would benefit your system, download and install the corresponding package.

Manually Disabling Unnecessary Services and Ports
To harden a server, you must first disable any unnecessary services and ports. This
process involves removing any unnecessary services, such as the Linux rlogin ser-
vice, and locking down unnecessary Transmission Control Protocol/User Datagram Protocol (TCP/UDP) ports. Once these services and ports are secure, you must then regularly maintain the system. firstly we do through manually work and only after through the open source program Bastille


Services to Disable
Linux, by nature, is more secure than most operating systems. Regardless, there are still uncertainties to every new Linux kernel that is released, and many security vulnerabilities that have not been discovered. Most Linux services are not vulnerable to these exploits. However, an administrator can reduce the amount of risk by removing unnecessary services. Red Hat Linux includes many services, so
it makes sense that an administrator customize the system to suit the company needs. Remember, you are removing risk when you remove unnecessary services.


The xinetd.conf File
The /etc/xinetd.conf file (previously the inetd.conf file) controls many Unix services, including File Transfer Protocol (FTP) and Telnet. It determines what services are available to the system.The xinetd (like inetd) service is a “super server” listening for incoming network activity for a range of services. It determines the actual nature of the service being requested and launches the appropriate server. The primary reason for the design is to avoid having to start and run a large number of low-volume servers. Additionally, xinetd’s ability to launch services on demand means that only the needed number of servers is run.

The etc/xinted.conf file directs requests for xinetd services to the /etc/xinetd.d directory. Each xinetd service has a configuration file in the xinetd.d directory. If a service is commented out in its specified configuration file, the service is unavailable. Because xinetd is so powerful, only the root should be able to configure its services. The /etc/xinetd.d directory makes it simple to disable services that your
system is not using. For example, you can disable the FTP and Telnet services by
commenting out the FTP and Telnet entries in the respective file and restarting
the service. If the service is commented out, it will not restart. The next section
demonstrates how to disable the Telnet, FTP, and rlogin services.

Telnet and FTP Most administrators find it convenient to log in to their Unix machines over a network for administration purposes. This allows the administrator to work remotely while maintaining network services. However, in a high-security environment, only physical access may be permitted for administering a server. In this case, you should disable the Telnet interactive login utility. Once disabled, no one can access the machine via Telnet.

1. To disable Telnet, you must edit the /etc/xinetd.d/telnet file. Open the Telnet file, using vi or an editor of your choice.
2. Comment out the service telnet line by adding a number sign (#) before service telnet: #service telnet
3. Write and quit the file.
4. Next, you must restart xinetd by entering:

   # /etc/rc.d/init.d/xinetd restart
   Stopping xinetd:                                   [OK}
   Starting xinetd:                                   [OK}

5. Attempt to log on to the system using Telnet.You should fail.
6. Note that commenting out the service line in the respective xinetd.d directory can disable many services.
7. Disable the FTP service using the same method (e.g., edit the /xinetd.d/wu-ftpd file by commenting out the service ftp line and restarting xinetd).
8. Attempt to access the system via FTP. You should be unable to log in to
   the server.
   

The Rlogin Service The remote login (rlogin) service is enabled by default in the /etc/xinetd.d/rlogin file. Rlogin has security vulnerabilities because it can bypass the password prompt to access a system remotely. There are two services associated with rlogin:

• login and
• RSH (remote shell).

1. To disable these services, open the /xinetd.d/rlogin file and comment out the service login line.
   
2. Then, open the /etc/xinetd.d/rsh file and comment out the service shell line.
   
3. Restart xinetd to ensure that your system is no longer offering these services.

Locking Down Ports
TCP/IP networks assign a port to each service, such as

• HTTP,
  
• Simple Mail Transfer Protocol (SMTP), and
  
• Post Office Protocol version 3 (POP3).

This port is given a number, called a port number, used to link incoming data to the correct service. For example, if a client browser is requesting to view a server’s Web page, the request will be directed to port 80 on the server. The Web service receives the request and sends the Web page to the client. Each service is assigned a port number, and each port number has a TCP and UDP port.

For example, port 53 is used for the Domain Name System (DNS) and has a TCP port and a UDP port.

1. TCP port 53 is used for zone transfers between DNS servers;
   
2. UDP port 53 is used for common DNS queries—resolving domain names to IP addresses.
   

Well-Known and Registered Ports
There are two ranges of ports used for TCP/IP networks:

1. well-known ports and
2. registered ports.

The well-known ports are the network services that have been assigned a specific port number (as defined by /etc/services). For example, SMTP is assigned port 25, and HTTP is assigned port 80. Servers listen on the network for requests at the well-known ports.

Registered ports are temporary ports, usually used by clients, and will vary each time a service is used. Registered ports are also called ephemeral ports, because they last for only a brief time. The port is then abandoned and can be used by other services.

The port number ranges are classified, according to Request for Comments (RFC) 1700.

• Well-known 1 to 1023
• Registered 1024 to 65535

Connections to ports number 1023 and below are assumed to run with root-level privileges. This means that untrusted services should never be configured with a port number below 1024.

To explain how well-known ports work with registered ports, let’s look at a typical Web site connection from a Web browser to a Web server. The client sends the HTTP request from a registered TCP port, such as port 1025. The request is routed across the network to the well-known TCP port 80 of a Web server. Once a session is established, the server continues to use port 80, and the client uses various registered ports, such as TCP port 1025 and 1026, to transfer the HTTP data.

Figure 2.5 is a packet capture that displays the establishment of a TCP session between a client and server, and the transmission of HTTP data between them.

• In frame 2 of the packet capture, the source address (24.130.10.35) is the client computer requesting the Web page.The destination address (192.0.34.65) is the Web server, which hosts the Internet Corporation of Assigned Names and Numbers (ICANN) Web site.
  
• In the Info field, the 1025 > 80 indicates that the source TCP port is 1025. The 80 indicates that the destination TCP port is 80.
• The first three frames display the TCP handshake, which establishes a TCP connection between the client and server.
  
• In the frames that follow, the client requests HTTP data from the server.The request determines the HTTP version that the client and server will use.
• The client then requests and downloads thecontents of the Web page.
  

Determining Ports to Block
When determining which ports to block on your server, you must first determine which services you require. In most cases, block all ports that are not exclusively required by these services. This is tricky, because you can easily block yourself from services you need, especially services that use ephemeral ports, as explained earlier.

If your server is an exclusive e-mail server running SMTP and IMAP, you can block all TCP ports except ports 25 and 143, respectively. If your server is an exclusive HTTP server, you can block all ports except TCP port 80. In both cases, you can block all UDP ports since SMTP and IMAP all use TCP services exclusively.

However, if you want to use your server as an HTTP client (i.e., for accessing operating system updates) or as an e-mail client to a remote mail server, you will restrict the system. Clients require registered UDP ports for DNS, as well as registered TCP ports for establishing connections with Web servers. If you open only the corresponding UDP ports 25, 80, and 143, DNS requests are blocked because DNS queries use UDP port 53, and DNS answers use a UDP registered port. Even if you open port 53, a different registered port may be assigned each time for the answer. Attempting to allow access to a randomly assigned registered port is almost impossible and a waste of time.

The same problem applies with TCP connections that require ephemeral ports. Therefore, you should either open all TCP/UDP registered ports (so you can use your server as a client), or block them (except for the services you require) and access resources, such as operating system updates, another way. Many administrators order the Red Hat Linux Update CDs, which are re-mastered every eight weeks, that contain all current updates. You can also simply download the updates from another computer.


Blocking Ports
To block TCP/UDP services in Linux, you must disable the service that uses the specific port. The following section discusses disabling ports using xinetd, and disabling ports assigned to stand-alone services.


Xinetd Services
Many services are disabled by their respective files in the /etc/xinetd.d directory by commenting out the service that uses the port. For example, to disable port 79 (used for finger services, which gives out user data that can be used by malicious hackers), you would comment out the service finger entry in /etc/xinetd.d/finger file.

Refer to Table 2.2 to view other ports you may wish to block. It lists common ports blocked by firewalls. However, these ports can also be blocked at the server itself. Follow these steps to disable port 79:

1. To disable port 79, you must edit the /etc/xinetd.d/finger file. Open the finger file and locate the service finger line.
2. Comment out the finger service line, and then write and quit the file.
3. Next, you must restart xinetd by entering:

   # /etc/rc.d/init.d/xinetd restart

4. if you have a finger program installed on your system, or access to a finger gateway, attempt a finger request to your system. You should fail. Note that you can use xinetd to disable many other ports.
   

Stand-Alone Services
To disable ports whose corresponding services are not included in the /etc/xinetd.d directory, you must kill the service’s process and make sure that service does not automatically restart upon reboot. These services are called standalone services.

For example, port 111 is assigned a stand-alone portmapper service not required for most e-mail servers. The portmapper service, which is technically part of the Sun Remote Procedure Call (RPC) service, runs on server machines and assigns port numbers to RPC packets, such as NIS and NFS packets. Because these RPC services are not used by most e-mail services, port 111 is not necessary. To disable port 111, you must disable the portmapper service as follows:

1. To disable the portmapper service, identify the process identifier (PID) for portmap by entering:

   # ps aux | grep portmap

2. The second column lists the PID number. The last column lists the process using that PID. To stop the portmapper service, identify the PID number and enter:

   # kill –9 [PID NUMBER]
   

3. To make sure the service does not restart during reboot, enter:

   # ntsysv  
   

4. Scroll down to the portmap service and uncheck the check box next to the service. Click OK. The portmap service will no longer restart at bootup.
   

NOTE Some ports, such as port 80, are not activated unless the service is installed. For example, if you have not installed Apache server, then port 80 is not used. There is no need to block the port because it is already disabled.

Hardening the System with Bastille
Bastille is an open source program that facilitates the hardening of a Linux system.
It performs many of the tasks discussed in this chapter, including downloading operating system updates and disabling services and ports that are not required for
the system’s job functions. The program also offers a wider range of additional services, from installing a firewall (ipchains) to implementing secure shell (SSH).

Bastille is powerful and can save administrators time from configuring each individual file and program throughout the operating system. Instead, the administrator answers a series of “Yes” and “No” questions through an interactive textbased interface.The program automatically implements the administrator’s preferences based on the answers to the questions.

Bastille is written specifically to Red Hat Linux and Mandrake Linux, but can be easily modified to run on most Unix flavors. The specific Red Hat/Mandrake content has been generalized, and now the hard-code filenames are represented as variables. These variables are set automatically at runtime.

Bastille Functions
The following list highlights the security features offered by Bastille to secure your system. You will choose which feature you want to implement on your system during the question-and-answer period.

For example, many servers do not need to provide firewall or Network Address Translation (NAT), so you may not need to configure ipchains. This list may vary as new versions of Bastille are released and the program becomes more powerful. More information about each of these features is explained in the program.

• Run the ipchains script You can configure your system as a packet filter.This allows your system to perform NAT, serve as a small firewall, and deny certain connection types to your server.
• Download and install RPM updates The most recent versions of the RPMs used on your system are downloaded and installed. These RPM downloads are obtained from the Red Hat Errata page.
• Apply restrictive permissions on administrator utilities Allows only the root to read and execute common Administrator utilities such as ifconfig, linuxconf, ping, traceroute, and runlevel). It disables the SUID root status for these programs, so nonroot users cannot use them.
• Create a second root account A second UID 0 (root) account allows administrators to track the original root account.This is helpful for tracking hackers because Bastille notifies the second account to original account logins. If you always use the second account, then you know when a security breach may have occurred.
• Disable r-protocols The r-protocols allow users to log on to remote systems using IP-based authentication. IP-based authentication permits only specific IP addresses to remotely log on to a system. Because this authentication is based on the IP address, a hacker who has discovered an authorized IP address can create spoofed packets that appear to be from the authorized system.
• Implement password aging Default Red Hat Linux systems allow passwords to expire after 99,999 days. Because this is too long in a secure environment, Bastille offers to change the password expiration time to 180 days.These configurations are written to the /etc/login.defs file.
  
• Password protect the LILO prompt Allows users with the correct password to add arguments to the LILO prompt. Otherwise, only the default value (usually linux) is allowed. Be careful to implement this change if you have a dual-boot system, because the name of the operating system, such as dos, is often typed at the LILO prompt to access other operating systems.
• Disable CTRL-ALT-DELETE rebooting This disallows rebooting the machine by this method.
• Password protect single-user mode If a user gains access to your physical system, he or she can enter single-user mode by typing init 1. Once in single-user mode, that user has root access, and no one else can access the machine. By placing a password on single-user mode, runlevel 1 is protected (the password is the root password).
• Optimize TCP Wrappers This choice modifies the inetd.conf (pre Red Hat Linux 7 versions only) and /etc/hosts.allow files so that inetd must contact TCP Wrappers whenever it gets a request, instead of automatically running the requested service. TCP Wrappers will determine if the requesting IP address is allowed to run the particular service. If the request is not allowed, the request is denied and the attempt is logged. Although IP-based authentication can be vulnerable, this optimization adds a layer of security to the process.
• Add Authorized Use banners These banners automatically appear whenever anyone logs on to the system. Authorized Use banners are helpful in prosecuting malicious hackers, and should be added to every system on your network that allows access to the network. An information bulletin from the U.S. Department of Energy’s Computer Incident Advisory Capability can be found here.

  The bulletin is titled “Creating Login Banners” and explains what is required within login banners for government computers. It also includes how to create banners and provides the text from the approved banner for Federal Government computer systems.

  Bastille uses a modified version of this login banner. If you choose to create a login banner, you can modify the banner text to suit your security needs in the etc/motd file.
• Disable the compiler Most hackers access systems through regular user accounts. Once they have access to the system, they compile malicious programs to attack the system and other systems. Disabling the compiler denies users from compiling programs, which reduces the security risk.

  This step is recommended for dedicated servers and firewalls, but may be too strict for workstations used by employees who require use of the compiler for their job tasks.

• Limit system resource usage If you limit system resource usage, you can reduce the chances of server failure from a DoS attack. If you choose to limit system resource usage in Bastille, the following changes will occur:
  
  1. Individual file size is limited to 40MB.
  2. Each individual user is limited to 150 processes.
  3. The allowable core files number is configured to zero. Core files are used for system troubleshooting. They are large and exploitable if a hacker gains control of them: they can grow and consume your file system.
  These limits are written to the /etc/security/limits.conf file.
• Restrict console access Anyone with access to the console has special rights, such as CD-ROM mounting. Bastille can specify which user accounts are allowed to log on via the console.
• Additional and remote logging Two additional logs can be added to /var/log/:
  
  1. /var/log/kernel (kernel messages)
  2. /var/log/syslog (error and warning severity messages)
     
  You can also log to a remote logging host if one exists.
  
• Process accounting setup Allows you to log the commands of all users. It also records when the commands were executed. This log file is helpful in retracing a hacker’s steps into your system, but the file can become large quickly. If the hacker has root access, the hacker can remove this accounting log.
• Disable unnecessary daemons As discussed earlier, only the required services should run on a system. All other services should be removed. Bastille allows you to disable daemons that are often unnecessary and pose potential security risks. If you performed a custom Red Hat installation with “everything,” you will be asked if you want to disable the services shown in Table 2.3.
• Download and install Secure Shell (SSH) A standard for securely logging on to remote systems. SSH encrypts usernames, passwords, and all information between hosts as they communicate across the network. Standard telnet connections send the information in clear text. Therefore, you should always use SSH to ensure secure remote connections.
• Deactivate and chroot named Similar to other services, named should be deactivated if the service is not required (e.g., if the server will not answer DNS queries). Bastille also offers to change the root directory of named to a child node on the directory tree, which is /home/dns. This new directory is considered a “chroot’ed prison” because the daemon is limited to only part of the file system and can only access the required files needed to function. These prisons are not entirely secure, but they do offer another layer of security to fend off a would-be hacker. This change is transparent, except that all configuration files and editing must occur in /home/dns. In addition, if you control named with ndc, you must enter:

  # ndc -c /home/dns/var/run/ndc

  
  

  NOTE The chroot() system call makes the current working directory act as if it were /. Consequently, a process that has used the chroot() system call cannot cd to higher-level directories. This prevents anyone exploiting the service from general access to the system.

• Harden Apache Web server httpd should be deactivated if the service is not required. If you decide to use Apache, you can perform the steps shown in the “Hardening the Apache Web Server” sidebar in Bastille to run the service.
• Disable printing Printing should only be enabled if your system needs to print. If printing is not required, Bastille removes SUID root on lpr, and disables lpr and lpd. As stated in the configuration script, if you disable SUID root on lpr and need to print, you must undo the setting by entering the following:
  
  • /bin/chmod 06555 /usr/bin/lpr /usr/bin/lprm
  • /sbin/chkconfig lpd on
• Disable FTP daemon user privileges By default (in the wu-ftpd configuration file), FTP clients cannot connect anonymously and upload files via FTP. Users with accounts on the system can still access the FTP server. This is dangerous if they access the server over a public network because the FTP passwords are sent as clear text, which can be captured by anyone with a packet sniffer. Anyone who has upload privileges can compromise the FTP daemon, because uploading files cause most attacks that allow root access.
• Disable anonymous download Allows anyone to download files from your FTP server without a unique username and password. Instead, it is recommended that you use an Apache Web-based file archive to allow the public to download files.

Hardening the Apache Web Server
Bastille has a reputation for being unable to secure the Apache Web server. If you implement the following steps for hardening Apache, be aware that security issues may still arise.

1. Run Apache as localhost only This action is especially helpful for Web designers and programmers because it allows them to work on their code and view their progress without opening the Web server to others network users. They access their local Web server by entering http://localhost.
2. Bind the Web server to a specific interface Allows you to bind the Web server’s IP address to an interface, such as an Ethernet network interface card (NIC). The option overrides the previous localhost-only action.
3. Disable symbolic links Symbolic links are “pointers” to other files in a file system. They are capable of allowing Web site visitors to access files outside of the Web server directories. If you disable symbolic links, you limit the files accessible to visitors on the Web server.
4. Deactivate server-side includes Server-side includes (SSIs) are interpreters or programs on a Web server that are activated by a client. SSIs can create HTML on the fly, which reduces bandwidth usage. SSIs are HTML directives to run programs on the server and add the programs’ output to the page being returned to the client. The problem is that crackers could cause the program to run in an insecure way, and in some cases could even cause other programs to run. Consequently, SSIs are considered insecure and have fallen out of favor. If you do not use SSIs on your Apache Web server, you should deactivate them.
5. Disable CGI scripts Common Gateway Interface (CGI) scripts allow a Web server to communicate with an application, such as a database, and then return that data to a client. CGI scripts should be limited to certain users, depending on the CGI scripts. For example, many scripts are used to process
   Web page forms, which are available to the public. Some scripts may be used to access private databases, which require limited access. If you do not use CGI scripts on your Apache Web server, you should deactivate them.
6. Disable indexes A world-readable file or directory allows web site visitors access to files or directories. An automatically generated index file will list the contents of these files and directories. Listing them is usually a bad idea unless you want the files to be listed for HTTP downloads (Web-based file archives) or similar uses.
   

d