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-m...

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

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@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@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" :->

Am 04.03.2015 um 17:06 schrieb Jochen Bern:

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.

surely - and *that* was my whole point, nobody talked about using spamhaus or DUL RBL's on a IMAP/POP3

my feature request last year was *because i have* already a rbldnsd which is used in postfix and on webserver with mod_security and i find it strange that i can't stop a dictionary attack faced on SMTP to continue on POP3/IMAP after locked out from postfix without write firewall rules

the whole point of a *locally administered* RBL is that you don't need to care about hown many mailservers you have and where they are nor need you to open security holes between them for sharing data

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 with

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

Am 04.03.2015 um 20:12 schrieb Michael Orlitzky:

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

you don't want a dns client in a kernel module with full permissions and you will never convince any sane kernel developer doing that nor does it much help for the users on a different operating system

dovecot is not linux only

In the case of HTTP, IMAP, etc. things are not so easy. Just think about NAT and CGN

that don't matter

if i blacklist a client because he starts a dictionary attack in SMTP i want it also bock on IMAP without use a dozen of different tools because teh via IMAP now catched account password will be used for send spam later when the SMTP RBL entry expires

and frankly that 100% trustable RBL lives *before* "permit_sasl_authenticated" because it would be pointless anywhere else

ordinary blacklists are score based on the MX, that is a complete differet machine with no business for POP3/IMAP or even outgoing mail

Am 04.03.2015 um 23:00 schrieb Felix Zandanel:

