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:
>>
>>
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
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!
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
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
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
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
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
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
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
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
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 ->
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
>
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
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
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.
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
17 matches
Mail list logo