Securing Linux Servers | Fedora 6 and Red Hat Enterprise Linux Bible

Opening up your Fedora or RHEL system as a server on a public network creates a whole new set of challenges when it comes to security. Instead of just turning away nearly all incoming requests, your computer will be expected to respond to requests for supported services (such as Web, FTP, or mail service) by supplying information or possibly running scripts that take in data.

Entire books have been filled with information on how to go about securing your servers. Many businesses that rely on Internet servers assign full-time administrators to watch over the security of their servers. So, think of this section as an overview of some of the kinds of attacks to look out for and some tools available to secure your Fedora or RHEL server.

Understanding Attack Techniques

Attacks on computing systems take on different forms, depending on the goal and resources of the attacker. Some attackers want to be disruptive, while others want to infiltrate your machines and utilize the resources for their own nefarious purposes. Still others are targeting your data for financial gain or blackmail. Here are three major categories of attacks:

Denial of service (DOS) - The easiest attacks to perpetrate are denial-of-service attacks. The primary purpose of these attacks is to disrupt the activities of a remote site by overloading it with irrelevant data. DOS attacks can be as simple as sending thousands of page requests per second at a Web site. These types of attacks are easy to perpetrate and easy to protect against. Once you have a handle on where the attack is coming from, a simple phone call to the perpetrator's ISP will get the problem solved .
Distributed denial of service (DDOS) - More advanced DOS attacks are called distributed denial-of-service attacks. DDOS attacks are much harder to perpetrate and nearly impossible to stop. In this form of attack, an attacker takes control of hundreds or even thousands of weakly secured Internet connected computers. The attacker then directs them in unison to send a stream of irrelevant data to a single Internet host. The result is that the power of one attacker is magnified thousands of times. Instead of an attack coming from one direction, as is the case in a normal DOS, it comes from thousands of directions at once. The best defense against a DDOS attack is to contact your ISP to see if it can filter traffic at its border routers.

Many people use the excuse , "I have nothing on my machine anyone would want" to avoid having to consider security. The problem with this argument is that attackers have a lot of reasons to use your machine. The attacker can turn your machine into an agent for later use in a DDOS attack. More than once, authorities have shown up at the door of a dumbfounded computer user asking questions about threats originating from their computer. By ignoring security, the owners have opened themselves up to a great deal of liability.
Intrusion attacks - To remotely use the resources of a target machine, attackers must first look for an opening to exploit. In the absence of inside information such as passwords or encryption keys, they must scan the target machine to see what services are offered . Perhaps one of the services is weakly secured and the attacker can use some known exploit to finagle his or her way in.

A tool called nmap is generally considered the best way to scan a host for services (note that nmap is a tool that can be used for good and bad). Once the attacker has a list of the available services running on his target, he needs to find a way to trick one of those services into letting him have privileged access to the system. Usually, this is done with a program called an exploit .

While DOS attacks are disruptive, intrusion type attacks are the most damaging . The reasons are varied, but the result is always the same. An uninvited guest is now taking up residence on your machine and is using it in a way you have no control over.

Protecting Against Denial-Of-Service Attacks

As explained earlier, a denial-of-service attack attempts to crash your computer or at least degrade its performance to an unusable level. There are a variety of denial-of-service exploits. Most try to overload some system resource, such as your available disk space or your Internet connection. Some common attacks and defenses are discussed in the following sections.

Mailbombing

Mailbombing is the practice of sending so much e-mail to a particular user or system that the computer's hard drive becomes full. There are several ways to protect yourself from mailbombing. You can use the Procmail e-mail-filtering tool or configure your sendmail daemon.

Cross-reference

See Chapter 19 for a more complete description of sendmail.

Blocking Mail with Procmail

The Procmail e-mail-filtering tool is installed by default with Fedora and RHEL and is tightly integrated with the sendmail e-mail daemon; thus, it can be used to selectively block or filter out specific types of e-mail. You can learn more about Procmail at the Procmail Web site: www.procmail.org .

To enable Procmail for your user account, create a .procmailrc file in your home directory. The file should be mode 0600 (readable by you but nobody else). Type the following, replacing evilmailer with the actual e-mail address that is mailbombing you:

 #  Delete mail from  evilmailer   :0 * ^From.*evilmailer /dev/null

The Procmail recipe looks for the From line at the start of each e-mail to see if it includes the string evilmailer . If it does, the message is sent to /dev/null (effectively throwing it away).

Blocking Mail with Sendmail

The Procmail e-mail tool works quite well when only one user is being mailbombed. If, however, the mailbombing affects many users, you should probably configure your sendmail daemon to block all e-mail from the mailbomber. Do this by adding the mailbomber's e-mail address or system name to the access file located in the /etc/mail directory.

Each line of the access file contains an e-mail address, hostname, domain, or IP address followed by a tab and then a keyword specifying what action to take when that entity sends you a message. Valid keywords are OK, RELAY, REJECT, DISCARD , and ERROR . Using the REJECT keyword will cause a sender's e-mail to be bounced back with an error message. The keyword DISCARD will cause the message to be silently dropped without sending an error back. You can even return a custom error message by using the ERROR keyword.

