BCP38 thread 93,871,738,435 + SPF
ge at linuxbox.org
Sun Oct 29 15:40:25 UTC 2006
On Sun, 29 Oct 2006, Douglas Otis wrote:
> On Sat, 2006-10-28 at 00:52 -0500, Gadi Evron wrote:
> > If you believe SPF prevents you from doing it, can you elaborate how?
> Spam referencing malicious SPF scripts can result in PASS or NEUTRAL,
> where the message and message rates may be normal. Recipients will not
> notice the role they are playing in an ongoing attack. There would be
> few clues, and BCP38 or ACLs will not prevent an SPF attack.
> >From a victim's perspective, there could be tens or hundreds of
> thousands of attack sources. No source represents an address of a
> Botnet. An attack could be composed of A-record transactions for hosts
> not seen in any message, or related to the domains of any SPF script.
> These SPF scripts might also later morph to frustrate forensic analysis
> or real-time blocking.
> SPF scripts add indirection from what is within a message. An attacking
> transaction would pass through DNS from one of the hundred thousand
> recipients. Finding a recipient will not link a DNS transaction to a
> message. The source of the message may also be a reputable provider.
> The recipient would need to trace the targets of all associated SPF
> scripts. A particular SPF script might be one of a hundred other
> scripts targeting the same victim, however. Analysis designed not to
> add to an attack can also be seen by the attacker.
> Nothing in the experimental SPF or Sender-ID RFCs explain how such
> catastrophic attacks are avoided. Their recommended premature
> termination of SPF scripts ensures there is no congestion avoidance as
> How would you identify and quell an SPF attack in progress?
Okay, now I understand.
You speak of an attack specfically utilizing SPF, not of how SPF relates
to botnets or attack traceback.
The same could be said for web servers, databases behind them, DNS-SEC
crypto calculations, etc.
More information about the NANOG