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

[Eric Broch]

Hmmm

Only difference between those versions is the spam throttle patch.

On 4/29/2020 5:31 AM, David Bray wrote:

Just an update on this
all seems to have resolved itself now

I'm not sure exactly what the differential was

 1. I ran the update - /yum --enablerepo=qmt-devel update/
  * before :   qmail-1.03-3.1.1.qt.el7.x86_64
  * after : qmail-1.03-3.2.qt.el7.x86_64

I did some other things, but that seems to have been the thing that 
made the change, I must have missed this step in the original install


I also find this fail2ban filter useful - it has significantly reduced 
the load on the server:

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


Thanks to those that replied


David Bray
0418 745334
2 ∞ & <


On Thu, 23 Apr 2020 at 11:17, David Bray <mailto:da...@brayworth.com.au>> 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 mailto:r...@mattei.org>> 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
<mailto:testforu...@whitehorsetc.com:92.118.38.83>

vchkpw-smtps: password fail (pass: 'somepassword')
someu...@whitehorsetc.com:185.50.149.2
<mailto: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

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

[David Bray]

Just an update on this
all seems to have resolved itself now

I'm not sure exactly what the differential was

   1. I ran the update - *yum --enablerepo=qmt-devel update*
  - before :   qmail-1.03-3.1.1.qt.el7.x86_64
  - after : qmail-1.03-3.2.qt.el7.x86_64

I did some other things, but that seems to have been the thing that made
the change, I must have missed this step in the original install

I also find this fail2ban filter useful - it has significantly reduced the
load on the server:
[Definition]
failregex = vchkpw-smtps?: vpopmail user not found .*:
vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*:
spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: 
origin_rdns:.*$
spamdyke.*?: DENIED_RDNS_MISSING .*origin_ip: 
origin_rdns:.*$

Thanks to those that replied


David Bray
0418 745334
2 ∞ & <


On Thu, 23 Apr 2020 at 11:17, 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:
>>>
>&g

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 <mailto:r...@mattei.org>> 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
<mailto:testforu...@whitehorsetc.com:92.118.38.83>

vchkpw-smtps: password fail (pass: 'somepassword')
someu...@whitehorsetc.com:185.50.149.2
<mailto: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 

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

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

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 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] 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 
<mailto:testforu...@whitehorsetc.com:92.118.38.83>


vchkpw-smtps: password fail (pass: 'somepassword') 
someu...@whitehorsetc.com:185.50.149.2 
<mailto: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

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

[Remo Mattei]

HI David, you can use TCPDump with source IP example 

tcpdump src 1.1.1.1 
And or with ports if you want. Like this

tcpdump -nnvvS src thebadguyipaddress and dst port 25





