SMTP Relay Honeypot Tutorial

Printable View

February 4th, 2005, 10:08 AM
Soda_Popinsky

SMTP Relay Honeypot Tutorial

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:

Quote:

#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://<jackpot>:<port>/html/hosts.html.
#If you set this value to "xyzzy", then HTTP requests must be of the
#form http://<jackpot>:<port>/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.
[email protected]

#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.

Quote:

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)

Quote:

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: [email protected]
05/02/04 08:02:59 GMT ENVE AttackerIP MyIP 250 Sender [email protected] 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: [email protected]
05/02/04 08:03:56 GMT ENVE AttackerIP MyIP 250 Recipient [email protected] 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.
February 4th, 2005, 12:10 PM
jdenny

Soda, no offense, I find it's better reading the details on the website rather than this "security tutorial".
I see you've posted some helpful tutorials, but honestly a sample network configuration (along with sample server's IP address, spammer's IP address, etc), sample jackpot.properties file, and sample console output would help.

Anyway, nice find! Jackpot is a great honeypot.

Quote:

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 believe it was released on around 2002. See the licensing terms on the website.

Peace always,
<jdenny>
February 4th, 2005, 02:51 PM
aozyre

thankyou very much
February 4th, 2005, 05:19 PM
R0n1n

SMTP relay honeypot...that sounds like a mix up of ideas...at least at this time in the morning it does.

A mail relay typically acts as a filter anyway and ensures that your mail server is not directly accessible from the internet, and a honeypot is used to fool attackers into wasting their time attacking target X while your other systems stay safe.

So, why would you want to make your mail relay a honeypot???

Unless of course it was a completely fake SMTP relay to begin with.
February 4th, 2005, 06:15 PM
Soda_Popinsky

Spammers look for open relays for spamming. Jackpot is a completely fake open relay, and pretty much just wastes a spammers time and collects information about the spammer.

jdenny- none taken! I'm a selfish tutorial writer, I only write these things when I have a need for them myself (and I needed this one quick last night). If I have time I may plug in some sample configs.
February 4th, 2005, 08:26 PM
R0n1n

So its more of a research tool then anything else?
February 4th, 2005, 08:39 PM
Soda_Popinsky

Nearly every (if not all) honeypots are considered research tools. Jackpot is a tool that allows you to catch spammers in the act of exploiting open relays, and allows you to either see what they do, waste their time with the tarpit function, or take action against the spammer.

I'll be making additions to the tut shortly.

edit: Additions made
February 4th, 2005, 08:51 PM
R0n1n

Yes I amware of that, but a mail relay honeypot seems to be more of a research tool then a "standard honeypot" which you may use to delay attackers. Whereas I see no point in setting up a fake mail relay for spammers to waste them time with (other then research) as it just chews up your bandwidth. As you just prevent your mail system from allowing external relaying and thats the attack mitigated.
February 4th, 2005, 08:57 PM
Soda_Popinsky

Yup, you are correct. I wouldn't put something like this on my business network, it's pretty much only for research. Personally, I am having fun with it and I hope I didn't promote it as a line of defense.
February 5th, 2005, 12:23 AM
The Duck

Well, personally, I like the idea, it sounds interesting and fun. I would give you AP's but for some reason i'm getting this:

Quote:

You have given out too many AntiPoints today, try again later.

Go figure... :p
December 5th, 2005, 05:04 AM
minasbeede

Quote:

Originally posted here by Soda_Popinsky
Yup, you are correct. I wouldn't put something like this on my business network, it's pretty much only for research. Personally, I am having fun with it and I hope I didn't promote it as a line of defense.

