Red Hat Linux Fedora For Dummies [Electronic resources] نسخه متنی

An Ounce of Protection: Preventing Intruders

We start by describing how to minimize your chances of being hacked. The following sections describe systems that increase your security:

Updating software: The Red Hat up2date utility helps keep your computer’s software up to date, which eliminates vulnerabilities as they are discovered.

Removing services: Hackers can’t take advantage of vulnerable software if you don’t use it. Turning off unnecessary services reduces your exposure.

OpenSSH and SSL: Except when viewing garden-variety, nonsecure Web pages, you should never communicate over the Internet (or wireless LANs) without using encryption. The open source SecureShell (SSH) and Secure Sockets Layer (SSL) provide effective encryption for your communications.

We describe each system in this section.

Reducing vulnerabilities by updating Red Hat Linux packages

Standard hacker operating procedure is simple: Find and then exploit vulnerabilities. The method, simple but effective, works like this: Joe Hacker walks around the Internet, rattling doorknobs and occasionally finding one that’s open. When no door is unlocked, the hacker looks for easier locks to pick. Your job is to make sure that your doors and windows are locked and not easily picked. Running firewalls, shutting down unnecessary services, and using good passwords ensures that you don’t leave anything unlocked. Making sure that your locks are not easily defeated requires constant supervision. Software is now powerful but complex. Complexity breeds bugs, and with bugs come vulnerabilities. Because the only certainties in life are death, taxes, and buggy software, the bugs have to be fixed whenever possible. Everyone needs to continually update software when errors are found and corrected.

Red Hat created an excellent method for updating its software: The Up-to-Date (up2date) system automatically detects new software and installs it for you. Next to using good passwords and firewalls, it’s probably the most effective security system you can run.

TipThe URL shown in the first text box is a server on the Red Hat Network (RHN). However, it's an artifact left over from the Red Hat Linux to Fedora Core conversion that doesn't control where up2date will search for updates. The configuration file /etc/sysconfig/rhn/sources contains the actual up2date server that Fedora will use.

The following steps describe how to configure up2date:

Click the GNOME menu, choose System ToolsRed Hat Network, and enter your root password if you’re prompted.

The Welcome to Red Hat Update Agent window, as shown in Figure 17-1, opens.

Figure 17-1: The Red Hat Network Configuration window.

Click the OK button and the Question dialog box opens.

You’re told that your keyring doesn’t contain the Red Hat public key. A keyring system helps maintain the public keys of places you need to securely communicate with. Because this is the first time you have tried to securely connect to the Red Hat Network, you don’t have its public key.

Click Yes to accept the Red Hat public key.

The Welcome to Red Hat Update Agent window opens.

Click the Forward button.

The Channels dialog box, shown in Figure 17-2, opens showing various options.

Figure 17-2: The Channels window.

The default options should be satisfactory, so click the Forward button.

Any updates that are available will be downloaded and you'll be prompted to install them.

Click the OK button to install the updates (if available).

The updates are installed and an Information dialog box opens.

Click the OK button and the up2date process finishes.

TipYou can skip having to manually click the up2date icon every time an update is available (oh, life is so hard). You can configure up2date to automatically update your system whenever it detects a new package.

Your Red Hat Linux computer can now receive updates. The up2date icon is displayed on the right side of the GNOME Panel. When the icon is green, life is good. When the icon turns red, however, updates are available. (A yellow icon indicates that up2date doesn’t know whether an update exists for your machine.) You want to click the icon so that it downloads and installs the updates.

TipYou can automate the update process using the Linux cron facility. Run the crontab -e command and create a cron entry like this: 0 1 * * * up2date -u. This example launches the up2date utility every day at 1 a.m. The -u option forces up2date to update any available Red Hat packages.

Red Hat provides summary and other information about your account at rhn.redhat.com. Go to that page and enter your username and password in the Sign In to RHN subwindow. You can view the status of your registered machine (or machines), modify your account, and read other important information.

Regularly updating your computer is an essential security measure. Many, many break-ins occur because of out-of-date software. With the help of RHN, you eliminate most vulnerabilities as they occur.

