hi.pe.kr 날으는물고기·´″°³о♡

webhoneypot is a DShield Web Application Honeypot offering this honeypot for users to capture automated web application exploits. It is a very simple “semi interactive” honeypot implemented in PHP.

webhoneypot project is used to develop the honeypot. Do not use this code to install a honeypot unless you are interested in helping development.

Prerequisitesfor installing webhoneypot.

• dshield.org account
• Publicly routable IP address that can receive requests on TCP port 80. Dynamic IP addresses are ok, but you should sign up with a dynamic dns provider like dyndns so that you can provide a constant hostname.
• Linux or Windows machine with a webserver, PHP5 support and the curl extension installed.

 webhoneypot installation section should also be applicable to nearly any LAMP (Linux, Apache, MySQL, PHP) application platform, but the exact paths are taken from Fedora Core, and will need to be altered to match your environment.

Installation is very easy

1. Extract the archive file honeypot.tgz ( webhoneypot ) to a temporary directory or into the directory for a virtual host that you plan to create.
2. Edit etcconfig.local and edit the userid (userid=…) and password (password=…) to match your account information for your Dshield login; If you provide the password, the script automatically converts it into a hashed password replacing the password entry. Also, complete the full path to the location where you will be keeping your log files (logdir=…) if different from the default location logs/.
3. Edit your apache configuration file /etc/httpd/httpd.conf ??
4. Now copy the four folders and contents into the appropriate folders
5. Set the appropriate permissions. The userid that your webserver runs under — usually apache — will need read permissions to the template folder. Use the chown command to make apache the owner of the templates folder, then use the chmod command to give the apache user read access to the files. (chmod + r) The apache user will also need write access to the logs folder. Once again change the owner to apache with the chown command and give apache write access with chmod + w.
6. Test the site. Open a webbrowser and navigate to your webhoneypot site. You should be get back the default template which states that you are using the demo server and welcome to phpmyadmin. Try http://[webhoneypot ip or dns name]/robots.txt and you should get back template 104 which is a robots.txt file. If you get an error instead the most common problems are an incorrect path in one of your configuration files, a permissions problem writing to the logfile, or you did not install the curl extension that is required to post the results back to Dshield. You should be able to determine which one it is by the webpage returned from the server or your logfile if you have one.
7. Check your logfile. If everything is operating properly, you should see the details of which templates are being matched, and the client request successfully posted to http://isc1.sans.org/weblogs/post.html.
8. Once you have completed your testing list any operational honeypots under your DShield profile page.
9. Log in to your account, go to the “my info” page and use the link provided to activate webhoneypot .

Download webhoneypot:

webhoneypot v0.1.r123 – webhoneypot.0.1.r123.tgz

Previously we explained why some web hosting servers block the WebsiteDefender Agent, which could cause your WebsiteDefender service to malfunction.

In this article, we will show you exactly how a web application firewall can block communications between the WebsiteDefender Agent and the WebsiteDefender Server.

Many hosting providers or server administrators use web application firewalls, such as ModSecurity, to filter and monitor a website for hacker attacks. Some of the web application firewalls used today have different configured rule sets to filter HTTP software requests and can therefore interfere with the WebsiteDefender Agent.  Below are some examples that show how and why the WebsiteDefender Agent might be blocked by a web application firewall.

The web application firewall might block the communication completely with the WebsiteDefender Agent.

In this example, the WebsiteDefender Agent request to the web server has been blocked by the firewall, based on the predefined rule sets. Any requests sent from the WebsiteDefender Server will not reach the WebsiteDefender Agent. Depending on the firewall configuration, when you run the WebsiteDefender Agent test, you might receive a “404 Not Found” error or “Unreachable” error code.

The web application firewall might alter, modify or strip important and essential components from the WebsiteDefender Agent request.

In this case, the request sent by the WebsiteDefender Scanning Server to the WebsiteDefender Agent will manage to pass through the firewall but the information returned will be invalid.

Therefore, the WebsiteDefender Agent will send an invalid response back to the WebsiteDefender Scanning Server, stating that a previously received communication request was corrupted or not recognized.

The request received by the WebsiteDefender Agent passes the Web Application Firewall check. In this case, the communication request sent by the WebsiteDefender Server to the WebsiteDefender Agent successfully passes through the web application firewall. The WebsiteDefender Agent response successfully reaches the WebsiteDefender Server, meaning that the WebsiteDefender Agent is up and running successfully.

출처 : www.websitedefender.com