Jackpot and the bubblegum Proxypot are (or can be) production honeypots . You don't simply learn from them. they can (and do) capture spam before it reaches the destination server. As they intercept spam that is being sent by an abuse pathway there's no need to filter:i f it comes, it's abuse-related. If the honeypot is configured to indicate to the abuser-spammer that it is an open relay or open proxy (by gioving a psotive response to the spammers' tests) then the spammer is very likely to send spam. (I say "abuse-related" because such honeypots receive both test messagfes and spam. You probably want to deliver the test messages, you don't want to deliver the spam.)

As the honeypot keeps a copy of everything, including the test messages first sent to it before the spam, it's possible to find out where the spammer sends his tests (which are how he learns the IP address of open relays.) If the ISP at that site is agreeable you can cause the spammer further trouble: some, when asked, consented to leave the account active but to divert all email away from it (as the account was for an illegal activity the owner had violated the TOS and had no real legal rights - these were always freemail providers.) For a while, at least, the spammer would think he was finding no open relays. He could check his test-message account for new email but there's never be any. What's he going to do when he figures out what's hit him - sue for not helping him commit abuse? Not likely - he'll just slink away, and maybe never use that freemail provider again for a test message dropbox address. That's a plus.

You also have copies of the spam and know the web sites to which the spammer directed his traffic. nowadays they may be pretty sophisticated and clever about that, of course, and use destinations that are also on zombies, and for which the DNS changes frequently.

Probably you'd want to at least think carefully before putting one on a business network but having one on a university network should be fine. I ran Jackpot for a while at home and caught some stuff. My ISP now doens't allow outgoing port 25 traffic but I still see (using ZoneAlarm) occassional probes of port 25: spammers still are looking. I have never run a proxypot but those can have a wicked effect on the spammers. Zombiepots would, today, also be wicked.

The problem with the internet was that it was designed when trust was a reasonable thing. Now it isn't. The trust that really hurts is the trust the abusers have that their abuse will work: if a system looks like it will allow abuse, it almost always does. Destroy that trust and you destroy spam. Make them fear every IP that looks like it can be abused, make them doubt that looking vulnerable is identical to being vulnerable. All the while you're doing that you can also be delibvering hard body blows to them. Microsoft ran a proxypot for a while and now has a suit with about 20 "John Doe" (som enames are now filled in) defendants. Anybody (in principle) can run a zombiepot. (If you doubt you can, fine: trust that doubt.)
December 5th, 2005, 05:18 AM
minasbeede

Quote:

Originally posted here by R0n1n

So, why would you want to make your mail relay a honeypot???

Unless of course it was a completely fake SMTP relay to begin with. [/B]

Exactly.

As it happens my honeypot was both an SMTP server and a honeypot. That's because it was a server first and because it was easier (and less expensive) to configure the SMTP server to accept but not deliver illicit relay email than it would have been to configure it to not accept illicit relay email. I think I succeeded in stopping delivery of spam to a few million recipients (a tiny drop in the bucket) but that was far, far better than not accepting the same spam so that the spammer would simply have selected another open realy that really was open and get the spam delivered.
Plus at least a few times I got the spammer's account terminated. Twice, for Chris "Rizler" Smith.

It is so much simpler to just run a completely fake SMTP relay that doing so is the method of choice. Then you don't have to filter: it's all abuse email. That's even more so for a proxypot: even the TCP/IP port is illicit for email.
December 5th, 2005, 06:15 AM
Soda_Popinsky

Hi minasbeede-

Jackpot, or any other honeypot, are not specifically defined as "production". So yes, Jackpot could be a production honeypot.

Unfortunately, Jackpot has been ditched and is no longer developed. I wouldn't encourage running it in an production enviroment for obvious reasons.

A quick glance at the proxypot changelog reveals the same (active development until May of this year, and nothing as far as community development it seems) so unless they magically ran out of bugs (or are developing elsewhere) I'd look for a different solution for the job. :D

Quote:

Originally posted here by minasbeede
Jackpot and the bubblegum Proxypot are (or can be) production honeypots . You don't simply learn from them. they can (and do) capture spam before it reaches the destination server. As they intercept spam that is being sent by an abuse pathway there's no need to filter:i f it comes, it's abuse-related. If the honeypot is configured to indicate to the abuser-spammer that it is an open relay or open proxy (by gioving a psotive response to the spammers' tests) then the spammer is very likely to send spam. (I say "abuse-related" because such honeypots receive both test messagfes and spam. You probably want to deliver the test messages, you don't want to deliver the spam.)

As the honeypot keeps a copy of everything, including the test messages first sent to it before the spam, it's possible to find out where the spammer sends his tests (which are how he learns the IP address of open relays.) If the ISP at that site is agreeable you can cause the spammer further trouble: some, when asked, consented to leave the account active but to divert all email away from it (as the account was for an illegal activity the owner had violated the TOS and had no real legal rights - these were always freemail providers.) For a while, at least, the spammer would think he was finding no open relays. He could check his test-message account for new email but there's never be any. What's he going to do when he figures out what's hit him - sue for not helping him commit abuse? Not likely - he'll just slink away, and maybe never use that freemail provider again for a test message dropbox address. That's a plus.

You also have copies of the spam and know the web sites to which the spammer directed his traffic. nowadays they may be pretty sophisticated and clever about that, of course, and use destinations that are also on zombies, and for which the DNS changes frequently.

Probably you'd want to at least think carefully before putting one on a business network but having one on a university network should be fine. I ran Jackpot for a while at home and caught some stuff. My ISP now doens't allow outgoing port 25 traffic but I still see (using ZoneAlarm) occassional probes of port 25: spammers still are looking. I have never run a proxypot but those can have a wicked effect on the spammers. Zombiepots would, today, also be wicked.

The problem with the internet was that it was designed when trust was a reasonable thing. Now it isn't. The trust that really hurts is the trust the abusers have that their abuse will work: if a system looks like it will allow abuse, it almost always does. Destroy that trust and you destroy spam. Make them fear every IP that looks like it can be abused, make them doubt that looking vulnerable is identical to being vulnerable. All the while you're doing that you can also be delibvering hard body blows to them. Microsoft ran a proxypot for a while and now has a suit with about 20 "John Doe" (som enames are now filled in) defendants. Anybody (in principle) can run a zombiepot. (If you doubt you can, fine: trust that doubt.)
December 5th, 2005, 03:11 PM
minasbeede

Quote:

Originally posted here by Soda_Popinsky
Hi minasbeede-

Jackpot, or any other honeypot, are not specifically defined as "production". So yes, Jackpot could be a production honeypot.

Unfortunately, Jackpot has been ditched and is no longer developed. I wouldn't encourage running it in an production enviroment for obvious reasons.

A quick glance at the proxypot changelog reveals the same (active development until May of this year, and nothing as far as community development it seems) so unless they magically ran out of bugs (or are developing elsewhere) I'd look for a different solution for the job. :D

Yes - although if it is run in a mode where it delivers nothing it is still useful. I saw that sometimes it did deliver spam, and that's bad enough to be avoided. "Production" is a word chosen by someone, I think Marcus Ranum, to differentiate that sort of usage from "research" usage. "Research" implies you just find things out and do nothing. "Production" implies going beyond finding things out. I think it also implies a narrow honeypot: one that is intended to capture only one specific type of abuse and be secure against all other types.

Originally I advocated running sendmail as a honeypot - the name "minasbeede" is a play on

sendmail -bd

Back then (circa 2001) that was enough to cause sendmail to accept everything but deliver nothing. Since then it's changed. and a bit more is needed. Jackpot isn't the only game in town: "roll your own" works.

Even when Jackpot delivered spam that was less than 1% of the incoming traffic. Many anti-spammers get all huffy about ever delivering any spam (and they do have a point) but when the internet as a whole essentially delivers 100% of the spam sent through it by abuse it's a bit short-sighted to complain about a system that instead stops 99% or so of it. But 100% stoppage is the goal. If Jackpot is run in the "deliver nothing" mode then it should only capture relay tests. There have been Oriental (Taiwan, Hong Kong, Korea, China) spammers who don't rely on receiving back their test messages and start trying to send spam merely because a system accepted a test message. Even in the "deliver nothing" mode Jackpot can stop some spam, and surely is useful for trapping relay tests.

Here's a captured relay test from somebody else's Jackpot:

220 mail.xxx.xxx.xxx ESMTP Sendmail (8.8.3/8.8.3) no UCE. See web page at servername Fri 02 Dec 2005 03:39:40 GMT
HELO yyy.yyy.yyy.yyy
250 mail.xxx.xxx.xxx
MAIL FROM:<[email protected]>
250 Sender <[email protected]> OK
RCPT TO:<[email protected]>
250 Recipient <[email protected]> OK
DATA
Message:

Received: from 58.53.63.222 ([58.53.63.222]) by mail.xxx.xxx.xxx (ESMTP Sendmail (8.8.3/8.8.3) no UCE. See web page at servername); Fri 02 Dec 2005 03:39:45 GMT
Subject: 7534df112cn206:yyy.yyy.yyy.yyy<192.168.0.137>
X-Priority: 1
X-Mail-Priority: Highest
Content-Type: text/plain;

I've replaced the actual IP number with yyy.yyy.yyy.yyy and changed the IP name to mail.xxx.xxx.xxx.

Back a ways in the logs of that Jackpot is a record of 2975 messages with 29680 recipients. that has to have been spam, with perhaps a few relay tests as well. Ah, yes: the subjects so far are all "Viagra/Cialis."

Real simple: the tested IP number is in the Subject. there is no message body.

I contend that the internet would be far different and far less available for abuse if some users would actually watch for the abuse and sometimes take action (like report the abuse to the involved ISPs.) Currently most ISPs probably would not even understand what you were telling them if you told them (as 56.com could be told) that an account on their system was being used as a dropbox for relay tests - that's how amazingly ignorant the internet as a whole is (where it's really the operators who are ignorant, of course.)

