Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Echo

  • From: Karsten W. Rohrbach
  • Date: Fri Aug 16 21:50:57 2002

Brad Knowles(brad.knowles@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@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

Attachment: pgp00014.pgp
Description: PGP signature




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.