Hi David,
yes, I completely understand your point, but I fear you missed
mine due to my tongue in cheek 'worst case' scenario.
Nothing at my gateway can stop people frivolously sending me
traffic that gets that far. Ack Rst.
exim4 however currently permits the script-kid-dosser equivalent
of a 'teergrube' attack.
Anyone can connect to a public exim, begin a legitimate looking
message transfer, then (apparently) so long as they send a line
of DATA within every $timeout seconds, hold the connection open
and send data until the end of eternity, irrespective of
advertised SIZE.
Unless I'm mistaken, nothing that I can configure at runtime will
stop it from doing this, and it will not report this to me in any
obvious way (though I'm sure I could find out if I thought to look
for such a thing, perhaps by some indirect means though).
It seems logical to me that message_size_limit should clip the
transmission of incoming messages that will certainly be refused at
the next stage of processing. I haven't looked at the code to see
what this would take to implement, so I'm speaking purely from
userland when I say 'seems logical'.
To address the question implicit in your examples, port 1234 will
get bounced by my firewall unless its a related connection, so yes
it will make my isp rich, but (more importantly) it won't consume
resources on my service hosts. Any such 'attack' that can be dropped
with limited resource usage can be logged and quickly blackholed with
limited impact.
The difference with exim is that if (ab)used (in)correctly, it deadlocks
the door open -- to answer that by configuring my firewall to rudely slam
a connection to port 25 shut after some particular time or traffic volume
has passed does not seem like the best answer here. On the other hand,
if I do not, what stops someone from eating up smtp_accept_max
connections more or less permanently in this way?
Sorry if I was unclear initially, does this seem like something that
will be troublesome to implement, or do you (still) have some other
objection to this type of change? (like it directly contravenes some
part of a relevant rfc... in which case I'd hope it were still optional
until the rfc was suitably repaired)
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? It's probably worth thinking about how to respond once people
start misconfiguring these things all about the place...
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 during that time and what will happen when it
finally fills up... At this stage I just know that it will let you keep
filling it up until you say you are done, even if its now going to 552
once you do. smtp commands issued prior to DATA appear to already be
limited in the number of bytes that constitute a valid command, so I
assume DATA is likewise hard limited to some large number. (guess1:
50Mb <? available heap )
If it is immune to overflow attack, then two issues remain. A
connection can be flooded with large amounts of junk traffic that is
not detected until very late (bad qos for legitimate traffic), and a
connection can be kept open indefinitely (even if max size is limited),
by very very slowly sending DATA (bad if it eats up all available
connections without timing any out).
Being able to cap both these things under admin control seems wise.
Anyway, I'm about to hit send and describe this in words of more or less
two syllables on a public list, so I hope I'm wrong somewhere along the
line about certain parts of this, or that it is going to be easy to amend...
If I'm wrong about significant things, a pointer to the relevant
references would be very welcome.
best,
Ron
(and yes, if I was worried that you really could do bad things to the
machines on the IP's my last email came through then I'd have forged
my mail to have appeared from somewhere else, but you might also notice
that exim is not listening on the host you mentioned yet either --
I'd like it to be though which is why I'm looking at it in greater
than usual depth ;-)
On Mon, Jul 19, 2004 at 03:31:16PM -0400, David S. Madole wrote:
> > From: "Ron" <ron@???>
> >
> > Not that I think my telco really _would_ open a connection to
> > my mailserver and simply send random bytes to it for as long as
> > they could, but backwater legislation means it _could_ earn them
> > up to 35c/Mb to do so...
>
> What makes you think that anyone needs to open a connection to send you
> random bytes?
>
> Or that you need to "accept" them in any way or that you can prevent them
> from being sent any way?
>
> cat /dev/random | nc -u someipaddress 1234
>
> or a million other ways.
>
> David
>
>
