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.
On 04 Mar 2015, at 21:46 , Jim Pazarena <dovecot at paz.bz> wrote:> 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.Why? Fail2ban is simple to install, simple to setup, and then (and here?s the best part) then you never have to look at it again. -- Death is caused by swallowing small amounts of saliva over a long period of time.
Am 05.03.2015 um 20:23 schrieb @lbutlr:> On 04 Mar 2015, at 21:46 , Jim Pazarena <dovecot at paz.bz> wrote: >> 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. > > Why? Fail2ban is simple to install, simple to setup, and then (and here?s the best part) then you never have to look at it againfail2ban is simple to install and to setup? *lol* yes if you have 99% out-of-the-box distribution configurations, igave it a try not so long ago and honestly the whole config snippets and log-parsing is a mess where i call it insane to give that stuff root permissions even on my private testserver -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20150305/db6fc888/attachment.sig>
Am 05.03.2015 um 20:23 schrieb @lbutlr:> On 04 Mar 2015, at 21:46 , Jim Pazarena <dovecot at paz.bz> wrote: >> 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. > > Why? Fail2ban is simple to install, simple to setup, and then (and here?s the best part) then you never have to look at it again. >I like fail2ban, but related to its design it is slow, i.e it was never fast enough to drop massive smtp botnets in time at one of my servers. 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