TipRed Hat permits you to register, for free, one computer for basic update service. Basic service allows you to download and install updated RPM packages. To update more machines, you have to purchase additional subscriptions at $60 per year. Note that you can register more machines under the Red Hat Network service, but they aren’t eligible for updates.

Reducing your exposure: Removing and reducing services

Hackers look for computer vulnerabilities by probing for vulnerable network services. Network services — such as Apache, Samba, and DHCP — are, of course, designed to respond to network queries. Therefore, hackers can readily find out what services you run and then find which, if any, attacks to use.

We describe elsewhere how keeping software updated minimizes your vulnerability. However, you can go one step better and make a service invulnerable by turning it off. One simple security rule is “Keep it simple.” The simple fact is that if you don’t need to run a service, you shouldn’t.

We describe in this section how to eliminate or reduce both network and non-network services. This section describes how to use the chkconfig utility to change the startup scripts that control when, how, and whether a network services starts at boot time:

Click the GNOME Menu and choose System SettingsServer SettingsServices. Enter the root password if you’re prompted.

The Service Configuration window opens.

Select an unnecessary service and shut it off by clicking the Stop button.

Click the OK button when the confirmation window appears.

Click the check mark to the left of the service to remove the check mark.

Removing the check mark prevents the service from starting automatically at boot time.

Repeat Steps 2–4 for each unnecessary service.

When you have turned off each unnecessary service, click the Save button.

Choose Quit from the File menu.

Which services you turn off depends on your needs, of course. For example, if you’re unintentionally running a web server, turn off the httpd service. You generally should be able to turn off these services:

The Advanced Power Management Daemon (APMD): APMD is useful if you — like most people — regularly power-off your personal workstation or laptop. However, APMD is generally unnecessary on servers that run continuously. You want to keep APMD in the former case (workstation or laptop) and remove it in the latter (server).

GPM: This service allows you to use a mouse when running in nongraphical mode. You’re running in graphical mode, so turn it off.

The job queue daemon: The atd daemon is used to schedule one-time cron-like jobs. If you need atd, you know it. Otherwise, turn it off.

Network File Sharing (NFS): You need only services such as nfs, nfslock, portmap, and autofs when you’re running an NFS server or client. The last thing you want to do is share files to the Internet, for example.

Print services: Many people don’t run the printer daemon on servers. Turn off cups or lpd whenever you don’t need to print.

Samba: Just like with NFS, you should turn off Samba if you don’t need it.

The rest is up to you. Terminate services with a vengeance.

You can’t modify a service when it isn’t running. You can toggle off the check mark on a nonrunning service, but it doesn’t have any effect if it’s not running.

TipYou can use the CLI-based chkconfig utility. Open a GNOME Terminal session and log in as root (su -):

List the services by running the chkconfig --list command.

List an individual service by specifying the service after the --list option: chkconfig - - list apmd.

Stop a service with the --add option: chkconfig - - add apmd.

Delete a service with the --del option: chkconfig - - del apmd.

Using a Secure Shell client

You may be most familiar with graphical network communication applications, like the Mozilla web browser and Evolution e-mail clients. However, a world of text-based tools is available, such as Secure Shell, Telnet, and FTP. Those applications provide an interactive method for connecting to other computers across networks and the Internet using a command-line interface (CLI); refer to Chapter 4 for more information about CLIs.

Interactive communication is effective for performing tasks on remote machines. For example, the primary way to work on Linux machines originally was via the CLI. The CLI is often the best way to perform remote tasks.

CLI-based communication used to be primarily carried out over the insecure Telnet, FTP, and rsh connections. All services used unencrypted connections, and passwords were readily detected. The rsh service also used a system of intermachine trust. That trust allowed hackers, like the infamous Kevin Mitnik, to “own” a network by breaking into one machine and then logging in to additional ones without authentication.

Open Secure Shell (OpenSSH) provides an encrypted channel to perform all those tasks. Red Hat Linux bundles OpenSSH by default. We describe how first to use the OpenSSH client to communicate with other machines and, second, create an OpenSSH server.

