[Dovecot] Odd Feature Request - RBL blacklist lookup to prevent authentication
I would like to have a list of IPs (hacker list) that I can do a lookup on so that if anyone tries to authenticate to dovecot they always fail if they are on my list.
I have the list - and the list is available as a DNS blacklist.
I'd like to have it work with both local IP lists or RBL lookup.
The idea is so hackers from known IP addresses never succeed.
If Dovecot provides the feature I have about 1/2 million IP addresses of known current hackers to block.
Anyone else interested in this?
Marc Perkel skrev den 2013-10-22 21:31:
Anyone else interested in this?
would you sell more ram later ?
basicly you like to have fail2ban to a central server logging via syslog ?
if yes create more rules to fail2ban and show it on a wiki
Quoting Marc Perkel marc@perkel.com:
I would like to have a list of IPs (hacker list) that I can do a lookup on so that if anyone tries to authenticate to dovecot they always fail if they are on my list.
I have the list - and the list is available as a DNS blacklist.
I'd like to have it work with both local IP lists or RBL lookup.
The idea is so hackers from known IP addresses never succeed.
If Dovecot provides the feature I have about 1/2 million IP addresses of known current hackers to block. Anyone else interested in this?
How about doing a SQL Auth with a 'NOT IN ' select.
Then in your post auth script do an RBL lookup and if listed (but not in your whitelist), add to your table (with a timestamp to expire of course) and kick the user.
IMHO, the problem with all out blocks on auth is the same as doing an all out block based on SPF - so many IPs are shared you can easily get false positives.
Rick
On 23/10/2013 05:45, Rick Romero wrote:
IMHO, the problem with all out blocks on auth is the same as doing an all out block based on SPF - so many IPs are shared you can easily get false positives.
Blocks using SPF will not be FP's, they will be by your internal decision, so will be a genuine block 'hit', even if you don't keep your RR current, that's the admins fault, not the users, or blockers.
But I agree with you on the rest, since of those 500K IP's Marc claims to have I'd bet that 99% are hijacked innocent pc's/servers, and of them, >75% would likely be a one time usage.
On 10/22/2013 3:22 PM, Noel Butler wrote:
But I agree with you on the rest, since of those 500K IP's Marc claims to have I'd bet that 99% are hijacked innocent pc's/servers, and of them, >75% would likely be a one time usage.
This accords with our own statistics. While it IS tempting to treat every IP# that "spams" or hits you with a port-scan as something worthy of blackholing, the reality is that the vast majority of the attempts are from "innocent" victim hosts.
Now, there's little doubt that MOST of these are not legitimate MTA endpoints, and so "shouldn't" be issuing email directly to your MX hosts. SPF + OpenDKIM are great, but only for those domains that actually use them; you can score "improperly delivered" emails bearing those domains with a policy defined by their operators, but many domains don't publish a policy.
I would caution people to avoid throwing out the baby with the bathwater. I've been collecting an increasing number of "mysterious" email delivery problems to endpoints which do not issue DSN/bounces, *OR* provide any feedback to their users that emails have been "blocked".
The list includes some big names, like:
comcast (cable ISP subscribers) secureserver.net hosted emails (GoDaddy's "hosted email" service, which uses Cloudmark's anti-spam solutions) McAfee's "MXLogic" anti-spam services
McAfee's "SaaS/MXLogic" anti-spam service has a responsive false positive mediation system, whereas comcast's + GoDaddy's setups are thoroughly dysfunctional and broken. Despite publishing SPF, fully specified OpenDKIM and using DomainKeys signing, having perfectly clean IP# reputations and not being on ANY RBLs, emails to those hosts is at best "random", or in comcast's case - when it's hosting "vanity domains" for its customers - completely broken.
I strongly suspect these inferior anti-spam systems are mistakenly ascribing fault for "Joe Jobbed" spam runs, even if they're delivered by non-compliant hosts as specified in the domain's SPF. All of my clients "login" and issue emails through our MTAs, which are specified as permitted senders in SPF, so there are no "rogue" road warriors "allowed" by our domains' SPF policies.
My point is simple: it's easy to let frustration about spam get the better of you, but don't create worse problems for your users and those who try to legitimately reach them. It's progressively making email less and less usable in a global context.
=R=
On 10/22/2013 10:27 PM, Robin wrote:
On 10/22/2013 3:22 PM, Noel Butler wrote:
But I agree with you on the rest, since of those 500K IP's Marc claims to have I'd bet that 99% are hijacked innocent pc's/servers, and of them, >75% would likely be a one time usage.
This accords with our own statistics. While it IS tempting to treat every IP# that "spams" or hits you with a port-scan as something worthy of blackholing, the reality is that the vast majority of the attempts are from "innocent" victim hosts.
Now, there's little doubt that MOST of these are not legitimate MTA endpoints, and so "shouldn't" be issuing email directly to your MX hosts. SPF + OpenDKIM are great...
The OP is discussing possibly blocking *IMAP* connections, not SMTP.
-- Stan
22.10.2013 21:31, Marc Perkel:
I would like to have a list of IPs (hacker list) that I can do a lookup on so that if anyone tries to authenticate to dovecot they always fail if they are on my list.
You could enable dovecot's tcpwrapper support for this.
Kind Regards, Christian Schmidt
-- No signature available.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 22 Oct 2013, Marc Perkel wrote:
I would like to have a list of IPs (hacker list) that I can do a lookup on so that if anyone tries to authenticate to dovecot they always fail if they are on my list.
I have the list - and the list is available as a DNS blacklist.
I'd like to have it work with both local IP lists or RBL lookup.
The idea is so hackers from known IP addresses never succeed.
Why would you let the auth happen at all? Is it some sort of tarpitting? Otherwise you could just block the IP with a firewall.
Maybe you can combine the deny AuthDatabase, as explained here: http://wiki2.dovecot.org/Authentication/RestrictAccess?highlight=%28deny%29 with a socket auth demon: http://wiki2.dovecot.org/AuthDatabase/Dict
So, you return success via the auth socket dict and use the remote IP as "key", but success is turned into "deny".
If Dovecot provides the feature I have about 1/2 million IP addresses of known current hackers to block.
Well, I do not like the notion "one IP == one person", too many setups use NAT.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUmd5xl3r2wJMiz2NAQLaVQf+KLz5cXy9u51KdVnoc2deJydbSuv0J8b1 IpQ2270EIKctTwtwABvYEEOM8o07S20kAL+vqBFBFgvS6pK/mgtm9fg/z1+GPgpu S5ngfOuHw+NrmwSP/JSOGCezFXnccH2a7KVN47pgYVRKWEOMH+j0hbbrogfXcMRD NMtI3GTDlPO0BVdXAavJxQylXbVYAZy5icrd/YkFyp6MkWCNOWkUYzOmr1/sAPZu 8t2t0SXXyfUc/gKHOdO8EGGbS2Bc2YRRO/M3iLScAiJWdo6uu4uCMOjPbZB+utqB 8Nicns0n9ZSCgIixYrjsfwE75nEjY8IwbSplL952sz4kHvG3+5MYrA== =TH+V -----END PGP SIGNATURE-----
participants (8)
-
Benny Pedersen
-
Christian Schmidt
-
Marc Perkel
-
Noel Butler
-
Rick Romero
-
Robin
-
Stan Hoeppner
-
Steffen Kaiser