Re: [qmailtoaster] ssl problem

[Andrew Swartz]

Also remember that SSLv3 refers to two different things:

1.  The SSLv3 protocol

2.  The SSLv3 ciphers (known as the ciphersuite).

In the s_client output below, it uses the SSLv3 protocol to negotiate NO 
cipher (i.e. the "Cipher is (NONE)" part).  It establishes a plaintext 
session using the SSLv3 protocol.


Excluding SSLv3 ciphers does not exclude the SSLv3 protocol.  You must 
explicitly exclude both (i.e. the SSLv3 protocol is vulnerable, as are 
some of its ciphers).


You can separately specify protocols and ciphers in the Dovecot config 
file, but I don't remember any way to do it for qmail.


There is a roundabout way, but it has consequences.  SSLv3, TLSv1, 
TLSv1_1 protocols all used the same ciphers (i.e. the SSLv3 ciphers). 
The only way to use the cipher string to forbid the SSLv3 protocol is to 
allow ONLY the TLSv1_2 ciphers.  That works because TLSv1_2 protocol 
introduced new ciphers which are not supported in the older protocols, 
so specifying only TLSv1_2 ciphers forces the TLSv1_2 protocol. However, 
requiring TLSv1_2 protocol has the unintended problem that many older 
OS's (such as CENTOS-5) cannot connect to it because they do not support 
TLSv1_2.


This is not a problem in newer OS's because SSLv3 protocol has been 
removed from newer versions of OpenSSL, so you can pick a ciphersuite 
with the strongest of the old ciphers and it will use the TLSv1 and/or 
TLSv1_1 protocols, which are supported by most older OS's.


If you are savvy/brave enough (I am not), you can recompile OpenSSL with 
SSLv3 protocol disabled.  That is really the effect you want, and may be 
the only way to get it for incoming connections to qmail.


This has been a very long-winded way to say that I don't think you can 
easily accomplish that which you wish.


FYI: this is the issue which prompted me to upgrade from Centos5 to Centos7.

-Andy


PS: It would be nice to have a qmail patch which allows specifying the 
protocols in a file called /control/tlsserverprotocols.






On 4/22/2020 2:53 PM, Eric Broch wrote:
Doesn't '!SSLv3' in your ciphers mean NO SSLv3 is accepted? So, your 
command should be


openssl s_client -connect mx.domain.ltd:25 -starttls smtp -no_ssl3

not the following command which forces ssl3...

openssl s_client -connect mx.domain.ltd:25 -starttls smtp -ssl3

Correct?

On 4/22/2020 9:57 AM, natan maciej milaszewski wrote:

Hi
I have a debian8 and qmail with tcpserver

I have big problem with disable sslv3 - or I dont understand


i crate /var/qmail/control/tlsserverciphers
and put:
ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:+HIGH:+MEDIUM

naw I restart qmail via svc:

svc -d /service/qmail-smtpd
svc -u /service/qmail-smtpd
svc -d /service/qmail
svc -u /service/qmail


and tested via openssl s_client -connect host:25 -starttls smtp -ssl3
and I thinking sslv3 working


openssl s_client -connect mx.domain.ltd:25 -starttls smtp -ssl3
CONNECTED(0003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 127 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
 Protocol  : SSLv3
 Cipher    : 
 Session-ID:
 Session-ID-ctx:
 Master-Key:
 Key-Arg   : None
 Krb5 Principal: None
 PSK identity: None
 PSK identity hint: None
 Start Time: 1587570345
 Timeout   : 7200 (sec)
 Verify return code: 0 (ok)
---

What i doing wrong ?



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Andrew Swartz]

If the problem is arising during the TLS negotiation, then there will 
never be an SMTP session started and therefore there will never be an 
attempt to even submit a password.


I do not think that a TLS negotiation problem will show up in any 
mail-related log file.  I've yet to find it in any log file.


-Andy





On 4/22/2020 5:17 PM, David Bray wrote:

no - but vchkpw, also spamdyke does

so this is blocking people that are providing bad passwords etc ...
but agree, still trying to work out who is doing something other than this

David Bray
0418 745334
2 ∞ & <


On Thu, 23 Apr 2020 at 11:15, Remo Mattei > wrote:


qmail does not log to maillog.
Remo

Inviato da iPad


Il giorno 22 apr 2020, alle ore 5:36 PM, David Bray
mailto:da...@brayworth.com.au>> ha scritto:


I agree, have them in place already, they are winners

  * I actually disagree slightly, if I'm not mistaken - it would
be better to have those two entries combined, wouldn't
fail2ban parse the maillog twice in his example ?

I use:
failregex = vchkpw-smtps?: vpopmail user not found .*:
            vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*:
            spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: 
origin_rdns:.*$

But - I'm not getting log entries for these guys, maillog is all
silent I watch /var/log/qmail/smtps/current float up and down, CPU
goes up and down, but /var/log/maillog is all silent

David Bray
0418 745334
2 ∞ & <


On Thu, 23 Apr 2020 at 00:06, Jaime Lerner
mailto:jaimeler...@geekgoddess.com>>
wrote:

David,

__ __

You might try the suggestions here:
https://www.taverner-rich.com/mitigating-brute-force-attacks/

__ __

I put them in place on my server and it definitely helped.

__ __

Jaime

__ __

*From: *Eric Broch mailto:ebr...@whitehorsetc.com>>
*Reply-To: *mailto:qmailtoaster-list@qmailtoaster.com>>
*Date: *Wednesday, April 22, 2020 at 9:40 AM
*To: *mailto:qmailtoaster-list@qmailtoaster.com>>
*Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?

__ __

Hi David,

I think you're on to something with fail2ban (keying off
maillog). I was monitoring my smtps port (watching the
certificate and encryption scroll by) using /usr/bin/recordio
and /var/log/maillog and found that the bad guys are trying to
login. Here are some failures from maillog:

vchkpw-smtps: vpopmail user not found
testforu...@whitehorsetc.com:92.118.38.83


vchkpw-smtps: password fail (pass: 'somepassword')
someu...@whitehorsetc.com:185.50.149.2


Maybe a fail2ban rule?!

Eric