TipYou should (dare we say must?) use encrypted channels when you’re communicating over the Internet and wireless networks. Both the Internet and Wi-Fi connections are inherently insecure, and you have to protect your communications.

Connecting to a Secure Shell server

Start by using OpenSSH as a client. Suppose that you want to log in to your ISP server, ssh.myisp.com, with OpenSSH:

Open a GNOME Terminal session.

Enter this command:

ssh ssh.myisp.com

Your mileage may vary, of course. You may have to use the -l option if, for example, your ISP user account name is different from your local computer. If your username on your local machine is lidia, but it’s lmaura at your ISP, enter this line:

ssh -l lmaura ssh.myisp.com

The first time you connect to a remote server, you’re prompted to accept the remote server’s fingerprint.

Enter yes when you’re prompted.

Enter your password when you’re prompted, and you’re logged in.

For example, you can now use a text-based e-mail client, like pine, to read your messages. This program is useful if you want to read your e-mail securely but can’t connect to your ISP with an SSL-enabled Mozilla or Evolution e-mail client.

Tunneling X across a network

That was a simple and useful way to use OpenSSH, but you can do more. The Red Hat OpenSSH client is automatically configured to forward 1X across its secure connection. While logged on to your ISP, you can run X Window client software and view it on your local machine:

Log in to your ISP (or any machine running a Secure Shell server) as just described.

Run an X Window application, such as xclock.

The simple xclock window is displayed on your desktop.

OpenSSH also bundles the file-transfer applications Secure Copy (scp) and Secure FTP (sftp). Secure Copy is non-interactive and copies files to and from a remote machine. Secure FTP is a secure version of FTP and is also interactive. This list describes how to copy files between two machines:

Copy from a local machine to a remote one: To transfer files from your local computer to a remote one, use Secure Copy (scp):

scp abc myacct@remote.myisp.com

This command copies the filename abc from the directory you’re working in to the myacct.myisp.com home directory on the remote machine. You can specify either or both of the local and remote directories. For example, this command copies the file abc from the /tmp directory on the local machine to the /var/tmp directory on the remote machine and renames it to xyz:

scp myaccount@remote.myisp.com:/tmp/abc /var/tmp/xyz

The scp syntax is important. If you leave out the colon (:), your file isn’t copied to the remote machine but rather is simply copied to a file named

Enter your username and password.

Enter the help command at the sftp prompt.

You see a list of sftp commands. The ones you use most are cd, lcd, dir, ls, get, and put. These commands work in similar fashion to their Linux equivalents.

Using sftp is self-explanatory. Use get to transfer a file, files, or directory from the remote to local machine; put transfers from local to remote.

TipAnother cool feature of OpenSSH is its ability to tunnel any protocol. You can potentially display an entire X Window from a remote machine via X, for example. Consult the OpenSSH documentation for more information.

Configuring an OpenSSH server

Configuring an OpenSSH server is straightforward. You only have to modify the /etc/ssh/sshd_config file and run the /etc/init.d/sshd script. Let’s look at the configuration file, the important parts of which are listed in these bullets:

Remove the older and faulty protocol version 1: Version 1 is broken and should not be used (change the parameter Protocol 2,1 to Protocol 2, as shown in this example):

Port 22
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

Remove the comment from in front of the login grace-time parameter: This action sets a limit on the length of time from when you start a login and the time you complete it:

LoginGraceTime 600

Disallow root logins: You should prevent users, including yourself, from logging in directly as root. Forcing users to first log in as a regular user and then “su-ing" to root provides an audit trail that can be used to see who did what as the root user; it also forces everyone to jump through two hoops before becoming the all-powerful root user:

PermitRootLogin yes
StrictModes yes

Uncomment these parameters to allow the various authentication modes:

# rhosts authentication should not be used
RhostsAuthentication no
# Don’t read the user’s ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Change to yes if you don’t trust ~/.ssh/known_hosts for
RhostsRSAAuthentication and HostbasedAuthentication
IgnoreUserKnownHosts no

Allow people to use password authentication, but don’t allow unauthenticated access:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
PermitEmptyPasswords no

