[Asrg] Software bashing [mostly OT, but on at the end]

[Franck Martin]

This seems an interesting thread and an interesting way of fighting spam.

Can we get more info and stats on the correlation of spam and fingerprinting of the OS?

We are a research group after all.

Now what happens to all the small businesses that use MS-Exchange to send email?

----- Original Message -----
From: "SM" <sm at resistor.net>
To: "Anti-Spam Research Group - IRTF" <asrg at irtf.org>
Sent: Friday, 23 January, 2009 8:00:24 PM (GMT+1200) Auto-Detected
Subject: Re: [Asrg] Software bashing [mostly OT, but on at the end]

At 20:54 22-01-2009, Rich Kulawiec wrote:
>But don't take my word for it: run the experiment yourself.  Turn on
>passive OS fingerprinting in your perimeter devices (or on your servers)
>and correlate that data with:
>
>         - spam attempts
>         - ssh attempts
>         - ftp attempts
>         - pop/imap attempts
>         - port scans
>         - crafted packet attacks
>         - http-based exploit attempts
>         - DoS attacks
>         - etc.
>
>After a year or two, I think you'll find is what I've found after running
>this experiment in multiple environments of different sizes, characteristics,
>purposes, etc.: the abuse problem is largely (in some cases, almost
>exclusively) a Microsoft Windows problem. [1]  And it's clear that
>the correlation far exceeds the population percentage, either as-observed
>or as-guesstimated.  (Some of my sensors have gone for months without
>detecting a non-Windows-originated ssh attempt, for instance.)

I'm commenting on the spam attempts only as I've been running an 
experiment on that since several years.  In general, most of the SMTP 
sessions from Windows hosts are spam attempts.  Passive OS 
Fingerprinting in combination with other heuristics can be quite 
effective in detecting spam attempts.

>As a result, it's long since become part of my anti-spam and overall
>security strategy to consider anything originating on a Windows system
>as "suspect", at best, and to subject such traffic to (a) rate-limiting
>(b) refusal (c) higher scrutiny and/or (d) modified services.  I highly
>recommend this approach for anybody with the facilities to use it:
>the results are striking.

Such a strategy doesn't work well in some environments where there is 
a higher proportion of valid messages from Windows-based mail 
servers.  Some people might need an exception list if they implement 
the above methods.