__ __

On 4/18/2020 4:12 AM, David Bray wrote:

Hi thanks - yes can block that IP

But it’s not just one, and the solution is not fine enough

I want more of a fail2ban rule, bad use bad pass 3 strikes
your out

__ __

I need to know they are mucking round.

__ __

I tried sending myself through the port with a bad
password- sure it blocks it, but there is no log of the
event - it looks like a legit, connection from Ann IP

__ __

On Sat, 18 Apr 2020 at 7:30 pm, Chris mailto:boh...@gmail.com>> wrote:

Here's a great article with instructions on how to
implement an IP blacklist in iptables. Unless you've
got a user in Panama, it looks like you's want to
block 141.98.80.30 



https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/

__ __

On Sat, Apr 18, 2020 at 5:49 PM David Bray
mailto:da...@brayworth.com.au>> wrote:

sure - thanks for replying, this comes in waves
taking the server to it's maximum at times 

__ __

as far as I can see this only logs are this:

__ __

==> /var/log/qmail/smtps/current <==
2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
2020-04-18 05:04:48.480785500 tcpserver: pid 13339
from 141.98.80.30
2020-04-18 05:04:48.480787500 tcpserver: ok 13339
dev.brayworth.com:172.105.181.18:465
:141.98.80.30::25638
2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
2020-04-18 05:04:52.830767500 tcpserver: pid 13340
from 

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Eric Broch]

#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` 
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
RECORDIO=""
RECORDIO="/usr/bin/recordio"
export SMTPS=1
export FORCETLS=0
export SMTPAUTH="!"

exec /usr/bin/softlimit -m 12800 \
/usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 465 \
$RECORDIO \
$SMTPD $VCHKPW /bin/true 2>&1



⁣Get BlueMail for Android ​

On Apr 22, 2020, 6:38 PM, at 6:38 PM, David Bray  wrote:
>Could I ask you command line for recordio
>Thanks in advance
>David Bray
>0418 745334
>2 ∞ & <
>
>
>On Wed, 22 Apr 2020 at 23:40, Eric Broch 
>wrote:
>
>> Hi David,
>>
>> I think you're on to something with fail2ban (keying off maillog). I
>was
>> monitoring my smtps port (watching the certificate and encryption
>scroll
>> by) using /usr/bin/recordio and /var/log/maillog and found that the
>bad
>> guys are trying to login. Here are some failures from maillog:
>>
>> vchkpw-smtps: vpopmail user not found
>> testforu...@whitehorsetc.com:92.118.38.83
>>
>> vchkpw-smtps: password fail (pass: 'somepassword')
>> someu...@whitehorsetc.com:185.50.149.2
>>
>> Maybe a fail2ban rule?!
>>
>> Eric
>>
>>
>> On 4/18/2020 4:12 AM, David Bray wrote:
>>
>> Hi thanks - yes can block that IP
>> But it’s not just one, and the solution is not fine enough
>> I want more of a fail2ban rule, bad use bad pass 3 strikes your out
>>
>> I need to know they are mucking round.
>>
>> I tried sending myself through the port with a bad password- sure it
>> blocks it, but there is no log of the event - it looks like a legit,
>> connection from Ann IP
>>
>> On Sat, 18 Apr 2020 at 7:30 pm, Chris  wrote:
>>
>>> Here's a great article with instructions on how to implement an IP
>>> blacklist in iptables. Unless you've got a user in Panama, it looks
>like
>>> you's want to block 141.98.80.30
>>>
>>>
>https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/
>>>
>>> On Sat, Apr 18, 2020 at 5:49 PM David Bray 
>>> wrote:
>>>
 sure - thanks for replying, this comes in waves taking the server
>to
 it's maximum at times

 as far as I can see this only logs are this:

 ==> /var/log/qmail/smtps/current <==
 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from
>141.98.80.30
 2020-04-18 05:04:48.480787500 tcpserver: ok 13339
>dev.brayworth.com:172.105.181.18:465
 :141.98.80.30::25638
 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from
>141.98.80.30
 2020-04-18 05:04:52.830768500 tcpserver: ok 13340
>dev.brayworth.com:172.105.181.18:465
 :141.98.80.30::14862
 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from
>141.98.80.30
 2020-04-18 05:04:57.304006500 tcpserver: ok 13342
>dev.brayworth.com:172.105.181.18:465
 :141.98.80.30::9646
 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from
>141.98.80.30
 2020-04-18 05:05:01.902266500 tcpserver: ok 13345
>dev.brayworth.com:172.105.181.18:465
 :141.98.80.30::54058
 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60

 David Bray
 0418 745334
 2 ∞ & <


 On Sat, 18 Apr 2020 at 15:41, Eric Broch 
 wrote:

> Can you send the log of one of the "bad" connections?
>
> On 4/17/2020 10:59 PM, David Bray wrote:
>
> I can see I'm getting hammered on my smtps port
>
> How can I mitigate this?
>
> I can see the IP's in /var/log/qmail/smtps/current
>
> *but where do I actually see that the smtp auth actually fails ?*
>
> or do I need to increase the logging somewhere ?
>
> if I tail -f /var/log/dovecot.log
>
> I can see the imap and pop failures
>
> thanks in advance
>
> David Bray
> 0418 745334
> 2 ∞ & <
>
> --
>> # David
>>
>>

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Eric Broch]

Simscan as well and whatever it calls...clamd, spamd, ...

⁣Get BlueMail for Android ​

On Apr 22, 2020, 7:18 PM, at 7:18 PM, David Bray  wrote:
>no - but vchkpw, also spamdyke does
>
>so this is blocking people that are providing bad passwords etc ...
>but agree, still trying to work out who is doing something other than
>this
>
>David Bray
>0418 745334
>2 ∞ & <
>
>
>On Thu, 23 Apr 2020 at 11:15, Remo Mattei  wrote:
>
>> qmail does not log to maillog.
>> Remo
>>
>> Inviato da iPad
>>
>> Il giorno 22 apr 2020, alle ore 5:36 PM, David Bray <
>> da...@brayworth.com.au> ha scritto:
>>
>> 
>> I agree, have them in place already, they are winners
>>
>>- I actually disagree slightly, if I'm not mistaken - it would be
>>better to have those two entries combined, wouldn't fail2ban parse
>the
>>maillog twice in his example ?
>>
>> I use:
>> failregex = vchkpw-smtps?: vpopmail user not found .*:
>> vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*:
>> spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: 
>> origin_rdns:.*$
>>
>> But - I'm not getting log entries for these guys, maillog is all
>silent I
>> watch /var/log/qmail/smtps/current float up and down, CPU goes up and
>down,
>> but /var/log/maillog is all silent
>>
>> David Bray
>> 0418 745334
>> 2 ∞ & <
>>
>>
>> On Thu, 23 Apr 2020 at 00:06, Jaime Lerner
>
>> wrote:
>>
>>> David,
>>>
>>>
>>>
>>> You might try the suggestions here:
>>> https://www.taverner-rich.com/mitigating-brute-force-attacks/
>>>
>>>
>>>
>>> I put them in place on my server and it definitely helped.
>>>
>>>
>>>
>>> Jaime
>>>
>>>
>>>
>>> *From: *Eric Broch 
>>> *Reply-To: *
>>> *Date: *Wednesday, April 22, 2020 at 9:40 AM
>>> *To: *
>>> *Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?
>>>
>>>
>>>
>>> Hi David,
>>>
>>> I think you're on to something with fail2ban (keying off maillog). I
>was
>>> monitoring my smtps port (watching the certificate and encryption
>scroll
>>> by) using /usr/bin/recordio and /var/log/maillog and found that the
>bad
>>> guys are trying to login. Here are some failures from maillog:
>>>
>>> vchkpw-smtps: vpopmail user not found
>>> testforu...@whitehorsetc.com:92.118.38.83
>>>
>>> vchkpw-smtps: password fail (pass: 'somepassword')
>>> someu...@whitehorsetc.com:185.50.149.2
>>>
>>> Maybe a fail2ban rule?!
>>>
>>> Eric
>>>
>>>
>>>
>>> On 4/18/2020 4:12 AM, David Bray wrote:
>>>
>>> Hi thanks - yes can block that IP
>>>
>>> But it’s not just one, and the solution is not fine enough
>>>
>>> I want more of a fail2ban rule, bad use bad pass 3 strikes your out
>>>
>>>
>>>
>>> I need to know they are mucking round.
>>>
>>>
>>>
>>> I tried sending myself through the port with a bad password- sure it
>>> blocks it, but there is no log of the event - it looks like a legit,
>>> connection from Ann IP
>>>
>>>
>>>
>>> On Sat, 18 Apr 2020 at 7:30 pm, Chris  wrote:
>>>
>>> Here's a great article with instructions on how to implement an IP
>>> blacklist in iptables. Unless you've got a user in Panama, it looks
>like
>>> you's want to block 141.98.80.30
>>>
>>>
>>>
>https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/
>>>
>>>
>>>
>>> On Sat, Apr 18, 2020 at 5:49 PM David Bray 
>>> wrote:
>>>
>>> sure - thanks for replying, this comes in waves taking the server to
>it's
>>> maximum at times
>>>
>>>
>>>
>>> as far as I can see this only logs are this:
>>>
>>>
>>>
>>> ==> /var/log/qmail/smtps/current <==
>>> 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
>>> 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30
>>> 2020-04-18 05:04:48.480787500 tcpserver: ok 13339
>dev.brayworth.com:172.105.181.18:465
>>> :141.98.80.30::25638
>>> 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
>>> 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30
>>> 2020-04-18 05:04:52.830768500 tcpserver: ok 13340
>dev.brayworth.com:172.105.181.18:465
>>> :141.98.80.30::14862
>>> 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
>>> 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30
>>> 2020-04-18 05:04:57.304006500 tcpserver: ok 13342
>dev.brayworth.com:172.105.181.18:465
>>> :141.98.80.30::9646
>>> 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
>>> 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30
>>> 2020-04-18 05:05:01.902266500 tcpserver: ok 13345
>dev.brayworth.com:172.105.181.18:465
>>> :141.98.80.30::54058
>>> 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
>>> 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
>>> 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
>>> 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
>>> 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
>>> 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60
>>>
>>>
>>> David Bray
>>>
>>> 0418 745334
>>> 2 ∞ & <
>>>
>>>
>>>
>>>
>>>
>>> On Sat, 18 Apr 2020 at 15:41, Eric Broch 
>wrote:
>>>
>>> Can you send the log of one of the "bad" connections?

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[David Bray]

no - but vchkpw, also spamdyke does

so this is blocking people that are providing bad passwords etc ...
but agree, still trying to work out who is doing something other than this

David Bray
0418 745334
2 ∞ & <


On Thu, 23 Apr 2020 at 11:15, Remo Mattei  wrote:

> qmail does not log to maillog.
> Remo
>
> Inviato da iPad
>
> Il giorno 22 apr 2020, alle ore 5:36 PM, David Bray <
> da...@brayworth.com.au> ha scritto:
>
> 
> I agree, have them in place already, they are winners
>
>- I actually disagree slightly, if I'm not mistaken - it would be
>better to have those two entries combined, wouldn't fail2ban parse the
>maillog twice in his example ?
>
> I use:
> failregex = vchkpw-smtps?: vpopmail user not found .*:
> vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*:
> spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: 
> origin_rdns:.*$
>
> But - I'm not getting log entries for these guys, maillog is all silent I
> watch /var/log/qmail/smtps/current float up and down, CPU goes up and down,
> but /var/log/maillog is all silent
>
> David Bray
> 0418 745334
> 2 ∞ & <
>
>
> On Thu, 23 Apr 2020 at 00:06, Jaime Lerner 
> wrote:
>
>> David,
>>
>>
>>
>> You might try the suggestions here:
>> https://www.taverner-rich.com/mitigating-brute-force-attacks/
>>
>>
>>
>> I put them in place on my server and it definitely helped.
>>
>>
>>
>> Jaime
>>
>>
>>
>> *From: *Eric Broch 
>> *Reply-To: *
>> *Date: *Wednesday, April 22, 2020 at 9:40 AM
>> *To: *
>> *Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?
>>
>>
>>
>> Hi David,
>>
>> I think you're on to something with fail2ban (keying off maillog). I was
>> monitoring my smtps port (watching the certificate and encryption scroll
>> by) using /usr/bin/recordio and /var/log/maillog and found that the bad
>> guys are trying to login. Here are some failures from maillog:
>>
>> vchkpw-smtps: vpopmail user not found
>> testforu...@whitehorsetc.com:92.118.38.83
>>
>> vchkpw-smtps: password fail (pass: 'somepassword')
>> someu...@whitehorsetc.com:185.50.149.2
>>
>> Maybe a fail2ban rule?!
>>
>> Eric
>>
>>
>>
>> On 4/18/2020 4:12 AM, David Bray wrote:
>>
>> Hi thanks - yes can block that IP
>>
>> But it’s not just one, and the solution is not fine enough
>>
>> I want more of a fail2ban rule, bad use bad pass 3 strikes your out
>>
>>
>>
>> I need to know they are mucking round.
>>
>>
>>
>> I tried sending myself through the port with a bad password- sure it
>> blocks it, but there is no log of the event - it looks like a legit,
>> connection from Ann IP
>>
>>
>>
>> On Sat, 18 Apr 2020 at 7:30 pm, Chris  wrote:
>>
>> Here's a great article with instructions on how to implement an IP
>> blacklist in iptables. Unless you've got a user in Panama, it looks like
>> you's want to block 141.98.80.30
>>
>>
>> https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/
>>
>>
>>
>> On Sat, Apr 18, 2020 at 5:49 PM David Bray 
>> wrote:
>>
>> sure - thanks for replying, this comes in waves taking the server to it's
>> maximum at times
>>
>>
>>
>> as far as I can see this only logs are this:
>>
>>
>>
>> ==> /var/log/qmail/smtps/current <==
>> 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
>> 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30
>> 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 
>> dev.brayworth.com:172.105.181.18:465
>> :141.98.80.30::25638
>> 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
>> 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30
>> 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 
>> dev.brayworth.com:172.105.181.18:465
>> :141.98.80.30::14862
>> 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
>> 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30
>> 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 
>> dev.brayworth.com:172.105.181.18:465
>> :141.98.80.30::9646
>> 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
>> 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30
>> 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 
>> dev.brayworth.com:172.105.181.18:465
>> :141.98.80.30::54058
>> 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
>> 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
>> 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
>> 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
>> 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
>> 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60
>>
>>
>> David Bray
>>
>> 0418 745334
>> 2 ∞ & <
>>
>>
>>
>>
>>
>> On Sat, 18 Apr 2020 at 15:41, Eric Broch  wrote:
>>
>> Can you send the log of one of the "bad" connections?
>>
>> On 4/17/2020 10:59 PM, David Bray wrote:
>>
>> I can see I'm getting hammered on my smtps port
>>
>>
>>
>> How can I mitigate this?
>>
>>
>>
>> I can see the IP's in /var/log/qmail/smtps/current
>>
>>
>>
>> *but where do I actually see that the smtp auth actually fails ?*
>>
>>
>>
>> or do I need to 

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Remo Mattei]

qmail does not log to maillog. 
Remo 

Inviato da iPad

> Il giorno 22 apr 2020, alle ore 5:36 PM, David Bray  
> ha scritto:
> 
> 
> I agree, have them in place already, they are winners
> I actually disagree slightly, if I'm not mistaken - it would be better to 
> have those two entries combined, wouldn't fail2ban parse the maillog twice in 
> his example ?
> I use:
> failregex = vchkpw-smtps?: vpopmail user not found .*:
> vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*:
> spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip:  
> origin_rdns:.*$
> 
> But - I'm not getting log entries for these guys, maillog is all silent I 
> watch /var/log/qmail/smtps/current float up and down, CPU goes up and down, 
> but /var/log/maillog is all silent
> 
> David Bray
> 0418 745334
> 2 ∞ & <
> 
> 
>> On Thu, 23 Apr 2020 at 00:06, Jaime Lerner  
>> wrote:
>> David,
>> 
>>  
>> 
>> You might try the suggestions here: 
>> https://www.taverner-rich.com/mitigating-brute-force-attacks/
>> 
>>  
>> 
>> I put them in place on my server and it definitely helped.
>> 
>>  
>> 
>> Jaime
>> 
>>  
>> 
>> From: Eric Broch 
>> Reply-To: 
>> Date: Wednesday, April 22, 2020 at 9:40 AM
>> To: 
>> Subject: Re: [qmailtoaster] SMTPS Port - Who is Failing ?
>> 
>>  
>> 
>> Hi David,
>> 
>> I think you're on to something with fail2ban (keying off maillog). I was 
>> monitoring my smtps port (watching the certificate and encryption scroll by) 
>> using /usr/bin/recordio and /var/log/maillog and found that the bad guys are 
>> trying to login. Here are some failures from maillog:
>> 
>> vchkpw-smtps: vpopmail user not found 
>> testforu...@whitehorsetc.com:92.118.38.83
>> 
>> vchkpw-smtps: password fail (pass: 'somepassword') 
>> someu...@whitehorsetc.com:185.50.149.2
>> 
>> Maybe a fail2ban rule?!
>> 
>> Eric
>> 
>>  
>> 
>> On 4/18/2020 4:12 AM, David Bray wrote:
>> 
>> Hi thanks - yes can block that IP
>> 
>> But it’s not just one, and the solution is not fine enough
>> 
>> I want more of a fail2ban rule, bad use bad pass 3 strikes your out
>> 
>>  
>> 
>> I need to know they are mucking round.
>> 
>>  
>> 
>> I tried sending myself through the port with a bad password- sure it blocks 
>> it, but there is no log of the event - it looks like a legit, connection 
>> from Ann IP
>> 
>>  
>> 
>> On Sat, 18 Apr 2020 at 7:30 pm, Chris  wrote:
>> 
>> Here's a great article with instructions on how to implement an IP blacklist 
>> in iptables. Unless you've got a user in Panama, it looks like you's want to 
>> block 141.98.80.30
>> 
>> 
>> https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/
>> 
>>  
>> 
>> On Sat, Apr 18, 2020 at 5:49 PM David Bray  wrote:
>> 
>> sure - thanks for replying, this comes in waves taking the server to it's 
>> maximum at times
>> 
>>  
>> 
>> as far as I can see this only logs are this:
>> 
>>  
>> 
>> ==> /var/log/qmail/smtps/current <==
>> 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
>> 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30
>> 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 
>> dev.brayworth.com:172.105.181.18:465 :141.98.80.30::25638
>> 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
>> 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30
>> 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 
>> dev.brayworth.com:172.105.181.18:465 :141.98.80.30::14862
>> 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
>> 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30
>> 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 
>> dev.brayworth.com:172.105.181.18:465 :141.98.80.30::9646
>> 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
>> 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30
>> 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 
>> dev.brayworth.com:172.105.181.18:465 :141.98.80.30::54058
>> 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
>> 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
>> 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
>> 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
>> 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
>> 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60
>> 
>> 
>> 
>> David Bray
>> 
>> 0418 745334
>> 2 ∞ & <
>> 
>>  
>> 
>>  
>> 
>> On Sat, 18 Apr 2020 at 15:41, Eric Broch  wrote:
>> 
>> Can you send the log of one of the "bad" connections?
>> 
>> On 4/17/2020 10:59 PM, David Bray wrote:
>> 
>> I can see I'm getting hammered on my smtps port
>> 
>>  
>> 
>> How can I mitigate this?
>> 
>>  
>> 
>> I can see the IP's in /var/log/qmail/smtps/current
>> 
>>  
>> 
>> but where do I actually see that the smtp auth actually fails ?
>> 
>>  
>> 
>> or do I need to increase the logging somewhere ?
>> 
>>  
>> 
>> if I tail -f /var/log/dovecot.log
>> 
>>  
>> 
>> I can see the imap and pop failures
>> 
>>  
>> 
>> thanks in advance
>> 
>> 
>> 
>> David Bray
>> 
>> 0418 745334
>> 2 ∞ & <
>> 

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[David Bray]