To start the OpenSSH daemon, follow these steps:

Make the changes and restart the Secure Shell daemon:

/etc/init.d/sshd restart

If you’re running a firewall, add this rule to your iptables-based firewall:

iptables -A INPUT  -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

Save your new firewall:

iptables-save > /etc/sysconfig/iptables

Restart the firewall:

/etc/init.d/iptables restart

Now you can use OpenSSH client and server to communicate to and from your Linux computer. Using the OpenSSH client, you can interactively log in to other computers, copy data between computers, and piggyback an arbitrary communication stream — such as X Window — with this puppy. You can reverse that process and communicate with your host Red Hat Linux computer. OpenSSH encrypts all your communication and prevents the exposure of your passwords and data to prying eyes.

Exchanging keys makes your life easier

You use OpenSSH by default to log in to a remote user account by using traditional passwords. However, OpenSSH can use a second authentication method that takes a little work to get started but saves work in the long run.

OpenSSH provides an authentication method called public-key cryptography. This system uses one public and one private key. You install the public key on the remote system and keep the private key on your computer. The public key can be shared with anyone — hey, it’s public. The private key must be kept secret at all costs. In fact, OpenSSH encrypts the private key by default. You must use a pass phrase — essentially a password with spaces — to decrypt the private key before using it.

When you want to log in or communicate with the remote computer, the keys are used to negotiate the process. The public-private key system guarantees that your user account is authenticated and is also the initiating host; passwords only authenticate your login account, not the computer you’re connecting from.

Setting up for a public-key cryptographic key exchange

To set up the key exchange, follow these steps:

Log in to your user account on the local computer.

For example, log in as the user rod on cancun.

Open a GNOME Terminal session.

Run this command:

ssh-keygen –t dsa

Tip This step starts the program that generates your public and private keys. Several encryption methods exist: DSA (Digital Signature Standard) and RSA (named after Ron Rivest, Adi Shamir, and Len Adleman) are the most popular. DSA is a nonproprietary algorithm, whereas RSA was until recently patented. Even though RSA is available for public use, we recommend using DSA.

The program thinks for a moment and returns this output:

Enter file in which to save the key (/home/rod/.ssh/id_dsa):

The keys are saved to the .ssh directory in your home directory. The default should be okay, so press the Return key.

The ssh-keygen program asks you to enter a pass phrase that it uses to encrypt your private key:

Enter passphrase (empty for no passphrase):

Enter your pass phrase and ssh-keygen generates the keys.

Use a phrase peppered with numbers and other characters. For example, you may try a pass phrase like this:

Giv3 m3 @ bre@k!

Verify the phrase by entering it a second time.

The ssh-keygen program generates your public and private keys. Those keys are stored by default in the .ssh directory. The .ssh directory is stored by default in your home directory; ssh-keygen creates the .ssh directory, if necessary.

Copying your public key to the remote computer

You have to copy the public key to the computer you securely communicate with. This steps describe how to copy and configure them:

Log in to your user account on the local computer.

For example, log in as the user rod on cancun.

Open a GNOME Terminal window by clicking the GNOME Menu button and choosing System ToolsTerminal.

Copy your public key to your account on the remote computer. For example, if your account on the remote computer cancun is rod, you can use the Open Secure Copy (scp):

scp .ssh/id_dsa.pub rod@cancun:

In this example, you’re connecting back into the same computer you’re already logged in to. This technique is the simplest way to test the OpenSSH server you’re experimenting with — no other machines, or even a network, are needed.

Enter your account password when you’re prompted, and the DSA public key is copied to your home directory on Cancun.

Log in to the remote machine. For example, use ssh:

ssh cancun

Enter your password when you’re prompted.

OpenSSH looks for public keys by default in the authorized_keys file in the .ssh directory (in your home directory).

Use these commands to copy the public key into the authorized_keys file (remember that you should still be in your home directory):

cat id_dsa.pub >> .ssh/authorized_keys

The cat command "concatenates" the contents of id_dsa.pub to the Linux standard output (that’s generally your console, which is the GNOME Terminal, in this case). The double greater-than symbols (>>) append the standard output to the authorized_keys file in the .ssh directory. No preexisting keys are disturbed.

