Echo
Karsten W. Rohrbach
karsten at rohrbach.de
Sat Aug 17 23:08:37 UTC 2002
Brad Knowles(brad.knowles at skynet.be)@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
-------------- 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/20020818/e1d9a98f/attachment.sig>
More information about the NANOG
mailing list