Re: [Asrg] Whitelisting on Message-ID (Was Turing Test ...) honypot plug

On Sunday, April 6, 2003, at 07:36  PM, Brad Spencer wrote:

> I'd consider it to be a favor to me to blocklist it, when it was open,
Me, too. In fact I screwed up a few weeks ago (god bless sendmail's 
queuemode=defer) and left a relay open (I copied a config from a 
machine behind a firewall to a machine open to the world). The bad news 
is the spammers found it amazingly quickly. the good news was that 
spamcop found the spammers even faster, and we got that puppy shut down 
before major bad things happened (just minor). Even more fun, we set 
the thing to accept and discard the spam from the spammer, so it ate a 
few tens of thousands of messages before he figured it out and went 
away.
In my case, the blacklist caught a problem much faster that I would 
have. While I don't by any means consider all blacklists my friend (or 
well run, or useful, or objective, or whatever), they're a useful tool. 
But not everyone thinks that way. Some folks don't want to be 
responsible. Some people don't want problems like that interfering with 
their priorities. Some folks (John Gilmore at hoptoad, for instance) 
see it as a violation of their rights... ohwell. But I'm all for a 
well-run blackhole setup, even when it makes my life inconvenient. 
Especially then, actually.
> (There's really a more basic system design problem: software is 
> distributed that can be predicted to become obsolete or dangerous.  
> That software does not include any automated mechanism for checking 
> for new versions - that's left up to the initiative of the operator.  
> Sure, lambaste the stupid operators - that doesn't solve the overall 
> problem nor their problem.) (All in parentheses because it's 
> parenthetical.)
(you mean, like apple does for MacOS X? but even then, there are 
issues. If you're running a production server, you're frankly an idiot 
to let a vendor or a software tool decide what gets upgraded and when. 
Small systems? sure. but larger organizations need to know what's going 
to break, and what won't, which means some time testing and evaluating 
on non-production hardware. And in many environments, those machines 
CAN'T talk to the update service because of firewall restrictions. 
Which is a feature. What works fine for some enviornments is a bad idea 
for others. Ultimately, if it's a server, the people who operate that 
server need to make the decisions about what to upgrade, and when, 
because there are going to be dependencies that only those people will 
understand and be able to make decisions about. Imagine the fun, for 
instance, of installing an OS patch that breaks a system that's being 
depended on for quarter-end financial processing, at quarter-end. The 
real world stops here.. Again, I think this is a minor case of "the 
entire world isn't like where you're at" -- I live in so many 
environments these days, and I deal with people in so many environments 
on a global basis, that I've had this driven into my skull with red hot 
pokers through the eye sockets. Since my group has just finished up a 
project involving dealing with e-mail and <mumble> languages, and is 
starting to work on extensions to properly support some other stuff I 
can't talk about, I've gotten very aware of the joy of dealing with 
international e-mail. Last I looked, about the only place I don't have 
at least a fingernail in is the space station; I even have subscribers 
to one list down in Antartica....)
> For the reasons you mention they won't upgrade.  I advocate an 
> anti-spam action that does nothing to help these people but that does 
> reduce their overall effect - dilute the pool of open relays 
> sufficiently with fakes and the real ones tend to no longer matter.
The problem iwth that is that, well, spammers aren't dumb. I was 
suprised at how quickly the spammer found my open relay. I was even 
MORE suprised at how reactive he was to my taking it down and bringing 
it up. (twice; I didn't fix it quite right the first time. grump), and 
then again the third time, once it was really fixed but acting as a 
byte bag to him. And then how quickly he figured it out and went away 
again. Honeypots are a useful tool here, but the smart spammers already 
have them figured out, and it seems every "N"th message is a test to 
make sure the relay isn't honeypotting. stupid spammers fall for them, 
of course, but this is an arms race. stupid spammers buy smarter tools 
over time.
But basically, you're right. I was having that discussion with a friend 
(also on this list) offline. Effective tools in scope for this group 
have to be either client-based, or receiving-server-based. You have to 
clean up your own yard before you can complain about the rusting cars 
in the neighborhood, and don't expect them to be removed until the city 
shows up with a tow truck (and frankly, we're living in a city that 
doesn't tow beaters -- who has the right to say "you stop that!" and 
make it work? Basically, nobody does. that was the ultimate failure of 
USENET: rules require either cooperation or policemen, and if you have 
neither?)
So, to me, if it requires server-side change, it's a non-starter, 
unless someone can tell me the major ISPs are on board. Until they are, 
anything to be done, has to be done at the receiving end, which WE 
control, and through education and encouragment, can evangelize out to 
the rest of the net. And that, to me, means better whitelisting, better 
blacklisting, better filtering, honeypotting tools, and the like. Most 
organizations are going to wait and see how they work on a small scale 
before committing to implement them into larger situations -- and that 
includes ISPs. And can you blame them? An infrastructure change to 
Earthlink can cost them tens of millions of dollars to implement; for 
AOL, much more. They aren't going to do what isn't proven. So it's 
going to have to be proven by the smaller users first, and that means, 
it can't be a solution that requires ISP buy-in up front.
>  The validity of the approach can be seen by logic.  Success of this 
> approach does require a number of fakes equal to or much greater than 
> the number of true open relays (the exact number depends on spammer 
> behavior.)  That number is attainable.
And the honey pot has to continue to work once spammers implement their 
"test every N'th email to make sure the relay is still working" code 
widely. Once honeypots become common, so will anti-honeypot technology. 
And I think honeypots are easier to work around than they are to 
protect from spammers hunting them; their greatest advantage now is 
they're rare enough that most spammers probably aren't worrying about 
them much yet.
So if you have a honey pot, how do you make it tempting to a spammer 
who's going to test that ti's working, while still make it effective as 
a honeypot? Assume, for instance, that the spammer has, say, 50 AOL 
accounts, 100 hotmail accounts, and 100 MSN accounts, all of which 
forward to his real hideaway, and he tests a honeypot by sending every 
rand(5000) email to one of his own tester addresses and validates it 
gets delivered. If too many disappear, he shuts down use of the address 
and goes elsewhere....

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg