Jun 27

Using Apache With Microsoft Windows

By jason Apache Server 1 Comment »

This document explains how to install, configure and run Apache 1.3 under Microsoft Windows. Please note that at this time, Windows support is entirely experimental, and is recommended only for experienced users. The Apache Group does not guarantee that this software will work as documented, or even at all. If you find any bugs, please document them on our bug reporting page. Contributions are welcomed, please submit your code or suggestions to the bug report page, or join the new-httpd mailing list.

The bug reporting page and new-httpd mailing list are not provided to answer questions about configuration or running Apache. Before you submit a bug report or request, first consult this document, the Frequently Asked Questions page and the other relevant documentation topics. If you still have a question or problem, post it to the comp.infosystems.www.servers.ms-windows newsgroup, where many Apache users and several contributions are more than willing to answer new and obscure questions about using Apache on Windows.

groups.google.com’s newsgroup archive offers easy browsing of previous questions. Searching the newsgroup archives, you will usually find your question was already asked and answered by other users!

Warning: Apache on NT has not yet been optimized for performance. Apache still performs best, and is most reliable on Unix platforms. Over time NT performance has improved, and great progress is being made in the upcoming version 2.0 of Apache for the Windows platforms. Folks doing comparative reviews of webserver performance are still asked to compare against Apache on a Unix platform such as Solaris, FreeBSD, or Linux.

Most of this document assumes that you are installing Windows from a binary distribution. If you want to compile Apache yourself (possibly to help with development, or to track down bugs), see Compiling Apache for Microsoft Windows.

Requirements

Apache 1.3 is designed to run on Windows NT 4.0 and Windows 2000. The binary installer will only work with the x86 family of processors, such as Intel’s. Apache may also run on Windows 95 and 98, but these have not been tested. In all cases TCP/IP networking must be installed.

If running on NT 4.0, installing Service Pack 3 or 6 is recommended, as Service Pack 4 created known issues with TCPIP/WinSock integrity that were resolved in later Service Packs.

Note: "Winsock 2" is required for Apache 1.3.7 and later.

If running on Windows 95, the "Winsock2" upgrade must be installed before Apache will run. "Winsock2" for Windows 95 is available here or via here. Be warned that the Dialup Networking 1.2 (MS DUN) updates include a Winsock2 that is entirely insufficient, and the Winsock2 update must be reinstalled after installing Windows 95 dialup networking.

Downloading Apache for Windows

Information on the latest version of Apache can be found on the Apache web server at http://www.apache.org/httpd. This will list the current release, any more recent alpha or beta-test releases, together with details of mirror web and anonymous FTP sites.

You should download the binary build of Apache for Windows named as apache_1_3_#-win32-with_src.msi if you are interested in the source code, or simply apache_1_3_#-win32-no_src.msi if you don’t plan to do anything with the source code and appreciate a faster download. Each of these files contains the complete Apache runtime. You must have the Microsoft Installer version 1.10 installed on your PC before you can install the Apache runtime distributions. Windows 2000 and Windows ME are both delivered with the Microsoft Installer support, others will need to download it. Instructions on locating the Microsoft Installer, as well as the binary distributions of Apache, are found at http://httpd.apache.org/dist/httpd/binaries/win32/

The source code is available in the -with_src.msi distribution, or from the http://httpd.apache.org/dist/httpd/ distribution directory as a .zip file. If you plan on compiling Apache yourself, there is no need to install either .msi package. The .zip file contains only source code, with MS-DOS line endings (that is cr/lf line endings, instead of the single lf used for Unix files.)

While the source is also available as a .tar.gz .tar.Z archive, these contain unix lf line endings that cause grief for Windows users. To use those archives, you must convert at least the .mak and .dsp files to have DOS line endings before MSVC can understand them. Please stick with the .zip file to spare yourself the headache.

Note: prior to 1.3.17 Apache was distributed as an InstallShield 2.0 .exe file. With an increasing number of users unable to run the InstallShield package [on Windows ME or Windows 2000] the binaries were repackaged into the readily available Microsoft Installer .msi format.

Installing Apache for Windows

Run the Apache .msi file you downloaded above. This will prompt you for:

  • your name and company name, and on Windows NT/2000, whether or not you want all users to access Apache as a Service, or if you want it installed to run when you choose the Start Apache shortcut.
  • your Server name, Domain name and administrative email account.
  • the directory to install Apache into (the default is C:\Program Files\Apache Group\Apache although you can change this to any other directory you wish)
  • the installation type. The "Complete" option installs everything, including the source code if you downloaded the -with_src.msi package. Choose the "Custom" install if you choose not to install the documentation, or the source code from that package.

During the installation, Apache will configure the files in the conf directory for your chosen installation directory. However if any of the files in this directory already exist they will not be overwritten. Instead the new copy of the corresponding file will be left with the extension .default. So, for example, if conf\httpd.conf already exists it will not be altered, but the version which would have been installed will be left in conf\httpd.conf.default. After the installation has finished you should manually check to see what in new in the .default file, and if necessary update your existing configuration files.

Also, if you already have a file called htdocs\index.html then it will not be overwritten (no index.html.default file will be installed either). This should mean it is safe to install Apache over an existing installation (but you will have to stop the existing server running before doing the installation, then start the new one after the installation is finished).

After installing Apache, you should edit the configuration files in the conf directory as required. These files will be configured during the install ready for Apache to be run from the directory where it was installed, with the documents served from the subdirectory htdocs. There are lots of other options which should be set before you start really using Apache. However to get started quickly the files should work as installed.

If you eventually uninstall Apache, your configuration files will not be removed. You will need to delete the installation directory tree ("C:\Program Files\Apache Group" by default) yourself if you do not care to keep your configuration and other web files. Since the httpd.conf file is a your accumulated effort in using Apache, you need to take the effort to remove it. The same happens for all other files you may have created, as well as any log files Apache created.

Running Apache for Windows

