I wonder if there is an easy way to provide dovecot a flat text file of ipv4 #'s which should be ignored or dropped? I have accumulated 45,000+ IPs which routinely try dictionary and 12345678 password attempts. The file is too big to create firewall drops, and I don't want to compile with wrappers *if* dovecot has an easy ability to do this. If dovecot could parse a flat text file of IPs and drop connections it would sure put a dent in these attempts. Thanks.
fail2ban blocked dynamically addresses for a period of time. It has a module for dovecot.> I wonder if there is an easy way to provide dovecot a flat text file > of ipv4 #'s which should be ignored or dropped? > > I have accumulated 45,000+ IPs which routinely try dictionary and > 12345678 password attempts. The file is too big to create firewall > drops, and I don't want to compile with wrappers *if* dovecot has an > easy ability to do this. If dovecot could parse a flat text file of > IPs and drop connections it would sure put a dent in these attempts.
Hi Jim, you may want to simply try ipset. :) http://ipset.netfilter.org/ http://daemonkeeper.net/781/mass-blocking-ip-addresses-with-ipset/ Kind regards, Felix On 01.03.15 08:53, Jim Pazarena wrote:> I wonder if there is an easy way to provide dovecot a flat text file of > ipv4 #'s which should be ignored or dropped? > > I have accumulated 45,000+ IPs which routinely try dictionary and > 12345678 password attempts. The file is too big to create firewall > drops, and I don't want to compile with wrappers *if* dovecot has an > easy ability to do this. If dovecot could parse a flat text file of IPs > and drop connections it would sure put a dent in these attempts. > > Thanks. >-- Felix Sch?ren Group Director of Enterprise Architecture, HEG. Online: http://www.heg.com/ This email is subject to: http://www.heg.com/disclaimer. Please consider the environment before printing this email
Am 01.03.2015 um 08:53 schrieb Jim Pazarena:> I wonder if there is an easy way to provide dovecot a flat text file of > ipv4 #'s which should be ignored or dropped? > > I have accumulated 45,000+ IPs which routinely try dictionary and > 12345678 password attempts. The file is too big to create firewall > drops, and I don't want to compile with wrappers *if* dovecot has an > easy ability to do this. If dovecot could parse a flat text file of IPs > and drop connections it would sure put a dent in these attempts.hence i asked month ago for RBL support because such lists are easy to feed into http://www.corpit.ru/mjt/rbldnsd.html - sadly i got no reply than use fail2ban and what not irrelevant if there is already a local dnsbl i guess for a C-programmer it takes not much more than 10 minutens include a config option to list rbl servers and close connections absed on the DNS responses -------------- 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/20150301/813b3cb3/attachment.sig>
Am 01.03.2015 um 08:53 schrieb Jim Pazarena:> I have accumulated 45,000+ IPs which routinely try dictionary and > 12345678 password attempts. The file is too big to create firewall > drops, and I don't want to compile with wrappers *if* dovecot has anHave you ever tried using IP sets on Linux?
On 03/01/2015 04:25 AM, Reindl Harald wrote:>> I wonder if there is an easy way to provide dovecot a flat text >> file of ipv4 #'s which should be ignored or dropped? >> >> I have accumulated 45,000+ IPs which routinely try dictionary >> and 12345678 password attempts. The file is too big to create >> firewall drops, and I don't want to compile with wrappers *if* >> dovecot has an easy ability to do this. If dovecot could parse a >> flat text file of IPs and drop connections it would sure put a >> dent in these attempts. > > hence i asked month ago for RBL support because such lists are easy > to feed into http://www.corpit.ru/mjt/rbldnsd.html - sadly i got no > reply than use fail2ban and what not irrelevant if there is already > a local dnsbl > > i guess for a C-programmer it takes not much more than 10 minutens > include a config option to list rbl servers and close connections > absed on the DNS responsesI've been asking for this off-and-on for years, and people immediately parrot back "just use fail2ban". I think fail2ban is a nice idea and all, but that suggestion assumes that I use iptables (I don't), I run firewalls on my servers (I don't; I run them on routers) and that I run Linux on my mail server (I don't). The other side of this equation, Postfix, has had this capability for years. Why it hasn't been added to dovecot is a mystery. It's the only thing (really, the ONLY thing!) that I dislike about dovecot. -Dave -- Dave McGuire, AK4HZ/3 New Kensington, PA
On March 1, 2015 10:26:40 AM Reindl Harald <h.reindl at thelounge.net> wrote:> i guess for a C-programmer it takes not much more than 10 minutens > include a config option to list rbl servers and close connections absed > on the DNS responsesclose pop3, set imap to listen only in lo interface, setup webmail with smtp auth, now then in apache install mod geoip, and only allow countrys with users in is imho the current most simplest, but maybe not the most usefull :(
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 01.03.2015 um 08:53 schrieb Jim Pazarena:> I have accumulated 45,000+ IPs which routinely try dictionary and > 12345678 password attempts. The file is too big to create firewall > drops,Have you also checked ipset (http://ipset.netfilter.org/) Its extremely powerful even with huge block lists -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU9Cn8AAoJEDUc5iWoaKTk3ToQAItYxio2z7BiGjpGD2KOztkQ LvD1yLoJyO2LQqM+8ItT7lFC1tXMfwxs1pMS0983f0H2r4k4w5DFaMtu6Nw1LWyD OTHvxpnkA95b/APn+02GDdXUTVdR9gdk7CWefm4undsuR20QX5b9xm7GmvYJL9Zl n8FyfedQBO1FaiaUEOLmXAJ/oNCx3XzNa4oHVNtV0F2uckAtHzQ+jTcjwgLPYiUm m48MQyYEk9BdXGYS0790zfYWUvfTymxGGBjiALlVRXA9k445OAsv0/PppvTBxH+S 4a3yF6CXh5vfb7bYSdcBhZz7nI5AnSDuFYKMSl+5VIMxFafLxN3N28TD5w7FAu12 ubpSMj52N8UO8axcFOoVuBi4o1fPoPODf46ztfKb5tC5inhpdnxEba1tExR4Eitn WHWu1y3HA9qUoZpG9iA97/bltQqqo0ZPw3run+j8HfR0eVkfBXogbahXxcWx7voq pnvDnL0HA6RUjA9d0wRmHpNvBfSxxzlcFaxV1uacoiZhcJcURilJgpufx0V0mys9 d+MOKVQ/4nxm4Rb2gXQXbaQiBr1TXMJNRRHFnox/lmuCRornHHVf3zDiCh5lM4vQ vnEO2qpVYfqBggTHeIQxC4rdfvmhcKZ3qtngmsQldXafph++n0mGIsu8Vkt7H4Zj 9inl3Wo4Mh84X0NEhZbj =lPnB -----END PGP SIGNATURE-----
On 03/01/2015 08:53 AM, Jim Pazarena wrote:> I wonder if there is an easy way to provide dovecot a flat text file of > ipv4 #'s which should be ignored or dropped? > > I have accumulated 45,000+ IPs which routinely try dictionary and > 12345678 password attempts. The file is too big to create firewall > drops [...]The inherent assumption here is that dovecot, using a "flat file", will be able to process the block list more effectively than the firewall, which is a tool written for the *purpose* but supposedly unable to even *try* due to the list's size. That sounds ... counterintuitive. To clarify, the governing influence on performance of *most* firewalls is the average number of rules a packet has to be matched against, and the two main tools to help with that are (if I may use iptables lingo here) a) --state ESTABLISHED to get everything but the connection-initiating packets out of the way ASAP and b) branching tree-like into dedicated-purpose subchains, rather than building linear lists. Assuming that the IPs to be blocked are randomly distributed, I'ld try something along the following lines: [main chain] --state ESTABLISHED,RELATED -j ACCEPT -p tcp --dport pop3 -j dove-blocks -p tcp --dport imap -j dove-blocks [subchain dove-blocks] -d 1.0.0.0/8 -j sub-1 -d 2.0.0.0/8 -j sub-2 ... -d 254.0.0.0/8 -j sub-254 [subchain sub-1] -d 1.2.0.0/16 -j sub-1-2 # We've seen 1.2.3.4 and 1.2.2.1 ... [subchain sub-1-2] -d 1.2.2.1 -j DROP -d 1.2.3.4 -j DROP 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
Am 02.03.2015 um 11:02 schrieb Jochen Bern:> On 03/01/2015 08:53 AM, Jim Pazarena wrote: >> I wonder if there is an easy way to provide dovecot a flat text file of >> ipv4 #'s which should be ignored or dropped? >> >> I have accumulated 45,000+ IPs which routinely try dictionary and >> 12345678 password attempts. The file is too big to create firewall >> drops [...] > > The inherent assumption here is that dovecot, using a "flat file", will > be able to process the block list more effectively than the firewall, > which is a tool written for the *purpose* but supposedly unable to even > *try* due to the list's size. That sounds ... counterintuitive* it's unmaintainable on firewall level * it's waste of ressources because it is *packet based* * hence a RBL would make so much more sense for rbldnsd it don't matter if 100, 1000, 10000, 10000000 addresses or even cidr-ranges are listed because the check is always *one* cheap dns request for the IP conencting at the moment -------------- 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/58b4a433/attachment.sig>
On March 2, 2015 10:15:22 AM Tobi <tobster at brain-force.ch> wrote:> > I have accumulated 45,000+ IPs which routinely try dictionary and > > 12345678 password attempts. The file is too big to create firewall > > drops, > Have you also checked ipset (http://ipset.netfilter.org/) > Its extremely powerful even with huge block liststhis is only usefull if real user have more then +45000 ips, and it why its not denynets in dovecot using xtables geoip here, and could let fail2ban create xtable csv datafile that can be included in xtable build, then just use geoip firewall rule to allow in all other ips if thats the goal of allow many ips default but i just default allow pr user country, all other is denyed connection
On Monday 02 March 2015 05:02:49 Jochen Bern wrote:> On 03/01/2015 08:53 AM, Jim Pazarena wrote: > > I wonder if there is an easy way to provide dovecot a flat text file > > of ipv4 #'s which should be ignored or dropped? > > > > I have accumulated 45,000+ IPs which routinely try dictionary and > > 12345678 password attempts. The file is too big to create firewall > > drops [...] > > The inherent assumption here is that dovecot, using a "flat file", > will be able to process the block list more effectively than the > firewall, which is a tool written for the *purpose* but supposedly > unable to even *try* due to the list's size. That sounds ... > counterintuitive. > > To clarify, the governing influence on performance of *most* firewalls > is the average number of rules a packet has to be matched against, and > the two main tools to help with that are (if I may use iptables lingo > here) a) --state ESTABLISHED to get everything but the > connection-initiating packets out of the way ASAP and b) branching > tree-like into dedicated-purpose subchains, rather than building > linear lists. Assuming that the IPs to be blocked are randomly > distributed, I'ld try something along the following lines: > > [main chain] > --state ESTABLISHED,RELATED -j ACCEPT > -p tcp --dport pop3 -j dove-blocks > -p tcp --dport imap -j dove-blocks > > [subchain dove-blocks] > -d 1.0.0.0/8 -j sub-1 > -d 2.0.0.0/8 -j sub-2 > ... > -d 254.0.0.0/8 -j sub-254 > > [subchain sub-1] > -d 1.2.0.0/16 -j sub-1-2 # We've seen 1.2.3.4 and 1.2.2.1 > ... > > [subchain sub-1-2] > -d 1.2.2.1 -j DROP > -d 1.2.3.4 -j DROP > > Regards, > J. BernI rather like this idea, but let me point out that this list should be pre-sorted with something that puts them in numerical order, and that order then pre-processed again to condense them into sequential blocks. And those sequential blocks are what you would present to iptables of ipset. You might have to trigger a new sort & condense session each time a new address is harvested and added to the list, but on a busy server that would have to be much less of a cpu hog than just searching a flat random list for every access. I use pop3 for access to 3 accounts, with mailfilter in front of fetchmail here, and occasionally will sort the reference files, and if a given class d address block gets hit several times, I re-arrange the regex to kill on "[xx.xx.xx'" alone, killing the whole class D. I watch the logs, and I don't recall that this policy has cost me a single message I should have received. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
> Am 01.03.2015 um 10:25 schrieb Reindl Harald <h.reindl at thelounge.net>: > Am 01.03.2015 um 08:53 schrieb Jim Pazarena: >> I wonder if there is an easy way to provide dovecot a flat text file of >> ipv4 #'s which should be ignored or dropped? >> >> I have accumulated 45,000+ IPs which routinely try dictionary and >> 12345678 password attempts. The file is too big to create firewall >> drops, and I don't want to compile with wrappers *if* dovecot has an >> easy ability to do this. If dovecot could parse a flat text file of IPs >> and drop connections it would sure put a dent in these attempts. > > hence i asked month ago for RBL support because such lists are easy to feed into http://www.corpit.ru/mjt/rbldnsd.html - sadly i got no reply than use fail2ban and what not irrelevant if there is already a local dnsblI absolutely agree with Harald Reindl's findings on the advantages of DNSBL, but you have to see the big picture. Though I?ll speak about DNSBL a lot in this text, this is about blocking IPs in general. In my opinion, the *only* valid setup to use DNSBL are MTAs that accept mail from unauthenticated clients. That is because in such scenarios there are several heuristics you can safely use to distinguish the good from the bad. One of the most important aspects has to do with the distinction between mail submission and transmission. If you don?t want an open relay, you normally let your users authenticate before they can submit their mail. In any other case it?s safe to assume that the client is another MTA wanting to push a message over to you. We are talking about server systems here, not end users. Servers that should have a valid hostname, a static IP with no NAT in between etc. Blocking one IP in this case *should* really only block that one bad computer system. In the end, it?s perfectly OK to block clients that are either not authenticated, have no valid hostname, use dynamically assigned IPs etc. from accessing your MTA. Once having checked that one may put single IPs on a private block list to speed things up. In the case of HTTP, IMAP, etc. things are not so easy. Just think about NAT and CGN. You as a service provider *can* never know that there?s no collateral damage when you block an IP address. Every single IP out there could be a gateway to a private or even carrier grade network with hundreds or thousands of computers behind it. Some of them might be infected by malware or controlled by a bad guy. Some others might be those your clients use to download their mail. You?d lock them all out?just because you want to safe some server resources? Is it really worth it? Imagine one of your customers traveling abroad, using unusual POPs to access your dovecot instance. If the gateway IP that your server sees is blocked, you lock out your own customer. It?s the old tale. Some words of advice: (1) There?s no point in listing thousands of IPs without proper TTL. And that TTL should be short! If there really were 45 000 single /32 IPs that were behaving rude at some point in the past, how can you be sure these addresses are still doing so? Moreover, with IPv4 addresses being rare and IPv6 only being deployed slowly, CGN happens to be used more often than in the past. Even with IPv6, where prefixes were initially meant to be static, there are many ISPs that don?t give their line customers static IPv6 prefixes. That means attackers as well as your customers might end up using many different addresses over time. (2) If you run your own block list and were to add another IP, there should be sufficient knowledge about the origin of the attack. Always check the RIR whois databases, look at the delegated address range the IP is in, the country, the owner of the network, hostnames... Monitor your log files and try to detect patterns. [Honestly, I?d not be willing to invest the time ;-) ] (3) Use a scoring system. If there are other DNSBLs that list the IP or network in question, the likelihood of causing more harm than good is a bit lower than if you are the only one suffering an attack. Community based DNSBLs are commonly a good thing. You see, blocking IPs just because it?s simple and effective (for the moment) might not be what you want. I?d rather let my users choose stronger passwords, strongly enforce TLS and scale up my server systems to handle the bad traffic. Surely, it depends on your own case, just don?t be na?ve and think that blocking IPs is a general solution to anything nowadays. It might very well work for you if you don?t have a lot of customers, though. Speaking about dovecot, I doubt direct DNSBL integration will happen upstream because dovecot already supports access lookups. You can use dovecot's tcpwrap and configure your /etc/hosts.deny to lookup an external ACL program that in turn consults your DNSBL. See man hosts_options, section RUNNING OTHER COMMANDS. Look for ?aclexec?.[1] I guess that should get you on track. Just be warned that this solution (a) spawns a new tcpwrap instance for each new client connection, and (b) also spawns a new process of your custom acl program. Cheers, Felix [1] http://manpages.ubuntu.com/manpages/quantal/man5/hosts_options.5.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://dovecot.org/pipermail/dovecot/attachments/20150304/0d2e2c43/attachment-0001.sig>