TAZ: TheTAZZone Network » honeypots

Tutorial – SMTP Relay Honeypot

admin — Mon, 23 Mar 2009 21:51:22 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

Do not use, republish, in whole or in part, without the consent of the Author. TheTAZZone policy is that Authors retain the rights to the work they submit and/or post…we do not sell, publish, transmit, or have the right to give permission for such…TheTAZZone merely retains the right to use, retain, and publish submitted work within it’s Network

Code: Select all: Soda_Popinsky has very kindly allowed this tutorial of his to be hosted on the TAZ.

SMTP Relay Honeypot Tutorial
By Soda_Popinsky

Overview:

This tutorial details the use of the Jackpot Mailswerver located here:
http://jackpot.uk.net/

A honeypot is, to quote Lance Spitzner founder of the Honeynet Project:

“Information system resource whose value lies in unauthorized or illicit use of that resource.”

Simply put, a honeypot is something that appears to be vulnerable, but in reality is recording illicit use by malicious attackers. I believe that most of the lure in honeypot technology lies in the sense of control it provides the owner. Network security is about avoidance, prevention, and mitigation, except where honeypots are involved. My interest in honeypots comes from a honeypots aggressive nature. A honeypot enables you to push back.

Jackpot is a “ready-to-run SMTP relay honeypot, written in pure Java”. With a tool like Jackpot, one can fight back against spammers with accurately logged complaints. The Jackpot website lists organizations you can go to with these complaints:

http://www.abuse.net/
http://www.spamhaus.org/index.lasso
http://www.euro.cauce.org/en/
http://www.cauce.org/
http://spam.abuse.net/
http://www.spamhelp.org/

Installation:

Find the download link here:
http://jackpot.uk.net

Unzip the file, and open the folder. Configuration is our first priority. Open jackpot.properties in a text editor. These fields are the most important:

ServerHeader: Change this to a fake server header (Jackpot by default is a dead giveaway, we’ll discuss later)
SmtpAddress: Specify the IP that jackpot will “serve” on.
HtmlPath: Change this to a folder name that you will remember
RoleAccountAlias: Specify the email address that postmaster email will go to
AdminUser: User ID for web admin
AdminPassword: User Pass for web admin
HttpPort: Change this to a port number you will access the web interface from. If left default, it could be a giveaway.
ServerName: Change this so your machine name isn’t revealed to a HELO command.

Review the other fields, you may need to tweak depending on your situation or configuration.

Here is the configuration file I am using:

#This entry specifies the value retuned in the “Server: ” HTTP header returned
#by Jackpot. By default, Jackpot claims to be “Jackpot” (with the current version number).
ServerHeader= Current Industries v 1.3

#IP Address where SMTP will be served, if your host is multi-homed. If the host is
#multi-homed, and this entry is missing or blank, SMTP will be served on all addresses.
SmtpAddress=

#Specifies a virtual path for HTML. This defaults to “html”, i.e.
#the root hosts page is http://:/html/hosts.html.
#If you set this value to “xyzzy”, then HTTP requests must be of the
#form http://:/xyzzy/something.html, otherwise they
#will elicit a 404. This is supposed to make it easier for Jackpot to be
#stealthy.
HtmlPath=jacklog

#Specifies an email address to which all mail to postmaster@[jackpot] or
#abuse@[jackpot] is to be forwarded.
RoleAccountAlias=SodaP@yahoo.com

#UserID for access to web-admin.
AdminUser=honeypot

#Password for access to Web-admin
AdminPassword=jackpotpassword

##################################################
##############
#The next section contains stuff you might customise to make
#this Jackpot look different from other Jackpots. If you want to
#customise these entries, telnet to a real mailserver and
#see how *it* behaves.
##################################################
##############

#Port for serving HTTP; it would be a good idea to change this, because the
#Jackpot server could be fingerprinted by finding it’s HTTP server.
HttpPort=8081

#This entry specifies the response sent to (all) VRFY requests.
VrfyResponse=250 User not recognized

#This entry specifies the response to (all) EXPN requests.
ExpnResponse=502 Command is disabled

#This entry specifies the response to (all) TURN requests.
TurnResponse=502 Command not implemented

#Specifies the 503 message
BadSequenceResponse=Bad sequence of commands

#This entry specifies the response to a DATA request.
DataResponse=Enter mail, end with \”.\” on a line by itself

#This entry specifies the response to a connection request when no threads are
#available in ther SMTP pool.
DiskFullResponse=Disk full

