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