On 4 Mar 2004 at 10:26, Alan J. Flavell wrote about
"Re: [Exim] Re: Bagle, unqualified H":
| On Wed, 3 Mar 2004, Fred Viles wrote:
|
| > This raises an interesting point. RFC2821 says a 5 minute timeout is
| > a SHOULD, not a MUST. It turns out that at least one legitimate MTA
| > (Mercury/32) does not wait that long. With a 90 second delay
| > introduced, it gave up trying to send.
| >
| > I've just had an interesting conversation with Mercury/32's author,
| > David Harris, about the wisdom of following the RFC timeout
| > recommendations. He pointed out that waiting five minutes for
| > commands from a sender exposes a receiving MTA to a trivial DDoS
| > attack,
|
| I'm not sure that I agree. If an MTA is so easy to compromise with a
| DDoS attack, then consider senarios such as this, assuming that the
| receiving MTA is applying even minimal checks to the incoming calls:
|
| 1. establish multiple calls from IP(s) whose DNS lookup results in a
| timeout.
Multiple connections from the same IP can be controlled with
smtp_max_per_host. PTR lookups are also optional, fot that matter.
And I would think it would not be all that easy for an attacker to
arrange for his thousands of zombie machines to all have unresponsive
DNS servers.
| 2. assuming that exim's "verify = sender" or equivalent is used (no
| callout required!), offer envelope sender address(es) which result in
| DNS timeouts.
Yes, that would work.
| - and so on. One or more of these strategies will delay the receiving
| MTA for perhaps a minute or so. If it can't cope with that, you have
| your DDoS already.
So your point is that as long as any DDoS vulnerability exists, it
doesn't matter how many of them there are?
| > with no practical benefit.
|
| I have to say that shrugging off a nontrivial fraction of spam and, it
| now seems, viruses too, seems to me like a "practical benefit".
I have apparently not made myself clear.
The timeouts that carry the DDos risk without a corresponding benefit
are not the ones your trick takes advantage of. They are the
timeouts on a receiving server waiting for a next command from a
sending server. For example, waiting for HELO, MAIL, RCPT, etc.
Your introduced delays depend on RFC compliant timeouts on a sending
server waiting for *responses* to RCPT commands from a receiving
server.
|...
- Fred
