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