North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Echo
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
|