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:
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.
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).
*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