Re: [Exim] Re: Bagle, unqualified HELO, time delays

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Fred Viles
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: Re: [Exim] Re: Bagle, unqualified HELO, time delays
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