The problem with such "reputation" approaches is that they
cut both ways. Aunt
Gertrude (presumably) HAD a good reputation, BEFORE her
system got infected with
a virus (in fact, spammers and worm authors probably COUNT on
the fact that the
system they're infecting HAD a good reputation; that's part
of what enables
them to wreak the havoc they do).
OK, there is more than one problem to solve.
Thank you for appreciating that fact.
But we have to start somewhere.
Right, but it helps little to start with something where we can SEE the MAJOR
problems and limitations with the approach before we even set off down that
path.
There's this overriding feeling that "we need to do SOMETHING" even if that
'something' is stupid and ill-considered. Let's do something that makes more
sense, long-term.
How do viruses spread in the first place? Mostly through spam.
I guess that depends on the virus, and your definition of spam. We agree that
spammers often USE viruses and worms to set up their spambot zombie armies;
it's less clear that the spammers themselves actually WROTE those worms (my
guess is that they pay hackers to create them...). As for me, I don't think
I've EVER seen a virus or worm that came here attached to anything that I'd
classify as spam (i.e. with a unsolicited, commercial, advertising-type message
attached to it). So I think it's rather more the OTHER way: viruses and worms
often hijack systems, which are then used to send spam. So probably, IMHO,
it's
more useful to stop the spread of viruses and worms (which my approach will do,
I feel, a pretty good job of) but for which these authentication/reputation/etc
approaches will have little effect on.
So there is a
value in breaking the cycle. If you need a botnet to acquire a botnet then
the problem is limited to the existing botnets and new entrants are
excluded.
SPF and its ilk do basically NOTHING to prevent authenticated, zombie-ized
machines from propagating viruses and worms by E-mail (or spam, for that
matter). They only (and arguably that) prevent (sort of) counterfeiting return
addresses, but even only achieve that with ugly side effects for legitimate
users who need to be able to send mail with their personal E-mail address
through a variety of (sometimes unexpected) outgoing SMTP servers (as in the
case of the cruise ship Internet cafe).
The fact that it IS infected today (and sending copies of
itself like mad, and
she maybe doesn't even know yet) doesn't make her LEGITIMATE mail she
occasionally is still sending out less legitimate or important.
OK HOW is it sending the spams out?
It could be as simple as telling her copy of Outlook to send them for it.
Only way that is going to work is to
relay through the ISP so that the spams can take account of the ISP
reputation. It is not difficult to implement rate limiting at the ISP level.
That depends on how you're trying to enforce those limitations. For example,
one of my consulting customers recently found that he couldn't send E-mails out
any more (although his wife could send her mails from the same machine). I
proposed that either his domain provider's mail server, i.e.
smtp.hisdomainname.com
was down, or else his DSL provider was choosing to block his attempts to send
mail through smtp.hisdomainname.com. And of course, when he tried to use SMTP
AUTH and use mail.dspcompany.com, they wouldn't authorize his
sale(_at_)hisdomainname(_dot_)com E-mail address. Now, in his case, he was
able to work
things out (with some difficulty and hassle, and a lot of time on the phone...
and this time costs real money, too) with dspcompany.com, at least temporarily,
but these kinds of problems tend to recur (and even become more frequent) as
these companies try to implement these fairly clueless, global kinds of
antispam
barriers.
Antivirus programs generally only trigger on KNOWN exploits
and KNOWN code; so
ALL viruses and worms are at their most virulent and most
dangerous BEFORE
they're detected by ANY of the flock of A-V programs out
there (not even talking
That is not our enerprise config, all executable content is blocked. There
is a small window of vulnerability due to bugs swuch as the JPEG bug but
these are easily fixed through SMS patch updates.
And that's part of the problem. These kinds of barriers are typically used by
ENTERPRISES but they represent the SMALLER percentage of total systems out
there. (And note that these zombie armies can just as easily be used to launch
massive DDOS attacks against enterprises as they can be used to send spam).
DDOS attacks, by their nature, CANNOT be defended against by enterprises (or
anybody else) since by the time they arrive at the enterprise's systems, the
damage has largely already been done. And (like using a magnifying glass to
focus sunlight on a helpless ant) until they arrive at the destination, the
attack is diffuse and essentially harmless, until it arrives focused on the
tiny
spot of the victim.
Ultimately, this is a war that CAN NOT be won at the enterprise level, we MUST
come up with solutions that work for ORDINARY USERS and these are people that
do
NOT run Exchange and do not run these costly enterprise-class "security"
packages.
If we got Microsoft to put something like I propose into ALL copies of Outlook
and Outlook Express, we would take a VERY large chunk out of the global
virus/worm problem, and make a serious dent in the spam problem as well.
Even UNIVERSAL, WORLDWIDE adoption of SPF, SMTP AUTH, and other proposed
"authenticated sender" and other such anti-counterfeiting-of-return-address
approaches wouldn't come even close to achieving the same result... and have
MUCH more serious, unwanted side effects.
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections! http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg