Configuring FTP and FTP Firewall Settings in IIS 7

Introduction

Microsoft has created a new FTP service that has been completely rewritten for Windows Server® 2008. This FTP service incorporates many new features that enable web authors to publish content better than before, and offers web administrators more security and deployment options.

Prerequisites

The following items are required to be installed to complete the procedures in this article:

1. IIS 7 must be installed on your Windows 2008 Server, and Internet Information Services (IIS) Manager must be installed.

2.You must create a root folder for FTP publishing:

• Create a folder at "%SystemDrive%\inetpub\ftproot"
• Set the permissions to allow anonymous access:
  • Open a command prompt.
  • Type the following command:
    ICACLS "%SystemDrive%\inetpub\ftproot" /Grant IUSR:R /T
• Close the command prompt.

Important Notes:

• The settings listed in this walkthrough specify "%SystemDrive%\inetpub\ftproot" as the path to your FTP site. You are not required to use this path; however, if you change the location for your site you will have to change the site-related paths that are used throughout this walkthrough.
• Once you have configured your firewall settings for the FTP service, you must configure your firewall software or hardware to allow connections through the firewall to your FTP server.
• If you are using a different firewall, please consult the documentation that was provided with your firewall software or hardware.

Use the FTP Site Wizard to Create an FTP Site With Anonymous Authentication

In this section you, create a new FTP site that can be opened for Read-only access by anonymous users. To do so, use the following steps:

1. Go to IIS 7 Manager. In the Connections pane, click the Sites node in the tree.
2. Right-click the Sites node in the tree and click Add FTP Site, or click Add FTP Site in the Actions pane.

3. When the Add FTP Site wizard appears:

• Enter "My New FTP Site" in the FTP site name box, then navigate to the "%SystemDrive%\inetpub\ftproot" folder that you created in the Prerequisites section. Note: If you choose to type in the path to your content folder, you can use environment variables in your paths.
• Click Next.

4. On the next page of the wizard:

• Choose an IP address for your FTP site from the IP Address drop-down, or choose to accept the default selection of "All Unassigned." Because you will be accessing this FTP site remotely, you want to make sure that you do not restrict access to the local server and enter the local loopback IP address for your computer by typing "127.0.0.1" in the IP Address box.
• You would normally enter the TCP/IP port for the FTP site in the Port box. For this walk-through, you will choose to accept the default port of 21.
• For this walkthrough, you do not use a host name, so make sure that the Virtual Host box is blank.
• Make sure that the Certificates drop-down is set to "Not Selected" and that the Allow SSL option is selected.
• Click Next.

 

5. On the next page of the wizard:

• Select Anonymous for the Authentication settings.
• For the Authorization settings, choose "Anonymous users" from the Allow access to drop-down. Select Read for the Permissions option.
• Click Finish.

6. Go to IIS 7 Manager. Click the node for the FTP site that you created. The icons for all of the FTP features display.

Summary

To recap the items that you completed in this step:

1. You created a new FTP site named "My New FTP Site", with the site's content root at "%SystemDrive%\inetpub\ftproot".
2. You bound the FTP site to the local loopback address for your computer on port 21, choosing not to use Secure Sockets Layer (SSL) for the FTP site.
3. You created a default rule for the FTP site to allow anonymous users "Read" access to the files.

Step 1: Configure the Passive Port Range for the FTP Service

In this section, you configure the server-level port range for passive connections to the FTP service. Use the following steps:

1. Go to IIS 7 Manager. In the Connections pane, click the server-level node in the tree.

2. Double-click the FTP Firewall Support icon in the list of features.

3. Enter a range of values for the Data Channel Port Range.

4. Once you have entered the port range for your FTP service, click Apply in the Actions pane to save your configuration settings.

Notes:

1. The valid range for ports is 1024 through 65535. (Ports from 1 through 1023 are reserved for use by system services.)
2. You can enter a special port range of "0-0" to configure the FTP server to use the Windows TCP/IP dynamic port range.
3. This port range will need to be added to the allowed settings for your firewall server.

Step 2: Configure the external IPv4 Address for a Specific FTP Site

In this section, you configure the external IPv4 address for the specific FTP site that you created earlier. Use the following steps:

