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 responses

I'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

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.

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

then setup fail2ban to manage extrafields

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mon, 2 Mar 2015, Dave McGuire wrote:

On 03/01/2015 06:34 PM, Benny Pedersen wrote:

...

...

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.

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

then setup fail2ban to manage extrafields

Now that's a very interesting idea, thank you! I will investigate this.

Does allownets support negative CIDRs?

Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQEVAwUBVPQfMXz1H7kL/d9rAQLP6Qf+KLmEwyVugxT5iXYRK5mVES5L8fsyKIM+ nZR0hMO2N2Aq30Sq6GFRc1+pJoICzP8t20X0yrOgR0pG7CfIIOwH6s/Z9RsBpFW6 WtuqPwRf5/K/KcL2IslIrvjvoYSuzlw4ny7/fLfBIwtuqlnIRhZz8L9CGAMmDWnK cPK2+qNDMGMDk9ueeriklO//BdvFcvlE9Rz/NlsmmbLXzXDN2OQdO9SqV67y7sIA pb7JSr+O2WNAIROm1tccTW22Z1YIYKjOboOHLCNr0MlPL8QDPDrSuy+z7gQpXtCC BDjXba2R/nWBAbwUR/+mJzErShCw48eERCCr7EGjQWYqd6+NHHgl6A== =xYN/ -----END PGP SIGNATURE-----

Am 01.03.2015 um 23:16 schrieb Dave McGuire:

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 responses

I'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.

Guys, dovecot is open source - if you desire a feature that the upstream programmer did not include, pay him a bounty to do so or send him a patch to be included. Period. We can discuss and mightbe somebody will fork if he is not willing to accept such a solutuion for any political reason.

I am really tired of reading this kind of complaints on OSS lists.

To make this not a "troll only" posting - it might be an suitable approach to let dovecot listen on the lo interface and put a proxy software in front, that supports RBLs.

Oliver

Protect your environment - close windows and adopt a penguin!

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mon, 2 Mar 2015, Dave McGuire wrote:

On 03/02/2015 02:38 AM, Oliver Welter wrote:

...

Guys, dovecot is open source - if you desire a feature that the upstream programmer did not include, pay him a bounty to do so or send him a patch to be included. Period. We can discuss and mightbe somebody will fork if he is not willing to accept such a solutuion for any political reason.

I am really tired of reading this kind of complaints on OSS lists.

....and this is perhaps the second most predictable knee-jerk response.

I am certainly capable of writing such a patch, but there is no point in expending the effort if it would not be included in the code base. The extreme negative reactions to this idea from people in this community, every time it has come up over the years, with almost rabid

Neither Timo nor dovecot.fi did responded with "use fail2ban", if I remember correctly. I actually wonder, why nobody replied with: "this is what tcpwrapper is for" :-) http://wiki2.dovecot.org/LoginProcess?highlight=%28tcp+wrapper%29 what had been ruled out by the OP with a conditional *if*.

If you for instance add a passdb{} driver, that does not interfere with the remaining code base (much), so one can use:

passdb { driver = ipdeny args = <host>/matchpattern/action .... *** }

in front of any other passdb{}.

*** some sort of notation to configure IP source, matching and reaction.

If such plugin(?) is available, I would expect immediate complains, it does not support:

• local file lists with various sets of syntaxes
• RBLs with a fine grained response matching
• use the same RBL response for multiple match-action pairs
• have it depended on protocol (POP3, IMAP, ManageSieve, ...)
• have it depended on user (use that passdb for all-but or just-these)
• have it to kick in after certain user-protocol-count-time patterns only

There is this, too: http://article.gmane.org/gmane.mail.imap.dovecot/61570 http://article.gmane.org/gmane.mail.imap.dovecot/42512

Maybe an addition to the penalty service would be OK as well.

Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQEVAwUBVPQoIXz1H7kL/d9rAQLHWwgAs+8TAw7i3qerJQHXD4GSDO0jPCDtqGg3 660CMHCilWNYP+AwM/wxRbBkhz6rtTZrMa3BjLlHo3jnc/kNnJu8YdPCiolQCiWX enU5576oeCikWcAQG/BJxrRTCtHVjzhenu/skCazD8vKncIUlJtn+kiAqpGC3NPe IAJg2FvZ0wgI+bzecZHFktVT8TF0JWtd8FNkD83rOJvNUW7ECrzyAMSUKQ+X54GH 6vcto6eeERY3DKpf/xUs1QBM/Pee1gdMTFU4clW2u9QZLf1aKuNaEVBAx4BaI5Ti hzL/UIXZ0+qHehxNCIyTFx0t4MZsPfJg9/dS3t2vmX9efSUFxe9bgg== =XjPT -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mon, 2 Mar 2015, Reindl Harald wrote:

Am 02.03.2015 um 10:06 schrieb Steffen Kaiser:

...

If such plugin(?) is available, I would expect immediate complains, it does not support:

• local file lists with various sets of syntaxes
• RBLs with a fine grained response matching
• use the same RBL response for multiple match-action pairs

or it could work just with no config, unconditional and

therefore I wrote, that I expect complains, if this feature would work like that

                                                     in front of any 

authentication,