There are two ways you can run Apache:

  • As a "service" (tested on NT/2000 only, but an experimental version is available for 95/98). This is the best option if you want Apache to automatically start when your machine boots, and to keep Apache running when you log-off.
  • From a console window. This is the best option available for Windows 95/98 users.

Complete the steps below before you attempt to start Apache as a Windows "service"!

To run Apache from a console window, select the "Start Apache as console app" option from the Start menu (in Apache 1.3.4 and earlier, this option was called "Apache Server"). This will open a console window and start Apache running inside it. The window will remain active until you stop Apache. To stop Apache running, either press select the "Shutdown Apache console app" icon option from the Start menu (this is not available in Apache 1.3.4 or earlier), or see Controlling Apache in a Console Window for commands to control Apache in a console window.

In Apache 1.3.13 and above it is now quite safe to press Ctrl+C or Ctrl+Break to stop the Apache in the console window. And on Windows NT/2000 with version 1.3.13, Apache will also gladly stop if you select ‘Close’ from the system menu (clicking the icon on the top-left corner of the console window) or click the close (X) button on the top-right corner. The Close menu item and close (X) button also work on Windows 95/98 as of Apache version 1.3.15. But do not try any of these approaches on earlier versions of the Apache server, since Apache would not clean up.

Testing Apache for Windows

If you have trouble starting Apache please use the following steps to isolate the problem. This applies if you started Apache using the "Start Apache as a console app" shortcut from the Start menu and the Apache console window closes immediately (or unexpectedly) or if you have trouble starting Apache as a service.

Run the "Command Prompt" from the Start Menu – Programs list. Change to the folder to which you installed Apache, type the command apache, and read the error message. Then review the error.log file for configuration mistakes. If you accepted the defaults when you installed Apache, the commands would be:

  c:
  cd "\program files\apache group\apache"
  apache
  Wait for Apache to exit, or press Ctrl+C
  more <logs\error.log

After looking at the error.log you will probably have a good chance of working out what went wrong and be able to fix the problem and try again. Many users discover that the nature of the httpd.conf file is easier to manage and audit than page after page of configuration dialog boxes.

After starting Apache running (either in a console window or as a service) if will be listening to port 80 (unless you changed the Port, Listen or BindAddress directives in the configuration files). To connect to the server and access the default page, launch a browser and enter this URL:

  http://localhost/

This should respond with a welcome page, and a link to the Apache manual. If nothing happens or you get an error, look in the error.log file in the logs directory. If your host isn’t connected to the net, you may have to use this URL:

  http://127.0.0.1/

Once your basic installation is working, you should configure it properly by editing the files in the conf directory.

Because Apache CANNOT share the same port with another TCP/IP application, you may need to stop or uninstall certain services first. These include (but are not limited to) other web servers, and firewall products such as BlackIce. If you can only start Apache with these services disabled, reconfigure either Apache or the other product so that they do not listen on the same TCP/IP ports. You may find the Windows "netstat -an" command useful in finding out what ports are in use.

Configuring Apache for Windows

Apache is configured by files in the conf directory. These are the same as files used to configure the Unix version, but there are a few different directives for Apache on Windows.

Begin configuring the Apache server by reviewing httpd.conf and its directives. Although the files access.conf and srm.conf both exist, these are old files which are no longer used by most administrators, and you will find no directives there.

httpd.conf contains a great deal of documentation itself, followed by the default configuration directives recommended when starting with the Apache server. Begin by reading these comments to understand the configuration file, and make small changes, starting Apache in a console window with each change. If you make a mistake, it will be easier to back up to configuration that last worked. You will have a better idea of which change caused the server to fail.

The main differences in Apache for Windows are:

  • Because Apache for Windows is multithreaded, it does not use a separate process for each request, as Apache does with Unix. Instead there are usually only two Apache processes running: a parent process, and a child which handles the requests. Within the child each request is handled by a separate thread. So, "process"-management directives are different:
    • MaxRequestsPerChild – Like the Unix directive, this controls how many requests a process will serve before exiting. However, unlike Unix, a process serves all the requests at once, not just one, so if this is set, it is recommended that a very high number is used. The recommended default, MaxRequestsPerChild 0, does not cause the process to ever exit.
    • ThreadsPerChild – This directive is new, and tells the server how many threads it should use. This is the maximum number of connections the server can handle at once; be sure and set this number high enough for your site if you get a lot of hits. The recommended default is ThreadsPerChild 50.
  • The directives that accept filenames as arguments now must use Windows filenames instead of Unix ones. However, because Apache uses Unix-style names internally, you must use forward slashes, not backslashes. Drive letters can be used; if omitted, the drive with the Apache executable will be assumed.
  • Apache for Windows has the ability to load modules at runtime, without recompiling the server. If Apache is compiled normally, it will install a number of optional modules in the \modules directory. To activate these, or other modules, the new LoadModule directive must be used. For example, to active the status module, use the following (in addition to the status-activating directives in access.conf): 
        LoadModule status_module modules/mod_status.so

    Information on creating loadable modules is also available. Note that some 3rd party modules may be distributed in the old style names, ApacheModuleFoo.dll. Always set the LoadModule command as directed as documented by the 3rd party module’s own documentation.

  • Apache for Windows version 1.3 series is implemented in synchronous calls. This poses an enormous problem for CGI authors, who won’t see unbuffered results sent immediately to the browser. This is not the behavior described for CGI in Apache, but it is a side-effect of the Windows port. Apache 2.0 is making progress to implement the expected asynchronous behavior, and we hope to discover that the NT/2000 implementation allows CGI’s to behave as documented.

  • Apache can also load ISAPI Extensions (i.e., Internet Server Applications), such as those used by Microsoft’s IIS, and other Windows servers. More information is available. Note that Apache CANNOT load ISAPI Filters.

Running Apache in a Console Window

The Start menu icons and the NT Service manager can provide a simple interface for administering Apache. But in some cases it is easier to work from the command line.