1. Go to IIS 7 Manager. In the Connections pane, click the FTP site that you created earlier in the tree, Double-click the FTP Firewall Support icon in the list of features.

2. Enter the IPv4 address of the external-facing address of your firewall server for the External IP Address of Firewall setting.

3. Once you have entered the external IPv4 address for your firewall server, click Apply in the Actions pane to save your configuration settings.

Summary

To recap the items that you completed in this step:

1. You configured the passive port range for your FTP service.
2. You configured the external IPv4 address for a specific FTP site.

(Optional) Step 3: Configure Windows Firewall Settings

Windows Server 2008 contains a built-in firewall service to help secure your server from network threats. If you choose to use the built-in Windows Firewall, you will need to configure your settings so that FTP traffic can pass through the firewall.

There are a few different configurations to consider when using the FTP service with the Windows Firewall - whether you will use active or passive FTP connections, and whether you will use unencrypted FTP or use FTP over SSL (FTPS). Each of these configurations are described below.

Note: You will need to make sure that you follow the steps in this section walkthrough while logged in as an administrator. This can be accomplished by one of the following methods:

• Logging in to your server using the actual account named "Administrator".
• Logging on using an account with administrator privileges and opening a command-prompt by right-clicking the Command Prompt menu item that is located in the Accessories menu for Windows programs and selecting "Run as administrator".

One of the above steps is required because the User Account Control (UAC) security component in the Windows Vista and Windows Server 2008 operating systems prevents administrator access to your firewall settings.

Note: While Windows Firewall can be configured using the Windows Firewall applet in the Windows Control Panel, that utility does not have the required features to enable all of the features for FTP. The Windows Firewall with Advanced Security utility that is located under Administrative Tools in the Windows Control Panel has all of the required features to enable the FTP features, but in the interests of simplicity this walkthrough will describe how to use the command-line Netsh.exe utility to configure the Windows Firewall.

Using Windows Firewall with non-secure FTP traffic

To configure Windows Firewall to allow non-secure FTP traffic, use the following steps:

1. Open a command prompt: click Start, then All Programs, then Accessories, then Command Prompt.
2. To open port 21 on the firewall, type the following syntax then hit enter:

   netsh advfirewall firewall add rule name="FTP (non-SSL)" action=allow protocol=TCP dir=in localport=21

3. To enable stateful FTP filtering that will dynamically open ports for data connections, type the following syntax then hit enter:

   netsh advfirewall set global StatefulFtp enable

Important Notes:

• Active FTP connections would not necessarily covered by the above rules; an outbound connection from port 20 would also need to be enabled on server. In addition, the FTP client machine would need to have its own firewall exceptions setup for inbound traffic.
• FTP over SSL (FTPS) will not be covered by these rules; the SSL negotiation will most likely fail because the Windows Firewall filter for stateful FTP inspection will not be able to parse encrypted data. (Some 3rd-party firewall filters recognize the beginning of SSL negotiation, e.g. AUTH SSL or AUTH TLS commands, and return an error to prevent SSL negotiation from starting.)

Using Windows Firewall with secure FTP over SSL (FTPS) traffic

The stateful FTP packet inspection in Windows Firewall will most likely prevent SSL from working because Windows Firewall filter for stateful FTP inspection will not be able to parse the encrypted traffic that would establish the data connection. Because of this behavior, you will need to configure your Windows Firewall settings for FTP differently if you intend to use FTP over SSL (FTPS). The easiest way to configure Windows Firewall to allow FTPS traffic is to list the FTP service on the inbound exception list. The full service name is the "Microsoft FTP Service", and the short service name is "ftpsvc". (The FTP service is hosted in a generic service process host (Svchost.exe) so it is not possible to put it on the exception list though a program exception.)

To configure Windows Firewall to allow secure FTP over SSL (FTPS) traffic, use the following steps:

1. Open a command prompt: click Start, then All Programs, then Accessories, then Command Prompt.
2. To configure the firewall to allow the FTP service to listen on all ports that it opens, type the following syntax then hit enter:

   netsh advfirewall firewall add rule name="FTP for IIS7" service=ftpsvc action=allow protocol=TCP dir=in

