Re: [mailop] Hen and egg problem with Talos
On 07.07.21 23:12, Jay Hennigan via mailop wrote: >> Encourage transparent 2FA, and options like country auth restrictions, >> blocking AUTH from cloud providers/hosting companies known for being a >> haven for those types of attacks, (should make a blog post on best >> practices for authentication on email servers one day) but.. > > [snip] > > Fail2ban can be very useful here. It's running to protect against brute force attacks, but it doesn't help against phished passwords. We also check against the number of different client addresses, since they often use multiple bot hosts - spread all over the world - after the data was phished. But this time it was just one host. Regards Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster University of Applied Sciences Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83-64908 Fax: +49 251 83-64910 E-Mail: b...@fh-muenster.de https://www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hen and egg problem with Talos
On 7/7/21 13:08, Michael Peddemors via mailop wrote: [snip] You should consider adding some AUTH protections of course, to mitigate compromised accounts, and better detection/rate limiters for when they do. Encourage transparent 2FA, and options like country auth restrictions, blocking AUTH from cloud providers/hosting companies known for being a haven for those types of attacks, (should make a blog post on best practices for authentication on email servers one day) but.. [snip] Fail2ban can be very useful here. -- Jay Hennigan - j...@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hen and egg problem with Talos
On 07.07.21 22:08, Michael Peddemors via mailop wrote: > Start by including the IP(s) you are discussing ;) mx-out-01.fh-muenster.de [185.149.214.63] mx-out-02.fh-muenster.de [212.201.120.206] > Compromised accounts are indeed the bane of the responsible > administrator, and as you can see.. the rate limiting systems ARE > essential, you are unlikely to suffer a reputation issue, if only a few > escape (unless they have REALLY bad content, your mail server should not > be processing). Absolutely. That's why we had rate limits in place for different markers: mailcounts each by sender address, authenticated user and client in different time frames. So far this had worked fine. So that other can learn from our mistake: Someone whitelisted the internal Exchange systems from the clients, because they kept triggering the limits, believing they'd get caught by the other markers which they did not. > Encourage transparent 2FA, and options like country auth restrictions, > blocking AUTH from cloud providers/hosting companies known for being a > haven for those types of attacks, (should make a blog post on best > practices for authentication on email servers one day) but.. Please do :) - I have actually thought about limiting AUTH to local networks, because we have VPN available for all clients - which would add another level. But that requires some effort from the "customers" and of course was not well received. It could also be circumvented after a user's credentials were phished. > As you correctly noted, yes.. cleaning up your reputation and getting > off blacklists IS the punishment for not being pro-active on issues like > that. It isn't the blacklist operators fault after all ;) I fully agree. And I've added another self-flagellation by posting here ;) > Most blacklists and reputation services are pretty understanding, if you > clearly communicate, and your email server is for the most part > professionally operated. And remember, be kind to them, they aren't your > enemy, and they probably get more than their fair of yelling and > screaming.. I'd never do anything like that. Especially since it's our fault and I have been doing this long enough to appreciate their work - after all they are my own line of defense too. > Now, having said that.. it is ALWAYS best to follow the posted > procedures for asking for removal, but if it does NOT fix things in say > 48 hours (hard to wait when you have screaming customers I know) then > their are good people on this list and others that can help you, as long > as you show that you already following their SOP for removal. I was able to switch over to other outgoing servers for now, so the customers have extinguished their torches (most of them didn't even notice). I am just confused on how to fix the reputation of those two boxes by sending emails without being able to send emails. Regards Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster University of Applied Sciences Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83-64908 Fax: +49 251 83-64910 E-Mail: b...@fh-muenster.de https://www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hen and egg problem with Talos
Start by including the IP(s) you are discussing ;) Compromised accounts are indeed the bane of the responsible administrator, and as you can see.. the rate limiting systems ARE essential, you are unlikely to suffer a reputation issue, if only a few escape (unless they have REALLY bad content, your mail server should not be processing). You should consider adding some AUTH protections of course, to mitigate compromised accounts, and better detection/rate limiters for when they do. Encourage transparent 2FA, and options like country auth restrictions, blocking AUTH from cloud providers/hosting companies known for being a haven for those types of attacks, (should make a blog post on best practices for authentication on email servers one day) but.. As you correctly noted, yes.. cleaning up your reputation and getting off blacklists IS the punishment for not being pro-active on issues like that. It isn't the blacklist operators fault after all ;) Most blacklists and reputation services are pretty understanding, if you clearly communicate, and your email server is for the most part professionally operated. And remember, be kind to them, they aren't your enemy, and they probably get more than their fair of yelling and screaming.. Now, having said that.. it is ALWAYS best to follow the posted procedures for asking for removal, but if it does NOT fix things in say 48 hours (hard to wait when you have screaming customers I know) then their are good people on this list and others that can help you, as long as you show that you already following their SOP for removal. (Nice to have the cast off, can type a real email again) On 2021-07-07 12:18 p.m., Thomas Walter via mailop wrote: Hey guys, I have to take the walk of shame and report a spam outbreak on my systems because of a phished user account and a loophole in the rate limiting we do. As soon as we got notifed, we stopped and cleaned the queues, blocked the user, investigated the cause and fixed the rate limiting before restarting. Of course this put us on multiple blacklists and cleaning those up is the proper punishment I guess. Now two of our outgoing systems are still rated as poor on Talos. If we use them to send emails, those will get rejected by a lot of recipients (public sector). But if we don't use them to send emails, their reputation at Talos will not improve since support tells us "reputation improves as the ratio of legitimate mails increases with respect to the number of complaints". Do you guys have any hints on what is the proper way out of this circle? Regards Thomas Walter -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
