Running Services

There are literally hundreds of different types of servers that you can install and use. However, when it comes to services on the Internet, there are a couple of main ones that you will probably want to enable. These include SSH, FTP, e-mail, and web.

Hardening SSH

The Secure Shell server (sshd) provides encrypted and authenticated remote connectivity for logins, file transfers, and remote command execution. The basic SSH server installation (sudo apt-get install openssh-server, discussed in Chapter 5) is secure enough to immediately place on the Internet. However, there are some parameters in the /etc/ssh/sshd_ config file that you might want to modify for added security (see Table 12-2).

Table 12-2: Commonly Modified SSH Server Parameters
Open table as spreadsheet

Option	Default Value	Purpose
AllowUsers	AllowUsers *	Restricts login access to a list of user names (separated by white space). You can also specify user@host to restrict access to a specific user logging in from a specific host. If only some users should have remote access, then you can use this to explicitly block all other users.
AllowGroups	AllowGroups *	Similar to AllowUsers, you can specify group names found in /etc/group. Only users who are members of the specified groups are allowed to login. To find the groups you are in, use the groups command.
LoginGraceTime	LoginGraceTime 120	Specifies the number of seconds a user should sit at the password prompt before being disconnected. The sshd has a limit on the number of concurrent connections. If someone is trying to block your connection by tying up all available connections, then consider lowering this value from 120 seconds to 5. You may also want to lower this value if you have users who connect but take too long trying to remember their passwords.
MaxStartups	MaxStartups 10	Specifies how many concurrent login attempts are permitted (before successfully entering your password). The default is 10 concurrent, unauthenticated connections. You should consider changing this to 10:30:60. This specifies allowing 10 concurrent. If the 10 are connected, then drop them at a rate of 30/100-there is a 30-percent chance that some connection will be dropped before LoginGraceTime. This will continue until the maximum of 60 connections is reached; then all new connections are dropped.
Port	Port 22	For servers on the Internet, consider moving them to a port other than 22/tcp. Although this is technically "security by obscurity", it will deter most simple reconnaissance attacks from finding your server and attempting brute-force logins.

Tip 

There are two parameters in /etc/ssh/sshd_config that are serious risks any to system on the Internet: PermitRootLogin and PermitEmptyPasswords. By default, users with empty passwords cannot log in. Although the default setting does permit root logins, Ubuntu does not give root a password. Still, setting either of these to yes is a serious risk for system on the Internet. You should consider changing both of them to no.

After you change anything in the /etc/ssh/sshd_config file, you will need to restart the server:

 sudo /etc/init.d/ssh restart 

Restarting the server will apply all the changes to new connections, but existing connections will be unaffected.

Using SSH Keys

SSH supports different types of authentication. Basic password authentication is the most common approach. However, password authentication isn't very good for automated tasks like cron jobs (see Chapter 7) that use SSH for network administration.

Another form of authentication uses keys. These can be used in place of passwords. The SSH keys are similar to PGP (see Chapter 10) in that they are asymmetrical; there is a public and a private key. Creating SSH keys requires generating keys on the client and transferring the public key to the server.

1. The ssh-keygen program is used to generate SSH keys on the client. You will need to specify the algorithm (DSA or RSA) and the bit size. For security, use a key size of at least 2048 bits.

    % ssh-keygen -t dsa -b 2048 Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): [enter] Enter passphrase (empty for no passphrase): [password][enter] Enter same passphrase again: [password][enter] Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: 82:be:37:65:df:d9:f6:20:0a:fc:85:76:8a:c6:61:10 user@ubuntu 

   Generating keys longer than 2048 bits may take awhile. Be patient and it will eventually ask you where to save the keys.

   Tip 

   The passphrase is used to protect the key from theft. If you are not worried about other users on the system stealing your SSH key file, then you can leave this blank. For automated system, you should probably leave it blank.

2. Generating keys creates two files. $HOME/.ssh/id_dsa (or id_rsa) holds the private key, whereas $HOME/.ssh/id_dsa.pub (or id_rsa.pub) is the public key. Transfer the public key from the client to the remote server.

    scp $HOME/.ssh/id_dsa.pub remote:id_dsa.pub 

   This will use SSH to copy the public key from your local system to the server named remote. The file will be copied to $HOME/id_dsa.pub (not $HOME/.ssh/id_dsa.pub on the remote host).

