Am 02.03.2015 um 18:56 schrieb Robert Schetterer:> perhaps and i mean really "perhaps" go this way > > https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/ > > https://sys4.de/de/blog/2012/12/28/botnets-mit-rsyslog-und-iptables-recent-modul-abwehren/ > > 45K+ IPs will work in a recent table > i have them too but for smtp only like > > echo 10000000 > /sys/module/xt_recent/parameters/ip_list_tot > > combine with geoip might be a good idea too > > is ultra faster then fail2ban cause no log file parsing is needed > > or an other idea > you might test, configure a syslog filter pumping in a recent table the > direct waythat is all nice but the main benefit of RBL's is always ignored: * centralized * no log parsing at all * honeypot data are "delivered" to any host * it's cheap * it's easy to maintain * it don't need any root privileges anywhere we have a small honeypot network with a couple of ipranges detecting mass port-scans and so on and this data are available *everywhere* so if some IP hits there it takes 60 seconds and any service supportings DNS blacklists can block them *even before* the bot hits the real mailserver at all -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20150302/cbb958d7/attachment.sig>
Am 02.03.2015 um 19:03 schrieb Reindl Harald:> > Am 02.03.2015 um 18:56 schrieb Robert Schetterer: >> perhaps and i mean really "perhaps" go this way >> >> https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/ >> >> >> https://sys4.de/de/blog/2012/12/28/botnets-mit-rsyslog-und-iptables-recent-modul-abwehren/ >> >> >> 45K+ IPs will work in a recent table >> i have them too but for smtp only like >> >> echo 10000000 > /sys/module/xt_recent/parameters/ip_list_tot >> >> combine with geoip might be a good idea too >> >> is ultra faster then fail2ban cause no log file parsing is needed >> >> or an other idea >> you might test, configure a syslog filter pumping in a recent table the >> direct way > > that is all nice > > but the main benefit of RBL's is always ignored: > > * centralized > * no log parsing at all > * honeypot data are "delivered" to any host > * it's cheap > * it's easy to maintain > * it don't need any root privileges anywhere > > we have a small honeypot network with a couple of ipranges detecting > mass port-scans and so on and this data are available *everywhere* > > so if some IP hits there it takes 60 seconds and any service supportings > DNS blacklists can block them *even before* the bot hits the real > mailserver at all >centralize may also work with syslog filters acting to a "grand" firewall/loadbalancers in front of all hosts, anyway depending to setups combine many solutions may goal the best results, your solution is fine too. At the end everything is fine what solves the task, and the admin has to decide which way he want to go MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra?e 15, 81669 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
On 2015/3/2 10:03, Reindl Harald wrote:> > that is all nice > > but the main benefit of RBL's is always ignored: > > * centralized > * no log parsing at all > * honeypot data are "delivered" to any host > * it's cheap > * it's easy to maintain > * it don't need any root privileges anywhere > > we have a small honeypot network with a couple of ipranges detecting > mass port-scans and so on and this data are available *everywhere* > > so if some IP hits there it takes 60 seconds and any service > supportings DNS blacklists can block them *even before* the bot hits > the real mailserver at all >I would like to reiterate Reindl Harald's point above, since subsequent discussion has gotten away from it. If Dovecot had DNS RBL support similar to Postfix, I think quite a few people would use it, and thereby defeat the scanners far more effectively than any other method. It is good that other people are suggesting things that will work today, but in terms of what new feature would be the best solution, I can't think of one better than a DNS RBL.
hi all I've been reading this thread with interest. As a rather novice programmer. I'm not being humble here, I really am not very good, I can do stuff, but it takes a LONG time. My spaghetti code even has meatballs in it ! Not being a great programmer I'm not really able to code something up, but it occurred to me something could be scripted, are the other posters suggesting something like the following .... It does use fail2ban, which I understand isn't the ideal solution, but in brief.... extract the IP's from the fail to ban log file (or any other log file if you so desire). Use these to push up to the firewall or insert into your dovecot 'if' statement (which programmatically even I could probably manage ;) ) I understand that this wasn't exactly what the OP was looking for but creating the 'if' on the fly, as it were , is certainly better than putting the values in manually . An outline for the first part, extracting the ips from a log file, if anyone is interested can be found here. http://www.the-art-of-web.com/system/fail2ban-log/ The second bit, adding in the values to the if statement, shouldn't be that hard... I could probably push something out in Java (but that would obviously not be any good for anyone!), maybe even PERL it would take me longer, at a push even a bash script... (I feel like my hair is going grey ;) ... Maybe even a good bash project for me as a beginner. Just a question to see if I am understanding the general preposition of this thread. thanks for you time, and to helping me to learn this stuff. David On 4 Mar 2015 05:04, "Earl Killian" <dovecot at lists.killian.com> wrote:> On 2015/3/2 10:03, Reindl Harald wrote: > >> >> that is all nice >> >> but the main benefit of RBL's is always ignored: >> >> * centralized >> * no log parsing at all >> * honeypot data are "delivered" to any host >> * it's cheap >> * it's easy to maintain >> * it don't need any root privileges anywhere >> >> we have a small honeypot network with a couple of ipranges detecting mass >> port-scans and so on and this data are available *everywhere* >> >> so if some IP hits there it takes 60 seconds and any service supportings >> DNS blacklists can block them *even before* the bot hits the real >> mailserver at all >> >> I would like to reiterate Reindl Harald's point above, since subsequent > discussion has gotten away from it. If Dovecot had DNS RBL support similar > to Postfix, I think quite a few people would use it, and thereby defeat the > scanners far more effectively than any other method. It is good that other > people are suggesting things that will work today, but in terms of what new > feature would be the best solution, I can't think of one better than a DNS > RBL. >
On 3/4/15, Earl Killian <dovecot at lists.killian.com> wrote:> On 2015/3/2 10:03, Reindl Harald wrote: >> >> that is all nice >> >> but the main benefit of RBL's is always ignored: >> >> * centralized >> * no log parsing at all >> * honeypot data are "delivered" to any host >> * it's cheap >> * it's easy to maintain >> * it don't need any root privileges anywhere >> >> we have a small honeypot network with a couple of ipranges detecting >> mass port-scans and so on and this data are available *everywhere* >> >> so if some IP hits there it takes 60 seconds and any service >> supportings DNS blacklists can block them *even before* the bot hits >> the real mailserver at all >> > I would like to reiterate Reindl Harald's point above, since subsequent > discussion has gotten away from it. If Dovecot had DNS RBL support > similar to Postfix, I think quite a few people would use it, and thereby > defeat the scanners far more effectively than any other method. It is > good that other people are suggesting things that will work today, but > in terms of what new feature would be the best solution, I can't think > of one better than a DNS RBL. >A people argued for this before, like a few argued for postfix-style failover for mysql database lookups, both are welcome features by Timo from memory, but only if someone else codes it up, otherwise, it will probably snow in Dubai before Timo does it, just look at how scarce he is here, we were getting bugzilla 18 months ago, and as the song goes "still waiting, still waiting" :->
On 03/04/2015 05:03 AM, Earl Killian wrote:> I would like to reiterate Reindl Harald's point above, since subsequent > discussion has gotten away from it. If Dovecot had DNS RBL support > similar to Postfix, I think quite a few people would use it, and thereby > defeat the scanners far more effectively than any other method. It is > good that other people are suggesting things that will work today, but > in terms of what new feature would be the best solution, I can't think > of one better than a DNS RBL.I've *seen* mailservers after an external DNSBL configured into them became defunct or unreachable, and "better", much less "the best solution", is not how *I* would rank the result in comparison to local rate limiting. (Note that, unlike in the case of spam and SMTP, allowing a couple POP/IMAP connection attempts until the limit strikes is unlikely to become visible to the legit userbase.) Which is not to say that such a feature should not be implemented - after all, Jim said that he compiled the 45k list *himself*, so it would be a *locally administered* DNSBL for him. On 03/03/2015 10:43 PM, Reindl Harald wrote:> the problem is the "in a secure way" > > that's not really possible when you mangle firewall rules which implies > root permissions - as RBL request is just a DNS request which don't need > *any* permissions on the machine which does the request > > the other problem is mangle firewall rules in context of existing > infrastructures is error prone - you may interfere existing rulesets > - it's a bad idea to start withThat's a lot of smoke you're blowing at a firewall that hasn't been specified beyond "it's *not* iptables". FWIW, *if* it were iptables, something along the lines of "-d myserver --dport 993 --state NEW -j (NF)QUEUE" would happily pass *only* the incoming IMAPS connections to a decision-maker running in userspace. Regards, 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 03/03/2015 11:03 PM, Earl Killian wrote:> On 2015/3/2 10:03, Reindl Harald wrote: >> >> that is all nice >> >> but the main benefit of RBL's is always ignored: >> >> * centralized >> * no log parsing at all >> * honeypot data are "delivered" to any host >> * it's cheap >> * it's easy to maintain >> * it don't need any root privileges anywhere >> >> we have a small honeypot network with a couple of ipranges detecting >> mass port-scans and so on and this data are available *everywhere* >> >> so if some IP hits there it takes 60 seconds and any service >> supportings DNS blacklists can block them *even before* the bot hits >> the real mailserver at all >> > I would like to reiterate Reindl Harald's point above, since subsequent > discussion has gotten away from it. If Dovecot had DNS RBL support > similar to Postfix, I think quite a few people would use it, and thereby > defeat the scanners far more effectively than any other method. It is > good that other people are suggesting things that will work today, but > in terms of what new feature would be the best solution, I can't think > of one better than a DNS RBL.Please add this support to iptables instead of Dovecot. It's a waste of effort to code it into every application that listens on the network. Combined with "--ctstate NEW" and a chain for IMAP packets, it would be no less efficient.