The authorized_keys file must have the right permissions. (See Appendix B for more information about file permissions.) In this case, loose permissions sink ships, and OpenSSH doesn’t work with, for example, read/-write/-execute group permissions.

Ensure the correct permissions:

chmod 644 .ssh/authorized_keys

Make sure that the OpenSSH server configuration allows key exchange. These options should be set in the /etc/ssh/sshd_config file:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

Restart the sshd daemon if you make any changes to the sshd_config file:

/etc/init.d/sshd restart

Connecting to the remote computer by using key exchange

Ready to use the key exchange authentication system? From the host (local) computer, try these steps:

Log in to your user account on the local computer.

For example, log in as the user rod on cancun.

Open a GNOME Terminal session.

Log in to the remote machine:

ssh cancun

Enter the pass phrase you used to encrypt your private key.

The remote computer authenticates you and your host computer. Voil! You’re in.

Making life even easier with ssh-agent

Red Hat automatically starts a system named ssh-agent. With ssh-agent, you enter your pass phrase and ssh-agent remembers it. You have to enter the pass phrase only once while logged in to your account. From then on, ssh-agent provides the OpenSSH clients with the pass phrase and you no longer have to enter a password or pass phrase. Life is easy.

Setting up ssh-agent is simple. Follow these steps:

Log in to your user account on the local computer.

For example, log in as the user rod on cancun.

Open a GNOME terminal by clicking the GNOME Menu and choosing System ToolsTerminal.

Enter this command:

ssh-add

Enter your pass phrase when you’re prompted.

Connect to the remote machine — for example, Cancun:

ssh cancun

You get logged in to your account on the remote machine without having to enter a password or pass phrase. This system works great.

Introducing encryption and security

Running a simple web server like the one introduced in Chapter 16 shouldn’t require you to make heroic security measures. Serving up static text and graphics doesn’t pique the interest of many hackers. However, when you start using the Web to do business or process sensitive information, you want to bump up your security. You build on the basic web server and create a secure web server.

Use the Secure Sockets Layer (SSL) protocol to construct a secure web server. SSL provides a mechanism that allows your web server to provide protected and authenticated connections. Using SSL with Apache allows the web server to prevent eavesdropping by encrypting the network communications to and from the web server and to identify itself to the client browser.

SSL provides encryption and ensures identification, which are described in the following two sections.

Encryption

The mathematical process encryption essentially garbles information so that only those with authorization can ungarble (and read) it; encryption prevents everyone whom you don’t want to read your communications from reading it. The process of encryption and decryption requires the combination of the mathematical process named encryption algorithm and the mathematical entity cryptographic keys (keys, for short). A key is basically a very long number.

A description of the mathematical process of encryption is beyond the scope of this book, but suffice it to say that you need a key to encrypt information and a key to decrypt it. SSL uses a type of encryption named public-key encryption. Public-key encryption works by having the server keep a secret key and the client use a public key. The public key can be known and used by anyone and everyone; the private key must be kept secret and known only to the server.

Public-key encryption has an advantage over other encryption types because distributing public keys across a medium like the Internet is easy. It sounds counterintuitive, but public-key encryption does work.

Identification

All the encryption in the world is useless if you’re tricked into connecting to the wrong web server. Suppose that you want to purchase a book from Amazon.com. You fire up Mozilla, connect to www.amazon.com, and happily enter your credit card number, expecting to receive your book the next day. It never comes.

In this scenario, some clever hacker has injected false DNS information into the Internet and your browser has even connected to www.hackazon.com. (Your web browser looked up the numeric IP address of Amazon.com but was deceived and received the address of the hacker’s fraudulent web server.) In this case, encryption worked like it was supposed to and prevented other hackers from intercepting your credit card. However, it didn’t ensure that the web server was the one you thought it was, and now the hacker is enjoying a wonderful vacation in Cancun, thanks to your credit card. D’oh!