3. You will need to tell the server which keys are permitted for logins. Copy the contents of id_dsa to $HOME/.ssh/authorized_keys. If the file exists, then you can just append to it.

    mkdir $HOME/.ssh   # in case it does not exist cat $HOME/id_dsa.pub >> $HOME/.ssh/authorized_keys 

4. On some SSH servers, you may need to make sure the server accepts keys. Edit (or have the administrator edit) the /etc/ssh/sshd_config file and make sure RSAAuthentication and PubkeyAuthentication are both set to yes. (Under the default installation for Ubuntu, they are already set to yes.) If you made changes, then you will also need to restart the SSH server.

5. Test the connection. You should be able to use ssh and connect to the host using only your key. If you entered a passphrase for the key, then you will be prompted for it but it will not be transferred across the network. Without a passphrase, you should immediately get a command-line prompt.

Tip 

If the server does not accept the key, then it will regress to using the user's login password. If you want to disable password-based logins, then set PasswordAuthentication to no in /etc/ssh/sshd_config.

Debugging SSH Connections

The most common problem with SSH is an unknown server key. During the server installation, a server key is generated. The OpenSSH client caches this key the first time you connect to the server, and then compares new keys during subsequent connections. There are only a few real reasons why the server key may not match. First and most common, the server was reinstalled for some reason and generated a new key, or was replaced by a different server with a different key. The alternative is that someone is trying to hijack your connection. Both will appear as a message that looks something like this:

 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 7f:23:ac:9d:4f:6d:88:eb:db:61:85:af:8b:c6:f3:21. Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending key in /home/user/.ssh/known_hosts:7 RSA host key for localhost has changed and you have requested strict checking. Host key verification failed. 

To resolve this problem, you'll need to remove the offending server's key from the SSH cache file: $HOME/.ssh/known_hosts. In this case, delete line 7 as specified in the warning:

 /home/user/.ssh/known_hosts:7. 

Warning 

Although hijacking is extremely rare, it is definitely possible! Do not just fix the cache file without making sure that it isn't a real attack. If you are at a coffeehouse (or hacker conference) and you own this server and nothing should have changed, then don't try to fix the connection to the server! If nothing should have changed then this probably is an attack and removing the cached entry can allow the attacker access to your system.

Enabling FTP

I use a variety of operating systems-some new and some very old. Using SSH to log in and transfer files between Unix and Linux systems is convenient. However, other operating systems may not be as convenient for using SSH. For example, in my opinion the best SSH clients for Windows are commercial and costly (although some free ones do exist). In some cases (for example, my OS/2 system) SSH is unavailable.

Since I need to transfer files between systems, I have found that FTP is ubiquitous, and usually a little faster than SSH even if it is not as secure. For a local network, FTP is a great file transfer option. For direct Internet access, FTP can be secure enough as long as you lock down the system and recognize that anyone may gain access to the server. Besides being universally available to all clients, FTP also overcomes one serious limitation found in SSH: SSH does not permit anonymous logins. With FTP, anyone can connect to a shared directory for collaboration.

Installing VSFTPD

Ubuntu offers a variety of FTP servers (apt-cache search ftpd). My personal preference is the Very Secure FTP Daemon (VSFTPD). I like all of the customizable features and the fact that it is secure enough to be given direct Internet access immediately after being installed. However, you'll probably want to customize the system since the basic installation gives no access.

Installing the server is straightforward:

 sudo apt-get install vsftpd 

The installation will start the server as a stand-alone process (not requiring inetd), configure the /etc/init.d/vsftpd startup script, and create the user ftp for anonymous access. The server immediately permits anonymous read-only access to the directory /home/ftp. You can log in using the user name anonymous or ftp with any password.

 $ ftp localhost Connected to localhost. 220 (vsFTPd 2.0.4) Name (localhost:ubuntu): anonymous 331 Please specify the password. Password: ******** 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls -la 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. drwxr-xr-x    2 0        65534        4096 Dec 09 16:30 . drwxr-xr-x    2 0        65534        4096 Dec 09 16:30 .. 226 Directory send OK. 

Any files or directories placed in the /home/ftp/ directory will be accessible by the anonymous FTP user. However, regular users do not have access until you explicitly enable it (see the section "Adjusting Regular FTP Access" later in this chapter).

Adjusting Anonymous FTP Access

If you don't want anonymous FTP access, then you can disable it.

1. As root, edit /etc/vsftpd.conf.

2. Change the configuration value anonymous_enable=YES to anonymous_enable=NO.

3. Restart the FTP server:

    sudo /etc/init.d/vsftpd restart 

