Noel Jones <njo...@megan.vbhcs.org> schrieb: > On 6/7/2014 8:33 AM, Kai Krakow wrote: >> Wietse Venema <wie...@porcupine.org> schrieb: >> >>> Kai Krakow: >>>> Hello list! >>>> >>>> Is there a way to prevent postfix from offering SASL auth (and >>>> that includes denying open relaying) to clients based on DNS RBL >>>> lookups? I've discovered the option smtpd_sasl_exceptions_networks >>>> which allows to do that by adding static subnet entries or adding >>>> a hash map. >>> >>> In theory, one could configure the smtpd_sasl_exceptions_networks >>> feature to query a daemon that replies "not found" when the client >>> IP address is blacklisted. >>> >>> smtpd_sasl_exceptions_networks = tcp:host:port >>> smtpd_sasl_exceptions_networks = socketmap:inet:host:port:name >>> smtpd_sasl_exceptions_networks = memcache:/file/name >>> >>> In practice, almost no-one will do that. But, this would do what >>> you asked for and more. >>> >>> Alternatively, you could update the smtpd_sasl_exceptions_networks >>> lookup table with fail2ban after Postfix logs some number of login >>> failures from a client IP address. >> >> I think I'd go that route. But from watching my log we don't have a >> problem with clients brute forcing on postfix SASL but with compromised >> servers (those which everyone can rent for a few bucks per month and >> nobody applies security patches to) using the right (hijacked) >> crediantials right from the beginning. > > I wonder why you're just trying to stop SASL from those client... > Why not just use reject_rbl_client (and maybe other restrictions) > before permit_sasl_authenticated to reject all mail from them? If > you're unwilling to accept SASL credentials, why would you accept > anything?
MX and Submission machine are the same postfix instance (and even the same worker process on port 25), it won't work. I'm planning to maybe change this in the future. But as with migrating all people to not submit on port 25 it is a long way to go. We are currently in the process of migrating customers to port 587. But there are still a lot who use old or silly mail clients which don't support TLS or even don't support port 587. I'm not able to do a hard cut because we are going the customer-confidence- first route. And then there is the fact that legitimate mails come in from networks we would never need to offer SASL auth to because those networks do not relay, they are directly submitting into the MX as MTA clients. So why offer a password authentication service to networks that don't need this features? It could close an attacking surface. The problem here is that we could never know beforehand when it is needed and when not. But we could disable this feature for networks we detect unexpected/unwanted behavior from. I'm looking for a way to implement that. We cannot even say that everything that does not look like dial-up by DNS lookup is not needing SASL. There are services out there running on servers with non-dial-up reverse lookups that do legitimate SASL lookups on our side. Wietse had a nice idea about rate limiting SASL login accounts during submission. Maybe I can exploit the resulting database to extract IPs and subnets with permanent spammy behavior and sync those into the SASL exception list. -- Replies to list only preferred.