Microsoft recently filed a suit with around 20 defendants based, as far as I can tell, on information captured by a single zombie honeypot. Microsoft has the size and budget to be able to follow through with a major lawsuit but in principle anyone could gather similar information.

Some zombie software is sent as a virus, meaning the virus could infect a system anywhere and that system would then "report home" to the spammer of the infection. I fnd it thigh-slapping funny for a spammer to be setting himself up to be gulled by someone who sets up a trap and then does a fake "phone home" as though it really is a zombie.

Spam is improper behavior on the internet. Technical tools don't have to work only technically: they can gather evidence that can be used to alter behavior (such as make sending spam too expensive because of the lawsuits.)
December 5th, 2005, 07:09 PM
Soda_Popinsky

Quote:

"Production" is a word chosen by someone, I think Marcus Ranum, to differentiate that sort of usage from "research" usage. "Research" implies you just find things out and do nothing. "Production" implies going beyond finding things out. I think it also implies a narrow honeypot: one that is intended to capture only one specific type of abuse and be secure against all other types.

Production and research honeypots are terms used by the Honeynet project, which differentiate honeypots used to protect organizations, or used to understand new threats. So by that reasoning, one can't be the other. (those terms were coined by the snort guy, according to the honeynet project)

Regardless, the honeypot is flexible (has no standards, and a generic definition), so everything is open to interpretation. There's no right and wrong, but there is effective and not.
December 5th, 2005, 07:31 PM
minasbeede