Tip 

You will need to restart the server any time you make a change to /etc/vsftpd.conf.

However, if you want to enable FTP access, then there are many configuration options you might want to change. Table 12-3 shows some of the anonymous FTP configuration options. Other options can be found in the online manual (man vsftpd.conf).

Table 12-3: Anonymous FTP Options for /etc/vsftpd.conf
Open table as spreadsheet

Option	Example	Purpose
anon_upload_enable	anon_upload_ enable=YES	Allow anonymous users to upload files to the /home/ftp/directory.
anon_mkdir_write_enable	anon_mkdir_write_enable=YES	Allow anonymous users to create directories under /home/ftp/ with the mkdir FTP command.
anon_other_write_enable	anon_other_write_enable=YES	Allow anonymous users to rename or delete files under /home/ftp/.
anon_max_rate	anon_max_rate=131072	Throttle file transfer rates for anonymous users. This specifies 131,072 bytes per second (or 1 megabit per second).
anon_world_readable_only	anon_world_readable_ only=YES	Restrict anonymous users to downloading only files that are world-readable. This way, the user ftp may have private files that cannot be downloaded.
hide_ids	hide_ids=YES	Changes all user and group IDs so they look like ftp. By default, all IDs are shown by their numeric values.
secure_email_list_enable	secure_email_list_ enable=YES	Force anonymous users to provide a valid password. You will need to create the file /etc/vsftpd. email_passwords and give it a list of passwords, one per line. Any of these passwords are acceptable for anonymous access.

Tip 

If you allow anonymous users to upload files, consider enabling disk quotas for user ftp (see Chapter 8). This way, anonymous FTP users won't consume all of your disk space.

Adjusting Regular FTP Access

By default, VSFTPD disables FTP access for regular users. To enabling FTP access for local (non-anonymous) users:

1. Edit /etc/vsftpd.conf.

2. Uncomment the local_enable=YES line.

3. Restart the server:

    sudo /etc/init.d/vsftpd restart 

After these changes, any user may FTP to his or her account by specifying a valid username and password. There are other local user options for /etc/vsftpd.conf that you may want to modify (see Table 12-4).

Table 12-4: Local User FTP Options for /etc/vsftpd.conf
Open table as spreadsheet

