Am 17.06.2014 21:04, schrieb Jochen Bern: > On -10.01.-28163 20:59, Reindl Harald wrote: >> i admit that i am not a C/C++-programmer, but i think >> doing the DNS request and in case it has a result block >> any login attemt should be not too complex > > Can't say that I actually ever *did* it, but according to the docs, the > following should work: > > 1. Use http://wiki2.dovecot.org/Authentication/MultipleDatabases to have > login requests go through a > http://wiki2.dovecot.org/AuthDatabase/CheckPassword first. Insert %r > into the args to pass the rip to the external executable. > > 2. Make that executable return failure if there is a matching DNSBL > entry. (Note that in the case of a *dictionary* attack, offenders should > appear in your resolver's local cache shortly, so you can set very low > timeouts.) Configure the database as "result_failure = return-fail" > (according to the docs, that should make dovecot generate a log entry) > and "result_success = continue" (which will pass processing to the > *actual* userdb/passdb). > > 3. *Now* you can take advantage of having the lookup being done by an > external executable, instead of (hard)code(d) within dovecot: Use the > iptables "recent" module to (temporarily) block packets from SRCs on a > local dynamic blacklist, and let the executable feed any matches it > encounters to that list through the /proc/net interface as well. > >> echo +addr >/proc/net/xt_recent/DEFAULT >> to add addr to the DEFAULT list
thanks - but all that workarounds is wwhat i want to avoid simply because the gain is not high enough, the possible points of failures are increased while having already a trustable DNSBL and how DNSBL is working - any answer means listed - no response or a NXDOMAIN means "don't block the client" finally the way a RBL works also means in case of failures you only have the DNS request timeout but no false positives
signature.asc
Description: OpenPGP digital signature