The distinction I'd make is that honeypots such as Jackpot (or an improved, supported Jackpot, if any) actually accomplish something that tends to injure the absuers or create a cost to them. It is accomplishing something that to me makes it a "production" honeypot. I thought perhaps the first appearance of the phrase "production honeypot" was in the web version a PowerPoint presentation made by Marcus Ranum but I could easily be wrong.

It appears Jackpots in the US (of which I have access to just one) do have some effect but most of that effect comes from interfering with spam from Asia to email addresses in Asia. As I have a sample of one I can't make really meaningful assessments but it sort of looks like spammers in the US have pretty much moved beyond open relay abuse to other types of abuse. That could be a reason for Jack Cleaver to stop developing or supporting Jackpot. Someone could write an open proxy honeypot that ran as a Windows application. Same, for a zombie honeypot. I doubt that there'd ever be anything like 1% coverage of the internent by honeypots: the high-volume abuse would be killed off long before that many could be implemented.

As it still stands any spammer can test systems throughout the internet and accurately divide them into two classes: those that can be abused and those that cannot - and then proceed to abuse those tht can be abused. It's cheap and safe (and the test might be done by a virus, making it even cheaper and safer, once the virus is out.) "Cheap and safe" means there's almost no pressure on the spammers to stop doing such things. It is no surprise that they don't stop doing such things.