Option	Example	Purpose
max_clients	max_clients=20	Limit the number of client connections. In this case, up to 20 clients can be connected at once. The default value is 0 meaning no limit.
max_per_ip	max_per_ip=2	Specify how many FTP connections may come from the same IP address. The default is 0 meaning no limit.
local_max_rate	local_max_rate=1048576	Specify the number of bytes per second for throttling FTP connections. This example sets a limit of one megabyte (eight megabit) per second. If you have an 8 Mbps connection, then consider setting the limit to 6 Mbps or less so the FTP server will not consume all available network bandwidth. The default value has no limit.
chroot_local_user	chroot_local_user=YES	Restrict local users to their home directories rather than letting them access anything on the system.
chroot_list_enable	chroot_list_enable=YES	Specify a list of users that should or should not be limited to their home directories. If chroot_local_ user is NO, then this is a list of users who should be restricted. If chroot_local_user is YES, then this is a list of users who should not be restricted. The list of users (one user name per line) is stored in /etc/vsftpd.chroot_list (you'll need to create this file).

Tip 

VSFTPD logs every connection, file transfer, and anonymous login password to the file /var/log/vsftpd.log. If your system is connected to the Internet, then you should monitor this log file for possible attacks or abuse. The log file is rotated weekly by the logrotate configuration file /etc/logrotate.d/vsftpd (see Chapter 10 for rotating log files).

Securing Internet FTP

FTP is not a secure protocol. Every user name and password is transmitted in plain text across the network. If your server is accessible from the Internet, then anyone capable of capturing your packets will see your valid user name and password. If you need to give users FTP access, consider creating a second account strictly for FTP access. By default, new accounts are given a unique group name. You can create an FTP-only account for each user, and assign the accounts to the user's group name. For example, user bill can be given the account bill-ftp in the group bill:

 sudo useradd -m -g bill -c "FTP for Bill" bill-ftp 

Be sure to give bill write-access to the bill-ftp directory:

 sudo chmod -R g+w /home/bill-ftp 

Then you can give this account a different password than Bill's regular account.

 sudo passwd bill-ftp 

Finally, you can block SSH and remote login access for any account containing -ftp in the account name.

1. Edit /etc/ssh/sshd_config.

2. Add the following option: DenyUsers *-ftp

3. Restart the SSH server: sudo /etc/init.d/ssh restart

This way, user bill can access the directory bill-ftp. But if his login credentials are ever compromised, then the attacker will be unable to access the account through SSH.

Enabling Postfix

E-mail is pretty much a mandatory network service. If you don't want to host your own e-mail, then you just need an e-mail client (see Chapter 5). However, if you plan to actually receive e-mail on your own system, then you will need an e-mail server. In addition, many applications generate status reports using e-mail. You will need a server if you want to send the e-mails directly to yourself.

Tip 

I have a home firewall that can e-mail its system logs. Rather than sending the logs out to my ISP, I have them sent directly to my own, internal mail server running on an Ubuntu system.

Ubuntu offers many different e-mail servers. However, Sendmail, Qmail, and Postfix are the most common under Linux. Of these servers, Sendmail is the oldest and most widely used, but it is also historically the most insecure. My personal preference is Postfix because of its security, speed, and reliability. Each of these mail servers support configurations that vary from plug- and-play simple to extremely complex. Unfortunately, none of these mail servers are trivial to configure. (Sendmail is one of the most complicated ones to configure-another reason that I like Postfix.)

To get started with your mail server, you will need to install the server package, configure it, and test it. If it tests well and seems to work, then you can be really daring and open it to the world.

1. Install the Postfix server. This will create the appropriate startup scripts, place default files, and start the server:

    sudo apt-get install postfix 

2. During the installation, you will be prompted for the type of installation. Your options are:

   • No configuration-Install the server but leave it unconfigured. (Probably not what you want unless you are trying to repair a broken installation.)

   • Internet Site-Assume the server will be directly connected to the Internet. Use this if you actually intend to send and receive e-mail directly. This is the default option but it is probably not what you want if you are installing on a home system, private network, or for a small business.

   • Internet with smarthost-This configuration is useful for most home users who need to relay out-bound e-mail through an ISP's smart mail relay. This can be used to provide a mail server to a local never even if the host is not accessible from the Internet.

Note 

A smarthost is a mail relay that knows how to route e-mail across the Internet. Many ISPs provide a smarthost for sending e-mail. You'll need to ask your ISP if they have an SMTP server for outbound delivery.

• Satellite system-This option configures Postfix as a system for sending e-mail through a smart mail relay, but not for receiving. This is a great option if your actual e-mail is stored on some other server.

• Local only-Choose this configuration if you have no external systems that will be relaying e-mail through this host.

I usually choose the Internet Site or Internet with smarthost option for primary servers. However, for secondary servers and workstations, I use the Satellite system. Depending on the option you choose, you will be prompted to supply your own mailing domain, smarthost name, and other configuration values. Then the installation will complete and the server will start up.

Post-Installation Configuration

There are a couple of options in /etc/postfix/main.cf that you might want to modify or add after the installation.

• relayhost-This option is the IP address or host name of the smarthost. If it is blank, then no smarthost is used.

• mydestination-This is a comma-separated list of host names and domains that are used for local delivery. You probably should add your system's host name to this list. Also, if this server is expected to receive e-mail for multiple domains, then you'll want to add every domain here.

• myhostname-This option specifies you host's Internet host name that is revealed when sending e-mail. I usually make this my Internet domain name rather than my private LAN's domain since seeing e-mail from neuhaus.roach.lan won't make sense to anyone but me.

• mydomain-Similar to myhostname, this specifies your Internet domain name. If you have a vanity (personal) domain, you can put it here rather than using your ISP or any private domain name.

• inet_interfaces-You can specify one or more network interfaces for receiving e-mail. If your system has multiple network interfaces but only one that should receive e-mail, then you definitely need to modify this line. If you're just testing, you can always say inet_interfaces = loopback-only and only receive e-mail from yourself.

• mynetworks-If other systems will be relaying e-mail through your server, then you will need to specify the networks that can relay e-mail. For example, I use:

   mysetworks = 127.0.0.0/8, 10.0.0.0/8 

  This setting enables me to send e-mail from localhost (the 127.0.0.1 subnet) and from my private, local network: 10.x.x.x. All other machines (not on these networks) that connect to my mail server can only deliver e-mail directly to this host; they cannot relay. This way, my host will not be used to relay spam to other networks.

• smtpd_banner-This is the welcome banner that is displayed any time a mail client connects to the mail server. For security, it should display as little information as possible about the system-don't display the server's version since that can be used by an attacker to gain knowledge about the server. The default setting does not give a version, but it does state Ubuntu (I recommend removing that). I usually make a simple banner:

   smtpd_banner = Private System - All connections are logged. 

There are many more configuration options. The file /usr/share/postfix/main.cf.dist is a template that describes every default option and configuration. Alternately, you can consult the man page: man 5 postconf. When you finish tweaking your configuration file, you need to tell Postfix to reload it:

 sudo /etc/init.d/postfix reload 

Testing Postfix

When you have it all configured, try sending an e-mail to yourself-both locally and to a remote system so that you can verify network access. Also, if any systems on your network will be relaying through your server, then try relaying e-mail. If there are any problems or errors, you should see them logged in /var/log/mail.log.

Opening Postifx

If you are going to be making your mail server publicly accessible from the Internet, then you will need to open port 25/tcp in your firewall. This traffic should go to your mail server. After opening the firewall, you can try e-mailing yourself from outside your network and see if you receive it.

Warning 

Opening your mail server to the Internet is not as easy as opening a port in a firewall. You're also going to need to configure your DNS entry for your domain so the server is listed as a mail exchanger (DNS MX record). How to do this depends on your domain registrar or DNS hosting provider. Contact them if you have questions.

Enabling Apache

Web servers play an important role on most networks. You can use them to create official web sites, or to test web pages before making them public. On internal networks, placing a file on a web site for download can be more convenient than using an FTP server. In addition, server- side scripts such as CGI scripts and PHP can create dynamic content. As a software developer, I frequently use HTML and CGI scripts to mock up graphic interfaces and user flows before devoting time to creating the final "real" interface.

The Ubuntu repositories contain a wide variety of web servers. For example, thttpd is a tiny server that is ideal for minimal-resource systems. Other server packages include dhttpd, fnord, and the Roxen Challenger server (roxen4). However, Apache is by and far the most common server. Although it isn't tiny, it is fast, stable, secure, and extremely flexible.

The basic Apache package installs the core web server: sudo apt-get install apache. This provides the server (httpd), startup script (/etc/init.d/apache), and log management file (/etc/logrotate.d/apache). You should be able to connect to it using http://localhost/ and see a generic web page (see Figure 12-1).

Figure 12-1: The default Apache server web page

Are You Being Served?

There are actually two different branches of Apache web servers: 1.x and 2.x. The Apache Software Foundation supports both versions. Basically, the 2.x branch is a complete rewrite and offers features such as IPv6 support and a new software API. However, unless you plan to create plug-ins for Apache (not CGI), you'll probably never notice a difference.

For Ubuntu, the apache package installs Apache 1.x, while apache2 installs the 2.x version. My preference is usually for Apache 1.x since it seems a little faster to me. (Unless I'm developing plug-ins, in which case I like the 2.x API). However, if I'm just creating web pages and CGI scripts, or installing web applications like Wikis and blogs, then either version works well.

Post-Installation Configuration

After installing Apache, there are a few configuration items that you will want to tweak. These are stored in the /etc/apache/httpd.conf file.

• ServerName-This configuration option specifies the host name to use during a redirection. It defaults to localhost-that's fine for testing but it really should be a network identifiable host name. Use either the machines public IP address or public domain name instead of localhost.

• ServerAdmin-This is the person to contact in case of a problem. It defaults to webmaster@localhost. I recommend creating a webmaster account for your domain and setting that as the contact. I try not to use specific users since people in companies have a tendency to move around-it's easier to change the mail alias than contact everyone who has the webmaster e-mail address.

• DocumentRoot-The default root is /var/www/. I usually change this to /home/ www-data/ (after creating a directory for the www-data user). I mainly do this because on my systems /home/ usually has more disk space than /var/ and if I'm enabling disk quotas, then /home/ usually has quotas enabled.

Beyond the basic contact and host name configurations, I also modify some of the default directories and files listed in the /etc/apache/httpd.conf file. Most of this is done for additional security.

• Remove unneeded aliases-Anything that is not needed on the server can be used to profile and potentially attack the server. I usually remove the web server's /doc/ entry, /images/, and /perl/. For example, /doc/ is defined as:

   <IfModule mod_alias.c>   Alias /doc/ /usr/share/doc/ </IfModule> <Location /doc>   order deny,allow   deny from all   allow from 127.0.0.0/255.0.0.0   Options Indexes FollowSymLinks MultiViews </Location> 

  I remove all of this. Even though /doc/ is only accessible from the local system, I have never needed to use any of these files from the web browsers. Providing these over the web could tell an attacker exactly what software (and vulnerabilities) are on my system.

• Disable indexes-Throughout the configuration file are Options lines that reference Indexes. For example:

   <Directory /var/www/> Options Indexes Includes FollowSymLinks MultiViews ... 

  Just remove the Indexes keyword. With this option, a directory without an index.html file will actually show the directory contents. This enables anyone to browse any file that may be accessible from the web server-including backup versions, temporary files, and hidden or personal directories. Removing the Indexes option blocks open directories and returns an error. If a specific directory should be open, then I can open it on an as- needed basis.

• Enable CGI scripts-I do a lot of programming, so I like to have CGI scripts enabled. I usually edit the public_html section and add ExecCGI to the list of options. This way, any executable in any user's public_html directory will act as a CGI script. The entire section ends up looking like:

   <Directory /home/*/public_html>     AllowOverride FileInfo AuthConfig Limit     Options MultiViews SymLinksIfOwnerMatch ExecCGI     <Limit GET POST OPTIONS PROPFIND>         Order allow,deny         Allow from all     </Limit>     <Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>         Order deny,allow         Deny from all     </Limit> </Directory> 

You will also need to go down to the AddHandler section and uncomment the CGI handler line:

 AddHandler cgi-script .cgi .sh .pl 

This handler allows any file that ends with .cgi, .sh, or .pl to be used as a CGI script.

Warning 

Enabling CGI scripts is definitely not for everyone. There are huge security implications here. If you enable CGI scripts for everyone, then there is a very serious threat of an attacker exploiting a weak script and compromising your system. For public servers that host many different users, I strongly recommend not enabling ExecCGI for everyone. But if it is just you on a private server, then this is a very convenient option.

After changing the /etc/apache/httpd.conf file, you will need to reload the configuration file.

 sudo /etc/init.d/apache reload 

Extending Apache

The basic Apache installation is good for serving web pages and handling basic CGI scripts. However, there are many additional packages that can be added to extend the server's functionality. These additional modules provide functionality that integrates into the web server. The full list of available modules can be found with apt-cache search libapache-mod.

Table 12-5 lists some of the available packages and the functionality that they provide. You can install any of them using apt-get install package. In some cases, there will be additional configuration steps needed before the modules can be used.

Table 12-5: Additional Apache Packages
Open table as spreadsheet

Package	Functionality
libapache-mod-perl	Adds support for Perl support. You can use <Perl>…</Perl> sections in your HTML to execute server-side scripting with Perl.
libapache-mod-ssl	Adds SSL support to the Apache server. This enables you to use HTTP or HTTPS. However, you will need to configure your SSL certificates before enabling SSL.
libapache-mod-php4	Provides PHP version 4 server-side scripting support. (If you are using Apache 2.x, then install libapache2-mod-php4 instead.)
libapache2-mod-php5	Provides PHP version 5 server-side scripting support for Apache 2.x. Unfortunately, at the time of this writing, libapache-mod-php5 was not available as a package for the Apache 1.x server. However, the php5-cgi package provides similar functionality.
tomcat5	This module provides support for Java and JSP web pages. Unlike the other modules, this one requires a large number of dependencies for supporting the Java environment.

Note 

For many of these modules, you can install them as an Apache plug-in or statically linked into the web server. For example, mod_perl can be loaded using libapache-mod-perl or statically provided by apache-perl. From my viewpoint, there is no real reason to have most of these libraries statically linked.

Creating Web Pages

After configuring the web server, you will want to create some HTML web pages. At minimum, you will want to replace the default placeholder (as previously shown in Figure 12-1) with your own page-or a blank page. Unless you change it (like I usually do), the default server web pages are located in /var/www/ and the placeholder is /var/www/index.html. Individual users can create a public_html directory (mkdir $HOME/public_html) and place their personal files in this directory. For example, Bill (my technical reviewer) can use:

 mkdir /home/bill/public_html echo "Test page" > /home/bill/public_html/index.html 

He can then access his test page using http://localhost/˜bill/.

Tip 

If you get an error accessing your page, check the file and directory permissions. Your home directory, public_html directory, and every web page need to be accessible by user ww-data or group www-data. This usually means making your home directory at least world-executable (chmod a+x $HOME) and the web directory world readable: find $HOME/public_html -type d -exec chmod 755 ‘{}‘ \; and chmod -R a+r $HOME/public_html.