3. To disable stateful FTP filtering so that Windows Firewall will not block FTP traffic, type the following syntax then hit enter:

   netsh advfirewall set global StatefulFtp disable

   
   
   

   More Information about Working with Firewalls

   It is often challenging to create firewall rules for FTP server to work correctly, and the root cause for this challenge lies in the FTP protocol architecture. Each FTP client requires two connections to be maintained between client and server:
   • FTP commands are transferred over a primary connection called the Control Channel, which is typically the well-known FTP port 21.
   • FTP data transfers, such as directory listings or file upload/download, require a secondary connection called Data Channel.
   Opening port 21 in a firewall is an easy task, but this means that an FTP client will only be able to send commands, not transfer data. This means that the client will be able to use the Control Channel to successfully authenticate and create or delete directories, but the client will not be able to see directory listings or be able to upload/download files. This is because data connections for FTP server are not allowed to pass through the firewall until the Data Channel has been allowed through the firewall.
   Note: This may appear confusing to an FTP client, because the client will seem to be able to successfully log in to the server, but the connection may appear to timeout or stop responding when attempting to retrieve a directory listing from the server.
   The challenges of working with FTP and firewalls doesn't end with the requirement of a secondary data connection; to complicate things even more, there are actually two different ways on how to establish data connection:
   • Active Data Connections: In an active data connection, an FTP client sets up a port for data channel listening and the server initiates a connection to the port; this is typically from the server's port 20. Active data connections used to be the default way of connecting to FTP server; however, active data connections are no longer recommended because they do not work well in Internet scenarios.
   • Passive Data Connections: In a passive data connection, an FTP server sets up a port for data channel listening and the client initiates a connection to the port.
   Note: Some FTP clients require explicit action to enable passive connections, and some clients don't even support passive connections. (One such example is command-line Ftp.exe utility that ships with Windows.) To add to the confusion, some clients attempt to intelligently alternate between the two modes when network errors happen, but unfortunately this does not always work.

   Some firewalls try to remedy problems with data connections with built-in filters that scan FTP traffic and dynamically allow data connections through the firewall. These firewall filters are able to detect what ports are going to be used for data transfers and temporarily open them on firewall so that clients can open data connections. (Some firewalls may enable filtering FTP traffic by default, but it is not always the case.) This type of filtering  is known as a type of Stateful Packet Inspection (SPI) or Stateful Inspection, meaning that the firewall is capable of intelligently determine the type of traffic and dynamically choose how to respond. Many firewalls now employ these features, including the built-in Windows Firewall.
   
   

Read More

Create a new site in IIS 7

The following article explains how to create a new website on your Windows server in IIS 7. IIS 7 (Internet Information Services) controls the configuration of each website on the server. There are two types of websites that can be configured, IP based sites and Name based sites*.


1. Log into your server through Remote Desktop Connection.

2. Click Start > All Programs > Administrative Tools > Internet Information Services (IIS) Manager.

3. Expand the server name.

4. Right-click Sites and choose Add Web Site…

5. Type in the Site Name. A description or the domain name is best to put into this field. This will automatically create an Application Pool for the site.

6. Enter or browse to the path where the website will have its root directory. This is the directory where the home page should go.

7. For the Binding, choose HTTP, choose an IP address that is free, leave the port as port 80, and enter in your domain name (i.e. www.domain.com) as the Host Name. Leave the checkbox for Start Web site immediately checked and click OK.

8. Go back to the IIS7 main screen and select the site under the Sites folder. Click Bindings… on the right sidebar so there is a host header for domain.com as well.

9. Click the Add button, choose HTTP, use the same IP address as setup in step 7, leave the port as port 80, and enter in your domain name (i.e.domain.com) as the Host Name. Click OK.

An IP-based website has a unique IP address therefore no other website can use this IP address. 

A name-based website shares a single IP address with each website on the server. You are able to make as many name-based sites as you wish with your single IP address.

Read More

Installing IIS 7 on Windows Server 2008 or Windows Server 2008 R2

Introduction

You can use Microsoft^® Web Platform Installer (Web PI) to easily install Internet Information Services (IIS) and applications that run on IIS. However, if you choose to install IIS manually, you can use this article for guidance.