Thus, an example /etc/mail/access file may look similar to this:

 # Check the /usr/share/doc/sendmail/README.cf file for a description # of the format of this file. (search for access_db in that file) # The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc # package. # # by default we allow relaying from localhost... localhost.localdomain RELAY localhost RELAY 127.0.0.1 RELAY # # Senders we want to Block # evilmailer@yahoo.com REJECT stimpy.glaci.com REJECT cyberpromo.com DISCARD 199.170.176.99 ERROR:"550 Die Spammer Scum!" 199.170.177 ERROR:"550 Email Refused"

As with most Linux configuration files, lines that begin with a # pound sign are comments. Our list of blocked spammers is at the end of this example file. Note that the address to block can be a complete e-mail address, a full hostname, a domain only, an IP address, or a subnet.

To block a particular e-mail address or host from mailbombing you, log in to your system as root, edit the /etc/mail/access file, and add a line to DISCARD mail from the offending sender.

After saving the file and exiting the editor, you must convert the access file into a hash-indexed database called access.db. The database is updated automatically the next time sendmail starts. Or you can convert the database immediately, as follows :

 #  cd /etc/mail  #  make

Sendmail should now discard e-mail from the addresses you added.

Spam Relaying

Another way in which your e-mail services can be abused is by having your system used as a spam relay. Spam refers to the unsolicited junk e-mail that has become a common occurrence on the Internet. Spammers often deliver their annoying messages from a normal dial-up Internet account. They need some kind of high-capacity e-mail server to accept and buffer the payload of messages. They deliver the spam to the server all in one huge batch and then log off, letting the server do the work of delivering the messages to the many victims.

Naturally, no self-respecting Internet service provider (ISP) will cooperate with this action, so spammers resort to hijacking servers at another ISP to do the dirty work. Having your mailserver hijacked to act as a spam relay can have a devastating effect on your system and your reputation. Fortunately, open mail relaying is deactivated by default on Fedora and Red Hat Linux installations. Open mail relaying is one security issue that you will not have to worry about.

You can allow specific hosts or domains to relay mail through your system by adding those senders to your /etc/mail/access file with keyword RELAY . By default, relaying is allowed only from the local host. Refer to Chapter 19, as well as the sendmail documentation, for more information.

Tip

One package you might consider using to filter out spam on your mail server is spamassassin. Spamassassin examines the text of incoming mail messages and attempts to filter out messages that are determined to be spam. Spamassassin is described in Chapter 19.

Smurf Amplification Attack

Smurfing refers to a particular type of denial-of-service attack aimed at flooding your Internet connection. It can be a difficult attack to defend against because it is not easy to trace the attack to the attacker. Here is how smurfing works.

The attack makes use of the ICMP protocol, a service intended for checking the speed and availability of network connections. Using the ping command, you can send a network packet from your computer to another computer on the Internet. The remote computer will recognize the packet as an ICMP request and echo a reply packet to your computer. Your computer can then print a message revealing that the remote system is up and telling you how long it took to reply to the ping.

A smurfing attack uses a malformed ICMP request to bury your computer in network traffic. The attacker does this by bouncing a ping request off an unwitting third party in such a way that the reply is duplicated dozens or even hundreds of times. An organization with a fast Internet connection and a large number of computers is used as the relay. The destination address of the ping is set to an entire subnet instead of a single host. The return address is forged to be your machine's address instead of the actual sender. When the ICMP packet arrives at the unwitting relay's network, every host on that subnet replies to the ping! Furthermore, they reply to your computer instead of to the actual sender. If the relay's network has hundreds of computers, your Internet connection can be quickly flooded.

The best fix is to contact the organization being used as a relay and inform them of the abuse. Usually, they need only to reconfigure their Internet router to stop any future attacks. If the organization is uncooperative, you can minimize the effect of the attack by blocking the ICMP protocol on your router. This will at least keep the traffic off your internal network. If you can convince your ISP to block ICMP packets aimed at your network, it will help even more.

Protecting Against Distributed DOS Attacks

DDOS attacks are much harder to initiate and nearly impossible to stop. A DDOS attack begins with the penetration of hundreds or even thousands of weakly secured machines. These machines can then be directed to attack a single host based on the whims of the attacker.

With the advent of DSL and cable modem, millions of people are enjoying Internet access with virtually no speed restrictions. In their rush to get online, many of those people neglect to implement even the most basic security. Because the vast majority of these people run Microsoft operating systems, they tend to get hit with worms and viruses rather quickly. After the machine has been infiltrated, quite often the worm or virus installs a program on the victim's machine that instructs it to quietly call home and announce that it is now ready to do the master's bidding .

