Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-13 Thread SZÉPE Viktor
Try entering your log line and the failregex here http://debuggex.com Idézem/Quoting Nathan Harris : > On 7/8/2016 6:06 PM, SZÉPE Viktor wrote: >> Please consider reading and understanding these Courier ban rules: >> >>

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-13 Thread Nathan Harris
On 7/8/2016 6:06 PM, SZÉPE Viktor wrote: > Please consider reading and understanding these Courier ban rules: > > https://github.com/szepeviktor/debian-server-tools/tree/master/security/fail2ban-conf/filter.d > > > These rules and overrides have been very helpful. However, there does not seem to

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-12 Thread Nathan Harris
On 7/8/2016 6:06 PM, SZÉPE Viktor wrote: > Please consider reading and understanding these Courier ban rules: > > https://github.com/szepeviktor/debian-server-tools/tree/master/security/fail2ban-conf/filter.d > > Both this link and your other email are very helpful. Thanks!

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-12 Thread Nathan Harris
On 7/8/2016 5:42 PM, Sam Varshavchik wrote: > Nathan Harris writes: > >> For a while now our server has been seeing a lot of brute force >> authentication attacks. Of course the source of these attacks is >> constantly changing. My firewall (pfSense) is running Snort and I am >> using the

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-12 Thread Nathan Harris
On 7/8/2016 5:43 PM, Sam Varshavchik wrote: > Nathan Harris writes: > >> >> On 7/8/2016 10:58 AM, Gordon Messmer wrote: >> > On 07/08/2016 06:49 AM, Nathan Harris wrote: >> >> Is there anything more >> >> sophisticated or a better approach to solving this problem? >> > I'd recommend that you not

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-09 Thread Alessandro Vesely
On Sat 09/Jul/2016 00:32:32 +0200 Gordon Messmer wrote: > On 07/08/2016 03:04 PM, Alexei Batyr' wrote: >> >> Unfortunately spamers/fishers et al. already mastered SSL and STARTTLS and >> successfully use them in brute force and other attacks. > > I'd expect so. I didn't recommend TLS as a measure

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread Gordon Messmer
On 07/08/2016 03:04 PM, Alexei Batyr' wrote: > > Unfortunately spamers/fishers et al. already mastered SSL and STARTTLS and > successfully use them in brute force and other attacks. I'd expect so. I didn't recommend TLS as a measure against brute-force attacks, I recommended it to protect

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread SZÉPE Viktor
You may discover some networks that are malicious (shadow nets) I maintain a list of these https://github.com/szepeviktor/debian-server-tools/tree/master/security/myattackers-ipsets Use the shell scripts provided. And take a look at iptables rule counters weekly so you know how successful they

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread SZÉPE Viktor
Please consider reading and understanding these Courier ban rules: https://github.com/szepeviktor/debian-server-tools/tree/master/security/fail2ban-conf/filter.d Idézem/Quoting Sam Varshavchik : > Nathan Harris writes: > >> For a while now our server has been seeing a

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread Alexei Batyr'
Gordon Messmer writes: > Authentication over plain text is only allowed if ESMTPAUTH is set in > etc/courier/esmtpd. To maintain password security, that setting should > be empty. Instead, use ESMTPAUTH_TLS to enable authentication only > after TLS is initialized. Unfortunately spamers/fishers

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread Sam Varshavchik
Nathan Harris writes: On 7/8/2016 10:58 AM, Gordon Messmer wrote: > On 07/08/2016 06:49 AM, Nathan Harris wrote: >> Is there anything more >> sophisticated or a better approach to solving this problem? > I'd recommend that you not allow authentication on any non-encrypted > protocols, and

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread Sam Varshavchik
Nathan Harris writes: For a while now our server has been seeing a lot of brute force authentication attacks. Of course the source of these attacks is constantly changing. My firewall (pfSense) is running Snort and I am using the following custom rules to help. alert tcp $SMTP_SERVERS 25 ->

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread Nathan Harris
On 7/8/2016 2:23 PM, Gordon Messmer wrote: > >> As far as rejecting/disabling smtp authentication, I was not aware there was >> a setting for this. > Authentication over plain text is only allowed if ESMTPAUTH is set in > etc/courier/esmtpd. To maintain password security, that setting should >

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread Gordon Messmer
On 07/08/2016 09:54 AM, Nathan Harris wrote: > Gordon, first let me start with a big thank you for pythonfilter which I > have used for years. Cool. Glad to hear it! > As far as rejecting/disabling smtp authentication, I was not aware there was > a setting for this. Authentication over

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread Nathan Harris
On 7/8/2016 10:58 AM, Gordon Messmer wrote: > On 07/08/2016 06:49 AM, Nathan Harris wrote: >> Is there anything more >> sophisticated or a better approach to solving this problem? > I'd recommend that you not allow authentication on any non-encrypted > protocols, and that'll only leave log

Re: [courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread Gordon Messmer
On 07/08/2016 06:49 AM, Nathan Harris wrote: > Is there anything more > sophisticated or a better approach to solving this problem? I'd recommend that you not allow authentication on any non-encrypted protocols, and that'll only leave log analysis tools like fail2ban as options.

[courier-users] Blocking Brute Force Auth Attacks

2016-07-08 Thread Nathan Harris
For a while now our server has been seeing a lot of brute force authentication attacks. Of course the source of these attacks is constantly changing. My firewall (pfSense) is running Snort and I am using the following custom rules to help. alert tcp $SMTP_SERVERS 25 -> $EXTERNAL_NET any