IIS 7.0 is the Web server role in Windows Server^® 2008 and the Web server in Windows Vista^®. IIS 7.5 is the Web server role in Windows Server^® 2008 R2 and the Web server in Windows^® 7. Windows Server 2008 R2 and Windows Server 2008 operating systems have all the IIS features needed to support the hosting of Web content in production environments. Windows 7 and Windows Vista also include IIS features, but the available features depend on the operating system versions.

Before You Begin

Ensure that you have administrative user rights on the computer on which you plan to install IIS 7. Note that by default, you do not have administrative user rights if you are logged on as a user other than as the built-in administrator, even if you were added to the local Administrators group on the computer (this is a new security feature in Windows Server 2008 called Local User Administrator).

Install IIS 7.5 on Windows Server 2008 R2

IIS is one of the Windows Server^® server roles. IIS 7 can be installed through the graphical user interface (GUI) by using the new Server Manager interface after the Windows Server operating system is installed.

Server Manager provides a single dashboard to install or uninstall server roles and features. Server Manager also gives an overview of all currently installed roles and features. When IIS 7 is chosen from the Server Manager, the basic components and services needed for IIS are automatically selected.

1. Click Start -> All Programs -> Administrative Tools -> Server Manager.

2. In the Server Manager window, scroll down to Roles Summary, and then click Add Roles. The Add Roles Wizard will start with a Before You Begin page. The wizard asks for verification of the following:

      a. The administrator account has a strong password.

      b. The network settings, such as IP addresses, are configured.

      c. The latest security updates from Windows^® Update are installed.

3. Select Web Server (IIS) on the Select Server Roles page. An introductory page will open with links for further information.

Note: When you use the Add Roles Wizard to install IIS, you get the default installation, which has a minimum set of role services. If you need additional IIS role services, such as Application Development or Health and Diagnostics, make sure to select the check boxes associated with those features in the Select Role Services page of the wizard.

4. Select the IIS services to be installed on the Select Role Services page. Add only the modules necessary. In this case, ASP.NET is selected, and a description of ASP.NET appears in the right pane. Once desired modules are added, click Next.

5. Add any required role services.

6. IIS is now installed with a default configuration for hosting ASP.NET on Windows Server. Click Close to complete the process.

7. Confirm that the Web server works by using http://localhost.

Note: Install only the absolutely necessary IIS services to minimize the IIS installation footprint. This also minimizes the attack surface, which is one of the benefits of IIS 7.

Install IIS 7.0 on Windows Server 2008

1. To start Server Manager, click Start Menu -> All Programs -> Administrative Tools -> Server Manager. The Server Manager window opens

2. In the Server Manager window, select Roles. The Role Summary View is displayed.

3. Click Add Roles. The Add Roles Wizard opens. Click Next to select roles to install.

4. Select Web Server (IIS). 

5. The Add Roles Wizard notifies you of any required dependencies; since IIS depends on the Windows Process Activation Service (WAS) feature, the following informational dialog box appears. Click Add Required Role Services to continue.

6. The Web Server is now selected for install. The Select Server Roles dialog box opens. Click Next to continue.

7. The following dialog box and information appears. Click Next to continue.

8. The Add Roles Wizard displays a list of all IIS 7.0 features available to install as shown below. Note that features comprising the default install are pre-selected.

9. To install just the IIS 7.0 default features, click the Install button, and then proceed to Step 14. If you need to install additional features, proceed to step 10.

10. For this example, we install additional IIS features. Select the check box for ASP.NET. The Wizard warns if adding an IIS feature will also cause other features to be installed.

11. Click Add Required Role Services to continue.

12. Continue selecting additional IIS Role Services features to install.

13. When you have selected all the features you require, click Next to continue.14. The Wizard provides a summary of what will be installed.

15. Click Install to continue. The Installation Progress dialog box opens.

16. When the IIS 7.0 installation is complete, the following dialog box opens. Click Close to return to the Server Manager.

17. You can now perform a quick check to verify that IIS 7.0 is installed. Start the Windows^® Internet Explorer^® Web browser, and enter the addresshttp://localhost. You should see the default IIS "Welcome" page.

Read More

How To Set Up A Ubuntu LAMP Server