When working with Apache it is important to know how it will find the configuration files. You can specify a configuration file on the command line in two ways:

  • -f specifies a path to a particular configuration file: 
    apache -f "c:\my server\conf\my.conf"
    apache -f test\test.conf
  • -n specifies the configuration file of an installed Apache service (Apache 1.3.7 and later): 
    apache -n "service name"

In these cases, the proper ServerRoot should be set in the configuration file.

If you don’t specify a configuration file name with -f or -n, Apache will use the file name compiled into the server, usually "conf/httpd.conf". Invoking Apache with the -V switch will display this value labeled as SERVER_CONFIG_FILE. Apache will then determine its ServerRoot by trying the following, in this order:

  • A ServerRoot directive via a -C switch.
  • The -d switch on the command line.
  • The current working directory
  • A registry entry, created if you did a binary install.
  • The server root compiled into the server.

The server root compiled into the server is usually "/apache". invoking apache with the -V switch will display this value labeled as HTTPD_ROOT.

When invoked from the start menu, Apache is usually passed no arguments, so using the registry entry is the preferred technique for console Apache.

During a binary installation, a registry key will have been installed, for example:

  HKEY_LOCAL_MACHINE\Software\Apache Group\Apache\1.3.13\ServerRoot

This key is compiled into the server and can enable you to test new versions without affecting the current version. Of course you must take care not to install the new version on top of the old version in the file system.

If you did not do a binary install then Apache will in some scenarios complain about the missing registry key. This warning can be ignored if it otherwise was able to find its configuration files.

The value of this key is the "ServerRoot" directory, containing the conf directory. When Apache starts it will read the httpd.conf file from this directory. If this file contains a ServerRoot directive which is different from the directory obtained from the registry key above, Apache will forget the registry key and use the directory from the configuration file. If you copy the Apache directory or configuration files to a new location it is vital that you update the ServerRoot directory in the httpd.conf file to the new location.

To run Apache from the command line as a console application, use the following command:

    apache

Apache will execute, and will remain running until it is stopped by pressing control-C.

Controlling Apache in a Console Window

You can tell a running Apache to stop by opening another console window and running:

    apache -k shutdown

Note: This option is only available with Apache 1.3.3 and later.

For earlier versions, you must use Control-C in the Apache console window to shut down the server.

From version 1.3.3 through 1.3.12, this should be used instead of pressing Control-C in a running Apache console window, because it allowed Apache to end any current transactions and cleanup gracefully.

As of version 1.3.13 pressing Control-C in the running window will cleanup Apache quite gracefully, and you may use -k stop as an alias for -k shutdown. Earlier versions do not understand -k stop.

You can also tell Apache to restart. This makes it re-read the configuration files. Any transactions in progress are allowed to complete without interruption. To restart Apache, run:

    apache -k restart

Note: This option is only available with Apache 1.3.3 and later. For earlier versions, you need to use Control-C in the Apache console window to shut down the server, and then restart the server with the Apache command.

Another very useful feature is the configuration files test option. To test the Apache configuration files, run:

    apache -t

This is especially useful following alterations to the configuration files while Apache is still running. You can make the changes, confirm that the syntax is good by issuing the "apache -t" command, then restart Apache with "apache -k restart". Apache will re-read the configuration files, allowing any transactions in progress to complete without interruption. Any new request will then be served using the new configuration.

Note: for people familiar with the Unix version of Apache, these commands provide a Windows equivalent to kill -TERM pid and kill -USR1 pid. The command line option used, -k, was chosen as a reminder of the "kill" command used on Unix.

Tagged with: • •
Jun 25

Security Tips for Apache Server Configuration

By jason Apache Server No Comments »

Some hints and tips on security issues in setting up a web server. Some of the suggestions will be general, others specific to Apache.

Permissions on ServerRoot Directories

In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits. As is the case with any command that root executes, you must take care that it is protected from modification by non-root users. Not only must the files themselves be writeable only by root, but so must the directories, and parents of all directories. For example, if you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these: 

    mkdir /usr/local/apache
    cd /usr/local/apache
    mkdir bin conf logs
    chown 0 . bin conf logs
    chgrp 0 . bin conf logs
    chmod 755 . bin conf logs

It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected: 

    cp httpd /usr/local/apache/bin
    chown 0 /usr/local/apache/bin/httpd
    chgrp 0 /usr/local/apache/bin/httpd
    chmod 511 /usr/local/apache/bin/httpd

You can create an htdocs subdirectory which is modifiable by other users — since root never executes any files out of there, and shouldn’t be creating files in there.

If you allow non-root users to modify any files that root either executes or writes on then you open your system to root compromises. For example, someone could replace the httpd binary so that the next time you start it, it will execute some arbitrary code. If the logs directory is writeable (by a non-root user), someone could replace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a non-root user), then someone may be able to overwrite the log itself with bogus data.

Server Side Includes

Server side includes (SSI) can be configured so that users can execute arbitrary programs on the server. That thought alone should send a shiver down the spine of any sys-admin.

One solution is to disable that part of SSI. To do that you use the IncludesNOEXEC option to the Options directive.

Non Script Aliased CGI

Allowing users to execute CGI scripts in any directory should only be considered if;

  1. You trust your users not to write scripts which will deliberately or accidentally expose your system to an attack.
  2. You consider security at your site to be so feeble in other areas, as to make one more potential hole irrelevant.
  3. You have no users, and nobody ever visits your server.

Script Alias’ed CGI

Limiting CGI to special directories gives the admin control over what goes into those directories. This is inevitably more secure than non script aliased CGI, but only if users with write access to the directories are trusted or the admin is willing to test each new CGI script/program for potential security holes.

Most sites choose this option over the non script aliased CGI approach.

CGI in general

Always remember that you must trust the writers of the CGI script/programs or your ability to spot potential security holes in CGI, whether they were deliberate or accidental.

All the CGI scripts will run as the same user, so they have potential to conflict (accidentally or deliberately) with other scripts e.g. User A hates User B, so he writes a script to trash User B’s CGI database. One program which can be used to allow scripts to run as different users is suEXEC which is included with Apache as of 1.2 and is called from special hooks in the Apache server code. Another popular way of doing this is with CGIWrap.

