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