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.
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.
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.
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? 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.
other soft capacity limitings can be done if the rate limiting described above lets through too much, such as deleting queue entries by random when hitting an excessive queue length. when measuring of link latency is done with it, the gpg approach might impose problems, since you need to rely on the outgoing mail timestamp of the echo relay because of variable queue length and gpg processing time.
Yeah, lots of interesting things to think about. Thanks for an interesting discussion! This is turning out to be very educational. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)