North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
- From: Brad Knowles
- Date: Sat Aug 17 18:02:11 2002
At 3:48 AM +0200 2002/08/17, Karsten W. Rohrbach wrote:
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.
...ip source address that is, thought it was obvious.
Assuming you're talking about the transmitting relay (which would
be difficult to fake), this would be some additional protection.
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.
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.
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
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
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.
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.
Yeah, lots of interesting things to think about.
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.
Thanks for an interesting discussion! This is turning out to be
Brad Knowles, <email@example.com>
"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(+++)