On Wed, Oct 8, 2008 at 10:33 PM, Sam Clippinger <[EMAIL PROTECTED]> wrote: > 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 >
Thanks for the explanation Sam! _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
