Re: TMDA backscatter

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

 




On Oct 15, 2007, at 5:51 AM, Frank Ellermann wrote:

Douglas Otis wrote:

By using the local-part in a spam campaign, one cached SPF record is able to reference an unlimited sequence of MX records.

In theory IANA could publish one _spf.arpa "v=spf1 mx a aaaa -all" record, and everybody could use it with "v=spf1 redirect=_spf.arpa". That one SPF record can (kind of) reference an unlimited number of MX records doesn't depend on SPF's local-part macro.

This adds perhaps 21 useless DNS transactions for each email received? Do you expect everyone to use inbound servers to send?

And e-mail providers wishing to offer "per user policies" could also create corresponding subdomains replacing local@xxxxxxxxxxxxxx addresses by say user@xxxxxxxxxxxxxxxxxxxx addresses. Likewise attackers trying to cause havoc can use user@xxxxxxxxxxxxxxxxxxxx addresses, they don't need SPF's local part macro for this purpose.

After all in your attack scenario it's the attacker who controls the MX records pointing to bogus addresses in the zone of the victim.

Use of MX records are normally predicated upon the sending of messages. When sending a message, MX records may have a potential DNS traffic amplification of about 10. However, overall amplification is much less when a message triggers an automated response. An automated response is likely to be filtered, and the sender risks being blocked, whether or not the MX record is doing something nefarious. Many situations can achieve this level of network amplification.

However, SPF's macros transforms a spam related attack into being completely free without tainting the messages. Sending spam should be considered a given as it represents a large portion of today's traffic. SPF permits an enormous amount of DNS traffic to be directed toward an innocent, uninvolved domain. Once the attack duration exceeds a recipient's negative caching, no additional resources of the attacker are consumed! The attack can come from anywhere, is not easily traced, and, beyond universal banning of SPF records, there is no defence! ACLs on DNS will not help, nor will BCP 38. This attack is likely to continue for a long duration.

Spammers often send messages continuously. A spam campaign can come from any source, purport to be from any domain, and yet attack the same innocent victim which can not be identified by examining the message.

Your attack scenario has nothing to with a spam campaign, the goal of a spam campaign is to send unsolicited mails to receivers. The goal of your attack scenario is to flood a zone with bogus and huge A or AAAA queries. And in your scenario the mail cannot purport to come from any domain, it has to come from domains under the control of the attacker where he manages his bogus MX records.

SPF adds a layer of indirection. SPF allows the local-part of spam to generate DNS transactions without consuming additional resources of attackers once their SPF record has been cached! The attack can then query any MX, A, AAAA, PTR, and TXT records from any domain unrelated to message content. Even the attacking MX record might be unrelated to any domain found within the message. SPF's added indirection provides spammers a complete disguise. Recipients using SPF are to know which messages are staging an attack. This is true even when they do not wish to play a role in a reported ongoing attack. Expect spammers to take advantage of this generous SPF gift. : (

Compared to an SPF related attack, most auto-replies will consume a greater amount of an attackers resources, identify the source of the attack, and not achieve the same level of amplification.

Backscatter doesn't consume resources of the spammer (apart from sending the UBE with a forged envelope sender address), and it can be "mail from" any "plausible" address, not identifying the real source. That's precisely the problem solved by SPF FAIL and PASS.

RFC3464 represents a far better solution as it removes incentives.

SPF enables a long duration DDoS attack.

Sorry, from my POV you still arrive at "MX records can be abused", not limited to SPF (or rather only limited if done using SPF).

Of course MX records can be abused. SPF increases the potential level of abuse by a factor of 10 or 20. With SPF macro's, abuse also becomes completely free.

Block all SPF records?

At least we won't need a new rfc-ignorant zone to implement this proposal... ;-)

Prevention might require DNS servers be modified to exclude SPF records. Do not expect compliance without some form of blocking imposed.

Maybe you should propose some "MX processing limits" for 2821bis.

Most systems are fairly careful about where they send messages to avoid being blocked, nor would the normal use of MX records require all targets be resolved. Timeouts recommended by RFC2821 ensure this operation remains fairly safe, unlike that for SPF. Even the packet limitation of DNS provides a fairly reasonable limit.

I'm not sure that "call back verification" schemes follow the "sending strategy" (4.5.4.1) in RFC 2821, after all they don't send any DATA.

Call back verification is not part of RFC2821?

You could squeeze quite a lot of names in the reply to an MX query, that's why SPF has an explicit limit 10. SMTP also doesn't specify size limits for MX queries.

DKIM can be processed prior to acceptance

Yes, but unlike SPF not before DATA. I skip the "anti-phishing" discussion because it's not directly related to "backscatter".

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

-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]