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-and-realtime-blacklists/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20140617/5390021d/attachment.sig>
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-and-realtime-blacklists/ >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. -- Regards, Giles Coochey, CCNP, CCNA, CCNAS NetSecSpec Ltd +44 (0) 8444 780677 +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles at coochey.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6454 bytes Desc: S/MIME Cryptographic Signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20140617/e3965619/attachment.p7s>
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 complexCan'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 listRegards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel
On 6/17/2014 7:16 PM, 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-and-realtime-blacklists/ >There are some Dovecot developments in that area: http://www.dovecot.org/talks/berlin-20140513.pptx.pdf (page 22) Regards, Stephan.