Re: TMDA backscatter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Oct 16, 2007, at 5:00 AM, Frank Ellermann wrote:

Douglas Otis wrote:

Do you expect everyone to use inbound servers to send?

No. Of course I'd expect that mail to <postmaster> to the IP of an MTA talking to an MX I care about works. BTW, it would be nice if only the MXs of the envelope sender address talk to other MXs, we could then scrap SPF in this "inherent RMX" parallel universe. Just decree that everybody has an implicit "v=spf1 mx a aaaa -all" policy, what a dream. Actually SPF is a clumsy approximation of this dream.

Requiring MX for discovery eliminates additional transactions needed to assert no policy record or valid email domain. However, the SPF or RMX concept is seriously flawed.

Defining valid sources might scale when done "by-name" but never "by- address". By-Name is how MX records declare destinations. PTR record-sets adjacent to an MX record could associate valid client domains. Perhaps special names like "_NONE" or "_ANY" could be defined for PTRs under a _MX-OUT leaf. DNS would then be able to return addresses needed to validate a specific client host-name within a single transaction, but not for all possible host-names. Being able to validate clients within an authorized source domain should safely satisfy your need for a protection mechanism.

Fully resolving just one MX record for either IPv4 and IPv6 addresses might necessitate 20 DNS transactions when permitting 10 MX targets. SPF allows 10 MX records, where each may contain 10 targets. Unless IPv6 is excluded, subsequent transactions for both A and AAAA records might be needed where a high level of NXDOMAINs would be ignored. This means 10 x (10 + 10) or 200 DNS transactions satisfy SPF semantics for each email-address checked. However, some suggest using SPF to authorize DKIM domains or PRAs first. When DKIM or PRAs are not authorized, it is common to then check MAIL FROM. Each message might therefore invoke 400 DNS transactions per message. Even after allowing this number of transactions, the resulting list may not encompass the addresses of all valid outbound hosts.

Use of MX records are normally predicated upon the sending of messages.

Yes, I proposed a simplification of your DNS attack scenario based on "call back verification" instead of SPF. AFAIK "CBV" works by connecting to an MX of the alleged sender, and trying a RCPT TO the envelope sender address. If that results in "unknown mailbox" the receiver knows that the envelope sender address is dubious at best.

Spammers also know this, that's why they forge "plausible" addresses. An SPF FAIL cuts them off at this stage. As long as there are more than enough unprotected "plausible" (= surviving CBV) addresses the spammers can carry on as is.

See above.

However, overall amplification is much less when a message triggers an automated response.

When I got about 1,000 bogus bounces and other auto-replies per day in 2004 I didn't care about other side effects, my mailbox was almost unusable.

See above.

An automated response is likely to be filtered

Filtering behind a POP3 modem connection is tricky, after all I still wanted to get "good" bounces, challenges, and other auto- replies.

Filtering or rejecting auto-responses before final delivery needs something in the direction of BATV plus good heuristics to identify "non-standard" backscatter (as outlined in RFC 3834).

BATV doesn't directly fight forgeries, it only stops backscatter before final delivery (ideally rejecting it at the MX of the alleged originator). It's a nice scheme, use it if you can. But it won't help me (as receiver) to reject forged "mail from" Douglas Otis.

See above.

SPF permits an enormous amount of DNS traffic to be directed toward an innocent, uninvolved domain.

Well, I'd try something more direct when I'd wish to attack a domain, your idea is IMO far too convoluted.

SPF enables a cached record to redirect the subsequent DNS transactions of a recipient. In addition, SPF provides an attacker the means to manage a sequence of MX records independently from what is seen as the originator.

And your claim that a domain under attack by bogus A or AAAA queries caused by MX records of the attacker, based on CBV, SPF, or what else, has no chance to find out who the attcker is, might be also wrong.

Logs of the DNS and mail servers may provide clues about which domains appear to have staged the attack, but the domain visible to a mail server is able to transition rapidly which prevents any filter from curtailing an ongoing attack.

The querying hosts can find out why they do this, and at that point one or more name servers of the attacker (where he manages the bogus MX records) are also known.

Finding one of perhaps hundreds of DNS servers used by an attacker will not offer a meaningful defence. The ability to redirect DNS transactions afforded a cached SPF record ensures an attacker can escape any blocking effort.

Once the attack duration exceeds a recipient's negative caching, no additional resources of the attacker are consumed

BTW, who determines the TTL of NXDOMAIN, can a zone under attack tune this?

The recipient decides. They may follow RFC2308 recommendations which is the lesser of either the SOA MINIMUM field or the SOA TTL. However some experience problems and truncate the duration. Here is a common tip given to Windows users:

"By default these negative entries are cached for 5 mins. But we can tweak the registry to NOT store negative entries at all!"

Even the attacking MX record might be unrelated to any domain found within the message.

They're referenced by mx-mechanisms in the SPF policy of the envelope sender, i.e. the attacker. And this SPF policy record still exists at least in the DNS cache of the receivers. FWIW, the querying hosts can find out what's going on.

How long will these records remain? A single cached SPF record can do untold damage with its ability to redirect recipient transactions. Rapidly changing these records will not consume much of an attackers resources. Attackers are extremely adept at fast- fluxing DNS. It is not 2004 any more.

Expect spammers to take advantage of this generous SPF gift.

Don't confuse "spammers" and "attackers". This might be the same persons, but the roles are very different. Spammers in their role as spammer might wish to attack successful anti-spammers, but they have no reason to prefer your attack strategy based on SPF where they'd be forced to risk one of their own name servers. I think all attackers prefer to risk more anonymous resources like zombies.

Why do you think there is a difference between a zombie and a name server? Why shouldn't a spammer offer an attacking service when it will not impact their spamming service?

RFC3464 represents a far better solution as it removes incentives.

No, that's not true. When my addresses were abused it was the number of bogus DSNs and other auto-replies that bothered me most, not the size of the DSNs.

RFC3464 removes incentives which affords greater protection at much smaller costs. SPF is not the only tool available!

And the incentive isn't to send spam indirectly in the form of a DSN to the forged envelope sender, the incentive is to abuse an unprotected "plausible" address. SPF FAIL offers the protection.

Despite intentions, SPF creates a far graver danger.

Call back verification is not part of RFC2821?

True, but I was talking about abusing CBV for an MX attack instead of SPF's mx-mechanism, and you then hinted that normal RFC 2821 sending strategies won't query for addresses of all names found in the MX records at once. Actually I don't know what real MTAs do if they get NXDOMAIN, do they wait before they try the next name ?

Regardless, it should not happen more than the number of targets contained within a single MX record. This attack would also incur the message and MX record overhead. While a concern, it is not in the same league.

Other solutions are able to prevent the DATA phase for spam. : )

Whatever it might be, it didn't work for me back in 2004. Victims of backscatter can't wait for worldwide adoption of MTAMARK, CSV, or "other solutions", they need something working now. SPF works as designed because it's in the best interest of spammers to stay away from FAIL-protected addresses.

The same could have been said about the use of DDT as a pesticide. This attitude will likely require banning SPF before its use can be irradiated. : (

-Doug






_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]