Could I ask you command line for recordio
Thanks in advance
David Bray
0418 745334
2 ∞ & <


On Wed, 22 Apr 2020 at 23:40, Eric Broch  wrote:

> Hi David,
>
> I think you're on to something with fail2ban (keying off maillog). I was
> monitoring my smtps port (watching the certificate and encryption scroll
> by) using /usr/bin/recordio and /var/log/maillog and found that the bad
> guys are trying to login. Here are some failures from maillog:
>
> vchkpw-smtps: vpopmail user not found
> testforu...@whitehorsetc.com:92.118.38.83
>
> vchkpw-smtps: password fail (pass: 'somepassword')
> someu...@whitehorsetc.com:185.50.149.2
>
> Maybe a fail2ban rule?!
>
> Eric
>
>
> On 4/18/2020 4:12 AM, David Bray wrote:
>
> Hi thanks - yes can block that IP
> But it’s not just one, and the solution is not fine enough
> I want more of a fail2ban rule, bad use bad pass 3 strikes your out
>
> I need to know they are mucking round.
>
> I tried sending myself through the port with a bad password- sure it
> blocks it, but there is no log of the event - it looks like a legit,
> connection from Ann IP
>
> On Sat, 18 Apr 2020 at 7:30 pm, Chris  wrote:
>
>> Here's a great article with instructions on how to implement an IP
>> blacklist in iptables. Unless you've got a user in Panama, it looks like
>> you's want to block 141.98.80.30
>>
>> https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/
>>
>> On Sat, Apr 18, 2020 at 5:49 PM David Bray 
>> wrote:
>>
>>> sure - thanks for replying, this comes in waves taking the server to
>>> it's maximum at times
>>>
>>> as far as I can see this only logs are this:
>>>
>>> ==> /var/log/qmail/smtps/current <==
>>> 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
>>> 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30
>>> 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 
>>> dev.brayworth.com:172.105.181.18:465
>>> :141.98.80.30::25638
>>> 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
>>> 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30
>>> 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 
>>> dev.brayworth.com:172.105.181.18:465
>>> :141.98.80.30::14862
>>> 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
>>> 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30
>>> 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 
>>> dev.brayworth.com:172.105.181.18:465
>>> :141.98.80.30::9646
>>> 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
>>> 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30
>>> 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 
>>> dev.brayworth.com:172.105.181.18:465
>>> :141.98.80.30::54058
>>> 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
>>> 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
>>> 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
>>> 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
>>> 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
>>> 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60
>>>
>>> David Bray
>>> 0418 745334
>>> 2 ∞ & <
>>>
>>>
>>> On Sat, 18 Apr 2020 at 15:41, Eric Broch 
>>> wrote:
>>>
 Can you send the log of one of the "bad" connections?

 On 4/17/2020 10:59 PM, David Bray wrote:

 I can see I'm getting hammered on my smtps port

 How can I mitigate this?

 I can see the IP's in /var/log/qmail/smtps/current

 *but where do I actually see that the smtp auth actually fails ?*

 or do I need to increase the logging somewhere ?

 if I tail -f /var/log/dovecot.log

 I can see the imap and pop failures

 thanks in advance

 David Bray
 0418 745334
 2 ∞ & <

 --
> # David
>
>

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[David Bray]

I agree, have them in place already, they are winners

   - I actually disagree slightly, if I'm not mistaken - it would be better
   to have those two entries combined, wouldn't fail2ban parse the maillog
   twice in his example ?

I use:
failregex = vchkpw-smtps?: vpopmail user not found .*:
vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*:
spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: 
origin_rdns:.*$

But - I'm not getting log entries for these guys, maillog is all silent I
watch /var/log/qmail/smtps/current float up and down, CPU goes up and down,
but /var/log/maillog is all silent

David Bray
0418 745334
2 ∞ & <


On Thu, 23 Apr 2020 at 00:06, Jaime Lerner 
wrote:

> David,
>
>
>
> You might try the suggestions here:
> https://www.taverner-rich.com/mitigating-brute-force-attacks/
>
>
>
> I put them in place on my server and it definitely helped.
>
>
>
> Jaime
>
>
>
> *From: *Eric Broch 
> *Reply-To: *
> *Date: *Wednesday, April 22, 2020 at 9:40 AM
> *To: *
> *Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?
>
>
>
> Hi David,
>
> I think you're on to something with fail2ban (keying off maillog). I was
> monitoring my smtps port (watching the certificate and encryption scroll
> by) using /usr/bin/recordio and /var/log/maillog and found that the bad
> guys are trying to login. Here are some failures from maillog:
>
> vchkpw-smtps: vpopmail user not found
> testforu...@whitehorsetc.com:92.118.38.83
>
> vchkpw-smtps: password fail (pass: 'somepassword')
> someu...@whitehorsetc.com:185.50.149.2
>
> Maybe a fail2ban rule?!
>
> Eric
>
>
>
> On 4/18/2020 4:12 AM, David Bray wrote:
>
> Hi thanks - yes can block that IP
>
> But it’s not just one, and the solution is not fine enough
>
> I want more of a fail2ban rule, bad use bad pass 3 strikes your out
>
>
>
> I need to know they are mucking round.
>
>
>
> I tried sending myself through the port with a bad password- sure it
> blocks it, but there is no log of the event - it looks like a legit,
> connection from Ann IP
>
>
>
> On Sat, 18 Apr 2020 at 7:30 pm, Chris  wrote:
>
> Here's a great article with instructions on how to implement an IP
> blacklist in iptables. Unless you've got a user in Panama, it looks like
> you's want to block 141.98.80.30
>
>
> https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/
>
>
>
> On Sat, Apr 18, 2020 at 5:49 PM David Bray  wrote:
>
> sure - thanks for replying, this comes in waves taking the server to it's
> maximum at times
>
>
>
> as far as I can see this only logs are this:
>
>
>
> ==> /var/log/qmail/smtps/current <==
> 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
> 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30
> 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 
> dev.brayworth.com:172.105.181.18:465
> :141.98.80.30::25638
> 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
> 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30
> 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 
> dev.brayworth.com:172.105.181.18:465
> :141.98.80.30::14862
> 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
> 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30
> 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 
> dev.brayworth.com:172.105.181.18:465
> :141.98.80.30::9646
> 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
> 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30
> 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 
> dev.brayworth.com:172.105.181.18:465
> :141.98.80.30::54058
> 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
> 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
> 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
> 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
> 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
> 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60
>
>
> David Bray
>
> 0418 745334
> 2 ∞ & <
>
>
>
>
>
> On Sat, 18 Apr 2020 at 15:41, Eric Broch  wrote:
>
> Can you send the log of one of the "bad" connections?
>
> On 4/17/2020 10:59 PM, David Bray wrote:
>
> I can see I'm getting hammered on my smtps port
>
>
>
> How can I mitigate this?
>
>
>
> I can see the IP's in /var/log/qmail/smtps/current
>
>
>
> *but where do I actually see that the smtp auth actually fails ?*
>
>
>
> or do I need to increase the logging somewhere ?
>
>
>
> if I tail -f /var/log/dovecot.log
>
>
>
> I can see the imap and pop failures
>
>
>
> thanks in advance
>
>
> David Bray
>
> 0418 745334
> 2 ∞ & <
>
> --
>
> # David
>
>

Re: [qmailtoaster] ssl problem

[Eric Broch]

Doesn't '!SSLv3' in your ciphers mean NO SSLv3 is accepted? So, your 
command should be


openssl s_client -connect mx.domain.ltd:25 -starttls smtp -no_ssl3

not the following command which forces ssl3...

openssl s_client -connect mx.domain.ltd:25 -starttls smtp -ssl3

Correct?

On 4/22/2020 9:57 AM, natan maciej milaszewski wrote:

Hi
I have a debian8 and qmail with tcpserver

I have big problem with disable sslv3 - or I dont understand


i crate /var/qmail/control/tlsserverciphers
and put:
ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:+HIGH:+MEDIUM

naw I restart qmail via svc:

svc -d /service/qmail-smtpd
svc -u /service/qmail-smtpd
svc -d /service/qmail
svc -u /service/qmail


and tested via openssl s_client -connect host:25 -starttls smtp -ssl3
and I thinking sslv3 working


openssl s_client -connect mx.domain.ltd:25 -starttls smtp -ssl3
CONNECTED(0003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 127 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
     Protocol  : SSLv3
     Cipher    : 
     Session-ID:
     Session-ID-ctx:
     Master-Key:
     Key-Arg   : None
     Krb5 Principal: None
     PSK identity: None
     PSK identity hint: None
     Start Time: 1587570345
     Timeout   : 7200 (sec)
     Verify return code: 0 (ok)
---

What i doing wrong ?



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] ssl problem

[natan maciej milaszewski]

Hi
I have a debian8 and qmail with tcpserver

I have big problem with disable sslv3 - or I dont understand


i crate /var/qmail/control/tlsserverciphers
and put:
ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:+HIGH:+MEDIUM

naw I restart qmail via svc:

svc -d /service/qmail-smtpd
svc -u /service/qmail-smtpd
svc -d /service/qmail
svc -u /service/qmail


and tested via openssl s_client -connect host:25 -starttls smtp -ssl3
and I thinking sslv3 working


openssl s_client -connect mx.domain.ltd:25 -starttls smtp -ssl3
CONNECTED(0003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 127 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1587570345
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

What i doing wrong ?



-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Solo]

Hi Eric / David.

My vpopmail.conf from fail2ban :

failregex = vchkpw-smtp: vpopmail user not found .*:$
vchkpw-smtps: vpopmail user not found .*:$
vchkpw-smtp: null password given .*:$
vchkpw-smtps: null password given .*:$
vchkpw-submission: null password given .*:$
vchkpw-submission: vpopmail user not found .*:$
vchkpw-submission: password fail .*:$
vchkpw-smtp: password fail .*:$
vchkpw-smtps: password fail .*:$
vchkpw-pop3: vpopmail user not found .*:$


scanning the maillog
and it catches a lot of attempts.

Set find/ban time to Your likings

Regards
/FvB

Den 22-04-2020 kl. 15:39 skrev Eric Broch:

Hi David,

I think you're on to something with fail2ban (keying off maillog). I was 
monitoring my smtps port (watching the certificate and encryption scroll 
by) using /usr/bin/recordio and /var/log/maillog and found that the bad 
guys are trying to login. Here are some failures from maillog:


vchkpw-smtps: vpopmail user not found 
testforu...@whitehorsetc.com:92.118.38.83


vchkpw-smtps: password fail (pass: 'somepassword') 
someu...@whitehorsetc.com:185.50.149.2


Maybe a fail2ban rule?!

Eric


On 4/18/2020 4:12 AM, David Bray wrote:

Hi thanks - yes can block that IP
But it’s not just one, and the solution is not fine enough
I want more of a fail2ban rule, bad use bad pass 3 strikes your out

I need to know they are mucking round.

I tried sending myself through the port with a bad password- sure it 
blocks it, but there is no log of the event - it looks like a legit, 
connection from Ann IP


On Sat, 18 Apr 2020 at 7:30 pm, Chris > wrote:


Here's a great article with instructions on how to implement an IP
blacklist in iptables. Unless you've got a user in Panama, it
looks like you's want to block 141.98.80.30

https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/

On Sat, Apr 18, 2020 at 5:49 PM David Bray mailto:da...@brayworth.com.au>> wrote:

sure - thanks for replying, this comes in waves taking the
server to it's maximum at times

as far as I can see this only logs are this:

==> /var/log/qmail/smtps/current <==
2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from
141.98.80.30
2020-04-18 05:04:48.480787500 tcpserver: ok 13339
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::25638
2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from
141.98.80.30
2020-04-18 05:04:52.830768500 tcpserver: ok 13340
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::14862
2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from
141.98.80.30
2020-04-18 05:04:57.304006500 tcpserver: ok 13342
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::9646
2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from
141.98.80.30
2020-04-18 05:05:01.902266500 tcpserver: ok 13345
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::54058
2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
2020-04-18 05:06:06.141273500 tcpserver: status: 6/60

David Bray
0418 745334
2 ∞ & <


On Sat, 18 Apr 2020 at 15:41, Eric Broch
mailto:ebr...@whitehorsetc.com>> wrote:

Can you send the log of one of the "bad" connections?

On 4/17/2020 10:59 PM, David Bray wrote:


I can see I'm getting hammered on my smtps port

How can I mitigate this?

I can see the IP's in /var/log/qmail/smtps/current

*but where do I actually see that the smtp auth actually
fails ?*

or do I need to increase the logging somewhere ?

if I tail -f /var/log/dovecot.log

I can see the imap and pop failures

thanks in advance

David Bray
0418 745334
2 ∞ & <


--
# David


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Eric Broch]

Thanks, Jaime!

Perfect.


On 4/22/2020 8:06 AM, Jaime Lerner wrote:


David,

You might try the suggestions here: 
https://www.taverner-rich.com/mitigating-brute-force-attacks/


I put them in place on my server and it definitely helped.

Jaime

*From: *Eric Broch 
*Reply-To: *
*Date: *Wednesday, April 22, 2020 at 9:40 AM
*To: *
*Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?

Hi David,

I think you're on to something with fail2ban (keying off maillog). I 
was monitoring my smtps port (watching the certificate and encryption 
scroll by) using /usr/bin/recordio and /var/log/maillog and found that 
the bad guys are trying to login. Here are some failures from maillog:


vchkpw-smtps: vpopmail user not found 
testforu...@whitehorsetc.com:92.118.38.83 



vchkpw-smtps: password fail (pass: 'somepassword') 
someu...@whitehorsetc.com:185.50.149.2 



Maybe a fail2ban rule?!

Eric

On 4/18/2020 4:12 AM, David Bray wrote:

Hi thanks - yes can block that IP

But it’s not just one, and the solution is not fine enough

I want more of a fail2ban rule, bad use bad pass 3 strikes your out

I need to know they are mucking round.

I tried sending myself through the port with a bad password- sure
it blocks it, but there is no log of the event - it looks like a
legit, connection from Ann IP

On Sat, 18 Apr 2020 at 7:30 pm, Chris mailto:boh...@gmail.com>> wrote:

Here's a great article with instructions on how to implement
an IP blacklist in iptables. Unless you've got a user in
Panama, it looks like you's want to block 141.98.80.30


https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/

On Sat, Apr 18, 2020 at 5:49 PM David Bray
mailto:da...@brayworth.com.au>> wrote:

sure - thanks for replying, this comes in waves taking the
server to it's maximum at times

as far as I can see this only logs are this:

==> /var/log/qmail/smtps/current <==
2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from
141.98.80.30
2020-04-18 05:04:48.480787500 tcpserver: ok 13339
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::25638
2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from
141.98.80.30
2020-04-18 05:04:52.830768500 tcpserver: ok 13340
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::14862
2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from
141.98.80.30
2020-04-18 05:04:57.304006500 tcpserver: ok 13342
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::9646
2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from
141.98.80.30
2020-04-18 05:05:01.902266500 tcpserver: ok 13345
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::54058
2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
2020-04-18 05:06:06.141273500 tcpserver: status: 6/60


David Bray

0418 745334
2 ∞ & <

On Sat, 18 Apr 2020 at 15:41, Eric Broch
mailto:ebr...@whitehorsetc.com>>
wrote:

Can you send the log of one of the "bad" connections?

On 4/17/2020 10:59 PM, David Bray wrote:

I can see I'm getting hammered on my smtps port

How can I mitigate this?

I can see the IP's in /var/log/qmail/smtps/current

*but where do I actually see that the smtp auth
actually fails ?*

or do I need to increase the logging somewhere ?

if I tail -f /var/log/dovecot.log

I can see the imap and pop failures

thanks in advance


David Bray

0418 745334
2 ∞ & <

-- 


# David

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Jaime Lerner]

David,

 

You might try the suggestions here: 
https://www.taverner-rich.com/mitigating-brute-force-attacks/

 

I put them in place on my server and it definitely helped.

 

