How to block offering SASL auth to clients based on RBL

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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.

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.

Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Kai Krakow
Wietse Venema <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Noel Jones-2
In reply to this post by Kai Krakow
On 6/7/2014 8:33 AM, Kai Krakow wrote:

> Wietse Venema <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

lists@rhsoft.net


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
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

@lbutlr

On 07 Jun 2014, at 09:53 , [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

lists@rhsoft.net


Am 07.06.2014 18:29, schrieb LuKreme:

>
> On 07 Jun 2014, at 09:53 , [hidden email] 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 150000 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 @
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Robert Schetterer-2
In reply to this post by Kai Krakow
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
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Noel Jones-2
In reply to this post by lists@rhsoft.net
On 6/7/2014 10:53 AM, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

@lbutlr
In reply to this post by lists@rhsoft.net

> On 07 Jun 2014, at 10:39 , [hidden email] wrote:
>
>
>
> Am 07.06.2014 18:29, schrieb LuKreme:
>>
>> On 07 Jun 2014, at 09:53 , [hidden email] 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 150000 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.

Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

lists@rhsoft.net


Am 07.06.2014 22:53, schrieb LuKreme:

>> On 07 Jun 2014, at 10:39 , [hidden email] wrote:
>>
>> Am 07.06.2014 18:29, schrieb LuKreme:
>>>
>>> On 07 Jun 2014, at 09:53 , [hidden email] 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 150000 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.

it will *not* reject it before sending

the **** with his iPhone needed even handholding to remove hat
message from the outgoing folder and tried to explain me he
can't delete it

the other one tried over *6 months* again and again send unauthenticated
after this crap device got stolen and i was even able to tell him day and
time when it was stolen from the maillog

> 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

that screen is hardly an iphone

> 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.

yes, because my postfix rejects such messages
but what happens is that it is retried again and again

proven by psotfix logs and after call the user bad names
it stopped *weeks* before the first attempt

>> 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?

he is just an Apple user and i face that problems with around
5 up to 10 users each month - now guess if all the users are
dumb or Apple is to dumb for create a sane mail client

>> in a client developed by monkeys
>
> You sound a lot like an anti-Apple bigot with an axe to grind.

guess why - *because* that crap devices are stealing my time for years

>> 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.

i know my server logs, they are real
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Kai Krakow
In reply to this post by Noel Jones-2
Noel Jones <[hidden email]> schrieb:

> On 6/7/2014 10:53 AM, [hidden email] 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.

Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Kai Krakow
In reply to this post by Wietse Venema
Wietse Venema <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Kai Krakow
In reply to this post by Noel Jones-2
Noel Jones <[hidden email]> schrieb:

> On 6/7/2014 8:33 AM, Kai Krakow wrote:
>> Wietse Venema <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Joe Laffey
In reply to this post by Kai Krakow
On Sun, 8 Jun 2014, Kai Krakow wrote:

> Noel Jones <[hidden email]> 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/
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

lists@rhsoft.net


Am 08.06.2014 17:18, schrieb Joe Laffey:

> On Sun, 8 Jun 2014, Kai Krakow wrote:
>
>> Noel Jones <[hidden email]> 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 40000 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
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Joe Laffey
On Sun, 8 Jun 2014, [hidden email] wrote:

>
>
> Am 08.06.2014 17:18, schrieb Joe Laffey:
>> On Sun, 8 Jun 2014, Kai Krakow wrote:
>>
>>> Noel Jones <[hidden email]> 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 40000 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/
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

lists@rhsoft.net

Am 08.06.2014 18:27, schrieb Joe Laffey:

> On Sun, 8 Jun 2014, [hidden email] wrote:
>> Am 08.06.2014 17:18, schrieb Joe Laffey:
>>> On Sun, 8 Jun 2014, Kai Krakow wrote:
>>>
>>>> Noel Jones <[hidden email]> 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 40000 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
Reply | Threaded
Open this post in threaded view
|

Re: How to block offering SASL auth to clients based on RBL

Joe Laffey
On Sun, 8 Jun 2014, [hidden email] 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/
12