[Dshield] Need some help testing

[Tomas L. Byrnes]

I think the approach that was being pioneered by TQMCube, which mirrors
the work @ DShield for attacks, is a far better way of addressing the
"dynamic spam source" (whether zombie or not) problem than RBLing
because something appears to be a dynamic IP address. There are plenty
of innocent dynamic IPs, and the Internet is devalued, and rendered more
fragile and insecure, by requiring that all of everyone's mail traffic
transit a relatively small subset of well known mailhosts.

The idea that TQM used, of having spam traps widely distributed, and
blacklisting CURRENT senders to those traps, with automatic aging when a
source isn't heard from for some period of time, was a very good one.
That would catch the current spammers while eliminating the scorched
earth problem. The only issues are reaction time and dampening, as well
as propagation, but those are solvable. In effect, it is a similar
problem to service load balancing and session persistence.

It's too bad that the project has fallen by the wayside. If David Cary
Hart ever raises his head again, I'll do what I can to help him out.



> -----Original Message-----
> From: list-bounces at lists.dshield.org 
> [mailto:list-bounces at lists.dshield.org] On Behalf Of Mar 
> Matthias Darin
> Sent: Sunday, July 08, 2007 11:50 PM
> To: General DShield Discussion List
> Subject: Re: [Dshield] Need some help testing
> 
> stHello, 
> 
> Tomas L. Byrnes writes: 
> 
> > I am well aware that there are many sites filtering addresses that 
> > they see as "dynamic" using some measure thereof. I am also, 
> > painfully, aware of how often that designation is woefully 
> inaccurate, 
> > and the difficulty with getting it changed.
> > 
> > I have had IPs I am responsible for, which were properly 
> reversed as 
> > static (using one of the methods you decided was "dynamic") 
> by my ISP, 
> > listed as dynamic. In one case, since the ISP controlled the PTR 
> > records, and wouldn't/couldn't change them, since they used 
> those for 
> > troubleshooting and network monitoring purposes, my only 
> option was to 
> > change ISPs. My current ISP, COX business services, will 
> set the PTR 
> > to whatever I say it should be, which I always make the FQDN of the 
> > mail server if there are multiple hosts nated to it.
> > 
> > This wasn't a case of "scorched earth", the IP had never 
> spammed, and 
> > there was a valid PTR, it just happened to be a PTR that 
> nit-picking 
> > pedants decided wasn't good enough.
> > 
> > SPAM is a scourge, but some of the cures being put forth are worse 
> > than the disease.
> 
> I agree completely.  Any tool misused is a problem, which is 
> the point of this thread - to actively find cases of false 
> positives and provide a means to not have them.  I have 8 
> years of research in this based upon experience with local 
> mail systems in my area.  As such, the rules I have developed 
> worked well for said systems.  In attempting to generalize 
> the process, the data has to be extensively verififed. 
> 
> Unforyunately, this whole issue revolves around spam zombies. 
>  Dynamic IP address filtering has proven to be one of the 
> best defenses against such spam.  It saves resources, cuts 
> costs and clearly has a marked improvement in mail server 
> functionality by the work not done by other tools. 
> 
>  --- 
> 
> DynaStop: Stopping spam one dynamic IP address at a time.
> http://tanaya.net/DynaStop/
> _________________________________________
> SANSFIRE 2007 July 25-August 2 in Washington, DC.  56 
> courses, SANS top instructors, and a great tools and 
> solutions expo. Register today!
> http://www.sans.org/info/4651 (brochure code ISC)
>