Re: Spam (or, how to buy Cheap Korean Cellphones :-)

[Paul Robertson <proberts () patriot net>]

On Sat, 7 Feb 2004, Rod Gilchrist wrote:

> > > Anyway, not a huge problem there. That's what smtp authentication
> > > is for. Send your mail via the other domain's smtp proxy (from the
> > > outside)
> > > and have them sign it. In order to do so you need a valid user ID and
> > > password.
> >
> > So, now you're requiring domains that don't normally allow 3rd party
> > relay
> > to enable it to allow their customers to continue to use their primary
> > e-mail domain?
>
> I'm not requiring anything.

Poor choice of words, you're advocating it.

> I'm noting that a protocol that is becoming increasingly popular if not
> widespread, deals pretty effectively with the issue you raised.

Not really- it's not being used in the end-user market, it's being used in
the corporate market.  Once again, in the corporate market, firewalls are
an effective means of controlling hoards of compromised machines (see last
week's thread.)  The ISP market has significantly more challenges in terms
of platforms, software control, versioning, application support and
variance.

Authenticated relays will either be dictionary attackable, or DoSable.
Current implementations don't deal with that, and certainly don't deal
with distributed password guessing attempts.  Once again, I submit that
you fail to take into account hundreds of thousands of already compromised
machines.

Spammers haven't gone widespread[2] after authenticated relays for only
one major reason- it's too easy to send mail without that.  As soon as thaqt
becomes difficult, the spammer only needs to walk their own spam lists to
get addresses to try against the appropriate gateways.  Subscribe to a few
high-volume mailing lists if you want to get the gateways easily, then
send a network of zombies off to try relays 5 at at time per addressee per
zombie.  Suddenly the user's credentials (generally a domain login in a
corporate environment) become valuable currancy and are relatively cheaply
found.

Now, take that to the home user market where the users don't have password
discipline that some percentage of companies do...

> Companies are implementing smtp authentication primarily because
> their people who are traveling want to have the email they send come
> from
> their corporate mail address so that it appears official and doesn't get
> stopped as spam.

Companies aren't, as far as I can tell a significant vector for spam, let
alone repeated spamming.  Corporate users also generally conform to
specific user name requirements which may indeed end up making their
authenticated relays more vulnerable.  We've already seen widespread abuse
of default SASL configurations, and I've yet to see an authentication
protocol that didn't add a bunch of complex and buggy code to something
that's already there- so in terms of overall risk to companies, I think
what you're advocating increases that and doesn't address the home user-
which is where a large portion of the problem lies- and why my points
still stand.

[snip]

> > I'd really rather not replace an exploited infrastructure with an
> > exploitable infrastructure.
>
> I'm of the opinion that a perfect solution is just not going to drop
> into
> our lap.

I *know* a perfect solution isn't going to drop in our lap- I'm not saying
"this solution isn't perfect, so it's not a good solution."  I'm saying
"This solution doesn't address the threat vectors well, other
solutions do- so let's focus on those.  In addition, this solution's
falure modes are not good[3]."

> The only thing that is going to work is bite size partial solutions that
> get deployed. Eventually they'll  become enough of a solution that spam
> will largely be dealt with.
>
> Everything else takes way, way too much debate to get enough of a
> consensus to be useful.

Personal Firewalls don't spark a massive amount of debate, and are
significantly more useful[1], open relay checkers seem to be more useful,
but may indeed not gain consensus.

> In terms of exploited machines inside your net, again this isn't an
> insurmountable problem. Apply a policy on your outbound smtp gateway;
> only so many messages from any one machine before you stop accepting
> mail from it. Reset every 24 hours to allow for the machine being
> reinstalled.

DHCP means that would be trivially surmounted inside a day by spamming
software.  Next thing you know, we're requiring 802.1x everywhere.
Solutions that require us to escallate to new architectures aren't
likely to see enough adoption to be worthwhile.  Solutions that have
signficant usability flaws, or that don't show that the next obvious
escallations render them pretty much useless aren't likely to see enough
adoption to make them worthwhile.

I honestly don't think you've addressed the failure modes.  I honestly
don't think the failure modes for such solutions make it worth the time to
implement.

Anyway, since we seem to not be saying anything essentially different,
we'll just have to agree to disagree.

Paul
[1]  That's why I started www.personalfirewallday.org, it's upstream of
the spam vector, and the failure modes are taken care of for the most part
with option 2 of the three things on the list of things to do.  Between
them, personal firewalls and updated AV take care of each other's failure
modes for say the 80th percentile of issues.
[2] I've worked on incidents where botnets were used to try to brute force
authentication from Web servers, no more than a trivial number of attempts
from each address.  I've seen evidence of SASL abuse, combine the two and
you're where the spammers will go if this happens.
[3] Once you put it all in place in today's environment, it fails too
quickly to the obvious next steps of the attackers and encourages
behaviour which increases overall risk and the trafficing of credentials.
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards