North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
- From: Karsten W. Rohrbach
- Date: Sat Aug 17 19:10:35 2002
Brad Knowles(email@example.com)@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
> > 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
|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.
> "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
Description: PGP signature