How to block offering SASL auth to clients based on RBL
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 -- Replies to list only preferred.
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 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
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 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 mes