> On Apr 21, 2020, at 17:15, David Bray  wrote:
> 
> Hey Remo, just looking at Andy's suggestion though
> 
> tcpdump - that only copies the data from the port ?
> So if if I were to use Andy's idea - it would be an interference in the port 
> and the data would have to be proxied to the correct port (or lost)
> 
> tcpdump - can I use that on an existing connection
> 
> What I have here is a lot of connections during the day, but then I notice 
> the CPU going up (between swimming, running, hiking and other leisure 
> activities)
> 
> So I just want to say - What are you doing and look  - can tcpdump do that ?
> I see tcpdump host  is an option ...
> 
> I'll see what I can discover there, thanks Remo/Andy
> 
> David Bray
> 0418 745334
> 2 ∞ & <
> 
> 
> On Wed, 22 Apr 2020 at 09:46, mailto:r...@mattei.org>> 
> wrote:
> The other is to leverage some of Andy’s suggestions and use tcpdump on that 
> port and see 😊
> 
> > Il giorno 21 apr 2020, alle ore 16:40, Andrew Swartz 
> > mailto:awswa...@acsalaska.net>> ha scritto:
> > 
> > David,
> > 
> > I have no idea where (or even if) incoming TLS sessions are logged.
> > 
> > I've used "openssl s_client" numerous times to see the details of a 
> > connection, but only from the client perspective.
> > 
> > Openssl does have the "s_server" complement of s_client, but I've never 
> > used it:
> > 
> > https://www.openssl.org/docs/man1.1.0/man1/s_server.html 
> > 
> > 
> > Maybe you could:
> > 1. set a firewall rule to redirect the offending IP to a new port, then
> > 2. run openssl s_server listening on the new port in a terminal window and 
> > thus watch the output of the TLS negotiation (or redirect the output to a 
> > file).
> > 
> > I've never done this.  But it seems the easiest way to debug a TLS 
> > negotiation from the server perspective (i.e. see what a remote client is 
> > doing without access to that client).  Others on the list may have better 
> > ideas or even some experience doing this.
> > 
> > -Andy
> > 
> > 
> > 
> >> On 4/20/2020 8:15 PM, David Bray wrote:
> >> Hi Andy - you have grasped the problem accurately
> >> As I understand it, the transaction does not leave a great deal of scope - 
> >> negotiate the encryption, send a password successfully or unsuccessfully - 
> >> (at that point it's logged)
> >> So it has to be the negotiation phase ...
> >> but:
> >>  * I've only just built this server
> >>  * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
> >>  o I think this adequate I've seen no OOM events - and the size is
> >>what I've used before
> >> The only thing I'm really seeing here that could be an issue is - the 
> >> newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing
> >> I see lots of broken servers, and have to /make allowances/, I do this by:
> >>touch /var/qmail/control/notlshosts/
> >> Noting - that is an outbound thing ... (see 
> >> https://www.qmailtoaster.org/notls.html 
> >> )
> >> So .. is it possible that a broken client is hitting the port, not 
> >> being able to make the necessary handshake and causing this CPU load 
> >> It's reported in the logs when the server makes an outbound transaction 
> >> like that ...
> >>deferral:
> >>
> >> TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./
> >> What would it look like in my logs if they where to have the reverse issue
> >> David Bray
> >> 0418 745334
> >> 2 ∞ & <
> >> On Tue, 21 Apr 2020 at 02:54, Andrew Swartz  >>   >> >> wrote:
> >>Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of
> >>events is:
> >>1.  Establish TCP connection
> >>2.  Negotiate SSL/TLS session
> >>3.  Begin SMTP session
> >>Of these, the SSL/TLS negotiation is by far the most CPU-intensive.
> >>Consider trying to see what is happening with the SSL/TLS negotiation.
> >>It may be failing in a way which is slamming the CPU but not showing up
> >>in the SMTP logs because it never completes and thus an SMTP session is
> >>never initiated.
> >>I'm unsure the best way to debug the incoming SSL/TLS negotiation.  You
> >>might set a firewall rule where incoming port 465 from that single
> >>IP is
> >>forwarded to stunnel (on another machine) which is set to output
> >>verbose
> >>debug info???
> >>It would be interesting to know the cause.  This could be some clever
> >>DOS attack where a single connection accomplishes the DOS by slamming
> >>the CPU by submitting something invalid to openSSL.  But it might just
> 

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

[David Bray]

Hey Remo, just looking at Andy's suggestion though

tcpdump - that only copies the data from the port ?
So if if I were to use Andy's idea - it would be an interference in the
port and the data would have to be proxied to the correct port (or lost)

tcpdump - can I use that on an existing connection

What I have here is a lot of connections during the day, but then I notice
the CPU going up (between swimming, running, hiking and other leisure
activities)

So I just want to say - *What are you doing and look * - can tcpdump do
that ?
I see tcpdump host  is an option ...

I'll see what I can discover there, thanks Remo/Andy

David Bray
0418 745334
2 ∞ & <


On Wed, 22 Apr 2020 at 09:46,  wrote:

> The other is to leverage some of Andy’s suggestions and use tcpdump on
> that port and see 😊
>
> > Il giorno 21 apr 2020, alle ore 16:40, Andrew Swartz <
> awswa...@acsalaska.net> ha scritto:
> >
> > David,
> >
> > I have no idea where (or even if) incoming TLS sessions are logged.
> >
> > I've used "openssl s_client" numerous times to see the details of a
> connection, but only from the client perspective.
> >
> > Openssl does have the "s_server" complement of s_client, but I've never
> used it:
> >
> > https://www.openssl.org/docs/man1.1.0/man1/s_server.html
> >
> > Maybe you could:
> > 1. set a firewall rule to redirect the offending IP to a new port, then
> > 2. run openssl s_server listening on the new port in a terminal window
> and thus watch the output of the TLS negotiation (or redirect the output to
> a file).
> >
> > I've never done this.  But it seems the easiest way to debug a TLS
> negotiation from the server perspective (i.e. see what a remote client is
> doing without access to that client).  Others on the list may have better
> ideas or even some experience doing this.
> >
> > -Andy
> >
> >
> >
> >> On 4/20/2020 8:15 PM, David Bray wrote:
> >> Hi Andy - you have grasped the problem accurately
> >> As I understand it, the transaction does not leave a great deal of
> scope - negotiate the encryption, send a password successfully or
> unsuccessfully - (at that point it's logged)
> >> So it has to be the negotiation phase ...
> >> but:
> >>  * I've only just built this server
> >>  * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
> >>  o I think this adequate I've seen no OOM events - and the size is
> >>what I've used before
> >> The only thing I'm really seeing here that could be an issue is - the
> newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing
> >> I see lots of broken servers, and have to /make allowances/, I do this
> by:
> >>touch /var/qmail/control/notlshosts/
> >> Noting - that is an outbound thing ... (see
> https://www.qmailtoaster.org/notls.html)
> >> So .. is it possible that a broken client is hitting the port, not
> being able to make the necessary handshake and causing this CPU load 
> >> It's reported in the logs when the server makes an outbound transaction
> like that ...
> >>deferral:
> >>
> TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./
> >> What would it look like in my logs if they where to have the reverse
> issue
> >> David Bray
> >> 0418 745334
> >> 2 ∞ & <
> >> On Tue, 21 Apr 2020 at 02:54, Andrew Swartz  > wrote:
> >>Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of
> >>events is:
> >>1.  Establish TCP connection
> >>2.  Negotiate SSL/TLS session
> >>3.  Begin SMTP session
> >>Of these, the SSL/TLS negotiation is by far the most CPU-intensive.
> >>Consider trying to see what is happening with the SSL/TLS
> negotiation.
> >>It may be failing in a way which is slamming the CPU but not showing
> up
> >>in the SMTP logs because it never completes and thus an SMTP session
> is
> >>never initiated.
> >>I'm unsure the best way to debug the incoming SSL/TLS negotiation.
> You
> >>might set a firewall rule where incoming port 465 from that single
> >>IP is
> >>forwarded to stunnel (on another machine) which is set to output
> >>verbose
> >>debug info???
> >>It would be interesting to know the cause.  This could be some clever
> >>DOS attack where a single connection accomplishes the DOS by slamming
> >>the CPU by submitting something invalid to openSSL.  But it might
> just
> >>be that some spammer is using a home-brewed script which is buggy
> >>and is
> >>unintentionally causing this problem.
> >>There seems no efficient way to block this without figuring out the
> >>cause and doing something to make that cause be logged into some log
> >>file.  Once that is accomplished, fail2ban (or something similar) can
> >>easily add firewall rules to block individual IP's which exhibit this
> >>behavior.
> >>-Andy
> >>On 4/19/2020 10:12 PM, David Bray wrote:
> >> > Hey thanks Re

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

[David Bray]

Thankfully CentOS 7 using 1.0.2k so not affected - thanks for the tip though

David Bray
0418 745334
2 ∞ & <


On Wed, 22 Apr 2020 at 09:40, Andrew Swartz  wrote:

> David,
>
> I just received this OpenSSL security advisory which may be describing
> your problem.  It describes a vulnerability which allows a DOS attack by
> submitting an invalid certificate.
>
> https://www.openssl.org/news/secadv/20200421.txt
>
>
> -Andy
>
>
> On 4/20/2020 8:15 PM, David Bray wrote:
> > Hi Andy - you have grasped the problem accurately
> >
> > As I understand it, the transaction does not leave a great deal of scope
> > - negotiate the encryption, send a password successfully or
> > unsuccessfully - (at that point it's logged)
> >
> > So it has to be the negotiation phase ...
> > but:
> >
> >   * I've only just built this server
> >   * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
> >   o I think this adequate I've seen no OOM events - and the size is
> > what I've used before
> >
> > The only thing I'm really seeing here that could be an issue is - the
> > newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing
> > I see lots of broken servers, and have to /make allowances/, I do this
> by:
> >
> > touch /var/qmail/control/notlshosts/
> >
> >
> > Noting - that is an outbound thing ... (see
> > https://www.qmailtoaster.org/notls.html)
> >
> > So .. is it possible that a broken client is hitting the port, not
> > being able to make the necessary handshake and causing this CPU load 
> > It's reported in the logs when the server makes an outbound transaction
> > like that ...
> >
> > deferral:
> >
>  
> TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./
> >
> >
> > What would it look like in my logs if they where to have the reverse
> issue
> >
> >
> >
> >
> >
> > David Bray
> > 0418 745334
> > 2 ∞ & <
> >
> >
> > On Tue, 21 Apr 2020 at 02:54, Andrew Swartz  > > wrote:
> >
> > Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of
> > events is:
> >
> > 1.  Establish TCP connection
> > 2.  Negotiate SSL/TLS session
> > 3.  Begin SMTP session
> >
> > Of these, the SSL/TLS negotiation is by far the most CPU-intensive.
> >
> > Consider trying to see what is happening with the SSL/TLS
> negotiation.
> > It may be failing in a way which is slamming the CPU but not showing
> up
> > in the SMTP logs because it never completes and thus an SMTP session
> is
> > never initiated.
> >
> > I'm unsure the best way to debug the incoming SSL/TLS negotiation.
> You
> > might set a firewall rule where incoming port 465 from that single
> > IP is
> > forwarded to stunnel (on another machine) which is set to output
> > verbose
> > debug info???
> >
> > It would be interesting to know the cause.  This could be some clever
> > DOS attack where a single connection accomplishes the DOS by slamming
> > the CPU by submitting something invalid to openSSL.  But it might
> just
> > be that some spammer is using a home-brewed script which is buggy
> > and is
> > unintentionally causing this problem.
> >
> > There seems no efficient way to block this without figuring out the
> > cause and doing something to make that cause be logged into some log
> > file.  Once that is accomplished, fail2ban (or something similar) can
> > easily add firewall rules to block individual IP's which exhibit this
> > behavior.
> >
> > -Andy
> >
> >
> >
> >
> >
> > On 4/19/2020 10:12 PM, David Bray wrote:
> >  > Hey thanks Remo
> >  > smtps is an inbound port, they are contacting me - this IP is in
> > Russia
> >  > somewhere - so do I want to engage (perhaps, probably not but ..)
> >  >
> >  > I could of course block that IP - but that doesn't help, I'd have
> to
> >  > block endless IPs
> >  >
> >  > I'd like to know what's taking the CPU load, in theory they
> > should be
> >  > connecting, supplying a password (perhaps) and sending data
> >  > but, there are sometimes bad passwords (2 for the 20th recorded
> > in maillog)
> >  >
> >  > So..
> >  > What are they doing the other times and why is it taking so much
> > CPU -
> >  > if it is just a port knock, why the CPU
> >  >
> >  > I need to be able to say, they are bad because ... *what is the
> > because* ?
> >  >
> >  > David Bray
> >  > 0418 745334
> >  > 2 ∞ & <
> >  >
> >  >
> >  > On Mon, 20 Apr 2020 at 15:32, Remo Mattei  > 
> >  > >> wrote:
> >  >
> >  > Hi,
> >  > Can you reach the server?  It maybe blocking you. So what
> > does your
> >  > queue looks like?
> >  >
> >  > Here is mine for ex

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

[remo]

The other is to leverage some of Andy’s suggestions and use tcpdump on that 
port and see 😊

> Il giorno 21 apr 2020, alle ore 16:40, Andrew Swartz  
> ha scritto:
> 
> David,
> 
> I have no idea where (or even if) incoming TLS sessions are logged.
> 
> I've used "openssl s_client" numerous times to see the details of a 
> connection, but only from the client perspective.
> 
> Openssl does have the "s_server" complement of s_client, but I've never used 
> it:
> 
> https://www.openssl.org/docs/man1.1.0/man1/s_server.html
> 
> Maybe you could:
> 1. set a firewall rule to redirect the offending IP to a new port, then
> 2. run openssl s_server listening on the new port in a terminal window and 
> thus watch the output of the TLS negotiation (or redirect the output to a 
> file).
> 
> I've never done this.  But it seems the easiest way to debug a TLS 
> negotiation from the server perspective (i.e. see what a remote client is 
> doing without access to that client).  Others on the list may have better 
> ideas or even some experience doing this.
> 
> -Andy
> 
> 
> 
>> On 4/20/2020 8:15 PM, David Bray wrote:
>> Hi Andy - you have grasped the problem accurately
>> As I understand it, the transaction does not leave a great deal of scope - 
>> negotiate the encryption, send a password successfully or unsuccessfully - 
>> (at that point it's logged)
>> So it has to be the negotiation phase ...
>> but:
>>  * I've only just built this server
>>  * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
>>  o I think this adequate I've seen no OOM events - and the size is
>>what I've used before
>> The only thing I'm really seeing here that could be an issue is - the newer 
>> machines are stricter on SSL - the TLS 1/1.2 deprecation thing
>> I see lots of broken servers, and have to /make allowances/, I do this by:
>>touch /var/qmail/control/notlshosts/
>> Noting - that is an outbound thing ... (see 
>> https://www.qmailtoaster.org/notls.html)
>> So .. is it possible that a broken client is hitting the port, not being 
>> able to make the necessary handshake and causing this CPU load 
>> It's reported in the logs when the server makes an outbound transaction like 
>> that ...
>>deferral:
>>
>> TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./
>> What would it look like in my logs if they where to have the reverse issue
>> David Bray
>> 0418 745334
>> 2 ∞ & <
>> On Tue, 21 Apr 2020 at 02:54, Andrew Swartz > > wrote:
>>Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of
>>events is:
>>1.  Establish TCP connection
>>2.  Negotiate SSL/TLS session
>>3.  Begin SMTP session
>>Of these, the SSL/TLS negotiation is by far the most CPU-intensive.
>>Consider trying to see what is happening with the SSL/TLS negotiation.
>>It may be failing in a way which is slamming the CPU but not showing up
>>in the SMTP logs because it never completes and thus an SMTP session is
>>never initiated.
>>I'm unsure the best way to debug the incoming SSL/TLS negotiation.  You
>>might set a firewall rule where incoming port 465 from that single
>>IP is
>>forwarded to stunnel (on another machine) which is set to output
>>verbose
>>debug info???
>>It would be interesting to know the cause.  This could be some clever
>>DOS attack where a single connection accomplishes the DOS by slamming
>>the CPU by submitting something invalid to openSSL.  But it might just
>>be that some spammer is using a home-brewed script which is buggy
>>and is
>>unintentionally causing this problem.
>>There seems no efficient way to block this without figuring out the
>>cause and doing something to make that cause be logged into some log
>>file.  Once that is accomplished, fail2ban (or something similar) can
>>easily add firewall rules to block individual IP's which exhibit this
>>behavior.
>>-Andy
>>On 4/19/2020 10:12 PM, David Bray wrote:
>> > Hey thanks Remo
>> > smtps is an inbound port, they are contacting me - this IP is in
>>Russia
>> > somewhere - so do I want to engage (perhaps, probably not but ..)
>> >
>> > I could of course block that IP - but that doesn't help, I'd have to
>> > block endless IPs
>> >
>> > I'd like to know what's taking the CPU load, in theory they
>>should be
>> > connecting, supplying a password (perhaps) and sending data
>> > but, there are sometimes bad passwords (2 for the 20th recorded
>>in maillog)
>> >
>> > So..
>> > What are they doing the other times and why is it taking so much
>>CPU -
>> > if it is just a port knock, why the CPU
>> >
>> > I need to be able to say, they are bad because ... *what is the
>>because* ?
>> >
>> > David Bray
>> > 0418 745334
>> > 2 ∞ & <

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

[Andrew Swartz]

David,

I have no idea where (or even if) incoming TLS sessions are logged.

I've used "openssl s_client" numerous times to see the details of a 
connection, but only from the client perspective.


Openssl does have the "s_server" complement of s_client, but I've never 
used it:


https://www.openssl.org/docs/man1.1.0/man1/s_server.html

Maybe you could:
1. set a firewall rule to redirect the offending IP to a new port, then
2. run openssl s_server listening on the new port in a terminal window 
and thus watch the output of the TLS negotiation (or redirect the output 
to a file).


I've never done this.  But it seems the easiest way to debug a TLS 
negotiation from the server perspective (i.e. see what a remote client 
is doing without access to that client).  Others on the list may have 
better ideas or even some experience doing this.


-Andy



On 4/20/2020 8:15 PM, David Bray wrote:

Hi Andy - you have grasped the problem accurately

As I understand it, the transaction does not leave a great deal of scope 
- negotiate the encryption, send a password successfully or 
unsuccessfully - (at that point it's logged)


So it has to be the negotiation phase ...
but:

  * I've only just built this server
  * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
  o I think this adequate I've seen no OOM events - and the size is
what I've used before

The only thing I'm really seeing here that could be an issue is - the 
newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing

I see lots of broken servers, and have to /make allowances/, I do this by:

touch /var/qmail/control/notlshosts/


Noting - that is an outbound thing ... (see 
https://www.qmailtoaster.org/notls.html)


So .. is it possible that a broken client is hitting the port, not 
being able to make the necessary handshake and causing this CPU load 
It's reported in the logs when the server makes an outbound transaction 
like that ...


deferral:

TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./


What would it look like in my logs if they where to have the reverse issue





David Bray
0418 745334
2 ∞ & <


On Tue, 21 Apr 2020 at 02:54, Andrew Swartz > wrote:


Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of
events is:

1.  Establish TCP connection
2.  Negotiate SSL/TLS session
3.  Begin SMTP session

Of these, the SSL/TLS negotiation is by far the most CPU-intensive.

Consider trying to see what is happening with the SSL/TLS negotiation.
It may be failing in a way which is slamming the CPU but not showing up
in the SMTP logs because it never completes and thus an SMTP session is
never initiated.

I'm unsure the best way to debug the incoming SSL/TLS negotiation.  You
might set a firewall rule where incoming port 465 from that single
IP is
forwarded to stunnel (on another machine) which is set to output
verbose
debug info???

It would be interesting to know the cause.  This could be some clever
DOS attack where a single connection accomplishes the DOS by slamming
the CPU by submitting something invalid to openSSL.  But it might just
be that some spammer is using a home-brewed script which is buggy
and is
unintentionally causing this problem.

There seems no efficient way to block this without figuring out the
cause and doing something to make that cause be logged into some log
file.  Once that is accomplished, fail2ban (or something similar) can
easily add firewall rules to block individual IP's which exhibit this
behavior.

-Andy





On 4/19/2020 10:12 PM, David Bray wrote:
 > Hey thanks Remo
 > smtps is an inbound port, they are contacting me - this IP is in
Russia
 > somewhere - so do I want to engage (perhaps, probably not but ..)
 >
 > I could of course block that IP - but that doesn't help, I'd have to
 > block endless IPs
 >
 > I'd like to know what's taking the CPU load, in theory they
should be
 > connecting, supplying a password (perhaps) and sending data
 > but, there are sometimes bad passwords (2 for the 20th recorded
in maillog)
 >
 > So..
 > What are they doing the other times and why is it taking so much
CPU -
 > if it is just a port knock, why the CPU
 >
 > I need to be able to say, they are bad because ... *what is the
because* ?
 >
 > David Bray
 > 0418 745334
 > 2 ∞ & <
 >
 >
 > On Mon, 20 Apr 2020 at 15:32, Remo Mattei mailto:r...@mattei.org>
 > >> wrote:
 >
 >     Hi,
 >     Can you reach the server?  It maybe blocking you. So what
does your
 >     queue looks like?
 >
 >     Here is mine for example:
 >
 >     # qmHandle -L
 > 

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

[Andrew Swartz]

David,

I just received this OpenSSL security advisory which may be describing 
your problem.  It describes a vulnerability which allows a DOS attack by 
submitting an invalid certificate.


https://www.openssl.org/news/secadv/20200421.txt


-Andy


On 4/20/2020 8:15 PM, David Bray wrote:

Hi Andy - you have grasped the problem accurately

As I understand it, the transaction does not leave a great deal of scope 
- negotiate the encryption, send a password successfully or 
unsuccessfully - (at that point it's logged)


So it has to be the negotiation phase ...
but:

  * I've only just built this server
  * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
  o I think this adequate I've seen no OOM events - and the size is
what I've used before

The only thing I'm really seeing here that could be an issue is - the 
newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing

I see lots of broken servers, and have to /make allowances/, I do this by:

touch /var/qmail/control/notlshosts/


Noting - that is an outbound thing ... (see 
https://www.qmailtoaster.org/notls.html)


So .. is it possible that a broken client is hitting the port, not 
being able to make the necessary handshake and causing this CPU load 
It's reported in the logs when the server makes an outbound transaction 
like that ...


deferral:

TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./


What would it look like in my logs if they where to have the reverse issue





David Bray
0418 745334
2 ∞ & <


On Tue, 21 Apr 2020 at 02:54, Andrew Swartz > wrote:


Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of
events is:

1.  Establish TCP connection
2.  Negotiate SSL/TLS session
3.  Begin SMTP session

Of these, the SSL/TLS negotiation is by far the most CPU-intensive.

Consider trying to see what is happening with the SSL/TLS negotiation.
It may be failing in a way which is slamming the CPU but not showing up
in the SMTP logs because it never completes and thus an SMTP session is
never initiated.

I'm unsure the best way to debug the incoming SSL/TLS negotiation.  You
might set a firewall rule where incoming port 465 from that single
IP is
forwarded to stunnel (on another machine) which is set to output
verbose
debug info???

It would be interesting to know the cause.  This could be some clever
DOS attack where a single connection accomplishes the DOS by slamming
the CPU by submitting something invalid to openSSL.  But it might just
be that some spammer is using a home-brewed script which is buggy
and is
unintentionally causing this problem.

There seems no efficient way to block this without figuring out the
cause and doing something to make that cause be logged into some log
file.  Once that is accomplished, fail2ban (or something similar) can
easily add firewall rules to block individual IP's which exhibit this
behavior.

-Andy





On 4/19/2020 10:12 PM, David Bray wrote:
 > Hey thanks Remo
 > smtps is an inbound port, they are contacting me - this IP is in
Russia
 > somewhere - so do I want to engage (perhaps, probably not but ..)
 >
 > I could of course block that IP - but that doesn't help, I'd have to
 > block endless IPs
 >
 > I'd like to know what's taking the CPU load, in theory they
should be
 > connecting, supplying a password (perhaps) and sending data
 > but, there are sometimes bad passwords (2 for the 20th recorded
in maillog)
 >
 > So..
 > What are they doing the other times and why is it taking so much
CPU -
 > if it is just a port knock, why the CPU
 >
 > I need to be able to say, they are bad because ... *what is the
because* ?
 >
 > David Bray
 > 0418 745334
 > 2 ∞ & <
 >
 >
 > On Mon, 20 Apr 2020 at 15:32, Remo Mattei mailto:r...@mattei.org>
 > >> wrote:
 >
 >     Hi,
 >     Can you reach the server?  It maybe blocking you. So what
does your
 >     queue looks like?
 >
 >     Here is mine for example:
 >
 >     # qmHandle -L
 >     Messages in local queue: 0
 >     Messages in remote queue: 0
 >
 >     My other server
 >
 >     # qmHandle -L
 >     10355792 (19, L)
 >        Return-path: r...@qmailx.com
 >
 >        From: Anacron mailto:r...@qmail.com> >>
 >        To: r...@qmailx.com 
>
 >        Subject: Anacron job 'cron.daily' on qmailxxx

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

[David Bray]

Hi Eric - was that for Andy or me

I'm on

   - qmail-1.03-3.1.1.qt.el7.x86_64
   - qmailadmin-1.2.16-2.qt.el7.x86_64
   - qmailmrtg-4.2-3.qt.el7.x86_64


David Bray
0418 745334
2 ∞ & <


On Tue, 21 Apr 2020 at 23:34, Eric Broch  wrote:

> Andy,
>
> May I ask what version of qmail you're on?
>
> Eric
> On 4/20/2020 10:15 PM, David Bray wrote:
>
> Hi Andy - you have grasped the problem accurately
>
> As I understand it, the transaction does not leave a great deal of scope -
> negotiate the encryption, send a password successfully or unsuccessfully -
> (at that point it's logged)
>
> So it has to be the negotiation phase ...
> but:
>
>- I've only just built this server
>- stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
>   - I think this adequate I've seen no OOM events - and the size is
>   what I've used before
>
> The only thing I'm really seeing here that could be an issue is - the
> newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing
> I see lots of broken servers, and have to *make allowances*, I do this by:
>
> touch /var/qmail/control/notlshosts/
>
>
> Noting - that is an outbound thing ... (see
> https://www.qmailtoaster.org/notls.html)
>
> So .. is it possible that a broken client is hitting the port, not
> being able to make the necessary handshake and causing this CPU load 
> It's reported in the logs when the server makes an outbound transaction
> like that ...
>
> deferral:
> TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./
>
>
> What would it look like in my logs if they where to have the reverse issue
>
>
>
>
>
> David Bray
> 0418 745334
> 2 ∞ & <
>
>
> On Tue, 21 Apr 2020 at 02:54, Andrew Swartz 
> wrote:
>
>> Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of events
>> is:
>>
>> 1.  Establish TCP connection
>> 2.  Negotiate SSL/TLS session
>> 3.  Begin SMTP session
>>
>> Of these, the SSL/TLS negotiation is by far the most CPU-intensive.
>>
>> Consider trying to see what is happening with the SSL/TLS negotiation.
>> It may be failing in a way which is slamming the CPU but not showing up
>> in the SMTP logs because it never completes and thus an SMTP session is
>> never initiated.
>>
>> I'm unsure the best way to debug the incoming SSL/TLS negotiation.  You
>> might set a firewall rule where incoming port 465 from that single IP is
>> forwarded to stunnel (on another machine) which is set to output verbose
>> debug info???
>>
>> It would be interesting to know the cause.  This could be some clever
>> DOS attack where a single connection accomplishes the DOS by slamming
>> the CPU by submitting something invalid to openSSL.  But it might just
>> be that some spammer is using a home-brewed script which is buggy and is
>> unintentionally causing this problem.
>>
>> There seems no efficient way to block this without figuring out the
>> cause and doing something to make that cause be logged into some log
>> file.  Once that is accomplished, fail2ban (or something similar) can
>> easily add firewall rules to block individual IP's which exhibit this
>> behavior.
>>
>> -Andy
>>
>>
>>
>>
>>
>> On 4/19/2020 10:12 PM, David Bray wrote:
>> > Hey thanks Remo
>> > smtps is an inbound port, they are contacting me - this IP is in Russia
>> > somewhere - so do I want to engage (perhaps, probably not but ..)
>> >
>> > I could of course block that IP - but that doesn't help, I'd have to
>> > block endless IPs
>> >
>> > I'd like to know what's taking the CPU load, in theory they should be
>> > connecting, supplying a password (perhaps) and sending data
>> > but, there are sometimes bad passwords (2 for the 20th recorded in
>> maillog)
>> >
>> > So..
>> > What are they doing the other times and why is it taking so much CPU -
>> > if it is just a port knock, why the CPU
>> >
>> > I need to be able to say, they are bad because ... *what is the
>> because* ?
>> >
>> > David Bray
>> > 0418 745334
>> > 2 ∞ & <
>> >
>> >
>> > On Mon, 20 Apr 2020 at 15:32, Remo Mattei > > > wrote:
>> >
>> > Hi,
>> > Can you reach the server?  It maybe blocking you. So what does your
>> > queue looks like?
>> >
>> > Here is mine for example:
>> >
>> > # qmHandle -L
>> > Messages in local queue: 0
>> > Messages in remote queue: 0
>> >
>> > My other server
>> >
>> > # qmHandle -L
>> > 10355792 (19, L)
>> >Return-path: r...@qmailx.com 
>> >From: Anacron mailto:r...@qmail.com>>
>> >To: r...@qmailx.com 
>> >Subject: Anacron job 'cron.daily' on qmailx.com
>> > 
>> >Date: 19 Apr 2020 10:28:28 -
>> >Size: 509 bytes
>> >
>> > 10358746 (6, L)
>> >Return-path:
>> >From: mailer-dae...@qmailxx.com
>> > 
>> >To: r.

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

[Eric Broch]

Andy,

May I ask what version of qmail you're on?

Eric

On 4/20/2020 10:15 PM, David Bray wrote:

Hi Andy - you have grasped the problem accurately

As I understand it, the transaction does not leave a great deal of 
scope - negotiate the encryption, send a password successfully or 
unsuccessfully - (at that point it's logged)


So it has to be the negotiation phase ...
but:

  * I've only just built this server
  * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
  o I think this adequate I've seen no OOM events - and the size
is what I've used before

The only thing I'm really seeing here that could be an issue is - the 
newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing

I see lots of broken servers, and have to /make allowances/, I do this by:

touch /var/qmail/control/notlshosts/


Noting - that is an outbound thing ... (see 
https://www.qmailtoaster.org/notls.html)


So .. is it possible that a broken client is hitting the port, not 
being able to make the necessary handshake and causing this CPU load 
It's reported in the logs when the server makes an outbound 
transaction like that ...


deferral:

TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./


What would it look like in my logs if they where to have the reverse issue





David Bray
0418 745334
2 ∞ & <


On Tue, 21 Apr 2020 at 02:54, Andrew Swartz > wrote:


Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of
events is:

1.  Establish TCP connection
2.  Negotiate SSL/TLS session
3.  Begin SMTP session

Of these, the SSL/TLS negotiation is by far the most CPU-intensive.

Consider trying to see what is happening with the SSL/TLS
negotiation.
It may be failing in a way which is slamming the CPU but not
showing up
in the SMTP logs because it never completes and thus an SMTP
session is
never initiated.

I'm unsure the best way to debug the incoming SSL/TLS
negotiation.  You
might set a firewall rule where incoming port 465 from that single
IP is
forwarded to stunnel (on another machine) which is set to output
verbose
debug info???

It would be interesting to know the cause.  This could be some clever
DOS attack where a single connection accomplishes the DOS by slamming
the CPU by submitting something invalid to openSSL.  But it might
just
be that some spammer is using a home-brewed script which is buggy
and is
unintentionally causing this problem.

There seems no efficient way to block this without figuring out the
cause and doing something to make that cause be logged into some log
file.  Once that is accomplished, fail2ban (or something similar) can
easily add firewall rules to block individual IP's which exhibit this
behavior.

-Andy





On 4/19/2020 10:12 PM, David Bray wrote:
> Hey thanks Remo
> smtps is an inbound port, they are contacting me - this IP is in
Russia
> somewhere - so do I want to engage (perhaps, probably not but ..)
>
> I could of course block that IP - but that doesn't help, I'd
have to
> block endless IPs
>
> I'd like to know what's taking the CPU load, in theory they
should be
> connecting, supplying a password (perhaps) and sending data
> but, there are sometimes bad passwords (2 for the 20th recorded
in maillog)
>
> So..
> What are they doing the other times and why is it taking so much
CPU -
> if it is just a port knock, why the CPU
>
> I need to be able to say, they are bad because ... *what is the
because* ?
>
> David Bray
> 0418 745334
> 2 ∞ & <
>
>
> On Mon, 20 Apr 2020 at 15:32, Remo Mattei mailto:r...@mattei.org>
> >> wrote:
>
>     Hi,
>     Can you reach the server?  It maybe blocking you. So what
does your
>     queue looks like?
>
>     Here is mine for example:
>
>     # qmHandle -L
>     Messages in local queue: 0
>     Messages in remote queue: 0
>
>     My other server
>
>     # qmHandle -L
>     10355792 (19, L)
>        Return-path: r...@qmailx.com
 >
>        From: Anacron mailto:r...@qmail.com> >>
>        To: r...@qmailx.com 
>
>        Subject: Anacron job 'cron.daily' on qmailx.com

>     
>        Date: 19 Apr 2020 10:28:28 -
>        Size: 509 bytes
>
>     10358746 (6, L)
>        Return-path:
>    

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

[David Bray]

Hi Andy - you have grasped the problem accurately

As I understand it, the transaction does not leave a great deal of scope -
negotiate the encryption, send a password successfully or unsuccessfully -
(at that point it's logged)

So it has to be the negotiation phase ...
but:

   - I've only just built this server
   - stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB
  - I think this adequate I've seen no OOM events - and the size is
  what I've used before

The only thing I'm really seeing here that could be an issue is - the newer
machines are stricter on SSL - the TLS 1/1.2 deprecation thing
I see lots of broken servers, and have to *make allowances*, I do this by:

touch /var/qmail/control/notlshosts/


Noting - that is an outbound thing ... (see
https://www.qmailtoaster.org/notls.html)

So .. is it possible that a broken client is hitting the port, not
being able to make the necessary handshake and causing this CPU load 
It's reported in the logs when the server makes an outbound transaction
like that ...

deferral:
TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./


What would it look like in my logs if they where to have the reverse issue





David Bray
0418 745334
2 ∞ & <


On Tue, 21 Apr 2020 at 02:54, Andrew Swartz  wrote:

> Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of events is:
>
> 1.  Establish TCP connection
> 2.  Negotiate SSL/TLS session
> 3.  Begin SMTP session
>
> Of these, the SSL/TLS negotiation is by far the most CPU-intensive.
>
> Consider trying to see what is happening with the SSL/TLS negotiation.
> It may be failing in a way which is slamming the CPU but not showing up
> in the SMTP logs because it never completes and thus an SMTP session is
> never initiated.
>
> I'm unsure the best way to debug the incoming SSL/TLS negotiation.  You
> might set a firewall rule where incoming port 465 from that single IP is
> forwarded to stunnel (on another machine) which is set to output verbose
> debug info???
>
> It would be interesting to know the cause.  This could be some clever
> DOS attack where a single connection accomplishes the DOS by slamming
> the CPU by submitting something invalid to openSSL.  But it might just
> be that some spammer is using a home-brewed script which is buggy and is
> unintentionally causing this problem.
>
> There seems no efficient way to block this without figuring out the
> cause and doing something to make that cause be logged into some log
> file.  Once that is accomplished, fail2ban (or something similar) can
> easily add firewall rules to block individual IP's which exhibit this
> behavior.
>
> -Andy
>
>
>
>
>
> On 4/19/2020 10:12 PM, David Bray wrote:
> > Hey thanks Remo
> > smtps is an inbound port, they are contacting me - this IP is in Russia
> > somewhere - so do I want to engage (perhaps, probably not but ..)
> >
> > I could of course block that IP - but that doesn't help, I'd have to
> > block endless IPs
> >
> > I'd like to know what's taking the CPU load, in theory they should be
> > connecting, supplying a password (perhaps) and sending data
> > but, there are sometimes bad passwords (2 for the 20th recorded in
> maillog)
> >
> > So..
> > What are they doing the other times and why is it taking so much CPU -
> > if it is just a port knock, why the CPU
> >
> > I need to be able to say, they are bad because ... *what is the because*
> ?
> >
> > David Bray
> > 0418 745334
> > 2 ∞ & <
> >
> >
> > On Mon, 20 Apr 2020 at 15:32, Remo Mattei  > > wrote:
> >
> > Hi,
> > Can you reach the server?  It maybe blocking you. So what does your
> > queue looks like?
> >
> > Here is mine for example:
> >
> > # qmHandle -L
> > Messages in local queue: 0
> > Messages in remote queue: 0
> >
> > My other server
> >
> > # qmHandle -L
> > 10355792 (19, L)
> >Return-path: r...@qmailx.com 
> >From: Anacron mailto:r...@qmail.com>>
> >To: r...@qmailx.com 
> >Subject: Anacron job 'cron.daily' on qmailx.com
> > 
> >Date: 19 Apr 2020 10:28:28 -
> >Size: 509 bytes
> >
> > 10358746 (6, L)
> >Return-path:
> >From: mailer-dae...@qmailxx.com
> > 
> >To: r...@qmail.com 
> >Subject: failure notice
> >Date: 19 Apr 2020 11:30:30 -
> >Size: 1089 bytes
> >
> > Messages in local queue: 2
> > Messages in remote queue: 0
> >
> > Just wonder it looks that you are using the SMTPs 465, did you try
> > the 587 Submission that address and see if it goes?
> > Just wonder if this is tight to that service.
> >
> > Maybe none of the above but just for troubleshooting steps, I would
> > 

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

[Andrew Swartz]

Port 465 should be SMTP over SSL/TLS.  Therefore the sequence of events is:

1.  Establish TCP connection
2.  Negotiate SSL/TLS session
3.  Begin SMTP session

Of these, the SSL/TLS negotiation is by far the most CPU-intensive.

Consider trying to see what is happening with the SSL/TLS negotiation. 
It may be failing in a way which is slamming the CPU but not showing up 
in the SMTP logs because it never completes and thus an SMTP session is 
never initiated.


I'm unsure the best way to debug the incoming SSL/TLS negotiation.  You 
might set a firewall rule where incoming port 465 from that single IP is 
forwarded to stunnel (on another machine) which is set to output verbose 
debug info???


It would be interesting to know the cause.  This could be some clever 
DOS attack where a single connection accomplishes the DOS by slamming 
the CPU by submitting something invalid to openSSL.  But it might just 
be that some spammer is using a home-brewed script which is buggy and is 
unintentionally causing this problem.


There seems no efficient way to block this without figuring out the 
cause and doing something to make that cause be logged into some log 
file.  Once that is accomplished, fail2ban (or something similar) can 
easily add firewall rules to block individual IP's which exhibit this 
behavior.


-Andy





On 4/19/2020 10:12 PM, David Bray wrote:

Hey thanks Remo
smtps is an inbound port, they are contacting me - this IP is in Russia 
somewhere - so do I want to engage (perhaps, probably not but ..)


I could of course block that IP - but that doesn't help, I'd have to 
block endless IPs


I'd like to know what's taking the CPU load, in theory they should be 
connecting, supplying a password (perhaps) and sending data

but, there are sometimes bad passwords (2 for the 20th recorded in maillog)

So..
What are they doing the other times and why is it taking so much CPU - 
if it is just a port knock, why the CPU


I need to be able to say, they are bad because ... *what is the because* ?

David Bray
0418 745334
2 ∞ & <


On Mon, 20 Apr 2020 at 15:32, Remo Mattei > wrote:


Hi,
Can you reach the server?  It maybe blocking you. So what does your
queue looks like?

Here is mine for example:

# qmHandle -L
Messages in local queue: 0
Messages in remote queue: 0

My other server

# qmHandle -L
10355792 (19, L)
   Return-path: r...@qmailx.com 
   From: Anacron mailto:r...@qmail.com>>
   To: r...@qmailx.com 
   Subject: Anacron job 'cron.daily' on qmailx.com

   Date: 19 Apr 2020 10:28:28 -
   Size: 509 bytes

10358746 (6, L)
   Return-path:
   From: mailer-dae...@qmailxx.com

   To: r...@qmail.com 
   Subject: failure notice
   Date: 19 Apr 2020 11:30:30 -
   Size: 1089 bytes

Messages in local queue: 2
Messages in remote queue: 0

Just wonder it looks that you are using the SMTPs 465, did you try
the 587 Submission that address and see if it goes?
Just wonder if this is tight to that service.

Maybe none of the above but just for troubleshooting steps, I would
try that.

Remo



On Apr 19, 2020, at 22:11, David Bray mailto:da...@brayworth.com.au>> wrote:

Ok - but after all the investigation etc, this is actually the
trigger which caught my eye in the first place

How this comes about is:

 1. User say hey I can't send
 2. I look and see this high CPU load and intermittent failures
for client to send

Any thoughts on where to start looking ..




my smtp/smtps are currently *10*/11 connections


==> /var/log/qmail/smtp/current <==
2020-04-20 05:07:50.207299500 tcpserver: end 29699 status 0
2020-04-20 05:07:50.207300500 tcpserver: status: 0/60

==> /var/log/qmail/smtps/current <==
2020-04-20 05:07:54.903665500 tcpserver: status: 9/60
2020-04-20 05:07:54.936654500 tcpserver: pid 29725 from 185.50.149.5
2020-04-20 05:07:54.936655500 tcpserver: ok 29725
dev.brayworth.com :172.105.181.18:465
 :185.50.149.5::5622
2020-04-20 05:08:00.108657500 tcpserver: status: 10/60
2020-04-20 05:08:00.152909500 tcpserver: pid 29734 from 185.50.149.5
2020-04-20 05:08:00.152910500 tcpserver: ok 29734
dev.brayworth.com :172.105.181.18:465
 :185.50.149.5::62006
2020-04-20 05:08:05.172650500 tcpserver: status: *11*/60
2020-04-20 05:08:05.208983500 tcpserver: pid 29740 from 185.50.149.5
2020-04-20 05:08:05.208984500 tcpserver: ok 29740
dev.brayworth.com :172.105.181.18:465
 :185.50.149.5::19686
2020-04-20 05:08:13.60133650

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

[remo]

I will give more suggestions in the morning time for bed. 

> Il giorno 19 apr 2020, alle ore 23:13, David Bray  ha 
> scritto:
> 
> 
> Hey thanks Remo
> smtps is an inbound port, they are contacting me - this IP is in Russia 
> somewhere - so do I want to engage (perhaps, probably not but ..)
> 
> I could of course block that IP - but that doesn't help, I'd have to block 
> endless IPs
> 
> I'd like to know what's taking the CPU load, in theory they should be 
> connecting, supplying a password (perhaps) and sending data
> but, there are sometimes bad passwords (2 for the 20th recorded in maillog)
> 
> So..
> What are they doing the other times and why is it taking so much CPU - if it 
> is just a port knock, why the CPU
> 
> I need to be able to say, they are bad because ... what is the because ?
> 
> David Bray
> 0418 745334
> 2 ∞ & <
> 
> 
>> On Mon, 20 Apr 2020 at 15:32, Remo Mattei  wrote:
>> Hi,
>> Can you reach the server?  It maybe blocking you. So what does your queue 
>> looks like?
>> 
>> Here is mine for example:
>> 
>> # qmHandle -L
>> Messages in local queue: 0
>> Messages in remote queue: 0
>> 
>> My other server 
>> 
>> # qmHandle -L
>> 10355792 (19, L)
>>   Return-path: r...@qmailx.com
>>   From: Anacron 
>>   To: r...@qmailx.com
>>   Subject: Anacron job 'cron.daily' on qmailx.com
>>   Date: 19 Apr 2020 10:28:28 -
>>   Size: 509 bytes
>> 
>> 10358746 (6, L)
>>   Return-path:
>>   From: mailer-dae...@qmailxx.com
>>   To: r...@qmail.com
>>   Subject: failure notice
>>   Date: 19 Apr 2020 11:30:30 -
>>   Size: 1089 bytes
>> 
>> Messages in local queue: 2
>> Messages in remote queue: 0
>> 
>> Just wonder it looks that you are using the SMTPs 465, did you try the 587 
>> Submission that address and see if it goes?
>> Just wonder if this is tight to that service. 
>> 
>> Maybe none of the above but just for troubleshooting steps, I would try 
>> that. 
>> 
>> Remo 
>> 
>> 
>>> On Apr 19, 2020, at 22:11, David Bray  wrote:
>>> 
>>> Ok - but after all the investigation etc, this is actually the trigger 
>>> which caught my eye in the first place
>>> 
>>> How this comes about is:
>>> User say hey I can't send
>>> I look and see this high CPU load and intermittent failures for client to 
>>> send
>>> Any thoughts on where to start looking ..
>>> 
>>> 
>>> 
>>> 
>>> my smtp/smtps are currently 10/11 connections
>>> 
>>> 
>>> ==> /var/log/qmail/smtp/current <==
>>> 2020-04-20 05:07:50.207299500 tcpserver: end 29699 status 0
>>> 2020-04-20 05:07:50.207300500 tcpserver: status: 0/60
>>> 
>>> ==> /var/log/qmail/smtps/current <==
>>> 2020-04-20 05:07:54.903665500 tcpserver: status: 9/60
>>> 2020-04-20 05:07:54.936654500 tcpserver: pid 29725 from 185.50.149.5
>>> 2020-04-20 05:07:54.936655500 tcpserver: ok 29725 
>>> dev.brayworth.com:172.105.181.18:465 :185.50.149.5::5622
>>> 2020-04-20 05:08:00.108657500 tcpserver: status: 10/60
>>> 2020-04-20 05:08:00.152909500 tcpserver: pid 29734 from 185.50.149.5
>>> 2020-04-20 05:08:00.152910500 tcpserver: ok 29734 
>>> dev.brayworth.com:172.105.181.18:465 :185.50.149.5::62006
>>> 2020-04-20 05:08:05.172650500 tcpserver: status: 11/60
>>> 2020-04-20 05:08:05.208983500 tcpserver: pid 29740 from 185.50.149.5
>>> 2020-04-20 05:08:05.208984500 tcpserver: ok 29740 
>>> dev.brayworth.com:172.105.181.18:465 :185.50.149.5::19686
>>> 2020-04-20 05:08:13.601336500 tcpserver: end 29690 status 256
>>> 2020-04-20 05:08:13.601337500 tcpserver: status: 10/60
>>> 
>>> David Bray
>>> 0418 745334
>>> 2 ∞ & <
>>> 
>>> 
 On Sun, 19 Apr 2020 at 10:04, David Bray  wrote:
 Thanks Eric
 
 It's hard to track things but I think I have had success monitoring the 
 /var/log/maillog
 
 I'm not sure why I didn't pick this up earlier, I'm already using the 
 fail2ban suggestion of the older qmailtoaster wiki 
 (http://wiki.qmailtoaster.com/index.php/Fail2Ban), actually had a rule to 
 process it and have expanded on this now
 
 I've been running email servers most of my working life and still get 
 tripped up by simple stuff
 
 Thank for your efforts in this area, it helps to talk things out
 
 cheers
 
 David Bray
 0418 745334
 2 ∞ & <
 
 
> On Sun, 19 Apr 2020 at 01:12, Eric Broch  wrote:
> It looks like a connect and disconnect. If there was authentication you'd 
> see it. I don't think you have anything to worry about here. I'm not 
> saying there's not some jerk out there messing with your smtps...just 
> saying it may be harmless. That said, do you have a good firewall in 
> place that prevents DOS attacks. I use Sonicwall myself but you can do 
> the same thing as others have shown with iptables.
> 
> Does anyone know how to do the same with the stock firewalld on COS7/8?
> 
> On 4/17/2020 11:49 PM, David Bray wrote:
>> sure - thanks for replying, this comes in waves taking the server to 
>> it's maximum at times

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

[David Bray]

Hey thanks Remo
smtps is an inbound port, they are contacting me - this IP is in Russia
somewhere - so do I want to engage (perhaps, probably not but ..)

I could of course block that IP - but that doesn't help, I'd have to block
endless IPs

I'd like to know what's taking the CPU load, in theory they should be
connecting, supplying a password (perhaps) and sending data
but, there are sometimes bad passwords (2 for the 20th recorded in maillog)

So..
What are they doing the other times and why is it taking so much CPU - if
it is just a port knock, why the CPU

I need to be able to say, they are bad because ... *what is the because* ?

David Bray
0418 745334
2 ∞ & <


On Mon, 20 Apr 2020 at 15:32, Remo Mattei  wrote:

> Hi,
> Can you reach the server?  It maybe blocking you. So what does your queue
> looks like?
>
> Here is mine for example:
>
> # qmHandle -L
> Messages in local queue: 0
> Messages in remote queue: 0
>
> My other server
>
> # qmHandle -L
> 10355792 (19, L)
>   Return-path: r...@qmailx.com
>   From: Anacron 
>   To: r...@qmailx.com
>   Subject: Anacron job 'cron.daily' on qmailx.com
>   Date: 19 Apr 2020 10:28:28 -
>   Size: 509 bytes
>
> 10358746 (6, L)
>   Return-path:
>   From: mailer-dae...@qmailxx.com
>   To: r...@qmail.com
>   Subject: failure notice
>   Date: 19 Apr 2020 11:30:30 -
>   Size: 1089 bytes
>
> Messages in local queue: 2
> Messages in remote queue: 0
>
> Just wonder it looks that you are using the SMTPs 465, did you try the 587
> Submission that address and see if it goes?
> Just wonder if this is tight to that service.
>
> Maybe none of the above but just for troubleshooting steps, I would try
> that.
>
> Remo
>
>
> On Apr 19, 2020, at 22:11, David Bray  wrote:
>
> Ok - but after all the investigation etc, this is actually the trigger
> which caught my eye in the first place
>
> How this comes about is:
>
>1. User say hey I can't send
>2. I look and see this high CPU load and intermittent failures for
>client to send
>
> Any thoughts on where to start looking ..
>
>
> 
>
> my smtp/smtps are currently *10*/11 connections
>
>
> ==> /var/log/qmail/smtp/current <==
> 2020-04-20 05:07:50.207299500 tcpserver: end 29699 status 0
> 2020-04-20 05:07:50.207300500 tcpserver: status: 0/60
>
> ==> /var/log/qmail/smtps/current <==
> 2020-04-20 05:07:54.903665500 tcpserver: status: 9/60
> 2020-04-20 05:07:54.936654500 tcpserver: pid 29725 from 185.50.149.5
> 2020-04-20 05:07:54.936655500 tcpserver: ok 29725 dev.brayworth.com:
> 172.105.181.18:465 :185.50.149.5::5622
> 2020-04-20 05:08:00.108657500 tcpserver: status: 10/60
> 2020-04-20 05:08:00.152909500 tcpserver: pid 29734 from 185.50.149.5
> 2020-04-20 05:08:00.152910500 tcpserver: ok 29734 dev.brayworth.com:
> 172.105.181.18:465 :185.50.149.5::62006
> 2020-04-20 05:08:05.172650500 tcpserver: status: *11*/60
> 2020-04-20 05:08:05.208983500 tcpserver: pid 29740 from 185.50.149.5
> 2020-04-20 05:08:05.208984500 tcpserver: ok 29740 dev.brayworth.com:
> 172.105.181.18:465 :185.50.149.5::19686
> 2020-04-20 05:08:13.601336500 tcpserver: end 29690 status 256
> 2020-04-20 05:08:13.601337500 tcpserver: status: 10/60
>
> David Bray
> 0418 745334
> 2 ∞ & <
>
>
> On Sun, 19 Apr 2020 at 10:04, David Bray  wrote:
>
>> Thanks Eric
>>
>> It's hard to track things but I think I have had success monitoring the
>> /var/log/maillog
>>
>> I'm not sure why I didn't pick this up earlier, I'm already using the
>> fail2ban suggestion of the older qmailtoaster wiki (
>> http://wiki.qmailtoaster.com/index.php/Fail2Ban), actually had a rule to
>> process it and have expanded on this now
>>
>> I've been running email servers most of my working life and still get
>> tripped up by simple stuff
>>
>> Thank for your efforts in this area, it helps to talk things out
>>
>> cheers
>>
>> David Bray
>> 0418 745334
>> 2 ∞ & <
>>
>>
>> On Sun, 19 Apr 2020 at 01:12, Eric Broch  wrote:
>>
>>> It looks like a connect and disconnect. If there was authentication
>>> you'd see it. I don't think you have anything to worry about here. I'm not
>>> saying there's not some jerk out there messing with your smtps...just
>>> saying it may be harmless. That said, do you have a good firewall in place
>>> that prevents DOS attacks. I use Sonicwall myself but you can do the same
>>> thing as others have shown with iptables.
>>>
>>> Does anyone know how to do the same with the stock firewalld on COS7/8?
>>> On 4/17/2020 11: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
>>> 

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

[Remo Mattei]

Hi,
Can you reach the server?  It maybe blocking you. So what does your queue looks 
like?

Here is mine for example:

# qmHandle -L
Messages in local queue: 0
Messages in remote queue: 0

My other server 

# qmHandle -L
10355792 (19, L)
  Return-path: r...@qmailx.com
  From: Anacron 
  To: r...@qmailx.com
  Subject: Anacron job 'cron.daily' on qmailx.com
  Date: 19 Apr 2020 10:28:28 -
  Size: 509 bytes

10358746 (6, L)
  Return-path:
  From: mailer-dae...@qmailxx.com
  To: r...@qmail.com
  Subject: failure notice
  Date: 19 Apr 2020 11:30:30 -
  Size: 1089 bytes

Messages in local queue: 2
Messages in remote queue: 0

Just wonder it looks that you are using the SMTPs 465, did you try the 587 
Submission that address and see if it goes?
Just wonder if this is tight to that service. 

Maybe none of the above but just for troubleshooting steps, I would try that. 

Remo 


> On Apr 19, 2020, at 22:11, David Bray  wrote:
> 
> Ok - but after all the investigation etc, this is actually the trigger which 
> caught my eye in the first place
> 
> How this comes about is:
> User say hey I can't send
> I look and see this high CPU load and intermittent failures for client to send
> Any thoughts on where to start looking ..
> 
> 
> 
> 
> my smtp/smtps are currently 10/11 connections
> 
> 
> ==> /var/log/qmail/smtp/current <==
> 2020-04-20 05:07:50.207299500 tcpserver: end 29699 status 0
> 2020-04-20 05:07:50.207300500 tcpserver: status: 0/60
> 
> ==> /var/log/qmail/smtps/current <==
> 2020-04-20 05:07:54.903665500 tcpserver: status: 9/60
> 2020-04-20 05:07:54.936654500 tcpserver: pid 29725 from 185.50.149.5
> 2020-04-20 05:07:54.936655500 tcpserver: ok 29725 
> dev.brayworth.com:172.105.181.18:465 :185.50.149.5::5622
> 2020-04-20 05:08:00.108657500 tcpserver: status: 10/60
> 2020-04-20 05:08:00.152909500 tcpserver: pid 29734 from 185.50.149.5
> 2020-04-20 05:08:00.152910500 tcpserver: ok 29734 
> dev.brayworth.com:172.105.181.18:465 :185.50.149.5::62006
> 2020-04-20 05:08:05.172650500 tcpserver: status: 11/60
> 2020-04-20 05:08:05.208983500 tcpserver: pid 29740 from 185.50.149.5
> 2020-04-20 05:08:05.208984500 tcpserver: ok 29740 
> dev.brayworth.com:172.105.181.18:465 :185.50.149.5::19686
> 2020-04-20 05:08:13.601336500 tcpserver: end 29690 status 256
> 2020-04-20 05:08:13.601337500 tcpserver: status: 10/60
> 
> David Bray
> 0418 745334
> 2 ∞ & <
> 
> 
> On Sun, 19 Apr 2020 at 10:04, David Bray  > wrote:
> Thanks Eric
> 
> It's hard to track things but I think I have had success monitoring the 
> /var/log/maillog
> 
> I'm not sure why I didn't pick this up earlier, I'm already using the 
> fail2ban suggestion of the older qmailtoaster wiki 
> (http://wiki.qmailtoaster.com/index.php/Fail2Ban 
> ), actually had a rule to 
> process it and have expanded on this now
> 
> I've been running email servers most of my working life and still get tripped 
> up by simple stuff
> 
> Thank for your efforts in this area, it helps to talk things out
> 
> cheers
> 
> David Bray
> 0418 745334
> 2 ∞ & <
> 
> 
> On Sun, 19 Apr 2020 at 01:12, Eric Broch  > wrote:
> It looks like a connect and disconnect. If there was authentication you'd see 
> it. I don't think you have anything to worry about here. I'm not saying 
> there's not some jerk out there messing with your smtps...just saying it may 
> be harmless. That said, do you have a good firewall in place that prevents 
> DOS attacks. I use Sonicwall myself but you can do the same thing as others 
> have shown with iptables.
> 
> Does anyone know how to do the same with the stock firewalld on COS7/8?
> 
> On 4/17/2020 11: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 

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

[David Bray]

Ok - but after all the investigation etc, this is actually the trigger
which caught my eye in the first place

How this comes about is:

   1. User say hey I can't send
   2. I look and see this high CPU load and intermittent failures for
   client to send

Any thoughts on where to start looking ..


[image: image.png]

my smtp/smtps are currently *10*/11 connections


==> /var/log/qmail/smtp/current <==
2020-04-20 05:07:50.207299500 tcpserver: end 29699 status 0
2020-04-20 05:07:50.207300500 tcpserver: status: 0/60

==> /var/log/qmail/smtps/current <==
2020-04-20 05:07:54.903665500 tcpserver: status: 9/60
2020-04-20 05:07:54.936654500 tcpserver: pid 29725 from 185.50.149.5
2020-04-20 05:07:54.936655500 tcpserver: ok 29725
dev.brayworth.com:172.105.181.18:465
:185.50.149.5::5622
2020-04-20 05:08:00.108657500 tcpserver: status: 10/60
2020-04-20 05:08:00.152909500 tcpserver: pid 29734 from 185.50.149.5
2020-04-20 05:08:00.152910500 tcpserver: ok 29734
dev.brayworth.com:172.105.181.18:465
:185.50.149.5::62006
2020-04-20 05:08:05.172650500 tcpserver: status: *11*/60
2020-04-20 05:08:05.208983500 tcpserver: pid 29740 from 185.50.149.5
2020-04-20 05:08:05.208984500 tcpserver: ok 29740
dev.brayworth.com:172.105.181.18:465
:185.50.149.5::19686
2020-04-20 05:08:13.601336500 tcpserver: end 29690 status 256
2020-04-20 05:08:13.601337500 tcpserver: status: 10/60

David Bray
0418 745334
2 ∞ & <


On Sun, 19 Apr 2020 at 10:04, David Bray  wrote:

> Thanks Eric
>
> It's hard to track things but I think I have had success monitoring the
> /var/log/maillog
>
> I'm not sure why I didn't pick this up earlier, I'm already using the
> fail2ban suggestion of the older qmailtoaster wiki (
> http://wiki.qmailtoaster.com/index.php/Fail2Ban), actually had a rule to
> process it and have expanded on this now
>
> I've been running email servers most of my working life and still get
> tripped up by simple stuff
>
> Thank for your efforts in this area, it helps to talk things out
>
> cheers
>
> David Bray
> 0418 745334
> 2 ∞ & <
>
>
> On Sun, 19 Apr 2020 at 01:12, Eric Broch  wrote:
>
>> It looks like a connect and disconnect. If there was authentication you'd
>> see it. I don't think you have anything to worry about here. I'm not saying
>> there's not some jerk out there messing with your smtps...just saying it
>> may be harmless. That said, do you have a good firewall in place that
>> prevents DOS attacks. I use Sonicwall myself but you can do the same thing
>> as others have shown with iptables.
>>
>> Does anyone know how to do the same with the stock firewalld on COS7/8?
>> On 4/17/2020 11: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]

Thanks Eric

It's hard to track things but I think I have had success monitoring the
/var/log/maillog

I'm not sure why I didn't pick this up earlier, I'm already using the
fail2ban suggestion of the older qmailtoaster wiki (
http://wiki.qmailtoaster.com/index.php/Fail2Ban), actually had a rule to
process it and have expanded on this now

I've been running email servers most of my working life and still get
tripped up by simple stuff

Thank for your efforts in this area, it helps to talk things out

cheers

David Bray
0418 745334
2 ∞ & <


On Sun, 19 Apr 2020 at 01:12, Eric Broch  wrote:

> It looks like a connect and disconnect. If there was authentication you'd
> see it. I don't think you have anything to worry about here. I'm not saying
> there's not some jerk out there messing with your smtps...just saying it
> may be harmless. That said, do you have a good firewall in place that
> prevents DOS attacks. I use Sonicwall myself but you can do the same thing
> as others have shown with iptables.
>
> Does anyone know how to do the same with the stock firewalld on COS7/8?
> On 4/17/2020 11: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 ?

[Tahnan Al Anas]

I don't know if anyone use csf firewall. It have many options to prevent
such issues.


--
--

Best Regards
Muhammad Tahnan Al Anas


On Sat, Apr 18, 2020 at 9:12 PM Eric Broch  wrote:

> It looks like a connect and disconnect. If there was authentication you'd
> see it. I don't think you have anything to worry about here. I'm not saying
> there's not some jerk out there messing with your smtps...just saying it
> may be harmless. That said, do you have a good firewall in place that
> prevents DOS attacks. I use Sonicwall myself but you can do the same thing
> as others have shown with iptables.
>
> Does anyone know how to do the same with the stock firewalld on COS7/8?
> On 4/17/2020 11: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 ?

[remo]

I stopped iptables and moved to pfsense for my front end firewall. Way more 
options and easier to deal with. 

> Il giorno 18 apr 2020, alle ore 08:11, Eric Broch  
> ha scritto:
> 
> 
> It looks like a connect and disconnect. If there was authentication you'd see 
> it. I don't think you have anything to worry about here. I'm not saying 
> there's not some jerk out there messing with your smtps...just saying it may 
> be harmless. That said, do you have a good firewall in place that prevents 
> DOS attacks. I use Sonicwall myself but you can do the same thing as others 
> have shown with iptables.
> 
> Does anyone know how to do the same with the stock firewalld on COS7/8?
> 
> On 4/17/2020 11: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 ∞ & <
-
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]

It looks like a connect and disconnect. If there was authentication 
you'd see it. I don't think you have anything to worry about here. I'm 
not saying there's not some jerk out there messing with your 
smtps...just saying it may be harmless. That said, do you have a good 
firewall in place that prevents DOS attacks. I use Sonicwall myself but 
you can do the same thing as others have shown with iptables.


Does anyone know how to do the same with the stock firewalld on COS7/8?

On 4/17/2020 11: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 ?

[Leonardo - IW Telecom]

Hi David, I don't know if this can help you but I use iptables with
xrecent module to limit 10 connections per minute on each port on my
server: 

iptables -A INPUT -p tcp --dport 25 -m state --state NEW -m recent --set
--name SMTP --rsource
iptables -A INPUT -p tcp --dport 25 -m state --state NEW -m recent
--update --seconds 60 --hitcount 10 --name SMTP --rsource -j DROP
iptables -A INPUT -p tcp --dport 110 -m state --state NEW -m recent
--set --name POP3 --rsource
iptables -A INPUT -p tcp --dport 110 -m state --state NEW -m recent
--update --seconds 60 --hitcount 10 --name POP3 --rsource -j DROP
iptables -A INPUT -p tcp --dport 995 -m state --state NEW -m recent
--set --name POP3S --rsource
iptables -A INPUT -p tcp --dport 995 -m state --state NEW -m recent
--update --seconds 60 --hitcount 10 --name POP3S --rsource -j DROP
iptables -A INPUT -p tcp --dport 465 -m state --state NEW -m recent
--set --name SMTPS --rsource
iptables -A INPUT -p tcp --dport 465 -m state --state NEW -m recent
--update --seconds 60 --hitcount 10 --name SMTPS --rsource -j DROP
iptables -A INPUT -p tcp --dport 587 -m state --state NEW -m recent
--set --name SUBMISSION --rsource
iptables -A INPUT -p tcp --dport 587 -m state --state NEW -m recent
--update --seconds 60 --hitcount 10 --name SUBMISSION --rsource -j DROP 

To check the blocked IPs see /proc/net/xt_recent/ 

The bad thing is it uses conntrack to work.

---

Em 2020-04-18 07:33, David Bray escreveu:

> Hi Tony, thanks 
> But not so much looking for a solution to block ips. 
> 
> I'm needing to identify which ips to block 
> 
> On Sat, 18 Apr 2020 at 8:19 pm, Tony White  wrote: 
> 
>> Or this...
>> 
>> -- snip --
>> #!/bin/bash
>> logf="/var/log/blockip.log"
>> mdate=`date +%c`
>> mip=$1
>> ### must be root ###
>> if [ `whoami` != "root" ]; then
>> echo ""
>> echo "$0 must be run as root"
>> echo ""
>> exit 1
>> fi;
>> 
>> if [ $mip == "--help" ]; then
>> echo ""
>> echo "Help: Block single and subnet IP's"
>> echo ""
>> echo "blockip 130.2.1.1"
>> echo "blockip 130.2.1.0/24 [1]"
>> echo ""
>> exit 1
>> fi;
>> 
>> mip1=${mip:0:6};
>> # your lan range if needed or comment out
>> if [ $mip1 == "192.168.1." ]; then  # change ip to suit
>> echo "$mdate Discarding LAN drop request for $mip1" >> $logf
>> exit 1
>> fi;
>> 
>> # whitelist special clients...
>> # change the IP.ADDR.ESS to suit.
>> # comment out to remove
>> if [ $mip == "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" ] || [ $mip == 
>> "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" ] || [ 
>> $mip == "IP.ADDR.ESS" ] ; then
>> echo "$mdate Discarding WAN drop request for $mip" >> $logf
>> echo "$mdate Discarding WAN drop request for $mip"
>> exit 1
>> fi;
>> 
>> export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
>> is_ip="grep -Ec 
>> '^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"
>> 
>> if [ `echo $mip |eval $is_ip` != "1" ]; then
>> echo "$mdate Error in IP address $mip" >> $logf
>> echo "$mdate Error in IP address $mip"
>> else
>> iptables -I INPUT -s $mip -j DROP
>> echo "iptables -I INPUT -s $mip -j DROP"
>> echo "iptables -I INPUT -s $mip -j DROP" >> /etc/rc.d/rc.blockedips
>> echo "$mdate now dropping all packets from $mip" >> $logf
>> fi;
>> -- snip --
>> 
>> best wishes
>> Tony White
>> 
>> On 18/4/20 8:09 pm, Tony White wrote:
>> 
>>> Hi David,
>>> Sorry try this instead...
>>> 
>>> -- snip --
>>> #!/bin/sh
>>> logf="/var/log/blacklist_ip.log"
>>> mdate=`date +%c`
>>> ### must be root ###
>>> if [ `whoami` != "root" ]; then
>>> echo ""
>>> echo "$0 must be ran as root"
>>> echo ""
>>> exit 1
>>> fi
>>> export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
>>> is_ip="grep -Ec 
>>> '^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"
>>> 
>>> if [ `echo $1 |eval $is_ip` != "1" ]; then
>>> echo "$mdate Error in IP address $1" >> $logf
>>> else
>>> echo "$1" >> /opt/spamdyke/etc/blacklist_ip
>>> echo "$mdate now dropping all packets from $1" >> $logf
>>> fi
>>> --snip --
>>> 
>>> best wishes
>>> Tony White
>>> On 18/4/20 8:04 pm, Tony White wrote:
>>> 
 Hi David,
 Try using this little script...
 
 -- snip --
 #!/bin/bash
 logf="/var/log/blockip.log"
 mdate=`date +%c`
 mip=$1
 ### must be root ###
 if [ `whoami` != "root" ]; then
 echo ""
 echo "$0 must be run as root"
 echo ""
 exit 1
 fi;
 
 if [ $mip == "--help" ]; then
 echo ""
 echo "Help: Block single and subnet IP's"
 echo ""
 echo "blockip 132.2.1.1"
 echo "blockip 132.1.0/24"
 echo ""
 exit 1
 fi;
 
 -- snip --
 
 worked for me forever...
 Use qtp watchall to monitor the logs a

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

[Tony White]

Hi David,
The ip you are having issues with returns (NXDOMAIN) so try
using this or a variant on the search string to find what
you are looking for.

-- snip --
#!/bin/bash
mdate=`date +%c`
mip=$1
### must be root ###
if [ `whoami` != "root" ]; then
    echo ""
    echo "$0 must be run as root"
    echo ""
    exit 1
fi;

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
is_ip="grep -Ec 
'^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"

 is_v=`grep $1 /var/log/qmail/smtp/current | wc -l`
 echo "Counted : $is_v entries"

if [ "$is_v" != "" ]; then
   is_host=`host $1`
   echo "Host RDNS = $is_host"
   if echo "$is_host" | grep -q "(NXDOMAIN)"; then
   #  echo "(NX Domain) found, block IP automatically..."
   # /lscripts/blockip $mip
    read -p "(NX Domain) found, block IP automatically Y/N : " yn
    case $yn in
  [Yy]* ) `/lscripts/blockip $mip`;;
  [Nn]* ) exit;;
    esac
   fi;
fi;

-- snip --

Try this to count the number of times an ip connects..

--snip --
#!/bin/bash
PATTERN="DENIED"
FILE="/var/log/qmail/smtp/current"
f1="/tmp/ips.txt"
f2="/tmp/current.txt"
f3="/tmp/ipn.txt"

if [ -n "$1" ] ;
then
  cd /var/log/qmail/smtp
  newfile=`lshead -t @* | head -n1`
  echo "Scanning : "$newfile
  FILE="/var/log/qmail/smtp/$newfile"
fi

echo $FILE

[[ -f "$f1" ]] && rm -f "$f1"
[[ -f "$f2" ]] && rm -f "$f2"
# was -q between grep ans $PATTERN
if grep -q $PATTERN $FILE;
 then
 #echo "Here are the Strings with the Pattern '$PATTERN':"
 echo -e "$(grep $PATTERN $FILE > $f2)\n"
 #echo -e "$(wc -l $f2)\n"
 while read line
 do
  ar=($line)
  #echo -e "${ar[8]}\n"
  echo -e ${ar[8]}>> "$f1"
    done < "$f2"
    echo -e "$(sort -n $f1 > $f3)"
    echo -e "$(uniq -dc $f3)"
  else
 echo "Error: The Pattern '$PATTERN' was NOT Found in '$FILE'"
 echo "Exiting..."
 exit 0
fi

-- snip --

best wishes
  Tony White

On 18/4/20 8:33 pm, David Bray wrote:


Hi Tony, thanks
But not so much looking for a solution to block ips.

I’m needing to identify which ips to block

On Sat, 18 Apr 2020 at 8:19 pm, Tony White mailto:t...@ycs.com.au>> wrote:

Or this...

-- snip --
#!/bin/bash
logf="/var/log/blockip.log"
mdate=`date +%c`
mip=$1
### must be root ###
if [ `whoami` != "root" ]; then
 echo ""
 echo "$0 must be run as root"
 echo ""
 exit 1
fi;

if [ $mip == "--help" ]; then
   echo ""
   echo "Help: Block single and subnet IP's"
   echo ""
   echo "blockip 130.2.1.1"
   echo "blockip 130.2.1.0/24 "
   echo ""
   exit 1
fi;

mip1=${mip:0:6};
# your lan range if needed or comment out
if [ $mip1 == "192.168.1." ]; then  # change ip to suit
   echo "$mdate Discarding LAN drop request for $mip1" >> $logf
   exit 1
fi;


# whitelist special clients...
# change the IP.ADDR.ESS to suit.
# comment out to remove
if [ $mip == "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" 
] || [ $mip == "IP.ADDR.ESS" ] || [
$mip == "IP.ADDR.ESS" ] ; then
   echo "$mdate Discarding WAN drop request for $mip" >> $logf
   echo "$mdate Discarding WAN drop request for $mip"
   exit 1
fi;

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
is_ip="grep -Ec 
'^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"

if [ `echo $mip |eval $is_ip` != "1" ]; then
   echo "$mdate Error in IP address $mip" >> $logf
   echo "$mdate Error in IP address $mip"
else
   iptables -I INPUT -s $mip -j DROP
   echo "iptables -I INPUT -s $mip -j DROP"
   echo "iptables -I INPUT -s $mip -j DROP" >> /etc/rc.d/rc.blockedips
   echo "$mdate now dropping all packets from $mip" >> $logf
fi;
-- snip --

best wishes
   Tony White

On 18/4/20 8:09 pm, Tony White wrote:

> Hi David,
>   Sorry try this instead...
>
> -- snip --
> #!/bin/sh
> logf="/var/log/blacklist_ip.log"
> mdate=`date +%c`
> ### must be root ###
> if [ `whoami` != "root" ]; then
>     echo ""
>     echo "$0 must be ran as root"
>     echo ""
>     exit 1
> fi
> export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
> is_ip="grep -Ec 
'^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"
>
> if [ `echo $1 |eval $is_ip` != "1" ]; then
> echo "$mdate Error in IP address $1" >> $logf
> else
> echo "$1" >> /opt/spamdyke/etc/blacklist_ip
> echo "$mdate now dropping all packets from $1" >> $logf
> fi
> --snip --
>
> best wishes
>   Tony White
> On 18/

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

[David Bray]

Hi Tony, thanks
But not so much looking for a solution to block ips.

I’m needing to identify which ips to block

On Sat, 18 Apr 2020 at 8:19 pm, Tony White  wrote:

> Or this...
>
> -- snip --
> #!/bin/bash
> logf="/var/log/blockip.log"
> mdate=`date +%c`
> mip=$1
> ### must be root ###
> if [ `whoami` != "root" ]; then
>  echo ""
>  echo "$0 must be run as root"
>  echo ""
>  exit 1
> fi;
>
> if [ $mip == "--help" ]; then
>echo ""
>echo "Help: Block single and subnet IP's"
>echo ""
>echo "blockip 130.2.1.1"
>echo "blockip 130.2.1.0/24"
>echo ""
>exit 1
> fi;
>
> mip1=${mip:0:6};
> # your lan range if needed or comment out
> if [ $mip1 == "192.168.1." ]; then  # change ip to suit
>echo "$mdate Discarding LAN drop request for $mip1" >> $logf
>exit 1
> fi;
>
>
> # whitelist special clients...
> # change the IP.ADDR.ESS to suit.
> # comment out to remove
> if [ $mip == "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" ] || [ $mip ==
> "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" ] || [
> $mip == "IP.ADDR.ESS" ] ; then
>echo "$mdate Discarding WAN drop request for $mip" >> $logf
>echo "$mdate Discarding WAN drop request for $mip"
>exit 1
> fi;
>
> export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
> is_ip="grep -Ec
> '^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"
>
> if [ `echo $mip |eval $is_ip` != "1" ]; then
>echo "$mdate Error in IP address $mip" >> $logf
>echo "$mdate Error in IP address $mip"
> else
>iptables -I INPUT -s $mip -j DROP
>echo "iptables -I INPUT -s $mip -j DROP"
>echo "iptables -I INPUT -s $mip -j DROP" >> /etc/rc.d/rc.blockedips
>echo "$mdate now dropping all packets from $mip" >> $logf
> fi;
> -- snip --
>
> best wishes
>Tony White
>
> On 18/4/20 8:09 pm, Tony White wrote:
>
> > Hi David,
> >   Sorry try this instead...
> >
> > -- snip --
> > #!/bin/sh
> > logf="/var/log/blacklist_ip.log"
> > mdate=`date +%c`
> > ### must be root ###
> > if [ `whoami` != "root" ]; then
> > echo ""
> > echo "$0 must be ran as root"
> > echo ""
> > exit 1
> > fi
> > export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
> > is_ip="grep -Ec
> '^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"
> >
> > if [ `echo $1 |eval $is_ip` != "1" ]; then
> > echo "$mdate Error in IP address $1" >> $logf
> > else
> > echo "$1" >> /opt/spamdyke/etc/blacklist_ip
> > echo "$mdate now dropping all packets from $1" >> $logf
> > fi
> > --snip --
> >
> > best wishes
> >   Tony White
> > On 18/4/20 8:04 pm, Tony White wrote:
> >
> >> Hi David,
> >>   Try using this little script...
> >>
> >> -- snip --
> >> #!/bin/bash
> >> logf="/var/log/blockip.log"
> >> mdate=`date +%c`
> >> mip=$1
> >> ### must be root ###
> >> if [ `whoami` != "root" ]; then
> >> echo ""
> >> echo "$0 must be run as root"
> >> echo ""
> >> exit 1
> >> fi;
> >>
> >> if [ $mip == "--help" ]; then
> >>   echo ""
> >>   echo "Help: Block single and subnet IP's"
> >>   echo ""
> >>   echo "blockip 132.2.1.1"
> >>   echo "blockip 132.1.0/24"
> >>   echo ""
> >>   exit 1
> >> fi;
> >>
> >> -- snip --
> >>
> >> worked for me forever...
> >> Use qtp watchall to monitor the logs and use th output to manually
> block ips or subnets
> >>
> >> If you need more hit me off list.
> >>
> >> best wishes
> >>   Tony White
> >> On 18/4/20 2: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 ∞ & <
> >>
> >>
> >> -
> >> 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
>
> --
# David

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

[Tony White]

Or this...

-- snip --
#!/bin/bash
logf="/var/log/blockip.log"
mdate=`date +%c`
mip=$1
### must be root ###
if [ `whoami` != "root" ]; then
    echo ""
    echo "$0 must be run as root"
    echo ""
    exit 1
fi;

if [ $mip == "--help" ]; then
  echo ""
  echo "Help: Block single and subnet IP's"
  echo ""
  echo "blockip 130.2.1.1"
  echo "blockip 130.2.1.0/24"
  echo ""
  exit 1
fi;

mip1=${mip:0:6};
# your lan range if needed or comment out
if [ $mip1 == "192.168.1." ]; then  # change ip to suit
  echo "$mdate Discarding LAN drop request for $mip1" >> $logf
  exit 1
fi;


# whitelist special clients...
# change the IP.ADDR.ESS to suit.
# comment out to remove
if [ $mip == "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" ] || [ 
$mip == "IP.ADDR.ESS" ] ; then

  echo "$mdate Discarding WAN drop request for $mip" >> $logf
  echo "$mdate Discarding WAN drop request for $mip"
  exit 1
fi;

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
is_ip="grep -Ec 
'^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"

if [ `echo $mip |eval $is_ip` != "1" ]; then
  echo "$mdate Error in IP address $mip" >> $logf
  echo "$mdate Error in IP address $mip"
else
  iptables -I INPUT -s $mip -j DROP
  echo "iptables -I INPUT -s $mip -j DROP"
  echo "iptables -I INPUT -s $mip -j DROP" >> /etc/rc.d/rc.blockedips
  echo "$mdate now dropping all packets from $mip" >> $logf
fi;
-- snip --

best wishes
  Tony White

On 18/4/20 8:09 pm, Tony White wrote:


Hi David,
  Sorry try this instead...

-- snip --
#!/bin/sh
logf="/var/log/blacklist_ip.log"
mdate=`date +%c`
### must be root ###
if [ `whoami` != "root" ]; then
    echo ""
    echo "$0 must be ran as root"
    echo ""
    exit 1
fi
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
is_ip="grep -Ec 
'^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"

if [ `echo $1 |eval $is_ip` != "1" ]; then
echo "$mdate Error in IP address $1" >> $logf
else
echo "$1" >> /opt/spamdyke/etc/blacklist_ip
echo "$mdate now dropping all packets from $1" >> $logf
fi
--snip --

best wishes
  Tony White
On 18/4/20 8:04 pm, Tony White wrote:


Hi David,
  Try using this little script...

-- snip --
#!/bin/bash
logf="/var/log/blockip.log"
mdate=`date +%c`
mip=$1
### must be root ###
if [ `whoami` != "root" ]; then
    echo ""
    echo "$0 must be run as root"
    echo ""
    exit 1
fi;

if [ $mip == "--help" ]; then
  echo ""
  echo "Help: Block single and subnet IP's"
  echo ""
  echo "blockip 132.2.1.1"
  echo "blockip 132.1.0/24"
  echo ""
  exit 1
fi;

-- snip --

worked for me forever...
Use qtp watchall to monitor the logs and use th output to manually block ips or 
subnets

If you need more hit me off list.

best wishes
  Tony White
On 18/4/20 2: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 ∞ & <



-
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 ?

[David Bray]

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 ?

[Tony White]

Hi David,
  Sorry try this instead...

-- snip --
#!/bin/sh
logf="/var/log/blacklist_ip.log"
mdate=`date +%c`
### must be root ###
if [ `whoami` != "root" ]; then
    echo ""
    echo "$0 must be ran as root"
    echo ""
    exit 1
fi
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
is_ip="grep -Ec 
'^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"

if [ `echo $1 |eval $is_ip` != "1" ]; then
echo "$mdate Error in IP address $1" >> $logf
else
echo "$1" >> /opt/spamdyke/etc/blacklist_ip
echo "$mdate now dropping all packets from $1" >> $logf
fi
--snip --

best wishes
  Tony White
On 18/4/20 8:04 pm, Tony White wrote:


Hi David,
  Try using this little script...

-- snip --
#!/bin/bash
logf="/var/log/blockip.log"
mdate=`date +%c`
mip=$1
### must be root ###
if [ `whoami` != "root" ]; then
    echo ""
    echo "$0 must be run as root"
    echo ""
    exit 1
fi;

if [ $mip == "--help" ]; then
  echo ""
  echo "Help: Block single and subnet IP's"
  echo ""
  echo "blockip 132.2.1.1"
  echo "blockip 132.1.0/24"
  echo ""
  exit 1
fi;

-- snip --

worked for me forever...
Use qtp watchall to monitor the logs and use th output to manually block ips or 
subnets

If you need more hit me off list.

best wishes
  Tony White
On 18/4/20 2: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 ∞ & <



-
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 ?

[Tony White]

Hi David,
  Try using this little script...

-- snip --
#!/bin/bash
logf="/var/log/blockip.log"
mdate=`date +%c`
mip=$1
### must be root ###
if [ `whoami` != "root" ]; then
    echo ""
    echo "$0 must be run as root"
    echo ""
    exit 1
fi;

if [ $mip == "--help" ]; then
  echo ""
  echo "Help: Block single and subnet IP's"
  echo ""
  echo "blockip 132.2.1.1"
  echo "blockip 132.1.0/24"
  echo ""
  exit 1
fi;

-- snip --

worked for me forever...
Use qtp watchall to monitor the logs and use th output to manually block ips or 
subnets

If you need more hit me off list.

best wishes
  Tony White
On 18/4/20 2: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 ∞ & <



-
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 ?

[Chris]

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]

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 ?

[Eric Broch]

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 ∞ & <