Jaime

 

From: Eric Broch 
Reply-To: 
Date: Wednesday, April 22, 2020 at 9:40 AM
To: 
Subject: Re: [qmailtoaster] SMTPS Port - Who is Failing ?

 

Hi David,

I think you're on to something with fail2ban (keying off maillog). I was 
monitoring my smtps port (watching the certificate and encryption scroll by) 
using /usr/bin/recordio and /var/log/maillog and found that the bad guys are 
trying to login. Here are some failures from maillog:

vchkpw-smtps: vpopmail user not found testforu...@whitehorsetc.com:92.118.38.83

vchkpw-smtps: password fail (pass: 'somepassword') 
someu...@whitehorsetc.com:185.50.149.2

Maybe a fail2ban rule?!

Eric

 

On 4/18/2020 4:12 AM, David Bray wrote:

Hi thanks - yes can block that IP

But it’s not just one, and the solution is not fine enough

I want more of a fail2ban rule, bad use bad pass 3 strikes your out

 

I need to know they are mucking round.

 

I tried sending myself through the port with a bad password- sure it blocks it, 
but there is no log of the event - it looks like a legit, connection from Ann IP

 

On Sat, 18 Apr 2020 at 7:30 pm, Chris  wrote:

Here's a great article with instructions on how to implement an IP blacklist in 
iptables. Unless you've got a user in Panama, it looks like you's want to block 
141.98.80.30 


https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/

 

On Sat, Apr 18, 2020 at 5:49 PM David Bray  wrote:

sure - thanks for replying, this comes in waves taking the server to it's 
maximum at times 

 

as far as I can see this only logs are this:

 

==> /var/log/qmail/smtps/current <==
2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30
2020-04-18 05:04:48.480787500 tcpserver: ok 13339 
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::25638
2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30
2020-04-18 05:04:52.830768500 tcpserver: ok 13340 
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::14862
2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30
2020-04-18 05:04:57.304006500 tcpserver: ok 13342 
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::9646
2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30
2020-04-18 05:05:01.902266500 tcpserver: ok 13345 
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::54058
2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
2020-04-18 05:06:06.141273500 tcpserver: status: 6/60


David Bray

0418 745334
2 ∞ & <

 

 

On Sat, 18 Apr 2020 at 15:41, Eric Broch  wrote:

Can you send the log of one of the "bad" connections?

On 4/17/2020 10:59 PM, David Bray wrote:

I can see I'm getting hammered on my smtps port 

 

How can I mitigate this?

 

I can see the IP's in /var/log/qmail/smtps/current

 

but where do I actually see that the smtp auth actually fails ?

 

or do I need to increase the logging somewhere ?

 

if I tail -f /var/log/dovecot.log

 

I can see the imap and pop failures

 

thanks in advance


David Bray

0418 745334
2 ∞ & <

-- 

# David

Re: [qmailtoaster] SMTPS Port - Who is Failing ?

[Eric Broch]

Hi David,

I think you're on to something with fail2ban (keying off maillog). I was 
monitoring my smtps port (watching the certificate and encryption scroll 
by) using /usr/bin/recordio and /var/log/maillog and found that the bad 
guys are trying to login. Here are some failures from maillog:


vchkpw-smtps: vpopmail user not found 
testforu...@whitehorsetc.com:92.118.38.83


vchkpw-smtps: password fail (pass: 'somepassword') 
someu...@whitehorsetc.com:185.50.149.2


Maybe a fail2ban rule?!

Eric


On 4/18/2020 4:12 AM, David Bray wrote:

Hi thanks - yes can block that IP
But it’s not just one, and the solution is not fine enough
I want more of a fail2ban rule, bad use bad pass 3 strikes your out

I need to know they are mucking round.

I tried sending myself through the port with a bad password- sure it 
blocks it, but there is no log of the event - it looks like a legit, 
connection from Ann IP


On Sat, 18 Apr 2020 at 7:30 pm, Chris > wrote:


Here's a great article with instructions on how to implement an IP
blacklist in iptables. Unless you've got a user in Panama, it
looks like you's want to block 141.98.80.30

https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/

On Sat, Apr 18, 2020 at 5:49 PM David Bray mailto:da...@brayworth.com.au>> wrote:

sure - thanks for replying, this comes in waves taking the
server to it's maximum at times

as far as I can see this only logs are this:

==> /var/log/qmail/smtps/current <==
2020-04-18 05:04:48.450871500 tcpserver: status: 6/60
2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from
141.98.80.30
2020-04-18 05:04:48.480787500 tcpserver: ok 13339
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::25638
2020-04-18 05:04:52.797644500 tcpserver: status: 7/60
2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from
141.98.80.30
2020-04-18 05:04:52.830768500 tcpserver: ok 13340
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::14862
2020-04-18 05:04:57.248902500 tcpserver: status: 8/60
2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from
141.98.80.30
2020-04-18 05:04:57.304006500 tcpserver: ok 13342
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::9646
2020-04-18 05:05:01.854790500 tcpserver: status: 9/60
2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from
141.98.80.30
2020-04-18 05:05:01.902266500 tcpserver: ok 13345
dev.brayworth.com:172.105.181.18:465 :141.98.80.30::54058
2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256
2020-04-18 05:05:09.729713500 tcpserver: status: 8/60
2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256
2020-04-18 05:06:05.965716500 tcpserver: status: 7/60
2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256
2020-04-18 05:06:06.141273500 tcpserver: status: 6/60

David Bray
0418 745334
2 ∞ & <


On Sat, 18 Apr 2020 at 15:41, Eric Broch
mailto:ebr...@whitehorsetc.com>> wrote:

Can you send the log of one of the "bad" connections?

On 4/17/2020 10:59 PM, David Bray wrote:


I can see I'm getting hammered on my smtps port

How can I mitigate this?

I can see the IP's in /var/log/qmail/smtps/current

*but where do I actually see that the smtp auth actually
fails ?*

or do I need to increase the logging somewhere ?

if I tail -f /var/log/dovecot.log

I can see the imap and pop failures

thanks in advance

David Bray
0418 745334
2 ∞ & <


--
# David