HTTPD - Apache2 Web Server
Apache is the most commonly used Web Server on Linux systems. Web Servers are used to serve Web Pages requested by client computers. Clients typically request and view Web Pages using Web Browser applications such as Firefox, Opera, or Mozilla.
Users enter a Uniform Resource Locator (URL) to point to a Web server by means of its Fully Qualified Domain Name (FQDN) and a path to the required resource. For example, to view the home page of the Ubuntu Web site a user will enter only the FQDN. To request specific information about paid support, a user will enter the FQDN followed by a path.
The most common protocol used to transfer Web pages is the Hyper Text Transfer Protocol (HTTP). Protocols such as Hyper Text Transfer Protocol over Secure Sockets Layer (HTTPS), and File Transfer Protocol (FTP), a protocol for uploading and downloading files, are also supported.
Apache Web Servers are often used in combination with the MySQL database engine, the HyperText Preprocessor (PHP) scripting language, and other popular scripting languages such as Python and Perl. This configuration is termed LAMP (Linux, Apache, MySQL and Perl/Python/PHP) and forms a powerful and robust platform for the development and deployment of Web-based applications.

Installation

The Apache2 web server is available in Ubuntu Linux. To install Apache2:

• At a terminal prompt enter the following command:
  

  sudo apt-get install apache2

  
  

Configuration

Apache is configured by placing directives in plain text configuration files. The main configuration file is called apache2.conf. In addition, other configuration files may be added using the Include directive, and wildcards can be used to include many configuration files. Any directive may be placed in any of these configuration files. Changes to the main configuration files are only recognized by Apache2 when it is started or restarted.
The server also reads a file containing mime document types; the filename is set by the TypesConfig directive, and is mime.types by default.
The default Apache2 configuration file is /etc/apache2/apache2.conf . You can edit this file to configure the Apache2 server. You can configure the port number, document root, modules, log files, virtual hosts, etc.

Basic Settings

This section explains Apache2 server essential configuration parameters. Refer to the Apache2 Documentation for more details.

• Apache2 ships with a virtual-host-friendly default configuration. That is, it is configured with a single default virtual host (using the VirtualHost directive) which can modified or used as-is if you have a single site, or used as a template for additional virtual hosts if you have multiple sites. If left alone, the default virtual host will serve as your default site, or the site users will see if the URL they enter does not match the ServerName directive of any of your custom sites. To modify the default virtual host, edit the file /etc/apache2/sites-available/default. If you wish to configure a new virtual host or site, copy that file into the same directory with a name you choose. For example, sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/mynewsite Edit the new file to configure the new site using some of the directives described below.
  
• The ServerAdmin directive specifies the email address to be advertised for the server's administrator. The default value is webmaster@localhost. This should be changed to an email address that is delivered to you (if you are the server's administrator). If your website has a problem, Apache2 will display an error message containing this email address to report the problem to. Find this directive in your site's configuration file in /etc/apache2/sites-available.
  
• The Listen directive specifies the port, and optionally the IP address, Apache2 should listen on. If the IP address is not specified, Apache2 will listen on all IP addresses assigned to the machine it runs on. The default value for the Listen directive is 80. Change this to 127.0.0.1:80 to cause Apache2 to listen only on your loopback interface so that it will not be available to the Internet, to (for example) 81 to change the port that it listens on, or leave it as is for normal operation. This directive can be found and changed in its own file, /etc/apache2/ports.conf
  
• The ServerName directive is optional and specifies what FQDN your site should answer to. The default virtual host has no ServerName directive specified, so it will respond to all requests that do not match a ServerName directive in another virtual host. If you have just acquired the domain name ubunturocks.com and wish to host it on your Ubuntu server, the value of the ServerName directive in your virtual host configuration file should be ubunturocks.com. Add this directive to the new virtual host file you created earlier (/etc/apache2/sites-available/mynewsite).
  

  	You may also want your site to respond to www.ubunturocks.com, since many users will assume the www prefix is appropriate. Use the ServerAlias directive for this. You may also use wildcards in the ServerAlias directive. For example, ServerAlias *.ubunturocks.com will cause your site to respond to any domain request ending in .ubunturocks.com.

  
  
