Echo

Sat Aug 17 01:48:45 UTC 2002

Brad Knowles(brad.knowles at skynet.be)@2002.08.16 22:27:08 +0000:
> At 9:43 PM +0200 2002/08/16, Karsten W. Rohrbach wrote:
> 
> >  Brad Knowles(brad.knowles at skynet.be)@2002.08.16 19:48:10 +0000:
> >>  	What kinds of anti-abuse protection methods have people used for
> >>  "echo" accounts that they have set up?
> >
> >  - scoreboard: one mail from one source addres in one minute time window
> 
> 	Yeah, but then abusers could easily generate elephantine 
> quantities of messages, simply by randomly generating return 
> addresses (if they wanted to DoS you or your network), or by randomly 
> generating the user portion of return addresses (if they wanted to 
> abuse you to DoS someone else).  If they know that there are multiple 
> domains handled by the same servers, they could randomly generate 
> addresses within that set of domains.

...ip source address that is, thought it was obvious. a very logical
algorithm would be ``n source ip adresses per /16 per minute'' which
would catch at least the badly distributed DDoS attacks and does not
impose large processing overhead in cycles and memory, i think.

i don't think that an echo service would be this popular that it
needs to process very many messages for the same /16 in a short period
of time.

> 
> >  - gnupg: mail needs to be signed to fire a return mail. key of the
> >    signer must belong to the robot's gpg trust web.
> 
> 	Ooh, so in order to use the echo server, they have to send a PGP 
> signed message?  Wow, that's pretty expensive.  That sounds like a 
> really excellent way to DoS your server.

it was just a quick idea. but queueing and (rapidly) scheduled weedouts
of those queues are nothing new, when you guard services with gpg/pgp.
other soft capacity limitings can be done if the rate limiting
described above lets through too much, such as deleting queue entries by
random when hitting an excessive queue length. when measuring of link
latency is done with it, the gpg approach might impose problems, since
you need to rely on the outgoing mail timestamp of the echo relay
because of variable queue length and gpg processing time.

> 
> 	Thanks for sharing!
> 

you're welcome.

/k
-- 
WebMonster Community Project -- Reliable and quick since 1998 -- All on BSD
http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/
GnuPG:   0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4  A113 B393 6BF4 DEC9 48A6
REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE  DF22 3340 4F4E 2964 BF46
REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C  5F 0B E0 6B 4D CD 8C 44
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 10x
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20020817/efee5c92/attachment.sig>