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. If I could find a list with compromised servers or build such a list of IPs by some heuristics, it would be easy to fill a lookup table for postfix. How is one supposed to automatically block such hijacked accounts within postfix? A simple heuristic could be detecting unusual high mail volume for that account, probably by detecting the always repeating or similar subjects. > To add DNSBL lookups to smtpd_sasl_exceptions_networks, one would > have to use maptype:mapname syntax (e.g., dnsbl:site.example.com, > dnsbl:site.example.com=filter, where the dnsbl: lookup table exists > only in the Postfix SMTP daemon). This is because the underlying > mechanism is used by all Postfix programs, and most programs must > not have dependencies on DNSBL support. However, lookup tables that > work in only one program would make Postfix more difficult to use. Using DNSBL and some sort of distributed heuristic detectors could easily identify compromised servers and automatically make postfix stop offering SASL auth to those clients. Although probably currently no one would do that, I still think this is an interesting idea although the proposed implementation may not be optimal in postfix yet. Background (tl;dr): We are hosting over 600 customer domains. There's always one or another who has his mail accounts compromised by a trojan. From information disclosed by German BSI, I deduce that those trojan infections may be years ago so password data collection by trojans has already a long history and went undetected for months or years. On the other hand we cannot force our users to change their passwords every few months. During the last weeks we started playing hare and hedgehog with those attackers. First, one customer's mail domain has been abused as sending domain to send thousands of mails out to real mail accounts, with almost no bounces, through a compromised server out of our control. We placed SPF records to mitigate the issue. That even had an effect because after a few hours, the mails stopped being sent from that server and instead now the attackers started relaying those mails directly through our server by using correct credentials and changing client IPs. We locked the account by changing credentials and felt confident, until after a few more hours, the customer directly sent those mails from his dial-up IP. We found that his systems had been infected with a bot net which is now used to spread the mails and the password has been compromised again. We sent in our support team who cleaned the infection and now it is fixed. But we are seeing similar behavior starting for other customer domains. It's scary to see this. I'm feeling we are going to see such issues more often in the future. Our postfix system blocks almost all incoming spam with almost no false positives (mostly customers who communicate with East Europe are affected by false positives, and we whitelisted those few servers or contacted the admins to fix their DNS/HELO). It's a several years old postfix configuration tuned regularily with a combination of greylisting, policyd- weight, a few very reliable DNS BLs for immediate blocking, and a combination of downstream spamassassin and different virus scanners (at least on of server level, customer firewall level, customer mail gateway level, client PC level). But in the last few weeks we become listed on blacklists more and more often, one of the most annoying being UCEprotect - and almost always by compromised mail accounts. I don't understand how mail administrators can opt-in to base their blocking decision on only one blacklist (that being UCEprotect) but that is another story - as is with UCEprotect as blacklist provider itself (they have a well established system of spam traps which is good but they are doing "questionable business practice"). -- Replies to list only preferred.