what is that same as to place it as first passdb, with the overhead of parsing the config file and adding it into the passdb{} chain.

             frankly even without any response - connection -> RBL check 

-> close connection, done

some external RBLs return certain information in the response, e.g. 127.0.0.2 is less problematic than 127.0.0.1, so "I expect complains" this or that RBL is not working correctly ;-)

hence RBL's make sense in the core because *in front* of any other protocol specific code

That's TCP wrapper or a firewall, IMHO. (for a file list, not RBL). However, there used to be a RBL patch for TCP wrapper and some distribution provide other implementations of a TCP wrapper with RBL, if this post correct: http://grokbase.com/t/centos/centos/143mg1wxsj/does-anyone-use-tcp-wrappers-...

Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQEVAwUBVPQufHz1H7kL/d9rAQKC3wf/ZuStrHInsV3OkgDC5EDBeSyvMOxlskiy xCNUeAxaqPt4DvgCHnXmXX3V2yi+hXvsFyWhIBcsJcgUvbi0sJWwy7Undw2Fs6Cf iaOD3+u1VV+7IwiiZIMNMpUcDisj9Ic3DBoDTx9SeyBS09i7lKAVORZw486LooWX uTCMZOEmzH43DEfHxmIMPMcyQBF4b7kzc3A/sabpc70bhrJAV8E2ZNpPzIyAiC3A PwjUR+YfdYoorqz79ymmzcngsUUSAXfiUAhJpRyVOL2UiMurjROdsU5vSpXJm71j lgELgKpo6DkIjX+qAPVtdPu/J6cRLUcfvysNezU2vV9KpgJk97cwmw== =2nvt -----END PGP SIGNATURE-----

daemontools

On 3/2/15, Steffen Kaiser <skdovecot@smail.inf.fh-brs.de> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mon, 2 Mar 2015, Reindl Harald wrote:

...

Am 02.03.2015 um 10:06 schrieb Steffen Kaiser:

...

If such plugin(?) is available, I would expect immediate complains, it does not support:

• local file lists with various sets of syntaxes
• RBLs with a fine grained response matching
• use the same RBL response for multiple match-action pairs

or it could work just with no config, unconditional and

therefore I wrote, that I expect complains, if this feature would work like that

...

                                                     in front of any

authentication,

what is that same as to place it as first passdb, with the overhead of parsing the config file and adding it into the passdb{} chain.

...

             frankly even without any response - connection -> RBL

check -> close connection, done

some external RBLs return certain information in the response, e.g. 127.0.0.2 is less problematic than 127.0.0.1, so "I expect complains" this or that RBL is not working correctly ;-)

...

hence RBL's make sense in the core because *in front* of any other protocol specific code

That's TCP wrapper or a firewall, IMHO. (for a file list, not RBL). However, there used to be a RBL patch for TCP wrapper and some distribution provide other implementations of a TCP wrapper with RBL, if this post correct: http://grokbase.com/t/centos/centos/143mg1wxsj/does-anyone-use-tcp-wrappers-...

---

Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQEVAwUBVPQufHz1H7kL/d9rAQKC3wf/ZuStrHInsV3OkgDC5EDBeSyvMOxlskiy xCNUeAxaqPt4DvgCHnXmXX3V2yi+hXvsFyWhIBcsJcgUvbi0sJWwy7Undw2Fs6Cf iaOD3+u1VV+7IwiiZIMNMpUcDisj9Ic3DBoDTx9SeyBS09i7lKAVORZw486LooWX uTCMZOEmzH43DEfHxmIMPMcyQBF4b7kzc3A/sabpc70bhrJAV8E2ZNpPzIyAiC3A PwjUR+YfdYoorqz79ymmzcngsUUSAXfiUAhJpRyVOL2UiMurjROdsU5vSpXJm71j lgELgKpo6DkIjX+qAPVtdPu/J6cRLUcfvysNezU2vV9KpgJk97cwmw== =2nvt -----END PGP SIGNATURE-----

Am 05.03.2015 um 22:45 schrieb Steffen:

Steffen Kaiser wrote:

...

passdb { driver = ipdeny args = <host>/matchpattern/action .... *** }

With next passdb{} as 1st in chain:

passdb { driver = checkpassword args = "/tmp/chktst ip=%r service=%s" result_success = continue result_failure = return-fail }

and this script BEGIN /tmp/chktst #!/bin/bash

echo "$@" >>/tmp/chktst.log # return OK exit 0 # return FAIL exit 1 END

I get the log entry: ip=127.0.0.1 service=imap /usr/local/dovecot-2.2.15/libexec/dovecot/checkpassword-reply

and with exit 0, the next passdb{} let me login, and with exit 1, all logins fail.

So, with the current stock Dovecot you can make RBL calls and decissions with a script. ;-)

• with a terrible overhead starting a full process
• no handling for DNS temp errors and so on
• i don't see any RBL handling above, you just call a random script

On March 1, 2015 10:26:40 AM Reindl Harald <h.reindl@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 responses

close 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 :(

Am 01.03.2015 um 10:25 schrieb Reindl Harald <h.reindl@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 dnsbl

I 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

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 I rather like this idea, but let me point out that this list should be

On Monday 02 March 2015 05:02:49 Jochen Bern wrote: 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>