At the whim of the master, the infected machines can now be used to focus a concentrated stream of garbage data at a selected host. In concert with thousands of other infected machines, a scriptkiddie (someone, often a youngster, who doesn't have the knowledge to create worms or viruses, but has the inclination and small bit of skill needed to find and launch them) now has the power to take down nearly any site on the Internet.

Detecting a DDOS is similar to detecting a DOS attack. One or more of the following signs are likely to be present:

Sustained saturated data link
No reduction in link saturation during off-peak hours
Hundreds or even thousands of simultaneous network connections
Extremely slow system performance

To determine if your data link is saturated, the act of pinging an outside host can tell much of the story. Much higher than usual latency is a dead giveaway. Normal ping latency (that is, the time it takes for a ping response to come back from a remote host) looks like the following:

 #  ping www.example.com  PING www.example.com (192.0.34.166) from 10.0.0.11: 56(84) bytes of data 64 bytes from 192.0.34.166: icmp_seq=1 ttl=49 time=40.1 ms 64 bytes from 192.0.34.166: icmp_seq=2 ttl=49 time=42.5 ms 64 bytes from 192.0.34.166: icmp_seq=3 ttl=49 time=39.5 ms 64 bytes from 192.0.34.166: icmp_seq=4 ttl=49 time=38.4 ms 64 bytes from 192.0.34.166: icmp_seq=5 ttl=49 time=39.0 ms --- www.example.com ping statistics --- 5 packets transmitted, 5 received, 0% loss, time 4035ms rtt min/avg/max/mdev = 38.472/39.971/42.584/1.432 ms

In the preceding example, the average time for a ping packet to make the round trip was about 39 thousandths of a second.

A ping to a nearly saturated link will look like the following:

 # ping www.example.com PING www.example.com (192.0.34.166): from 10.0.0.11: 56(84)bytes of data 64 bytes from 192.0.34.166: icmp_seq=1 ttl=62 time=1252 ms 64 bytes from 192.0.34.166: icmp_seq=2 ttl=62 time=1218 ms 64 bytes from 192.0.34.166: icmp_seq=3 ttl=62 time=1290 ms 64 bytes from 192.0.34.166: icmp_seq=4 ttl=62 time=1288 ms 64 bytes from 192.0.34.166: icmp_seq=5 ttl=62 time=1241 ms --- www.example.com ping statistics --- 5 packets transmitted, 5 received, 0% loss, time 5032ms rtt min/avg/max/mdev = 1218.059/1258.384/1290.861/28.000 ms

In this example, a ping packet took, on average, 1.3 seconds to make the round trip. From the first example to the second example, latency increased by a factor of 31! A data link that goes from working normally to slowing down by a factor of 31 is a clear sign that link utilization should be investigated.

For a more accurate measure of data throughput, a tool such as ttcp can be used. To test your connection with ttcp you must have installed the ttcp RPM package on machines inside and outside of your network. (The ttcp package comes on the DVD included with this book.) If you are not sure whether the package is installed, simply type ttcp at a command prompt. You should see something like the following:

 #  ttcp  Usage: ttcp -t [-options] host [ < in ] ttcp -r [-options > out] Common options: -l ## length of bufs read from or written to network (default 8192) -u use UDP instead of TCP -p ## port number to send to or listen at (default 5001) -s -t: source a pattern to network -r: sink (discard) all data from network -A align the start of buffers to this modulus (default 16384) -O start buffers at this offset from the modulus (default 0) -v verbose: print more statistics -d set SO_DEBUG socket option -b ## set socket buffer size (if supported) -f X format for rate: k,K = kilo{bit,byte}; m,M = mega; g,G = giga Options specific to -t: -n ## number of source bufs written to network (default 2048) -D don't buffer TCP writes (sets TCP_NODELAY socket option) -w ## number of microseconds to wait between each write Options specific to -r: -B for -s, only output full blocks as specified by -l (for TAR) -T "touch": access each byte as it's read -I if Specify the network interface (e.g. eth0) to use

The first step is to start up a receiver process on the server machine:

 #  ttcp -rs  ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket

The –r flag denotes that the server machine will be the receiver. The –s flag, in conjunction with the –r flag, tells ttcp that you want to ignore any received data .

The next step is to have someone outside of your data link, with a network link close to the same speed as yours, set up a ttcp sending process:

 #  ttcp -ts server.example.com  ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> server.example.com ttcp-t: socket ttcp-t: connect

Let the process run for a few minutes and then press Ctrl+C on the transmitting side to stop the testing. The receiving side will then take a moment to calculate and present the results:

 #  ttcp -rs  ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket ttcp-r: accept from 64.223.17.21 ttcp-r: 2102496 bytes in 70.02 real seconds = 29.32 KB/sec +++ ttcp-r: 1226 I/O calls, msec/call = 58.49, calls/sec = 17.51 ttcp-r: 0.0user 0.0sys 1:10real 0% 0i+0d 0maxrss 0+2pf 0+0csw

In this example, the average bandwidth between the two hosts was 29.32 kilobytes per second. On a link suffering from a DDOS, this number would be a mere fraction of the actual bandwidth the data link is rated for.

If the data link is indeed saturated, the next step is to determine where the connections are coming from. A very effective way of doing this is with the netstat command, which is included as part of the base Fedora installation. Type the following to see connection information:

 #  netstat –tupn

Table 14-3 describes each of the netstat parameters used here.

Table 14-3: netstat Parameters
Open table as spreadsheet
*Parameter*	*Description*
*-t, --tcp*	Show TCP socket connections.
*-u, --udp*	Show UDP socket connections.
*-p, --program*	Show the PID and name of the program to which each socket belongs.
-n, --numeric	Show numerical address instead of trying to determine symbolic host, port, or user names .

The following is an example of what the output might look like:

  Active Internet connections (w/o servers)   Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name   tcp 0 0 65.213.7.96:22 13.29.132.19:12545 ESTABLISHED 32376/sshd   tcp 0 224 65.213.7.96:22 13.29.210.13:29250 ESTABLISHED 13858/sshd   tcp 0 0 65.213.7.96:6667 13.29.194.190:33452 ESTABLISHED 1870/ircd   tcp 0 0 65.213.7.96:6667 216.39.144.152:42709 ESTABLISHED 1870/ircd   tcp 0 0 65.213.7.96:42352 67.113.1.99:53 TIME_WAIT -   tcp 0 0 65.213.7.96:42354 83.152.6.9:113 TIME_WAIT -   tcp 0 0 65.213.7.96:42351 83.152.6.9:113 TIME_WAIT -   tcp 0 0 127.0.0.1:42355 127.0.0.1:783 TIME_WAIT -   tcp 0 0 127.0.0.1:783 127.0.0.1:42353 TIME_WAIT -  tcp 0 0 65.213.7.96:42348 19.15.11.1:25 TIME_WAIT -

The output is organized into columns defined as follows:

Proto - Protocol used by the socket.
Recv-Q - The number of bytes not yet copied by the user program attached to this socket.
Send-Q - The number of bytes not acknowledged by the host.
Local Address - Address and port number of the local end of the socket.
Foreign Address - Address and port number of the remote end of the socket.
State - Current state of the socket. Table 14-4 provides a list of socket states.
PID/Program name - Process ID and program name of the process that owns the socket.

Table 14-4: Socket States
Open table as spreadsheet
*State*	*Description*
*ESTABLISHED*	Socket has an established connection.
*SYN_SENT*	Socket actively trying to establish a connection.
*SYN_RECV*	Connection request received from the network.
*FIN_WAIT1*	Socket closed and shutting down.
*FIN_WAIT2*	Socket is waiting for remote end to shut down.
*TIME_WAIT*	Socket is waiting after closing to handle packets still in the network.
*CLOSED*	Socket is not being used.
*CLOSE_WAIT*	The remote end has shut down, waiting for the socket to close.
*LAST_ACK*	The remote end has shut down, and the socket is closed, waiting for acknowledgement .
*LISTEN*	Socket is waiting for an incoming connection.
*CLOSING*	Both sides of the connection are shut down, but not all of your data has been sent.
UNKNOWN	The state of the socket is unknown.

During a DOS attack, the foreign address is usually the same for each connection. In this case, it is a simple matter of typing the foreign IP address into the search form at www.arin.net/whois/ so you can alert your ISP.

During a DDOS attack, the foreign address will likely be different for each connection. In this case, it is impossible to track down all of the offenders because there will likely be thousands of them. The best way to defend yourself is to contact your ISP and see if it can filter the traffic at its border routers.

Protecting Against Intrusion Attacks

Crackers have a wide variety of tools and techniques to assist them in breaking into your computer. Intrusion attacks focus on exploiting weaknesses in your security, so the crackers can take more control of your system (and potentially do more damage) than they could from the outside.

Fortunately, there are many tools and techniques for combating intrusion attacks. This section discusses the most common break-in methods and the tools available to protect your system. Although the examples shown are specific to Fedora and other Red Hat Linux systems, the tools and techniques are generally applicable to any other Linux or UNIX-like operating system.

Cross-Reference

The tripwire package, which was recently dropped from the Fedora distribution, is a good tool for detecting whether intrusion attacks have taken place. The tripwire package, however, is still available from Fedora Extras. The description of tripwire is not in this edition. However, if you are interested in installing the package on your own, you can find the description of tripwire on the companion Web site of this book at www. wiley .com/go/fedora6bible .

Evaluating Access to Network Services

Fedora, Red Hat Linux, and its UNIX kin provide many network services, and with them many avenues for cracker attacks. You should know these services and how to limit access to them.

What do I mean by a network service? Basically, I am referring to any task that the computer performs that requires it to send and receive information over the network using some predefined set of rules. Routing e-mail is a network service. So is serving Web pages. Your Linux box has the potential to provide thousands of services. Many of them are listed in the /etc/services file. Look at a snippet of that file:

 # /etc/services: # service-name port/protocol [aliases ...] [# comment] chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp-data 20/tcp ftp-data 20/udp # 21 is registered to ftp, but also used by fsp ftp 21/tcp ftp 21/udp fsp fspd ssh 22/tcp # SSH Remote Login Protocol ssh 22/udp # SSH Remote Login Protocol telnet 23/tcp telnet 23/udp # 24 - private mail system smtp 25/tcp mail

After comment lines, you will notice three columns of information. The left column contains the name of each service. The middle column defines the port number and protocol type used for that service. The rightmost field contains an optional alias or list of aliases for the service.

As an example, examine the last entry in the file snippet. It describes the SMTP (Simple Mail Transfer Protocol) service, which is the service used for delivering e-mail over the Internet. The middle column contains the text 25/tcp, which tells us that the SMTP protocol uses port 25 and uses the Transmission Control Protocol (TCP) as its protocol type.

What exactly is a port number ? It is a unique number that has been set aside for a particular network service. It allows network connections to be properly routed to the software that handles that service. For example, when an e-mail message is delivered from some other computer to your Linux box, the remote system must first establish a network connection with your system. Your computer receives the connection request, examines it, sees it labeled for port 25, and thus knows that the connection should be handed to the program that handles e-mail (which happens to be sendmail).

Note

A program that runs quietly in the background handling service requests (such as sendmail) is called a daemon . Usually, daemons are started automatically when your system boots up, and they keep running until your system is shut down. Daemons may also be started on an as-needed basis by xinetd , a special daemon that listens on a large number of port numbers , and then launches the requested process.

I mentioned that SMTP uses the TCP protocol. Some services use UDP, the User Datagram Protocol. All you really need to know about TCP and UDP (for the purpose of this security discussion) is that they provide different ways of packaging the information sent over a network connection. A TCP connection provides error detection and retransmission of lost data. UDP doesn't check to ensure that the data arrived complete and intact; it is meant as a fast way to send non-critical information.

Disabling Network Services

Although there are hundreds of services (listed in /etc/services ) that potentially could be available and subject to attack on your Fedora or Red Hat Linux system, in reality only a few dozen services are installed and only a handful of those are on by default. Most network services are started by either the xinetd process or by a start-up script in the /etc/init.d directory.

xinetd is a daemon that listens on a great number of network port numbers. When a connection is made to a particular port number, xinetd automatically starts the appropriate program for that service and hands the connection to it. The xinetd daemon improves on its predecessor, inetd , by offering features that include more flexible access control, more logging settings, and denial-of-service prevention.

The configuration file /etc/xinetd.conf is used to provide default settings for the xinetd server. The directory /etc/xinetd.d contains files telling xinetd what ports to listen on and what programs to start. Each file contains configuration information for a single service, and the file is usually named after the service it configures. For example, to enable the rsync service, edit the rsync file in the /etc/xinetd.d directory and look for a section similar to the following:

 service rsync { disable = yes socket_type = stream wait = no user = root server = /usr/bin/rsync server_args = --daemon log_on_failure += USERID }

Note that the first line of this example identifies the service as rsync . This exactly matches the service name listed in the /etc/services file, causing the service to listen on port 873 for TCP and UDP protocols. You can see that the service is off by default ( disable = yes ). To enable the rsync services, change the line to read like this:

 disable = no

Tip

The rsync service is a nice one to turn on if your machine is an FTP server. It allows people to use an rsync client (which includes a checksum-search algorithm) to download files from your server. With that feature, users can restart a disrupted download without having to start from the beginning.

Because most services are disabled by default, your computer is only as insecure as you make it. You can double-check that insecure services, such as rlogin and rsh (which are included in the rsh-server package), are also disabled by making sure that disabled = yes is set in the /etc/xinetd.d/rlogin and rsh files.

Tip

You can make the remote login service active but disable the use of the /etc/host.equiv and .rhosts files, requiring rlogin to always prompt for a password. Rather than disabling the service, locate the server line in the rsh file ( server = /usr/sbin/in.rshd ) and add a space followed by -L at the end. Of course, that doesn't change the fact that your password and data will still be sent unencrypted over the network.

You now need to send a signal to the xinetd process to tell it to reload its configuration file. The quickest way to do that is to reload the xinetd service. As the root user, type the following from a shell:

 #  service xinetd reload  Reloading configuration: [ OK ]

That's it - you have enabled the rsync service. Provided that you have properly configured your mail server (see Chapter 19), clients should now be able to download files from your computer via the rsync protocol.

Securing Servers with SELinux

Red Hat, Inc. did a clever thing when it took its first swipe at implementing SELinux in Red Hat systems. Instead of creating only policies to control every aspect of your Linux system, it created a " targeted " policy type that focused on securing those services that are most vulnerable to attacks. Red Hat then set about securing those services in such a way that, if they were compromised, a cracker couldn't compromise the rest of the system as well.

After you have opened a port in your firewall so others can request a service, and then started that service to handle requests, SELinux can be used to set up walls around that service. As a result, its daemon process, configuration files, and data can't access resources they are not specifically allowed to access. The rest of your computer, then, is safer.

As Red Hat continues to work out the kinks in SELinux, there has been a tendency for users to experience SELinux failures and just disable SELinux. If you have tried SELinux in the past and turned it off when you had a problem, consider that SELinux has improved quite a bit in Fedora 6 and it might be time for you to try it again.

If you do encounter a failure related to SELinux, try to find out if SELinux should have caused the failure. In other words, maybe you were doing something that was unsafe and SELinux was right to fail. However, if the failure you encounter turns out to be a bug with SELinux, file a bug report and help make the service better.

If you are enabling FTP, Web (HTTPD), DNS, NFS, NIS, or Samba services on your Fedora or RHEL system, you should consider leaving SELinux enabled and working with the settings from the Security Level Configuration window to configure those services. See Chapter 10 for a more in-depth description of SELinux in Fedora and RHEL, as well for a description of how to use the Security Level Configuration window to configure SELinux. For information on SELinux that is specific to Apache Web servers, refer to this Web site: http://fedora.redhat.com/docs/selinux-apache-fc3 . An FAQ on SELinux for Fedora is available here: http://fedora.redhat.com/docs/selinux-faq-fc3 .

Protecting Web Servers with Certificates and Encryption

Previous sections told you how to lock the doors to your Fedora or RHEL system to deny access to crackers. The best dead bolt lock, however, is useless if you are mugged in your own driveway and have your keys stolen. Likewise, the best computer security can be for naught if you are sending passwords and other critical data unprotected across the Internet.

A savvy cracker can use a tool called a protocol analyzer or a network sniffer to peek at the data flowing across a network and pick out passwords, credit card data, and other juicy bits of information. The cracker does this by breaking into a poorly protected system on the same network and running software, or by gaining physical access to the same network and plugging in his or her own equipment.

You can combat this sort of theft by using encryption. The two main types of encryption in use today are symmetric cryptography and public-key cryptography.

Symmetric Cryptography

Symmetric cryptography , also called private-key cryptography, uses a single key to both encrypt and decrypt a message. This method is generally inappropriate for securing data that will be used by a third party, because of the complexity of secure key exchange. Symmetric cryptography is generally useful for encrypting data for one's own purposes.

A classic use of symmetric cryptography is for a personal password vault. Anyone who has been using the Internet for any amount of time has accumulated a quantity of user names and passwords for accessing various sites and resources. A personal password vault lets you store this access information in an encrypted form. The end result is that you have to remember only one password to unlock all of your access information.

Until recently, the United States government was standardized on a symmetric encryption algorithm called DES (Data Encryption Standard) to secure important information. Because there is no direct way to crack DES-encrypted data, to decrypt DES encrypted data without a password you would have to use an unimaginable amount of computing power to try to guess the password. This is also known as the brute force method of decryption.

As personal computing power has increased nearly exponentially, the DES algorithm has had to be retired . In its place, after a very long and interesting search, the U.S. government has accepted the Rijndael algorithm as what it calls the AES (Advanced Encryption Standard). Although the AES algorithm is also subject to brute force attacks, it requires significantly more computing power to crack than the DES algorithm does.

For more information on AES, including a command line implementation of the algorithm, you can visit http://aescrypt. sourceforge .net/ .

Public-Key Cryptography

Public-key cryptography does not suffer from key distribution problems, and that is why it is the preferred encryption method for secure Internet communication. This method uses two keys, one to encrypt the message and another to decrypt the message. The key used to encrypt the message is called the public key because it is made available for all to see. The key used to decrypt the message is the private key and is kept hidden. The entire process works like this:

Imagine that you want to send me a secure message using public-key encryption. Here is what we need:

I must have a public and private key pair. Depending on the circumstances, I may generate the keys myself (using special software) or obtain the keys from a key authority.
You want to send me a message, so you first look up my public key (or more accurately, the software you are using looks it up).
You encrypt the message with the public key. At this point, the message can only be decrypted with the private key (the public key cannot be used to decrypt the message).
I receive the message and use my private key to decrypt it.

Secure Sockets Layer

A classic implementation of public-key cryptography is with secure sockets layer (SSL) communication. This is the technology that enables you to securely submit your credit card information to an online merchant. The elements of an SSL-encrypted session are as follows:

SSL-enabled Web browser (Firefox, Mozilla, Internet Explorer, Opera, Konquerer,and so on)
SSL-enabled Web server (Apache)
SSL certificate

To initiate an SSL session, a Web browser first makes contact with a Web server on port 443, also known as the HTTPS port (Hypertext Transport Protocol Secure). After a socket connection has been established between the two machines, the following occurs:

The server sends its SSL certificate to the browser.
The browser verifies the identity of the server through the SSL certificate.
The browser generates a symmetric encryption key.
The browser uses the SSL certificate to encrypt the symmetric encryption key.
The browser sends the encrypted key to the server.
The server decrypts the symmetric key with its private key counterpart of the public SSL certificate.
The browser and server can now encrypt and decrypt traffic based on a common knowledge of the symmetric key.

Secure data interchange can now occur.

Creating SSL Certificates

In order to create your own SSL certificate for secure HTTP data interchange, you must first have an SSL-capable Web server. The Apache Web server (httpd package), which comes with Fedora and RHEL, is SSL-capable. Here are some of the files you will need to create your own SSL certificates for the Apache Web server:

/etc/httpd/conf/httpd.conf - Web server configuration file
/etc/pki/tls/certs/Makefile - Certificate building script
/etc/httpd/conf.d/ssl.conf - Primary Web server SSL configuration file

Now that you're familiar with the basic components , take a look at the tools used to create SSL certificates:

 #  cd /etc/pki/tls/certs  #  make  This makefile allows you to create: o public/private key pairs o SSL certificate signing requests (CSRs) o self-signed SSL test certificates To create a key pair, run "make SOMETHING.key". To create a CSR, run "make SOMETHING.csr". To create a test certificate, run "make SOMETHING.crt". To create a key and a test certificate in one file, run "make SOMETHING.pem". To create a key for use with Apache, run "make genkey". To create a CSR for use with Apache, run "make certreq". To create a test certificate for use with Apache, run "make testcert". To create a test certificate with serial number other than zero, add SERIAL=num Examples: make server.key make server.csr make server.crt make stunnel.pem make genkey make certreq make testcert make server.crt SERIAL=1 make stunnel .pem SERIAL=2 make testcert SERIAL=3

The make command utilizes the Makefile to create SSL certificates. (The make command is used for a variety of software tasks with C and C++ programming.) Without any arguments the make command simply prints the information listed above. The following defines each argument you can give to make :

make server.key - Creates generic public/private key pairs.
make server.csr - Generates a generic SSL certificate service request.
make server.crt - Generates a generic SSL test certificate.
make stunnel.pem - Generates a generic SSL test certificate, but puts the private key in the same file as the SSL test certificate.
make genkey - Same as make server.key except it places the key in the ssl.key directory.
make certreq - Same as make server.csr except it places the certificate service request in the ssl.csr directory.
make testcert - Same as make server.crt except it places the test certificate in the ssl.crt directory.
make server.crt SERIAL=1 - Generate the keys mentioned above using keys serial numbers other than zero.

Using Third-Party Certificate Signers

In the real world, I know who you are because I recognize your face, your voice, and your mannerisms. On the Internet, I cannot see these things and must rely on a trusted third party to vouch for your identity. To ensure that a certificate is immutable, it has to be signed by a trusted third party when the certificate is issued and validated every time an end user taking advantage of your secure site loads it. The following is a list of the trusted third-party certificate signers:

GlobalSign - www.globalsign.net/
GeoTrust - www.geotrust.com/
VeriSign - www.verisign.com/
RapidSSL.com - www.rapidssl.com/
Thawte - www.thawte.com/
Entrust - www.entrust.com/
ipsCA - www.ipsca.com/
COMODO Group - www.comodogroup.com/

Note

Because of the fluid nature of the certificate business, some of these companies may not be in business when you read this, while others may have come into existence. To get a more current list of certificate authorities, from your Mozilla Firefox browser select Edit Preferences. From the Preferences window that appears, select Advanced Security View Certificates. From the Certificate Manager window that appears, refer to the Authorities tab to see Certificate Authorities from which you have received certificates.

Each of these certificate authorities has gotten a chunk of cryptographic code embedded into nearly every Web browser in the world. This chunk of cryptographic code allows a Web browser to determine whether or not an SSL certificate is authentic . Without this validation, it would be trivial for crackers to generate their own certificates and dupe people into thinking they are giving sensitive information to a reputable source.

Certificates that are not validated are called self-signed certificates . If you come across a site that has not had its identity authenticated by a trusted third party, your Web browser will display a message similar to the one shown in Figure 14-4.

Figure 14-4: A pop-up window alerts you when a site is not authenticated.

This does not necessarily mean that you are encountering anything illegal, immoral, or fattening. Many sites opt to go with self-signed certificates, not because they are trying to pull a fast one on you, but because there may not be any reason to validate the true owner of the certificate and they do not want to pay the cost of getting a certificate validated. Some reasons for using a self-signed certificate include:

The Web site accepts no input - In this case, you as the end user, have nothing to worry about. There is no one trying to steal your information because you aren't giving out any information. Most of the time this is done simply to secure the Web transmission from the server to you. The data in and of itself may not be sensitive, but, being a good netizen, the site has enabled you to secure the transmission to keep third parties from sniffing the traffic.
The Web site caters to a small clientele - If you run a Web site that has a very limited set of customers, such as an Application Service Provider, you can simply inform your users that you have no certificate signer and that they can browse the certificate information and validate it with you over the phone or in person.
Testing - It makes no sense to pay for an SSL certificate if you are only testing a new Web site or Web-based application. Use a self-signed certificate until you are ready to go live.

Creating a Certificate Service Request

To create a third-party validated SSL certificate, you must first start with a Certificate Service Request (CSR). To create a CSR, do the following on your Web server:

 #  cd /etc/pki/tls/certs  #  make certreq  /usr/bin/openssl You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]:  US  State or Province Name (full name) [Berkshire]:  Connecticut  Locality Name (eg, city) [Newbury]:  Mystic  Organization Name (eg, company) [My Company Ltd]:  Acme Marina, Inc.  Organizational Unit Name (eg, section) []:  InfoTech  Common Name (eg, your name or your server's hostname) []  :   www.acmemarina.com  Email Address []:  webmaster@acmemarina.com

To complete the process, you will be asked if you want to add any extra attributes to your certificate. Unless you have a reason to provide more information, you should simply press Enter at each of the following prompts to leave them blank.

 Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

Getting the CSR Signed

Once your CSR has been created, you need to send it to a signing authority for validation. The first step in this process is to select a signing authority. Each signing authority has different deals, prices, and products. Check out each of the signing authorities listed in the "Using third-party certificate signers" section earlier in this chapter to determine which works best for you. The following are areas where signing authorities differ :

Credibility and stability
Pricing
Browser recognition
Warranties
Support
Certificate strength

After you have selected your certificate signer, you have to go through some validation steps. Each signer has a different method of validating identity and certificate information. Some require that you fax articles of incorporation, while others require a company officer be made available to talk to a validation operator. At some point in the process you will be asked to copy and paste the contents of the CSR you created into the signer's Web form.

 #  cd /etc/pki/tls/certs  #  cat localhost.csr  -----BEGIN CERTIFICATE REQUEST----- MIIB6jCCAVMCAQAwgakxCzAJBgNVBAYTAlVTMRQwEgYDVQQIEwtDb25uZWN0aWN1 dDEPMA0GA1UEBxMGTXlzdGljMRowGAYDVQQKExFBY21lIE1hcmluYSwgSW5jLjER MA8GA1UECxMISW5mb1RlY2gxGzAZBgNVBAMTEnd3dy5hY21lbWFyaW5hLmNvbTEn MCUGCSqGSIb3DQEJARYYd2VibWFzdGVyQGFjbWVtYXJpbmEuY29tMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDcYH4pjMxKMldyXRmcoz8uBVOvwlNZHyRWw8ZG u2eCbvgi6w4wXuHwaDuxbuDBmw//Y9DMI2MXg4wDq4xmPi35EsO1Ofw4ytZJn1yW aU6cJVQro46OnXyaqXZOPiRCxUSnGRU+0nsqKGjf7LPpXv29S3QvMIBTYWzCkNnc gWBwwwIDAQABoAAwDQYJKoZIhvcNAQEEBQADgYEANv6eJOaJZGzopNR5h2YkR9Wg l8oBl3mgoPH60Sccw3pWsoW4qbOWq7on8dS/++QOCZWZI1gefgaSQMInKZ1II7Fs YIwYBgpoPTMC4bp0ZZtURCyQWrKIDXQBXw7BlU/3A25nvkRY7vgNL9Nq+7681EJ8 W9AJ3PX4vb2+ynttcBI= -----END CERTIFICATE REQUEST-----

You can use your mouse to copy and paste the CSR into the signer's Web form.

After you have completed the information validation, paid for the signing, and answered all of the questions, you have completed most of the process. In 48 to 72 hours you should receive an e-mail with your shiny new SSL certificate in it. The certificate will look similar to the following:

Copy and paste this certificate into an empty file called server.crt , which must reside in the /etc/pki/tls/certs directory, and restart your Web server:

 #  service httpd restart

Assuming your Web site was previously working fine, you can now view it in a secure fashion by placing an "s" after the http in the Web address. So if you previously viewed your Web site at http://www.acmemarina.com , you can now view it in a secure fashion by going to https://www.acmemarina.com .

Creating Self-Signed Certificates

Generating and running a self-signed SSL certificate is much easier than having a signed certificate. To generate a self-signed SSL certificate, do the following:

Remove the key and certificate that currently exist:

 #  rm /etc/pki/tls/certs/localhost.crt  #  rm /etc/pki/tls/private/localhost.key

Create your own server key:
```
 #  make genkey  
```

Create the self-signed certificate by typing the following:

 #  make testcert  umask 77 ; \ /usr/bin/openssl req -new -key /etc/httpd/conf/ssl.key/server.key -x509 -days 365 -out /etc/httpd/conf/ssl.key/server.crt . . .

At this point, it is time to start adding some identifying information to the certificate. Before you can do this, you must unlock the private key you just created. Do so by typing the password you typed earlier. Then follow this sample procedure:

 You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]:  US  State or Province Name (full name) [Berkshire]:  Ohio  Locality Name (eg, city) [Newbury]:  Cincinnati  Organization Name (eg, company) [My Company Ltd]:  Industrial Press, Inc.  Organizational Unit Name (eg, section) []:  IT  Common Name (eg, your name or your server's hostname) []:  www.industrialpressinc.com  Email Address []:  webmaster@industrialpressinc.com

The preceding generation process places all files in the proper place. All you need to do is restart your Web server and add https instead of http in front of your URL. Don't forget: you'll get a certificate validation message from your Web browser, which you can safely ignore.

Restarting Your Web Server

By now you've probably noticed that your Web server requires you to enter your certificate password every time it is started. This is to prevent someone from breaking into your server and stealing your private key. Should this happen, you are safe in the knowledge that the private key is a jumbled mess. The cracker will not be able to make use of it. Without such protection, a cracker could get your private key and easily masquerade as you, appearing to be legitimate in all cases.

If you just cannot stand having to enter a password every time your Web server starts, and are willing to accept the increased risk, you can remove the password encryption on your private key. Simply do the following:

 #  cd /etc/pki/tls/private  #  /usr/bin/openssl rsa -in localhost.key -out localhost.key

Troubleshooting Your Certificates

The following tips should help if you are having problems with your SSL certificate:

Only one SSL certificate per IP address is allowed. If you want to add more than one SSL-enabled Web site to your server, you must bind another IP address to the network interface.
Make sure you aren't blocking port 443 on your Web server. All https requests come in on port 443. If you are blocking it, you will not be able to get secure pages.
The certificate lasts for only one year. When that year is up, you have to renew your certificate with your certificate authority. Each certificate authority has a different procedure for doing this; check the authority's Web site for more details.
Make sure you have the mod_ssl package installed. If it is not installed, you will not be able to serve any SSL-enabled traffic.

For many years , the United States government treated encryption technology like munitions. As a result, anyone wanting to export encryption technology had to get an export license from the Commerce Department. This applied not only to encryption software developed within the United States, but also to software obtained from other countries and then re-exported to another country (or even to the same country you got it from). Thus, if you installed encryption technology on your Linux system and then transported it out of the country, you were violating federal law! Furthermore, if you e-mailed encryption software to a friend in another country or let him or her download it from your server, you violated the law.

In January 2000, the U.S. export laws relating to encryption software were relaxed considerably. However, often the U.S. Commerce Department's Bureau of Export Administration requires a review of encryption products before they can be exported. U.S. companies are also still not allowed to export encryption technology to countries classified as supporting terrorism.