Re: [Exim] error response rate limiting vs. overloaded syste…

Top Pagina
Delete this message
Reply to this message
Auteur: Jerry Jorgenson
Datum:  
Aan: exim-users
Onderwerp: Re: [Exim] error response rate limiting vs. overloaded systems
Oops, accidentally sent this to Avleen rather than the ML.

Jerry

On Sun, 6 Jul 2003 07:14:51 -0700
Avleen Vig <lists-exim@???> wrote:

> Not really, as I state later, your application can only open a set
> number of connections. The number is set by the administrator based on
> the load the server is able to handly.


Unfortunately, there is a finite number of connections the server can
take, and while this might have some merit if you set TIME_WAIT to zero,
so that it would drop the connection immediately, you can't actually do
that because you'll dump all the valid connections as well.

>
> You argument boils down to "Keep a connection open for an abnormally
> long period of time before returning an error, and just leave the
> connection idle so it doesn't take up resources".


Idle connections take up resources: 1 slot in the TCP stack per
connection. Most systems that I know about don't have an infinite TCP
stack. But if you know of one please post it.

> Thus, if you rate limit is 10s, and in 10s you recieve 100 connections
> which recieve one error or another, and the maximum simultanious
> connections you accept is 5, you're choked.
> (these numbers are of course hypothetical).


Absolutely.

> You *cannot* accept more than your predefined number of connections. And
> if on of those connections gets rate limited, it still takes up a slot
> that a new connection cannot.
>
> This is all true unless you're talking about Exim dynamically being able
> to adjust the maximum number of connections it can take (eg, increasing
> by one each time an oold connection is rate limited), but that has its
> own serious issues.


And is still subject to O/S limits.

> > > Spammers appreciate that most ISP's, and even a number of
> > > businesses, now employ the use of connection rate limiting (in one
> > > form or another). He finds limits at which he can slam your servers
> > > from one of many drones around the world until either his list of
> > > recipients is exhausted, or your servers block him. He will open up
> > > as many connections as possible.


Example: One spammer using 6000 separate ip-addresses in one minute.

> > While this may be true of some spammers it is not generally true and
> > it is especially not true of broken client software which has been the
> > most noticable cause of problems in my experience with both ISPs and
> > corporate networks.
>
> It most certainly is true of spammers from my vantage point.


If I only had to deal with broken MTA's the world would be a wonderful
place.

> > Nope, you've failed to note that adding capacity doesn't mean you also
> > give it away under the control of third parties. The goal of DoS
> > protection mechanisms is to have control over your resources and to
> > not give that control to third parties. Like I said: Pay a little,
> > save a lot.
>
> No, by adding more capacity you're pushing back the problem by being
> able to accept more connections, until the volume of mails grows again.
> Of course you should add more horsepower when your farm actually cannot
> accept connections, but artificially forcing it to is not a good idea
> :-)


DoS protection assumes that one server or a small group of servers is
hitting you numerous times. This is easy to block. This is also not what
sophisticated spammers do.


>
> > > Spammers, through the mass availability of open proxies and relays,
> > > compromised clients, and other things we wish didn't exist, have far
> > > more resources to send our mail, than any one organisation does to
> > > receive (to the best of my knowledge).


This has been my experience. I'll say that Exim helps a great deal in
this.

> >
> > Sure, but that's more or less irrelevant. This part of the problem is
> > solved by identification and denial of authorisation -- i.e. reject
> > their transactions before they can further impact your limited
> > resources.


On a light day (like the 4th), 400 ip-addresses were blocked for a time
period of 24, 72 or 96 hours (there's a formula) in addition to the 30,000
ip-addresses and address ranges that are blocked permanently. Some of the
400 will get placed on the permanent list.

>
> I agree whole heartedly.
>
> > Open proxies and open relays are relatively easily
> > mechanically identified in a completely impartial manner and there are
> > several well maintained lists of them. The important thing here is to
> > realize that when rejecting their connections you really must employ
> > error response rate limiting. This is because many open relays, and
> > most open proxies, are prone to exactly the kind of problem that we
> > started down this thread with -- they will unwittingly hammer on your
> > server if you send them a 5xx response that they don't honour. This
> > only stands to reason because any server that's an open relay is
> > liable to have other implementation bugs as well.
>
> Right, and they'll open up as many simultanious connections as the
> resources on their side permit. If you rate limit one connection, it's
> completely possible that the slow down in traffic is sufficient for
> another thread to fire up. And so all your connections will get used up,
> regardless of how much horsepower you may or may not have left.


Correct, you actually have to have the capacity to filter out these before
they hit the mail servers. It's not fun, of course if it was fun, people
would pay to do it :-)

Ack. More spammers, got to go.

Jerry


--
Jerry Jorgenson
jerry@???
http://www.j3iss.com/