[linux-elitists] web server software for tarpitting?

Karsten M. Self karsten@linuxmafia.com
Sat Feb 23 18:15:11 PST 2008


on Sat, Feb 23, 2008 at 08:59:02AM -0800, Don Marti (dmarti@zgp.org) wrote:
> begin kermit tensmeyer quotation of Thu, Feb 21, 2008 at 12:05:08AM +0000:

Your attribution's missing a space, Don.
 
> >   the solutions are to fix the standards, and then focus on allowing 
> > software to match the standards. DTD validation has been around for a 
> > long time. Quick fixes  will generate other problems that can be worse 
> > than the problem it was intended to fix
> 
> Already fixed at the HTTP level.  Caching the DTD until it expires is
> the only approach that's consistent with both the HTTP standard and
> the unwritten HTTP client rule of not being a dick to the people who
> run the HTTP server.

Requires compliance in *every* client using the protocol.  Or at least
sufficiently many that the "I'm with Dick" population can't
significantly affect the W3C's Web infrastructure.  In Gartner terms:
P=0.

> Already-deployed corporate software gets fixed only
> if someone with budget authority complains, or if
> there's a credible legal threat.
> 
> Remember the great Wisconsin NTP DoS of 2003?
>   http://pages.cs.wisc.edu/~plonka/netgear-sntp/
>   http://pages.cs.wisc.edu/~plonka/netgear-sntp/#ToC44
> 
> This situation seems different because it's not one badly designed
> product, but zillions of in-house programs.  In this case, the only
> way I can see to make someone complain is to slow down the software.
> The developer who's ordered to make the fix wouldn't even have to know
> about the policy.

That ... smells bad to me.  "Never cache" and "always cache" both lead
to problems.  You're still dealing with compliance issues.  And
tarpitting (in the email sense) works largely on the basis that it both
solves the local problem (the tarpitting email-recipient server gets
less spam) and he general problem (lots of tarpitting servers (we hope)
start to create socket / TCP starvation on the spam sender(s).  Though
likelihood of this in an age of botnets seems ... low.
 
> It seems like the most obvious fix would be for HTTP client libraries
> to cache where possible by default, and make the programmer turn off
> the cache if he or she really didn't want it.

I still smell a protocol mismatch.

Short term fix:  band-aide a solution with rate-limiting (what the
proposed tarpitting solution really is), tattling, caching,
infrastructure enhancement, and outreach to dev tools providers (e.g.:
major scripting languages, business back-end tools (Java, J2EE, etc.),
and Microsoft (multiple sins) to improve future products where specific
faults are determined.  In future:  switch to, or create, a protocol
which more closely fits the needs and goals of DTD distribution.  I like
the outline I provided earlier:  DNS + singerprinting + PKI.  I've been
guilty of worse sins.


Peace.

-- 
Karsten M. Self <karsten@linuxmafia.com>        http://linuxmafia.com/~karsten
    Ceterum censeo, Caldera delenda est.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20080223/7f471398/attachment.pgp 


More information about the linux-elitists mailing list