-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 then takes 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. 231 Securing Linux 6 30190c06.qxd:Layout 1 12/18/07 12:15 AM Page 231 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 6-3 describes each of the netstat parameters used here. TABLE 6-3 netstat Parameters 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 the numerical address instead of trying to determine the symbolic host, port, or usernames. 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 6-4 provides a list of socket states.  PID/Program name — Process ID and program name of the process that owns the socket. 232 Running the Show Part II 30190c06.qxd:Layout 1 12/18/07 12:15 AM Page 232 TABLE 6-4 Socket States 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 com- puter. 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 dis- cusses 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 Linux or UNIX-like operating system. Evaluating Access to Network Services Linux systems and their 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. 233 Securing Linux 6 30190c06.qxd:Layout 1 12/18/07 12:15 AM Page 233 What do I mean by a network service? Basically, I am referring to any task that the computer per- forms 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 the 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 col- umn contains the text 25/tcp, which tells you 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 net- work 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). I mentioned that SMTP uses TCP. Some services use UDP, the User Datagram Protocol. All you really need to know about TCP and UDP (for the purposes of this security discussion) is that they pro- vide different ways of packaging the information sent over a network connection. A TCP connec- tion 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 noncritical information. 234 Running the Show Part II 30190c06.qxd:Layout 1 12/18/07 12:15 AM Page 234 Disabling Network Services Although there are hundreds of services (with official port numbers listed in /etc/services) that potentially could be available and subject to attack on your Linux system, in reality only a few dozen services are installed and only a handful of those are on by default. In Fedora and RHEL systems, most network services are started by either the xinetd process or by a start-up script in the /etc/init.d directory. Other Linux systems use the inetd process instead of xinetd. xinetd and inetd are daemons that listen on a great number of network port numbers. When a connection is made to a particular port number, xinetd or inetd automatically starts the appropri- ate program for that service and hands the connection to it. For xinetd, the configuration file /etc/xinetd.conf is used to provide default settings for the xinetd server. The directory /etc/xinetd.d contains files that tell xinetd what ports to listen on and what programs to start (the inetd daemon, alternatively, uses only the /etc/inetd.conf file). Each file in /etc/xinetd.d 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. You can see that the service is off by default ( disable = yes). To enable the rsync services, change the line to read disable = no instead. Thus, the disable line from the preced- ing example would look like this: disable = no 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 down- load 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 in Fedora and RHEL systems), are also disabled by making sure that disabled = yes is set in the /etc/xinetd.d/rlogin and rsh files. TIP TIP 235 Securing Linux 6 30190c06.qxd:Layout 1 12/18/07 12:15 AM Page 235 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. 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 in Fedora and RHEL systems is to reload the xinetd service. As the root user, type the following from a shell: # service xinetd reload Reloading configuration: [ OK ] You can also tell the xinetd process directly to reread the configuration file by sending it a SIGHUP signal. That works if you are using the inetd daemon instead (on systems such as Debian or Slackware) to reread the /etc/inetd.conf file. For example, type this (as root user) to have the inetd daemon reread the configuration file: # killall -s SIGHUP inetd That’s it — you have enabled the rsync service. Provided that you have properly configured your FTP server, 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 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. The company 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. Once you have opened a port in your firewall so others can request a service, 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 see SELinux failures and just disable the entire SELinux service. However, a better course is to find out if SELinux is really stopping you from doing something that is unsafe. If it 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. For information on SELinux that is specific to Fedora, refer to this site: http://fedoraproject.org/wiki/SELinux TIP TIP 236 Running the Show Part II 30190c06.qxd:Layout 1 12/18/07 12:15 AM Page 236 Protecting Web Servers with Certificates and Encryption Previous sections told you how to lock the doors to your Linux 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 pass- words 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 soft- ware, 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 usernames and passwords for accessing various sites and resources. A personal password vault lets you store this access infor- mation in an encrypted form. The end result is that you have to remember only one password to unlock all of your access information. Exporting Encryption Technology Before describing how to use the various encryption tools, I need to warn you about an unusual pol- icy of the United States government. For many years, the United States government treated encryp- tion 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, 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. 237 Securing Linux 6 30190c06.qxd:Layout 1 12/18/07 12:15 AM Page 237 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 United States 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/. Asymmetric 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. Imagine that you want to send me a secure message using public-key encryption. Here is what we need: 1. I must have a public and private key pair. Depending on the circumstances, I may gener- ate the keys myself (using special software) or obtain the keys from a key authority. 2. 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). 3. You encrypt the message with the public key. At this point, the message can be decrypted only with the private key (the public key cannot be used to decrypt the message). 4. 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) communi- cation. 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 (Mozilla, Internet Explorer, Opera, Konquerer, and so on)  SSL-enabled Web server (Apache)  SSL certificate 238 Running the Show Part II 30190c06.qxd:Layout 1 12/18/07 12:15 AM Page 238 To initiate an SSL session, a Web browser first makes contact with a Web server on port 443, also known as the HTTPS (Hypertext Transport Protocol Secure) port. After a socket connection has been established between the two machines, the following occurs: 1. The server sends its SSL certificate to the browser. 2. The browser verifies the identity of the server through the SSL certificate. 3. The browser generates a symmetric encryption key. 4. The browser uses the SSL certificate to encrypt the symmetric encryption key. 5. The browser sends the encrypted key to the server. 6. 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 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 other Linux systems, is SSL-capable. The following procedure for creating SSL certificates is done on a Fedora system that includes Apache from the httpd-2.2.3-5 package. This procedure may be differ- ent for Apache on other Linux systems. Once you have a server ready to go, you should familiarize yourself with the important server-side components of an SSL certificate: # ls -l /etc/httpd/conf -rw-r r 1 root root 36010 Jul 14 15:45 httpd.conf lrwxrwxrwx 1 root root 37 Aug 12 23:45 Makefile -> / / /usr/share/ssl/certs/Makefile drwx 2 root root 4096 Aug 12 23:45 ssl.crl drwx 2 root root 4096 Aug 12 23:45 ssl.crt drwx 2 root root 4096 Jul 14 15:45 ssl.csr drwx 2 root root 4096 Aug 12 23:45 ssl.key drwx 2 root root 4096 Jul 14 15:45 ssl.prm # ls -l /etc/httpd/conf.d/ssl.conf -rw-r r 1 root root 11140 Jul 14 15:45 ssl.conf The /etc/httpd/conf and /etc/httpd/conf.d directories contain all of the components necessary to create your SSL certificate. Each component is defined as follows:  httpd.conf — Web server configuration file  Makefile — Certificate building script  ssl.crl — Certificate revocation list directory  ssl.crt — SSL certificate directory 239 Securing Linux 6 30190c06.qxd:Layout 1 12/18/07 12:15 AM Page 239  ssl.csr — Certificate service request directory  ssl.key — SSL certificate private key directory  ssl.prm — SSL certificate parameters  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/httpd/conf # 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”. Examples: make server.key make server.csr make server.crt make stunnel.pem make genkey make certreq make testcert The make command utilizes the makefile to create SSL certificates. Without any arguments, the make command simply prints the information listed in the preceding example. 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. 240 Running the Show Part II 30190c06.qxd:Layout 1 12/18/07 12:15 AM Page 240 [...]... pstree), login-related commands (login, rlogin, and slogin), and many other tools Here’s how to run chkrootkit from INSERT: 1 Insert the CD that comes with this book into the CD drive and reboot 2 From the boot prompt, type insert and press Enter INSERT should boot to a desktop 247 6 30190c06.qxd:Layout 1 Part II 12/18/07 12:15 AM Page 248 Running the Show 3 To be able to check the Linux system installed... Choosing and Installing a Linux Distribution are included on this book’s DVD and CD and how to run them live or use them to install Linux permanently Each of the other chapters in this part of the book is dedicated to understanding and installing a particular Linux distribution After you’ve installed Linux, you’ll want to understand how to get and manage software for your Linux system These are important topics... ready to install Linux on your hard disk, I recommend you try Fedora Using the CD that comes with this book, you can boot directly to Damn Small Linux (or several other smaller bootable Linux distros), Debian, or Gentoo (to do a network install of those distributions to your hard disk) Debian and Damn Small Linux are two distributions that can be set up to work well on computers that are older and less... software distribution and help when you need it (from such things as forums and online chats) Other Distributions There seems to be a new Linux distribution every five minutes, and I really have to stop writing this book at some point To keep the descriptions of Linux distributions to a reasonable size (and actually have the space to describe how to use Linux) , several interesting Linux distributions aren’t... http://slackware.com/getslack) to get Linux software Those sites often let you download a complete copy of their distributions and give you the opportunity to purchase a boxed set However, one way to get a more complete view of available Linux distributions is to go to a Web site dedicated to spreading information about Linux distributions Use these sites to connect to forums and download documentation about many Linux distributions. .. improvements to Linux live CDs and installers, getting your hands on a working Linux system is quicker and more solid than ever before Choosing a Linux distribution If you are a first-time Linux user, I recommend that you: Understanding installation issues Try a bootable Linux — This book’s CD and DVD include several bootable Linux systems The advantage of a bootable Linux is that you can try out Linux without... book Notable Linux distributions not included in this book are TurboLinux, Xandros, and CentOS TurboLinux (www.turbolinux.com) is a popular distribution in Asia-Pacific countries Xandros (www.xandros.com), designed to operate well in Microsoft Windows environments, is a wellregarded desktop Linux system CentOS has become very popular among consultants who used to use Red Hat Linux CentOS is a rebuild... you reboot, they are good tools for starting out with Linux Install a desktop Linux system — Choose one of the Linux distributions and install it on your computer’s hard disk Permanently installing Linux to your hard disk gives you more flexibility for adding and removing software, accessing and saving data to hard disk, and more permanently customizing your system Installing Linux as a desktop system... I go to find Linux distributions is DistroWatch.com Go to the Major Distributions link to read about the top Linux distributions (most of which are included with this book) Links will take you to download sites, forums, home pages, and other sites related to each distribution Linux Help (www.linuxhelp.net) — Select the ISO images link from this site’s home page, and you can find download links to ISO... and Installing a Linux Distribution IN THIS PART Chapter 7 Installing Linux Chapter 8 Running Fedora and Red Hat Enterprise Linux Chapter 9 Running Debian GNU /Linux Chapter 10 Running SUSE and openSUSE Linux Chapter 11 Running KNOPPIX Chapter 12 Running Yellow Dog Linux Chapter 13 Running Gentoo Linux Chapter 14 Running Slackware Linux Chapter 15 Running Linspire and Freespire Chapter 16 Running Mandriva . root 40 96 Jul 14 15 :45 ssl.csr drwx 2 root root 40 96 Aug 12 23 :45 ssl.key drwx 2 root root 40 96 Jul 14 15 :45 ssl.prm # ls -l /etc/httpd/conf.d/ssl.conf -rw-r r 1 root root 111 40 Jul 14 15 :45 ssl.conf The. 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 Linux. in disk-checking tools (such as du, find, and ls), process table tools (ps and pstree), login-related commands ( login, rlogin, and slogin), and many other tools. Here’s how to run chkrootkit from