Well, not necessarily. At the moment, spamdyke is only vulnerable to a very small part of the DNS spoofing attack. Most of the danger Dan Kaminsky discovered comes from caching -- a vulnerable host could cache incorrect DNS data sent by the attacker. spamdyke doesn't cache DNS information, so that's a moot point.
To be completely honest, there is a small danger that spamdyke could receive spoofed responses from an attacker, if the attacker sends packets with the correct ID numbers to the correct port before the "real" nameserver could respond. The chances of success are very, very low (but not zero) because each spamdyke process uses a different UDP port for its DNS traffic, which only remains open while the process is running. Also, the starting IDs for the queries are chosen randomly by each process. It's not like a BIND server that uses the same port for thousands of queries and increments its IDs in a predictable pattern. If someone did manage to spoof responses to a spamdyke process, the most they could achieve would be an incorrect result for an RBL or rDNS query. As a result, if a message were accepted improperly, the only consequence is one piece of spam being delivered. Alternatively, if a legitimate message were rejected improperly, the sender would receive a bounce or the remote server would retry later (depending on the filter and the attacker's data). There's no way to corrupt or intercept email with this attack. So, I plan to look at randomizing the query ports. It's not a complex change, so it'll probably be in the next feature-release or two. Because the risk is so low, I may not implement it if the overhead is too high. Either way, I plan to remain calmer than CERT/CC did. :) -- Sam Clippinger slamp slamp wrote: > On Fri, Oct 3, 2008 at 5:52 PM, Eric Shubert <[EMAIL PROTECTED]> wrote: > >> Felix Buenemann wrote: >> >>> Hi, >>> >>> I agree with Arthur and Bgs in that SPF is a smarter thing to check, >>> because it can be done without checking headers and currently has a much >>> wider disribution base. >>> >>> IMHO the only way to properly reject DKIM failed mail is at the end of >>> the DATA command, which is exactly how eg. simscan rejects virii or spam >>> mail. So IMHO DKIM verification is something to do for a queue-handler >>> not a frot end smtp handler, that is geared for high performance. (This >>> is based on the assumtion, that spamdyke deals with 99% of the scam with >>> very little cpu time, thus reducing server load and leaving more in >>> depth checks to those mails that slip through spamdyke's already tight web.) >>> >>> -- Felix >>> >> Good thinking, Felix. Some things just don't belong in spamdyke as is. >> >> -- >> -Eric 'shubes' >> >> > > > I am not sure if this has been implemented, but this should be at the > top, right? > > Fix the DNS spoofing "bug" by randomizing the outbound port with every > query. > Try not to panic about it like CERT/CC did. > _______________________________________________ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
