Installation of the Webhoneypot http://sites.google.com/site/webhoneypotsite/home/installation-of-the-webhoneypot Supported Operating Systems First Thoughts Prerequisites Installation from source (tar or svn) Configuration Troubleshooting

The Webhoneypot should work on all operating systems with a Webserver capable of PHP and something like mod_rewrite or mod_alias and PHP5 including commandline-support

Packages are available for some operatingsystems

<dl></dl>

<dt>Debian: </dt>

<dt></dt>

<dd></dd>

<a href="http://sites.google.com/site/webhoneypotsite/home/installation-of-the-webhoneypot/install-debian">Install Debian</a>

<dt>Ubuntu: </dt>

The first thing you need to decide is if you wish to install it on a dedicate domain (using virtual hosts) or in a subdirectory. Recommendation is to use a dedicated domain.

There are several considerations:

adding a new virtual host usually requires administrative privileges for the server (this might not always be the case, since in some cases you might have the ability to add new virtual hosts trough a web interface like cPanel).

adding a new virtual host requires you to posess a given domain. You can circumvent this requirement by using a dynamic DNS provider (which gives you a free DNS name) or by using a subdomain

using the honeypot in a subdirectory is a security risk. While we try our best to make sure that our code is secure, you might want to reconsider deploying it in a production environment. One risk you might expose yourself to is XSS vulnerabilities in the served up templates. Even though we try hard to remove exploitable code from the templates, some things might slip through. This is also relevant to the subdomain scenario.

a Webserver capable of PHP and something like mod_rewrite or mod_alias

PHP5 with commandline-support

This guide supposes that you already have functional webserver and PHP set up with your webserver. If you don't have PHP set up, please refer to the documentation of your webserver (or the documentation of PHP - http://www.php.net/install) on how to do so.

A dshield account. This can be configured after installation.

The installation from the tarball is the most flexible version - but most things must be done manually. All installation tasks must normally be done as root/Administrator.

Unpack the archive (tar -xzf &lt;tarfile&gt;, unzip &lt;zip&gt;) e.g. to /opt/webhoneypot

For security reasons, the honeypot checks if the used directories (templates, lib, log, etc) are outside of the document root. Keep this in mind when extracting it (ie. you should extract it somewhere other than the document root for your webserver)

Set the appropriate permissions (see table below)

Configure your Rewrite Rules:

Run lib/config.php

Filessystem Linux (e.g. below /opt/webhoneypot):

Directory

Contents

Description

Html

index.php

This directory is the DOCUMENT_ROOT

Logs

Logfiles

This Directory may be linked e.g. to /var/log/webhoneypot or configured with config.local (see below)

Etc

config.local

This Directory may be linked to /etc/webhoneypot

templates

template files and directories

Lib

config.php

common_functions.php

update-client.php

updates

update files

Permissions

owner:group

permissions

all directories

# all files

Exceptions:

logs

html/index.php

root:root

www:www

755

644

640

440

Remember the webhoneypot is optimized for virtual host usecase.

Copy index.php from the "html" directory to the directory where you want to use it (you might also want to rename it to something else). Note: on systems which they support it, you might want to use a symlink to the original file, so that you can update it in one place and you don't have to remember updating it in all the places you've copied it to.

It is recommended that you install the free IIS 7 URL rewriting module from Microsoft (http://blogs.iis.net/ruslany/archive/2008/11/10/url-rewrite-module-release-to-web.aspx ). It will work even without it, but having it installed can give a much more authentic looking result.

Add a virtual directory pointing to the html directory of the honeypot

If you don't have the URL rewriting module installed, the URL will look like this: http://example.com/wh/index.php/PHPBB (where wh is assumed to be the name of the virtual directory)

If you have URL rewriting, add the following rule: pattern: .*, rewrite url: /wh/index.php

Add a new site with the physical path set to the html directory

If you have URL rewriting, add the same rules as above

Edit it and replace the $sBaseDir=realpath(dirname(__FILE__) . '/../'); line with the absolute path of your webhoneypot directory (the parent directory of html, lib, logs, etc). For example:

$sBaseDir=”/opt/webhoneypot”; //for *nix $sBaseDir=”c://weboneypot”; //for windows

All user-configuration is done with etc/config.local. The syntax is as follows:

Configuration of various Webservers.

Make sure that mod_rewrite is loaded (in many configuration it is not by default). You should see a line like the following in your apache configuration file: LoadModule rewrite_module modules/mod_rewrite.so

Add the following configuration options for mod_rewrite. They can be placed either in your apache configuration file directly or in a .htaccess file:

Mod_alias has the advantage of being enabled by default on more servers, however it cannot be configured from the .htaccess file (configuration must be done directly in the Apache configuration files), which makes this solution unfeasible if you don't have access to the configuration files. The needed configuration directive is:

Enable the mod_rewrite module (make sure that it is present in the server.modules list and not commented out). Add the following configuration line:

Quick tip: if you get "no input file specified" with nginx + fastcgi + PHP, check that fastcgi_param is set correctly. It should be set like this:

where /var/www/nginx-default is the document root for the particular site

Add the following rewrite rule:

If URL rewriting is not available for your webserver, you still might be able to use the honeypot, because most webservers will traverse the path up until they find a part which is actionable. So for example, given the following url: http://example.com/wh.php/PHPBB/index.php, the webserver goes up the path until it arrives to wh.php and executes it. The honeypot is coded to handle this situation

If the user who extracted/installed the webhoneypot is not the same as the one the webserver is running under, you need the following permissions for the webserver user:

read on etc

read on html/index.php

read on lib

read/write on logs

read on templates