If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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

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.

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.

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

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.

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.

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

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

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.

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.

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.