Fwd: Re: IP drop list

[Jim Pazarena]

On 2015-03-02 2:02 AM, 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.

I am the original poster and just came back to this thread. When the
first couple replies were "fail2ban" I lost interest.

The reason I contemplated a flat text scan by dovecot is because, for
the most part, my dovecot is low volume. So even if parsing a flat text
file is less 'efficient' than a firewall insertion, it WOULD serve to
defeat dictionary attacks rather readily. I already have a routine which
scans my dovecot logs for goofy attacks such as dictionary or 12345
attempts. And since the attacks are pop/IMAP only, that is the only
avenue which I wanted to defeat.

This question garnered lots and lots of responses and I appreciate them
all and read them all. And out of all the responses I think I will
pursue the ipset routine. It seems easy enough and can act at the
firewall level. The DNS RBL would be cool.

I am also cognizant that 45,000 SHOULD have a TTL. However, these were
IPs attempting to fetch email with obviously hacker type passwords.
If, later, a given IP is re-assigned to a 'legitimate' person, they
would still be able to send an email to me ' postmaster@ ' asking
about an inability to fetch email.

But parsing the flat text file would STILL be my preference. I'll look
at the source and see if I can figure out where to inject such code.
Like I said, my dovecot is low volume, so a fraction of a second at
connection time is low impact. Considering that the flat text file
may hang around in the memory cache it could even be less impact than
low.