Re: How to block offering SASL auth to clients based on RBL
Alex JOST jost+postfix...@dimejo.at schrieb: Am 11.06.2014 21:17, schrieb Kai Krakow: * mbox server: handle pop3 and imap requests from users * accepts no external traffic, just from mailout / bulkmail * just a receiver for local domains * maybe handle dovecot outgoing mails (thou we didn't support anyway) Any ideas/suggestions? Do you see problems? When using Dovecot you should consider migrating away from mbox as suggested by the developer. http://dovecot.org/list/dovecot/2014-May/096318.html mbox was used as a generic term here. Actually, we are using maildir since years because mbox has bad performance and concurrency problems. -- Replies to list only preferred.
Re: How to block offering SASL auth to clients based on RBL
Am 11.06.2014 21:17, schrieb Kai Krakow: * mbox server: handle pop3 and imap requests from users * accepts no external traffic, just from mailout / bulkmail * just a receiver for local domains * maybe handle dovecot outgoing mails (thou we didn't support anyway) Any ideas/suggestions? Do you see problems? When using Dovecot you should consider migrating away from mbox as suggested by the developer. http://dovecot.org/list/dovecot/2014-May/096318.html -- Alex JOST
Re: How to block offering SASL auth to clients based on RBL
Stan Hoeppner s...@hardwarefreak.com schrieb: On 6/10/2014 3:39 PM, Wietse Venema wrote: Kai Krakow: BTW: In this context, what's the best approach to put mailboxes on a separate machine? Let the LDA drop mails into NFS mounts, or let postfix transport the mails via transport_map into a machine which hosts the LDA (dovecot in our case)? I recommend Dovecot via LMTP, but NFS would work, too, assuming one file per message. I can't say which approach would handle the most load. Dovecot's LMTP and LDA both perform index updates during delivery to the mailbox. They also enable Sieve. Dovecot's speedy performance is due in large part to its indexes. If you use the Postfix LDA to drop mail directly into maildir files, Dovecot will need to stat the new files to update its indexes, before responding to a LIST command. On a busy server this can be expensive, and responsiveness at the MUA may be sluggish. Thus I concur with Wietse. Use LMTP for performance, and to enable Sieve scripting. Okay, thanks to both of you. That are the pointers I need. I'm currently in the mood of creating a new mail server architecture based on the impressions from the last weeks: * mailin server: does MX and outbound mail * mailout server: handle user submissions only * transport mails to local domains via dovecot LMTP / to mbox server * transport mails to remote domains by passing them to mailin server * bulkmail server: handle user and webserver bulk submissions * handles mails generated by webservers (e.g. webforms) * handles newsletters from worker processes * other bulk purposes * maybe handle outbound bulk mails * can transport to local domains directly * mbox server: handle pop3 and imap requests from users * accepts no external traffic, just from mailout / bulkmail * just a receiver for local domains * maybe handle dovecot outgoing mails (thou we didn't support anyway) With this setup I can place different policies and rate limits for inbound/outbound. The mail servers mailin and mailout are named by view of the user altough the first handles external inbound/outbound, and the second handles submissions. Access to the bulk server could be limited to user accounts flagged as such. Any ideas/suggestions? Do you see problems? I'm not sure yet if I deploy this to different VM instances or just put multiple postfix instances on the same machine... I'd probably prefer the first. There's already a central and separated user db not outlined in this setup and accessed via mysql. -- Replies to list only preferred.
Re: How to block offering SASL auth to clients based on RBL
On Sat, Jun 7, 2014 at 3:33 PM, Kai Krakow hurikha...@gmail.com wrote: 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. What I do against this is; install CSF/LFD, the open/free suite of ConfigServer scripts. It has a wonderful option where you can prevent the blacklisted IP to even access postfix at all. Blocklists are controlled by modifying /etc/csf/csf.blocklists (I would recommend against using spamhaus or UCEprotect though, too many weird decisions there, and prone to false positives). So why not do that? In addition you get an awful lot of good security for your server. Regards, Julius Thijssen
Re: How to block offering SASL auth to clients based on RBL
Peter pe...@pajamian.dhs.org schrieb: On 06/08/2014 08:17 PM, Kai Krakow wrote: 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. If you can't force your users off of port 25, then the next best thing is to separate our your submission by IP address, if done correctly your users will be able to stay on port 25, not have to change the hostname (or any other settings in their MUA) and you will have separated out submission from MX traffic and can treat the two with different configs. Yes, that is the plan. Separate submission, MX, and mailboxes from each other, while during the same process migrate people to use port 587 on the new submission machine which has its port 25 hopefully closed... We already started to migrate new customers to port 587. But it is still on the same machine (though with a little different config), thus there's also port 25 available used by other customers. And those silly autodetection of older MUAs sticks to port 25 unencrypted. :-( So even new customers who redo their installations on their own silently go back to port 25. Maybe I'll add some flag into our user tables to block port 25 auth for new users. At least modern software does it right and tries 587 first, even Google Mail does it right if you configure an outgoing SMTP account. Apparently people tend to love old software and only use what they know. BTW: In this context, what's the best approach to put mailboxes on a separate machine? Let the LDA drop mails into NFS mounts, or let postfix transport the mails via transport_map into a machine which hosts the LDA (dovecot in our case)? -- Replies to list only preferred.
Re: How to block offering SASL auth to clients based on RBL
On 6/10/2014 1:24 PM, Kai Krakow hurikha...@gmail.com wrote: And those silly autodetection of older MUAs sticks to port 25 unencrypted. So even new customers who redo their installations on their own silently go back to port 25. So... why on earth are you allowing UNENCRYPTED AUTH at ALL, let alone on port 25?
Re: How to block offering SASL auth to clients based on RBL
Kai Krakow: BTW: In this context, what's the best approach to put mailboxes on a separate machine? Let the LDA drop mails into NFS mounts, or let postfix transport the mails via transport_map into a machine which hosts the LDA (dovecot in our case)? I recommend Dovecot via LMTP, but NFS would work, too, assuming one file per message. I can't say which approach would handle the most load. When I started work on Postfix, my dream configuration for inbound mail handling was: Internet - N x Postfix server - M x Mailbox server With N and M scaling up as needed. Wietse
Re: How to block offering SASL auth to clients based on RBL
On 6/10/2014 3:39 PM, Wietse Venema wrote: Kai Krakow: BTW: In this context, what's the best approach to put mailboxes on a separate machine? Let the LDA drop mails into NFS mounts, or let postfix transport the mails via transport_map into a machine which hosts the LDA (dovecot in our case)? I recommend Dovecot via LMTP, but NFS would work, too, assuming one file per message. I can't say which approach would handle the most load. Dovecot's LMTP and LDA both perform index updates during delivery to the mailbox. They also enable Sieve. Dovecot's speedy performance is due in large part to its indexes. If you use the Postfix LDA to drop mail directly into maildir files, Dovecot will need to stat the new files to update its indexes, before responding to a LIST command. On a busy server this can be expensive, and responsiveness at the MUA may be sluggish. Thus I concur with Wietse. Use LMTP for performance, and to enable Sieve scripting. Cheers, Stan
Re: How to block offering SASL auth to clients based on RBL
On 06/09/2014 04:56 PM, li...@rhsoft.net wrote: well, one could say: block them from submission port and don't allow SASL on 25, but that works only if you are a startup beginning from scratch, If that's the case then you can put submission on a separate IP address, so that your users can continue to submit to port 25 so that your users can continue to submit to port 25 and how will that lead to close port 25 completly? So on the one hand you complain about how difficult it is to switch users off of port 25, but then when I give you a solution that means you don't have to you complain because you don't want them on port 25? Make up your mind, please. my server has not to handle *any* MX traffic from outside, Then I fail to see what the problem is. besides that you gain nothing why in the world should admins deal with all sort of workarounds because MUA developers are too stupid for sane defaults and insist in use 25? Please, go to Microsoft, Apple, Google, etc, and convince all of them to write their software the way you want. Unfortunately we live in the real world and this is what we have to deal with. Depending on your specific situation you may or may not have to cater to those MUAs. frankly *all* ISP's should start to block outgoing port 25 I would love to see that, but again, we live in the real world. and the problem would go away at the same time as 90% of attempted spam delivery would disappear because all the infected zombies have no longer a way to send their crap without hacking the acount data and use real submission PBLs, FCRDNS, etc help a lot with this as well. Postscreen, when properly configured, is great at filtering zombie SPAM. The harder SPAM to filter tends to be SPAM that originates from legitimate servers, as you have said. the difference ISP is blocking 25 or i do the same is simply that nobody calls the ISP but anybody blames his mail admin which can help in both cases but in one point to the ISP :-) Regardless of who is blocking it you have to deal with the results. As I said earlier you may be in a position where you can just block 25 outright and be able to push all your users to submission, or this may be too overwhelming of a task. The difference is that if the ISP blocks it then the user is *already* on 587. Peter
Re: How to block offering SASL auth to clients based on RBL
On 06/08/2014 08:17 PM, Kai Krakow wrote: 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. If you can't force your users off of port 25, then the next best thing is to separate our your submission by IP address, if done correctly your users will be able to stay on port 25, not have to change the hostname (or any other settings in their MUA) and you will have separated out submission from MX traffic and can treat the two with different configs. Peter
Re: How to block offering SASL auth to clients based on RBL
Noel Jones njo...@megan.vbhcs.org schrieb: On 6/7/2014 10:53 AM, li...@rhsoft.net wrote: Am 07.06.2014 17:25, schrieb Noel Jones: 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? i think the point for different RBL lists for incoming mail and SASL is pretty clear that you have a problem if you are using dialup-lists for your un-authenticated incoming mail flow you can't use the same for submission or better said: There are two general types of RBL -- bad neighborhoods and bad behavior. One would generally not block SASL to a bad neighborhood, but maybe useful to block SASL to a host with bad behavior. The original question was about using an RBL to block SASL based on bad behavior. Obviously the OP has such an RBL in mind already. Why would you want any mail from a known bad host? Actually I don't care if I disable relaying (which can only be done using SASL anyway) for subnets or bad bahaving AS. But I still want legitimate mail come in for my customers - even if it originates from such networks. But I want to (automatically) block the suspicious networks and not first block all then whitelist the known-good. -- Replies to list only preferred.
Re: How to block offering SASL auth to clients based on RBL
Wietse Venema wie...@porcupine.org schrieb: Kai Krakow: 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. Typically, this is done with postfwd (a third-party program) rate limits. Either rate limit the envelope sender address (assuming that you use smtpd_sender_login_maps to prevent sender spoofing) or rate limit the sasl_username attribute. 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. I could rip out the DNSBL client code from the Postfix SMTP daemon source code and make it available as 1) a lookup table to all programs 2) a library module that implements the underlying DNS client code. Defer that idea... I think it is not nedded yet because I currently like this idea: 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 In that case, rate limiting by sasl login account is the way to go. Good luck. I didn't know I could rate limit based on the SASL login account. I will try that, sounds like the way to go. It will not completely block those mails but at list mitigate such problems a lot. Still, I think it could be clever not offering SASL auth to bad behaving networks if those have been suspicious in the past. It could stop the hackers from even knowing if the credentials are correct, read: stop them from trying the account for spam sending right at the beginning so they (hopefully) just discard that account as not working. -- Replies to list only preferred.
Re: How to block offering SASL auth to clients based on RBL
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.
Re: How to block offering SASL auth to clients based on RBL
On Sun, 8 Jun 2014, Kai Krakow wrote: Noel Jones njo...@megan.vbhcs.org schrieb: But I want to (automatically) block the suspicious networks and not first block all then whitelist the known-good. Not sure I completely understand the issue, but is this something where you could use fail2ban to monitor your logs in real time and autoban via iptables any ip that had failed logins? You could whitelist your own ip range so they never get bannned regardless. -- Joe Laffey The Stable Visual Effects http://TheStable.tv/?e34523M/
Re: How to block offering SASL auth to clients based on RBL
Am 08.06.2014 17:18, schrieb Joe Laffey: On Sun, 8 Jun 2014, Kai Krakow wrote: Noel Jones njo...@megan.vbhcs.org schrieb: But I want to (automatically) block the suspicious networks and not first block all then whitelist the known-good. Not sure I completely understand the issue, but is this something where you could use fail2ban to monitor your logs in real time and autoban via iptables any ip that had failed logins? You could whitelist your own ip range so they never get bannned regardless. the idea of using a RBL is that you can setup your own honeypot like i did last weekend, feed your own RBL and most likely get only real bad bots and *before* they ever touch your machine our honeypot ist using free public IP's and listens on every common port writing every connecting IP into a RBL within a week 4 client IP's and 15%-20% don't expire after the configured 7 days because they come alaways back you can assume no customer ever will touch the honeypot
Re: How to block offering SASL auth to clients based on RBL
On Sun, 8 Jun 2014, li...@rhsoft.net wrote: Am 08.06.2014 17:18, schrieb Joe Laffey: On Sun, 8 Jun 2014, Kai Krakow wrote: Noel Jones njo...@megan.vbhcs.org schrieb: But I want to (automatically) block the suspicious networks and not first block all then whitelist the known-good. Not sure I completely understand the issue, but is this something where you could use fail2ban to monitor your logs in real time and autoban via iptables any ip that had failed logins? You could whitelist your own ip range so they never get bannned regardless. the idea of using a RBL is that you can setup your own honeypot like i did last weekend, feed your own RBL and most likely get only real bad bots and *before* they ever touch your machine our honeypot ist using free public IP's and listens on every common port writing every connecting IP into a RBL within a week 4 client IP's and 15%-20% don't expire after the configured 7 days because they come alaways back you can assume no customer ever will touch the honeypot Could you possibly set up a honeypot that feeds its logs via syslogging to your main server... then use fail2ban to ban ips from that log as well? You could even used separate regexes that matched only logs from the honeypot and have a much greater ban time on those. I do see the speed advantage to an RBL, and we used to run one that was mainly manually set up (using djbdns's rbl). I have just fallen in love with the auto operation of tools like fail2ban. Either way, the honeypot is a good idea to catch some known spammers. Though are we talking about spammers trying to guess SASL passwords, or ones that already have account credentials, or open relays? Note that I believe fail2ban could be setup with custom regexps to be used as a rate limiting tool for sending mail with valid credentials. Perhaps not the best solution for that, as it completely blocks the ip, but it would be automatic. -- Joe Laffey The Stable Visual Effects http://TheStable.tv/?e34525M/
Re: How to block offering SASL auth to clients based on RBL
Am 08.06.2014 18:27, schrieb Joe Laffey: On Sun, 8 Jun 2014, li...@rhsoft.net wrote: Am 08.06.2014 17:18, schrieb Joe Laffey: On Sun, 8 Jun 2014, Kai Krakow wrote: Noel Jones njo...@megan.vbhcs.org schrieb: But I want to (automatically) block the suspicious networks and not first block all then whitelist the known-good. Not sure I completely understand the issue, but is this something where you could use fail2ban to monitor your logs in real time and autoban via iptables any ip that had failed logins? You could whitelist your own ip range so they never get bannned regardless. the idea of using a RBL is that you can setup your own honeypot like i did last weekend, feed your own RBL and most likely get only real bad bots and *before* they ever touch your machine our honeypot ist using free public IP's and listens on every common port writing every connecting IP into a RBL within a week 4 client IP's and 15%-20% don't expire after the configured 7 days because they come alaways back you can assume no customer ever will touch the honeypot Could you possibly set up a honeypot that feeds its logs via syslogging to your main server... then use fail2ban to ban ips from that log as well? You could even used separate regexes that matched only logs from the honeypot and have a much greater ban time on those. I do see the speed advantage to an RBL, and we used to run one that was mainly manually set up (using djbdns's rbl). I have just fallen in love with the auto operation of tools like fail2ban. Either way, the honeypot is a good idea to catch some known spammers. Though are we talking about spammers trying to guess SASL passwords, or ones that already have account credentials, or open relays? Note that I believe fail2ban could be setup with custom regexps to be used as a rate limiting tool for sending mail with valid credentials. Perhaps not the best solution for that, as it completely blocks the ip, but it would be automatic. surely you could do a lot of things but why setup fail2ban at all if you have no sshd on standard ports and already a hyperfast rbldnsd running which scales over more than one server without touch any configuration frankly you can even use your RBL with web application firewalls http://blog.modsecurity.org/2010/09/advanced-topic-of-the-week-real-time-blacklist-lookups.html
Re: How to block offering SASL auth to clients based on RBL
On Sun, 8 Jun 2014, li...@rhsoft.net wrote: but why setup fail2ban at all if you have no sshd on standard ports and already a hyperfast rbldnsd running which scales over more than one server without touch any configuration frankly you can even use your RBL with web application firewalls http://blog.modsecurity.org/2010/09/advanced-topic-of-the-week-real-time-blacklist-lookups.html Interesting... Certainly much more scalable if you need that level of flexibility. I would still use fail2ban or similar on sshd on non-standrd ports. However, I hardly ever get hits on the non-standard sshd ports I have been using for well over 15 years. But this is a topic for another mailing list. -- Joe Laffey The Stable Visual Effects http://TheStable.tv/?e34526M/
Re: How to block offering SASL auth to clients based on RBL
On 06/08/2014 08:53 AM, LuKreme wrote: the stupidity is trying 25 first That is still what most servers support or even require. I think the vast number of ESPs will accept submission on port 587. Only supporting port 25 for submission nowadays is a disaster considering the number of ISPs that block outbound port 25. Many will still offer 25 for backwards compatibility, but even those will use a separate IP address in the vast majority of cases so as not to mix submission with MX traffic. Peter
Re: How to block offering SASL auth to clients based on RBL
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. 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. Wietse
Re: How to block offering SASL auth to clients based on RBL
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
Re: How to block offering SASL auth to clients based on RBL
Kai Krakow: 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. Typically, this is done with postfwd (a third-party program) rate limits. Either rate limit the envelope sender address (assuming that you use smtpd_sender_login_maps to prevent sender spoofing) or rate limit the sasl_username attribute. 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. I could rip out the DNSBL client code from the Postfix SMTP daemon source code and make it available as 1) a lookup table to all programs 2) a library module that implements the underlying DNS client code. 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 In that case, rate limiting by sasl login account is the way to go. Good luck. Wietse
Re: How to block offering SASL auth to clients based on RBL
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? -- Noel Jones
Re: How to block offering SASL auth to clients based on RBL
Am 07.06.2014 17:25, schrieb Noel Jones: 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? i think the point for different RBL lists for incoming mail and SASL is pretty clear that you have a problem if you are using dialup-lists for your un-authenticated incoming mail flow you can't use the same for submission or better said: typically you have permit_sasl_authenticated in any case before the RBL's and for using RBL's in front of submission they must be much more careful selected and should only contain known abusive IP's but not kill all enduser-dialup-ranges or you end in no longer have any mail-customer in a short * MX: you don't want clients-adsl-xx-xx-xx-some-isp.domain.tld deliver mail * SUBMISSION: you don't want to block that customer ranges completly well, one could say: block them from submission port and don't allow SASL on 25, but that works only if you are a startup beginning from scratch, i condsidered that but it would take weeks and months to explain all customers that they have to fix their client configs and i see even new configured clients using 25 because the idiotic MUA's still default to 25 and burrie the port setting somewhere under expert or extended settings, so you can't do that if you have hundrets of customers with all sort of devices iPhones and Apple Mail permanently disable SASL auth for unknown reasons or in case of password changes need to re-configure the outgoing mailserver seperated from the incoming creating enough work for a sysadmins lifetime
Re: How to block offering SASL auth to clients based on RBL
On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote: i condsidered that but it would take weeks and months to explain all customers that they have to fix their client configs and i see even new configured clients using 25 because the idiotic MUA's still default to 25 and burrie the port setting somewhere under expert or extended settings, so you can't do that if you have hundrets of customers with all sort of devices Don't most modern clients try 25 first, then fall back to other ports (587 and the stupid one I forget and don't support)? When I eliminated connecting on port 25 for clients it was pretty seamless, albeit most of them are Mac users, so they never even noticed the change. iPhones and Apple Mail permanently disable SASL auth for unknown reasons or in case of password changes need to re-configure the outgoing mailserver seperated from the incoming creating enough work for a sysadmins lifetime I have no idea what you are talking about; I've never had any issue with secure connections from iOS or OS X to my mail server. -- I want a refund, I want a light, I want a reason for all this night after night after night after night
Re: How to block offering SASL auth to clients based on RBL
Am 07.06.2014 18:29, schrieb LuKreme: On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote: i condsidered that but it would take weeks and months to explain all customers that they have to fix their client configs and i see even new configured clients using 25 because the idiotic MUA's still default to 25 and burrie the port setting somewhere under expert or extended settings, so you can't do that if you have hundrets of customers with all sort of devices Don't most modern clients try 25 first, then fall back to other ports (587 and the stupid one I forget and don't support)? the stupidity is trying 25 first When I eliminated connecting on port 25 for clients it was pretty seamless, albeit most of them are Mac users, so they never even noticed the change. define modern client i had *recently* one which client did not work after we switched to a 4096/SHA-256 cert, guess what, Eudora on a Apple machine, yes i answered with i don't care *but* i can't answer that all day long for all sort of cases iPhones and Apple Mail permanently disable SASL auth for unknown reasons or in case of password changes need to re-configure the outgoing mailserver seperated from the incoming creating enough work for a sysadmins lifetime I have no idea what you are talking about; I've never had any issue with secure connections from iOS or OS X to my mail server did i say anything about secure connections? * the setting for using authentication get lost repeatly if you haven't seen that you have to few Apple users the iPhones try again and again after that send unautheticated * after heartblead we forced all users to change their passwords on the stupid Apple clients you need to change the password seperatly for incoming and outgoing mail while even Outlook for a decase has a checkbox use same credentials as for incoming mail * and not the f**ing Apple clients don't ask for the new password after the first error * frankly a trained monkey could develop the code to enter only username and password and try the same credentials on 587 by default instead try first 25 or send unauthenticated the Apple user *never takes notice* if sending fails *never* if you want i can give you a log where the same iPhone for weeks tried every 5 minutes send to somebody[at]gmail.com resulting in 15 error messages on the server side and the user even needed 5 mails and finally a phone call asking what exectly he don't understand in my mails and why t**uck he don't ask or just stop copy blindly protected mail adresses in a client developed by monkeys unable to verify if a address can be valid at all by not containing a @
Re: How to block offering SASL auth to clients based on RBL
Am 07.06.2014 09:59, 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. The idea goes like this: * SASL auth is not offered - no way to relay mail * based on a DNS-RBL that lists ASs with known bad behavior * based on a DNS-RBL that lists IPs which are known to run compromised servers I imagined a configuration like this: smtpd_sasl_exceptions_networks = reject_rbl_client z.mailspike.net=127.0.0.2 reject_rbl_client dnsbl-3.uceprotect.net Apart from this maybe being a bad idea, it would open the possibility to react to distributed brute force attacks and compromised passwords if an appropriate DNS BL could be offered by someone. Currently, I'd like to try out the idea but I'm not sure if the above configuration accepts passing in DNS BLs. Any suggestions? What could be the consequences of this? I'm interested in reading more ideas. Maybe there's already another approach to successfully prevent bots from using compromised mail user accounts? I outlined the same question here: http://serverfault.com/questions/602327/postfix-offer-sasl-authentication-based-on-rbl bad idea, perhaps good idea if you have your own rbl to sync brute forcers ips to other servers perhaps you like or get inspired by this https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/ Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: How to block offering SASL auth to clients based on RBL
On 6/7/2014 10:53 AM, li...@rhsoft.net wrote: Am 07.06.2014 17:25, schrieb Noel Jones: 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? i think the point for different RBL lists for incoming mail and SASL is pretty clear that you have a problem if you are using dialup-lists for your un-authenticated incoming mail flow you can't use the same for submission or better said: There are two general types of RBL -- bad neighborhoods and bad behavior. One would generally not block SASL to a bad neighborhood, but maybe useful to block SASL to a host with bad behavior. The original question was about using an RBL to block SASL based on bad behavior. Obviously the OP has such an RBL in mind already. Why would you want any mail from a known bad host? -- Noel Jones
Re: How to block offering SASL auth to clients based on RBL
On 07 Jun 2014, at 10:39 , li...@rhsoft.net wrote: Am 07.06.2014 18:29, schrieb LuKreme: On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote: i condsidered that but it would take weeks and months to explain all customers that they have to fix their client configs and i see even new configured clients using 25 because the idiotic MUA's still default to 25 and burrie the port setting somewhere under expert or extended settings, so you can't do that if you have hundrets of customers with all sort of devices Don't most modern clients try 25 first, then fall back to other ports (587 and the stupid one I forget and don't support)? the stupidity is trying 25 first That is still what most servers support or even require. When I eliminated connecting on port 25 for clients it was pretty seamless, albeit most of them are Mac users, so they never even noticed the change. define modern client i had *recently* one which client did not work after we switched to a 4096/SHA-256 cert, guess what, Eudora on a Apple machine, yes i answered with i don't care Eudora? Eudora hasn’t been supported for many many years,a nd hasn’t had much if any envelopment on it for a decade. Certainly not modern in any sense of the word. iPhones and Apple Mail permanently disable SASL auth for unknown reasons or in case of password changes need to re-configure the outgoing mailserver seperated from the incoming creating enough work for a sysadmins lifetime I have no idea what you are talking about; I've never had any issue with secure connections from iOS or OS X to my mail server did i say anything about secure connections? You said SASL auth. * the setting for using authentication get lost repeatly if you haven't seen that you have to few Apple users the iPhones try again and again after that send unautheticated Never seen that. Run OS X and iOS all day every day, as do many users. * after heartblead we forced all users to change their passwords on the stupid Apple clients you need to change the password seperatly for incoming and outgoing mail while even Outlook for a decase has a checkbox use same credentials as for incoming mail” Since incoming and outgoing can be different, that’s really not that big a deal. * and not the f**ing Apple clients don't ask for the new password after the first error That’s certainly not true. I get asked for my Gmail password all the damn time (because Google app specific password for 2-factor users don;t work well). * frankly a trained monkey could develop the code to enter only username and password and try the same credentials on 587 by default instead try first 25 or send unauthenticated Sorry, this is not what happens unless, maybe, you allow unauthenticated submission on port 25? Dunno, I never did that. Mail.app and iOS first try port 25, then try 587, then try… I think it’s 465? the Apple user *never takes notice* if sending fails *never* That is not true. If sending fails it tells you and asks if you want to use a different server (if more than one is configured) or asks you ant you want to do, including try-again or edit the message. if you want i can give you a log where the same iPhone for weeks tried every 5 minutes send to somebody[at]gmail.com resulting in 15 error messages If you server reject the email, both iOS and OS X do not retry. I have no idea what you (or your user) did to generate 150,000 error messages, but that is not what has ever happened here. You cannot send a mail from Apple mail or iOS to “someone[at]gmail.com. It will reject it before sending. https://www.dropbox.com/s/tm6bvy7v8t1kuu9/Screenshot%202014-06-07%2014.48.53.PNG If you try to send it anyway, you get: https://www.dropbox.com/s/wwpvycgcopn8q7u/Screenshot%202014-06-07%2014.50.38.PNG The behavior of iOS is similar, though i does not ask you for another server, it just says the address was rejected by the server and the message was not sent. on the server side and the user even needed 5 mails and finally a phone call asking what exectly he don't understand in my mails and why t**uck he don't ask or just stop copy blindly protected mail adresses So your user is dumb? in a client developed by monkeys You sound a lot like an anti-Apple bigot with an axe to grind. unable to verify if a addresscan be valid at all by not containing a @ Again, I don’t know what happened, but what you describe is simply not at all how anything works. -- 'Are you Death?' IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
Re: How to block offering SASL auth to clients based on RBL
Am 07.06.2014 22:53, schrieb LuKreme: On 07 Jun 2014, at 10:39 , li...@rhsoft.net wrote: Am 07.06.2014 18:29, schrieb LuKreme: On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote: i condsidered that but it would take weeks and months to explain all customers that they have to fix their client configs and i see even new configured clients using 25 because the idiotic MUA's still default to 25 and burrie the port setting somewhere under expert or extended settings, so you can't do that if you have hundrets of customers with all sort of devices Don't most modern clients try 25 first, then fall back to other ports (587 and the stupid one I forget and don't support)? the stupidity is trying 25 first That is still what most servers support or even require. well, and now tell me a valid reason that a mail-client while setup a new account could not do a simple check if 587 is available and only in case it's not available fall back to 25 When I eliminated connecting on port 25 for clients it was pretty seamless, albeit most of them are Mac users, so they never even noticed the change. define modern client i had *recently* one which client did not work after we switched to a 4096/SHA-256 cert, guess what, Eudora on a Apple machine, yes i answered with i don't care Eudora? Eudora hasn’t been supported for many many years,a nd hasn’t had much if any envelopment on it for a decade. Certainly not modern in any sense of the word. i know that you know that now the customer knows fine if something affects only a few customers but that don't change the fact taht if you have to support hundrets of them you can chose between be careful or face a support nightmare after changes iPhones and Apple Mail permanently disable SASL auth for unknown reasons or in case of password changes need to re-configure the outgoing mailserver seperated from the incoming creating enough work for a sysadmins lifetime I have no idea what you are talking about; I've never had any issue with secure connections from iOS or OS X to my mail server did i say anything about secure connections? You said SASL auth in the world i live SASL has nothing to do with the connection a secure connection by defintion is encrypted with TLS * the setting for using authentication get lost repeatly if you haven't seen that you have to few Apple users the iPhones try again and again after that send unautheticated Never seen that. Run OS X and iOS all day every day, as do many users. fine for you, i have that problem mutiple times each month for multiple customers as well as sometimes even for people in the own company which for sure have no new iPhone * after heartblead we forced all users to change their passwords on the stupid Apple clients you need to change the password seperatly for incoming and outgoing mail while even Outlook for a decase has a checkbox use same credentials as for incoming mail” Since incoming and outgoing can be different, that’s really not that big a deal. it *can* be different, most time it is not and even if POP3/IMAP is not the same server the user database is shared i know nobody on this planet maintaining different user databases for SMTP and IMAP/POP3 * and not the f**ing Apple clients don't ask for the new password after the first error That’s certainly not true. I get asked for my Gmail password all the damn time (because Google app specific password for 2-factor users don;t work well). it is true otherwise you can't explain why people in the same room had that problem * frankly a trained monkey could develop the code to enter only username and password and try the same credentials on 587 by default instead try first 25 or send unauthenticated Sorry, this is not what happens unless, maybe, you allow unauthenticated submission on port 25? Dunno, I never did that. surely, i allow that from my_networks otherwise any switch, heat sensor and what not would need SASL accounts Mail.app and iOS first try port 25, then try 587, then try… I think it’s 465? and *that* is plain stupid first 587 and *then* 25 is the way to go the Apple user *never takes notice* if sending fails *never* That is not true. If sending fails it tells you and asks if you want to use a different server (if more than one is configured) or asks you ant you want to do, including try-again or edit the message. ah so you explain me all the thousands of lines in my maillog from iPhones using invalid RCPT's, no authentication at all and trying over weeks every 5 minutes did not happen - than the postfix log lies or you have only very few users if you want i can give you a log where the same iPhone for weeks tried every 5 minutes send to somebody[at]gmail.com resulting in 15 error messages If you server reject the email, both iOS and OS X do not retry. I have no idea what you (or your user) did to generate 150,000 error messages, but that is
