Ok, Lets say that you are correct about the DOS. Please explain the possible problem. Given my solution already in place.
1. There is not much diff in you thought then a DOS that would MAX
the incoming concurrent (smtp) connections.
2. My solution for the problem of somebody flooding me with
concurrent (smtp,imp,pop,dns,etc) connections is very simple.
3. I allow X connections ( where X is unique per service ). Connections from a /24.
4. I have iptables logging though a filtered syslog ( to post to sql,
& do stuff, etc).
* <>So when I have X connections in time frame T, From a /24 I drop
the allowed connections from that /24 (using iptables) to N (lets
say 3).
* Thus preventing a flood from any network but still allowing mail
though.
* When the attempted connections drops down to X/2 ( in time frame
of T ) then the restriction Goes Back to the Norm!Given this setup how is it possible to cause a DNS flood of requests? Let alone the other problems this fixes?
Plus this only effects networks that are a concern. This can be done on separate MX servers so if volume is a concern each would do this separately.
I use this bc I run f-prot on all incoming email & that is a system killer. But this has prevented a problem
Topaz M. Bott
James Craig Burley wrote:
On 2004-06-04 01:29:10 -0400, Topaz M. Bott wrote:
James Craig Burley wrote:Irrelevant. SPF doesn't employ a central server, and my DNS cache isn't
Glancing at the ORDB.org nameservers I fail to see how the SPF DNS=20Do they use IP addresses or domain names as keys?
usage can be so intense as to be a problem or a weak link.
large enough for all possible in-addr.arpa. domains.
Again, not the point.
Or, maybe it is: what is your DNS cache hit rate *today*?
What will your DNS cache hit rate be after you expose (via SPF lookups for every incoming email) it to lookups based on arbitrary host names submitted by potentially-hostile SMTP clients?
domain in the world in the DNS. Besides that I don't know about you butRight. And this check is exactly as expensive as an SPF lookup.
I have a check before SPF check that checks to C if the domain exists.
Now you are going to say that checking it C if a domain exist is still
DNS.
It's pretty close. And it's pretty much the same kinda thing that I've been talking about.
But it differs from SPF in two important ways:
- It's easy for spammers to forge existing domains, thus defeating the utility of the check for all except old-school spamware and vermin.
- Having determined that a domain exists via such a lookup, one really hasn't learned anything useful. (The email could still be forged; the site might not even accept bounces!)
Therefore, spammers have little or no incentive to attack this particular exposure: these domain-exists checks are easy to fool and thus don't represent enough of a problem to try to convince sysadmins to disable them.
(And, since they're so easy to fool but do cost upstream DNS caches some amount of resources, lots of sites don't bother doing these checks -- their own local processing catches that sort of spam and vermin without hitting those DNS caches.)
This is where I think James' argumentation falls down. Checking for MX
and A records for the reverse-path domain has been in the standard
configuration of sendmail and other mailers for at least 5 years or so.
True, but some admins disable it for performance reasons, and, as I point out above, spammers have little or no incentive to *attack* these checks -- they can merely forge existing domain names.
James may have turned it off, but I guess most mail-admins haven't and
90+% of all mail servers are performing such checks. So spammers can
already (and could for the last several years) use exactly the DOS
attacks James outlined. AFAIK, they haven't.
Right. But once they decide SPF has upped the ante sufficiently that they can no longer easily forge existing domain names that "SPF-permit" their spam, they *will* attack it.
And, if we never reach that point, then SPF will do nothing in the long run but give spammers incentive to buy newer, better spamware from the black hats -- spamware that either finds, or comes with data bases containing, existing domain names that do not publish SPF records or publish overly permissive SPF records.
PS: I don't think SPF will make even a dent in spam. It will cut down on
the misrouted bounces, if it ever gets off ground, which would be nice,
too.
I think SPF will make a dent in spam, much like pushing sand around on a beach makes a dent in the ocean.
But, oh, please, I *hope* you're right about misrouted bounces; SMTP's (badly designed) bounce system is responsible for a substantial portion of the resources wasted on spam and vermin. (I know this firsthand as a longtime victim of joe jobs.)
In that sense, I have a selfish basis on which to advocate SPF adoption: assuming I can publish my own SPF records, it'd be great if sites like AOL would use SPF to refuse email forging my domain names in the envelope-sender fields, rather than deliver tons of useless bounces to my server.
(And of course I'll hardly care if AOL wants to beat up on its own DNS caches as a result...at least until/unless their problems reach the root servers, or my own DNS servers. ;-)