SSL identification is based on the concept of a certificate. Certificates contain the public key you need to set up an encrypted connection and additional information used to verify the identity of the web server. The certificate also comes with information about who created it, when it was created, and how it was created. After you obtain a certificate from the web server you’re connecting to, you’re ready to safely conduct business. Huh? What good does that do if you’re connecting to the hacker’s web server? The certificate just ensures that you connect securely to the bad-boy site.

The problem is solved by using a go-between called a certificate authority (CA). When you connect to a secure web server, it sends you its certificate. The web server also subscribes to a CA. The CA has investigated the subscribing web server and, if satisfied with its authenticity, vouches for its identity. If the CA is on your list of known CAs, you accept the certificate and use the public key to verify the server’s identity and set up the encrypted connection.

Protecting your web server with SSL

A secure web server requires a certificate. The certificate is used to verify the web server to its clients. The instructions in this section describe how to create the certificate.

You can view the list of CAs your browser knows about. Follow these steps to view the CA list:

Choose Mozilla EditPreferences.

The Preferences window opens.

Expand the Privacy & Security menu by clicking the plus (+) sign immediately to the left of the menu option.

Click the Certificates menu.

The Certificates subwindow opens.

Click the Manage Certificates button.

The Certificate Manager window opens behind the Preferences window.

Click the upper margin of the Preferences window and move it so that you can see the Certificate Manager window.

Click the Authorities tab and you see a list of all CAs your browser knows about.

Your browser automatically accepts the certificate from any secure web page you visit that subscribes to one of these CAs.

It costs time and money to subscribe to a CA, of course. However, you don’t necessarily need to spend the money if you intend to use your secure web server for personal use or just to experiment. We show you how to construct a certificate and then use it without registering with a CA.

These steps outline the general process of creating a certificate:

Install the SSL software.

Create your web server’s private key.

Create your web server’s certificate.

You can optionally register your certificate with a CA. For example, VeriSign, Inc., is one of the most widely known CAs. Go to www.verisign. com and click the SSL Certificates link to find out more about its service.

Connect to the secure web server and accept the certificate; accepting the certificate is automatic if the server subscribes to a CA; otherwise, you have to accept the certificate manually.

Just like Apache, the SSL software is included in the Red Hat Linux distribution. The following sections describe how to install, configure, and use SSL to create a secure web server.

Installing the SSL package

Follow these steps to install the SSL module package (we assume that you have already installed the Apache web server, as described in Chapter 16):

Log in as root and open the GNOME Terminal session by clicking the GNOME Menu button and choosing System ToolsTerminal.

Apache needs an additional RPM package to provide SSL connections.

Insert the companion DVD in the DVD/CD-ROM drive.

Enter this command to install the SSL package:

rpm -ivh /mnt/cdrom/RedHat/RPMS/mod_ssl*

Creating a private key

Recall that public-key encryption requires that the server use a private key. (Your web browser — the client — uses the public key.) We describe in this section how to generate a private key.

Generate your web server’s private key by following these steps. Installing the Mod_ssl package created several directories in /etc/httpd/conf that contain generic keys and certificates. You have to remove those "dummy" files before you can create your own.

Enter these commands to remove the generic key and certificate:

cd /etc/httpd/conf/ssl.key
rm server.key ../ssl.crt/server.crt

Press y each time you’re prompted to remove the files.

Change to this directory, where the make file certificate is located:

cd /usr/share/ssl/certs

The makefile contains instructions for making the certificate. All you have to do is “run” the makefile and specify the action to take:

make genkey

This text is printed:

umask 77 ; /usr/bin/openssl genrsa -des3 1024 > /etc/httpd/conf/ssl.key/server.key
Generating RSA private key, 1024 bit long modulus
.....................++++++
...................++++++
e is 65537 (0x10001)
Enter pass phrase:

Tip Remember your pass phrase! You’re asked to enter the pass phrase whenever you start your secure web server. You also have to manually start the web server and enter the pass phrase in order to start it.

You have to enter a pass phrase. Like a password, a pass phrase protects your private key on the web server. Enter a good pass phrase.

For example, enter something like this:

hack me no more

Note that spaces are allowed and are, in fact, encouraged.

