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 .*:<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 <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 <r...@mattei.org
    <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
        <da...@brayworth.com.au <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 .*:<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
        <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 <ebr...@whitehorsetc.com
            <mailto:ebr...@whitehorsetc.com>>
            *Reply-To: *<qmailtoaster-list@qmailtoaster.com
            <mailto:qmailtoaster-list@qmailtoaster.com>>
            *Date: *Wednesday, April 22, 2020 at 9:40 AM
            *To: *<qmailtoaster-list@qmailtoaster.com
            <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
                <boh...@gmail.com <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
                    <da...@brayworth.com.au
                    <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
                        <ebr...@whitehorsetc.com
                        <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

Reply via email to