Author: Ron Date: To: exim-users Subject: Re: [Exim] hole in message_size_limit? (was: verify = header_sender ...)
On Tue, Jul 20, 2004 at 09:33:13AM +0100, Philip Hazel wrote: > On Tue, 20 Jul 2004, Ron wrote:
>
> > if I do not, what stops someone from eating up smtp_accept_max
> > connections more or less permanently in this way?
>
> Nothing. (Except smtp_accept_reserve.) A malhost (sic) can connect and
> send you 1 byte every timeout period and thereby tie up connections for a
> very long time (well below $message_size_limit). If you offer *any*
> public service, you are always open to DOS attacks. I think this is
> somewhat fundamental, irrespective of the actual service (applied to
> non-electronic services too).
Exactly, which is why I came to believe we probably need both a size clamp
and a maximum time window for DATA to complete within. (or at least will
if these sort of attacks really become a problem)
You can't prevent people attempting a dos, but you can limit their
success by detecting them early and controlling the resources they
can consume.
That aim does seem to conflict with the protocol spec though which makes
this tougher...
> > Now that I think about it though, in addition, does exim4 have any way
> > that I can protect a server from a 'mad' teergrube host on the net, or
> > do we need an equivalent of message_size_limit for outgoing messages
> > too?
>
> message_size_limit applies to all messages handled by Exim. It has no
> inbuilt concept of incoming and outgoing.
Ok. In 14.23 it mostly talks about incoming messages, though it was clear
that as a transport option it applies to outgoing messages. It might be
mentioned elsewhere already but the docs for the global option would benefit
from a slightly more explicit note about this too then.
I think I badly worded that question though, the defence against a mad
teergrube again would appear not to involve quantity of data so much as
clamping how long someone can hold a seemingly active connection open
while allegedly processing a single message. We presently time out for
inactivity, but not for 'loitering'.
> > Finally, I also haven't confirmed what actually will happen if I were
> > to send an enormous amount of DATA to some exim process, I don't know
> > offhand where it puts it
>
> After the size limit has been exceeded, it discards it.
Cool. So the only real issues are traffic congestion (smtp permits
arbitrary 'uploads' with no mechanism for capping them), and plain
vanilla dos (tie up the resources for as long as possible, many brands
available).
Would it be feasible to generate some sort of event at that point,
or process an acl that might decide what to do with the message?
(like acl_check_data but called for the still incomplete message
before deciding how to proceed)
From my black box probing, exim4 seems basically immune to excess data
and long delays at all stages except during DATA transfer, or at least
can be configured to be so. (you could probably still get a pretty long
delay if you start slow from E ... H ... though)
Some carefully placed new timeout limits and something like the acl
described above for oversize messages would probably about cover what
I see we could reasonably do here. Someone may suggest a better way
to implement the same result though.