Enter the same phrase a second time when you’re prompted.

The Apache web server’s private key is now in place. The key is readable by only the root user. Protect this key at all costs.

Certify yourself: Creating your own certificate

You need to generate a public key to use with the private one. Although the secure web server uses the private key, your web browser uses a public one. The browser uses the public key to verify the authenticity of the server; the server uses the public and private keys to create the encrypted connection.

Public keys are contained within a certificate.

Follow these steps to create your own certificate.

Change to the directory where the certificate generating makefile is located:

cd /usr/share/ssl/certs

Make the new certificate by entering this command:

make testcert

You’re prompted for the pass phrase you created in the preceding section. Enter the pass phrase when you’re prompted.

You’re prompted to enter information about your location, IP address, and other information that can help identify your certificate as valid. These steps outline the questions and what you need to enter.

You’re prompted to enter your country code.

For example, enter US if you live in the United States, GB for Great Britain, or MX for Mexico.

Enter your state (for the United States) or province name. (Don’t abbreviate the name.)

For example, enter New Mexico.

Enter your city name.

In this example, enter Albuquerque.

Enter your organization or company name if you have one.

For example, enter Paunchy Heavy Industries, Ltd.

Optionally, enter your suborganization, if you have one.

Enter the full name of your web server.

For example, the sample web server is named Veracruz, and the network name is paunchy.net. Therefore, you enter veracruz.paunchy.net.

The name of your server must match its DNS name (if you run your own DNS server). If the two don’t match, you’re prompted to access or reject the certificate every time you connect to the web server.

Enter your e-mail address:

paul@paunchy.net

Your certificate is constructed. Restart your web server with this command:

/etc/init.d/httpd restart

Danger, Will Robinson! Detecting intruders

Everybody needs a loyal, vigilant robot to sound the alert when aliens, monsters, Dr. Smith, and hackers come at you. You can’t have literal robots (or can you?), but you can have an intrusion-detection system (IDS).

Intrusion detection is the flip side of intrusion prevention. You can’t depend on not getting hacked unless you turn off your computer and lock it in your panic room. Remember that no silver bullet exists in the world of computer security. You have to take measures to detect whether and when you get compromised.

Intrusion detection requires more on-going work than any of the security systems we discuss in this book. The other systems, such as firewalls and password protection, require some up-front work, but then run without much additional work. An IDS, however, requires some initial installation and configuration and then continual review. You have to monitor an IDS daily if you want it to be of any use to you.

Many IDSs — far too many to describe here — can give you extra security. We suggest two mature and relatively easy-to-use systems that provide good bang for your buck: Snort and Tripwire.

Snort is a network-based IDS. It looks for patterns in your network traffic that indicate hacker probes and break-in attempts. Snort isn’t perfect and does report false positive alerts. You’re going have to spend time identifying and eliminating false-positives if you want to use Snort. However, that will be time well spent because Snort is considered to be an excellent IDS by system administrators and security professionals. Go to www.snort.org to find more information.

Tripwire works by securely recording the fingerprints of files and directories and then comparing them to subsequent ones. Any differences between the current and original fingerprint indicates the file has changed and might have been compromised. The fingerprints are called checksums, which are unique mathematical values calculated from the contents of a file or directory. You can find Tripwire at www. tripwire.com.

Enter the pass phrase when you’re prompted and your secure web server starts.

Connecting to your secure web server

After you have created the private key and certificate, you can connect to your secure web server.

These steps describe how the process of obtaining the server’s certificate works:

Log in to your Red Hat Linux computer and open Mozilla.

Click the GNOME Main Menu and choose InternetMozilla Web Browser.

Enter the URL of your secure web server.

For example, enter channel. All your communication is hidden from eavesdropping.

You can view the certificate you just accepted by opening the Manage Certificate window from the Mozilla Preferences dialog box, as described earlier in this chapter.

TipGo to this site to find out how to create and register a certificate with a Certificate Authority (CA):

www.redhat.com/docs/manuals/linux/RHL-10-Manual/custom-guide/s1-secureserver-generatingkeyl

iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED -j -dport 443