#Controls whether Jackpot adds a Received: header. Defaults to yes. If it doesn’t,
#it’s a badly-broken relay.
AddReceivedHeader=yes

#Controls whether any Received: header should show the sending host and address.
#If not, then the received header will show only the return path from the HELO (which
#a spammer would normally be forge). If this is No, Jackpot acts as a blind relay.
ShowReceivedHost=no

#This entry specifies the name of the mail server, as output in the banner.
#There are some (commented out) examples below from real mail-servers.
#MTADescription=Jackpot MailSwerver Version 1.0.0
MTADescription=ESMTP Sendmail V8

#This entry specifies the name of this machine, used in the response to HELO/EHLO,
#in any Received: header added by Jackpot to relayed messages,
#and to construct a postmaster address. Defaults to the name of your localhost
#(best setting).
ServerName=EVER-12E5oP

##################################################
##############
#This section contains stuff related to logging and so on -
#general system control.
##################################################
##############

#If set to Yes, bounce-messages will be sent for unaliased addresses in this
#(Jackpot’s) domain, and whenever a recipient’s mailhosts cannot be contacted.
#Default is no.
SendBounceMessages=no

#This entry specifies the maximum number of recipients in a message-envelope before it is
#rejected as spam. If you find you are getting relay-requests with multiple recipients,
#consider raising it.
MaxRecipients=1

#Extra time taken to respond to commands when in a spamrun.
#This is applied to every line entered in a HELO dioalog; the default is 1s. This
#is enough to make a HTML message from Outlook Express take almost a minute to enter.
TarpitDelay=3000

#The amount of time considered ‘too soon’ for the purposes of determining if a
#message should be relayed. Messages submitted via SMTP may also be subject to
#tarpitting if they arrive ‘too soon’. Default is 20s.
MinSpamInterval=20000

#This entry specifies the location for log output.
logfile=jackpot.log

#This entry controls the size of the ThreadPool. Jackpot will
#politely decline protocol activities on ports 25 and [HTTP-port]
#once the number of free threads falls below 5.
MaxThreads = 50

#Specifies the nameserver to use. If not provided, uses the system default.
#Doesn’t seem to affect anything much.
#NameServer=

#Specifies the (comma-delimited)names:ports of the HTTP servers to be updated
when SMTP traffic is captured.
LogServers=127.0.0.1

#Determines whether an Ident service should be offered to abuse.net
#(speeds up enquiries).
IdentForAbuse=yes

#Specifies what kinds of message get output to the system logs. This is a
#bit-set, the values are as follows:
# SMTP = 1;
# HTTP = 2;
# RELAY = 4;
# STATUS = 8;
# PROXY = 16;
# ENVE = 32;
# CONFIG = 64;
# DEBUG = 128;
FileLogging=255
ConsoleLogging=31

#Specifies a limit on the number of spams that should be stored for
#each spam-source.
MaxStoragePerSource=100

##################################################
##############
#This section specifies timouts for socket-connections used for
#several different purposes. Times are in milliseconds.
##################################################
##############
#How long to wait for proxy-test results
ProxyCheckTimeout=3000

#How long to wait for abuse.net lookups
AbuseLookupTimeout=3000

#How long to wait for SBL lookups
SBLLookupTimeout=2000

##################################################
##############
#This section controls what is running, and how, at system
#startup.
##################################################
##############

#Whether to start the HTTP service.
StartupHttp=yes

#Whether to start the SMTP service
StartupSmtp=yes

#Whether to start up with relaying enabled
StartupRelay=no

#Whether to start up with tarpitting enabled
StartupTarpit=yes

#Whether to start up with POSTing to storage enabled
StartupStorage=yes

#Whether to start up with the SOCKSV4 Proxy Server running
StartupProxy=no

##################################################
##############
#The last section contains stuff you are unlikely to need to
#change, at least for now.
##################################################
##############

#Port for serving SMTP; if you change this, you’ll probably be the only
#person who ever sends mail to your Jackpot server.
SmtpPort=25

#This entry restricts the maximum number of messages that can be queued at any one time.
#The queue is in memory, and Spammy will have to send relay-requests on multiple
#connections simultaneously to have a chance of filling it up.
MaxQueueSize=100

To start the honeypot, run jackpot.bat in the console. You will see it begin the “Mailswerver” daemon, as well as it’s web services.