• The DocumentRoot directive specifies where Apache should look for the files that make up the site. The default value is /var/www. No site is configured there, but if you uncomment the RedirectMatch directive in /etc/apache2/apache2.conf requests will be redirected to /var/www/apache2-default where the default Apache2 site awaits. Change this value in your site's virtual host file, and remember to create that directory if necessary!
  

	The /etc/apache2/sites-available directory is not parsed by Apache2. Symbolic links in /etc/apache2/sites-enabled point to "available" sites. Use the a2ensite (Apache2 Enable Site) utility to create those symbolic links, like so: sudo a2ensite mynewsite where your site's configuration file is /etc/apache2/sites-available/mynewsite. Similarly, the a2dissite utility should be used to disable sites.

Default Settings

This section explains configuration of the Apache2 server default settings. For example, if you add a virtual host, the settings you configure for the virtual host take precedence for that virtual host. For a directive not defined within the virtual host settings, the default value is used.

• The DirectoryIndex is the default page served by the server when a user requests an index of a directory by specifying a forward slash (/) at the end of the directory name.
  For example, when a user requests the page http://www.example.com/this_directory/, he or she will get either the DirectoryIndex page if it exists, a server-generated directory list if it does not and the Indexes option is specified, or a Permission Denied page if neither is true. The server will try to find one of the files listed in the DirectoryIndex directive and will return the first one it finds. If it does not find any of these files and if Options Indexes is set for that directory, the server will generate and return a list, in HTML format, of the subdirectories and files in the directory. The default value, found in /etc/apache2/apache2.conf is " index.html index.cgi index.pl index.php index.xhtml". Thus, if Apache2 finds a file in a requested directory matching any of these names, the first will be displayed.
  
• The ErrorDocument directive allows you to specify a file for Apache to use for specific error events. For example, if a user requests a resource that does not exist, a 404 error will occur, and per Apache2's default configuration, the file /usr/share/apache2/error/HTTP_NOT_FOUND.html.var will be displayed. That file is not in the server's DocumentRoot, but there is an Alias directive in /etc/apache2/apache2.conf that redirects requests to the /error directory to /usr/share/apache2/error/. To see a list of the default ErrorDocument directives, use this command: grep ErrorDocument /etc/apache2/apache2.conf
  
• By default, the server writes the transfer log to the file /var/log/apache2/access.log. You can change this on a per-site basis in your virtual host configuration files with the CustomLog directive, or omit it to accept the default, specified in /etc/apache2/apache2.conf. You may also specify the file to which errors are logged, via the ErrorLog directive, whose default is /var/log/apache2/error.log. These are kept separate from the transfer logs to aid in troubleshooting problems with your Apache2 server. You may also specify the LogLevel (the default value is "warn") and the LogFormat (see /etc/apache2/apache2.conf for the default value).
  
• Some options are specified on a per-directory basis rather than per-server. Option is one of these directives. A Directory stanza is enclosed in XML-like tags, like so:
  

  
      ...
     
                    
                  

  The Options directive within a Directory stanza accepts one or more of the following values (among others), separated by spaces:
  
  • ExecCGI - Allow execution of CGI scripts. CGI scripts are not executed if this option is not chosen.
    

    	Most files should not be executed as CGI scripts. This would be very dangerous. CGI scripts should kept in a directory separate from and outside your DocumentRoot, and only this directory should have the ExecCGI option set. This is the default, and the default location for CGI scripts is /usr/lib/cgi-bin.

    
    
  • Includes - Allow server-side includes. Server-side includes allow an HTML file to include other files. This is not a common option. See the Apache2 SSI Howto for mor information.
    
  • IncludesNOEXEC - Allow server-side includes, but disable the #exec and #include commands in CGI scripts.
    
  • Indexes - Display a formatted list of the directory's contents, if no DirectoryIndex (such as index.html) exists in the requested directory.
    

    	For security reasons, this should usually not be set, and certainly should not be set on your DocumentRoot directory. Enable this option carefully on a per-directory basis only if you are certain you want users to see the entire contents of the directory.

    
    
  • Multiview - Support content-negotiated multiviews; this option is disabled by default for security reasons. See the Apache2 documentation on this option.
    
  • SymLinksIfOwnerMatch - Only follow symbolic links if the target file or directory has the same owner as the link.
    