I am not against block lists. I just say their use should be justified as they may decrease overall service quality as well. There is another solution for auth based services: As soon as you detect a possible attack (# auth reqs > x etc.), keep the connection open, slow it down and just never let it succeed regardless of the credentials provided. This is done on a per-connection basis. No block list needed. Can be accomplished with fail2ban and iptables and therefore uses minimal server resources.

well, i have iptables rate controls which blocks most dictionary attacks and small DOS-attacks perfectly well

but that won't change the fact that if from an IP address starts a large dictionary attack and that IP is a CGN it *would* affect users from the same IP anyways

and since this is fact it is reasonable to

• enter that IP in the wbeinterface feeding rbldnsd
• enter in the scond field 1800 seconds or whatever value
• apply it that way for any service supporting RBL's
• release that lock automatically after X seconds

security and defense is always layered but such things don't work well if half or mail-subsytems needs sepcial handling

Am 04.03.2015 um 21:03 schrieb Dave McGuire:

On 03/04/2015 02:12 PM, Michael Orlitzky 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.

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.

<head explodes>

Would you care to integrate it into IOS on my Cisco as well?

There are things connected to the Internet that aren't PCs running Linux, you know. It may be hard to accept, but that's the way it is.

I assume your dovecot runs on some kind of *nix so there should be some sort of netfilter available which you can put in front of your listening ports.

It might be also an option to create some kind of "hooks" in dovecot that can be used to connect to a DNSBL checker - so configuration can happen outside of dovecot.

Oliver

-- Protect your environment - close windows and adopt a penguin!

Am 04.03.2015 um 21:45 schrieb Dave McGuire:

On 03/04/2015 03:37 PM, Oliver Welter 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.

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.

<head explodes>

Would you care to integrate it into IOS on my Cisco as well?

There are things connected to the Internet that aren't PCs running

Linux, you know. It may be hard to accept, but that's the way it is.

I assume your dovecot runs on some kind of *nix

Of course. I run it under Solaris.

...

so there should be some sort of netfilter available which you can put in front of your listening ports.

There is. But I already have a firewall, running on bulletproof hardware that doesn't depend on spinning disks. I don't want to add ANOTHER firewall when I already have a perfectly good one. Besides, my mail server is built for...serving mail. Not being a firewall.

Well, from an academic point of view, a network service that denies connection on the ip layer is also an ip firewall.

Oliver

-- Protect your environment - close windows and adopt a penguin!

Am 04.03.2015 um 21:51 schrieb Oliver Welter:

...

...

...

...

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.

<head explodes>

Would you care to integrate it into IOS on my Cisco as well?

There are things connected to the Internet that aren't PCs running

Linux, you know. It may be hard to accept, but that's the way it is.

I assume your dovecot runs on some kind of *nix

Of course. I run it under Solaris.

...

so there should be some sort of netfilter available which you can put in front of your listening ports.

There is. But I already have a firewall, running on bulletproof hardware that doesn't depend on spinning disks. I don't want to add ANOTHER firewall when I already have a perfectly good one. Besides, my mail server is built for...serving mail. Not being a firewall.

Well, from an academic point of view, a network service that denies connection on the ip layer is also an ip firewall.

nonsense

a service using RBL's don't reject on IP layer

On 03/04/2015 04:33 PM, Professa Dementia wrote:

On 3/4/2015 12:45 PM, Dave McGuire wrote:

...

There is. But I already have a firewall, running on bulletproof hardware that doesn't depend on spinning disks. I don't want to add ANOTHER firewall when I already have a perfectly good one. Besides, my mail server is built for...serving mail. Not being a firewall.

You can implement whatever type of security you are comfortable with, however, best practices is to have layered security, also known as the "belt and suspenders" method of keeping your pants up.

A perimeter firewall and local firewalls (iptables usually) on each machine is the minimum level of security I set up. A perimeter firewall alone does not protect you from an attacker who is able to compromise one machine and install a scanner which then scan all the systems on your internal network looking for exploitable weaknesses. All the while the perimeter firewall is oblivious to the attack going on internally and utterly incapable of mitigating it even if it were aware.

Yes, I have some experience in these matters, thank you.

You've made my point for me. This is why I want Dovecot to handle the next layer, either via big flat files, a mysql/pgsql table, or DNS queries.

             -Dave

-- Dave McGuire, AK4HZ/3 New Kensington, PA

On 03/04/2015 06:12 PM, Jochen Bern wrote:

On 03/04/2015 09:45 PM, Dave McGuire wrote:

...

On 03/04/2015 03:37 PM, Oliver Welter wrote:

...

Am 04.03.2015 um 21:03 schrieb Dave McGuire:

...

Am 04.03.2015 um 20:12 schrieb Michael Orlitzky:

...

Please add [DNSBL] support to iptables instead of Dovecot. It's a waste of effort to code it into every application that listens on the network.

(FWIW, I agree that DNSBL hooks have no business being in kernel space. A standard *userland* DNSBL client communicating with iptables and similar by means of libnetfilter_queue would sound quite promising, however ...)

This is what I had in mind. Here's a proof of concept. First, the iptables rule:

iptables -A tcp_packets -p tcp --dport 443 -j NFQUEUE --queue-num 1

(the details aren't important, just send something to NFQUEUE #1).

Then create the queue as root, and drop privileges. After that you can make accept/drop decisions in userspace. This took maybe 15 minutes using NetfilterQueue from pypi. It would be easy to replace the

if ipp.src == badguy

test with a real RBL lookup. But then you'd need to make the RBL list configurable, and implement a scoring system, and document it, etc. (i.e. all the /actual/ work).

import os, pwd, grp from netfilterqueue import NetfilterQueue from scapy.all import IP

def drop_privileges(uid_name='dovecot', gid_name='dovecot'): """ Drop user/group privileges from root/root to the given ones. """ if os.getuid() != 0: # We're not root *shrug*. return

# Get the uid/gid from the name
running_uid = pwd.getpwnam(uid_name).pw_uid
running_gid = grp.getgrnam(gid_name).gr_gid

# Remove group privileges
os.setgroups([])

# Try setting the new uid/gid
os.setgid(running_gid)
os.setuid(running_uid)

# Ensure a very conservative umask
old_umask = os.umask(077)

def callback(packet): """ Callback function registered through netfilter. Will be called on every packet passed to the netfilter queue. """ badguy = "127.0.0.1" ipp = IP(packet.get_payload())

if ipp.src == badguy:
    print("Dropping packet from %s..." % badguy)
    packet.drop()
else:
    packet.accept()

nfqueue = NetfilterQueue() nfqueue.bind(1, callback)

drop_privileges()

try: nfqueue.run() except KeyboardInterrupt: print("Bailing...")

Am 02.03.2015 um 20:01 schrieb Benny Pedersen:

...

...

...

...

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

rethink why its allownets not denynets

...

45K+ IPs will work in a recent table i have them too but for smtp only like

have you seem a single user with 45k ips that does not make logs of login fails ?

the most problem may nat and false positves, with firewall or deny ip stuff you may ban wanted users too, so this should be only used in heavy cases, so there is no ultimate solution which fits every case on every setup

Best Regards 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 02 Mar 2015, at 16:34 , Benny Pedersen me@junc.eu wrote:

On March 2, 2015 8:32:35 PM Robert Schetterer rs@sys4.de wrote:

...

the most problem may nat and false positves, with firewall or deny ip stuff you may ban wanted users too, so this should be only used in heavy cases, so there is no ultimate solution which fits every case on every setup

yep pop-before-smtp was simple once, here i just allow in country users with xtables geoip, out of country is vacation users with no life :)

You must have a small user base if you can block users who are out of the country. Even with my very small server I’ve had legitimate users connect from at least a dozen countries in the last year. Not everyone who travels abroad is doing it for vacation. I have one user who is often in the far east or India and another who is often in numerous African countries, all for business.

The proper thing to do is to setup authentication on port 587 and only use that for submitting mail (that is, do not allow submission on port 25 at all) and then use something like sshguard or fail2ban to blacklist repeated unauthorized connections.

I simply block ssh access at all unless it is from inside the LAN or from one specific IP address, so to get to my servers I have to ssh to ServerA which is the only server allowed external access to ssh on my mail web and DNS servers.

-- I intend to live forever -- so far, so good!

Am 03.03.2015 um 00:45 schrieb Benny Pedersen:

On March 2, 2015 10:50:59 PM Dave McGuire mcguire@neurotica.com wrote:

...

On 03/02/2015 05:34 AM, Joseph Tam wrote:

...

...

...

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

its not a big hint its not called denynets is it ?

...

I myself just want a mechanism to deny certain IP addresses when I spot them, regardless of the implementation. But anything that offloads my mail servers from anything that doesn't involve serving mail makes me happy.

fokus on not blocking 500000 ips, but that users not have 500000 ips

if the server is just for you, your brother and his wife

i will stop saying this again

better so