C:\Documents and Settings\Soda\Desktop\jackpot-1.2.2>jackpot.bat
C:\Documents and Settings\Soda\Desktop\jackpot-1.2.2>java -Xss32k -Xmx24M -classpath ./classes;dnsjava-1.2.4.jar;jackpot.jar net.jackpot.Jackpot
05/02/04 19:25:06 GMT STATUS Jackpot Mailswerver version 1.2.2
05/02/04 19:25:15 GMT STATUS Started SMTP for your.ip.address
05/02/04 19:25:15 GMT STATUS Serving SMTP on port 25 for your.ip.address
05/02/04 19:25:15 GMT STATUS Serving HTTP on port 8081
05/02/04 19:25:15 GMT STATUS Jackpot version 1.2.1 is available at jackpot.uk.net
05/02/04 19:25:34 GMT SMTP attack.ip.address your.ip.address HELO
05/02/04 19:25:59 GMT SMTP attack.ip.address your.ip.address HELO

You’ll notice the last 2 lines in the console, they don’t appear when you start jackpot. Those are captured attacks, and will appear as they arrive.

Logging:

Logging is done in the file jackpot.log. The second column containing ENVE will contain communication with your honeypot.

Sample snippet from my log (notice the telnet-ish behavior of the attacker)

05/02/04 08:02:32 GMT ENVE AttackerIP MyIP 250 none-e8alt64jnu
05/02/04 08:02:56 GMT ENVE AttackerIP MyIP MAIL FROM: asdf@ASDF.com
05/02/04 08:02:59 GMT ENVE AttackerIP MyIP 250 Sender asdf@ASDF.com OK
05/02/04 08:03:16 GMT ENVE AttackerIP MyIP RCPT TP O: M<AIL@OTHER>COM
05/02/04 08:03:19 GMT ENVE AttackerIP MyIP 500 Command garbled
05/02/04 08:03:38 GMT ENVE AttackerIP MyIP RCPT TPOL: MAIL @ OTHER>COM.
05/02/04 08:03:41 GMT ENVE AttackerIP MyIP 500 Command garbled
05/02/04 08:03:53 GMT ENVE AttackerIP MyIP RCPT TO: MAIL@other.com
05/02/04 08:03:56 GMT ENVE AttackerIP MyIP 250 Recipient MAIL@other.com OK
05/02/04 08:04:06 GMT ENVE AttackerIP MyIP DATA

Jackpot also has a web interface, which we configured earlier. Visit

http://localhost

:[HttpPort]/[HtmlPath]/home.html for your interface. Fill in the fields with the ones defined in your config file.

The logging interface is very simple, you just click on a host and view the spam attempts they made on your server, including the data that was attempted to be sent, and other useful info for a complaint.

Admin:

Your username and password were defined in the config file earlier. Very simple interface for a very simple honeypot. It’s very self explanatory, except for the tarpit feature. That number forces a delay between commands, slowing the spammer down.

Conclusion:

Jackpot is hardly an industrial strength honeypot, but it’s good enough to be very useful. I don’t expect anyone will use this tutorial on a production environment, but just be aware that Honeypots introduce a security risk into an environment. So if you know what you are doing, go for it.
——————————————————-

I have no idea how old the Jackpot software is because it isn’t shown anywhere on the site. I was able to use it just fine.

I will have another tutorial coming out on Valentines Day, hopefully. It’s describes new breed of honeypot that you should all enjoy

Tutorial – Custom Web Based Honeypots with GHH

admin — Sun, 15 Mar 2009 21:42:21 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

Code: Select all: Soda_Popinsky has very kindly allowed this tutorial of his to be hosted on the TAZ.

Custom Web Based Honeypots with GHH
by Soda_Popinsky

Links
http://ghh.sourceforge.net
https://sourceforge.net/projects/ghh/

GHDB operated by johnny.ihackstuff.com

Overview

What is GHH?
GHH is the reaction to a new type of malicious web traffic: search engine hackers. GHH is a “Google Hack” honeypot. It is designed to provide reconaissance against attackers that use search engines as a hacking tool against your resources. GHH implements honeypot theory to provide additional security to your web presence.

What is a honeypot?
A honeypot is, to quote Lance Spitzner founder of the Honeynet Project:

“An information system resource whose value lies in unauthorized or illicit use of that resource.”

Simply put a honeypot is something that appears to be vulnerable, but in reality is recording illicit use by malicious attackers.

