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 .*:<HOST>
            vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*:<HOST>
            spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: <HOST>
origin_rdns:.*$
            spamdyke.*?: DENIED_RDNS_MISSING .*origin_ip: <HOST>
origin_rdns:.*$

Thanks to those that replied


David Bray
0418 745334
2 ∞ & <


On Thu, 23 Apr 2020 at 11:17, David Bray <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 <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 <
>> 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 .*:<HOST>
>>             vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*:<HOST>
>>             spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: <HOST>
>> 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 <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 <ebr...@whitehorsetc.com>
>>> *Reply-To: *<qmailtoaster-list@qmailtoaster.com>
>>> *Date: *Wednesday, April 22, 2020 at 9:40 AM
>>> *To: *<qmailtoaster-list@qmailtoaster.com>
>>> *Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ?
>>>
>>>
>>>
>>> Hi David,
>>>
>>> I think you're on to something with fail2ban (keying off maillog). I was
>>> monitoring my smtps port (watching the certificate and encryption scroll
>>> by) using /usr/bin/recordio and /var/log/maillog and found that the bad
>>> guys are trying to login. Here are some failures from maillog:
>>>
>>> vchkpw-smtps: vpopmail user not found
>>> testforu...@whitehorsetc.com:92.118.38.83
>>>
>>> vchkpw-smtps: password fail (pass: 'somepassword')
>>> someu...@whitehorsetc.com:185.50.149.2
>>>
>>> Maybe a fail2ban rule?!
>>>
>>> Eric
>>>
>>>
>>>
>>> On 4/18/2020 4:12 AM, David Bray wrote:
>>>
>>> Hi thanks - yes can block that IP
>>>
>>> But it’s not just one, and the solution is not fine enough
>>>
>>> I want more of a fail2ban rule, bad use bad pass 3 strikes your out
>>>
>>>
>>>
>>> I need to know they are mucking round.
>>>
>>>
>>>
>>> I tried sending myself through the port with a bad password- sure it
>>> blocks it, but there is no log of the event - it looks like a legit,
>>> connection from Ann IP
>>>
>>>
>>>
>>> On Sat, 18 Apr 2020 at 7:30 pm, Chris <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 <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 <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
>>>
>>>

Reply via email to