Virtual Hosts Settings

Virtual hosts allow you to run different servers for different IP addresses, different host names, or different ports on the same machine. For example, you can run the website for http://www.example.com and http://www.anotherexample.com on the same Web server using virtual hosts. This option corresponds to the directive for the default virtual host and IP-based virtual hosts. It corresponds to the directive for a name-based virtual host.
The directives set for a virtual host only apply to that particular virtual host. If a directive is set server-wide and not defined within the virtual host settings, the default setting is used. For example, you can define a Webmaster email address and not define individual email addresses for each virtual host.
Set the DocumentRoot directive to the directory that contains the root document (such as index.html) for the virtual host. The default DocumentRoot is /var/www.
The ServerAdmin directive within the VirtualHost stanza is the email address used in the footer of error pages if you choose to show a footer with an email address on the error pages.

Server Settings

This section explains how to configure basic server settings.
LockFile - The LockFile directive sets the path to the lockfile used when the server is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or USE_FLOCK_SERIALIZED_ACCEPT. It must be stored on the local disk. It should be left to the default value unless the logs directory is located on an NFS share. If this is the case, the default value should be changed to a location on the local disk and to a directory that is readable only by root.
PidFile - The PidFile directive sets the file in which the server records its process ID (pid). This file should only be readable by root. In most cases, it should be left to the default value.
User - The User directive sets the userid used by the server to answer requests. This setting determines the server's access. Any files inaccessible to this user will also be inaccessible to your website's visitors. The default value for User is www-data.

	Unless you know exactly what you are doing, do not set the User directive to root. Using root as the User will create large security holes for your Web server.

The Group directive is similar to the User directive. Group sets the group under which the server will answer requests. The default group is also www-data.

Apache Modules

Apache is a modular server. This implies that only the most basic functionality is included in the core server. Extended features are available through modules which can be loaded into Apache. By default, a base set of modules is included in the server at compile-time. If the server is compiled to use dynamically loaded modules, then modules can be compiled separately, and added at any time using the LoadModule directive. Otherwise, Apache must be recompiled to add or remove modules. Ubuntu compiles Apache2 to allow the dynamic loading of modules. Configuration directives may be conditionally included on the presence of a particular module by enclosing them in an block. You can install additional Apache2 modules and use them with your Web server. You can install Apache2 modules using the apt-get command. For example, to install the Apache2 module for MYSQL authentication, you can run the following command from a terminal prompt:

sudo apt-get install libapache2-mod-auth-mysql

Once you install the module, the module will be available in the /etc/apache2/mods-available directory. You can use the a2enmod command to enable a module. You can use the a2dismod command to disable a module. Once you enable the module, the module will be available in the the /etc/apache2/mods-enabled directory.

HTTPS Configuration

The mod_ssl module adds an important feature to the Apache2 server - the ability to encrypt communications. Thus, when your browser is communicating using SSL encryption, the https:// prefix is used at the beginning of the Uniform Resource Locator (URL) in the browser navigation bar.
The mod_ssl module is available in apache2-common package. If you have installed this package, you can run the following command from a terminal prompt to enable the mod_ssl module:

sudo a2enmod ssl

Certificates and Security

To set up your secure server, use public key cryptography to create a public and private key pair. In most cases, you send your certificate request (including your public key), proof of your company's identity, and payment to a Certificate Authority (CA). The CA verifies the certificate request and your identity, and then sends back a certificate for your secure server.
Alternatively, you can create your own self-signed certificate. Note, however, that self-signed certificates should not be used in most production environments. Self-signed certificates are not automatically accepted by a user's browser. Users are prompted by the browser to accept the certificate and create the secure connection.
Once you have a self-signed certificate or a signed certificate from the CA of your choice, you need to install it on your secure server.

Types of Certificates

You need a key and a certificate to operate your secure server, which means that you can either generate a self-signed certificate or purchase a CA-signed certificate. A CA-signed certificate provides two important capabilities for your server:

• Browsers (usually) automatically recognize the certificate and allow a secure connection to be made without prompting the user.
  
• When a CA issues a signed certificate, it is guaranteeing the identity of the organization that is providing the web pages to the browser.
  

