North American Network Operators Group

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

Re: Echo

  • From: Karsten W. Rohrbach
  • Date: Sat Aug 17 19:10:35 2002

Brad Knowles([email protected])@2002.08.17 23:36:49 +0000:
> At 3:48 AM +0200 2002/08/17, Karsten W. Rohrbach wrote:
> 
> >  ...ip source address that is, thought it was obvious.
> 
> 	You mean, the IP address of the machine contacting you, or the IP 
> address of the originating machine?  If the former, keep in mind that 
> many providers host a large number of customers, and you could deny 
> service to a lot of innocent people.  If the latter, then you would 
> be vulnerable to forging.

every machine connecting to an smtp port is a potential transmitting
relay...

> 
> >                                                        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.
> 
> 	Assuming you're talking about the transmitting relay (which would 
> be difficult to fake), this would be some additional protection.

thinking twice about the pseudo algo up there, it would be rotten easy
to DoS the systems for connections from ``well-known'' systems which
might depend on the service (latency measurement, again). one would need
to have a white list for those ip adresses.

> 
> >  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.
> 
> 	Unless someone is trying to DoS your machine.  Heck, they could 
> just generate zillions of SYN packets with random source IP 
> addresses, and that could cause you some significant problems.

syn-cookies, where's the problem?

> 
> >  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.
> 
> 	Cron job every minute?  Would you use a program to pull down the 
> mailbox with POP3 or IMAP or somesuch, or would you directly access & 
> process the mailbox?  Or maybe pre-filter the messages with procmail 
> into seperate mailbox files which could then be further processed by 
> your script?

hmmm, cron job is simple, but intermediate storage of the incoming
mails might pose problems, you're prefectly right...

> 
> 	What do you do if they decide to start sending you a large number 
> of really huge messages?  They could potentially fill up your mailbox 
> space on the disk, even in just a single minute.


deliver to a filter that limits max. size of messages by lines?
then stuff its output in a fifo with a daemon listening on the other
side:
|head -n200 >/var/whereever_not_tmp/echofifo

implement the fifo listener as a small daemon that select()s on the fifo
and processes the mails. 

regards,
/k

-- 
> "Niklaus Wirth has lamented that, whereas Europeans pronounce his name
> correctly (Ni-klows Virt), Americans invariably mangle it into
> (Nick-les Worth).  Which is to say that Europeans call him by name, but
> Americans call him by value."
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: pgp00016.pgp
Description: PGP signature