GHH allows administrators to track malicious hosts, observe who is perpetrating the attack and how it is being executed via the log. The data generated by this, or any other honeypot can be used to deny future access to attackers, notify service providers of attacks originating from their networks or act as an input for statistical analysis.

What are search engine hackers and why should I care?
Google has developed a powerful tool. The search engine that Google has implemented allows for searching on an immense amount of information. The Google index has swelled past 8 billion pages [February 2005] and continues to grow daily. Mirroring the growth of the Google index, the spread of web-based applications such as message boards and remote administrative tools has resulted in an increase in the number of misconfigured and vulnerable web apps available on the Internet.

These insecure tools, when combined with the power of a search engine and index which Google provides, results in a convenient attack vector for malicious users. It is in your best interest to be knowledgable of, and protect yourself from this threat.

This threat is amplified by tools like Foundstone’s Sitedigger, and Wikto, which automate this technique.

Building the Honeypot

(it’s recommended you have used or are familiar with how the pre-built honeypots work, as well as an existing knowledge of PHP)

At the GHH project page, you will find several pre-built honeypots. They may contain a certain file structure, but basically, they all have at least this minimum:

3 files

-The Honeypot
-The Config File
-The Log file

And a README.txt, which isn’t required to function but contains instructions for other users.

At the GHH project page, download the “Custom GHH Template”. Extract the contents and view config.php in a text editor. Each section is clearly marked with a header and footer, with small detail on what the section does. Find the configuration section, and change the $Filename variable to contain the filename or path to a text file (which you will have to make) that isn’t in the document root of your webserver. There is no default filename or default logfile to prevent predictable file locations. Your logs for your custom honeypot will go into this filepath, as well as any new honeypots that use this configuration file.

View template.php in a text editor and find the configuration section. Enter the filepath or filename for your configuration file (config.php doesn’t have to be in your document root).

Scroll down to where it says “Begin Custom Honeypot Section”.

PHP:

Code: Select all

////////////////////////////////////////////////////////

//Begin Custom Honeypot Section

//GHH Honeypot by Ryan McGeehan for GHDB Signature #365 (intitle:"PHP Shell *" "Enable stderr" filetypehp)

////////////////////////////////////////////////////////

$HoneypotName = "PHPSHELL";

//Trick PHP Shell page
echo “\n\nPHP Shell 1.7\n\n\n

PHP Shell 1.7

\n\n\n\n\n\n\n

//Find our PHP shell target in the referer site
if (strstr($Attack['referer'], “Shell”)){
$Signature[] = “Target in URL”;
}

//Finds if exact GHDB signature was used
if (strstr ($Attack['referer'], ” intitle%3A%22PHP+Shell+*%22+%22Enable+stderr%22+fi
letype%3Aphp”)){
$Signature[] = “GHDB Signature!”;
}

////////////////////////////////////////////////////////
//End Custom Honeypot Section
////////////////////////////////////////////////////////

The header shows that this template is using the honeypot code for the Google Hacking Database (GHDB) #365, which is a PHP Shell honeypot. PHP Shell is a vulnerability on a misconfigured webserver, and GHH is emulating it in this example.

Change $HoneypotName to a string that will describe the honeypot in the logs. GHH honeypots use quick and dirty names here as a standard.

The echo statement that appears is what imitates the vulnerable page. You will need the HTML output of the vulnerable website to place into this line. You can find HTML to use from the GHDB at the link provided above, maintained by johnny.ihackstuff.com. This brings up an important point called fingerprinting, which will be covered later.

The next line is a signature. It is a quick statement that searches for “Shell” in the referred URL. Many search engines have a referral included in their links, so it’s possible to determine which search engine and what query an attacker used to reach the honeypot. In this case, “Shell” is being searched for, and if found it will put “Target in URL” in the logs to do some of the investigation for us.

The next signature searches the referral for the exact GHDB Signature, this will tell us that the attacker either
A) Used a hacking tool
B) Used the GHDB database or
C) got lucky and crafted the same search as GHDB.

That’s how this section operates. Here are your tools to work with.

The $Attacker array contains these indexes:

PHP:

Code: Select all: $Attacker['IP'] //Contains the Hosts IP $Attacker['request'] //Contains the Hosts request to get to the honeypot $Attacker['referer'] //Contains the referrer if exists $Attacker['agent'] //Contains the hosts user agent $Attacker['accept'] //The rest describe the browser and connection between host and server $Attacker['charset'] $Attacker['encoding'] $Attacker['language'] $Attacker['connection'] $Attacker['keep_alive']

