[Mailman-Developers] Interesting study -- spam on postedaddresses...
John Morton
jwm@plain.co.nz
Fri, 22 Feb 2002 14:25:07 +1300
On Friday 22 February 2002 11:20, Chuq Von Rospach wrote:
> On 2/21/02 2:00 PM, "John Morton" <jwm@plain.co.nz> wrote:
> > I think we're really getting into wild speculation territory here. No one
> > will bother hacking the code to automatically get new free mail accounts
> > [...]
>
> Nobody has bothered to do this YET. That we know of. But the spamhacks are
> evolving rapidly.
Well, let's find out shall we? Set up a honeypot private list containing a
collection of free mail accounts, then cycle through the account every week
checking for spam and making some postings to keep the traffic up. Enough
with the armchair anthropology, already!
> More rapidly than the anti-spam hacks in many ways. I
> sure wouldn't depend on them never doing this.
I agree. That's because we're in an arms race here. Email harvesters are
probably evolving faster than the countermeasures because of the tendency to
deploy one countermeasure and forget about it.
> I'm not sure what we'd do if
> they did, either, but some aspects of it have happened to me in small ways,
> just not from the major spamhacks.
So basically you need to deploy a countermeasure, monitor it's effectiveness,
and deploy another when it fails. Repeat for as long as you consider it
important, or can tolerate not resorting to private archives, and
establishing better trust relationships with the subscribers.
> Fact is, if they want your subscribers, they can get them. Or more
> correctly, your subscribers that post -- but if everyone lurks in fear, why
> hav a mail list?
I think we all need to take a deep breath and say 'It's only junkmail'.
They're not spending up large on your credit card or pouring sugar into your
gas tank.
> The question is, what can we do to make it as tough as we
> can for the spammers, without screwing it up for us (as admins) or our list
> users. If only because the harder we make it for them to hack us, they more
> likely they'll go somewhere else that's easier to crack...
Right. So let's go with contact forms for list admins, and slashdot style,
per user configurable address mangling for the archives. Let's do a little
research into the ongoing effectiveness of these methods, too, so we know
when it's time to implement something more expensive.
> On the other hand, if Mailman does become the de-factor mail list standard,
> or one of a couple of key list servers, you can bet the spam ahcks will
> focus on it, because if they can crack the code, they can crack a LOT of
> lists really fast. So we have the potential to become a target of our
> success, and we should be aware of that.
It's probably one of the top three or four already. Do listserv and majordomo
admins have a major spam problem?
The two above techniques will work fine. If I, as a list subscriber feel that
the signal to noise ratio is dropping, I can change my address mangling
scheme. Hiding the otherwise web published list admin address behind a form
should just about protect it by that vector for all time as it will just
never be worthwhile hitting a collection of forms when you can get vast lists
of addresses elsewhere.
(of course you have to publish the mailing list address, so you can deduce
the admin address from that...:-)
> But what happens when other groups get smart too, and clean up the low
> hanging fruit? Depending on that to protect us is a false security,
> basically no better than the old security-by-obscurity issue. Given port
> scanners and the like, there IS no obscurity from the crackers any more.
The problem with obscurity as a security tool is that it's not reliable. You
may as well assume that one day your secret will be out, so the decision as
to where and how to deploy it needs to be made based on the cost of
obscuring, the cost of having the information revealed, the cost of
reimplementing the system to replace the obscured part, and the size of the
window of opportunity created before you can fix the problem.
Passwords, passphrases, keys and so forth are all examples of security
through obscurity. They work because it's very easy to replace them; they
work most effectively in systems that are good at detecting that they've been
compromised. Striping identity strings from network daemons is another
security through obscurity technique. No one would rely on it to protect
them, but it does make the job harder for attackers and easier for the
defenders - they have to try a lot more things to detect what software is
behind the port, or just brute force it with known attacks, greatly
increasing the detection and response time available to defenders.
Obscurity is useful. In our case, it's the only prevention tool we have.
Email addresses are not secrets, but we still want to protect them from the
bad guys while making them available to the good guys. We will never solve
this problem. Even if you made all the subscribers sign a contract promising
not reveal the addresses of the list membership to non-subscribers, and had
reason to trust that they where not spammers. Someone could always go over to
the dark side. An outlook virus could alway be used as the spam vector. And
so on.
The best we can do here is implement something simple now that gets the job
done, and continuously test it to see if it's still good enough. When it's
not, we build another countermeasure.
John