Stopping users overriding system wide settings…

To run a really tight ship, you’ll want to stop users from setting up .htaccess files which can override security features you’ve configured. Here’s one way to do it…

In the server configuration file, put

<Directory />

AllowOverride None

Options None

Allow from all

</Directory>

Then setup for specific directories

This stops all overrides, Includes and accesses in all directories apart from those named.

Protect server files by default

One aspect of Apache which is occasionally misunderstood is the feature of default access. That is, unless you take steps to change it, if the server can find its way to a file through normal URL mapping rules, it can serve it to clients.

For instance, consider the following example:

  1. # cd /; ln -s / public_html
  2. Accessing http://localhost/~root/

This would allow clients to walk through the entire filesystem. To work around this, add the following block to your server’s configuration: 

 <Directory />
     Order Deny,Allow
     Deny from all
 </Directory>

This will forbid default access to filesystem locations. Add appropriate <Directory> blocks to allow access only in those areas you wish. For example, 

 <Directory /usr/users/*/public_html>
     Order Deny,Allow
     Allow from all
 </Directory>
 <Directory /usr/local/httpd>
     Order Deny,Allow
     Allow from all
 </Directory>

Pay particular attention to the interactions of <Location> and <Directory> directives; for instance, even if <Directory /> denies access, a <Location /> directive might overturn it.

Also be wary of playing games with the UserDir directive; setting it to something like "./" would have the same effect, for root, as the first example above. If you are using Apache 1.3 or above, we strongly recommend that you include the following line in your server configuration files:

UserDir disabled root
Tagged with: • •
Jun 05

How to load balance with apache

By jason Apache Server No Comments »

deployment overview

web server
site1.yourdomain.com
192.168.1.35

web server
siste2.yourdomain.com
192.168.1.36

data server
db1.yourdomain.com
192.168.1.37

load balancer
balance-1.yourdomain.com
192.168.1.45

install and enable apache and proxy_balancer

1.create a dedicated server for load balancing. install apache2 and then install mod proxy_balancer and proxy_http with dependencies.

2.enable mod_proxy in httpd.conf. note that i’m leaving ProxyRequests off since we’re only using the ProxyPass and ProxyPassReverse directives. this keeps the server secure from spammers trying to use your proxy to send email.

<IfModule mod_proxy.c>
        ProxyRequests Off

        <Proxy *>
                AddDefaultCharset off
                Order deny,allow
                Allow from all
                #Allow from .example.com
        </Proxy>

        ProxyVia On
</IfModule>

configure mod_proxy and mod_proxy_balancer

mod_proxy and mod_proxy balancer serve as a very functional load balancer. however mod_proxy_balancer makes slightly unfortunate assumptions about the format of the cookie that you’ll use for sticky session handling. one way to work around this is to create your own session cookie (very easy with apache). the examples below describe how to do this

first create a virtual host or use the default  and add this configuration to it:

<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from 192.168
</Location>
<Proxy balancer://mycluster>
  # cluster member 1
  BalancerMember http://site1.yourdomain.com:80 route=lb1
  # cluster member 2
  BalancerMember http://site2.yourdomain.com:80 route=lb2
</Proxy>
ProxyPass /balancer-manager !
ProxyPass / balancer://mycluster/ lbmethod=byrequests stickysession=BALANCEID
ProxyPassReverse / http://site1.yourdomain.com/
ProxyPassReverse / http://site2.yourdomain.com/

Note:

  • i’m allowing access to the balancer manager from any IP matching 192.168.*.*
  • i’m load balancing between 2 servers (site1.yourdomain.com, site2.yourdomain.com) on port 80
  • i’m defining two routes for these servers called lb1 and lb2
  • i’m excluding (!) the balancer-manager directory fro the ProxyPass to allow access to the manager ui on the load balancing server
  • i’m expecting a cookie called BALANCEID to be available to manage sticky sessions

  • this is a simplistic load balancing configuration. apache has many options to control timeouts, server loading, failover etc. too much to cover but read more in the apache documentation

    configure the web servers to write a session cookie

    on each of the web servers, add this code to your vhost configuration:

    RewriteEngine On
    RewriteRule .* - [CO=BALANCEID:balancer.lb1:.yourdomain.com]

    making sure to specify the correct route e.g. lb1 on site1.yourdomain.com etc.

    you also probably want to setup your cookie domain properly in drupal, i.e. modify drupal/sites/default/settings.php as follows:

    # $cookie_domain = 'example.com';
    $cookie_domain = 'yourdomain.com';

    important urls

    useful urls for testing are:

    References:

  • apache’s mod_proxy_balancer documentation
  • apache’s mod_proxy documentation

     

    About Load Banlance topic you can read my old post:

    • Tagged with: • • •
    May 28

    apache configuration skills

    By jason Apache Server 2 Comments »

    Changing protocol behavior with misbehaving clients
    Earlier versions recommended that the following lines be included in httpd.conf to deal with known client problems. Since the affected clients are no longer seen in the wild, this configuration is likely no-longer necessary.

    #
    # The following directives modify normal HTTP response behavior.
    # The first directive disables keepalive for Netscape 2.x and browsers that
    # spoof it. There are known problems with these browser implementations.
    # The second directive is for Microsoft Internet Explorer 4.0b2
    # which has a broken HTTP/1.1 implementation and does not properly
    # support keepalive when it is used on 301 or 302 (redirect) responses.
    #
    BrowserMatch “Mozilla/2″ nokeepalive
    BrowserMatch “MSIE 4\.0b2;” nokeepalive downgrade-1.0 force-response-1.0

    #
    # The following directive disables HTTP/1.1 responses to browsers which
    # are in violation of the HTTP/1.0 spec by not being able to grok a
    # basic 1.1 response.
    #
    BrowserMatch “RealPlayer 4\.0″ force-response-1.0
    BrowserMatch “Java/1\.0″ force-response-1.0
    BrowserMatch “JDK/1\.0″ force-response-1.0

    Prevent “Image Theft”
    This example shows how to keep people not on your server from using images on your server as inline-images on their pages. This is not a recommended configuration, but it can work in limited circumstances. We assume that all your images are in a directory called /web/images.

    SetEnvIf Referer “^http://www\.example\.com/” local_referal # Allow browsers that do not send Referer info SetEnvIf Referer “^$” local_referal <Directory /web/images>
    Order Deny,Allow
    Deny from all
    Allow from env=local_referal
    </Directory>

    Do not log requests for images in the access log

    This example keeps requests for images from appearing in the access log. It can be easily modified to prevent logging of particular directories, or to prevent logging of requests coming from particular hosts.

    SetEnvIf Request_URI \.gif image-request
    SetEnvIf Request_URI \.jpg image-request
    SetEnvIf Request_URI \.png image-request
    CustomLog logs/access_log common env=!image-request

    Changing protocol behavior with misbehaving clients

    Earlier versions recommended that the following lines be included in httpd.conf to deal with known client problems. Since the affected clients are no longer seen in the wild, this configuration is likely no-longer necessary.

    #
# The following directives modify normal HTTP response behavior.
# The first directive disables keepalive for Netscape 2.x and browsers that
# spoof it. There are known problems with these browser implementations.
# The second directive is for Microsoft Internet Explorer 4.0b2
# which has a broken HTTP/1.1 implementation and does not properly
# support keepalive when it is used on 301 or 302 (redirect) responses.
#
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0

#
# The following directive disables HTTP/1.1 responses to browsers which
# are in violation of the HTTP/1.0 spec by not being able to grok a
# basic 1.1 response.
#
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0

    Tagged with: • •
    Dec 28

    Split Apache Log With Cronolog

    By jason Apache Server No Comments »

    About Cronolog

    cronolog is a simple filter program that reads log file entries from standard input and writes each entry to the output file specified by a filename template and the current date and time. When the expanded filename changes, the current file is closed and a new one opened. cronolog is intended to be used in conjunction with a Web server, such as Apache, to split the access log into daily or monthly logs


    Install cronolog in the Linux

    #wget http://cronolog.org/download/cronolog-1.6.2.tar.gz
    #tar zxvf cronolog-1.6.2.tar.gz
    #cd cronolog-1.6.2
    #./configure
    #make
    #make install

    cronolog options

    Long form

    Short form

    Meaning

    –hardlink=NAME

    -H NAME

    maintain a hard link from NAME to the current log file

    –symlink=NAME

    -S NAME

    maintain a symbolic link from NAME to the current log file

    –prev-symlink=NAME

    -P NAME

    maintain a symbolic link from NAME to previous log

    –link=NAME

    -l NAME

    same as -S/–symlink

    –help

    -h

    print a help message then exit

    –period=PERIOD

    -p PERIOD

    set the rotation period explicitly (new in 1.6.2)

    –delay=DELAY

    set the rotation period delay (new in 1.6.2 — this will be renamed –rotation-offset with a short form of -o in 1.6.3)

    –once-only

    create single output log from template (not rotated)

    –debug=FILE

    -x FILE

    write debug messages to FILE ( or to standard error if FILE is "-")

    –american

    -a

    Interprete ambiguous start dates in American date formats (mm/dd/yy[yy])

    –european

    -e

    Interprete ambiguous start dates in European date formats (dd/mm/yy[yy] – default)

    –start-time=DT

    -s DT

    starting date and time (in ambiguous cases interpreted according to –american or –european specification)

    –time-zone=TZ

    -z TZ

    use TZ for timezone

    –version

    -V

    print version number, then exit

    Template specifiers

    Specifier

    Description

    %%

    a literal % character

    %n

    a new-line character

    %t

    a horizontal tab character

    Time fields

    %H

    hour (00..23)

    %I

    hour (01..12)

    %p

    the locale’s AM or PM indicator

    %M

    minute (00..59)

    %S

    second (00..61, which allows for leap seconds)

    %X

    the locale’s time representation (e.g.: "15:12:47")

    %Z

    time zone (e.g. GMT), or nothing if the time zone cannot be determined

    Date fields

    %a

    the locale’s abbreviated weekday name (e.g.: Sun..Sat)

    %A

    the locale’s full weekday name (e.g.: Sunday .. Saturday)

    %b

    the locale’s abbreviated month name (e.g.: Jan .. Dec)

    %B

    the locale’s full month name, (e.g.: January .. December)

    %c

    the locale’s date and time (e.g.: "Sun Dec 15 14:12:47 GMT 1996")

    %d

    day of month (01 .. 31)

    %j

    day of year (001 .. 366)

    %m

    month (01 .. 12)

    %U

    week of the year with Sunday as first day of week (00..53, where week 1 is the week containing the first Sunday of the year)

    %W

    week of the year with Monday as first day of week (00..53, where week 1 is the week containing the first Monday of the year)

    %w

    day of week (0 .. 6, where 0 corresponds to Sunday)

    %x

    locale’s date representation (e.g. today in Britain: "15/12/96")

    %y

    year without the century (00 .. 99)

    %Y

    year with the century (1970 .. 2038)


    Cronolog usage:

    Edit your httpd.conf file

    CustomLog "|/path/to/cronolog [OPTIONS] logfile-spec" [format]

    CustomLog "|/usr/sbin/cronolog /web/logs/%Y/%m/%d/access.log" combined
    ErrorLog "|/usr/sbin/cronolog /web/logs/%Y/%m/%d/errors.log"

    Security issues with cronolog

    As far as I am aware noone has done a formal security audit of cronolog. However I have checked the code for potential buffer overflows and such like, and have not found anything untoward. Users should however be aware that cronolog is normally invoked from the web server and passed a filename template from which it constructs the names of the log files that are written. On Unix-like systems piped log programs are started by the initial server process, which runs as root; thus cronolog will usually run as root. If an attacker can write to the web server configuration file then he or she could cause cronolog to write to critical files. Mind you if an attacker does manage to change the web server configuration file then all sorts of nefarious actions are open to them.

    Tagged with: • •
    Dec 28

    Apache Performance Tuning

    By jason Apache Server 1 Comment »

    Forewarning:

    …in other words, don’t implement in extra complexity if you don’t need it. A site handling a few thousand requests per day will do fine on a default configuration and just about any hardware. This article is geared towards a site that needs to handle multiple concurrent requests [ten to several hundred per second].

    General [in order of importance]

    RAM

    The single biggest issue affecting webserver performance is RAM. Have as much RAM as your hardware, OS, and funds allow [within reason].

    The more RAM your system has, the more processes [and threads] Apache can allocate and use; which directly translates into the amount of concurrent requests/clients Apache can serve.

    Generally speaking, disk I/O is usually a close 2nd, followed by CPU speed and network link. Note that a single PII 400 Mhz with 128-256 Megs of RAM can saturate a T3 (45 Mbps) line.

    Select MPM

    Chose the right MPM for the right job:

    prefork [default MPM for Apache 2.0 and 1.3]:
    • Apache 1.3-based.
    • Multiple processes, 1 thread per process, processes handle requests.
    • Used for security and stability.
    • Has higher memory consumption and lower performance over the newer Apache 2.0-based threaded MPMs.
    worker:
    • Apache 2.0-based.
    • Multiple processes, many threads per process, threads handle requests.
    • Used for lower memory consumption and higher performance.
    • Does not provide the same level of isolation request-to-request, as a process-based MPM does.
    winnt:
    • The only MPM choice under Windows.
    • 1 parent process, exactly 1 child process with many threads, threads handle requests.
    • Best solution under Windows, as on this platform, threads are always “cheaper” to use over processes.

    Configure MPM

    Core Features and Multi-Processing Modules

    Default Configuration
    <IfModule prefork.c>
  StartServers            8
  MinSpareServers         5
  MaxSpareServers        20
  MaxClients            150
  MaxRequestsPerChild  1000
</IfModule>

<IfModule worker.c>
  StartServers            2
  MaxClients            150
  MinSpareThreads        25
  MaxSpareThreads        75
  ThreadsPerChild        25
  MaxRequestsPerChild     0
</IfModule>

<IfModule mpm_winnt.c>
  ThreadsPerChild       250
  MaxRequestsPerChild     0
</IfModule>
    Directives
    MaxClients, for prefork MPM

    MaxClients sets a limit on the number of simultaneous connections/requests that will be served.

    I consider this directive to be the critical factor to a well functioning server. Set this number too low and resources will go to waist. Set this number too high and an influx of connections will bring the server to a stand still. Set this number just right and your server will fully utilize the available resources.

    An approximation of this number should be derived by dividing the amount of system memory (physical RAM) available by the maximum size of an apache/httpd process; with a generous amount spared for all other processes.

    MaxClients ¡Ö (RAM – size_all_other_processes)/(size_apache_process)Use ‘ps -ylC httpd –sort:rss’ to find process size. Divide number by 1024 to get megabytes. Also try ‘top’.

    Use ‘free -m’ for a general overview. The key figure to look at is the buffers/cache used value.

    Use ‘vmstat 2 5′ to display the number of runnable, blocked, and waiting processes; and swap in and swap out.

    Example:

    • System: VPS (Virtual Private Server), CentOS 4.4, with 128MB RAM
    • Apache: v2.0, mpm_prefork, mod_php, mod_rewrite, mod_ssl, and other modules
    • Other Services: MySQL, Bind, SendMail
    • Reported System Memory: 120MB
    • Reported httpd process size: 7-13MB
    • Assumed memory available to Apache: 90MB

    Optimal settings:

    • StartServers 5
    • MinSpareServers 5
    • MaxSpareServers 10
    • ServerLimit 15
    • MaxClients 15
    • MaxRequestsPerChild 2000

    With the above configuration, we start with 5-10 processes and set a top limit of 15. Anything above this number will cause serious swapping and thrashing under a load; due to the low amount of RAM available to the [virtual] Server. With a dedicated Server, the default values [ServerLimit 256] will work with 1-2GB of RAM.

    When calculating MaxClients, take into consideration that the reported size of a process and the effective size are two different values. In this setup, it might be safe to use 20 or more workers… Play with different values and check your system stats.

    Note that when more connections are attempted than there are workers, the connections are placed into a queue. The default queue size value is 511 and can be adjusted with the ListenBackLog directive.

    ThreadsPerChild, for winnt MPM

    On the Windows side, the only useful directive is ThreadsPerChild, which is usually set to a value of 250 [defaults to 64 without a value]. If you expect more, or less, concurrent connections/requests, set this directive appropriately. Check process size with Task Manager, under different values and server load.

    MaxRequestsPerChild

    Directive MaxRequestsPerChild is used to recycle processes. When this directive is set to 0, an unlimited amount of requests are allowed per process.

    While some might argue that this increases server performance by not burdening Apache with having to destroy and create new processes, there is the other side to the argument…

    Setting this value to the amount of requests that a website generates per day, divided by the number of processes, will have the benefit of keeping memory leaks and process bloat to a minimum [both of which are a common problem]. The goal here is to recycle each process once per day, as apache threads gradually increase their memory allocation as they run.

    Note that under the winnt MPM model, recycling the only request serving process that Apache contains, can present a problem for some sites with constant and heavy traffic.

    Requests vs. Client Connections

    On any given connection, to load a page, a client may request many URLs: page, site css files, javascript files, image files, etc.

    Multiple requests from one client in rapid succession can have the same effect on a Server as “concurrent” connections [threaded MPMs and directive KeepAlive taken into consideration]. If a particular website requires 10 requests per page, 10 concurrent clients will require MPM settings that are geared more towards 20-70 clients. This issue manifests itself most under a process-based MPM [prefork].

    Separate Static and Dynamic Content

    Use separate servers for static and dynamic content. Apache processes serving dynamic content will carry overhead and swell to the size of the content being served, never decreasing in size. Each process will incur the size of any loaded PHP or Perl libraries. A 6MB-30MB process size [or 10% of server's memory] is not unusual, and becomes a waist of resources for serving static content.

    For a more efficient use of system memory, either use mod_proxy to pass specific requests onto another Apache Server, or use a lightweight server to handle static requests:

    • lighttpd [has experimental win32 builds]
    • tux [patched into RedHat, runs inside the Linux kernel and is at the top of the charts in performance]

    The Server handling the static content goes up front.

    Note that configuration settings will be quite different between a dynamic content Server and a static content Server.

    mod_deflate

    Reduce bandwidth by 75% and improve response time by using mod_deflate.

    LoadModule deflate_module modules/mod_deflate.so
    <Location />
    AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml application/x-javascript
    </Location>

    Loaded Modules

    Reduce memory footprint by loading only the required modules.

    Some also advise to statically compile in the needed modules, over building DSOs (Dynamic Shared Objects). Very bad advice. You will need to manually rebuild Apache every time a new version or security advisory for a module is put out, creating more work, more build related headaches, and more downtime.

    mod_expires

    Include mod_expires for the ability to set expiration dates for specific content; utilizing the ‘If-Modified-Since’ header cache control sent by the user’s browser/proxy. Will save bandwidth and drastically speed up your site for [repeat] visitors.

    Note that this can also be implemented with mod_headers.

    KeepAlive

    Enable HTTP persistent connections to improve latency times and reduce server load significantly [25% of original load is not uncommon].

    prefork MPM:

    KeepAlive On
    KeepAliveTimeout 2
    MaxKeepAliveRequests 80

    worker and winnt MPMs:

    KeepAlive On
    KeepAliveTimeout 15
    MaxKeepAliveRequests 80

    With the prefork MPM, it is recommended to set ‘KeepAlive’ to ‘Off’. Otherwise, a client will tie up an entire process for that span of time. Though in my experience, it is more useful to simply set the ‘KeepAliveTimeout’ value to something very low [2 seconds seems to be the ideal value]. This is not a problem with the worker MPM [thread-based], or under Windows [which only has the thread-based winnt MPM].

    With the worker and winnt MPMs, the default 15 second timeout is setup to keep the connection open for the next page request; to better handle a client going from link to link. Check logs to see how long a client remains on each page before moving on to another link. Set value appropriately [do not set higher than 60 seconds].

    SymLinks

    Make sure ‘Options +FollowSymLinks -SymLinksIfOwnerMatch’ is set for all directories. Otherwise, Apache will issue an extra system call per filename component to substantiate that the filename is NOT a symlink; and more system calls to match an owner.

    <Directory />
    Options FollowSymLinks
    </Directory>

    AllowOverride

    Set a default ‘AllowOverride None’ for your filesystem. Otherwise, for a given URL to path translation, Apache will attempt to detect an .htaccess file under every directory level of the given path.

    <Directory />
    AllowOverride None
    </Directory>

    ExtendedStatus

    If mod_status is included, make sure that directive ‘ExtendedStatus’ is set to ‘Off’. Otherwise, Apache will issue several extra time-related system calls on every request made.

    ExtendedStatus Off

    Timeout

    Lower the amount of time the server will wait before failing a request.

    Timeout 45

    Other/Specific

    Cache all PHP pages, using Squid, and/or a PHP Accelerator and Encoder application, such as APC. Also take a look at mod_cache under Apache 2.2.

    Convert/pre-render all PHP pages that do not change request-to-request, to static HTML pages. Use ‘wget’ or ‘HTTrack’ to crawl your site and perform this task automatically.

    Pre-compress content and pre-generate headers for static pages; send-as-is using mod_asis. Can use ‘wget’ or ‘HTTrack’ for this task. Make sure to set zlib Compression Level to a high value (6-9). This will take a considerable amount of load off the server.

    Use output buffering under PHP to generate output and serve requests without pauses.

    Avoid content negotiation for faster response times.

    Make sure log files are being rotated. Apache will not handle large (2gb+) files very well.

    Gain a significant performance improvement by using SSL session cache.

    Outsource your images to Amazon’s Simple Storage Service (S3).

    Measuring Web Server Performance

    Load Testing

    Apache HTTP server benchmarking tool
    httperf
    The Grinder, a Java Load Testing Framework

    Benchmarks

    I have searched extensively for Apache, lighttpd, tux, and other webserver benchmarks. Sadly, just about every single benchmark I could locate appeared to have been performed completely without thought, or with great bias.

    Do not trust any posted benchmarks, especially ones done with the ‘ab’ tool.

    The only way to get a valid report is to perform the benchmark yourself.

    For valid results, note to test under a system with limited resources, and maximum resources. But most importantly, configure each httpd server application for the specific situation.

    Tagged with: •
    Dec 27

    Secure Your Apache Server Configuration

    By jason Apache Server 1 Comment »

    First, make sure you’ve installed latest security patches

    There is no sense in putting locks on the windows, if your door is wide open. As such, if you’re not patched up there isn’t really much point in continuing any longer on this list. Go ahead and bookmark this page so you can come back later, and patch your server.

    Hide the Apache Version number, and other sensitive information.

    By default many Apache installations tell the world what version of Apache you’re running, what operating system/version you’re running, and even what Apache Modules are installed on the server. Attackers can use this information to their advantage when performing an attack. It also sends the message that you have left most defaults alone.

    Edit in your httpd.conf file and add two directives:

    ServerSignature Off
ServerTokens Prod

    The ServerSignature appears on the bottom of pages generated by apache such as 404 pages, directory listings, etc.

    The ServerTokens directive is used to determine what Apache will put in the Server HTTP response header. By setting it to Prod it sets the HTTP response header as follows:

    Server: Apache

    If you’re super paranoid you could change this to something other than "Apache" by editing the source code, or by using mod_security (see below).

    Make sure apache is running under its own user account and group

    Several apache installations have it run as the user nobody. So suppose both Apache, and your mail server were running as nobody an attack through Apache may allow the mail server to also be compromised, and vise versa.

    User apache
Group apache

    Ensure that files outside the web root are not served

    We don’t want apache to be able to access any files out side of its web root. So assuming all your web sites are placed under one directory (we will call this /web), you would set it up as follows:

    <Directory />
  Order Deny,Allow
  Deny from all
  Options None
  AllowOverride None
</Directory>
<Directory /web>
  Order Allow,Deny
  Allow from all
</Directory>

    Turn off directory browsing

    You can do this with an Options directive inside a Directory tag. Set Options to either None or -Indexes

    Options -Indexes

    Turn off server side includes

    This is also done with the Options directive inside a Directory tag. Set Options to either None or -Includes

    Options -Includes

    Turn off CGI execution

    If you’re not using CGI turn it off with the Options directive inside a Directory tag. Set Options to either None or -ExecCGI

    Options -ExecCGI

    Don’t allow apache to follow symbolic links

    This can again can be done using the Options directive inside a Directory tag. Set Options

    to either None or -FollowSymLinks

    Options -FollowSymLinks

    Turning off multiple Options

    If you want to turn off all Options simply use:

    Options None


    If you only want to turn off some separate each option with a space in your Options directive:

    Options -ExecCGI -FollowSymLinks -Indexes

    Turn off support for .htaccess files

    This is done in a Directory tag but with the AllowOverride directive. Set it to None.

    AllowOverride None


    If you require Overrides ensure that they cannot be downloaded, and/or change the name to something other than .htaccess. For example we could change it to .httpdoverride, and block all files that start with .ht from being downloaded as follows:

    AccessFileName .httpdoverride
<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
    Satisfy All
</Files>

    Run mod_security

    mod_security is a super handy Apache module written by Ivan Ristic, the author of Apache Security from O’Reilly press.

    You can do the following with mod_security:

    • Simple filtering
    • Regular Expression based filtering
    • URL Encoding Validation
    • Unicode Encoding Validation
    • Auditing
    • Null byte attack prevention
    • Upload memory limits
    • Server identity masking
    • Built in Chroot support
    • And more

    Disable any unnecessary modules

    Apache typically comes with several modules installed. Go through the apache module documentation and learn what each module you have enabled actually does. Many times you will find that you don’t need to have the said module enabled.

    Look for lines in your httpd.conf that contain LoadModule. To disable the module you can typically just add a # at the beginning of the line. To search for modules run:

    grep LoadModule httpd.conf

    Here are some modules that are typically enabled but often not needed: mod_imap, mod_include, mod_info, mod_userdir, mod_status, mod_cgi, mod_autoindex.

    Make sure only root has read access to apache’s config and binaries

    This can be done assuming your apache installation is located at /usr/local/apache as follows:

    chown -R root:root /usr/local/apache
chmod -R o-rwx /usr/local/apache

    Lower the Timeout value

    By default the Timeout directive is set to 300 seconds. You can decrease help mitigate the potential effects of a denial of service attack.

    Timeout 45

    Limiting large requests

    Apache has several directives that allow you to limit the size of a request, this can also be useful for mitigating the effects of a denial of service attack.

    A good place to start is the LimitRequestBody directive. This directive is set to unlimited by default. If you are allowing file uploads of no larger than 1MB, you could set this setting to something like:

    LimitRequestBody 1048576

    If you’re not allowing file uploads you can set it even smaller.

    Some other directives to look at are LimitRequestFields, LimitRequestFieldSize and LimitRequestLine. These directives are set to a reasonable defaults for most servers, but you may want to tweak them to best fit your needs. See the documentation for more info.

    Limiting the size of an XML Body

    If you’re running mod_dav (typically used with subversion) then you may want to limit the max size of an XML request body. The LimitXMLRequestBody directive is only available on Apache 2, and its default value is 1 million bytes (approx 1mb). Many tutorials will have you set this value to 0 which means files of any size may be uploaded, which may be necessary if you’re using WebDAV to upload large files, but if you’re simply using it for source control, you can probably get away with setting an upper bound, such as 10mb:

    LimitXMLRequestBody 10485760

    Limiting Concurrency

    Apache has several configuration settings that can be used to adjust handling of concurrent requests. The MaxClients is the maximum number of child processes that will be created to serve requests. This may be set too high if your server doesn’t have enough memory to handle a large number of concurrent requests.

    Other directives such as MaxSpareServers, MaxRequestsPerChild, and on Apache2 ThreadsPerChild, ServerLimit, and MaxSpareThreads are important to adjust to match your operating system, and hardware.

    Restricting Access by IP

    If you have a resource that should only by accessed by a certain network, or IP address you can enforce this in your apache configuration. For instance if you want to restrict access to your intranet to allow only the 176.16 network:

    Order Deny,Allow
Deny from all
Allow from 176.16.0.0/16


    Or by IP:

    Order Deny,Allow
Deny from all
Allow from 127.0.0.1

    Adjusting KeepAlive settings

    According to the Apache documentation using HTTP Keep Alive’s can improve client performance by as much as 50%, so be careful before changing these settings, you will be trading performance for a slight denial of service mitigation.

    KeepAlive’s are turned on by default and you should leave them on, but you may consider changing the MaxKeepAliveRequests which defaults to 100, and the KeepAliveTimeout which defaults to 15. Analyze your log files to determine the appropriate values.

    Run Apache in a Chroot environment

    chroot allows you to run a program in its own isolated jail. This prevents a break in on one service from being able to effect anything else on the server.

    It can be fairly tricky to set this up using chroot due to library dependencies. I mentioned above that the mod_security module has built in chroot support. It makes the process as simple as adding a mod_security directive to your configuration:

    SecChrootDir /chroot/apache

    There are however some caveats however, so check out the docs for more info.

    Acknowledgments

    I have found the book Apache Security to be a highly valuable resource for securing an apache web server. Some of the suggestions listed above were inspired by this book.

    Suggestions

    Please post any suggestions, caveats, or corrections in the comments and I will update the post if necessary.

    Tagged with:
    Next Entries
    preload preload preload