One of the great virtues of production honeypots (SMTP, proxy, zombie) is that ordinary users don't look for vulnerabilities and are completely unaffected by the honeypots. Only abusers look for such vulnerabilities and it is precisely those individuals who should suffer for their abuse.

There are those who also search the internet for vulnerable systems so that they can blocklist them. As long as the listings that result aren't so broad that they affect operation of a critical server that's no problem.
December 5th, 2005, 07:50 PM
Soda_Popinsky

Quote:

The distinction I'd make is that honeypots such as Jackpot (or an improved, supported Jackpot, if any) actually accomplish something that tends to injure the absuers or create a cost to them. It is accomplishing something that to me makes it a "production" honeypot. I thought perhaps the first appearance of the phrase "production honeypot" was in the web version a PowerPoint presentation made by Marcus Ranum but I could easily be wrong.

Your terminology is incorrect in that honeypots are not part of the business function in just about any every enviroment. Production enviroments imply that there is a business function that cannot be interrupted. As such, you can assume that the business deploying a honeypot is doing so to protect their own investments, and not to enter the Anti-Spam (Anti-Whatever) industry. They probably wouldn't want the expense of counter-hack technology and the risks associated with it. Especially in Illinois.
December 5th, 2005, 08:14 PM
minasbeede

Quote:

Originally posted here by Soda_Popinsky
Your terminology is incorrect in that honeypots are not part of the business function in just about any every enviroment. Production enviroments imply that there is a business function that cannot be interrupted. As such, you can assume that the business deploying a honeypot is doing so to protect their own investments, and not to enter the Anti-Spam (Anti-Whatever) industry. They probably wouldn't want the expense of counter-hack technology and the risks associated with it. Especially in Illinois.

You make perfect sense, but I don't think or intend to imply that "production" means the honeypots are fulfilling a business function. I think, too, that the honeynet project also doesn't mean to imply that - but I could be wrong.

"Production" means (to me) they are used to produce results (and not merely learn.) The terms "production honeypot" and "research honeypot" are, I think, meant to indicate that there are different forms of honeypot.

I could see a business using a production honeypot(as Microsoft did, with a zombiepot) but I'd think they'd maintain a huge separation between production business systems and production honeypots. If the "production" honeypot does no more than accept and record abuse attempts then I could see it being used more closely to the business functions - but I'm not the person to decide that for any business.

Even so, just as Microsoft saw fit to do other businesses could also take a more aggressive stance against abuse in order to reduce the level of abuse and thus benefit the business. That would be particularly so, I'd think, for ISPs and network connectivity providers. There'd also be a possibility of a changed reputation effect: if ISP A becomes known as one that detects abuse and institutes lawsuits or provides evidence for criminal prosecutions that ought to dissaude many of the potential abusers from even trying to abuse IP addresses controlled by ISP A. I don't think it matters a lot if any honeypot used in that effort is claimed to be a production honeypot in the business sense or not. What matters is that it does produce results.
December 6th, 2005, 10:18 AM
Egaladeist

bumped