On Tue, 14 Nov 2006, Edward Lewis wrote:
> What I find potentially troubling is that an application might choose to refer
> to the DNS in an unwise way to find ancillary data to verify that a received
> message unit is genuine and is authorized to be processed.
(Un)fortunately, the DNS is the best distributed database we have.
> I have had some
> experience in building such systems, the experience being part of research
> projects, and have seen first hand some of the startling performance issues
> that may ensue. This work is about 6 years old now, but it didn't really hit
> home until now.
Trust me, comparing the performance of some DNS lookups to avoid the need
to run them through anti-virus and anti-spam processing is moot. DNS lookups
are cheap. Without using various DNS checks (and greylisting, which i
personally despise) I'd have to add a few Xeons to our anti-spam setup.
> The first ingredient in the problem is that the processing unit performing the
> security checks is the end receiver. This means that there is probably a
> large population base from which traffic can be sourced (legitimately). These
> sources are prone to "abuse" because it is their job to accept data and then
> protect themselves. What else can they do but do their job?
Whether the anti-spam postfix, or my real mailserver's postfix is accepting
the message hardly matters from a security point of view. And I think
experience has proven that a unix based anti-spam server's security risk
outweights 500+ employees running malware within your network.
> Spam is not just a problem because it exists, it is a problem because
> the defenses against it are just as much of a problem. (Not to mention the
> false positives.)
And as I argued with people like Gilmore in the past - I can't afford
not to do spam filtering. Even if my customers wanted to see all spam
(they don't) and even if I felt morally obligated to deliver email even
if it is spam (I don't) and provided I had the hours per day to manually
read the spam (I don't), then my personal error rate on messages would
be higher then my current technical setup.
> The third ingredient is the amplification factor that is a result of
> robustness of the security. When slapping security onto any existing system,
> some level of robustness is lost.
and gained?
> Because of the flood, the routers couldn't get to the DNS to get the
> certificates.
Sounds like a design mistake.
> In conclusion, there isn't really much the DNSOP community can do about this.
There are things we can do, mostly involved with BCP's and sane software
defaults and things like AS112.
> If we try to protect the DNS, well, there's nothing that can really be done in
> the protocol about this, other than to ask "please use the DNS less."
Why would we ask that? DNS serves many good purposes. If "protecting" comes
down to "don't use", then you also have no more need to protect it.
> What I kind of am getting to here is that if the TXT RR is used to convey
> security policy or a search list of servers, then it would be hard to enforce
> reasonable approaches. If an new RR is required for the approach, then the
> protocol can be built in such a way that number of searched sources can be
> limited. Further, if there is no fallback from one RR to another, no
> "alternate" paths to take, I THINK (can't prove) that it would make it easier
> on an operator to know what is the appropriate level of security response to
> the receipt of a message. If the RR RDATA can only have two servers and there
> can only be one RR considered per event, the load has a chance of being
> managed.
Having a seperate RR makes it easier to make custom decisions based on that
RR set.
As for the mentioned EHLO attack, this is easilly prevented in postfix.
Add to main.cf:
smtpd_helo_restrictions = check_helo_access
hash:/etc/postfix/helo_access
Add to /etc/postfix/helo_access:
# reject ehlo string with more then 5 host parts
.*.*.*.*.* "550 HELO string too long, rejecting possible DOS"
And if you think SMTP spam filtering email is bad, wait for your phones
to need to do SIP spam filtering. How long before we can't trust our
phones anymore? I give it two years top.
Paul
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