Most Web browsers that support SSL have a list of CAs whose certificates they automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser asks the user to either accept or decline the connection.
You can generate a self-signed certificate for your secure server, but be aware that a self-signed certificate does not provide the same functionality as a CA-signed certificate. A self-signed certificate is not automatically recognized by most Web browsers, and a self-signed certificate does not provide any guarantee concerning the identity of the organization that is providing the website. A CA-signed certificate provides both of these important capabilities for a secure server. The process of getting a certificate from a CA is fairly easy. A quick overview is as follows:

1. Create a private and public encryption key pair.
   
2. Create a certificate request based on the public key. The certificate request contains information about your server and the company hosting it.
   
3. Send the certificate request, along with documents proving your identity, to a CA. We cannot tell you which certificate authority to choose. Your decision may be based on your past experiences, or on the experiences of your friends or colleagues, or purely on monetary factors.
   Once you have decided upon a CA, you need to follow the instructions they provide on how to obtain a certificate from them.
   
4. When the CA is satisfied that you are indeed who you claim to be, they send you a digital certificate.
   
5. Install this certificate on your secure server, and begin handling secure transactions.
   

Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key.

Generating a Certificate Signing Request (CSR)

To generate the Certificate Signing Request (CSR), you should create your own key. You can run the following command from a terminal prompt to create the key:

openssl genrsa -des3 -out server.key 1024

Generating RSA private key, 1024 bit long modulus
.....................++++++
.................++++++
unable to write 'random state'
e is 65537 (0x10001)
Enter pass phrase for server.key:

You can now enter your passphrase. For best security, it should at least contain eight characters. The minimum length when specifying -des3 is four characters. It should include numbers and/or punctuation and not be a word in a dictionary. Also remember that your passphrase is case-sensitive.
Re-type the passphrase to verify. Once you have re-typed it correctly, the server key is generated and stored in server.key file.

	You can also run your secure web server without a passphrase. This is convenient because you will not need to enter the passphrase every time you start your secure web server. But it is highly insecure and a compromise of the key means a compromise of the server as well.

In any case, you can choose to run your secure web server without a passphrase by leaving out the -des3 switch in the generation phase or by issuing the following command at a terminal prompt:

openssl rsa -in server.key -out server.key.insecure

Once you run the above command, the insecure key will be stored in the server.key.insecure file. You can use this file to generate the CSR without passphrase.
To create the CSR, run the following command at a terminal prompt:

openssl req -new -key server.key -out server.csr

It will prompt you enter the passphrase. If you enter the correct passphrase, it will prompt you to enter Company Name, Site Name, Email Id, etc. Once you enter all these details, your CSR will be created and it will be stored in the server.csr file. You can submit this CSR file to a CA for processing. The CAN will use this CSR file and issue the certificate. On the other hand, you can create self-signed certificate using this CSR.

Creating a Self-Signed Certificate

To create the self-signed certificate, run the following command at a terminal prompt:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

The above command will prompt you to enter the passphrase. Once you enter the correct passphrase, your certificate will be created and it will be stored in the server.crt file.

	If your secure server is to be used in a production environment, you probably need a CA-signed certificate. It is not recommended to use self-signed certificate.

Installing the Certificate

You can install the key file server.key and certificate file server.crt or the certificate file issued by your CA by running following commands at a terminal prompt:

sudo cp server.crt /etc/ssl/certs
sudo cp server.key /etc/ssl/private

You should add the following four lines to the /etc/apache2/sites-available/default file or the configuration file for your secure virtual host. You should place them in the VirtualHost section. They should be placed under the DocumentRoot line:

SSLEngine on

SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire

SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key

HTTPS should listen on port number 443. You should add the following line to the /etc/apache2/ports.conf file:

Listen 443

Accessing the Server

Once you install your certificate, you should restart your web server. You can run the following command at a terminal prompt to restart your web server:

sudo /etc/init.d/apache2 restart 

	You should remember and enter the passphrase every time you start your secure web server.

You will be prompted to enter the passphrase. Once you enter the correct passphrase, the secure web server will be started. You can access the secure server pages by typing https://your_hostname/url/ in your browser address bar.

Read More