You can use these indexes along with some logic written in PHP similar (or exact logic, searching for different strings) to the sample given above. When your code decides it has found something malicious in the $Attacker array, append it to the end of the $Signature array:

PHP:

Code: Select all: if (strstr($Attack['referer'], "Shell")){ $Signature[] = "Target in URL"; //Append it like this, $array[]= "whatever"; will go to the end of the array }

and it will appear in the logfile along with any other signatures found.

The Logs

Here’s an example log from testing:

The logs are done in the CSV format. (Comma Separated Values) Each field is separated by a comma. The fields in the document include:

Tripped: The honeypot was accessed / tripped. (If you have multiple honeypots, this will tell you which one was accessed)
Time of Attack: The time the honeypot was viewed
Host: The IP address of the attacker
Requested URI: The Uniform Resource Identifier made to reach your site
Referrer: This will have the query used in the search engine in most cases, alarming you to what the attacker attempted to find, and how they tried to find it. The most important detail of the log.
Accepts: Contents of the Accept: header if there is one.
Accepts Charset: Contents of the Accepts_Charset header if there is one.
Accept Language: Contents of the Accept-Language
Connection: Contents of the Connection: header from the current request
User Agent: The user agent of the attacker
Signatures: The signature of attack the honeypot was able to determine from a combination of browsers headers.

Making Sense of It All

Don’t panic if your log file ($Filename) has a large number of requests in it. Honeypots are meant to be accessed. This log is a potent source of information to see how attackers are reaching your site. By looking at the referrer field in the log, you will be able to determine where the attacker came from, the query they used, or if your honeypot has been discovered and linked.

Fingerprinting and Policy

Fingerprinting

Fingerprinting is an issue with all honeypots. Fingerprinting is the process of identifying a honeypot from a legit application or host. In GHH’s case, the HTML has to be nearly identical in most cases to the vulnerable application’s HTML. This way Google indexes the honeypots and vulnerable applications the same way and they cannot be fingerprinting without browsing the server or viewing the page. There are some cases when the HTML is different from honeypot to honeypot, which would require you to break up the string with randomized codes, numbers, or strings.

Policy

Be extremely careful when creating any policies around a GHH logfile. There can be false positives and it can become a potential risk if logs are actively involved with policies.

————————

If anyone needs help trying out ghh, or has any suggestions for it, shoot me a pm. But seeing how I am “Under Investigation” now, I don’t know how long that offer will stand

So give it a roll and let me know how it goes.

Tutorial – Advanced Web Based Honeypot Techniques

admin — Fri, 13 Mar 2009 21:40:15 +0000

ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE

Code: Select all: Soda_Popinsky has very kindly allowed this tutorial of his to be hosted on the TAZ.
You can find the original post here: http://www.antionline.com/showthread.php?s=&threadid=269669

Advanced Web Based Honeypot Techniques
by Soda_Popinsky

Links
http://ghh.sourceforge.net
https://sourceforge.net/projects/ghh/

GHDB operated by johnny.ihackstuff.com

Background

The GHH project develops web based honeypots designed to lure “Google Hackers” using malicious search engine tactics, along with tools and documentation to allow others to develop customized honeypots, decreasing the exposure of vulnerable applications in the Google index.

Recommended Reading:

http://tazforum.thetazzone.com/viewtopi … =6084#6084

Overview

This tutorial will expand upon extension spoofing and transparent linking, and how to apply it in the creation of customized web based honeypots. The v1.1 honeypots and documentation released by GHH will be used as a reference for this tutorial.

Spoofed file extensions

While browsing through the Google Hacking Database (GHDB), you should notice that not all of the signatures target server side scripts (.php for example). This hack, for example:

inurl:passwd.txt

That hack searches for the file extension .txt. The contents of these files are usually interesting, and their exposure could introduce vulnerability on the server they are hosted on. There is usually more of a risk being introduced to the enviroment than a typical web application vulnerability in cases like these.

Or perhaps these:

inurl:admin.mdb
inurl:customer.mdb
inurl:users.mdb

Depending on their contents, a database file such as this could cause extreme losses. In order to emulate filetypes like these, GHH depends on apache htaccess files to spoof its file extension. We can then take advantage of server side scripting to log and handle the attack any way we want, and if we’re using GHH as an engine, this means log remotely and apply signatures to the attack.

So following the previous tutorial on GHH v1.0 (Should still be compatible) we can leverage htaccess and Apache to allow our honeypot to spoof another file extension. By placing a htaccess file in the same directory as our honeypot with the following lines:

Code: Select all: AddHandler application/x-httpd-php .mdb #Change .mdb to your filetype AddType application/x-httpd-php .mdb #Change .mdb to your filetype

Apache & PHP will interpret the .xyz file as a PHP script . The only problem is that browsers won’t behave normally when viewing some extensions (.mdb, .txt for example) To handle this, we can place the following PHP code at the beginning of our honeypot:

PHP:

Code: Select all: header('Content-Type: text/plain'); //This line must change //Rest of code... ?>

This will tell the browser to handle a file as a certain type of content. The previous code would be acceptable for a .sql, .txt, .log, .dat file or something similar. When the content reaches the attacker, the browser will behave like it should (we already have them captured, but it’s best not to tip them off anyhow). If you had a database file, you’d want it to open in access for example. This would require ‘Content-Type: application/msaccess’ to be sent to the browser.

Content types available @:
http://www.iana.org/assignments/media-types/

Transparent Linking

Transparent linking is the process of advertising your honeypot to search engines, but not the casual users of your website. There are a few ways to do this, some better than others. The better your transparent link, the less false positives you’ll have in your logs. The goal is to have visitors to your honeypot that are referred from a search engine, and not from the site it’s hosted on. This forces them to find the honeypot through the engine, and by that vector you can retrieve the search query they used against your site (intention and motive!)

Direct link
Simply making an obvious hyperlink with some text in your top level website:

PHP:

Code: Select all: blah

Obvious problems include users clicking on the link, and filling your logs with false positive. Don’t use this type of link.

Camo Link
The following CSS style will make the link the same color as your background. You should change black to match your background.

PHP:

Code: Select all

Then apply your style to the link.

PHP:

Code: Select all: .

This has it’s problems as well. It’s cumbersome, because you might not know what the background will be behind the link. This makes a literally transparent link desireable, however I haven’t found any options other than CSS Alpha() function, which doesn’t seem to work well with text.

Disappearing link
The following CSS will prevent the link from being shown to the user at all, as long as their browser renders CSS.

PHP:

Code: Select all

The link is now completely nonexistent, except in the source. The thought was that being completely invisible would be the best option, however the GHH project learned the hard way that display:none is completely ignored by Google because it can be abused. Against what seems to be the popular belief, Google does not index links with a CSS style of display:none (such a smart spider!) It will however, be indexed by less powerful crawlers.

Shy Link
In order to leverage a disappearing link, you’ll need to plug in some PHP to detect when the Googlebot comes around (You have to cater to Googlebot )

PHP:

Code: Select all: if(!strstr($_SERVER['HTTP_USER_AGENT'], 'Googlebot')) echo 'class="cya"'; ?> >.

This is also a pain, but it does the job. Other spiders aren’t as smart as Googlebot, and freely crawl links with the display:none style, so this technique will compeletly cover the link from casual browsers and still let it be discovered by Google.

Map Link
The use of image maps can be a quick way to link multiple honeypots. Create nearly untouchable links in an image.

PHP:

Code: Select all

Buddy Link
Buddy linking is as simple as having other domains link to your honeypot. When they are crawled, spiders will hopefully follow up to your site. Casual users of your site are not likely to cause false positives, however users of your buddies site may cause them, making it a good idea to stick to the tactics described here.

“Tattletale” Link
TELL the search engine where you are, and forget about linking. Most engines have a suggest feature, Google has sitemaps. If you don’t feel like using the python tool or writing XML, there’s the option to submit a textfile with URL’s separated by CRLF’s. Check it out here:
http://www.google.com/webmasters/si…bid=us-et-about

GHH Theory

The nature of GHH is to be known but not seen. This is why working with GHH is challenging. The concept of Google Hacking and Honeypots are simple, however the design of the web and the design of a honeypot in tandem present the challenge of “hiding in plain sight” on the web. GHH is developed under that concept, which is useful in the creation of new tools related to the relevant attacks.

Benefits of GHH include very early warning of a potential attack, by catching an attacker in their reconnaisance phase and learning their possible motives. GHH also improves other vulnerable targets chances of survival on the web. By saturating a search engine index with specific false positives, it makes what was once an foolproof vector a more unreliable source of victims. So in short, it also benefits others.