[Dovecot] dnsbl feature for dovecot

[John Fawcett]

On 03/07/13 12:47, Professa Dementia wrote:
> On 7/3/2013 12:35 AM, John Fawcett wrote:
>
>> The point is to stop spambot connections to pop and
>> imap (which are usually done to try and steal
>> credentials).
> This is not the usual way spambots work.  Generally, spambots scrape
> addresses from various sources in order to get lists of emails to send
> spam to.
>
> What you seem to be experiencing may be zombie nets trying to brute
> force credentials so they can then send spam from compromised accounts.
>  This is a different beast with a different solution.
Yes I have evidence that passwords found by brute force on pop3
were then used to send email via smtp.
>
> Regardless, you have a spcific problem that needs addressing.
>
> I ran an ISP for almost two decades and have dealt with these issues
> myself.  My recommendations:
>
> 1) Enforce strong user passwords.  I use 12 characters minimum.  14
> characters or more would be better, but this length starts to make it
> hard for mere humans to remember.  Enforce a rule that the password
> contains at least 2 or 3 of the following: lower case letter, upper case
> letter, digit, and symbol which is not one of the prior three.
>
> Some systems require the user's password have all four.  This actually
> weakens the password (if you care to know why, I can go into the math in
> a later post).
>
> After enforcing your chosen rules, run the password through cracklib
> before accepting it from the user.  Or even better, what I started doing
> was having the system generate passwords and not let the user choose
> their own.  Initially people grumbled a bit, but they soon got used to
> it and security was much better.
>
>
> 2) Fail2Ban with rules that seem like they are pretty weak, but trust
> me, they work fine and you limit complaints from users.
>
>   a) If you get 3 invalid login attempts within a minute from more than
> 1 IP address, block that login for 10 minutes.  If you have blocked a
> login and another attempt to log in to that account is made then tarpit
> that connection.  Usually 60 seconds is sufficient.  Do not extend the
> original block time past the original 10 minutes.
>   b)  If you get 5 invalid login attempts within a minute from the same
> IP, block that IP for 5 minutes.  This is usually a valid user who
> forgot their password, as opposed to a) which is usually a malicious
> third party.
>
> Some of this you can do with off the shelf tools, some of it may require
> some glue code (Perl or Python works nicely) on your part.  If you can
> implement this, it will stop the abuse cold.
>
>
> 1) provides security and makes brute forcing infeasible.  2) helps
> reduce load on your systems.
these look like good suggestions.
>> I was imagining a distributed solution which is already
>> in use in many mtas applied also to imap and pop
>> so that connections could be stopped from the first
>> one.
>>
>> I am assuming that if there is such a feature then data is
>> available (e.g. sorbs) or if not yet being collected that it
>> could be done.
> I feel your pain and frustration.  I do not believe there is an RBL list
> of offending IP's for brute force attacks and I think one would be hard
> to build and keep up to date enough to be useful, since most of these
> systems are compromised home computers, but they get fixed and there is
> a lot of turnover - infected systems are repaired and new ones infected.
>
> Most of them are in the far east, so if you do not mind applying a
> cudgel to the problem, you can block entire ranges of IPs altogether.
> Of course, one of your users traveling to one of those areas would need
> to use some other method to access email (mobile device, webmail, etc).
>
> Dem
I take the point that ips in such a dnsbl would probably have a
short life span.

However, whatever may be the difficulties, such a list would not
make sense if there is no functionality in the server to use it.
I am going to look into Timo's suggestion though on tcpwrappers
to see how this would work.

John