Am 17.06.2014 19:43, schrieb Giles Coochey:

On 17/06/2014 18:16, Reindl Harald wrote:

...

after having my own dnsbl feeded by a honeypot and even mod_security supports it for webservers i think dovecot sould support the same to prevent dictionary attacks from known bad hosts, in our case that blacklist is 100% trustable and blocks before SMTP-Auth while normal RBL's are after SASL

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

setup a own honeypot and feed rbldnsd with the sources is quite easy and in case of a own, trustable RBL where no foreigners report somebody by mistake it's relieable and scales well over many machines and services as long services supporting it

mod_security: http://blog.inliniac.net/2007/02/23/blocking-comment-spam-using-modsecurity-...

If you have the bllist as a file then you may as well drop with iptables (in Linux) or ipfw (BSD).

Use an IP tool for an IP block, not the application.

Spamhaus project has a kind of script for this type of thing:

http://www.spamhaus.org/faq/section/DROP%20FAQ

I'm quite happy to use fail2ban, yes - dovecot has to handle a few failed logins for each blocked IP, but it works for me and pretty much mitigates the attack

that's not the point, to achieve the same as with a RBL you need to manipulate iptables on every machine - the RBL is centrally for HTTP/SMTP and so it makes sense to use it also for IMAP/POP3

additionally you have no log - thats bad with a RBL you have a dedicated log containign much more data than source / target IP and ports

also i don't want to have fail2ban on every machine, the point of a RBL with a honeypot is that bad machines are blocked for 7 days just beause they touch any unused IP and likely before they even hit the production servers

iptables-rules are managed here also centralized over a lot of machines and i really don't want to marry the honeypot with the iptables

Am 17.06.2014 20:23, schrieb Giles Coochey:

On 17/06/2014 18:56, Reindl Harald wrote:

...

Am 17.06.2014 19:43, schrieb Giles Coochey:

...

On 17/06/2014 18:16, Reindl Harald wrote:

...

after having my own dnsbl feeded by a honeypot and even mod_security supports it for webservers i think dovecot sould support the same to prevent dictionary attacks from known bad hosts, in our case that blacklist is 100% trustable and blocks before SMTP-Auth while normal RBL's are after SASL

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

setup a own honeypot and feed rbldnsd with the sources is quite easy and in case of a own, trustable RBL where no foreigners report somebody by mistake it's relieable and scales well over many machines and services as long services supporting it

mod_security: http://blog.inliniac.net/2007/02/23/blocking-comment-spam-using-modsecurity-...

If you have the bllist as a file then you may as well drop with iptables (in Linux) or ipfw (BSD).

Use an IP tool for an IP block, not the application.

Spamhaus project has a kind of script for this type of thing:

http://www.spamhaus.org/faq/section/DROP%20FAQ

I'm quite happy to use fail2ban, yes - dovecot has to handle a few failed logins for each blocked IP, but it works for me and pretty much mitigates the attack that's not the point, to achieve the same as with a RBL you need to manipulate iptables on every machine - the RBL is centrally for HTTP/SMTP and so it makes sense to use it also for IMAP/POP3

Or just do it on the firewall...

• you need to centralize it
• it don't fit my environment

...

additionally you have no log - thats bad with a RBL you have a dedicated log containign much more data than source / target IP and ports Iptables has a log option

please read again what you quoted

iptables logs hardly contain the username postfix rejections based on RBLs contain From/To

a huge difference if it comes to analyze logs

iptables logs are *packet based*

...

also i don't want to have fail2ban on every machine, the point of a RBL with a honeypot is that bad machines are blocked for 7 days just beause they touch any unused IP and likely before they even hit the production servers That's your personal choice

yes, and that's why i asked for RBL support and not fail2ban

...

iptables-rules are managed here also centralized over a lot of machines and i really don't want to marry the honeypot with the iptables That's specific to your deployment

yes, that's why i ask for a feature i know fail2ban and like tools well

I don't know how much use such a feature within dovecot would get as there are quite a few specific tools that could accomplish pretty much the same goals of what you're looking for - it is just unfortunate that they don't fit in your own environment.

yes

Am 17.06.2014 20:39, schrieb Giles Coochey:

On 17/06/2014 19:32, Reindl Harald wrote:

...

Am 17.06.2014 20:23, schrieb Giles Coochey:

...

On 17/06/2014 18:56, Reindl Harald wrote:

...

Am 17.06.2014 19:43, schrieb Giles Coochey:

...

On 17/06/2014 18:16, Reindl Harald wrote:

Iptables has a log option please read again what you quoted

iptables logs hardly contain the username postfix rejections based on RBLs contain From/To

a huge difference if it comes to analyze logs

iptables logs are *packet based*

Yes, you wouldn't get more information from the (iptables) log other than what can be discerned from the packet header & timestamp information.

You should probably examine the allow_nets code and see to what extent it can be used or perhaps extended if necessary.

http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets

to make it short: i know all that options the question remains in the topic i started

if the answer from Timo is "no" that it's just no nothing won't change the question

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